Não tenho iotop, atop ou qualquer ferramenta que não seja Redhat no Redhat 7.9.
Existe uma maneira de investigar qual processo está consumindo todo o acesso ao disco rígido?
Não tenho o gnome instalado, então não tenho acesso à ferramenta monitor disponível com o gnome. Estou usando apenas o ssh e a ferramenta de linha de comando.
Usando o SAR, detectei que o SDA do disco rígido está 99% ocupado, mas não sei o porquê.
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.
Endereço IP e MAC
/etc/machine-id e /var/lib/dbus/machine-id
identidade do gerenciador de assinaturas
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 sysadminusermod -aG wheel sysadminpasswd sysadminQuando 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:
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:
getfacle setfaclem vez de seus equivalentes nfs4_, já que tanto o cliente quanto o servidor são Linux/POSIX?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?
