lobi's questions

Procurando executar um script na primeira segunda-feira do mês, depois um script diferente na primeira quarta-feira do mês.

A questão é que, se um novo mês começar em uma terça-feira, por exemplo, a ação "primeira quarta-feira do mês" será a primeira. Eu gostaria de ter isso configurado para que a ação "primeira quarta-feira do mês" ocorra apenas se for seguida de uma segunda-feira dentro desse mês.

A lógica pode ser usada para descobrir isso de uma perspectiva de script, mas o problema é que eu preciso disso em uma expressão cron, pois essa é a única maneira de agendar isso no sistema que estou usando (requer uma expressão cron para agendamento avançado , e detalhes deste sistema não são relevantes para esta questão).

Edit: Não há dependência ou relacionamento entre os scripts mencionados acima sendo executados pelo cron. Para simplificar a pergunta, eles seriam simplesmente dois cronjobs separados no mesmo crontab.

Procurando espelhar a porta de uma interface de firewall de rede, conecte essa interface a um servidor Linux e faça com que esse servidor Linux execute constantemente um tcpdump e armazene a saída em arquivos.

Especificamente, meu requisito é que os arquivos pcap sejam salvos repetidamente, pois o tamanho desse arquivo atinge um número específico.

Por exemplo:

A porta 2 do firewall Juniper espelha todo o tráfego na porta 1. A porta 2 se conecta ao eth0 no servidor Linux. O servidor Linux tem um processo tcpdump em execução constante no eth0. O servidor Linux está configurado para salvar o tráfego em um arquivo chamado "tcpdump.pcap", mas quando o arquivo pcap exceder um tamanho específico, ele será compactado e renomeado para "tcpdump.pcap.0.gz". Como o segundo arquivo excede um tamanho específico, ele será renomeado para "tcpdump.pcap.1.gz", etc.

Isso me permitirá visualizar o tráfego de rede no último período de tempo X (por enquanto, estou procurando ter visibilidade nas últimas 72 horas).

O problema aqui é que não sei como fazer o que foi dito acima. Especificamente, como faço para que o tcpdump seja executado continuamente e salve automaticamente os pcaps, comprima e renomeie automaticamente cronologicamente?

Ao usar um servidor OpenVPN TUN (camada 3) client-to-clientdesativado, meus clientes ainda podem se comunicar.

A configuração de cliente para cliente deve evitar isso de acordo com a documentação:

Remova o comentário da diretiva cliente-para-cliente se desejar que os clientes conectados possam se comunicar pela VPN. Por padrão, os clientes só poderão acessar o servidor.

Por que os clientes podem continuar se comunicando quando esta opção está desativada?

Aqui está o conf do meu servidor:

port 443
proto tcp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh4096.pem
topology subnet
server 10.10.201.0 255.255.255.128
ifconfig-pool-persist ipp.txt
crl-verify /etc/openvpn/keys/crl.pem
push "route [omitted]"
push "dhcp-option DNS [omitted]"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so login
cipher AES-256-CBC
tls-auth /etc/openvpn/keys/pfs.key 0
verb 4

Ubuntu 14.x. Usando grep para procurar todos os arquivos linuxtest-client2 . Isso inclui várias extensões de arquivo (csr, crt, chave). Quando eu grep para a parte do meio do nome do arquivo, "2.", ele também retorna linhas que contêm "2" além de "2". ao usar ls -l com ele. Isso faz com que sejam retornados resultados com "2" no tamanho do arquivo, data e hora.

Por que os tamanhos de arquivo estão sendo acionados por este grep quando não há ponto após eles?:

root@ip-10-198-0-205:/etc/easy-rsa# ls -ltr keys/ | grep -E '*2.*'
total 228
-rw------- 1 root root 3272 Oct 15 18:28 ca.key
-rw-r--r-- 1 root root 2451 Oct 15 18:28 ca.crt
-rw------- 1 root root 3268 Oct 15 18:31 server.key
-rw-r--r-- 1 root root  769 Oct 15 18:42 dh4096.pem
-rw-r--r-- 1 root root 8244 Oct 19 15:36 02.pem
-rw-r--r-- 1 root root 8250 Oct 19 19:21 03.pem
-rw------- 1 root root 3394 Oct 23 19:48 removemetest.key
-rw-r--r-- 1 root root 1785 Oct 23 19:48 removemetest.csr
-rw-r--r-- 1 root root 8264 Oct 23 19:48 removemetest.crt
-rw-r--r-- 1 root root 8264 Oct 23 19:48 04.pem
-rw------- 1 root root 3394 Oct 23 20:50 revoketest449.key
-rw-r--r-- 1 root root 1789 Oct 23 20:50 revoketest449.csr
-rw-r--r-- 1 root root 8270 Oct 23 20:50 revoketest449.crt
-rw-r--r-- 1 root root 8270 Oct 23 20:50 05.pem
-rw-r--r-- 1 root root 3633 Oct 23 20:50 revoke-test.pem
-rw-r--r-- 1 root root 1182 Oct 23 20:50 crl.pem
-rw------- 1 root root 3394 Oct 23 20:54 linuxtest-client1.key
-rw-r--r-- 1 root root 1793 Oct 23 20:54 linuxtest-client1.csr
-rw-r--r-- 1 root root    3 Oct 23 20:54 serial.old
-rw-r--r-- 1 root root 8287 Oct 23 20:54 linuxtest-client1.crt
-rw-r--r-- 1 root root  909 Oct 23 20:54 index.txt.old
-rw-r--r-- 1 root root   21 Oct 23 20:54 index.txt.attr.old
-rw-r--r-- 1 root root 8287 Oct 23 20:54 06.pem
-rw------- 1 root root 3394 Oct 26 17:57 linuxtest-client2.key
-rw-r--r-- 1 root root 1793 Oct 26 17:57 linuxtest-client2.csr
-rw-r--r-- 1 root root    3 Oct 26 17:57 serial
-rw-r--r-- 1 root root 8287 Oct 26 17:57 linuxtest-client2.crt
-rw-r--r-- 1 root root   21 Oct 26 17:57 index.txt.attr
-rw-r--r-- 1 root root 1058 Oct 26 17:57 index.txt
-rw-r--r-- 1 root root 8287 Oct 26 17:57 07.pem

Mas se eu não usar -l em ls, ele retornará os resultados adequados que estou procurando, então claramente meu regex está correto:

root@ip-10-198-0-205:/etc/easy-rsa# ls keys/ | grep -E '*2.*'
02.pem
linuxtest-client2.crt
linuxtest-client2.csr
linuxtest-client2.key

No momento, estou configurando o OpenVPN para fornecer acesso da empresa a vários clientes. Nosso requisito é usar certificados, proteger com senha as chaves do cliente, bem como usar autenticação de fator duplo (MFA) por cliente.

Eu tenho um monte de tokens Fortinet FortiToken 200 que gostaria de usar, mas não consigo encontrar nenhuma informação que mostre como usar esses tokens com algo como OpenVPN. Depois de procurar um pouco mais, não consigo encontrar nenhuma informação que mostre como alguém pode usar um token físico com o OpenVPN.

Então, minha pergunta é: como posso usar um token físico com o OpenVPN? Não posso usar algo como o Google Authenticator, pois planejamos ter clientes VPN também por meio de seus smartphones. A documentação de instruções do OpenVPN PKCS#11 está muito mal escrita.

Estou começando a acreditar que, se o MFA é um requisito, o OpenVPN simplesmente não é uma opção viável neste momento.

Obrigado pela ajuda.

Todos sabemos que o ping é a maneira mais comum de estabelecer a conectividade da camada 3. A conectividade da camada 1 é estabelecida pela luz do link. A conectividade da camada 2 é estabelecida verificando se o protocolo de link aparece como ativo (ou você vê o endereço MAC), mas e a conectividade da camada 2 não ethernet? Que tal as camadas 4, 5, 6 e 7?

Portanto, a pergunta é: quais são as formas comuns de estabelecer inequivocamente a conectividade nas camadas 2, 4, 5, 6 e 7?

Algumas ideias que me vêm à cabeça:

1) telnet para a porta 80/443 para conectividade da camada 7

2) usar netcat (como?)

Estou tentando configurar um túnel VPN usando o StrongSwan 5.1.2 entre duas instâncias do Amazon AWS EC2 executando o Ubuntu 14.04.2 LTS. Antes de usar o StrongSwan, usei o open(libre)swan em um Amazon RedHat AMI, que funcionou bem. Por alguma razão, não consigo nem fazer o IKE trabalhar aqui para o StrongSwan. Eu verifiquei três vezes minhas configurações da AWS e tudo parece bom, então deve ser um problema com a configuração do StrongSwan.

Como você verá abaixo, o erro que estou recebendo é "Erro ao escrever no soquete: argumento inválido" . Eu procurei online e realmente não consigo encontrar a solução para isso. Estou convencido de que meu strongswan ipsec.conf está configurado incorretamente.

Aqui está o que eu estou trabalhando:

Instance #1: N.Virginia - 10.198.0.164 with public EIP 54.X.X.X
Instance #2: Oregon - 10.194.0.176 with public EIP 52.Y.Y.Y

A topologia (simples) é a seguinte:

[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]

Verifiquei se as seguintes configurações da AWS estão corretas:

Security groups permit all
IP information is correct
Src/Dest disabled on both instances
ACLs permit all
routes are present and correct (route to 10.x will point to that local instance in order to be routed out to the VPN tunnel)

Abaixo está o /etc/ipsec.conf (este é do Oregon, porém é o mesmo na instância N.Virginia exceto que os valores left|right estão invertidos) :

config setup
        charondebug="dmn 2, mgr 2, ike 2, chd 2, job 2, cfg 2, knl 2, net 2, enc 2, lib 2"
conn aws1oexternal-aws1nvexternal
        left=52.Y.Y.Y (EIP)
        leftsubnet=10.194.0.0/16
        right=54.X.X.X (EIP)
        rightsubnet=10.198.0.0/16
        auto=start
        authby=secret
        type=tunnel
        mobike=no
        dpdaction=restart

Abaixo está o /etc/ipsec.secrets *(invertido para outra instância, obviamente):

54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"

Abaixo está o /etc/strongswan.conf:

charon {
        load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }
}

Abaixo está o /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

Aqui está a saída de depuração de /var/log/syslog Parece que o problema aqui é "erro ao gravar no soquete: Argumento inválido; depois de tudo que tentei, continuo recebendo o mesmo erro :

Jun 17 17:34:48 ip-10-198-0-164 charon: 13[IKE] retransmit 5 of request with message ID 0
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[NET] sending packet: from 54.X.X.X[500] to 52.Y.Y.Y[500] (1212 bytes)
Jun 17 17:34:48 ip-10-198-0-164 charon: 03[JOB] next event in 75s 581ms, waiting]
Jun 17 17:34:48 ip-10-198-0-164 charon: 16[NET] sending packet: from 54.X.X.X[500] to 52.Y.Y.Y[500]
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[MGR] checkin IKE_SA aws1vexternal-aws1oexternal[1]
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[MGR] check-in of IKE_SA successful.
Jun 17 17:34:48 ip-10-198-0-164 charon: 16[NET] error writing to socket: Invalid argument
Jun 17 17:36:04 ip-10-198-0-164 charon: 03[JOB] got event, queuing job for execution
Jun 17 17:36:04 ip-10-198-0-164 charon: 03[JOB] no events, waiting
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] checkout IKE_SA
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] IKE_SA aws1vexternal-aws1oexternal[1] successfully checked out
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] giving up after 5 retransmits
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] establishing IKE_SA failed, peer not responding
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] checkin and destroy IKE_SA aws1vexternal-aws1oexternal[1]
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] IKE_SA aws1vexternal-aws1oexternal[1] state change: CONNECTING => DESTROYING
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] check-in and destroy of IKE_SA successful

Abaixo está o que eu tentei até agora:

1) Camada verificada 3

2) máquinas reiniciadas

3) Tentei adicionar em leftid=

4) Tentei atualizar o ipsec e reiniciar o ipsec

5) Tentei adicionar nat_traversal=yes na configuração confif (observe que isso não deve importar, pois o ipsec statusall é verificado usando IKEv2, que de acordo com a documentação usa automaticamente nat_traversal)

6) Tentei omitir virtual_private <-- Foi usado de acordo com a documentação do openswan da AWS, então incluí-o na configuração do strongswan.

7) Tentei desabilitar net.ipv4.conf.all.send_redirects = 0 e net.ipv4.conf.all.accept_redirects = 0 em /etc/sysctl.conf

8) Tentei usar IP privado em vez de EIPs. Não recebo mais o erro de soquete, no entanto, obviamente, os dois IPs não podem se comunicar entre si para emparelhar ...

9) Tentei adicionar isso ao strongswan.conf: load = aes des sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown

10) Tentei usar o leftfirewall=sim, não funcionou

Por favor ajude! Obrigado!

EDIÇÃO Nº 1:

A resposta de Michael resolveu o problema original, no entanto, tenho um novo problema relacionado ao roteamento. Ambas as instâncias VPN não conseguem executar ping uma na outra. Além disso, quando tento fazer ping de uma instância aleatória em qualquer sub-rede, para outra instância aleatória ou para a instância VPN de ponta, recebo a seguinte resposta de ping:

root@ip-10-194-0-80:~# ping 10.198.0.164
PING 10.198.0.164 (10.198.0.164) 56(84) bytes of data.
From 10.194.0.176: icmp_seq=1 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=2 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=3 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=4 Redirect Host(New nexthop: 10.194.0.176)

Obviamente, isso deve ser um problema de roteamento entre as duas instâncias VPN (provavelmente devido à configuração strongswan ou à tabela de roteamento da instância), pois o host 10.194.0.80 na sub-rede Oregon pode receber uma resposta da instância VPN Oregon. Tabela de rotas + traceroute na instância:

root@ip-10-194-0-80:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.194.0.1      0.0.0.0         UG        0 0          0 eth0
10.194.0.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0

root@ip-10-194-0-80:~# traceroute 10.198.0.164
traceroute to 10.198.0.164 (10.198.0.164), 30 hops max, 60 byte packets
 1  10.194.0.176 (10.194.0.176)  0.441 ms  0.425 ms  0.409 ms^C

Quando eu estava usando o openswan, ele não exigia que eu fizesse nenhuma modificação manual na tabela de roteamento de cada instância.

Esta é a tabela de roteamento da instância do Oregon VPN:

root@ip-10-194-0-176:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.194.0.1      0.0.0.0         UG        0 0          0 eth0
10.194.0.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0

Estou um pouco perplexo.

EDIÇÃO #2:

Parece que o roteamento entre as instâncias VPN pode não ser o problema: /var/log/syslog mostra os pacotes recebidos de um IP público da instância VPN para a outra instância VPN

Jun 23 19:57:49 ip-10-194-0-176 charon: 10[NET] received packet: from 54.X.X.X[4500] to 10.194.0.176[4500] (76 bytes)

Parece que é um problema relacionado às Associações de Segurança Infantil:

aws1oexternal-aws1nvexternal:   child:  10.194.0.0/16 === 10.198.0.0/16 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 **connecting**):

/var/log/syslog:

Jun 23 19:52:19 ip-10-194-0-176 charon: 02[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 23 19:52:48 ip-10-194-0-176 charon: 11[IKE] queueing CHILD_CREATE task
Jun 23 19:52:48 ip-10-194-0-176 charon: 11[IKE]   activating CHILD_CREATE task
Jun 23 19:52:48 ip-10-194-0-176 charon: 06[IKE] establishing CHILD_SA aws1oexternal-aws1nvexternal
Jun 23 19:52:48 ip-10-194-0-176 charon: 10[IKE] received FAILED_CP_REQUIRED notify, no CHILD_SA built
Jun 23 19:52:48 ip-10-194-0-176 charon: 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[CFG] looking for a child config for 10.194.0.0/16 === 10.198.0.0/16 
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[CFG] found matching child config "aws1oexternal-aws1nvexternal" with prio 10
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[IKE] configuration payload negotiation failed, no CHILD_SA built
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[IKE] failed to establish CHILD_SA, keeping IKE_SA

***EDIT #3: Problema resolvido (uhh, na verdade veja o EDIT #4 abaixo...)****

Problema resolvido.

1) Não segui corretamente as instruções de configuração de Michael. Eu também configurei um rightsourceip e um leftsourceip juntos, fazendo com que ambas as instâncias acreditassem que ambos eram iniciadores. Assegurei-me de que um fosse o iniciador e o outro o solicitante; isso corrigiu o problema de IKE.

2) Descobri que também tinha que definir explicitamente o parâmetro esp. Mesmo que já exista um padrão (aes128-sha1,3des-sha1), o parâmetro esp ainda precisa ser definido para que a instância saiba usar esp OR ah (mas não ambos). Acabei usando aes128-sha1-modp2048.

Espero que esta postagem ajude o próximo novato no Linux a configurar isso !!

Felicidades!

EDIT #4: Problema (na verdade não) resolvido

Ao solucionar um problema separado relacionado ao strongswan, alterei o parâmetro "leftfirewall", testei, não corrigi meu problema separado e, em seguida, voltei para a configuração original de antemão (comentei leftfirewall). Percebi então que agora não conseguia fazer ping pelo túnel. Depois de enlouquecer por horas tentando descobrir o que aconteceu, comentei o parâmetro esp para ver o que aconteceria: AGORA POSSO PING ATRAVÉS DO TÚNEL DE NOVO! <- então, existe a possibilidade de que alguns fantasmas do ipsec estejam me enganando e que o parâmetro esp não seja realmente a correção para os erros TS_UNACCEPTABLE (embora outros recursos online afirmem que o parâmetro esp é a correção ...)

EDIT #5: Problema totalmente resolvido

Acabei movendo tudo para um ambiente de teste e começando do zero. Instalei da fonte usando a versão mais recente (5.3.2) em vez da versão mais antiga que estava no repositório do Ubuntu (5.1.2). Isso resolveu o problema que estava tendo acima e verificou a conectividade da camada 7 usando netcat (ótima ferramenta!!) entre várias sub-redes no túnel VPN.

Além disso: NÃO é necessário habilitar nomes de host DNS para o VPC (como fui levado a acreditar incorretamente pela Amazon), FYI>

Espero que tudo isso ajude!!!!!!

Edição adicional 11/02/2017:

Conforme solicitação da JustEngland, copiando a configuração de trabalho abaixo (omitindo alguns detalhes para evitar a identificação de qualquer forma):

Lado a:

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration
config setup
# Add connections here.
conn %default
 ikelifetime= You choose; must match other side
 keylife= You choose; must match other side
 rekeymargin= You choose; must match other side
 keyingtries=1
 keyexchange= You choose; must match other side
 authby=secret
 mobike=no

conn side-a
 left=10.198.0.124
 leftsubnet=10.198.0.0/16
 leftid=54.y.y.y
 leftsourceip=10.198.0.124
 right=52.x.x.x
 rightsubnet=10.194.0.0/16
 auto=start
 type=tunnel
# Add connections here.


root@x:~# cat /etc/ipsec.secrets 
A.A.A.A B.B.B.B : PSK "Your Password"

Lado B:

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration
config setup

conn %default
 ikelifetime= You choose; must match other side
 keylife= You choose; must match other side
 rekeymargin= You choose; must match other side
 keyingtries=1
 keyexchange= You choose; must match other side
 authby=secret
 mobike=no

conn side-b
 left=10.194.0.129
 leftsubnet=10.194.0.0/16
 leftid=52.x.x.x
 right=54.y.y.y
 rightsubnet=10.198.0.0/16
 rightsourceip=10.198.0.124
 auto=start
 type=tunnel

root@x:~# cat /etc/ipsec.secrets 
B.B.B.B A.A.A.A : PSK "Your Password"

Procurei em todo o google e stackoverflow; não consegue encontrar uma resposta para este problema "simples".

Background: Eu tenho um servidor Supermicro rodando centos 6.5 kernal 2.6.32-431.29.2.el6.x86_64. Tenho tentado configurar o IPMI e, depois de muita solução de problemas, percebo que o problema provavelmente se deve ao fato de o módulo ipmi_si (e ipmi_msghandler) não estar presente. Acredito que a única forma de obter esses módulos seja atualizando o kernel:

[blah@localhost]$ yum provides "*/ipmi_msg*.ko"
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
 * base: centos.mirror.constant.com
 * epel: ftp.osuosl.org
 * extras: linux.cc.lehigh.edu
 * updates: mirror.metrocast.net
kernel-debug-2.6.32-504.el6.x86_64 : The Linux kernel compiled with extra debugging enabled
Repo        : base
Matched from:
Filename    : /lib/modules/2.6.32-    504.el6.x86_64.debug/kernel/drivers/char/ipmi/ipmi_msghandler.ko

kernel-2.6.32-504.el6.x86_64 : The Linux kernel
Repo        : base
Matched from:
Filename    : /lib/modules/2.6.32-       504.el6.x86_64/kernel/drivers/char/ipmi/ipmi_msghandler.ko

...etc

Concordou? Prefiro obter esses módulos sem atualizar o kernel. Além disso, assumindo que devo atualizar o kernel, alguém pode confirmar que a razão para isso é simplesmente que esses módulos não são "compatíveis" com o kernel atual?

Obrigado.

Solucionando um problema de IPMI em um servidor centos 6.5. Especificamente, não consigo configurar o gerenciamento da Web do IPMI devido a erros ao tentar trabalhar com as configurações de LAN do IPMI.

Recebo o seguinte erro quando digito ipmitool lan print:

[root@]# ipmitool lan print
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
Get Channel Info command failed
Invalid Channel 255

Quase todas as respostas do google/stackexchange para esses problemas resultam na resposta encontrada aqui ipmitool - can't find /dev/ipmi0 ou /dev/ipmidev/0 , no entanto, este servidor supermicro tem os mesmos módulos de kernel ipmi exatos carregados como meu outro servidor supermicro como mostrado abaixo:

[root@SERVER_WITHOUT_WORKING_IPMI]# modprobe --showconfig | grep ipmi
alias platform:ipmi_si ipmi_devintf
[root@SERVER_WITH_WORKING_IPMI]# modprobe --showconfig | grep ipmi
alias platform:ipmi_si ipmi_devintf

Portanto, suspeito que este não seja um problema relacionado aos módulos do kernel ...

Qualquer assistência sobre isso é muito apreciada. Observe que este dispositivo está em produção, portanto, tenho que ter cuidado ao "experimentar". Observe também que sou relativamente novo no Linux (engenheiro de rede aqui).

Obrigado a todos...(esse é meu primeiro post!)