Ich habe einen Server, auf dem Ubuntu Server 18.04 läuft. Es handelt sich um den lokalen Catch-All-Server – er hostet eine Samba-Freigabe, einen Medienserver und einen Perforce-Server. Ich verbinde mich mit diesem Depot über eine lokale Netzwerk-IP (ssl:192.xxx:1666). Alles hat wunderbar funktioniert, bis …
...Ich habe auch versucht, eine Wiki.js-Installation hinzuzufügen. Es gab jede Menge Paket- und Konfigurations-Thrashing. Apache wurde entfernt, Wiki.js / MongoDB / MariaDB / PostgreSQL wurden alle durcheinandergebracht und mehr als einmal gelöscht, und Nginx wurde viele Male installiert und wieder entfernt.
Hier ist der Grund - (Kontext für das, was ich damals vorhattewahrscheinlichhat dies verursacht):
Ich habe DNS-Filter für das gesamte Netzwerk über PiHole und damit lokale DNS-Namen und CNAME-Einträge für die verschiedenen Prozesse auf diesem Ubuntu-Server erstellt. Die Idee war, dass ich einen Client-Rechner an einer anderen Stelle im Netzwerk beispielsweise auf „perforce.RackServer.net“ statt auf „192.168.0.x:1666“ verweisen und mit etwas Reverse-Proxying durch nginx dasselbe Ergebnis erzielen könnte. Wir haben versucht, die Adressierung für Menschen lesbar zu machen, anstatt dass mich jeder für alles nach IPs und Portnummern fragen muss.
Ich tatnichtIch habe nginx erfolgreich eingerichtet. Es ist jetzt deinstalliert. Das ist in Ordnung – ich werde später darauf zurückkommen. Hier ist das Problem.
Irgendwo in all dem ist etwas mit der Netzwerkkonfiguration (die Maschine hat eth0 und eth1) durcheinander geraten, und jetzt, wenn ich versuche
#sudo systemctl start helix-p4dctl.service
Ich bekomme
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.
Eine Systemctl-Statusprüfung davon gibt mir:
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.
Das ähnelt dem Fehler, den ich jetzt erhalte, wenn ich versuche, eine Remoteverbindung mit dem visuellen p4v-Client herzustellen:
Connect to server failed; check $P4PORT.
connect: 192.168.0.117:1666: Connection refused
Das Überprüfen der Umgebungsvariable P4PORT auf dem Server ergibt:
...nichts. Es SOLLTE ssl:1666 oder einfach 1666 sein. Das war es bis jetzt. Wenn ich das also auf den gewünschten Wert einstelle,
export $P4PORT=ssl:1666
und dann versuche ich, den Dienst zu starten. Ich erhalte die gleiche Fehlermeldung wie beim ersten Mal.
Lassen Sie uns die tatsächliche Verbindung überprüfen ...
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
Das gleiche mit:
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
Und:
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
Nmap zeigt jedoch 1666 nicht geöffnet an ...
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
Hier ist die ifconfig, nur als Referenz.
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
Ich bin eigentlich kein Networking-Typ von Beruf - und ich lerne immer noch *nix - also bin ich völlig überfordert, und ichhabenum das Perforce-Depot wieder online zu bringen. Alles ist da, die Maschine weigert sich nur plötzlich, Verbindungen – remote ODER lokal – auf 1666 anzunehmen, aus welchem Grund auch immer. Alle anderen Dienste, die ordnungsgemäß funktioniert haben, funktionieren entweder noch oder wieder. Es ist nur dieser eine.
Antwort1
Das Rätsel ist endlich gelöst.
Diese Perforce-Installation war eine Version von 2021, p4d/2021.2/LINUX26X86_64/2264565 (ich habe das beim Durchsehen der Protokolle gefunden). Irgendwann gerieten die installierten Helix-/P4-Pakete in ein Apt-Get-Upgrade (das hätte nicht passieren dürfen, es handelte sich um manuelle Downloads und Installationen von .deb-Paketen), und das brachte die neueste Version von 2022 auf den Rechner.
Es stellte sich heraus, dass die neueste Perforce Server-Version auf dieser alten Maschine nicht funktioniert, oder vielleicht liegt es daran, dass sie unter Ubuntu 18.04 nicht funktioniert. So oder so hat die Installation einer frühen Version von 2021 funktioniert. Und Sie können tatsächlich alle Depotdateien aus einem Depot-Backup in ein neues, leeres Depot ziehen, und es wird funktionieren.
Die rätselhaftesten fünf Tage, die ich je damit verbracht habe, an einer Befehlszeile herumzubasteln.