Problema
O comando apt-get (no Debian) não pode acessar o repositório via apt-cacher-ng proxy (instalado no Centos).
Ambiente
# /etc/centos-release
CentOS Linux release 7.5.1804 (Core)
$ yum -q info apt-cacher-ng.x86_64
Installed Packages
Name : apt-cacher-ng
Arch : x86_64
Version : 3.1
Release : 4.el7
...
From repo : epel
...
Debianos são 7,11
Detalhes
tcpdump on Centos mostra que não há nenhuma resposta da solicitação apt-cacher-ng to (single) apt-get :
# tcpdump -i eno1 -nn port 3142
...
15:05:17.528378 IP 10.XX.XX.XX.38562 > 10.YY.YY.YY.3142: Flags [S], seq 2752129391, win 29200, options [mss 1460,sackOK,TS val 85570664 ecr 0,nop,wscale 4], length 0
strace no Centows mostra que apt-cacher-ng trava na chamada de sistema select() :
...
open("/dev/null", O_RDWR) = 6
fstat(6, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
dup2(6, 0) = 0
dup2(6, 1) = 1
dup2(6, 2) = 2
close(6) = 0
select(6, [5], [], NULL, NULL
Rastreio completo em Colar: link
Não há reação em strace aos pacotes recebidos ao escutar a porta 3142.
Editar
Existe uma única string no arquivo de log:
Tue Oct 2 14:18:15 2018|Not creating Unix Domain Socket, fifo_path not specified
Mas não sei quando apareceu (lançamentos eram muito mais do que um).
Edit2
Os clientes são configurados com /etc/apt/apt.conf.d/00aptproxy file:
Acquire::http::Proxy "http://10.XX.XX.XX:3142";
O SELinux está no modo permissivo.
O firewall tem uma regra:
-A INPUT -p udp -m udp --dport 3142 -m conntrack --ctstate NEW -j ACCEPT
Editar3
Configuração atual do ator:
# grep -Ev "^$|^#" /etc/apt-cacher-ng/acng.conf
CacheDir: /var/cache/apt-cacher-ng
LogDir: /var/log/apt-cacher-ng
SupportDir: @LIBDIR@
Port:3142
BindAddress:0.0.0.0
ReportPage: acng-report.html
VerboseLog: 1
ForeGround: 1
ExThreshold: 4
Debug: 7
LocalDirs: acng-doc @DOCDIR@
UseWrap: 0
Sic (!) WebUI Interno está disponível com curl 127.0.0.1:3142 , mas não de clientes ( curl 10.XX.XX.XX:3142 )
Edit4
# cat /sys/class/net/eno1/statistics/rx_dropped
0
dropwatch -l kas também não mostra quedas (quando executo apt-cacher-ng e apt-get update no cliente).
Como rastrear a pilha TCP / IP, certo? O Google diz que esses dois métodos são suficientes. ( ifconfig e netstat não estão disponíveis em repos e ethtool não suporta -S flag)
Só agora não tenho ideia de onde cavar ao lado para resolver este problema.
Eu não entendo se o monitoramento de fd6 ( /dev/null ) é o problema real e porque o processo precisa clonar este fd.
Ninguém pode sugerir o que mais posso verificar para encontrar a causa raiz ou solicitar uma solução alternativa?