Binarus's questions

Não tenho certeza se esta pergunta está mais relacionada ao Linux ou ao Windows. Mas vamos lá:

Usando qemu-system-x86_64 7.2.15o Debian bookworm com kernel 6.1.0 / amd64em um servidor com dois Xeon E5-2690v3, criei minha primeira VM executando o Windows 11. A mídia de instalação continha o Windows 11 Pro 21H2.

Esta instalação falhou inicialmente devido à ausência de um módulo TPM 2.0 no hardware da VM. Graças a este site e a outros, o problema não foi muito difícil de resolver (instale o swtpme seus amigos e expanda um pouco a linha de comando do Qemu). Após seguir esses passos, o Windows 11 foi instalado sem problemas. Como mencionado acima, esta era a versão 21H2.

Durante a instalação, o Qemu tinha -cpu host... Ou seja, o Windows 11 foi instalado usando a CPU Xeon E5-2690v3.

Em seguida, a VM começou a instalar suas atualizações. Ao tentar executar a atualização de recursos do Windows 11 para a versão 23H2, ela me informou que a falha ocorreu devido à incompatibilidade da CPU com o Windows 11. Sim, é verdade: primeiro, a instalação ocorreu naquela CPU sem nenhuma reclamação, depois as atualizações falharam devido à incompatibilidade da CPU.

Como eu precisava de uma versão atualizada daquela VM, fiz vários testes com diferentes tipos de CPU no Qemu. Todos falharam, exceto um: se eu configurasse -cpu qemu64, as atualizações eram realizadas.

Embora eu esteja feliz com isso (claro), estou realmente me perguntando por que funcionou. Estudei a lista de CPUs Intel compatíveis com o Windows 11 várias vezes, mas não vi nenhuma entrada como qemu64essa. O mesmo acontece com a lista de CPUs AMD .

Daí a pergunta: Por que o Windows 11 funciona -cpu qemu64mesmo que essa CPU não esteja na lista de CPUs suportadas?

Tenho milhares de imagens cujas principais características são as da imagem anexa: todas as imagens estão em uma moldura (quase) preta, enquanto o conteúdo real da imagem quase sempre está em um fundo branco.

Agora eu gostaria de girar o conteúdo real da imagem para que a borda esquerda desse conteúdo fique vertical. Então eu gostaria de cortar (aparar) a imagem para que a borda preta seja jogada fora, mas mantendo o conteúdo real completamente. Ou seja, mesmo que a área que contém o conteúdo real não seja perfeitamente retangular, tudo dessa área deve ser mantido, o que significa que pequenos restos do quadro preto ainda podem ser visíveis depois.

Dado o número de imagens que eu gostaria de tratar dessa forma, acho que terei que fazer isso usando ferramentas de linha de comando. No passado, usei o ImageMagick para esse tipo de trabalho (para transformações que são muito mais fáceis), mas eu realmente não me importaria em combinar várias ferramentas diferentes para realizar a tarefa.

O que eu já tentei:

Eu pesquisei como desnivelar imagens, e isso funciona na maioria das vezes. No entanto, os métodos de desnivelamento que eu encontrei funcionam deixando as linhas de texto horizontais. Isso é legal porque facilita a leitura, mas é claro que na maioria dos casos as bordas da área que segura o texto não ficam verticais ou horizontais depois, respectivamente. Não é isso que eu estou procurando.

Para explicar com mais detalhes, gostaria de:

1. Detecte a borda esquerda entre o quadro preto e a área que contém o conteúdo real da imagem.
2. Ajuste uma linha reta (invisível) ao longo dessa borda.
3. Determine o ângulo entre essa linha e uma linha vertical.
4. Gire a imagem inteira pelo (negativo) ângulo para que a borda da etapa 1 fique vertical.
5. Corte a imagem, descartando o máximo possível do quadro preto, mas mantendo assim a área completa que contém o conteúdo real (e, portanto, aceitando que o restante do quadro preto seja mantido se essa área não for perfeitamente retangular).

Alguém poderia explicar como fazer isso, de preferência usando ferramentas de linha de comando?

No Debian bullseye, estou iniciando máquinas virtuais usando QEMU / KVM por linha de comando (ou seja, sem virshou outros auxiliares / wrappers). Uma dessas VMs começa a partir de um dispositivo de bloco declarado da seguinte forma:

-blockdev driver=file,node-name=q1,filename=/dev/loop0 \

Ainda hoje, notei acidentalmente que o QEMU deu o seguinte aviso ao iniciar essa VM:

Opening a block device as a file using the 'file' driver is deprecated

Um pouco de pesquisa mostrou que esse aviso é conhecido e que existem soluções para ele, por exemplo, a resposta aceita de @Stephen Kitt aqui , que propõe a seguinte blockdevdeclaração:

-blockdev node-name=q1,driver=raw,file.driver=host_device,file.filename=/dev/loop0 \

Esta solução sem dúvida funciona, mas não consegui encontrar nenhuma documentação para file.driver=host_device. Portanto, testei algumas outras opções e cheguei à seguinte solução que também parece funcionar:

-blockdev driver=host_device,node-name=q1,filename=/dev/loop0 \

Alguém poderia explicar brevemente qual é a diferença entre essas duas declarações? Notavelmente, espera-se que um deles supere o outro em termos de latência ou taxa de transferência?

Como uma pergunta bônus, alguém sabe onde host_deviceestá a documentação? Na outra pergunta/resposta vinculada acima, há um link para o commit que provavelmente implementou esse driver. No entanto, também não consegui encontrar nenhuma documentação por trás desse link.

Estou lutando para entender o redirecionamento de IO no bash. Eu vi muitos exemplos como o seguinte (que é literalmente retirado da resposta aceita aqui ):

exec 3<> /tmp/foo  #open fd 3.
echo "test" >&3
exec 3>&- #close fd 3.

Não entendi a segunda linha. Para ser preciso, não entendo como seu comportamento está de acordo com o manual do bash.

Obviamente, na segunda linha, >&3deve redirecionar stdout(e possivelmente stderr- não sei) para o descritor de arquivo 3; todo o resto não faria sentido.

Mas do manual atual do bash (no momento em que escrevo), seção 3.6.4 (formatando o meu):

Essa construção permite que tanto a saída padrão (descritor de arquivo 1) quanto a saída de erro padrão (descritor de arquivo 2) sejam redirecionadas para o arquivo cujo nome é a expansão de word. Existem dois formatos para redirecionar a saída padrão e o erro padrão:
&>worde>&word

[ Em seguida, explica diferenças sutis entre o primeiro e o segundo formato, mas vamos deixar isso de lado por um momento porque não é importante para a pergunta. ]

No meu entendimento, isso diz que >&3redireciona stderre stdoutpara um arquivo cujo nome é 3, que é bem diferente de redirecionar stdout(e possivelmente stderr) para descritor de arquivo 3.

Alguém poderia explicar o que estou perdendo?

Em primeiro lugar, gostaria de observar que estou ciente de que há muitas outras questões relacionadas ao encaminhamento do agente SSH. As pessoas queriam saber como fazer o encaminhamento de agente funcionar ou como configurá-lo com segurança. Mas tenho o problema oposto: parece que não posso desativá -lo com segurança. Aqui vamos nos:

Estou executando um sistema Debian bullseye, atualizado no momento em que escrevo, basicamente vanilla. Nesse sistema, um daemon SSH está em execução, com a seguinte configuração em /etc/ssh/sshd_config:

AcceptEnv LANG LC_*
AllowAgentForwarding no
AllowTcpForwarding no
AllowStreamLocalForwarding no
ChallengeResponseAuthentication no
Ciphers [email protected],[email protected]
Compression no
DebianBanner no
HostKeyAlgorithms rsa-sha2-512,ssh-ed25519
KbdInteractiveAuthentication no
KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group-exchange-sha256
ListenAddress aaa.bbb.ccc.ddd
LoginGraceTime 20
MACs [email protected],[email protected]
PasswordAuthentication no
PermitUserRC no
Protocol 2
# The first of the following version is the right one.
# However, for brain-dead WinSCP, we need the second version.
#PubkeyAcceptedKeyTypes rsa-sha2-512,rsa-sha2-256,ssh-ed25519
PubkeyAcceptedKeyTypes rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ssh-rsa
RekeyLimit 100M 20m
Subsystem sftp /usr/lib/openssh/sftp-server

Match user copyremote
  ChrootDirectory /backup
  ForceCommand /usr/lib/openssh/sftp-server

Este é o arquivo de configuração completo ; nada foi removido ou ofuscado, exceto o endereço IP em que ele escuta. Além disso, não há outros locais que contenham trechos de configuração adicionais para o daemon SSH.

Basicamente, essa configuração tenta desativar todos os recursos que não preciso, por exemplo, o recurso de encaminhamento de agente (nota: Nesse arquivo de configuração, não adicionei as linhas para a maioria dos recursos que estão desativados por padrão (de acordo com o manual)). Vemos também que a autenticação é baseada exclusivamente em chaves públicas.

Outro dia estava investigando um problema com o usuário copyremotee o subsistema sftp e por isso deu -vcomo parâmetro to sftpem uma máquina cliente. Isso leva à seguinte saída (mostrando apenas as partes relevantes):

root@morn ~/scripts # sftp -v -i ~/.ssh/id_rsa_backup_user [email protected]:/backup/achilles.bsdtar.gz .
OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n  15 Mar 2022
[...]
debug1: Remote: /home/usr/copyremote/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/usr/copyremote/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
[...]

Agora isso é assustador. Achei que tinha desativado o encaminhamento de agente globalmente no arquivo de configuração de todo o sistema no servidor. No entanto, pelo que entendi, essa saída oferece.

Alguém poderia explicar como posso desativar o encaminhamento de agente (e outros recursos que não desejo que o servidor ofereça) globalmente ?

Esses recursos podem ser desabilitados explicitamente nos authorized_keysarquivos, mas isso seria muito propenso a erros e muito trabalhoso se houvesse vários usuários e cada um deles aceitasse várias chaves públicas, então eu realmente prefiro poder desativá-lo em um lugar.

Este é o authorized_keysarquivo do usuário copyremoteno servidor:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDs6ku+LXaUBs....JFchhaoQ== me@client

Não há nada de especial lá. Notavelmente, o encaminhamento do agente não é permitido explicitamente. Por que ele não aplica a configuração da configuração de todo o sistema?

PS Estou ciente de que SSH / SFTP chroot não fornece a segurança que esperaríamos dele. Eu implementei outras medidas no servidor que mitigam esse problema, então não precisa ser discutido aqui :-)

Acabei de atualizar dois servidores do Debian 10 (Buster) para o Debian 11 (Bullseye). Depois, não consegui mais alcançar nenhum deles pela rede. Depois de alguma investigação, o seguinte problema acabou:

Ambas as máquinas têm um dispositivo de ponte configurado. Obviamente, o algoritmo que o Debian usa para atribuir endereços MAC aos dispositivos de ponte mudou da versão 10 para 11. Após a atualização, o dispositivo de ponte no primeiro servidor tinha o mesmo endereço MAC que o dispositivo de ponte no segundo servidor , o que com certeza não foi o caso antes.

Uma das respostas afirma que uma ponte é um dispositivo puramente interno e que, portanto, o endereço MAC de uma ponte não importa. No entanto, isso é obviamente errado. Pelo menos no meu caso, os pacotes de ambas as máquinas estavam saindo com o endereço de origem do hardware sendo o endereço MAC da ponte, e as portas de rede em ambas as máquinas estavam processando os pacotes de entrada apenas se fossem destinados ao endereço MAC da ponte.

Como esse endereço MAC era o mesmo em ambas as máquinas, a rede ficou inutilizável, o que é completamente lógico e compreensível.

Como posso fazer o Debian gerar endereços MAC diferentes para dispositivos de ponte que estão em máquinas diferentes (ou mesmo na mesma máquina, mas esse não é o meu problema)?

Atualização 2022-09-15:

Acontece que o que eu estava tentando alcançar não faz muito sentido. Portanto, na verdade, essa pergunta deve ser excluída. No entanto, existem alguns comentários muito esclarecedores; portanto, vou deixá-lo como está no momento e deixar a decisão sobre seu destino para a comunidade.

Pergunta original:

Atualmente estou tentando aprender nftablese tenho feito alguns progressos. Agora eu tenho o seguinte problema (por favor, tenha paciência comigo se a pergunta for burra, mas todas as referências apontam para wiki.netfilter.org, que atualmente está inativa (minha sorte de sempre :-)):

Eu tenho uma rede IPv4 com alguns PCs clientes e um PC roteador/firewall que está sendo executado nftables. O roteador tem dois endereços IP 192.168.20.253e 192.168.20.254. O primeiro é apenas para gerenciamento do roteador (por exemplo, um daemon SSH está escutando no roteador nesse endereço), enquanto o último é o endereço de gateway que os clientes devem usar.

No conjunto de regras do roteador nftables, gostaria de ser capaz de distinguir entre os pacotes que entraram .253(para esses pacotes, permitiria apenas SSH quando o daddr(endereço de destino) realmente for .253) e os pacotes que entraram .254(para esses pacotes, eu permitiria apenas se o daddrestiver fora da rede local).

Eu sei como conseguir isso se .253e .254forem atribuídos a duas interfaces diferentes. Mas este não é o caso; ambos os endereços IP do roteador são atribuídos à mesma interface.

Alguém poderia me dar uma dica? Não encontrei dicas em man nft. Ele menciona expressões de roteamento como ipou nexthop, mas isso obviamente não ajuda. Preciso criar duas interfaces (na mesma NIC) e atribuir .253a uma delas e .254a outra?

Espero que esta não seja uma pergunta duplicada. Eu vi várias perguntas semelhantes, onde a resposta era colocar na lista negra o respectivo dispositivo ou partição. Mas no meu caso, não posso fazer isso (veja abaixo). Tendo dito isto:

Em um host debian buster x64, criei uma VM (baseada em QEMU). A VM é executada em uma partição de dispositivo de bloco, digamos /dev/sdc1. Eu instalei o sistema debian nessa partição basicamente assim (algumas etapas omitidas):

#> mkfs.ext4 -j /dev/sdc1
#> mount /dev/sdc1 /mnt/target
#> debootstrap ... bullseye /mnt/target

Em seguida, montei os diretórios necessários ( /dev, /sysetc.), fiz o chroot em /mnt/target, concluí a instalação do sistema operacional convidado e inicializei a VM.

A VM foi iniciada sem problemas. Mas a cada reinicialização da VM, a VM tinha mais problemas, que eu estava reparando nos prompts GRUBe initramfs, até que o reparo não fosse mais possível porque obviamente o ext4sistema de arquivos havia sido danificado.

Como originalmente pensei que tinha feito algo errado, por exemplo, esqueci de desmontar a ext4partição antes de iniciar a VM, repeti toda a instalação do zero várias vezes. O resultado foi o mesmo em todos os casos: após algumas reinicializações, o ext4sistema de arquivos estava tão danificado que não consegui repará-lo.

Acidentalmente, encontrei a razão para isso, mas não tenho ideia de como resolver o problema. Percebi que e2fsckse recusou a operar nessa partição, alegando que ela estava em uso embora não estivesse montada e a VM não estivesse em execução. Investigações posteriores mostraram que existia um thread de kernel jbd2/sdc.

Isso significa que o kernel do host acessa o diário nessa partição/sistema de arquivos. Quando eu inicio a VM, o kernel convidado obviamente faz o mesmo. Tenho quase certeza de que a corrupção do sistema de arquivos se deve ao fato de ambos os kernels acessarem o sistema de arquivos, principalmente o diário, ao mesmo tempo.

Como posso resolver o problema?

Não consigo colocar na lista negra o respectivo disco ou a respectiva partição no host, porque preciso montá-los lá para preparar ou concluir a instalação do sistema operacional convidado em um chroot. Por outro lado, não parece possível dizer ao kernel do host para liberar o diário assim que a VM for iniciada.

Instalei muitas VMs nos últimos anos exatamente da mesma maneira, mas não ativei o diário ao criar seu ext4sistema de arquivos. Consequentemente, não tive esse problema com essas VMs.

Editar 1

Caso seja relevante, ao montar a partição e fazer chroot nela para concluir a instalação do sistema operacional convidado, uso os seguintes comandos:

cd /mnt
mkdir target

mount /dev/sdc1 target

mount --rbind /dev target/dev
mount --make-rslave target/dev
mount --rbind /proc target/proc
mount --make-rslave target/proc
mount --rbind /sys target/sys
mount --make-rslave target/sys

LANG=C.UTF-8 chroot target /bin/bash --login

Ao desmontar, eu apenas faço

umount -R target

O umountcomando não relata nenhum erro.

Atualmente, estou tentando entender a expansão de parâmetros, especialmente as diferentes formas que podem remover partes do valor de um parâmetro por correspondência de padrões. Por causa desta pergunta, vamos nos concentrar na ${parameter#word}expansão.

As duas seções relevantes do manual ( man bash) (ênfase minha):

${parameter#word}
${parameter##word}
Remova o padrão de prefixo correspondente. A palavra é expandida para produzir um padrão exatamente como na expansão do nome do caminho e comparada com o valor expandido do parâmetro usando as regras descritas em Correspondência de padrões abaixo. Se o padrão corresponder ao início do valor do parâmetro, o resultado da expansão será o valor expandido do parâmetro com o padrão de correspondência mais curto (o '#'caso) ou o padrão de correspondência mais longo (o '##'caso) excluído. [...]

Expansão
do nome do caminho Após a divisão de palavras, a menos que a opção -f tenha sido definida, o bash verifica cada palavra em busca dos caracteres *, ? e [. Se um desses caracteres aparecer, a palavra será considerada um padrão e substituída por uma lista ordenada alfabeticamente de nomes de arquivos correspondentes ao padrão (consulte Correspondência de padrões abaixo). [...]

No entanto, considere a seguinte parte de uma sessão de terminal:

root@cerberus ~/scripts # mkdir test
root@cerberus ~/scripts # cd test
root@cerberus ~/scripts/test # touch foo
root@cerberus ~/scripts/test # String=foobar
root@cerberus ~/scripts/test # printf '%s\n' ${String#foo}
bar
root@cerberus ~/scripts/test # printf '%s\n' ${String#*}
foobar
root@cerberus ~/scripts/test #

Não consigo entender a saída após o último comando. De acordo com o manual, o *deve ser expandido para foo, pois fooé o único arquivo no diretório atual; pelo menos, esta é a minha noção de "produzir um padrão como na expansão do nome do caminho".

Portanto, neste caso, printf '%s\n' ${String#*}deve dar a mesma saída que printf '%s\n' ${String#foo}.

Obviamente, este não é o caso. Onde está meu mal-entendido?

Eu gostaria de compactar um monte de pastas que estão em um determinado diretório, criando um arquivo zip por pasta. Para isso, utilizo o seguinte comando:

$ find -maxdepth 1 -mindepth 1 -type d | xargs -I@ zip -r @.zip @

Isso funciona como esperado.

No entanto, por acidente, notei um comportamento que não esperava quando usei #como a string de substituição em vez de @:

$ find -maxdepth 1 -mindepth 1 -type d | xargs -I# zip -r #.zip #

zip error: Invalid command arguments (cannot write zip file to terminal)

zip error: Invalid command arguments (cannot write zip file to terminal)

... and so on (the same message repeated for every folder)

#normalmente abre um comentário, então fica claro que as coisas dão errado aqui. Mas eu esperava que a linha de comando realmente se tornasse find -maxdepth 1 -mindepth 1 -type d | xargs -I, porque tudo (incluindo) o primeiro #é um comentário e é removido.

No entanto, ele obviamente executa o zipcomando. Por quê?

Considere um sistema Linux com instalação e configuração padrão de sudo; ou seja, rootpode executar todos os comandos, pegando a identidade de outros usuários, e por favor considere o seguinte comando:

sudo -u user1 -g group1 some_program

Claro, eu esperaria que fosse some_programexecutado com EUID user1 e com EGID group1. No entanto, aprendi da maneira mais difícil que isso só funciona se user1for realmente um membro de group1; Eu realmente deveria ter estudado man sudomais a fundo. Da explicação da -gopção de linha de comando:

[...] A política sudoers permite que qualquer um dos grupos do usuário alvo seja especificado por meio da opção -g, desde que a opção -P não esteja em uso.

Isso é muito inconveniente. Costumo usar sudopara fins de teste, especialmente quando um serviço ou programa é executado sob UIDs e GIDs arbitrários, o respectivo usuário não sendo membro do respectivo grupo. Nesses casos, antes de poder testar com sudo, tenho que tornar o respectivo usuário membro do respectivo grupo e não devo esquecer de reverter essa ação quando os testes terminarem.

Daí a pergunta: Existe uma configuração ou configuração que permite root-executar sudoprogramas usando UIDs e GIDs arbitrários que não correspondem ? Estou interessado apenas em soluções que forneçam um mecanismo geral para todos os programas, UIDs e GIDs . Ou seja, colocar listas de programas específicos, UIDs ou GIDs /etc/sudoersnão é uma opção.

Uma solução possível poderia ser um provedor de políticas alternativo sudoque permitisse isso. No entanto, aprender a instalá-lo e configurá-lo provavelmente seria muito difícil, e não tenho certeza se seguiria esse caminho, mesmo que não houvesse outra solução. Além disso, eu não encontrei tal coisa até agora.

ATUALIZAÇÃO 1 (2022-01-27)

O sistema em questão roda o Debian buster, atualizado com todos os patches disponíveis no momento em que este artigo foi escrito. O SELinux não está instalado. Este é o meu /etc/sudoersarquivo (deixando apenas comentários e linhas vazias):

Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
root    ALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) ALL
ipupdate ALL = (root) NOPASSWD: /root/scripts/asterisk-external-ip

Atualmente acredito que a última linha não tem nada a ver com o problema e que provavelmente deveria tê-la removido para minimizar a distração. Por outro lado, aprendi que às vezes são apenas as partes aparentemente sem importância "removidas para maior clareza" que realmente causam o respectivo erro.

Eu li muitas perguntas e respostas sobre como o setuidbit funciona e sobre como sudofunciona, e acho que entendi essas coisas.

No entanto, não consegui descobrir o que deve acontecer quando um programa é executado via sudo se o próprio programa tiver o setuidbit definido . A questão é melhor explicada por um exemplo:

No sistema em questão, existe um usuário chamado user1. O sistema foi sudoinstalado e configurado corretamente para que o rootusuário possa executar programas como qualquer usuário diferente que desejar. Além disso, existe um programa /usr/bin/exampleprogque é de propriedade root:wheele tem os bits setuide definidos:setgid

root@morn ~ # dir /usr/bin/exampleprog
-rwsr-sr-x 1 root wheel 92K 2017-11-16 23:42 /usr/bin/exampleprog

Agora eu entro como root e executo o seguinte comando:

root@morn ~ # sudo -u user1 /usr/bin/exampleprog

O que acontece depois? É exampleprogexecutado como user1(como poderia ser esperado das opções fornecidas a sudo) ou é executado como root (porque o executável pertence ao root e tem seu setuidbit definido)?

Para tornar as coisas mais complicadas, existe um programa adicional /usr/bin/wrapper, também de propriedade de root:wheel, mas sem os bits setuide :setgid

root@morn ~ # dir /usr/bin/wrapper
-rwxr-xr-x 1 root wheel 15K 2017-11-16 23:42 /usr/bin/wrapper

O wrapperprograma, ao ser executado, em algum momento executa (spawns) /usr/bin/exampleprog.

Agora eu executo:

root@morn ~ # sudo -u user1 /usr/bin/wrapper

Quando wrapperdesova exampleprog, o último será executado como user1ou como root?

Estou lidando com procmaila primeira vez, então peço desculpas se a pergunta a seguir é estúpida. Antes de colocar procmailem produção, estou fazendo alguns testes básicos. Um deles produziu um resultado totalmente inesperado que o torna quase inútil no meu cenário:

Quando procmailnão consegue ler seu arquivo de configuração, ele define seu código de saída como 0(true) quando termina. Isso é catastrófico, porque no meu cenário, estou usando procmailcomo um MDA que é executado de dentro do fetchmail. Se procmailnão puder ler seu arquivo de configuração, ele não poderá processar (entregar) mensagens conforme necessário, mas definirá o código de saída 0quando terminar; fetchmailinterpreta isso como uma entrega bem-sucedida e exclui as respectivas mensagens upstream. Em resumo, isso leva à perda dessas mensagens.

As permissões neste cenário são bastante complexas ( fetchmail+ procmail+ cyrdeliverover lmtp, fetchmailrodando sob sua própria conta de usuário, procmailsendo suide setgid, e assim por diante), então pode muito bem acontecer que alguém cometa um erro com as permissões quando algo precisa ser alterado. Devido ao problema descrito acima, tais erros provavelmente levam à perda de mensagens.

Portanto, gostaria de saber como fazer procmailpara sair com falha (código de saída diferente de 0) caso não consiga ler seu arquivo de configuração.

Para dar uma ideia do que se trata, considere a seguinte sessão de terminal (linhas irrelevantes removidas). Observe que a propriedade / permissões no diretório de configuração estão erradas intencionalmente, porque este é meu caso de teste.

root@morn /etc/fetchmail # whoami
root

root@morn /etc/fetchmail # dir
total 52K
drwx------   2 fetchmail root 4.0K 2022-01-23 10:09 .
drwxr-xr-x 123 root      root  12K 2022-01-22 17:17 ..
-rw-------   1 fetchmail root 2.4K 2022-01-23 10:09 fetchmailrc
-rw-------   1 root      mail  282 2022-01-23 02:49 procmailrc
-rw-r--r--   1 root      root  110 2022-01-23 00:36 testmessage

root@morn /etc/fetchmail # dir `which procmail`
-rwsr-sr-x 1 root mail 92K 2017-11-16 23:42 /usr/bin/procmail
    
root@morn /etc/fetchmail # cat /etc/systemd/system/pp-fetchmail.service    
User=fetchmail
Group=mail
ExecStart=/usr/bin/fetchmail -f /etc/fetchmail/fetchmailrc --pidfile /run/fetchmail/fetchmail.pid --syslog

root@morn /etc/fetchmail # cat fetchmailrc
poll
pop3.example.com
proto pop3
bad-header accept
user "[email protected]"
ssl
pass "supersecret"
is "user1" here
no rewrite
mda "/usr/bin/procmail TARGET=user1 /etc/fetchmail/procmailrc"

root@morn /etc/fetchmail # cat testmessage
From: [email protected]
To: [email protected]
Subject: Test message

This is a test message.

root@morn /etc/fetchmail # sudo -u fetchmail -g mail /usr/bin/procmail /etc/fetchmail/procmailrc < testmessage && echo "procmail exited 0" 
procmail: Couldn't read "/etc/fetchmail/procmailrc"
procmail exited 0

Claro, as duas últimas linhas são o problema. Alguém sabe como contornar? É claro que corrigir as permissões faria com que funcionasse corretamente, mas é isso que não estou pedindo explicitamente. Eu gostaria de ter uma solução mais robusta em caso de erros (meus ou outros).

Por favor, considere o seguinte log de uma sessão de terminal (Debian Buster, Bash 5.0):

root@cerberus ~/scripts # rm -f result
root@cerberus ~/scripts # { { echo test; } | cat > result; }
root@cerberus ~/scripts # cat result
test
root@cerberus ~/scripts #

Nada de especial aqui, este é o comportamento esperado, e eu o entendo.

Mas não entendo o comportamento no seguinte caso:

root@cerberus ~/scripts # rm -f result
root@cerberus ~/scripts # { { echo test >&3; } | cat > result; } 3>&1
test
root@cerberus ~/scripts # cat result
root@cerberus ~/scripts #

Para ser preciso, acredito que entendo por que "teste" é gerado ao executar a segunda linha, mas não entendo por que nada entra no arquivo de resultado. Meu entendimento do que acontece é o seguinte:

1. A princípio, fd 3 é configurado como uma duplicata de stdout. Tenho certeza de que isso acontece antes que o pipe seja executado, porque, caso contrário, nenhum dos comandos no pipe teria acesso ao fd 3, o que causaria uma mensagem de erro "bad descriptor".

2. Um pipeline não é um comando simples, então um subshell é gerado para executá-lo. O subshell herda o ambiente de execução do shell pai, incluindo descritores de arquivo e redirecionamentos. [1]

3. Cada um dos comandos no pipeline também é executado em seu próprio subshell [2] , novamente herdando o ambiente de execução e os descritores de arquivo. echoA saída de 's é redirecionada para fd 3, que por sua vez foi duplicada de stdoutantes, o que em resumo leva echoa saída de 's a aparecer stdout(a saída vai para fd 3, que vai para fd 1, que é stdout).

4. Mas não entendo por que echoa saída de 's não entra no arquivo de resultado. Do manual do bash (ênfase minha):

A saída de cada comando no pipeline é conectada por meio de um pipe à entrada do próximo comando. Ou seja, cada comando lê a saída do comando anterior. Essa conexão é executada antes de qualquer redirecionamento especificado pelo comando.

Estou entendendo isso no sentido de que echoa saída de ' deve ser conectada à catentrada de ' antes que o redirecionamento >&3seja configurado ou aplicado, respectivamente. Mas se isso for verdade, o arquivo de resultado existirá (e conterá "teste") depois que o comando for executado. Portanto, meu entendimento está obviamente errado.

Alguém poderia explicar o que estou perdendo?

Atualização, com base na excelente resposta de AB e Gilles abaixo, com mais explicações

A fonte das minhas preocupações é o que escrevi no item 3. acima. Simplesmente não funciona assim; veja também a resposta de Gilles.

AB foi o primeiro a fornecer uma resposta (veja abaixo). No entanto, eu precisava de algum tempo para entendê-lo. Por isso vou explicar algumas passagens para que possam ser compreendidas mais facilmente.

1. Última parte da linha: 3>&1é feito primeiro: fd 1 apontando para a saída do terminal é duplicado para fd 3. Isso significa que fd 1 e fd 3 agora apontam para a saída do terminal. Eles são idênticos e podem ser usados ​​alternadamente.

2. Antes de bifurcar, um pipe é criado, normalmente usando a pipe(2)chamada de sistema, nos próximos fds disponíveis: digamos fd 4 e fd 5. O processo de preparação então bifurca em future echo e future cat, executando as seguintes etapas:
   
   a) O processo de preparação para echo funciona assim:
   
   fd 5 é duplicado para fd 1 (sobrescrevendo onde fd 1 apontava: a saída do terminal). Isso significa que fd 1 agora é idêntico a fd 5 e que eles podem ser usados ​​alternadamente. Especificamente, fd 1 não aponta mais para a saída do terminal, mas aponta para a extremidade de escrita do pipe.
   
   Neste estágio (mas veja abaixo), a saída de echoiria para a extremidade de escrita do pipe, porque echoescreve para fd 1, que aponta para essa extremidade de escrita.
   
   Como não precisamos de dois descritores de arquivo para a mesma coisa, e porque echograva em fd 1 de qualquer maneira, fd 5 é fechado agora.
   
   Então echoé executado, mas depois de ter configurado o redirecionamento adicional observado por trás dele (ver 3.).
   
   b) Da mesma forma, o processo de preparação para catduplicatas fd 4 a fd 0, significando que fd 0 não aponta mais para a entrada do terminal, mas aponta para o lado receptor do tubo. Nesse estágio, a entrada para catviria do lado receptor do tubo, porque catlê de fd 0, e fd 0 está conectado a esse lado receptor. Porque não precisamos de dois descritores de arquivo para a mesma coisa, e porque catlê de fd 0 de qualquer maneira, fd 4 é fechado agora. Em seguida, caté executado.
   
   Enquanto tudo isso acontece, o fd 3 é herdado em todos os lugares.

3. >&3faz o oposto do marcador 1: ele duplica fd 3 para fd 1. fd 3 foi criado para apontar para a saída do terminal e é herdado pelo subshell que executa o pipe e os subshells adicionais que executam os comandos individuais do pipe.
   
   Na etapa 2a), fd 1 foi apontado para o lado de escrita do tubo. Mas agora, o redirecionamento >&3sobrescreve fd 1 novamente e o torna igual a fd 3, que por sua vez (ainda) aponta para a saída do terminal. Isso significa que fd 1 não aponta mais para o lado de escrita do pipe, mas para a saída do terminal. Esta é a razão pela qual "test" aparece no terminal quando o pipe é executado (lembre-se que echosempre escreve para fd 1, independentemente de onde fd 1 apontar).
   
   Além disso, quando fd 1 é "substituído" pelo redirecionamento, sua versão antiga é fechada (porque a chamada de sistema subjacente dup2(2)faz isso). Como sua versão antiga apontava para a extremidade de escrita do tubo, essa extremidade de escrita agora está fechada.
   
   Por causa disso, a extremidade receptora e, portanto, cat, não receberá nenhum dado. Eles recebem imediatamente uma notificação EOF. Esta é a razão pela qual catnão recebe nada e, consequentemente, o arquivo de resultado permanece vazio ou é truncado.
   
   [ Nota lateral: eu deveria ter fechado o fd 3 após o redirecionamento (ou seja, deveríamos ter escrito >&3 3>&-em vez de >&3), porqueecho-como mencionado acima- escreve para fd 1 e não sabe nada sobre fd 3. No entanto, essa parte estava faltando no meu exemplo, e eu gostaria de deixar assim para não distrair do problema real). ]
   
   

Em meus scripts bash, costumo usar pipes e gostaria de saber qual estágio do pipe estava causando o problema em caso de erros. A estrutura básica de tais snippets é:

#!/bin/bash

ProduceCommand 2>/dev/null | ConsumeCommand >/dev/null 2>&1
PipeErrors=("${PIPESTATUS[@]}")
[[ "${PipeErrors[0]}" -eq '0' ]] || { HandleErrorInProduceCommand; }
[[ "${PipeErrors[1]}" -eq '0' ]] || { HandleErrorInConsumeCommand; }

Agora (curiosamente pela primeira vez) estou em uma situação em que seria ótimo se eu pudesse usar teeou pee. Mas o que acontece ao $PIPESTATUSusar esses comandos? Por exemplo:

#!/bin/bash

ProduceCommand 2>/dev/null | tee >(ConsumeCommand1) >(ConsumeCommand2) >/dev/null 2>&1
PipeErrors=("${PIPESTATUS[@]}")

ou

#!/bin/bash

ProduceCommand 2>/dev/null | pee ConsumeCommand1 ConsumeCommand2 2>/dev/null
PipeErrors=("${PIPESTATUS[@]}")

Acredito que em ambos os casos ${PipeErrors[0]}reflita o status de erro do ProduceCommand. Além disso, seria lógico supor que ${PipeErrors[1]}reflete o status de erro de teeou de peesi mesmo, respectivamente.

Mas isso me leva a pelo menos dois problemas de compreensão:

1. Qual é o status de erro (valor de retorno) de teeou pee? Não encontrei declarações precisas sobre isso nas páginas de manual. Eles retornam um status de erro codificado se um dos comandos de consumo falhar ou eles retransmitem o status de erro dos comandos de consumo de alguma forma (como ssh, por exemplo)? Se o primeiro for o caso, como podemos descobrir qual dos comandos de consumo é o culpado? Se o último for o caso, qual status de erro é retransmitido? É simplesmente o comando que falha primeiro?

2. AFAIK, bash ou o próprio comando teeor pee, respectivamente, usam pipes (fifos) internamente para obter ProduceCommanda saída de 's para os comandos de consumo. Isso significa que temos um pipe cujo (primeiro e neste caso, único) lado receptor é o próprio pipe. Isso não deve influenciar $PipeErrorsno código de exemplo acima, mas não tenho certeza.

Alguém poderia dar uma luz sobre isso?

A pergunta a seguir está relacionada ao ZFS no Linux (ZoL) / OpenZFS , como é fornecido, por exemplo, no Debian Buster e no Debian Bullseye.

Como o título diz, gostaria de saber se os nomes de instantâneos do ZFS teoricamente podem conter novas linhas (como os nomes de arquivos normais podem fazer) e, se sim, como posso trabalhar com segurança por meio de uma lista de nomes de instantâneos em um script.

Eu tentei criar instantâneos com esses nomes, mas o zfs (felizmente) se recusou a fazer isso. No entanto, gostaria de ter certeza e, portanto, estou perguntando aqui.

Um pouco de pano de fundo: neste site e em outros lugares, muitas vezes há a questão de como podemos analisar a saída de lstrabalhar com a lista de nomes de arquivos nome por nome. A resposta é principalmente: Não faça isso, porque pode haver efeitos colaterais inesperados, por exemplo, se os nomes dos arquivos contiverem novas linhas; em vez disso, use globbing do bash. Eu entendi isso (na verdade, sempre fiz assim).

No entanto, quando se trata de nomes de instantâneos ZFS, não há globbing. Por exemplo, na minha caixa, quando emito algo como zfs list -H -r -o name -t snapshot rpool/vm-garak, recebo uma lista de nomes de instantâneos com as entradas separadas por uma nova linha:

root@cerberus ~/scripts # zfs list -H -r -o name -t snapshot rpool/vm-garak
rpool/vm-garak@Q-2021-10-03-12-09-01
rpool/vm-garak@T-2021-10-03-12-14-01
rpool/vm-garak@T-2021-10-03-12-19-01
rpool/vm-garak@Q-2021-10-03-12-24-01
rpool/vm-garak@T-2021-10-03-12-29-01
rpool/vm-garak@T-2021-10-03-12-34-01
rpool/vm-garak@Q-2021-10-03-12-39-01
rpool/vm-garak@T-2021-10-03-12-44-01
rpool/vm-garak@T-2021-10-03-12-49-01
rpool/vm-garak@H-2021-10-03-12-54-01

Tenho alguns scripts que funcionam com essa lista nome por nome; ou seja, linha por linha, contando com o fato de que o caractere de nova linha indica com segurança um novo nome de instantâneo.

Contanto que eu tenha a criação de instantâneos sob meu controle, isso é seguro, porque posso evitar nomes de instantâneos não razoáveis. Mas os instantâneos são criados por outra pessoa, e daí se houver uma nova linha no nome? Como mencionado acima, não tive sucesso em criar esses nomes de instantâneos, mas certamente não estou ciente de todos os métodos estranhos que poderiam produzi-los.

Uma nota final: estou ciente de que eventualmente poderia me safar com o globbing, desde que se trate de instantâneos normais de conjuntos de dados (sistema de arquivos), porque o ZFS os coloca em um diretório oculto e os torna acessíveis como diretórios/arquivos normais. No entanto, no meu caso, os instantâneos são instantâneos de ZVOLs, que o ZFS não torna acessível dessa maneira.

Da referência rápida do nftables :

family refere-se a um dos seguintes tipos de tabela: ip, arp, ip6, bridge, inet, netdev.

e

type refere-se ao tipo de cadeia a ser criada. Os tipos possíveis são:

filter: Suportado por famílias de tabelas arp, bridge, ip, ip6 e inet.
route: Marca pacotes (como mangle para o gancho de saída, para outros ganchos use o filtro de tipo), suportado por ip e ip6.
nat: Para realizar a tradução de endereços de rede, suportada por ip e ip6.

De outro documento que explica como configurar chains :

Os tipos de cadeia possíveis são:

filtro, que é usado para filtrar pacotes. Isso é suportado pelas famílias de tabelas arp, bridge, ip, ip6 e inet.

route, que é usado para redirecionar pacotes se algum campo de cabeçalho IP relevante ou a marca de pacote for modificado. Se você estiver familiarizado com iptables, esse tipo de cadeia fornece semântica equivalente à tabela mangle, mas apenas para o gancho de saída (para outros ganchos, use filtro de tipo). Isso é suportado pelas famílias de tabelas ip, ip6 e inet.

nat, que é usado para realizar a tradução de endereços de rede (NAT). Apenas o primeiro pacote de um determinado fluxo atinge essa cadeia; os pacotes subseqüentes o ignoram. Portanto, nunca use essa cadeia para filtragem. O tipo de cadeia nat é suportado pelas famílias de tabelas ip, ip6 e inet.

Assim, de acordo com pelo menos duas referências autorizadas, nenhum tipo de cadeia é suportado pela netdevfamília. Diante disso, como podemos usar a netdevfamília?

Gostaria de configurar um SSH Daemon em um dos meus servidores para que determinados usuários em clientes remotos possam executar determinados comandos no servidor. Cada usuário, identificado por uma determinada chave pública, deve ser capaz de executar um comando específico para ele.

Em geral, parece haver muitas opções para fazer isso, sendo três delas:

• ForceCommand ...in sshd_config: Isso não é flexível o suficiente no meu caso, pois cada um desses usuários (chaves públicas) deve acionar outro comando.

• command="..."in authorized_keys: Isso é ideal para minha situação, pois cada usuário tem um authorized_keysarquivo individual em seu diretório inicial nesse servidor e, portanto, cada usuário pode executar seu próprio comando individual. Mas eu tenho um problema de compreensão com esse método que me leva à questão detalhada abaixo.

• O /usr/lib/restricted-ssh-commandsmétodo: Este método é um pouco grande demais para o meu caso de uso porque cada um dos meus usuários precisa apenas de um comando para executar; além disso, as expressões regulares que são usadas com este método devem ser elaboradas com muito cuidado, pois de outra forma impõem um risco de segurança.

Como mencionado acima, gostaria de optar pelo segundo método. No entanto, em todos os tutoriais que li (e isso foi muito, por exemplo, este ) foi enfatizado que devemos adicionar não apenas a command=...opção nos authorized_keysarquivos, mas várias outras, assim:

command="/bin/foo bar baz",no-port-forwarding,no-x11-forwarding,no-agent-forwarding ssh-rsa ...

Agora estou preocupado com a relação entre /etc/ssh/sshd_config(onde já configurei todas as opções do daemon que são importantes para mim em todo o sistema) e as opções nos authorized_keysarquivos.

Eu li man authorized_keyso que me deu a impressão de que authorized_keystem precedência sshd_configpara as opções que estão em ambos. No entanto, não está claramente declarado (a menos que eu tenha perdido) o que acontece com as opções que não estão em authorized_keys, mas estão em sshd_config; eles serão retirados sshd_config?

Para dar um exemplo real: no-x11-forwardingé uma das opções que podemos (e devemos, de acordo com todos os tutoriais que li) usar em authorized_keys. Mas já entrei X11Forwarding no. sshd_configEntão, o que acontece se eu sair no-x11-forwardingde authorized_keys?

Ter que incluir todas as opções relevantes em cada authorized_keysarquivo seria um pouco estúpido, mas mais uma vez, todos os tutoriais que encontrei enfatizavam que deveríamos fazê-lo.

Agradeceria se alguém pudesse me dar uma luz sobre isso.

No passado, de tempos em tempos, ao desenvolver software Linux, notei que algumas manpáginas que tratam da documentação do desenvolvedor estão faltando em meus sistemas.

Isso acontece principalmente em sistemas Debian. Por exemplo, ontem precisei usar a fls()função, mas man flsnão deu em lugar nenhum, e apesar de pesquisar e tentar isso e aquilo, ainda não tenho ideia do que poderia fazer para instalar aquelas manpáginas que faltam.

Acredito que este problema esteja relacionado ao fato de que algumas funções que estão disponíveis originalmente foram implementadas em outras plataformas (por exemplo, fls()parece vir de BSD. No entanto, essa descoberta não ajudou; não há documentação especial POSIXou de BSDdesenvolvedor no Debian ( pelo menos, eu não consegui encontrá-lo).

Até agora, eu contornei o problema pesquisando por man xxx, que funcionou (ou seja, deixe-me encontrar a respectiva manpágina) todas as vezes. Mas isso é grosseiro e insatisfatório e me torna dependente de serviços online, então acho que é hora de resolver o problema.

Como instalar toda essa documentação em versões recentes do Debian (principalmente as páginas de manual que não estão no pacote glibc-doc)?

Por favor, considere o seguinte comando:

find . -type f -name '*.*' -exec mv '{}' '{}_foo' \;

Como findevitar loops infinitos neste caso?

Por um lado, acredito saber que find não funciona como os shell globs, ou seja, não busca uma lista de todos os *.jpgarquivos, armazena essa lista internamente e depois processa as entradas da lista . Em vez disso, ele faz com que os arquivos sejam processados ​​"incrementalmente" a partir do sistema operacional subjacente e processa cada um deles assim que souber (vamos ignorar uma certa quantidade de buffer que pode ocorrer, pois isso é irrelevante para a questão). Afinal, pelo que entendi, essa é a principal vantagem do findover globs em diretórios que contêm muitos arquivos.

Se isso for verdade, gostaria de entender como find evita loops sem fim. No exemplo acima, 1.jpgseria renomeado para 1.jpg_foo. De discussões no StackOverflow e em outros lugares, eu sei que renomear pode resultar no arquivo (nome) ocupando um slot diferente na lista de arquivos do diretório, então é provável que encontre esse arquivo uma segunda vez, renomeie-o novamente (para 1.jpg_foo_foo), e assim sobre.

Obviamente, isso não acontece.