Minha empresa implementou um dispositivo upstream que faz descriptografia e isso exige que todas as caixas tenham o certificado da CA raiz instalado.

Copiei o certificado ca no formato pem e fiz o seguinte. A atualização confirmou que um certificado foi adicionado. O último certificado em /etc/ssl/certs/ca-certifcates.crt mostra o certificado root.crt. Também instalei o certificado intermediário.

sudo apt-get install -y ca-certificates
sudo cp root.crt /usr/local/share/ca-certificates
sudo update-ca-certificates 

No entanto, ao usar o Firefox ou o Brave, o seguinte erro ocorre. Este erro é do Firefox. É claramente um problema de certificado, acho que os navegadores não estão vendo o certificado?

"Não conectou: possível problema de segurança"

Alguém pode estar tentando se passar pelo site e você não deve continuar.

Os sites provam sua identidade por meio de certificados. O Firefox não confia em www.google.com porque seu emissor de certificado é desconhecido, o certificado é autoassinado ou o servidor não está enviando os certificados intermediários corretos.

Código de erro: SEC_ERROR_UNKNOWN_ISSUER

Descrição

Meu objetivo é fazer ping na Máquina C ( 10.223.0.7) da Máquina A ( 10.101.0.40)

Tenho 2 redes e 3 máquinas

• Rede A:10.223.0.0/24

• Rede B:10.101.0.0/16

• Máquina A (o "pinger"): 10.101.0.40(no eth5)

• Máquina B (o "roteador"): 10.101.2.97(no ens7) e 10.223.0.1(no wg0)

• Máquina C (o "pingado"): 10.223.0.7(em wg0)

• Habilitei o encaminhamento de IP na Máquina B, globalmente e em ambas as interfaces ens7 e wg0

• Meu firewall está ACEITANDO regras FORWARD na Máquina B.

• Adicionei esta regra: iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADEna Máquina B para habilitar o mascaramento

• Adicionei esta regra ip route add 10.223.0.0/24 via 10.101.2.97 dev eth5na Máquina A para rotear os pacotes

O teste

Quando lanço o ping, isto é o que posso ver com tcpdump -nni any icmp:

Máquina A:

18:16:12.976724 eth5  Out  IP 10.101.1.40 > 10.223.0.7: ICMP echo request, id 7373, seq 1065, length 64

Máquina B:

18:16:12.977241 ens7  In  IP 10.101.1.40 > 10.223.0.7: ICMP echo request, id 7373, seq 1065, length 64
18:16:12.977287 wg0   Out IP 10.223.0.1 > 10.223.0.7: ICMP echo request, id 7373, seq 1065, length 64
18:16:12.978201 wg0   In  IP 10.223.0.7 > 10.223.0.1: ICMP echo reply, id 7373, seq 1065, length 64
18:16:12.978217 ens7  Out IP 10.223.0.7 > 10.101.1.40: ICMP echo reply, id 7373, seq 1065, length 64

Máquina C

18:16:12.977754 wg0   In  IP 10.223.0.1 > 10.223.0.7: ICMP echo request, id 7373, seq 1065, length 64
18:16:12.977767 wg0   Out IP 10.223.0.7 > 10.223.0.1: ICMP echo reply, id 7373, seq 1065, length 64

E nenhuma resposta está retornando para a Máquina A.

Acho que o problema está na 4ª linha do log da Máquina B. O IP do SRC é, 10.223.0.7mas na minha opinião deveria ser 10.101.2.97, o IP da Máquina B na rede ens7. Não tenho a mínima ideia do porquê disso ser assim.

Tentei adicionar essa regra de mascarada, iptables -t nat -A POSTROUTING -o ens7 -j MASQUERADEmas como esperado: isso não está funcionando.

Pergunta

Por que a máscara está funcionando na solicitação (veja a 2ª linha da Máquina B) e não na resposta (veja a 4ª linha da Máquina B)?

Visão geral rápida da situação

Tenho um host Fedora no qual há várias NICs e VMs (QEMU/KVM/LibVirt). Cada convidado acessa a internet por meio de uma ponte virtual que opera no modo NAT e encaminha o tráfego para um único dispositivo físico.

Por razões que estão além de mim, quando se trata deste adaptador USB/Ethernet (um telefone Android), não consigo fazê-lo funcionar como faço com outras NICs. O convidado recebe respostas DNS do host, então tenta acessar a internet e não obtém nada além de respostas do tipo ICMP host unreachable e TTL expired .

Uma descrição de como minha infraestrutura funciona

Aqui está um resumo de como isso geralmente funciona. O problemático trio guest/bridge/NIC virá depois (mas supostamente funciona da mesma forma).

O host

Uma estação de trabalho Fedora 40 x86_64.

➜  ~ uname -r 
6.10.6-200.fc40.x86_64

O hipervisor

QEMU/KVM, LibVirt, usando virt-manager ou virsh dependendo das necessidades.

➜  ~ qemu-kvm --version
QEMU emulator version 8.2.6 (qemu-8.2.6-3.fc40)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

➜  ~ virsh --version=long
Virsh command line tool of libvirt 10.1.0
See web site at https://libvirt.org/

Compiled with support for:
 Hypervisors: QEMU/KVM LXC LibXL OpenVZ VMware VirtualBox ESX Hyper-V Test
 Networking: Remote Network Bridging Interface udev Nwfilter
 Storage: Dir Disk Filesystem SCSI Multipath iSCSI iSCSI-direct LVM RBD Gluster ZFS
 Miscellaneous: Daemon Nodedev SELinux Secrets Debug DTrace Readline

➜  ~ virt-manager --version
4.1.0

O convidado

Instalação limpa do Win10, ISO do MS, winFSP e Virtio-win-guest-tools instalados.

C:\Users\User>ver

Microsoft Windows [version 10.0.19045.4780]

PS C:\Windows\system32> winget list
Nom                                      ID                                       Version          Disponible    Source
-----------------------------------------------------------------------------------------------------------------------
WinFsp 2023                              WinFsp.WinFsp                            2.0.23075                      winget
Virtio-win-guest-tools                   ARP\Machine\X86\{c5ad265e-98e6-40bd-801… 0.1.262

Visão geral da configuração usual

Resumindo

Aqui está como eu costumo fazer as coisas. O host é conectado a um roteador por meio de uma NIC Ethernet física, vamos chamá-la de eth0 em my_network. Uma rede virtual é criada no virt-manager, vamos chamá-la de my_virt_net. Ela tem uma ponte virtual que opera no modo NAT e encaminha para o dispositivo físico eth0, vamos chamá-lo de virbr0. O convidado obtém uma interface de rede virtual correspondente àquela fonte de rede, configurada como um dispositivo virtIO, vamos chamá-la de vNIC0.

O vNIC do convidado recebe um IP via DHCP (libvirt executa uma instância DNSMASQ para cada um, eu acho?). Neste exemplo, estamos operando em 10.0.0.0/24, o gateway sendo 10.0.0.1.

Regras e rotas de IP são criadas para garantir que o tráfego do convidado passe pelo dispositivo certo. Libvirt cuida da criação de regras MASQUERADE no iptables.

Uma vez feito tudo isso, o convidado tem acesso à internet. O tráfego flui da seguinte maneira:

Guest <-> vNIC0 <-> virbr0 <-> vnet0 <-> eth0 <-> my_network <-> outside_world

Em detalhe

➜  ~ nmcli con show                        
NAME          UUID                                  TYPE       DEVICE      
my_network   3d72b049-b1a7-49e8-ab55-18edf0d79de9  ethernet   enp0s31f6  

➜  ~ ip addr
1: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 40:8d:5c:4d:e5:c0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 40431sec preferred_lft 40431sec
    inet6 2a01:e0a:18b:b670:3429:7bc3:6997:2e17/64 scope global dynamic noprefixroute 
       valid_lft 86265sec preferred_lft 86265sec
    inet6 fe80::ca7c:24c:ce13:2a22/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
2: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:ed:b3:89 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global virbr0
       valid_lft forever preferred_lft forever
3: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:32:2f:3e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe32:2f3e/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

➜  ~ brctl show
bridge name bridge id       STP enabled interfaces
virbr0      8000.525400edb389   yes     vnet0

➜  ~ virsh net-list
 Name               State    Autostart   Persistent
-----------------------------------------------------
 my_virt_net        active   yes         yes

➜  ~ ip rule
0:  from all lookup local
100:    from all iif virbr0 lookup 100
32766:  from all lookup main
32767:  from all lookup default

➜  ~ ip route show table 100 
default dev enp0s31f6 scope link

➜  ~ ip route               
default via 192.168.1.254 dev enp0s31f6 proto dhcp src 192.168.1.1 metric 100 
10.0.0.0/24 dev virbr0 proto kernel scope link src 10.0.0.1 
192.168.1.0/24 dev enp0s31f6 proto kernel scope link src 192.168.1.1 metric 100 

➜  ~ iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 19151 packets, 2171K bytes)
 pkts bytes target     prot opt in     out     source               destination         
21657 2313K LIBVIRT_PRT  0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain LIBVIRT_PRT (1 references)
    0     0 RETURN     0    --  *      enp0s31f6  10.0.0.0/24          224.0.0.0/24        
    0     0 RETURN     0    --  *      enp0s31f6  10.0.0.0/24          255.255.255.255     
   19   988 MASQUERADE  6    --  *      enp0s31f6  10.0.0.0/24         !10.0.0.0/24          masq ports: 1024-65535
    4  5112 MASQUERADE  17   --  *      enp0s31f6  10.0.0.0/24         !10.0.0.0/24          masq ports: 1024-65535
    0     0 MASQUERADE  0    --  *      enp0s31f6  10.0.0.0/24         !10.0.0.0/24

Esta é uma configuração bem padrão, eu acho. Ela funciona bem para as minhas necessidades. As saídas que mostrei são simplificadas, já que tenho, de fato, vários convidados e NICs, mas você entendeu a ideia. É sempre a mesma configuração, e funciona.

Uma coisa a ser observada é que eu uso scripts /etc/NetworkManager/dispatcher.d/para adicionar ou remover regras de IP e rotas quando as interfaces ficam ativas ou inativas.

Então qual é o problema?

Aqui está o que está acontecendo. Quero usar um dispositivo USB/Ethernet (um telefone Android) conectado ao host e configurar o IP como qualquer outra NIC. Quero que esse telefone seja usado como um gateway para o mundo externo, por um e apenas um convidado, e o host, de preferência, não deve poder usá-lo. Minha configuração usual é ter tudo bem isolado.

O telefone é conectado ao host e configurado para ligar automaticamente o tethering USB. Ele é detectado como uma interface de rede e fornece uma concessão DHCP, como esperado:

➜  ~ ip addr
8: enp0s20f0u6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 46:7a:42:be:dc:85 brd ff:ff:ff:ff:ff:ff
    inet 192.168.171.52/24 brd 192.168.171.255 scope global dynamic noprefixroute enp0s20f0u6
       valid_lft 2302sec preferred_lft 2302sec
    inet6 2a02:8440:6103:24e4:d1fa:3bae:2f95:5b9d/64 scope global deprecated dynamic noprefixroute 
       valid_lft 1503sec preferred_lft 0sec
    inet6 2a02:8440:6315:5cc:8eb1:665a:abb2:6847/64 scope global dynamic noprefixroute 
       valid_lft 7108sec preferred_lft 7108sec
    inet6 fe80::faaa:5745:cf53:55cf/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
13: virbr3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:eb:85:6a brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.1/24 brd 10.0.3.255 scope global virbr3
       valid_lft forever preferred_lft forever

Garantindo que temos conectividade com o mundo exterior:

➜  ~ traceroute -i enp0s20f0u6 www.google.com
traceroute to www.google.com (142.250.178.132), 30 hops max, 60 byte packets
 1  _gateway (192.168.171.21)  0.831 ms  0.711 ms  0.803 ms
 ...
 ...
 ...
 [REDACTED]
 ...
 ...
 ...
15  par21s22-in-f4.1e100.net (142.250.178.132)  49.062 ms  66.086 ms  65.975 ms

Então eu faço o de sempre. Eu crio uma rede virtual no virt-manager (modo NAT, encaminhamento para o dispositivo físico enp0s20f0u6 especificamente) e a conecto como um dispositivo virtIO ao convidado. Eu configuro regras de ip e rotas em um script que roda quando a interface é ativada ou desativada:

➜  ~ sudo nano /etc/NetworkManager/dispatcher.d/103-motoE14-handler.sh

#!/bin/bash

interface=$1
event=$2

if [ "$interface" = "enp0s20f0u6" ]; then
  case "$event" in
    up)
      ip rule add prio 103 iif virbr3 table 103
      ip route add default dev "$interface" table 103
      ;;
    down)
      ip rule del iif virbr3 table 103
      ip route del table 103 default dev "$interface"
      ;;
  esac
fi

➜  ~ sudo chmod +x /etc/NetworkManager/dispatcher.d/103-motoE14-handler.sh

Embora essa seja exatamente a mesma configuração para outros convidados e NICs, o convidado não tem conectividade com o mundo externo.

Verificações de sanidade

Só para esclarecer, fiz o seguinte, e muito mais, antes de postar:

1. Tente outro telefone: não é bom.
2. Tente outro convidado: no bueno.
3. Acabar com a configuração, reconstruir do zero: nada bom.
4. Tente outra NIC no convidado problemático: funciona.
5. Experimente a NIC problemática no host: ela funciona.
6. Tente com todas as outras NICs inativas e apenas esta restante, incluindo defini-la como o gateway padrão para todo o tráfego: nenhuma alteração.
7. n-tuple verifica as regras de IP, rotas de IP, tabelas de IP: parece bom para mim.
8. Verifique o firewall. Tudo parece bem para mim.
9. Tente um novo convidado executando o Fedora 40: mesmo problema.
10. Usar passagem USB: funciona, mas gostaria de gerenciar todas as minhas interfaces da mesma maneira.
11. Use um modelo de dispositivo e1000e em vez de virtIO: não é bom.

Captura de tráfego de rede

Estou tentando ler os dumps TCP que capturo do host, na interface física, na ponte e na vnet, mas isso está além da minha compreensão de rede...

Observe o seguinte:

1. "Fidel" é o nome do anfitrião.
2. A placa de rede USB/Ethernet, também conhecida como telefone Android, é:

• enp0s20f0u6 (nome da interface).
• 46:7a:42:be:dc:85 (endereço MAC).
• 192.168.171.21 (IP de gateway).

3. 192.168.171.52 é o IPv4 alugado pela NIC ao host via DHCP.
4. A ponte virtual é:

• virbr3.
• 52:54:00:eb:85:6a.
• 10.0.3.1.

4. A NIC virtual anexada ao convidado é:

• 52:54:00:43:16:2f
• 10.0.3.219

tcpdumpdo anfitrião: enp0s20f0u6

➜  ~ sudo tcpdump -e -E -f -i enp0s20f0u6 
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s20f0u6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:48:37.824751 46:7a:42:be:dc:85 (oui Unknown) > a6:fe:e6:ee:73:2d (oui Unknown), ethertype IPv6 (0x86dd), length 106: 2a02-8440-6315-05cc-8eb1-665a-abb2-6847.rev.sfr.net.57013 > 2a02-8440-6315-05cc-0000-0000-0000-0033.rev.sfr.net.domain: 3959+ A? checkappexec.microsoft.com. (44)
18:48:37.838107 46:7a:42:be:dc:85 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 20.191.45.158 tell fidel, length 28
18:48:37.867576 46:7a:42:be:dc:85 (oui Unknown) > a6:fe:e6:ee:73:2d (oui Unknown), ethertype IPv6 (0x86dd), length 152: 2a02-8440-6315-05cc-8eb1-665a-abb2-6847.rev.sfr.net.57276 > 2a02-8440-6315-05cc-0000-0000-0000-0033.rev.sfr.net.domain: 10318+ PTR? 3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.c.5.0.5.1.3.6.0.4.4.8.2.0.a.2.ip6.arpa. (90)
18:48:37.988238 a6:fe:e6:ee:73:2d (oui Unknown) > 46:7a:42:be:dc:85 (oui Unknown), ethertype IPv6 (0x86dd), length 232: 2a02-8440-6315-05cc-0000-0000-0000-0033.rev.sfr.net.domain > 2a02-8440-6315-05cc-8eb1-665a-abb2-6847.rev.sfr.net.57013: 3959 3/0/0 CNAME prod-atm-wds-apprep.trafficmanager.net., CNAME prod-agic-we-3.westeurope.cloudapp.azure.com., A 20.56.187.20 (170)

tcpdumpdo anfitrião: virbr3

➜  ~ sudo tcpdump -e -E -f -i virbr3              
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on virbr3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:14:19.404024 52:54:00:43:16:2f (oui Unknown) > 52:54:00:eb:85:6a (oui Unknown), ethertype IPv4 (0x0800), length 74: 10.0.3.219.62464 > fidel.domain: 54546+ A? www.google.com. (32)
19:14:19.414360 52:54:00:eb:85:6a (oui Unknown) > 52:54:00:43:16:2f (oui Unknown), ethertype IPv4 (0x0800), length 90: fidel.domain > 10.0.3.219.62464: 54546 1/0/0 A 216.58.213.68 (48)
19:14:19.427738 52:54:00:43:16:2f (oui Unknown) > 52:54:00:eb:85:6a (oui Unknown), ethertype IPv4 (0x0800), length 106: 10.0.3.219 > par21s18-in-f4.1e100.net: ICMP echo request, id 1, seq 13, length 72
19:14:19.427786 52:54:00:eb:85:6a (oui Unknown) > 52:54:00:43:16:2f (oui Unknown), ethertype IPv4 (0x0800), length 134: fidel > 10.0.3.219: ICMP time exceeded in-transit, length 100
19:14:19.429008 52:54:00:43:16:2f (oui Unknown) > 52:54:00:eb:85:6a (oui Unknown), ethertype IPv4 (0x0800), length 106: 10.0.3.219 > par21s18-in-f4.1e100.net: ICMP echo request, id 1, seq 14, length 72

O que eu vejo?

Quando o convidado solicita uma resolução de DNS, o host parece fornecê-la (e, de fato, a saída do traceroute no convidado do Windows mostra que o endereço IP de www.google.com foi encontrado, mas a rota não pode ser... rastreada).

Alguém tem sugestões sobre o que está acontecendo?

Editar: Tive que encurtar os resultados tcpdumpporque o StackExchange estava detectando minha postagem como spam... Fornecerei mais em postagens subsequentes, se necessário.

Eu estava tentando emitir uma atualização do ceph de 17 para 18.2.4, conforme descrito aqui

ceph orch upgrade start --ceph-version 18.2.4
Initiating upgrade to quay.io/ceph/ceph:v18.2.4

Depois disso, porém, o orquestrador não responde mais

ceph orch upgrade status
Error ENOENT: Module not found

Definir o backend de volta para o orchestrator ou cephadm falha, porque o serviço aparece como 'desabilitado'. O gerente do Ceph jura que o serviço está ligado.

Pelo que pude perceber até agora, estou preso com um daemon mgr executando o reef, enquanto o resto do cluster executa o quincy.

ceph versions
{
    "mon": {
        "ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy (stable)": 5
    },
    "mgr": {
        "ceph version 18.2.4 (e7ad5345525c7aa95470c26863873b581076945d) reef (stable)": 1
    },
    "osd": {
        "ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy (stable)": 31
    },
    "mds": {
        "ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy (stable)": 4
    },
    "overall": {
        "ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy (stable)": 40,
        "ceph version 18.2.4 (e7ad5345525c7aa95470c26863873b581076945d) reef (stable)": 1
    }
}

Como faço para restabelecer o cluster em um estado saudável?

EDIT 1 Saúde Ceph:

  cluster:
    id:     16249ca6-4060-11ef-a8a1-7509512e051b
    health: HEALTH_WARN
            insufficient standby MDS daemons available
            mon gpu001 is low on available space
            1/5 mons down, quorum ***
            Degraded data redundancy: 92072087/608856489 objects degraded (15.122%), 97 pgs degraded, 97 pgs undersized
            7 pgs not deep-scrubbed in time

  services:
    mon: 5 daemons, quorum ***
    mgr: cpu01.fcxjpi(active, since 5m)
    mds: 4/4 daemons up
    osd: 34 osds: 31 up (since 45h), 31 in (since 46h); 31 remapped pgs
 
  data:
    volumes: 1/1 healthy
    pools:   4 pools, 193 pgs
    objects: 121.96M objects, 32 TiB
    usage:   36 TiB used, 73 TiB / 108 TiB avail
    pgs:     92072087/608856489 objects degraded (15.122%)
             29422795/608856489 objects misplaced (4.832%)
             97 active+undersized+degraded
             65 active+clean
             31 active+clean+remapped
  io:
    client:   253 KiB/s rd, 51 KiB/s wr, 3 op/s rd, 2 op/s wr

Nota : a pergunta foi feita originalmente no SO [https://stackoverflow.com/posts/78949269], fui aconselhado a movê-la para cá. Atualmente, estou no processo de pesquisa dos logs do MGR para investigar o status e, eventualmente, forçar um downgrade.

Após a atualização do openssh-server é impossível remover chaves antigas do known_hostsarquivo porque ssh-keygen:

$ ssh-keygen -R oldserver
/home/grin/.ssh/known_hosts:1: invalid line
/home/grin/.ssh/known_hosts:12: invalid line
/home/grin/.ssh/known_hosts:123: invalid line
Not replacing existing known_hosts file because of errors

Preciso remover essas linhas individualmente?

No Ansible 2.16.8 em um Mac (M1) executando Python 3.12.4 (via homebrew), estou tentando configurar um group_vars/all.yml global que pode ser substituído por inventory/x/group_vars/all.yml se necessário. No entanto, parece que o arquivo global está substituindo os valores específicos do inventário.

Dado o seguinte arquivo:

# group_vars/all.yml
level: global all

# inventory/x/group_vars/all.yml
level: inventory all

# inventory/x/group_vars/test.yml
level: inventory group

E correndo:

ansible all -i inventory/x -m debug -a "var=level" -o

Eu entendo:

test-host | SUCCESS => { "changed": false, "level": "inventory group" }
non-test-host | SUCCESS => { "changed": false, "level": "global all" }

Mas espero obter:

test-host | SUCCESS => { "changed": false, "level": "inventory group" }
non-test-host | SUCCESS => { "changed": false, "level": "inventory all" }

Quero configurar um RAID5 usando LVM, com diferentes tamanhos de disco:
2 x 2 TB
3 x 1 TB

Minha primeira pergunta é: qual é a melhor/mais segura configuração para fazer com minha configuração atual:

1. Particionando os 2 TB em 1 TB/partição
   • 7 PV de 1 TB cada em um único VG
   • 1 LV usando RAID5: lvcreate --stripes 6 --type raid5 --size 100%VG --name lv-name vg-name
     => o resultado é um tamanho de 6 TB
2. Reagrupando 1 TB em 2 TB (deixando 1 disco para trás), mas não sei como isso pode ser feito... e se é mesmo possível???
   • Talvez... mesclando 1 VG de 4 TB (2 x 2 TB: vg-name) e 1 VG de 2 TB (2 x 1 TB: new-vg):vgmerge -v vg-name new-vg
   • Então 1 LV RAID5: lvcreate --stripes 2 --type raid5 --size 100%VG --name lv-name vg-name
     => o resultado deve ser um tamanho de 5 TB

Na verdade, para testar, configurei a primeira solução com 7 PV, e a primeira sincronização está demorando uma eternidade, já faz quase 24 horas e está em apenas 39,45%.
Então, estou me perguntando por que, e quero ter alguma saída/estatísticas/relatório sobre minha configuração para talvez entendê-la um pouco mais. Então, aqui vem minha segunda pergunta: como ter algumas informações sobre as estatísticas (velocidade de E/S, status de sincronização, saúde etc...)?
Eu sei sobre:

• lvs -a -o name,copy_percent,health_status,devices vg-name
• Alguns links úteis como Red Hat Doc sobre relatórios LVM
• lvm fullreport(mas a saída é ilegível... quero dizer, não é exibida bem), o Red Hat Doc está falando sobre isso, mas não há nenhum exemplo, nem dicas para personalizar um pouco a saída...

Obrigado pelo seu tempo.

Suponha que eu crie um volume RAID1 de dois discos com mdadm e então crie uma partição BTRFS/ZFS/bcachefs nele. Então os dados em um dos dois discos são corrompidos. Se eu executar uma limpeza, não há como o BTRFS/ZFS/bcachefs corrigir o problema copiando os dados corretos sobre o corrompido. Como aconteceria se fosse o BTRFS/ZFS/bcachefs para gerenciar os dois discos físicos sozinho. Isso ocorre porque o mdadm oculta o fato de que há dois discos físicos subjacentes.

Está certo?

Tenho um problema em todas as máquinas na rede resolvendo especificamente o host analytics.google.com. Devo dizer que todas as outras resoluções de host funcionam bem. Tentei usar vários servidores DNS diferentes, incluindo Cloudflare (DoH), Quad9 (todos eles), Google DNS, sem sucesso. Não está relacionado à máquina cliente ou mesmo ao sistema operacional, já que todas as máquinas nesta rede, incluindo alguns PCs, Macs e dispositivos móveis, têm o mesmo problema.

C:\Users\An>nslookup analytics.google.com
Server:  dns.google
Address:  8.8.8.8

*** dns.google can't find analytics.google.com: Non-existent domain

Apesar disso:

C:\Users\An>nslookup google.com
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    google.com
Addresses:  2a00:1450:4001:808::200e
          172.217.16.142

Estou meio perdido depois de 3 dias tentando resolver um problema. Qualquer ajuda é muito bem-vinda. Obrigado.

Estou quebrando a cabeça com isso desde ontem. Estou tentando configurar o mod_cache para armazenar em cache arquivos JavaScript específicos usando a seguinte configuração colocada na seção de configuração do meu host virtual:

<IfModule mod_cache.c>
                <IfModule mod_cache_disk.c>
                        CacheRoot /var/cache/apache24/mod_cache_disk
                        CacheQuickHandler off
                        CacheIgnoreQueryString On
                        <LocationMatch "chunk-.+\.js$">
                                CacheEnable disk                              
                                CacheHeader on
                                CacheDetailHeader on
                                CacheMaxFileSize 25000000
                                CacheDefaultExpire 86400
                        </LocationMatch>
                </IfModule>
        </IfModule>

Os arquivos são adicionados corretamente ao cache, conforme mostrado pelos cabeçalhos das solicitações http e pela saída de htcacheclean -a -p /var/cache/apache24/mod_cache_disk/:

GET https://example.com/en/chunk-WXIYG2YB.js
HTTP/2 200 
last-modified: Sun, 01 Sep 2024 20:39:11 GMT
etag: "114a-62114d11a75eb-gzip"
accept-ranges: bytes
vary: Accept-Encoding
content-encoding: gzip
x-robots-tag: noindex
x-cache: MISS from mydomain.com
x-cache-detail: "cache miss: attempting entity save" from mydomain.com
content-type: application/javascript
date: Wed, 04 Sep 2024 10:35:43 GMT
server: Apache/2.4.59 (FreeBSD) OpenSSL/1.1.1t-freebsd
X-Firefox-Spdy: h2

e o cache:

https://example.com:443/en/chunk-IUI5V3WX.js?
https://example.com:443/en/chunk-IUI5V3WX.js?
https://example.com:443/en/chunk-WXIYG2YB.js?
https://example.com:443/en/chunk-WXIYG2YB.js?
...

Como pode ser visto, além do fato de haver duplicatas, um caractere "?" é anexado à chave de cache, o que suspeito que possa levar a perdas de cache, mesmo que eu tenha adicionado a configuração CacheIgnoreQueryString.

Todas as requisições que devem atingir o cache resultam em "falha de cache: tentativa de salvar entidade". Eu realmente apreciaria qualquer ajuda ou ideia neste momento.

desde já, obrigado