Qual seria uma boa maneira de saber quando um computador Linux foi instalado?
Qualquer solução que eu possa pensar seria baseada em stat -c %y, por exemplo.
stat --format %y /etc/os-release /etc/skel
2022-04-06 12:00:18.402055811 +0200
2022-04-06 12:00:19.895055839 +0200
Mas usar o horário de modificação tem deficiências óbvias, e a data de nascimento pode não ser suportada.
O realpathutilitário de comando agora é definido pelo POSIX em sua edição 8 (2024): realpath — resolver um nome de caminho
realpath [-E|-e] arquivo
O utilitário realpath deve canonizar o nome do caminho especificado pelo operando do arquivo da seguinte forma:
Se uma chamada para a
realpath()função com o caminho especificado como seu primeiro argumento for bem-sucedida, o caminho canonizado deverá ser o caminho que seria retornado por essarealpath()chamada. Caso contrário:
Se a opção -e for especificada, a canonização falhará.
Se a opção -E for especificada, então se uma chamada para a
realpath()função com o caminho especificado como seu primeiro argumento encontrar uma condição de erro diferente de [ENOENT], a canonização falhará; se a chamada encontrar um erro [ENOENT], o realpath expandirá todos os links simbólicos que seriam encontrados em uma tentativa de resolver o caminho especificado usando o algoritmo especificado em XBD 4.16 Pathname Resolution, exceto que quaisquer<slash>caracteres finais que não sejam também<slash>caracteres iniciais serão ignorados. Se essa expansão for bem-sucedida e o prefixo do caminho do caminho expandido for resolvido para um diretório existente, o caminho canonizado será o caminho expandido. Em todos os outros casos, a canonização falhará. Se o caminho expandido não estiver vazio, não começar com um<slash>e tiver exatamente um componente de caminho, ele será tratado como se tivesse um prefixo de caminho de "./".Se nenhuma opção for especificada, o realpath canonizará o caminho especificado de uma maneira não especificada, de modo que o caminho absoluto resultante não contenha nenhum componente que faça referência a arquivos do tipo link simbólico e não contenha nenhum componente que seja ponto ou ponto-ponto.
Após a canonização bem-sucedida, o realpath gravará o nome do caminho canonizado, seguido por um
<newline>caractere, na saída padrão.Se a canonização falhar ou o caminho canonizado estiver vazio, nada será gravado na saída padrão, uma mensagem de diagnóstico será gravada no erro padrão e o realpath sairá com status diferente de zero.
[...]
Minha pergunta é: a -eopção de realpathjá é suportada pelo menos por GNU e Solaris, mas não consigo encontrar nenhuma menção à -Eopção em nenhuma realpathque eu pudesse verificar (macOS, FreeBSD, Solaris, GNU). O OpenGroup a inventou?
Após reinstalar uma máquina Linux, executei inadvertidamente wipefs -ano pendrive instalador:
$ wipefs -a /dev/sd?
/dev/sda: 8 bytes were erased at offset 0x00010040 (btrfs): 5f 42 48 52 66 53 5f 4d
/dev/sdb: 8 bytes were erased at offset 0x00010040 (btrfs): 5f 42 48 52 66 53 5f 4d
...
/dev/sdw: 8 bytes were erased at offset 0x00010040 (btrfs): 5f 42 48 52 66 53 5f 4d
/dev/sdx: 8 bytes were erased at offset 0x00010040 (btrfs): 5f 42 48 52 66 53 5f 4d
/dev/sdy: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31
/dev/sdy: 2 bytes were erased at offset 0x000001fe (dos): 55 aa
/dev/sdy: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sdy: calling ioctl to re-read partition table: Success
Como wipefsa saída contém o deslocamento e o conteúdo dos bytes deletados, parece possível restaurar /dev/sdy. Como você faria isso?
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:
./adiretório completo./b/bdiretório completo./bdiretório./diretórioMinhas "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' MAILTO=me@xyz.org '*/15 * * * * /path/cmd' | crontab -
# crontab -l # (on Linux/macOS/FreeBSD)
MAILTO=me@xyz.org
*/15 * * * * /path/cmd
nota: /path/cmd é silencioso a menos que detecte um problema
O código falha no Solaris por três motivos:
MAILTO=lança um erro de sintaxe*/15lança um erro de sintaxecrontab -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?
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)>" me@xyz.org
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