Perguntas[debian](unix)

Isto está em uma máquina Debian 12.10 lxc. Estou tentando fazer com que bind9/named escute em um segundo IP de host local:

/etc/bind/named.conf.options:
options {                                                                                                                            
    listen-on port 53 { 127.0.0.1; 192.168.18.2; };
    listen-on port 5353 { 127.0.0.2; };
    [...]
}

Eu também tentei

    listen-on port 53 { 127.0.0.1; 127.0.0.2; 192.168.18.2; };

mas não está funcionando (sim, reiniciei o named depois de fazer essa alteração de configuração):

$ sudo netstat -tunapl4
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      2126/named
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      2126/named
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      339/master
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      2126/named
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      2126/named
tcp        0      0 192.168.18.2:53         0.0.0.0:*               LISTEN      2126/named
tcp        0      0 192.168.18.2:53         0.0.0.0:*               LISTEN      2126/named
udp        0      0 192.168.18.2:53         0.0.0.0:*                           2126/named
udp        0      0 192.168.18.2:53         0.0.0.0:*                           2126/named
udp        0      0 127.0.0.1:53            0.0.0.0:*                           2126/named
udp        0      0 127.0.0.1:53            0.0.0.0:*                           2126/named

O que estou perdendo e por que a maioria dos meus soquetes estão aparecendo duas vezes?

Editar: esqueci de mencionar - não há nada nos meus registros sobre isso.

Estou atualizando o NodeJS e o NPM para a versão LTS mais recente no meu antigo servidor Debian 11 (bullseye). Limpei os pacotes e dependências nodejs e npm originais da distribuição e instalei com sucesso o NodeJS v22.15.0 e o NPM v10.9.2 usando o nodesource .

Agora estou tentando remover o pacote nodejs-legacy que — presumo — provavelmente não é mais necessário, mas tanto o apt quanto o apt-get (eles se comportam exatamente da mesma forma nesse aspecto) reclamam que:

$ sudo apt remove nodejs-legacy
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Virtual packages like 'nodejs-legacy' can't be removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Pelo que entendi, pacotes virtuais apenas definem dependências e/ou instalam arquivos de configuração. Por que um pacote, mesmo "virtual" — ou como quiserem chamá-lo — não pode ser desinstalado? O apt (ou apt-get ) não pode simplesmente atualizar o banco de dados de pacotes e/ou remover esses arquivos?

Este pacote em particular nem sequer faz parte de nenhuma dependência:

$ sudo apt depends nodejs-legacy
<nodejs-legacy>
$ sudo apt rdepends nodejs-legacy
<nodejs-legacy>

Acho que posso simplesmente deixar assim, já que não parece entrar em conflito com mais nada (pelo menos até agora). Mas prefiro manter meus servidores livres de lixo velho espalhado por aí.

Qual é a maneira recomendada de livrar um sistema Debian de pacotes virtuais antigos que não são mais necessários?

Todos os pacotes listados no arquivo /var/lib/apt/extended_statesmostram Auto-Installed: 1. Eu esperava que os instalados manualmente mostrassem Auto-Installed: 0. Isso é estranho para mim, porque eu instalei o curl manualmente e ele aparece em apt-mark showmanual. Então, onde o apt-mark encontra a lista de pacotes instalados manualmente?

Tenho um minicomputador Qotom Q1900G2-P com AlmaLinux 9.5.
Qotom com bios American Megatrends, build 06/01/2015.
Bios redefinida para a configuração de fábrica, configuração padrão.

Sem cabo de vídeo, HDMI ou VGA, não inicia... nem pelo dmesg, nem pelo syslog, nem pela mensagem NADA!
Parece que até consigo acessar o menu do GRUB, mas obviamente não tenho vídeo conectado, só consigo ver a inicialização. Se eu conectar o vídeo depois, com o miniPC ligado, não há sinal de vídeo.
O mesmo acontece com o Debian 12.10.

OK com Windows!! :(( Com Windows ele inicia também sem cabo de vídeo!

Tentei inserir /etc/default/grubalgumas opções como:
GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset console=tty1"
ou
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset text"

Mas nada! :((

algumas telas do BIOS aqui https://imgur.com/a/TyDEDq5

Alguma ideia para resolver? Agradeço antecipadamente.

Como o Java 25 LTS será lançado em breve (setembro de 2025) e eu ainda não instalei o Java JDK 21 LTS (setembro de 2023), tentei fazer isso no sudo apt install openjdk-21-jdkmeu Debian 12. Mas falhou e apareceu uma package not foundmensagem.

Seu pacote ainda não está disponível no Debian 12: openjdk-21 (exceto no sid).

Estou pensando em baixá-lo de https://jdk.java.net/archive/ como uma versão tar.gzde teste 21.0.2 (build 21.0.2+13)(ao custo de esquecer aptos comandos para lidar com Java e anotar na minha agenda para verificar manualmente se há atualizações lá)

Mas estou com medo disto:

.debO que está incluído aqui não .tar.gzdanificará meu sistema se eu tentar instalá-lo, se o pacote
dedicado para o Debian 12 não puder ser criado por anos?openjdk-21-jdk

Por curiosidade, estou pesquisando sobre gerenciamento de rede Debian.

Notei que meu Debian 12 usa rede por padrão para gerenciar a rede.

$ systemctl status networking
● networking.service - Raise network interfaces
     Loaded: loaded (/lib/systemd/system/networking.service; enabled; preset: enabled)
     Active: active (exited) since Thu 2025-04-17 17:20:34 CST; 2 days ago
       Docs: man:interfaces(5)
   Main PID: 552 (code=exited, status=0/SUCCESS)
      Tasks: 1 (limit: 2306)
     Memory: 1.1M
        CPU: 62ms
     CGroup: /system.slice/networking.service
             └─500 dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0

Pelo documento, essa rede parece com ifupdown.

$man interfaces

Posso pensar nisso simplesmente como uma interface para o ifupdown?

Para enviar e-mails 2FA de um site PHP para mim mesmo, configurei uma substituição de registro MX e criei uma regra de firewall que permite acesso ao servidor de e-mail para o domínio de destino, mas quando tento enviar, sendmailgrava em seu log que o e-mail foi aceito para entrega, mas nunca é entregue.

Para testar a resolução de nomes DNS, eu executo nslookupe insiro type=MXo comando, mas ele sempre imprime:

;; communications error to 10.0.0.1#53: timed out
;; communications error to 10.0.0.1#53: timed out
;; communications error to 10.0.0.1#53: timed out
;; no servers could be reached

Quando eu ping, telnet, ou curl, etc, a resolução de nomes por esse servidor DNS funciona bem. Por exemplo, ele pode instalar pacotes de repositórios Debian.

A partir dessas poucas informações sobre sendmail, que consegui absorver, parece que tudo o que ele precisa entregar [email protected]é um registro MX para example.comapontar para smtp.example.com. Corrija-me se eu estiver errado. Todos esses itens parecem estar em vigor: há um registro MX para example.comno meu servidor DNS; ele aponta para , smtp.example.comque também tem um registro A; estou enviando para [email protected]; há uma regra de firewall que permite que a máquina Linux com sendmailresolva nomes com o servidor DNS; há uma regra de firewall que permite que a máquina Linux com sendmailenvie e-mails para smtp.example.com. Tudo isso existe na minha LAN e não precisa de nenhum acesso à Internet externa.

Como devo solucionar problemas de entrega do sendmail nessa situação?

EDITAR :

Enquanto isso, descobri a causa raiz da falha sendmail: ele acrescenta qualquer endereço de e-mail que eu uso na linha de comando com o nome de usuário conectado no momento (sem considerar su), ou seja, se meu nome de usuário for myusername, ele muda me@mydomainpara myusername@me@mydomainna primeira tentativa e myusername@mydomainna segunda tentativa.

Falta alguma coisa em sendmail.mc, mas o que é?

Tenho um arquivo com terminações de linha no estilo DOS em um *.orig.tar.xzpacote de código-fonte que preciso corrigir antes de compilar um 3.0 (quilt)pacote Debian. Meu patch atualmente tem terminações de linha no estilo Unix.

Podemos inspecionar os arquivos para ver se o patch tem 29 terminações de linha no estilo Unix e se o arquivo de origem tem 5000 terminações de linha no estilo Dos.

$ dos2unix -i debian/patches/model_icd CONFIG/model_config_file.txt
       0      29       0  no_bom    text    debian/patches/model_icd
    5000       0       0  no_bom    text    CONFIG/model_config_file.txt

Resultados da construção:

$ dpkg-buildpackage
...
 dpkg-source --before-build .
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying model_icd
patching file CONFIG/model_config_file.txt
Hunk #1 FAILED at 1638 (different line endings).
Hunk #2 FAILED at 4997 (different line endings).
2 out of 2 hunks FAILED
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'model_icd' is correctly applied by quilt, use 'quilt refresh' to update it
dpkg-source: info: restoring quilt backup files for model_icd
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/model_icd/ --reject-file=- < debian/patches/model_icd subprocess returned exit status 1
dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 2

Coisas que tentei:

Primeiro, eu simplesmente modifiquei meu patch para usar terminações de linha no estilo dos, mas o quilt remove isso e eu obtenho o mesmo resultado

$ unix2dos debian/patches/model_icd
$ dos2unix -i debian/patches/model_icd CONFIG/model_config_file.txt
      29       0       0  no_bom    text    debian/patches/model_icd
    5000       0       0  no_bom    text    CONFIG/model_config_file.txt
$ dpkg-buildpackage
...
dpkg-source: info: applying model_icd
(Stripping trailing CRs from patch; use --binary to disable.)
patching file CONFIG/model_config_file.txt
Hunk #1 FAILED at 1638 (different line endings).
Hunk #2 FAILED at 4997 (different line endings).
2 out of 2 hunks FAILED
...

Se eu testar quiltdiretamente, posso fazê-lo funcionar com a --binaryopção:

$ quilt push -a --binary
Applying patch model_icd
patching file CONFIG/model_config_file.txt

Now at patch model_icd

Para que isso funcione de forma mais automática, tentei definir QUILT_PATCH_OPTS=:

$ QUILT_PATCH_OPTS="--binary" quilt push -a
Applying patch model_icd
patching file CONFIG/model_config_file.txt

Now at patch model_icd

Então, tentei definir isso em debian/rules:

export QUILT_PATCH_OPTS="--binary"
%:
        dh $@

Mas isso não é usado por dpkg-sourcequem usa patchdiretamente, nãoquilt

Em seguida, tentei enganá-lo definindo esse sinalizador no patches/seriesarquivo. dpkg-source(1)recomenda contra isso, o que sugere que isso pode ser possível.

# debian/patches/series
model_icd --binary

Mas isso ainda não funciona.

Tentei procurar source/optionsalgo e li o guia do mantenedor , mas não vi isso abordado em lugar nenhum.

Eu administro a distribuição "bookworm stable". Recentemente, comecei a experimentar um pacote chamado mpd. Por razões que não entendo, o responsável pelo mpdrepositório do GitHub não disponibiliza documentação para versões mais antigas (por exemplo, a versão 0.23.12 incluída na "bookworm stable"). Os manuais do sistema são extremamente breves.

Tenho tido alguns problemas com o mpd, e não ter acesso à documentação detalhada não está ajudando. Decidi que, dadas as circunstâncias, devo tentar um pacote mais recente. A versão que acho que funcionará é a 0.24.2-1 - atualmente no repositório "testing" . O mpdpacote mais recente no Debian, o 0.24.3-1, agora está na pasta "unstable"... Pode ser uma escolha melhor e corresponderia totalmente à documentação disponível .

Quando instalei um pacote de 'backports' , segui um procedimento semelhante a este (atualizado para refletir o uso de 'testing` em vez de 'backports':

• Modifique /etc/apt/sources.listpara adicionar 'teste'
• Instalar:sudo apt install -t testing mpd mpc ...
• Remover testes de /etc/apt/sources.list(uma medida de "segurança" :)

Isso parece aproximadamente correto? Fiz algumas pesquisas, mas não consegui encontrar um exemplo específico de instalação de um único pacote de "testing" para "stable" — todos eles refletiam uma atualização geral (todos os pacotes) para "testing" — não é o que eu quero!

Se isso não funcionar, agradeceria sugestões sobre a melhor forma de proceder com a instalação de uma versão atualizada do mpd.

Ganhei um laptop Dell Precision 5690 novinho para um novo emprego. Instalei o Debian 12 e atualizei o kernel para a versão 6.12.12, pois a maior parte do hardware não funcionava na versão 6.1 que vem com o Bookworm. Estou usando o gerenciador de janelas i3.

Em algum momento, o touchpad parou de funcionar. Não sei exatamente quando, pois eu o usava acoplado a um mouse, mas ele definitivamente funcionava , mas não funciona mais. Pode ser que funcionasse com o Wayland e, quando migrei para o i3/X, parou.

Tenho os seguintes pacotes instalados:

xserver-xorg-input-libinput/stable,now 1.2.1-1+b1 amd64 [installed]
xserver-xorg-input-wacom/stable,now 1.1.0-1 amd64 [installed,automatic][/code]

Colei uma tonelada de resultados de depuração aqui: https://www.pastery.net/hghjmj+unyxkc+unxdvs+uurwru+dsdrdr

• xinput listmostra o dispositivo conforme o esperado
• xinput testnão relata nenhum evento
  • Embora, em um ponto, eu CONSEGUI fazer com que ele relatasse cliques (mas não movimento). Você pode ver isso na minha saída de colagem. Não sei como ou por quê, mas não funciona mais.
• Não consigo ver nenhuma referência ao dispositivo em Xorg.0.log (porém, devo olhar para /var/log/Xorg... ou /var/log/installer/Xorg...?)
• sudo libinput recordmostra claramente que o touchpad está funcionando
• sudo libinput measure touchpad-pressuremostra que a pressão está funcionando
• O touchpad funciona conforme o esperado na tela de configuração do BIOS
• O touchpad também não funciona na tela de login ou quando o X inicia após o login
• Tudo indica que /dev/input/event5o caminho correto é o Touchpad, mas quando eu grep os logs do Xorg para o evento5, ele parece listar um Generic USB Audio devicemouse ou um mouse PS/2

Tenho tentado mexer nos arquivos de configuração do Xorg, por exemplo, usando InputClassseções para "capturar" o touchpad e aplicar o libinputdriver a ele. Também tentei fazer isso e aplicar o evdevdriver, como posso ver no registro libinput mencionado. Nenhuma dessas estratégias parece funcionar, embora eu saiba que esses arquivos de configuração estão funcionando, pois se eu remover o arquivo de configuração libinput, meu teclado e mouse também param de funcionar.

Perguntei em vários lugares, mas ninguém parece capaz de me ajudar. Alguém pode me dar alguma ideia de onde devo continuar procurando?

*** EDITAR ***

Breve atualização sobre isso: o touchpad funciona com meu kernel original versão 6.1. O xinput o detecta como um "mouse genérico PS/2" e, embora eu não consiga rolar com dois dedos nem nada, ele funciona como esperado.

Isso indicaria um problema de firmware? Se sim, há alguma maneira de resolver? Infelizmente, quase nada mais (em termos de hardware) funciona no kernel 6.1.