All perguntas(unix)

Comprei um novo disco rígido USB3 de 16 TB - não um SSD, mas os antigos discos giratórios.

Seagate Expansão HDD 16 TB

Criei uma partição de disco completa formatada com ext4 - 14 TB após a formatação.

Agora, quando eu monto, eu reconheço um som tok-tok-tok. Se eu desmonto, ele desaparece instantaneamente. Ele fica silencioso se ele estiver apenas conectado, mas não montado.

O que é isso? Algum mecanismo de acesso a disco do SO ou o quê? Cache?

Se eu fizer isso em um Debian 10, isso acontece 2x/s. Se eu montar em um Debian 12, isso acontece uma vez a cada 3s.

Tenho uma câmera que cria tráfego RTSP. Conectei-a a um PC Linux via Ethernet, configurei a rede e o acesso. Mas quando tentei aplicar regras de QoS, as estatísticas tc mostraram que poucos bytes foram enviados.

Após alguma pesquisa, descobri que o tráfego HTTP, SSH e RTSP (conexão) da câmera era exibido corretamente nas estatísticas. No entanto, tc parece funcionar de forma diferente com tráfego RTP.

O vídeo no VLC estava sendo reproduzido, nft e tcpdump mostravam tráfego. Tentei usar Debian 12, Ubuntu 24.04, Manjaro - ainda não funcionou. Imitar RTP com FFMPEG também não deu certo. Isso parece muito estranho e eu não sabia o que poderia causar o problema ou o que mais tentar.

Estou tentando instalar o simple-scanneraplicativo em um novo Ubuntu 24.04. Ele não está mais disponível como .DEB, mas posso instalá-lo como um flatpak.

No entanto, ele quer um driver de scanner e o driver de scanner que eu tenho (da Epson) se instala como um .DEB e tenta puxá-lo libsanedo repositório e falha porque não consegue encontrá-lo (funcionou bem no meu sistema Ubuntu 22.04).

Alguma solução?

Antigo usuário do Ubuntu em transição para o Debian

Quando eu digito um comando que requer sudono Debian, mas esqueço de adicioná-lo, sudorecebo uma mensagem de erro extremamente inútil e até incorretacommand not found

Por exemplo

Esqueci de digitarsudo

$ dmidecode
bash: dmidecode: command not found

Digitadosudo

$ sudo dmidecode 
# dmidecode 3.4
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
68 structures occupying 2743 bytes.
Table at 0x000EB9E0.

No Ubuntu, recebi uma mensagem de erro mais útil, como "você deve ser root para usar este comando" ou algo semelhante.

Existe uma maneira de obter uma mensagem de erro melhor no Debian?

Em resposta aos comentários

Fornecer o caminho completo do comando gera uma mensagem de erro mais útil:

$ /usr/sbin/dmidecode
# dmidecode 3.4
/sys/firmware/dmi/tables/smbios_entry_point: Permission denied
Scanning /dev/mem for entry point.
/dev/mem: Permission denied

Então isso provavelmente é um problema de caminho.

Ao monitorar os logs do firewall, notei que MACos endereços relatados nos nftableslogs não correspondem ao comprimento padrão.

Pelo que entendi, MACo endereço tem 48 bits, que devem ser representados como 12 dígitos hexadecimais, porque cada dígito hexadecimal requer 4 bits, portanto 48/4 = 12 dígitos hexadecimais (agrupados em 6 grupos de 2 dígitos cada).

O acima exposto está de acordo com o que a Wikipedia afirma:

Como normalmente representados, os endereços MAC são reconhecíveis como seis grupos de dois dígitos hexadecimais , separados por hífens, dois pontos ou sem separador.

De acordo com a Wikipedia, um exemplo desse endereço é 01:23:45:67:89:AB, o que significa que há 12 dígitos hexadecimais (6 grupos x 2 por grupo = 12) e é assim que reconheço dispositivos no meu LANtambém e como faço a filtragem de tráfego no LAN.

Esses 6 dígitos hexadecimais de grupo também são vistos em logs de firewall (por exemplo, ARPentrada), já que isso está claro, não vou postar um exemplo disso.

No entanto, também existem registros como este:

2024-09-29T14:44:21.000498+02:00 debian kernel: [ 2520.417160] DROP default new_in_4: IN=wlan0 OUT= MAC=00:c0:ca:52:bf:8e:10:a3:b8:f5:f7:28:08:00 SRC=157.48.189.170 DST=192.168.1.34 LEN=132 TOS=0x08 PREC=0x20 TTL=43 ID=0 PROTO=UDP SPT=35165 DPT=3451 LEN=112

Este lista 14 grupos de MACendereços de dígitos hexadecimais ou 28 dígitos hexadecimais no total.
Todos esses endereços começam com 00:e terminam com :00como primeiro e último grupo de dígitos.

Portanto, este MACendereço que pode ser visto no nftableslog tem mais que o dobro do tamanho do que deveria ter (contando o grupo de prefixo e o grupo de sufixo de 00).

A pergunta 1 é: o que é esse MACendereço de 14 grupos e 28 dígitos e o que ele significa em nftableslogs?

E a pergunta 2, provavelmente ainda mais interessante, é: como é possível obter MACo endereço de um peer em algum lugar da internet? Presumo que esse MACendereço venha de fora NATdo firewall porque não o reconheço.

Como posso filtrar esses MACendereços estranhos e devo fazer isso?

Esta entrada de log de exemplo descarta o tráfego UDP de entrada gerado pelo peer do BitTorrent porque fechei o cliente.

editar:

ip link show wlan0

3: wlan0 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DORMANT group default qlen 1000
    link/ether 00:c0:ca:52:bf:8e brd ff:ff:ff:ff:ff:ff

Estou tentando usar jmtpfsminha GoPro para transferir arquivos quando a conecto ao meu computador.

Tenho um script que funciona fora de uma regra udev. No entanto, quando executado dentro da regra udev, o script falha e desconecta meu dispositivo USB.

Um exemplo mínimo de funcionamento é dado aqui:

roteiro

#!/usr/bin/env bash
jmtpfs /media/GoPro > /tmp/gopro.log 2> /tmp/gopro.err

regra udev

SUBSYSTEM=="usb", ATTR{idVendor}=="2672", ATTR{idProduct}=="004b", ACTION=="add", RUN+="/bin/bash -c /home/matt/Projects/GoProScraping/scripts/grab_go_pro_files.sh"

A saída do arquivo /tmp/gopro.erré:

Device 0 (VID=2672 and PID=004b) is UNKNOWN in libmtp v1.1.19.
Please report this VID/PID and the device model to the libmtp development team
fusermount: mount failed: Operation not permitted

A saída de journalctl -fé:

Sep 29 09:45:31 nina kernel: usb 1-4: new high-speed USB device number 16 using xhci_hcd
Sep 29 09:45:31 nina kernel: usb 1-4: New USB device found, idVendor=2672, idProduct=004b, bcdDevice= 0.01
Sep 29 09:45:31 nina kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 29 09:45:31 nina kernel: usb 1-4: Product: GoPro MAX
Sep 29 09:45:31 nina kernel: usb 1-4: Manufacturer: GoPro
Sep 29 09:45:31 nina kernel: usb 1-4: SerialNumber: C3351325091705
Sep 29 09:45:31 nina sudo[1455]:     root : PWD=/ ; USER=root ; COMMAND=/usr/bin/jmtpfs /media/GoPro
Sep 29 09:45:31 nina sudo[1455]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
Sep 29 09:45:34 nina sudo[1455]: pam_unix(sudo:session): session closed for user root
Sep 29 09:45:34 nina kernel: usb 1-4: USB disconnect, device number 16
Sep 29 09:45:34 nina systemd-udevd[1453]: 1-4: Process '/bin/bash -c /home/matt/Projects/GoProScraping/scripts/grab_go_pro_files.sh' failed with exit code 1.

Parece que eu conecto a GoPro, o udev detecta que ela está conectada, então ocorre um erro de permissão e o erro faz com que o USB seja desconectado e então o udev detecta novamente.

Entretanto, se eu tentar executar o comando: jmtpfs /media/GoProcomo usuário root, ele monta bem e eu consigo acessar os arquivos manualmente.

Achei que as regras do udev eram executadas como root. O que estou esquecendo?

Existe alguma correção que eu possa fazer no meu sistema? Devo registrar um bug evdi ou outro bug tracking de um pacote?

A última atualização do kernel falhou. Tive que remover o evdipacote. Depois disso, a atualização foi bem-sucedida. Preciso do evdi para o pacote displaylink-driver para usar uma docking station. Ao tentar instalar, displaylink-driverrecebo a saída do terminal abaixo com um erro de pós-processamento com código de saída 10. O mencionado make.logestá aqui .

Não há muitas opções para eu fazer a docking station funcionar. Um bug registrado para pop os parece resolver isso, no entanto, sem resposta. Não é a primeira vez que instalo este pacote, então um comentário na nota de lançamento apontando para a solução alternativa uefi sec não deve me incomodar. No entanto, tentei e falhei, porque não consigo instalar o pacote evdi. O rastreador de bugs evdi tem um problema com o código de retorno pós-instalação 10 , no entanto, este é antigo e se refere ao kernel mais antigo. Com o kernel kernkel 6.1.0-24-amd64, funcionava antes.

# apt install displaylink-driver
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  linux-headers-6.1.0-21-common
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
  evdi
Suggested packages:
  update-notifier-common
The following NEW packages will be installed:
  displaylink-driver evdi
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/6,905 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Selecting previously unselected package evdi.
(Reading database ... 268277 files and directories currently installed.)
Preparing to unpack .../evdi_1.14.6-100_amd64.deb ...
Unpacking evdi (1.14.6-100) ...
Selecting previously unselected package displaylink-driver.
Preparing to unpack .../displaylink-driver_6.0.0-24_amd64.deb ...
Unpacking displaylink-driver (6.0.0-24) ...
Setting up evdi (1.14.6-100) ...
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
Creating symlink /var/lib/dkms/evdi/1.14.6/source -> /usr/src/evdi-1.14.6

Building module:
Cleaning build area...
make -j16 KERNELRELEASE=6.1.0-25-amd64 all INCLUDEDIR=/lib/modules/6.1.0-25-amd64/build/include KVERSION=6.1.0-25-amd64 DKMS_BUILD=1...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.0-25-amd64 (x86_64)
Consult /var/lib/dkms/evdi/1.14.6/build/make.log for more information.
dpkg: error processing package evdi (--configure):
 installed evdi package post-installation script subprocess returned error exit status 10
dpkg: dependency problems prevent configuration of displaylink-driver:
 displaylink-driver depends on evdi (>= 1.14.4); however:
  Package evdi is not configured yet.
 displaylink-driver depends on evdi (<< 1.15.0); however:
  Package evdi is not configured yet.

dpkg: error processing package displaylink-driver (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 evdi
 displaylink-driver
E: Sub-process /usr/bin/dpkg returned an error code (1)

Sobre a pergunta de Stephen Kitts:

$ cat synaptics.list 
deb [signed-by=/usr/share/keyrings/synaptics-repository-keyring.gpg] https://www.synaptics.com/sites/default/files/Ubuntu/ stable main
deb [signed-by=/usr/share/keyrings/synaptics-repository-keyring.gpg] https://www.synaptics.com/sites/default/files/Ubuntu/ stable non-free

Tenho duas referências que parecem confiáveis, mas oferecem informações diferentes.

Na primeira referência, é mencionado que default.targeté um dos alvos iniciais executados. Então (assumindo que queremos que o sistema inicialize no modo CLI) multi-user.targetserá executado, seguido por basic.target, e finalmente, chegaremos a sysinit.target.

Entretanto, na segunda referência, o processo é descrito na ordem oposta! Ele afirma que sysinit.targeté executado primeiro, seguido por basic.target, e assim por diante.

Estou confuso. Qual ordem está correta? /sbin/initCom ​​qual alvo começa logo no começo?

Recentemente, testei o Hashicorp Vault e o achei muito útil.

Estou tentando configurar certificados SSH assinados para efetuar login em meus hosts/servidores remotos, conforme este guia:

https://developer.hashicorp.com/vault/docs/secrets/ssh/signed-ssh-certificates

Enviei o arquivo .pem público do Vault para o host de destino no qual desejo fazer login e apontei para ele em /etc/ssh/sshd_config usando TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem

Gerei um par de chaves públicas privadas no meu cliente. Obtive a chave pública assinada pelo Vault no meu servidor Vault usando esse guia e enviei de volta para o cliente.

Eu consigo fazer ssh no host de destino sem problemas com senha ou chave privada ssh. O que eu não consigo fazer funcionar é ssh com a chave pública assinada e também forçá-lo a usar somente esse método.

Aqui estão os comandos que tentei adicionar ao arquivo de configurações do host (Debian) /etc/ssh/sshd_config: usePAM no PasswordAuthentication no ChallengeResponseAuthentication no PubKeyAuthentication no

Aqui está o comando ssh que estou usando: ssh -v -o “IdentityOnly yes” -o CertificateFile=“/path/to/signedcert.pub” -i “/path/to/privatekey” user@IP

As saídas -v indicam que ele tenta as várias opções, mas, no final das contas, o certificado assinado não funciona e ele retorna para a autenticação de senha (o que também não está claro para mim, pois pensei que meus comandos em sshd_config seriam suficientes para desabilitar isso...). Estou executando sudo systemctl restart sshd ao fazer essas alterações no host de destino.

Qualquer conselho ou sugestão seria muito apreciado, pois estou me sentindo um tanto bloqueado, mas provavelmente estou esquecendo de algo óbvio...

Obrigado pela ajuda!

Uma pergunta relacionada está aqui, mas a resposta não é muito intuitiva. Certamente há um método mais padrão para configurar NIC:
Como posso associar permanentemente comandos tc qdisc a uma interface específica?

Outra questão relacionada é:
As regras do TC podem persistir além de uma reinicialização? Onde?

No entanto, não estou usando networkingo serviço para editar, /etc/network/interfacesconforme detalhado posteriormente na pergunta.

Atualmente, minha placa de rede wifi está configurada para usar noqueuedisciplina de enfileiramento e quero alterá-la para fq_codel, mas, para que ela persista, reinicialize:

ip link show dev wlan0
    
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff

Para mudar qdisceu faço:

sudo tc qdisc add dev wlan0 root fq_codel
ip link show dev wlan0

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DORMANT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff

Isso funciona, qdiscfoi alterado conforme visto, mas somente até a reinicialização.

Também verifiquei o qdiscvalor padrão definido no sistema, que já está definido como fq_codel:

sudo sysctl net.core.default_qdisc

net.core.default_qdisc = fq_codel

A rede é controlada por systemd-networkd, networkingo serviço é desabilitado.
A NIC é gerenciada por NetworkManagersem nenhuma configuração systemd.