no RHEL 7 e 8 eu sempre fiz:
/etc/default/grub
GRUB_CMDLINE_LINUX=... verbosee removendo rhgb quietseguido de fazer umgrub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfgIsso não tem efeito no RHEL 9. Qual é a maneira correta de fazer isso agora no RHEL 9?
Notei grub.cfgque agora ele está localizado /boot/no RHEL e tentei essa localização na -oopção, mas ainda não funcionou.
Tenho alguns servidores baremetal executando RHEL, que anteriormente tinham alguns problemas com travamentos de java/JVM e, ocasionalmente, algumas mensagens de erro de memória em nível de kernel. Os servidores agora estão quase todos ociosos, pois as cargas de trabalho foram movidas para outro lugar, aguardando a substituição da memória.
Depois de ler a postagem de Aleksey Shipilёv Please test your memory , gostaria de executar o memtester no host para ver se ele detectaria esses problemas sem precisar reinicializar. Normalmente, usaríamos apenas o memtest86+ "normal" na reinicialização, mas pode ser interessante ter alternativas.
Quanto tempo levaria para concluir uma execução do memtester em um servidor da era de 2016 com 3 TB de memória?
Estou enfrentando um problema ao executar o comando yum. Ao executar o comando yum, estou recebendo o erro abaixo:
-bash: /usr/bin/yum: /usr/libexec/platform-python: bad interpreter: No such file or directory.
Ao executar o subscription-manager, ele apresenta o erro abaixo:
ModuleNotFoundError: No module named 'pkg_resources'
As alterações que fiz foram remover o arquivo python3.6. O python3.11 está atualmente instalado no servidor e consigo usar o python3 sem problemas.
Existe alguma configuração pela qual eu possa apontar o yum/subscription-manager para o python3.11 e resolver esse problema?
Obrigado
Tentando montar um compartilhamento do Windows de um contêiner UBI9-minimal. Descobri que cifs não está contido na imagem. Tentar instalar 'cifs-utils' via microdnf parece indicar que ele não existe. Fazer uma repoquery microdnf cifs (ou *cifs*) não produz resultados.
Como instalar o cifs-utils no UBI9-minimal para montar um compartilhamento do Windows?
Fui encarregado de configurar atualizações automáticas em algumas estações de trabalho e servidores RHEL8 de alto desempenho.
Não gosto disso, pois muitas coisas podem dar errado com atualizações não supervisionadas, mas bem, parece que provocar bugs e perdas de dados é "mais seguro" do que ter computadores não atualizados pelo menos semanalmente...
Os computadores de destino usam zfse kmod-nvidia(de zfsonlinux.org e www.elrepo.org , respectivamente); ambos os RPMs precisam de uma "versão" de kernel correspondente, então a primeira medida de segurança que eu gostaria de implementar é garantir que, quando um novo kernel estiver disponível, o e instalado zfs( kmod-nvidiaou sua atualização disponível) seja compatível com ele.
Por exemplo, agora há um novo kernel:
$ sudo dnf update --assumeno
Updating Subscription Management repositories.
Last metadata expiration check: 0:57:59 ago on Thu 28 Nov 2024 12:08:30 AM CET.
Dependencies resolved.
==========================================================================================================================================================
Package Architecture Version Repository Size
==========================================================================================================================================================
Installing:
kernel x86_64 4.18.0-553.30.1.el8_10 rhel-8-for-x86_64-baseos-rpms 10 M
Upgrading:
bpftool x86_64 4.18.0-553.30.1.el8_10 rhel-8-for-x86_64-baseos-rpms 11 M
kernel-headers x86_64 4.18.0-553.30.1.el8_10 rhel-8-for-x86_64-baseos-rpms 12 M
kernel-tools x86_64 4.18.0-553.30.1.el8_10 rhel-8-for-x86_64-baseos-rpms 11 M
kernel-tools-libs x86_64 4.18.0-553.30.1.el8_10 rhel-8-for-x86_64-baseos-rpms 10 M
pam x86_64 1.3.1-36.el8_10 rhel-8-for-x86_64-baseos-rpms 748 k
python3-perf x86_64 4.18.0-553.30.1.el8_10 rhel-8-for-x86_64-baseos-rpms 11 M
webkit2gtk3 x86_64 2.46.3-2.el8_10 rhel-8-for-x86_64-appstream-rpms 28 M
webkit2gtk3-jsc x86_64 2.46.3-2.el8_10 rhel-8-for-x86_64-appstream-rpms 4.5 M
Installing dependencies:
kernel-core x86_64 4.18.0-553.30.1.el8_10 rhel-8-for-x86_64-baseos-rpms 43 M
kernel-devel x86_64 4.18.0-553.30.1.el8_10 rhel-8-for-x86_64-baseos-rpms 24 M
kernel-modules x86_64 4.18.0-553.30.1.el8_10 rhel-8-for-x86_64-baseos-rpms 36 M
Transaction Summary
==========================================================================================================================================================
Install 4 Packages
Upgrade 8 Packages
Total download size: 202 M
As kmod-nvidiacosturas instaladas são compatíveis:
$ sudo dnf repoquery --requires kmod-nvidia | awk '$1 == "kernel"'
kernel >= 4.18.0-553.el8_10
Mas não sei o que dizer sobre zfs, pois não há menção de nenhum kernelrequisito em seu RPM:
$ sudo dnf repoquery --requires zfs
Updating Subscription Management repositories.
/bin/sh
/usr/bin/python3.6
libblkid.so.1()(64bit)
libblkid.so.1(BLKID_1.0)(64bit)
libc.so.6(GLIBC_2.28)(64bit)
libcrypto.so.1.1()(64bit)
libdl.so.2()(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libnvpair.so.3()(64bit)
libnvpair3(x86-64) = 2.1.15-1.el8
libnvpair3(x86-64) = 2.1.15-2.el8
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.12)(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
librt.so.1()(64bit)
librt.so.1(GLIBC_2.3.3)(64bit)
libtirpc.so.3()(64bit)
libudev.so.1()(64bit)
libudev.so.1(LIBUDEV_183)(64bit)
libuuid.so.1()(64bit)
libuuid.so.1(UUID_1.0)(64bit)
libuutil.so.3()(64bit)
libuutil3(x86-64) = 2.1.15-1.el8
libuutil3(x86-64) = 2.1.15-2.el8
libz.so.1()(64bit)
libzfs.so.4()(64bit)
libzfs5(x86-64) = 2.1.15-1.el8
libzfs5(x86-64) = 2.1.15-2.el8
libzfs_core.so.3()(64bit)
libzpool.so.5()(64bit)
libzpool5(x86-64) = 2.1.15-1.el8
libzpool5(x86-64) = 2.1.15-2.el8
openssl
rtld(GNU_HASH)
sysstat
systemd
util-linux
zfs-kmod = 2.1.15
Como posso verificar se a atualização instalada (ou disponível) zfsé compatível com o novo kernel?
Quero instalar uma versão recente do graphviz (por exemplo, Graphviz versão 12) em um sistema RHEL 7.
Quando olho para RPMfind, só consigo ver rpms para Fedora. Onde encontro um RPM para RHEL 7?
Uma vez por mês, descubro que um dos meus servidores RedHat 9 foi reiniciado (na verdade, é o AlmaLinux 9, mas como é um clone do RH9, essa questão provavelmente é melhor resolvida no contexto do RH9). Estou tentando descobrir o que está causando o travamento, mas não há arquivos de despejo de núcleo criados!
Eu segui as instruções neste post , exceto que parece que não tenho nada compatível no meu sistema, mas quando eu aciono um core dump com:
durma 3 e mate -SEGV $!
não há nenhum arquivo de despejo de núcleo!
Confirmei que os princípios básicos estão definidos com:
[root@myhost ~]# cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
[root@myhost ~]# ulimit -c
unlimited
Há algo mais que eu deva definir para deixar o arquivo de despejo ser criado? Suspeito que meu próprio aplicativo (não empacotado) esteja causando o problema... mas não há nenhum arquivo core nem mesmo no diretório que contém o aplicativo.
====ATUALIZAÇÃO====
Modifiquei /etc/coredump.conf e configurei storage=external (todo o resto comentado), depois reiniciei e executei o seguinte:
[root@myhost ~]# sleep 3 & kill -SEGV $!
[1] 3583
[root@myhost ~]#
[1]+ Segmentation fault (core dumped) sleep 3
[root@myhost ~]# coredumpctl --all
TIME PID UID GID SIG COREFILE EXE SIZE
Sat 2024-10-26 12:56:46 EDT 3583 0 0 SIGSEGV none /usr/bin/bash -
[root@myhost ~]# ll /var/lib/systemd/coredump/
total 0
Então ainda não há arquivos de dump de núcleo visíveis (e observe o "nenhum" acima). O log do sistema mostra:
Oct 26 13:06:41 ngcvls1 systemd[1]: Started Process Core Dump (PID 4459/UID 0).
Oct 26 13:06:41 ngcvls1 systemd-coredump[4460]: Resource limits disable core dumping for process 4458 (bash).
Oct 26 13:06:41 ngcvls1 systemd-coredump[4460]: Process 4458 (bash) of user 0 dumped core.
Então, na linha de comando eu executei:
ulimit -c unlimited
e repeti o teste de segfault, então um arquivo core foi criado! Mas na reinicialização ele desapareceu. (Apesar de eu ter storage=external definido em coredump.conf). Preciso de core dumps para sobreviver a reinicializações, caso contrário não consigo dizer por que meu sistema travou. Chegando perto! Gostaria de tornar ulimit -c permanente, mas não tenho certeza de onde colocar isso (não gosto do conselho de outras postagens para colocar em .bashrc)
Usei o comando abaixo para verificar regras de política relacionadas e encontrei apenas as 2 regras relacionadas a seguir:
[root@system1 home]# sesearch -A -s httpd_t -t httpd_sys_content_t -ds -dt
allow httpd_t httpd_sys_content_t:dir { ioctl lock read };
allow httpd_t httpd_sys_content_t:lnk_file { getattr read };
Os processos no httpd_tdomínio só podem ler dire lnk_filecom httpd_sys_content_ttag... Isso significa que o SELinux dirrealmente contém todos os arquivos dentro dele?
Tentei procurar a definição de "dir" no SELinux na internet, mas não consegui encontrar nada.
SO: RHEL 9
Política SELinux: Direcionada
Comecei a testar o firewall em um sistema Red Hat 8. Minha única pergunta aqui é como depurar os dados enigmáticos que não significam quase nada. Como faço para rastrear uma rejeição de volta à fonte do problema de por que uma solicitação foi rejeitada??
Criei o seguinte para gravá-los em um local de log diferente para rastreamento. Criei um novo arquivo chamado /etc/rsyslog.d/firewall-drop.conf e adicionei o seguinte ao arquivo
:msg,contains,"_DROP" /var/log/firewalld-drop.log
:msg,contains,"_REJECT" /var/log/firewalld-drop.log
& stop
Reinicie o serviço para que ele tenha efeito. Recebo informações neste arquivo de log como:
Sep 13 10:03:07 localhost kernel: FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:11:11:b0:3a:6e:08:00 SRC=10.2.3.87 DST=10.2.255.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=60776 PROTO=UDP SPT=138 DPT=138 LEN=209
Sep 13 10:03:22 localhost kernel: FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:70:b5:e8:4b:04:dc:08:00 SRC=10.2.3.203 DST=10.2.255.255 LEN=72 TOS=0x00 PREC=0x00 TTL=128 ID=63130 PROTO=UDP SPT=57621 DPT=57621 LEN=52
Sep 13 10:03:25 localhost kernel: FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:e0:2b:e9:1c:d4:be:08:00 SRC=10.2.3.68 DST=10.2.255.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=48193 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 13 10:03:26 localhost kernel: FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:e0:2b:e9:1c:d4:be:08:00 SRC=10.2.3.68 DST=10.2.255.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=48194 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 13 10:03:26 localhost kernel: FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:e0:2b:e9:1c:d4:be:08:00 SRC=10.2.3.68 DST=10.2.255.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=48195 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 13 10:03:38 localhost kernel: FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:e0:2b:e9:1c:d4:be:08:00 SRC=10.2.3.68 DST=10.2.255.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=48196 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 13 10:03:38 localhost kernel: FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:e0:2b:e9:1c:d4:be:08:00 SRC=10.2.3.68 DST=10.2.255.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=48197 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 13 10:03:39 localhost kernel: FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:e0:2b:e9:1c:d4:be:08:00 SRC=10.2.3.68 DST=10.2.255.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=48198 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 13 10:03:48 localhost kernel: FINAL_REJECT: IN=eth0 OUT= MAC=01:00:5e:00:00:01:e0:55:3d:11:04:f0:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=55985 PROTO=2
Sep 13 10:03:52 localhost kernel: FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:70:b5:e8:4b:04:dc:08:00 SRC=10.2.3.203 DST=10.2.255.255 LEN=72 TOS=0x00 PREC=0x00 TTL=128 ID=63131 PROTO=UDP SPT=57621 DPT=57621 LEN=52
A realidade aqui é que esses dados não significam nada para mim e certamente não são intuitivos. Como podemos descobrir qual é a causa raiz de uma rejeição de firewall?? Depois de algumas pesquisas, não encontrei nada que indicasse como ler essa baboseira corretamente. Esta é a primeira vez que brinco com o firewall, então posso estar perdendo algo realmente básico aqui???
Tentando descobrir como encontrar onde existem repositórios para instalações do yum.
Sou completamente novo nessa instalação do yum, então, se o yum install anything não funcionar, não sei nem onde procurar para ver de onde está vindo.
Quais repositórios existem por aí que eu possa pesquisar coisas. No meu caso, estou trabalhando em um ambiente sandbox com RHEL 8.x. Quando tento executar o yum install wine -y, ele falha porque faltam dependências.
Não tenho ideia de como encontrar repositórios ou pesquisá-los.
Qualquer orientação para um novato seria apreciada. Obrigado.