Fravadona's questions

Tenho uma estação de trabalho RHEL 8 que hospeda um aplicativo cuja interface gráfica do usuário (GUI) pode ser acessada via https.

Quando o aplicativo é iniciado, ele cria alguns arquivos de soquete /tmpcom nomes aleatórios e o .socksufixo:

$ ls -l /tmp/*.sock
srwx------ 1 app app 0 Dec 21 13:30 /tmp/supervisor-358513b0f6222d2339e4ab66d30b0037.sock
srwx------ 1 app app 0 Dec 21 13:31 /tmp/mongodb-358513b0f6222d2339e4ab66d30b0037.sock
srwx------ 1 app app 0 Dec 21 13:31 /tmp/livegui-358513b0f6222d2339e4ab66d30b0037.sock

$ file /tmp/*.sock
/tmp/supervisor-358513b0f6222d2339e4ab66d30b0037.sock: socket
/tmp/mongodb-358513b0f6222d2339e4ab66d30b0037.sock:    socket
/tmp/livegui-358513b0f6222d2339e4ab66d30b0037.sock:    socket

^{atualização: A parte "aleatória" dos nomes dos arquivos de soquete é, na verdade, um MD5 do caminho onde o aplicativo está instalado.}

Quando as pessoas usam o aplicativo com frequência, ele funciona bem por semanas/meses, mas quando ninguém se conecta ao aplicativo por alguns dias, ele para de responder; quando isso acontece, posso ver que os .sockarquivos foram excluídos enquanto os processos do aplicativo ainda estavam em execução...

Existe alguma maneira de evitar a exclusão de alguns arquivos no /tmp?

Tenho que mover alguns arquivos/diretórios de um diretório que era compartilhado por várias pessoas para outro computador. Os elementos que tenho que mover são alguns diretórios, alguns subdiretórios, alguns arquivos específicos em subdiretórios, etc... É uma pequena bagunça ^^

Estou tentando aplicar o método em https://serverfault.com/a/788007/154366, mas falha de alguma forma.

Aqui está minha configuração de teste (tentei torná-la representativa o suficiente para que eu pudesse entender a maioria dos detalhes, rsync --filter=mergepara que eu pudesse aplicá-la ao meu problema real):

#!/bin/bash
mkdir -p /tmp/test/{a/b,b/{a,b},c,.d}
touch /tmp/test/{f.txt,.f.txt,{a/b,b,b/{a,b},c,.d}/f.txt,b/.f.txt}
tree -a /tmp/test

/tmp/test
├── a
│   └── b
│       └── f.txt
├── b
│   ├── a
│   │   └── f.txt
│   ├── b
│   │   └── f.txt
│   ├── .f.txt
│   └── f.txt
├── c
│   └── f.txt
├── .d
│   └── f.txt
├── .f.txt
└── f.txt

Agora eu gostaria de usar um único rsync -avcomando para copiar os seguintes itens de /tmp/testpara /tmp/filt:

• o ./adiretório completo
• o ./b/bdiretório completo
• todos os arquivos e dotfiles filhos diretos do ./bdiretório
• todos os arquivos (não dotfiles) filhos diretos do ./diretório

Minhas "cópias" esperadas estão marcadas =>aqui:

/tmp/test/           =>  /tmp/filt/
/tmp/test/a/         =>  /tmp/filt/a/
/tmp/test/a/b/       =>  /tmp/filt/a/b/
/tmp/test/a/b/f.txt  =>  /tmp/filt/a/b/f.txt
/tmp/test/b/         =>  /tmp/filt/b/
/tmp/test/b/a/
/tmp/test/b/a/f.txt
/tmp/test/b/b/       =>  /tmp/filt/b/b/
/tmp/test/b/b/f.txt  =>  /tmp/filt/b/b/f.txt
/tmp/test/b/f.txt    =>  /tmp/filt/b/f.txt
/tmp/test/b/.f.txt   =>  /tmp/filt/b/.f.txt
/tmp/test/c/
/tmp/test/c/f.txt
/tmp/test/.d/
/tmp/test/.d/f.txt
/tmp/test/f.txt      =>  /tmp/filt/f.txt
/tmp/test/.f.txt

Então escrevi o seguinte filter.txtarquivo para usá-lo com rsync's --filter=merge:

+ /[!.]*
+ /a/
+ /a/**
+ /b/
+ /b/b/
+ /b/b/**
- /b/*/
+ /b/*
- /**

Mas quando executo o comando:

rsync -av --dry-run --filter='merge filter.txt' /tmp/test /tmp/filt/

Eu entendo:

sending incremental file list
test/

sent 74 bytes  received 20 bytes  188.00 bytes/sec
total size is 0  speedup is 0.00 (DRY RUN)

^{nota: é claro que o /tmp/filtdiretório não existe, então a falta de saída não está relacionada a ele.}

O que estou fazendo errado?

Quando me conecto a um macOS Sonoma remoto a partir de um Linux RHEL 8 ssh -J user@portal user@mace, uma vez conectado, executo o vim somefile, recebo alguns caracteres estranhos no canto superior esquerdo da "página" e também no prompt do shell após sair do Vim:

[>4;m

^{nota: não consegui capturar esses bytes corretamente, não sei como posso fazer isso}

Não é a primeira vez que enfrento esse problema com diferentes combinações de sistemas operacionais locais/remotos (Solaris/FreeBSD/AIX/Linux/macOS), mas antes eu só precisava instalar os terminfopacotes nos NIXs remotos para consertar.

No macOS Sonoma, o terminfo xterm-256colorusado pelo RHEL 8 já está em /usr/share/terminfo/78/xterm-256color, e mudar TERMpara xtermnão ajuda.

Alguma ideia do que fazer para resolver o problema?

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?

Estou procurando uma maneira de anular o comportamento indesejável de alguns instaladores que anexam código .bashrcpara forçar o carregamento de seu ambiente automaticamente. O problema surgiu algumas vezes, principalmente com o Conda, e em alguns casos o usuário acabou com uma conta quebrada que o impedia de fazer login mais.

Eu tentei adicionar um documento aqui não fechado no final do .bashrc, assim:

# .bashrc

#...

: <<'__END__'

O que funciona, mas gera avisos irritantes de erros de análise .

Qual seria uma maneira limpa de fazer isso (sem tornar o .bashrc somente leitura)?

Eu tenho um script de instalador/atualizador destinado a IRIX/Linux/macOS/FreeBSD e gostaria de estender sua compatibilidade para Solaris.

Já consertei algumas partes que não eram compatíveis com POSIX, exceto a crontabque é gerada assim:

printf '%s\n' [email protected] '*/15 * * * * /path/cmd' | crontab -

# crontab -l # (on Linux/macOS/FreeBSD)
[email protected]
*/15 * * * * /path/cmd

^{nota: /path/cmd é silencioso a menos que detecte um problema}

O código falha no Solaris por três motivos:

1. MAILTO=lança um erro de sintaxe
2. */15lança um erro de sintaxe
3. crontab -tenta abrir o arquivo chamado-

Eu consertei o nº 2 e o nº 3 com:

printf '%s\n' '0,15,30,45 * * * * /path/cmd' | crontab

# crontab -l
0,15,30,45 * * * * /path/cmd

Agora eu não sei como converter a MAILTO=parte. Qual seria uma maneira POSIX de encaminhar e-mails de um crontab?

Solução alternativa selecionada:

Graças aos ponteiros @ilkkachu e @Gilles'SO-stopbeingevil' , aqui está como decidi emular o comportamento do crontab de MAILTOuma maneira compatível com POSIX:

# crontab -l
0,15,30,45 * * * * out=$(/path/cmd 2>&1); [ -n "$out" ] && printf \%s\\n "$out" | mailx -s "Cron <$LOGNAME@$(uname -n)>" [email protected]

Mas, há um problema potencial com esta solução: se nãoprintf for um shell embutido e a saída for muito grande, ela falhará com um ou semelhantes.Argument list too long