Perguntas[redhat](server)

Tenho uma VM RHEL9 registrada e recentemente clonei uma cópia dela restaurando a partir do backup mais recente do Veeam.

Depois alterei o IP, o gateway, também /etc/hostso arquivo e regenerei /etc/machine-ido arquivo (também /var/lib/dbus/machine-id)

Então eu executei subscription-manager unregistere subscription-manager cleanem ambas as VMs. Também fiz login no console web do Redhat Hybrid Cloud Console para verificar se não há sistemas relevantes registrados.

Então eu executei subscrption-manager registerpara ambas as VMs, e esperava que houvesse duas novas entradas no Redhat Hybrid Cloud Console. No entanto, descobri que sempre há apenas uma entrada, e parece que as VMs estavam sobrescrevendo uma à outra.

Verifiquei se eles têm dois IPs, IDs de máquina e identidade de gerenciador de assinaturas diferentes, mas parece que quando tento registrar os dois, o Redhat os vê como o mesmo sistema.

Minha pergunta é: qual é a possível causa desse comportamento e como posso resolvê-lo corretamente?

2025-01-06 Atualização rápida:

Seguindo a resposta sugerida, tento atualizar o MAC Address, mas o Redhat parece ainda não conseguir dizer que são duas VMs diferentes. Abaixo está minha configuração atual da VM original e da VM restaurada.

• VM original:

Endereço IP e MAC

/etc/machine-id e /var/lib/dbus/machine-id

identidade do gerenciador de assinaturas

• VM restaurada:

Endereço IP e MAC

/etc/machine-id e /var/lib/dbus/machine-id

identidade do gerenciador de assinaturas

Tenho um servidor RHEL 7.9. Estou tentando criar uma conta local chamada sysadmin. Eu executei

• useradd sysadmin
• usermod -aG wheel sysadmin
• passwd sysadmin

Quando olho, /homevejo a pasta sysadmin, mas ela tem um proprietário diferente. O proprietário é uma conta de serviço que não está relacionada. Se eu executar chown sysadmin:sysadmin, ele não altera o proprietário, ele permanece a mesma conta de serviço. Não vejo nenhum log relacionado em secure ou messages. Não há /var/log/auth.logarquivos syslog ou syslog. Alguém viu esse comportamento?

Estou tentando entender como o systemd-journald e o rsyslog funcionam juntos. Os logs são armazenados em/var/logs? Faz

du -h /var/log/journal/

é suficiente para o que eu preciso?

Após atualizar alguns servidores de RHEL8 para RHEL9 usando o utilitário Leapp, há alguns avisos após a atualização em dnfe rpm: aviso: Assinatura não suportada. Algoritmo de hash SHA1 não disponível.

Toda vez que executei qualquer um desses comandos, recebi este aviso:

[root@web ~]# rpm -q kernel
warning: Signature not supported. Hash algorithm SHA1 not available.
warning: Signature not supported. Hash algorithm SHA1 not available.
kernel-5.14.0-362.18.1.el9_3.x86_64
kernel-5.14.0-427.18.1.el9_4.x86_64
kernel-5.14.0-427.20.1.el9_4.x86_64

[root@web ~]# dnf repolist
warning: Signature not supported. Hash algorithm SHA1 not available.
warning: Signature not supported. Hash algorithm SHA1 not available.
Updating Subscription Management repositories.
repo id                          repo name
rhel-9-for-x86_64-appstream-rpms Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs)
rhel-9-for-x86_64-baseos-rpms    Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs)

Não sei de qual pacote ou o que desencadeia esse problema. A maioria das soluções disponíveis na web envolve reativar o SHA1, o que não é efetivamente uma solução.

Além disso, todos os pacotes estão marcados com, el9exceto alguns gpg-pubkeypacotes, então acho que não há nada do RHEL9 por aí.

[root@web ~]# rpm -qa | grep -v el9
warning: Signature not supported. Hash algorithm SHA1 not available.
warning: Signature not supported. Hash algorithm SHA1 not available.
gpg-pubkey-fd431d51-4ae0493b
gpg-pubkey-a14fe591-578876fd
gpg-pubkey-d4082792-5b32db75

Como posso rastrear o problema real para me livrar desses avisos?

Temos 8 servidores Cisco com 12 discos giratórios para dados e 2 SSDs para sistema operacional. Os 2 SSDs estão no software Linux RAID 1. Todos os SSDs têm seu indicador de desgaste em um dígito e alguns daqueles que atingiram o valor 1 falharam. Estou trocando todos eles pelas peças sobressalentes (um processo longo e cansativo), mas notei que o indicador de desgaste está caindo 1 ou 2% por semana (não fiz medições exatas). Há um único aplicativo em execução nesses servidores e o fornecedor me deu algumas ideias vagas, mas eu realmente preciso encontrar os diretórios nos quais ele está gravando. Dessa forma, posso realmente destacar o problema e pressionar o fornecedor para uma solução. Pesquisei um pouco, mas não consegui encontrar muito. iotop, por exemplo, mostra a taxa de transferência completa do disco, incluindo os 12 discos giratórios. O SO é Redhat 7.9

Em resposta a algumas das perguntas:

• os discos são "SSD SATA de 480 GB e 2,5 polegadas Enterprise Value 6 Gb"
• o ID do produto é "UCS-SD480GBKS4-EB"
• os discos foram fornecidos como padrão com os servidores em 2018
• O desgaste parece ter acelerado recentemente (agora estou registrando o desgaste, então terei uma resposta melhor sobre isso em alguns dias)
• Substituí a maioria dos discos por discos idênticos adquiridos talvez alguns anos depois.
• iotop está mostrando uma gravação constante de 8 MB/s.
• o sistema está executando o hadoop em 8 servidores. O sistema de arquivos hadoop está em discos giratórios, portanto não deve tocar nos SSDs
• Reduzi consideravelmente o IO do disco por sugestão do fornecedor, embora ainda pareça alto (8 MB/s)

Estamos executando uma loja Rocky Linux 8.9 (essencialmente RHEL 8.9) e recebi a tarefa de investigar ACLs em sistemas de arquivos montados via NFS. Também estamos usando FreeIPA/IdM.

Configurei uma máquina de teste, inscrevi-a no IdM, exportei um compartilhamento NFS e montei-a localmente, mas a parte ACL parece estar faltando:

[root@example ~]# cat /etc/exports
/export/ *(rw,acl,no_root_squash)

[root@example ~]# mount | grep /export
localhost:/export on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1)

[root@example ~]# cd /mnt/
[root@example mnt]# touch testfile
[root@example mnt]# getfacl testfile
# file: testfile
# owner: root
# group: root
user::rw-
group::r--
other::r--

[root@example mnt]# setfacl -m u:user:r testfile 
setfacl: testfile: Operation not supported

Algumas perguntas:

1. Foi entendido corretamente que eu deveria usar getfacle setfaclem vez de seus equivalentes nfs4_, já que tanto o cliente quanto o servidor são Linux/POSIX?
2. Eu preciso do idmapd? Eu tenho um serviço chamado nfs-idmapd em execução com sucesso.
3. Li em algum lugar que sec=sysdeveria ser substituído seckrb5durante a montagem.

ATUALIZAR:

Investiguei um pouco mais e tive um pequeno avanço: nfsv4_set*aclfunciona bem no compartilhamento NFS, desde que se use UIDs ou GIDs numéricos. É o acoplamento à IdM/Kerberos que está causando problemas.

Eu tenho um servidor redhat 7.9 com cerca de 30 usuários, 64 núcleos e 512 Go de RAM. Eu tenho vários processos de zumbis, não sei exatamente o que o usuário criou para criá-los, mas tenho a sensação, depois de ler coisas na internet, que quando a sessão deles for encerrada, todos os zumbis serão mortos porque o processo "pai" será eliminado.

então vamos imaginar que se um usuário criar cerca de 30 zumbis durante sua sessão, eu poderia ter no máximo 900 processos de zumbis, é apenas uma aproximação porque quanto mais durar a sessão de um usuário, maior será o número do processo de zumbi. Preciso monitorar esse número para evitar falha no servidor ou algo assim?

Eu sei que processos zumbis não consomem nenhum recurso (RAM, CPU, etc.) mas também é uma evidência de que esse valor não pode ser superior a um limite...

Eu sei também que às vezes o usuário desconecta e os processos zumbis são limpos, então o número de processos zumbis pode diminuir ...

Eu tenho esse problema no RHEL 8.6 com proftpd 1.3.8a

Eu tenho uma configuração de servidor proftpd, com um usuário chamado IFTPTEST. Em sua home, este usuário possui 2 diretórios, in/ e out/. Meu objetivo é: colocar os arquivos no diretório out/ e o usuário se conectar ao servidor (com usuário/senha) para buscar o arquivo.

Quando o usuário se conecta, ele pode entrar no diretório out/, listar o conteúdo do diretório e colocar os arquivos no diretório. No entanto, quando ele tenta obter o arquivo, recebo um erro de permissão negada :

sftp> ls -al
drwxrwxr-x    3 IFTPTEST 1000         4096 Nov  9 10:02 .
drwxrwxr-x    3 IFTPTEST 1000         4096 Nov  9 10:02 ..
drwxrwxr-x    2 IFTPTEST 1000         4096 Nov  9 10:08 in
drwxrwxrwx    2 IFTPTEST 1000         4096 Nov  9 10:05 out
sftp> cd out
sftp> ls -al
drwxrwxrwx    2 IFTPTEST 1000         4096 Nov  9 10:05 .
drwxrwxr-x    3 IFTPTEST 1000         4096 Nov  9 10:02 ..
-rwxrwxrwx    1 IFTPTEST 1000           13 Nov  9 10:05 test
sftp> get test test.txt
Fetching /out/test to test.txt
remote open("/out/test"): Permission denied

Mesmo com o diretório out/ e o arquivo de teste com direitos 777, recebo o Permission negado .

No sftp.log, posso ver:

OPEN command for '/out/test' blocked by 'RETR' handler

E em /var/log/messages :

RETR /appli_var/XFRF/xfrf_files/ftpusers/IFTPTEST/out/test denied by <Limit> configuration

O que não entendo, porque tenho a configuração RETR para o diretório out/ em meu proftpd.conf (veja abaixo).

É um problema conhecido ? Tenho algum problema na minha configuração?

Conteúdo do proftpd.conf (não coloquei o arquivo inteiro):

# Proftpd server configuration

[...]

LoadModule mod_vroot.c
<Global>
   VRootEngine              on
   VRootLog                 /appli_var/XFRF/proftpd/vroot.log
   VRootOptions             allowSymlinks
   DefaultRoot ~
</Global>

[...]

# Directory limits
<Global>
   <Directory />
      <Limit ALL>
         DenyAll
      </Limit>
      <Limit CDUP CWD LIST MDTM MLSD MLST NLST PWD STAT XCUP XPWD OPENDIR READDIR REALPATH LSTAT FSTAT SETSTAT STOR SITE_CHMOD>
         AllowAll
      </Limit>
   </Directory>
   <Directory /in>
      <Limit ALL>
         DenyAll
      </Limit>
      <Limit CDUP CWD LIST MDTM MLSD MLST NLST PWD STAT XCUP XPWD RETR SIZE APPE DELE RNFR RNTO STOR STOU SITE_CHMOD SETSTAT FSETSTAT LSTAT FSTAT READ>
         AllowAll
      </Limit>
   </Directory>
   <Directory /out>
      <Limit ALL>
         DenyAll
      </Limit>
      <Limit CDUP CWD LIST MDTM MLSD MLST NLST PWD STAT XCUP XPWD RETR SIZE DELE SITE_CHMOD SETSTAT FSETSTAT LSTAT FSTAT READ>
         AllowAll
      </Limit>
   </Directory>
</Global>

[...]

LoadModule mod_sftp.c
# SFTP virtual server (user/password authentication)
# ----------------------------------------------------
<VirtualHost 10.19.xx.xxx>
    <Limit LOGIN>
      AllowAll
    </Limit>
    ServerName                  "SFTP Server"
    Port                        20022
    AccessGrantMsg              "Welcome to SFTP %u"
    SFTPEngine                  on
    SFTPHostKey                 /appli/XFRF/proftpd/etc/ssh/proftpd_dsa_key
    SFTPHostKey                 /appli/XFRF/proftpd/etc/ssh/proftpd_rsa_key
    SFTPHostKey                 /appli/XFRF/proftpd/etc/ssh/proftpd_ecdsa_key
    SFTPAuthMethods             password
    SFTPCompression             delayed
    SFTPLog                     /appli_var/XFRF/proftpd/sftp.log
    ExtendedLog                 /appli_var/XFRF/proftpd/sftp_extended.log
    TransferLog                 /appli_var/XFRF/proftpd/sftp_transfer.log
    ServerLog                   /appli_var/XFRF/proftpd/sftp_server.log
</VirtualHost>

[...]

Se necessário, posso ver mais em /var/log/messages :

dispatching PRE_CMD command 'LSTAT /out/test' to mod_tls
dispatching PRE_CMD command 'LSTAT /out/test' to mod_exec
dispatching PRE_CMD command 'LSTAT /out/test' to mod_core
dispatching PRE_CMD command 'LSTAT /out/test' to mod_core
in dir_check(): setting umask to 0022 (was 0022)
dispatching POST_CMD command 'LSTAT /out/test' to mod_exec
dispatching LOG_CMD command 'LSTAT /out/test' to mod_log
dispatching PRE_CMD command 'STAT /out/test' to mod_tls
dispatching PRE_CMD command 'STAT /out/test' to mod_exec
dispatching PRE_CMD command 'STAT /out/test' to mod_core
dispatching PRE_CMD command 'STAT /out/test' to mod_core
in dir_check(): setting umask to 0022 (was 0022)
dispatching POST_CMD command 'STAT /out/test' to mod_exec
dispatching LOG_CMD command 'STAT /out/test' to mod_log
dispatching PRE_CMD command 'RETR /out/test' to mod_tls
dispatching PRE_CMD command 'RETR /out/test' to mod_exec
dispatching PRE_CMD command 'RETR /out/test' to mod_core
dispatching PRE_CMD command 'RETR /out/test' to mod_core
dispatching PRE_CMD command 'RETR /out/test' to mod_vroot
dispatching PRE_CMD command 'RETR /out/test' to mod_vroot
dispatching PRE_CMD command 'RETR /out/test' to mod_auth
dispatching PRE_CMD command 'RETR /out/test' to mod_xfer
in dir_check_full(): path = '/appli_var/XFRF/xfrf_files/ftpusers/IFTPTEST/out/test', fullpath = '/appli_var/XFRF/xfrf_files/ftpusers/IFTPTEST/out/test'
RETR /appli_var/XFRF/xfrf_files/ftpusers/IFTPTEST/out/test denied by <Limit> configuration
dispatching POST_CMD_ERR command 'RETR /out/test' to mod_exec
dispatching POST_CMD_ERR command 'RETR /out/test' to mod_vroot
dispatching POST_CMD_ERR command 'RETR /out/test' to mod_auth
dispatching LOG_CMD_ERR command 'RETR /out/test' to mod_log
dispatching LOG_CMD_ERR command 'RETR /out/test' to mod_xfer
dispatching POST_CMD_ERR command 'OPEN /out/test' to mod_exec
dispatching LOG_CMD_ERR command 'OPEN /out/test' to mod_log

Temos 254 servidores físicos quando todas as máquinas são servidores DELL R740.

servidores fazem parte do cluster Hadoop. a maioria deles está mantendo o sistema de arquivos HDFS e os serviços de gerenciamento de nó e nó de dados, parte deles são máquinas Kafka.

O sistema operacional instalado nos servidores físicos é o RHEL 7.9

Agora queremos adicionar 52 servidores físicos adicionais ao cluster. mas podemos adicionar apenas os servidores DELL R760que devem ser instalados comRHEL 8.6

cada servidor físico inclui 256G e 64 núcleos.

O problema é que não podemos trabalhar com a versão RHEL 8.6 porque a versão Hadoop. não cabe RHEL 8.6

Portanto, precisamos ficar com a versão RHEL 7.9, mas, por outro lado, o servidor DELL R760 não pode estar alinhado com o RHEL 7.9

portanto, estamos pensando em usar máquinas VM em vez de máquinas físicas DELL R760.

está claro para nós que o desempenho da VM não é como o das máquinas físicas.

mas digamos. se aumentarmos a memória padrão de 256G para 384G e aumentarmos os COREs de 64 para 80 Core's, na(s) máquina(s) VM

Portanto, caso definamos a máquina VM como acima da especificação com mais memória e CPU

então faz sentido adicionar as máquinas VM adicionais? ao cluster Hadoop e não se preocupar com problemas de desempenho?

Temos um servidor RHEL 7.9 que atua como um servidor DHCP/TFTP (PXE) atendendo a várias sub-redes. Abaixo está uma cópia do nosso arquivo dhcpd.conf (o servidor DHCP/PXE é XY145.98):

allow bootp;
allow booting;
max-lease-time 1200;
default-lease-time 900;

subnet X.Y.145.96 netmask 255.255.255.224 {
  option routers X.Y.145.126;
  range X.Y.145.100 X.Y.145.105;
  next-server X.Y.145.98;
  filename "pxelinux.0"
}

subnet X.Y.145.144 netmask 255.255.255.248 {
  option routers X.Y.145.145;
  range X.Y.145.146 X.Y.145.150;
  next-server X.Y.145.98;
  filename "pxelinux.0"
}

O problema que estamos vendo é que o grub.cfg está pegando o IP do options routerparâmetro para a variável pxe_default_serverao invés do next-serverparâmetro. Este ( pxe_default_server) é então usado para definir o net_default_serverparâmetro variável e nosso PXE falha porque aponta para o IP do gateway em vez do IP do servidor DHCP/PXE. Se editarmos o arquivo grub.cfg para codificar o pxe_default_serverparâmetro para ser igual ao IP do servidor DHCP/PXE... podemos inicializar sem problemas e obter uma imagem. Existe um parâmetro diferente que eu deveria estar usando?