metablaster's questions

Geralmente sigo o SimpleBackportCreation para criar backports personalizados para vários pacotes que não existem no branch estável.

Um dos passos é instalar build-depscom sudo mk-build-deps --install --removecomando.

A questão é: depois que o backport estiver instalado, preciso manter build-depsos pacotes instalados ou é seguro excluí-los depois que o backport personalizado estiver instalado?

Quero principalmente economizar espaço, mas o motivo secundário é que atualizar um backport pode desinstalar/atualizar build-depsuma versão anterior, mas a compilação para a nova versão do backport pode falhar, então estou pensando se, nesse caso, build-depsos pacotes removidos afetarão o backport antigo criado inicialmente e já instalado.

Resumindo, posso purgar *-build-deps?

Há 10 ferramentas de rede no pacote net-tools do Debian (e também em outras distros, provavelmente o pacote tem um nome diferente):

• arp (ip n)
• ifconfig (ip)
• mmi-ferramenta (ethtool)
• nameif (link ip)
• netstat (ss)
• rota (ip r)
• éteres
• rapp
• plipconfig
• slattach

Pela lista acima, tenho certeza de que os primeiros 6 estão obsoletos e há substitutos conhecidos, conforme estabelecido entre parênteses.

Mas não está claro sobre os outros 4, eles também estão obsoletos e quais são seus substitutos? São eles:

• éteres
• rapp
• plipconfig
• slattach

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

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.

Estou usando o método no link abaixo para criar um backport personalizado do Debian, por exemplo, para pacotes que ainda não foram backportados, mas existem no branch de testes:

https://wiki.debian.org/SimpleBackportCreation

Agora eu gostaria de desfazer o pacote backport instalado, mas simplesmente executar sudo apt purge <package_name>não é suficiente porque vejo que alguns pacotes foram instalados e sobreviveram à limpeza. (Eu os vejo no menu do aplicativo e posso executá-los)

A questão é como identificar todos os pacotes extras que foram instalados para poder eliminá-los também?

Ainda tenho o diretório de compilação que foi usado para compilar o backport.

Se eu executar sudo less /var/log/apt/history.logo log, ele mostrará apenas o backport, mas não mostrará os pacotes extras que foram instalados.

O pacote específico que atualmente desejo expurgar, bem como as dependências, é crow-translate: https://packages.debian.org/trixie/crow-translate

Os pacotes extras neste caso específico que vejo no menu do aplicativo são:

• Assistente QT 5
• Designer QT 5
• QT 5 Linguista

Mas acredito que há mais que não estão visíveis no menu do aplicativo.

A seguir está meu conjunto de regras simplificado ARP, apenas regras de transmissão são mostradas, outras regras (não mostradas aqui) não são relevantes.

Por favor, veja os comentários do código que são perguntas (?)

#!/usr/sbin/nft -f

add chain arp arp_table input {
    # filter = 0
    # Packets delivered to the local system
    type filter hook input priority filter; policy drop;
}

add chain arp arp_table output {
    # filter = 0
    # Packets send by the local system
    type filter hook output priority filter; policy drop;
}

# ARP Broadcast address
define broadcast_ether = { ff:ff:ff:ff:ff:ff }

# IPv4 network address
define network_addr_4 = { 192.168.1.0/24 }

# NIC ether address
define physical_ether = { bb:c9:51:d4:4a:b6 }

# Why input to broadcast address never hits?
# This rule should handle broadcast input
add rule arp arp_table input arp daddr ether $broadcast_ether log prefix "ACCEPT input broadcast: " accept

# Why input to 00:00:00:00:00:00 hits instead?
# This rule handles input toward 00:00:00:00:00:00 from LAN
add rule arp arp_table input arp saddr ip $network_addr_4 arp daddr ether 00:00:00:00:00:00 accept

# Why output to broadcast never hits?
# This rule should handle output toward ff:ff:ff:ff:ff:ff to LAN
add rule arp arp_table output arp daddr ether $broadcast_ether log prefix "ACCEPT output broadcast: " accept

# Why output to 00:00:00:00:00:00 hits instead?
# This rule handles output toward 00:00:00:00:00:00 to LAN
add rule arp arp_table output arp saddr ether $physical_ether arp daddr ether 00:00:00:00:00:00 accept

Há várias questões aqui, a principal delas é que o ARPtráfego de transmissão ff:ff:ff:ff:ff:ffé inexistente, por isso adicionei uma instrução de log para capturar esse tráfego, mas ele nunca aparece, tanto para o tráfego quanto para inputo outputtráfego.

O que acontece é que vejo muita entrada/saída direcionada ao 00:00:00:00:00:00endereço, o que sugere que, 00:00:00:00:00:00de alguma forma, é um endereço de broadcast.

Então a questão principal é por que não vejo ARPtráfego direcionado para o endereço de broadcast e por que 00:00:00:00:00:00o endereço é usado em vez disso?

A segunda pergunta é: o que é 00:00:00:00:00:00endereço? Por que ele é necessário e o que significa?

Se eu bloquear o tráfego de/para 00:00:00:00:00:00(por exemplo, removendo essas regras), a rede deixará de funcionar devido à ARPperda desses pacotes.

Não consigo encontrar nenhuma documentação que explique a sintaxe e a avaliação dos seguintes exemplos de construção:

add rule filter output tcp flags & (syn | ack) == syn | ack
add rule filter output tcp flags & (fin | syn) != 0

Eu li a resposta do @AB aqui: logging TCP flags .

Isso apenas explica o propósito dessas construções ( TCPsinalizadores de correspondência), mas eu gostaria de saber a sintaxe e como funciona a avaliação das expressões junto com os operadores.

Particularmente o significado dos operadores "bit a bit" e como eles são avaliados nas flagsexpressões como um todo.

Também não está claro para mim o que != 0faz e, em particular, o propósito do &operador inicial.

Eu sei que eles são OR, AND etc., mas não entendo como isso se aplica às nftablesregras.

Alguns exemplos mais complexos também poderiam ajudar.

pkexecnão é instalado por padrão, ao Debiancontrário runuserdo que é.

Até agora eu tenho usado, pkexecmas descobri que também existe runuser, e desde então runuserparece ser mais avançado (olhando as opções na manentrada que não entendo completamente e não usei o comando ainda), então isso me fez pensar se existe existe qualquer benefício para instalar pkexecjá runuserestá lá.

Quais são os prós e os contras runuserem comparação com pkexec?

Existem vários blogs on-line dizendo que se syncfor executado, pois sudosincronizará todos os sistemas de arquivos, mas se for executado normalmente (sem sudo), sincronizará o sistema de arquivos "atual".

Mas não está claro o que significa "atual", qual sistema de arquivos é atual?

Se eu tiver 3 discos onde cada um tem 2 partições ext4 totalizando 6 sistemas de arquivos, então qual deles é "atual", synccontra qual deles funcionará se não for executado sudo?

EDITAR:

Blogs que afirmam isso:

https://www.baeldung.com/linux/sync-command

https://phoenixnap.com/kb/linux-sync

Citações:

Geralmente, para sincronizar o sistema de arquivos atual, executamos o comando sincronizar sem qualquer opção:

$ sincronização

Embora o uso de sincronização sem argumentos sincronize o sistema de arquivos atual, a execução do comando com sudo sincroniza todos os sistemas de arquivos montados.

Configurei o switch virtual openvswitch e posso listá-lo com ipo comando da seguinte maneira:

# Show all interfaces
ip link

Saída:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

<snip>

5: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 8a:94:11:48:01:db brd ff:ff:ff:ff:ff:ff
6: ovsbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether e6:db:3f:88:4b:48 brd ff:ff:ff:ff:ff:ff

O openvswitch desta saída é nomeadoovsbr0

Agora quero usar o ipcomando para listar apenas esse switch virtual e excluir outras interfaces, por exemplo:

# List only bridges
ip link show type bridge

Resultado esperado:

6: ovsbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether e6:db:3f:88:4b:48 brd ff:ff:ff:ff:ff:ff

Saída real:

<no output>

Por que espero que este comando seja gerado ovsbr0?

Este problema é específico openvswitchporque se eu usar o mesmo comando para listar pontes que não o são, openvswitchele funcionará bem.

Exemplo com uma ponte criada com ipcomando:

# Create bridge named "br0"
sudo ip link add br0 type bridge

# Show the newly created bridge called "br0"
ip link show type bridge

Fornece o resultado esperado:

7: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 6a:76:6f:50:da:35 brd ff:ff:ff:ff:ff:ff

Como você pode ver, o comando funciona se a ponte for criada com ipo comando.
Mas não funciona paraopenvswitch

Pergunta:

1. Como utilizo o ipcomando para listar apenas openvswitchinterfaces (switches virtuais)?
2. Por que o ipcomando não funciona para listar openvswitchinterfaces (switches virtuais)?

Contexto adicional:

O openvswitchnão foi criado com ipo comando, mas sim com o comando ovs-vsctl que faz parte do openvswitchpacote:

sudo ovs-vsctl add-br ovsbr0

No entanto, esta openvswitchponte pode ser excluída com ipo comando, mesmo que não tenha sido criada com ipo comando:

# Delete it with ip command
sudo ip link delete ovsbr0

# Alternative and conventional method
sudo ovs-vsctl del-br ovsbr0

O que eu tentei:

# List openvswitch only but specifying type other than TYPE bridge
ip link show type TYPE

Quais são os outros tipos de interface para testar a listagem?

# See TYPE := section from this output for types other than "bridge"
ip link show help

/var/log/user.log

Qual é o escopo deste arquivo de log? Está relacionado apenas ao usuário conectado no momento ou a vários usuários e quais?

Do que se trata esse arquivo de log e quando devo examiná-lo?

No link abaixo há uma imagem explicando o fluxo de pacotes entre cadeias emnftables

Ganchos de filtro de rede

Entendo tudo menos uma coisa, a imagem não explica em que fase é routing decisionfeito?

Segundo a imagem deverá ser feito em 2 locais:

1. Depois preroutingdo gancho, mas antes inpute forwardcapuz
2. Antes outputdo gancho quando um pacote sai do processo localhost

O primeiro ponto acima faz sentido porque existem 2 ganchos possíveis a seguir prerouting, no entanto, para o ponto 2 não está claro qual decisão de roteamento deve ser executada, pois a única opção de fluxo do processo local é o outputgancho, portanto não deve haver nenhuma decisão de roteamento, mas o a imagem diz que existe um.

Isso me faz acreditar que existe apenas uma decisão de roteamento que está no ponto 1 acima.
Por que a imagem especifica routing decisiono nó entre local processe outputo gancho?

SNATé feito no postroutinggancho que, de acordo com a documentação, "vê todos os pacotes após o roteamento, pouco antes de saírem do sistema local"
Mas a questão é qual roteamento? já que existem 2 decisões de roteamento de acordo com a imagem.

E aliás. o que é "decisão de roteamento" (nó na imagem) Não acho que seja NATporque NATé feito em preroutinge postroutingganchos.

Aqui está um exemplo de conjunto de regras relevante com 2 exemplos nftablesde regras NAT que mascaram o IP da máquina virtual para a LAN:

#!/usr/sbin/nft -f

add table nat_4

# Sees all packets after routing, just before they leave the local system
add chain nat_4 postrouting_nat_4 {
    type nat hook postrouting priority srcnat; policy accept;
    comment "Postrouting SNAT IPv4 traffic"
}

# Masquerade all packets going from VMs to the LAN/Internet
add rule nat_4 postrouting_nat_4 meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter masquerade to :1024-65535

# Same rule as above but without [to :PORT_SPEC]
add rule nat_4 postrouting_nat_4 meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter masquerade

O endereço IP de exemplo 192.168.122.0/24é o endereço de rede no qual a máquina virtual opera.

Eu entendo o que masqueradeacontece, ele funciona SNATalterando o IP de origem para o IP da interface de saída.
Nesse sentido, entendo o que faz a segunda regra do exemplo acima.

O que não entendo é a declaração [to :PORT_SPEC] ( docs link ), no exemplo (1ª regra):masquerade to :1024-65535

O que exatamente faz masquerade to :1024-65535e é necessário especificá-lo?
Essas duas regras são basicamente iguais ou em que são diferentes?
Qual é o preferido para fazer NAT da máquina virtual para a Internet em vez do switch virtual no host local?

Aqui está um exemplo prático de como atualmente uso um unamed settipo de ICMP:

#!/usr/sbin/nft -f

add table filter_4

add chain filter_4 icmp_out_4 {
    comment "Output ICMPv4 traffic"
}

define response_icmp_4 = {
    0, # Echo Reply
    3, # Destination Unreachable
    10, # Router Solicitation
    11, # Time Exceeded
    12, # Parameter Problem
    14 # Timestamp Reply
}

# Block ICMP response from localhost
add rule filter_4 icmp_out_4 icmp type $response_icmp_4 drop

O que eu quero fazer é converter isso unamed setchamado response_icmp_4em um conjunto nomeado.
Aqui está minha tentativa frustrada de fazer isso:

# Declare named set
add set filter_4 response_icmp_4 { type inet_service }

# Add ICMP type elements
add element filter_4 response_icmp_4 {
    0, # Echo Reply
    3, # Destination Unreachable
    10, # Router Solicitation
    11, # Time Exceeded
    12, # Parameter Problem
    14 # Timestamp Reply
}

A criação do conjunto funciona, mas é recusada durante o processamento da regra:

# Block ICMP response from localhost
add rule filter_4 icmp_out_4 icmp type @response_icmp_4 drop

Com a seguinte saída de erro:

Erro: incompatibilidade de tipo de dados, tipo ICMP esperado, expressão tem tipo serviço de rede de internet

O erro é autoexplicativo, mas a questão é: o que typedevo especificar? porque type inet_servicenão funciona.

De acordo com os documentos, as expressões válidas typesãoipv4_addr, ipv6_addr, ether_addr, inet_proto, inet_service, mark

Também é possível especificar typeofa derivação automática do tipo de dados, mas isso não funciona tão bem, por exemplo:

add set filter_4 response_icmp_4 { typeof vlan id }

Quais erros com erro semelhante:

Erro: incompatibilidade de tipo de dados, tipo ICMP esperado, expressão tem tipo inteiro

O que é um erro estranho porque ICMP typeÉ um número inteiro.

Se você também puder criar um link para a documentação explicando isso, isso seria útil porque não consigo encontrá-lo.

Aqui está um exemplo prático de como ct helpero objeto é atualmente declarado de acordo com os documentos do Nftables

#!/usr/sbin/nft -f

add table filter_4 {
    # TODO: Can helper object be declared outside the scope of table declaration scope?
    # ct helper stateful object
    # "ftp-standard" is the name of this ct helper stateful object
    # "ftp" is the in-kernel name of the ct helper for ftp
    ct helper ftp-standard {
        type "ftp" protocol tcp;
    }
}

O ct helperobjeto é então usado para ex. do seguinte modo:

add chain filter_4 new_out_4 {
    comment "New output IPv4 traffic"
}

# FTP (active and passive)
# Rule for initial ftp connection (control channel), setting ct helper stateful object to use
# "ftp-standard" is the name of the ct helper stateful object
add rule filter_4 new_out_4 tcp sport >1023 tcp dport 21 ct helper set "ftp-standard" accept

O que eu quero alcançar é conhecer a sintaxe para declarar ct helperobjetos fora da tabela de maneira semelhante a como os conjuntos são declarados.

Um exemplo de como um conjunto é declarado fora do escopo da declaração da tabela

add set filter_4 multicast_proto { type inet_proto; comment "IPv4 multicast protocols"; }
add element ip filter_4 multicast_proto { udp, igmp }

De maneira semelhante, quero declarar ct helpero objeto, por exemplo:

# Table declaration
add table filter_4

# Declare ct helper separately
add ct helper ftp-standard {
    type "ftp" protocol tcp;
}

É claro que isso não funciona, qual é a sintaxe para adicionar\declarar ct helperassim?

Parece ct helperque deve estar vinculado a uma tabela (isso é verdade?), portanto, talvez o nome da tabela deva ser especificado no exemplo acima.

Eu configurei uma regra para combinar pacotes multicast da seguinte maneira:

add rule filter_4 new_out_4 meta pkttype multicast goto multicast_out_4

filter_4é uma tabela IPv4, new_out4é uma cadeia de saída e multicast_out_4é uma cadeia para lidar com tráfego somente multicast.

Aqui está uma imagem mais completa da tabela IPv4, excluindo a parte não relevante:

#!/usr/sbin/nft -f

add table filter_4

add chain filter_4 output {
    # filter = 0
    type filter hook output priority filter; policy drop;
}

add chain filter_4 multicast_out_4 {
    comment "Output multicast IPV4 traffic"
}

add chain filter_4 new_out_4 {
    comment "New output IPv4 traffic"
}

#
# Stateful filtering
#

# Established IPv4 traffic
add rule filter_4 input ct state established goto established_in_4
add rule filter_4 output ct state established goto established_out_4

# Related IPv4 traffic
add rule filter_4 input ct state related goto related_in_4
add rule filter_4 output ct state related goto related_out_4

# New IPv4 traffic ( PACKET IS MATCHED HERE )
add rule filter_4 input ct state new goto new_in_4
add rule filter_4 output ct state new goto new_out_4

# Invalid IPv4 traffic
add rule filter_4 input ct state invalid log prefix "drop invalid_filter_in_4: " counter name invalid_filter_count_4 drop
add rule filter_4 output ct state invalid log prefix "drop invalid_filter_out_4: " counter name invalid_filter_count_4 drop

# Untracked IPv4 traffic
add rule filter_4 input ct state untracked log prefix "drop untracked_filter_in_4: " counter name untracked_filter_count_4 drop
add rule filter_4 output ct state untracked log prefix "drop untracked_filter_out_4: " counter name untracked_filter_count_4 drop

Na configuração acima, o novo tráfego de saída, incluindo multicast, é correspondido por regraadd rule filter_4 output ct state new goto new_out_4

Aqui está new_out_4uma cadeia apenas com a regra multicast relevante (não funcional) que não funciona:

# Multicast IPv4 traffic ( THIS RULE DOES NOT WORK, SEE LOG OUTPUT BELOW)
add rule filter_4 new_out_4 meta pkttype multicast goto multicast_out_4

#
# Default chain action ( MULTICAST PACKET IS DROPPED HERE )
#
add rule filter_4 new_out_4 log prefix "drop new_out_4: " counter name new_out_filter_count_4 drop

Aqui está o que o log diz sobre pacotes multicast descartados:

descarte new_out_4: IN= OUT=eth0 SRC=192.168.1.100 DST=224.0.0.251 LEN=163 TOS=0x00 PREC=0x00 TTL=255 ID=27018 DF PROTO=UDP SPT=5353 DPT=5353 LEN=143

O pacote descartado foi enviado para o endereço de destino 224.0.0.251, este é o endereço multicast, deveria ser correspondido pela regra multicast em new_out_4cadeia e deveria ser processado por multicast_out_4cadeia, mas não foi.

Em vez disso, o pacote não foi correspondido e foi descartado pela regra de descarte padrão na new_out_4cadeia acima, consulte o comentário (Ação da cadeia padrão).

Obviamente isto significa que a regra multicast não funciona.

Por que a regra multicast não funciona?

Esperado:

meta pkttype multicastcorresponde ao endereço de destino224.0.0.251

EDITAR:

Informações do sistema:
Kernel: 6.5.0-0.deb12.4-amd64
teve o mesmo problema com o kernel anterior 6.1

nftables: v1.0.6 (Lester Gooch #5)

Instalei winehq-stagingo pacote do repositório winehq no debian 12 em vez do repositório debian que usarei do Lutris.

Depois disso, listei o que foi instalado:

aptitude search '?narrow(?installed,?origin(dl.winehq.org))'

E este comando foi impresso:

i A wine-staging                                   - WINE Is Not An Emulator - runs MS Windows programs       
i A wine-staging-amd64                             - WINE Is Not An Emulator - runs MS Windows programs       
i A wine-staging-i386:i386                         - WINE Is Not An Emulator - runs MS Windows programs       
i   winehq-staging                                 - WINE Is Not An Emulator - runs MS Windows programs

Estou tendo problemas para entender esta saída:

1. O que a letra "A" significa na saída?
2. Qual é a diferença entre winehq-stagingewine-staging
3. Como existem versões x64 e x86 bits instaladas, o que significam as outras duas? isso é o que exatamente significam 4 dessas versões e como elas são usadas?

Abaixo estão 2 exemplos idênticos de configuração de logrotate, a única diferença é o postroatebloco onde o segundo exemplo está faltando>/dev/null 2>&1 || true

/var/log/nftables.log {
  size +10M
  maxage 30
  sharedscripts
  postrotate
    /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
  endscript
}

/var/log/nftables.log {
  size +10M
  maxage 30
  sharedscripts
  postrotate
    /usr/bin/systemctl kill -s HUP rsyslog.service
  endscript
}

Gostaria de saber por que o segundo exemplo é ruim (presumo que seja) e explique o que exatamente
>/dev/null 2>&1 || truefaz?

Quero dizer o significado de cada um dos personagens: >/dev/nulle 2>&1e ||etrue

Aqui está um exemplo arbitrário da minha tentativa de instalar um pacote (wine neste exemplo):

sudo apt install wine
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  fonts-wine libcapi20-3 libodbc2 libosmesa6 libwine libz-mingw-w64 wine64
Suggested packages:
  odbc-postgresql tdsodbc q4wine winbind winetricks playonlinux wine-binfmt dosbox wine64-preloader
Recommended packages:
  wine32
The following NEW packages will be installed:
  fonts-wine libcapi20-3 libodbc2 libosmesa6 libwine libz-mingw-w64 wine wine64
0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 104 MB of archives.
After this operation, 698 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Na saída existem duas categorias (presumivelmente opcionais) chamadas:

• Suggested packages:
• Recommended packages:

Meu entendimento é que --install-suggestsvai instalar Suggested packagesenquanto --no-install-recommendsnão vai instalarRecommended packages:

Meu entendimento está correto?
Minha confusão e pergunta é (em relação à saída): o que exatamente essas duas opções fazem?

Presumo que --install-suggestsserá instalado Suggested packages, o que deve significar que Suggested packagesnão será instalado automaticamente, correto?

Por outro lado, presumo que Recommended packages:sejam instalados automaticamente, a menos --no-install-recommendsque seja especificado.

Meu entendimento está correto e se não, como devo usar essas 2 opções em relação à saída?

Para aumentar a confusão, essas 2 opções parecem mutuamente exclusivas devido ao fato de uma ter conotação negativa enquanto a outra tem conotação positiva.

Antes que a querida comunidade marque esta pergunta como duplicada, saiba que fiz uma pesquisa no site e descobri que não há duplicata equivalente, por exemplo, este link não é duplicado

Eu segui as seguintes instruções:

• https://wiki.debian.org/Backports
• https://backports.debian.org/Instructions

De acordo com estas instruções, a etapa nº 1 é atualizar /etc/apt/sources.listadicionando a seguinte linha:

• deb http://deb.debian.org/debian bookworm-backports main contrib non-free

Quando esta etapa for concluída, precisamos atualizar o índice executandosudo apt update

A partir deste ponto temos duas opções:

1. Instale explicitamente um pacote de backports, por exemplo

• apt install -t bookworm-backports <package>

2. Instalar implicitamente um pacote de backports

• apt install <package>/bookworm-backports

Há uma diferença significativa entre esses 2 métodos!

O primeiro método instalará o pacote a partir de backports, mas também extrairá todas as suas dependências também de backports, incluindo suas dependências e assim por diante, o que resulta na instalação "inchada" de um pacote.

O segundo método é mais limpo, melhor e recomendado pelo debian porque, diferentemente do primeiro método, ele reutilizará dependências (do principal, não dos backports) e puxará apenas o pacote principal que está sendo instalado que é dos backports.

Em outras palavras, o segundo método reutilizará dependências que já estão instaladas no sistema sem baixá-las. No entanto, sob certas circunstâncias, se isso não for possível, ele extrairá dependências de backports (embora em cenários raros)

O problema que estou tendo é que o primeiro método com -topções sempre funciona, enquanto o segundo método nunca funciona.

Quero saber por que isso acontece e como posso fazer o segundo método funcionar?

Aqui estão dois exemplos que podem ser reproduzidos para você testar:

sudo apt install wine/bookworm-backports
sudo apt install passwordsafe/bookworm-backports

Aqui está a saída do primeiro exemplo:

sudo apt instalar wine/bookworm-backports

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package wine is a virtual package provided by:
  wine 8.0~repack-4
You should explicitly select one to install.

E: Release 'bookworm-backports' for 'wine' was not found

Como você pode ver bookworm-backportsnão foi encontrado!

No entanto, se você executar -ta opção, poderá confirmar que isso é falso:

sudo apt install wine -t bookworm-backports

O que funcionará perfeitamente e oferecerá a você a instalação do pacote.

Então a pergunta é muito simples, por que o segundo método (sem a -topção) não funciona e o que preciso fazer para que funcione, estou fazendo algo errado?

Para informações adicionais, estou usando o Debian 12 (bookworm)

E o meu sources.listfica assim:

deb https://deb.debian.org/debian/ bookworm main
deb-src https://deb.debian.org/debian/ bookworm main

deb http://security.debian.org/debian-security bookworm-security main
deb-src http://security.debian.org/debian-security bookworm-security main

deb https://deb.debian.org/debian/ bookworm-updates main
deb-src https://deb.debian.org/debian/ bookworm-updates main

deb https://deb.debian.org/debian/ bookworm-backports main
deb-src https://deb.debian.org/debian/ bookworm-backports main