El cliente y el servidor de Perforce ya no se conectan, 127.0.0.1:1666 rechaza todas las conexiones en el servidor, incluso las conexiones locales

El cliente y el servidor de Perforce ya no se conectan, 127.0.0.1:1666 rechaza todas las conexiones en el servidor, incluso las conexiones locales

Tengo un servidor que ejecuta el servidor Ubuntu 18.04, y es el servidor local general: aloja un recurso compartido de samba, un servidor de medios y un servidor Perforce. Me conecto a ese depósito a través de una IP de red local (ssl:192.xxx:1666). Todo iba funcionando muy bien hasta...

... También intenté agregarle una instalación de wiki.js. Hubo muchos cambios en los paquetes y la configuración. Apache fue eliminado, wiki.js/mongodb/mariadb/postgresql fueron desechados y eliminados más de una vez, y nginx fue instalado y eliminado muchas veces.

He aquí por qué: (contexto de lo que estaba haciendoprobablementecausó esto):

Tengo filtrado de DNS para toda la red a través de PiHole y con eso, creé nombres DNS locales y entradas CNAME para los distintos procesos en ese servidor Ubuntu. La idea era poder apuntar una máquina cliente a otra parte de la red, por ejemplo, "perforce.RackServer.net" en lugar de "192.168.0.x:1666" y obtener el mismo resultado con algún proxy inverso mediante nginx. Intentábamos hacer que las direcciones fueran legibles para los humanos en lugar de que todos tuvieran que pedirme direcciones IP y números de puerto para todo.

Hicenotuvo éxito al configurar nginx. Está desinstalado ahora. Está bien, volveré a ello más tarde. Aquí está el problema.

En algún momento de todo eso, algo con la configuración de red (la máquina tiene eth0 y eth1) se estropeó, y ahora, cuando intento #sudo systemctl start helix-p4dctl.service

yo obtengo

Job for helix-p4dctl.service failed because the control process exited with error code.
See "systemctl status helix-p4dctl.service" and "journalctl -xe" for details.

Una verificación de estado de systemctl me da:

Jun 20 14:10:07 RackServer p4dctl[4186]: error: Connect to server failed; check $P4PORT.
connect: 127.0.0.1:1666: Connection refused
Jun 20 14:10:07 RackServer p4dctl[4188]: error: Connect to server failed; check $P4PORT.
connect: 127.0.0.1:1666: Connection refused
Jun 20 14:10:07 RackServer p4dctl[4189]: error: Connect to server failed; check $P4PORT.
connect: 127.0.0.1:1666: Connection refused
Jun 20 14:10:07 RackServer p4dctl[4190]: error: Connect to server failed; check $P4PORT.
connect: 127.0.0.1:1666: Connection refused
Jun 20 14:10:08 RackServer p4dctl[4181]: error: 'PerforceServer' p4d: '/opt/perforce/sbin/p4d' exited with status 255.
Jun 20 14:10:08 RackServer p4dctl[4181]: Started 0 services.
Jun 20 14:10:08 RackServer p4dctl[4181]: error: Not all services started successfully.
Jun 20 14:10:08 RackServer systemd[1]: helix-p4dctl.service: Control process exited, code=exited status=1
Jun 20 14:10:08 RackServer systemd[1]: helix-p4dctl.service: Failed with result 'exit-code'.
Jun 20 14:10:08 RackServer systemd[1]: Failed to start LSB: Starts all Perforce services.

Esto es similar al error que aparece ahora al intentar conectarme de forma remota con el cliente visual p4v:
Connect to server failed; check $P4PORT.
connect: 192.168.0.117:1666: Connection refused

Verificar la variable de entorno P4PORT en el servidor me da:

...nada. DEBE ser ssl:1666 o simplemente 1666. Solía ​​serlo, hasta ahora. Entonces, si lo configuro como debería ser

export $P4PORT=ssl:1666

y luego intento iniciar el servicio, aparece el mismo error que la primera vez.

Comprobemos la conexión real...

admin@RackServer:~$ ping 192.168.0.117
PING 192.168.0.117 (192.168.0.117) 56(84) bytes of data.
64 bytes from 192.168.0.117: icmp_seq=1 ttl=64 time=0.052 ms
64 bytes from 192.168.0.117: icmp_seq=2 ttl=64 time=0.022 ms
64 bytes from 192.168.0.117: icmp_seq=3 ttl=64 time=0.017 ms

Lo mismo con: admin@RackServer:~$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.022 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.016 ms

Y: admin@RackServer:~$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.054 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.018 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.014 ms

Sin embargo, nmap no muestra 1666 abierto... 21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
139/tcp open netbios-ssn
445/tcp open microsoft-ds
631/tcp open ipp
3306/tcp open mysql
3389/tcp open ms-wbt-server

Aquí está el ifconfig, sólo como referencia.
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.117 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::da16:9fa8:aff2:2aef prefixlen 64 scopeid 0x20<link>
ether 00:04:23:d3:d0:92 txqueuelen 1000 (Ethernet)
RX packets 33063 bytes 2652752 (2.6 MB)
RX errors 0 dropped 2 overruns 0 frame 0
TX packets 1872 bytes 269690 (269.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18 memory 0xb8820000-b8840000

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.116 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::659f:d321:8607:cc5f prefixlen 64 scopeid 0x20<link>
ether 00:04:23:d3:d0:93 txqueuelen 1000 (Ethernet)
RX packets 31082 bytes 2047269 (2.0 MB)
RX errors 0 dropped 2 overruns 0 frame 0
TX packets 531 bytes 41557 (41.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 19 memory 0xb8800000-b8820000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 5185 bytes 278583 (278.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5185 bytes 278583 (278.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

En realidad, no soy un tipo de networking de profesión, y todavía estoy aprendiendo *nix, así que estoy muy por encima de mi cabeza, ytenerpara que ese depósito de Perforce vuelva a estar en línea. Todo está ahí, la máquina de repente se niega a aceptar conexiones (remotas O locales) en 1666 por cualquier motivo. Todos los demás servicios que han estado funcionando correctamente siguen funcionando o han vuelto a funcionar. Es sólo éste.

Respuesta1

Misterio resuelto, por fin.

Esta instalación de Perforce fue una versión de 2021, p4d/2021.2/LINUX26X86_64/2264565 (encontré esto revisando los registros). En algún momento, los paquetes helix/p4 instalados quedaron atrapados en una actualización de apt-get (no deberían haberlo sido, eran descargas e instalaciones manuales de paquetes .deb), y eso puso la última versión 2022 en la máquina.

Resulta que la última versión de Perforce Server no funciona en esa máquina antigua, o tal vez es que no funciona en Ubuntu 18.04. De cualquier manera, la instalación de una versión de principios de 2021 funcionó. Y, de hecho, puede colocar todos los archivos del depósito desde una copia de seguridad del depósito en un depósito nuevo y vacío, y funcionará.

Los 5 días más desconcertantes que he pasado trabajando en una línea de comando.

información relacionada