nagylzs's questions

Tenho três servidores, totalmente conectados via wireguard. Eles executam o Ubuntu Server 22.04 e o cluster repmr postgresql com replicação de streaming.

Todos os computadores têm um endereço público, mas as instâncias do PostgreSQL e os clientes de banco de dados usam os endereços internos (na VPN wireguard).

Em um dos computadores, vejo isto nos logs:

2024-07-26 07:23:14.463 UTC [147915] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 07:25:56.242 UTC [148509] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 07:28:17.567 UTC [148818] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 07:33:13.234 UTC [149090] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 07:48:42.721 UTC [149723] FATAL:  terminating walreceiver due to timeout
2024-07-26 07:52:17.298 UTC [151521] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 08:01:25.141 UTC [151889] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 08:02:16.337 UTC [152868] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 08:06:13.169 UTC [152951] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 08:22:04.180 UTC [153377] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly

Além disso, quando tento conectar-me ao banco de dados primário a partir de um programa Go ou Python, às vezes vejo "tempo limite de conexão" ou "redefinição de conexão por peer", "a conexão foi fechada no meio da operação" e mensagens semelhantes. É importante observar que isso acontece apenas em um computador e não nos outros.

No lado do servidor (postgresql primário), vejo isso nos logs:

2024-07-26 12:31:36.667 UTC [3778655] telegraf@telegraf LOG:  could not receive data from client: Connection reset by peer
2024-07-26 12:31:36.897 UTC [3777638] telegraf@telegraf LOG:  could not receive data from client: Connection reset by peer
2024-07-26 12:31:39.462 UTC [3775606] telegraf@telegraf LOG:  could not receive data from client: Connection reset by peer
2024-07-26 12:31:39.480 UTC [3780628] telegraf@telegraf LOG:  could not receive data from client: Connection reset by peer

Esses erros acontecem apenas algumas vezes por hora. É o suficiente para tornar meus aplicativos não confiáveis, mas eles são intermitentes. Executei este teste de ping entre os endereços públicos:

ping -c 3600 primary.public.com
# waited an hour...
--- primary.public.com ping statistics ---
3600 packets transmitted, 3600 received, 0% packet loss, time 3603052ms
rtt min/avg/max/mdev = 72.849/73.214/101.325/0.881 ms

Também executei um teste de ping no endereço IP privado:

ping -c 1008 primary.private.com
# waited...
--- primary.private.com ping statistics ---
1008 packets transmitted, 783 received, 22.3214% packet loss, time 1013304ms
rtt min/avg/max/mdev = 80.742/91.383/256.720/16.133 ms

Em outras palavras, 22% dos pacotes de ping são perdidos no wireguard.

O valor MTU para todos os dispositivos wireguard é o padrão 1420.

3: dev0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.241.64.3/32 scope global dev0
       valid_lft forever preferred_lft forever

Também tentei testar o MTU usando este script:

size=1272
while ping -s $size -c1 -M do primary.internaladdress.com >&/dev/null; do 
  ((size+=4))
done
echo "Max MTU size: $((size-4+28))

E também imprimiu 1420.

E observe que o problema só existe entre dois computadores dos três. Por exemplo, é ruim entre A e B, mas é bom entre BC.

Deve-se notar que o computador problemático está longe (num continente diferente). Mas isso não deveria causar isso.

Pelo que entendi, o wireguard encapsula pacotes IP em pacotes UDP criptografados, e o protocolo TCP se encarrega de reenviar os pacotes perdidos.

É muito estranho que os pacotes IP entre endereços públicos tenham 0% de data de descarte, mas os pacotes wireguard/UDP tenham mais de 20%. É possível que pacotes UDP sejam descartados por algum roteador ou switch? Talvez QoS esteja acontecendo?

Esses servidores são alugados e ficam muito distantes um do outro. Obviamente, não posso fazer nada para eliminar a queda de pacotes. Entendo que o UDP sempre não será confiável. Mas me pergunto se posso consertar as conexões TCP de alguma forma. Mesmo que às vezes fiquem lentos (mesmo que não consigam se comunicar por um ou dois segundos), eles não devem reiniciar a conexão. Quais são minhas opções?

Usando o Ubuntu 20.04 LTS, tenho isso em /etc/fail2ban/jail.local:

[DEFAULT]
bantime   = 3600
banaction = iptables
blocktype = drop


[sshd]
enabled   = true
protocol  = tcp
port      = ssh
filter    = sshd
logpath   = /var/log/auth.log
maxretry  = 3

Mas é isso que vejo quando listo as regras do iptables:

╰─# iptables -L f2b-sshd -n -v
Chain f2b-sshd (1 references)
 pkts bytes target     prot opt in     out     source               destination
   13  1356 REJECT     all  --  *      *       222.187.232.205      0.0.0.0/0            reject-with icmp-port-unreachable
   18  1516 REJECT     all  --  *      *       221.181.185.153      0.0.0.0/0            reject-with icmp-port-unreachable
   17  1064 REJECT     all  --  *      *       222.186.180.130      0.0.0.0/0                  777 55854 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

O problema é que ele usa REJECT (com ICMP) em vez de DROP.

O action.d/iptables.conf contém isto:

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>

É o arquivo de ação padrão do iptables, fornecido com o pacote apt fail2ban oficial para esta versão do SO.

Também tentei adicionar "blocktype=drop" em [sshd], mas não tem efeito.

Não tenho certeza de como depurar isso, porque o serviço fail2ban não registra os comandos reais do iptables.

o que estou perdendo?

Eu tenho um disco com essas camadas: disco sata, luks, zpool, ext4

O ext4 fs foi criado com estes comandos:

cryptsetup -v luksFormat /dev/sdb
cryptsetup luksOpen /dev/sda store02
zpool create zstore02 /dev/mapper/store02
zfs create -V 1600G zstore02/dsk02
mkfs.ext4 -L dsk02 /dev/zstore02/dsk02

O sistema é o Ubuntu 20.04.1 LTS. Este pool foi posteriormente importado em outro sistema 20.04.1.

Eu quero criar um instantâneo de leitura/gravação e montá-lo. Mas me diz "sem espaço":

root@computer:~# zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zstore02  1,81T  1,50T   320G        -         -     7%    82%  1.00x    ONLINE  -
root@computer:~# zfs list
NAME             USED  AVAIL     REFER  MOUNTPOINT
zstore02        1,61T   148G       24K  /zstore02
zstore02/dsk02  1,61T   262G     1,50T  -
root@computer:~# zfs snapshot zstore02/dsk02@test
cannot create snapshot 'zstore02/dsk02@test': out of space
root@computer:~# zfs get reservation zstore02/dsk02
NAME            PROPERTY     VALUE   SOURCE
zstore02/dsk02  reservation  none    local
root@computer:~# zfs set reservation=10G zstore02
root@computer:~# zfs set reservation=10G zstore02/dsk02
root@computer:~# zfs snapshot zstore02/dsk02@test
cannot create snapshot 'zstore02/dsk02@test': out of space
root@computer:~#

Não funciona com reservado=nenhum nem reservado=10G.

Aparentemente, "zpool list" relata 300G de espaço livre e "zfs list" relata 262G de espaço livre. Mas de alguma forma não consigo criar um instantâneo. Por quê?

ATUALIZAR

Se eu tentar criar um novo volume, ele funcionará (desculpe pela localidade húngara):

root@computer:~# zfs create -V 1G zstore02/test
root@computer:~# mkfs.ext4 -L test /dev/zstore02/test
mke2fs 1.45.5 (07-Jan-2020)
Eszközblokkok eldobása: kész
Fájlrendszer létrehozása 262144 4 blokkal és 65536 inode-dal
Fájlrendszer UUID: 14e07b33-5d25-465a-aeb8-7fbfe2499dfd
Tartalék szuperblokkok tárolva a blokkokon:
        32768, 98304, 163840, 229376

Csoporttáblák foglalása: kész
Inode táblák írásakor: kész
Napló létrehozása (8192 blokk): kész
Szuperblokkok és fájlrendszer-könyvelési információk írása: kész

root@computer:~# zfs snapshot zstore02/test@snap1

root@computer:~# zfs list -t snapshot
NAME                  USED  AVAIL     REFER  MOUNTPOINT
zstore02/test@snap1     0B      -     32,7M  -
root@computer:~#

Funciona para qualquer volume que eu crie, exceto zstore02/dsk02.

Mas por que?

Eu preciso escrever scripts que criam serviços em clusters docker swarm. Um script de exemplo seria semelhante a este:

docker service create \
    --name postgres \
    --mode global \
    --constraint "node.labels.postgres==master" \
    --network my-network \
    --env POSTGRES_USER="postgres" \
    --env POSTGRES_PASSWORD="****" \
    postgres:10

As variáveis ​​de ambiente POSTGRES_USER e POSTGRES_PASSWORD devem vir dos segredos do docker. Por exemplo:

echo "example_password" | docker secret create postgres-password -

Eu entendo que o segredo pode ser acessado como um arquivo de dentro de um contêiner em execução. Mas no exemplo acima, ele deve ser passado para o comando "service create" como uma variável de ambiente. Ele é usado pelo ponto de entrada do container, portanto deve ser apresentado ANTES do container ser criado. Então, como posso passar um segredo para a opção --env do comando "docker service create"?

Eu tenho um servidor zabbix e um agente, em dois computadores diferentes. O agente é executado no modo ativo, por exemplo, tenho isso no arquivo de configuração:

StartAgents=0
ServerActive=my.zabbix.server.com
Hostname=my.zabbix.agent.com

O servidor zabbix pode ser acessado da máquina com o agente, por exemplo:

telnet my.zabbix.server.com 10051
Trying 111.111.111.111...
Connected to my.zabbix.server.com.
Escape character is '^]'.
Connection closed by foreign host.

Além disso, o registro automático do host foi ativado no servidor e o agente registrou o host com sucesso quando o iniciei. Então a conexão deve estar viva. Isto é o que vejo no log do agente quando o inicio:

83074:20171128:082440.324 Starting Zabbix Agent [my.zabbix.agent.com]. Zabbix 3.4.1 (revision 71734).
83074:20171128:082440.324 **** Enabled features ****
83074:20171128:082440.324 IPv6 support:          YES
83074:20171128:082440.324 TLS support:           YES
83074:20171128:082440.324 **************************
83074:20171128:082440.324 using configuration file: /usr/local/etc/zabbix34/zabbix_agentd.conf
83074:20171128:082440.324 agent #0 started [main process]
83076:20171128:082440.325 agent #1 started [collector]
83077:20171128:082440.326 agent #2 started [active checks #1]

Em outras palavras, o agente poderia se conectar ao servidor, até mesmo reconhecer sua versão. Nada mais acontece no log do agente.

No servidor, ainda diz que o host está inacessível!

Qual poderia ser o problema?

UPDATE : no front-end, vejo esta mensagem:

Não sei por que ele quer se conectar a 10050? É usado para agentes passivos. Meu agente deve estar ativo.

UPDATE2 : Se eu excluir o host do servidor zabbix e reiniciar o agente, acontece o seguinte:

O host é registrado automaticamente no servidor novamente. O registro do agente:

14551:20171128:193954.483 Starting Zabbix Agent [my.zabbix.server.com]. Zabbix 3.4.1 (revision 71734).
14551:20171128:193954.484 **** Enabled features ****
14551:20171128:193954.484 IPv6 support:          YES
14551:20171128:193954.484 TLS support:           YES
14551:20171128:193954.484 **************************
14551:20171128:193954.484 using configuration file: /usr/local/etc/zabbix34/zabbix_agentd.conf
14551:20171128:193954.484 agent #0 started [main process]
14553:20171128:193954.485 agent #1 started [collector]
14554:20171128:193954.485 agent #2 started [active checks #1]
14554:20171128:193954.614 no active checks on server [my.zabbix.server.com:10051]: host [my.zabbix.agent.com] not found

Onde:

• my.zabbix.server.com é o FQDN do servidor
• my.zabbix.agent.com é o FQDN do agente e também o parâmetro HostName na configuração do agente.

Assim, parece que o agente registra o host com sucesso, mas por algum motivo, o servidor tenta obter as informações do agente no modo passivo. Apesar do fato de que o agente foi configurado no modo ativo.

ATUALIZAÇÃO 3 : Embora os agentes estejam enviando dados, a lista de hosts ainda mostra um problema:

Disponibilidade/ZBX tem um sinalizador vermelho e uma mensagem dizendo que "Obter valor do agente falhou: não é possível conectar a [[endereço_ip_aqui]:1050]: [4] chamada de sistema interrompida". Eu verifiquei cada item e cada descoberta para esses hosts, e todos eles têm type="Zabbix Agent Active". Então eu não entendo porque o servidor está tentando se conectar a eles no modo passivo??? Isso não causa um "problema" real (por exemplo, algo que gera uma ação e envia notificações do servidor zabbix), mas é muito perturbador ver bandeiras vermelhas na tela.

Até que esse problema seja totalmente resolvido, nem aceitarei minha própria resposta.

ATUALIZAÇÃO 4 : depois de alterar todos os tipos de itens, tipos de descoberta e os tipos dos protótipos de itens das regras de descoberta de baixo nível de todos os modelos que estão conectados aos meus hosts e todos os modelos vinculados ali, as bandeiras vermelhas do ZBX finalmente desapareceram . Acredito que sou um usuário experiente de software, mas foi bastante difícil entender o que está acontecendo e alterar todos os parâmetros para que funcione.

Eu tenho este arquivo rnd.key no meu sistema:

key "rndc-key1" {
    algorithm hmac-md5;
    secret "xxxxxxxxxxxxxxx==";
};
key "rndc-key2" {
        algorithm hmac-md5;
        secret "yyyyyyyyyyy==";
};

Então eu os uso para diferentes zonas:

zone "somedomain1.com" {
    type master;
    file "/etc/bind/master/db.somedomain1.com";
    allow-update {
    key rndc-key1;
    };
};


zone "somedomain2.com" {
    type master;
    file "/etc/bind/master/db.somedomain2.com";
    allow-update {
    key rndc-key2;
    };
};

Quando tento executar "rndc freeze", recebo este erro:

rndc: error: /etc/bind/rndc.key:5: 'key' redefined near 'key'
rndc: could not load rndc configuration

O que isto significa? Qual é o problema aqui? Não é possível usar teclas diferentes para zonas diferentes?

Eu escrevi um programa com bugs que criou acidentalmente cerca de 30 milhões de arquivos em /tmp. (O bug foi introduzido há algumas semanas e estava criando alguns subdiretórios por segundo.) Eu poderia renomear /tmp para /tmp2 e agora preciso excluir os arquivos. O sistema é FreeBSD 10, o sistema de arquivos raiz é zfs.

Enquanto isso, uma das unidades no espelho deu errado e eu a substituí. A unidade possui dois discos SSD de 120 GB.

Aqui está a questão: substituir o disco rígido e restaurar todo o array levou menos de uma hora. Excluir arquivos /tmp2 é outra história. Escrevi outro programa para remover os arquivos e ele pode excluir apenas 30 a 70 subdiretórios por segundo. Levará de 2 a 4 dias para excluir todos os arquivos.

Como é possível que a restauração de toda a matriz leve uma hora, mas a exclusão do disco leve 4 dias? Por que tenho um desempenho tão ruim? 70 deleções/segundo parece um desempenho muito, muito ruim.

Eu poderia excluir o inode para /tmp2 manualmente, mas isso não liberaria espaço, certo?

Isso pode ser um problema com o zfs, ou com os discos rígidos ou o quê?