Tilman Schmidt's questions

Estou gerenciando alguns proxies da web executando o Squid 4.10 no Ubuntu 20.04LTS em vários locais distribuídos em todo o mundo. Um deles desenvolveu o péssimo hábito de ocasionalmente não acessar uma página da web. O usuário recebe uma página de erro dizendo:

Hmmm... can't reach this page
It looks like the webpage at <URL> might be having issues,
or it may have moved permanently to a new web address.
ERR_TUNNEL_CONNECTION_FAILED

Depois de adicionar %err_code/%err_detailao final do relevante logformatconforme recomendado nesta postagem da lista de discussão , as entradas access.log do Squid para os acessos com falha ficam assim:

1635169354.239    171 10.72.1.103 NONE/503 0 CONNECT ad.360yield.com:443 - HIER_
NONE/- - ERR_DNS_FAIL/-

O status do Squid é NONE/503, e o código de erro e os detalhes sempre ERR_DNS_FAIL/-. O carimbo de data/hora, o endereço IP do cliente e a URL solicitada variam, é claro.

Cada ocorrência do problema afeta um único FQDN ou um número muito pequeno de FQDNs, geralmente todos da mesma organização (por exemplo, lm.licenses.adobe.com e cc-api-data.adobe.io, ambos da Adobe.) Todos os outros os acessos continuam funcionando normalmente. Uma ocorrência dura tipicamente entre cinco e dez minutos. Durante esse período, todos os clientes que tentam acessar esse FQDN são afetados. Antes e depois disso, o mesmo FQDN funciona sem problemas. Não há regularidade discernível nos FQDNs afetados.

Algumas das ocorrências são acompanhadas por uma mensagem como:

2021/10/25 15:42:34 kid1| ipcacheParse No Address records in response to 'ad.360yield.com'

mas na /var/log/squid/cache.logmaioria dos casos nada é registrado lá.

Como posso descobrir o que está errado lá?

Estou executando um servidor rsync (baseado em Linux) para distribuição de software. Um servidor de repositório de origem (baseado em Windows) que está fora do meu controle envia pacotes de software para ele via rsync, e cerca de cem servidores satélites em todo o mundo extraem dele, também via rsync.

O repositório de origem contém muitos arquivos duplicados grandes. Quero reduzir o espaço em disco e o consumo de largura de banda nos servidores satélites, substituindo essas duplicatas por hardlinks. O administrador do repositório de origem não quer ou não pode fazê-lo na origem, então estou tentando fazer isso após o fato no servidor de distribuição. Eu criei um script bash simples baseado nofdupescomando que encontra grupos de duplicatas e os substitui por hardlinks para um único arquivo. As transferências rsync para os servidores satélites preservam esses hardlinks conforme desejado graças à opção -H. A transferência do repositório de origem, no entanto, produz resultados inconsistentes. Às vezes, a desduplicação é preservada. Às vezes, o servidor de origem retransmite todos os arquivos de um grupo desduplicado e a desduplicação é interrompida, mesmo que os arquivos de origem não tenham sido alterados.

Daí a minha pergunta: Qual é o comportamento oficial do rsync caso seja solicitado a sincronizar dois arquivos idênticos, mas separados e os arquivos já existirem no destino com o conteúdo correto, mas como hardlinks para o mesmo arquivo? Qual é o critério exato para retransmitir um arquivo? Existe uma maneira de garantir que o hardlink no destino seja preservado nessa situação, mesmo que o hardlink não exista na origem?

Estou tentando construir um proxy reverso do Apache para tornar um conjunto de servidores acessível por meio de um único ponto de acesso. Todos os servidores oferecem uma interface de administração web na porta 3000, e pretendo apresentar todos eles como diretórios no proxy reverso. As interfaces contêm links locais que devem ser reescritos para ir para o subdiretório correto do servidor no proxy.

Eu posso alcançar o comportamento necessário com trechos de configuração como este para cada servidor individualmente:

<Location /testadmin-warsaw/>
        ProxyPass http://warsaw.example.com:3000/
        ProxyPassReverse /
        ProxyHTMLEnable  On
        ProxyHTMLURLMap  / /testadmin-warsaw/ L
        RequestHeader    unset Accept-Encoding
</Location>

Como isso se torna bastante tedioso e propenso a erros à medida que os servidores vêm e vão, estou buscando uma configuração dinâmica. De acordo com a documentação do Apache, o seguinte deve funcionar:

<LocationMatch "^/testadmin-(?<OFFICENAME>\w+)/(.*)$">
        ProxyPassMatch   http://$1.example.com:3000/$2
        ProxyPassReverse /
        ProxyHTMLEnable  On
        ProxyHTMLInterp  On
        ProxyHTMLURLMap  / /testadmin-${env:MATCH_OFFICENAME|unknown}/ VL
        RequestHeader    unset Accept-Encoding
</LocationMatch>

<LocationMatch>definiria a variável de ambiente MATCH_OFFICENAMEpara a parte do nome do escritório do diretório e ProxyHTMLURLMapinseriria esse nome no local apropriado nos links reescritos.

Mas quando eu testo essa configuração, um link originalmente apontando /other/page.htmlé reescrito em /testadmin-unknown/other/page.htmlvez de /testadmin-warsaw/other/page.htmlcomo pretendido. Em outras palavras, ProxyHTMLURLMapage como se a variável de ambiente MATCH_OFFICENAMEnão estivesse definida.

Se eu omitir a env:parte e colocar apenas /testadmin-${MATCH_OFFICENAME}/como o padrão, o Apache registra um aviso: "AH00111: A variável de configuração ${MATCH_OFFICENAME} não está definida".

Onde está meu erro?

Instalei o Bacula 7.4.4 em um sistema openSUSE Leap 42.3 do repositório https://build.opensuse.org/package/show/home%3AXimi1970%3AopenSUSE%3AExtra/bacula recomendado em https://software.opensuse.org /pacote/bacula . Esses pacotes usam o mecanismo alternativo do openSUSE para configurar o DMBS a ser usado no catálogo - no meu caso, MySQL. Infelizmente, o pacote é um pouco bugado. Após a instalação dos pacotes bacula-director e bacula-mysql, os links simbólicos para a biblioteca libbaccats em /usr/lib64 ficam assim:

libbaccats.so -> /etc/alternatives/libbaccats.so
libbaccats-mysql.so -> libbaccats-mysql-7.4.4.so
libbaccats-stub.so -> libbaccats-7.4.4.so
libbaccats-7.4.4.so -> libbaccats-stub-7.4.4.so

Os dois últimos são obviamente absurdos e fazem com que qualquer tentativa de executar o director ou o utilitário dbcheck falhem com a mensagem de erro:

Erro fatal: Por favor, substitua esta biblioteca libbaccats nula por uma adequada.

Obviamente, isso é facilmente corrigido emitindo os comandos:

ln -sf libbaccats-stub-7.4.4.so libbaccats-stub.so
ln -sf /etc/alternatives/libbaccats-7.4.4.so libbaccats-7.4.4.so

para produzir o resultado desejado:

libbaccats.so -> /etc/alternatives/libbaccats.so
libbaccats-7.4.4.so -> /etc/alternatives/libbaccats-7.4.4.so
libbaccats-mysql.so -> libbaccats-mysql-7.4.4.so
libbaccats-stub.so -> libbaccats-stub-7.4.4.so

que permite os links simbólicos em /etc/alternatives:

libbaccats.so -> /usr/lib64/libbaccats-mysql.so
libbaccats-7.4.4.so -> /usr/lib64/libbaccats-mysql-7.4.4.so

para direcionar corretamente as referências libbaccats para a variante do MySQL.

No entanto, cada vez que o ldconfig(8)comando é executado, ele redefine o link simbólico /usr/lib64/libbaccats-7.4.4.so para apontar para libbaccats-stub-7.4.4.so novamente, quebrando o Bacula. Como ldconfigé executado automaticamente pelo sistema em várias ocasiões, isso é bastante irritante.

O mesmo problema existe com o Bacula 9.0.6 do repositório https://download.opensuse.org/repositories/home:/cristyde/openSUSE_Leap_42.3/ .

Como posso corrigir ldconfiga ideia de onde esse link simbólico deve apontar?

Em um de nossos servidores, yum historyrelata:

[tschmidt@sl-was01p ~]$ sudo yum history
Loaded plugins: product-id, search-disabled-repos, security, subscription-
              : manager
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    30 | <dlewandowski>           | 2016-10-07 11:18 | E, I, U        |   38 EE
    29 | <dlewandowski>           | 2016-09-16 16:13 | Erase          |    3   
[...]

Mas o usuário de login relatado jura que não estava perto da máquina (física ou logicamente) em nenhum lugar próximo a esse momento e lastparece apoiar isso:

[tschmidt@sl-was01p ~]$ last|grep dle
dlewando pts/0        al-dlewandowski. Tue Oct 11 09:01 - 09:23  (00:22)    
dlewando pts/0        al-dlewandowski. Tue Oct 11 08:37 - 08:40  (00:02)    
dlewando pts/1        al-dlewandowski. Tue Oct  4 11:04 - 11:09  (00:04)    
dlewando pts/0        al-dlewandowski. Tue Oct  4 10:50 - 11:11  (00:21)    

O Syslog também não relata nenhuma sudoatividade de ou para esse usuário em torno da yumatividade em questão.

Eu gostaria de saber porque yum historyreporta aquele usuário aparentemente incorreto. De onde ele extrai essa informação? O nome de usuário não aparece em nenhum lugar em /var/log/yum.log.

Dado um domínio do Microsoft Active Directory configurado como um subdomínio do domínio DNS público da empresa, diga:

• domínio público contoso.com
• Domínio do Active Directory inside.contoso.com

Existem cinco controladores de domínio (DCs) em quatro sites. Todos eles também são servidores DNS configurados com contoso.com e inside.contoso.com como zonas integradas do AD separadas. Três dos DCs estão executando o Server 2008R2, os outros dois, o Server 2012.

Agora, irritantemente, uma pasta chamada "dentro" continua aparecendo na zona contoso.com, que contém registros A para alguns ou todos os DCs. Se eu excluir todos esses registros, a pasta desaparece, apenas para reaparecer alguns minutos depois com um único registro A do DC e registros A para os outros DCs adicionados gradualmente. Parece que, quando os controladores de domínio se registram no DNS, as entradas são adicionadas à zona contoso.com em vez de inside.contoso.com, onde pertencem.

Pergunta simples: por quê?

Observação 1: todos os controladores de domínio também estão listados corretamente como registros A na zona intern.contoso.com. Não sei se essas entradas foram adicionadas manualmente.

Observação 2: Nenhuma das outras entradas de host na zona inside.contoso.com é duplicada para a pasta interna na zona contoso.com.

Uma rede habilitada para pilha dupla totalmente IPv6 é monitorada pelo Nagios 3.5.1 instalado do EPEL em um servidor CentOS 6.7. Os hosts monitorados executam agentes NRPE, todos configurados para serem executados como daemons (não via xinetd) com a linha de configuração

allowed_hosts=bombur.example.com

onde bombur.example.comestá o FQDN do servidor Nagios que resolve no DNS para os endereços IPv4 e IPv6:

% host bombur
bombur.example.com has address 192.0.2.28
bombur.example.com has IPv6 address 2001:db8:f00:ba8::28

Isso funciona bem para hosts executando versões NRPE anteriores a 2.15, que não têm suporte para IPv6 e aceitam apenas conexões IPv4. Mas em hosts com NRPE 2.15, que suporta IPv6, as conexões do servidor Nagios são rejeitadas com a mensagem de log:

nrpe[21665]: Host 2001:db8:f00:ba8::28 is not allowed to talk to us!

Aparentemente, a allowed_hosts=<hostname>diretiva permite apenas o endereço IPv4 do host fornecido, não seu endereço IPv6.

Essa dedução está correta? Existe uma maneira de contornar esse comportamento, de preferência sem codificar o endereço IPv6 numérico em todas as configurações do agente NRPE?