Malvineous's questions

Dada a configuração abaixo, como posso desfazer a routersopção para o interior grouppara que certas máquinas não sejam informadas do que é o gateway padrão do exterior group?

group {
  # A bunch of options go here which should apply to all clients.
  option domain-name-servers ...
  option routers 192.168.0.1;

  # This host should be told about the default gateway.  This is just an example,
  # there are many more.
  host example1 { }

  group {
    # This group should have no default gateway supplied by the DHCP server,
    # but otherwise inherit all the options from the parent group.
    option routers 0.0.0.0;

    host example2 { }
  }

  # There are many other groups that I have omitted for simplicity.
  group { }
}

No meu caso, estou usando algumas câmeras IP que comprei da China e elas ligam para casa (na verdade, para servidores localizados nos EUA), mas mesmo assim não há como desabilitar isso nos próprios dispositivos. Eu bloqueei o tráfego no meu firewall, mas prefiro que nem chegue tão longe, informando a câmera que não há gateway padrão disponível, então ela não sabe para onde enviar pacotes destinados fora da minha rede.

Quando uso a configuração acima, a 0.0.0.0opção é ignorada pelo servidor DHCP ISC e ainda fornece o gateway herdado do grupo pai.

Existe uma maneira de substituir completamente a routersopção do pai group { }?

Estou tentando configurar um servidor TFTP usando o tftp-hpa e, de acordo com a página de manual , posso usar a --verbosityopção para obter mais saída.

Infelizmente não consigo encontrar nada que explique o que devo passar para esta opção. Como eu uso isso?

• --verbosity loud
• --verbosity 5
• --verbosity 255
• --verbosity DEBUG

Isso está documentado em algum lugar? Nada que eu tentei até agora produz mensagens no stdout.

Por muitos anos, configurei minhas máquinas Linux sem troca, pois elas tinham memória suficiente para fazer o que eu precisava e eu preferiria que um processo fosse morto se usasse muita memória, em vez de ficar cada vez maior e silenciosamente desacelerar tudo.

No entanto, descobri que precisava de swap para usar a hibernação em um laptop, então criei uma partição de troca e a hibernação está funcionando bem.

Recentemente, descobri que a máquina estava entrando em espera em vez de hibernar e, após investigação, descobriu-se que não havia espaço suficiente na partição de troca para que a hibernação ocorresse. Isso ocorreu porque a partição de troca que eu achava que estava reservada para hibernação, na verdade estava sendo usada como espaço de troca normal.

Existe alguma maneira de dizer ao Linux para usar uma determinada partição de troca apenas para hibernação e não usá-la para troca durante a operação normal?

EDIT: De acordo com a pergunta abaixo, a máquina tem 8 GB de memória e a partição de troca também é de 8 GB, já que eu a queria apenas para uso de hibernação e não para uso de troca real, portanto, qualquer tamanho maior que o tamanho da memória da máquina teria sido desperdiçado. O problema subjacente é que, como a partição de troca de 8 GB está sendo usada como memória adicional, a máquina agora pode alocar até 16 GB de memória (8 GB física + 8 GB de troca). Recentemente, ele tinha 10 GB em uso e, é claro, não podia hibernar, pois 10 GB não cabiam na partição de troca de 8 GB.

Então, eu estava testando um roteador e ele adicionou alguns endereços IPv6 aleatórios a todas as máquinas da minha rede, incluindo meu servidor DNS. De alguma forma, esses IPs foram transmitidos como servidores DNS válidos (não tenho certeza de como apenas o roteador real envia pacotes IPv6 RA), mas para encurtar a história, agora todas as minhas máquinas estão enviando consultas DNS para um endereço IP que não existe.

Se eu reiniciar resolvedcom systemctl restart systemd-resolved, resolvectlainda mostrará esses IPs falsos como servidores de nomes válidos.

Eles estão listados, /etc/resolv.confportanto, se eu excluí-los e reiniciá systemd-resolved-los, apenas adiciona os IPs falsos novamente.

Se eu olhar nos logs journalctl --unit=systemd-resolved, ele me diz que os IPs falsos estão operando no "modo de recurso degradado", mas não me diz onde encontrou esses IPs para começar.

De onde ele está pegando esses endereços IP errados? Existe algum arquivo de cache que eu preciso excluir para fazê-lo voltar a usar apenas os IPs fornecidos apenas pelos anúncios do roteador IPv6?

Devido a algumas peculiaridades de rede envolvendo VPNs e intervalos de IP conflitantes, tenho duas sub-redes roteando para duas interfaces diferentes. Eu gostaria de fazer um endereço IP em uma sub-rede sair por um gateway diferente.

Eu posso fazer isso executando:

$ route add -host 1.2.3.4 gw 5.6.7.8
$ ip route show
1.2.3.4 via 5.6.7.8 dev eth0 scope link 

Eu gostaria de tornar esta mudança permanente. Como estou usando systemd-networkd, estou tentando fazer isso atualizando o existente /etc/systemd/network/50-dhcp.conf:

[Match]
Name=eth0

[Network]
DHCP=ipv4

[Route]
#Gateway=5.6.7.8
Destination=1.2.3.4/32

Isso funciona, mas sem a Gatewaylinha não define a rota:

$ ip route show
1.2.3.4 dev eth0 proto static scope link

Se eu descomentar a Gatewaylinha, a nova rota não aparece!

Como posso especificar um gateway ao adicionar a rota estática usando systemd-networkd?

Percebi que, quando faço SSH em uma máquina remota por meio de um link lento, o SSH parece "grudar" depois que uma quantidade relativamente grande de dados é transferida.

Por exemplo, digitar texto no link é bom, mas a execução ls /etccongelará a conexão por alguns minutos.

Eu entenderia se o atraso fosse porque eu estava maximizando a velocidade da conexão e ela voltou ao normal depois que os dados foram transferidos, mas a conexão congela por muito mais tempo do que você esperaria pela quantidade de dados realmente envolvida.

O estranho é que se eu abrir duas conexões SSH de e para as mesmas máquinas, quando uma delas congelou, a outra ainda funciona bem. Portanto, não posso maximizar a velocidade da conexão, caso contrário, os dois congelariam ao mesmo tempo.

Não há modelagem de tráfego ativa em nenhuma caixa ou (tanto quanto eu posso dizer) nos roteadores intermediários, portanto, não deve haver nada descartando pacotes para manter a velocidade média de transferência dentro de um determinado intervalo.

Alguém pode sugerir algo que possa causar esse tipo de comportamento ou algo mais para verificar?

A mesma coisa acontece com scpe sshfs, ao scprelatar uma taxa de transferência enorme (muitos MB/s, então a velocidade cai lentamente stalledpor alguns minutos, então, se eu tiver sorte, ela se repetirá até que a transferência do arquivo termine.) sshfsfunciona, mas muitas vezes (nem sempre) depois que um arquivo é salvo, o ponto de montagem não responde por alguns minutos, bloqueando temporariamente qualquer programa que tente acessá-lo.

EDIT: Eu tentei usar iperfe obter algumas estatísticas interessantes:

Local:  0.0- 0.9 sec   256 KBytes  2.25 Mbits/sec
Remote: 0.0- 7.0 sec   256 KBytes   302 Kbits/sec

Local:  0.0-15.9 sec  1.00 MBytes   529 Kbits/sec
Remote: 0.0-16.0 sec  1.00 MBytes   524 Kbits/sec

Parece que abaixo de uma certa quantidade de dados, o local pode enviar muito mais rápido do que o remoto pode receber. Eu acho que isso não é um problema de SSH, afinal. Vou investigar algumas configurações de TCP que podem ajustar isso, mas se alguém souber com certeza, por favor avise!