0

I have a server running Ubuntu server 18.04, and it's the catch-all local server - hosts a samba share, media server, and a Perforce server. I connect to that depot via a local network IP (ssl:192.x.x.x:1666). Everything was working great until...

...I also tried to add a wiki.js install to it. There was a lot of package and config thrashing. Apache got removed, wiki.js / mongodb / mariadb / postgresql all got thrown around and deleted more than once, and nginx got installed and torn out many times.

Here's why - (context for what I was up to that probably caused this):

I have DNS filtering for the whole network via PiHole and with that, I created local DNS names & CNAME entries for the various processes on that Ubuntu server. The idea was I could point a client machine elsewhere in the network to, say, "perforce.RackServer.net" instead of "192.168.0.x:1666" and get the same result with some reverse proxy'ing by nginx. We were trying to make addressing human-readable instead of everyone having to ask me for IPs and port numbers for everything.

I did not have success setting up nginx. It's uninstalled now. That's fine - I'll come back to it later. Here's the problem.

Somewhere in all that, something with the network configuration (the machine has eth0 and eth1) got whacked, and now when I try #sudo systemctl start helix-p4dctl.service

I get

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.

A systemctl status check of that gives me:

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.

That's similar to the error I now get trying to connect remotely with the p4v visual client:
Connect to server failed; check $P4PORT.
connect: 192.168.0.117:1666: Connection refused

Checking the P4PORT environment variable on the server gives me:

...nothing. It SHOULD be ssl:1666 or just 1666. It used to be, until now. So if I set that to what it should be with

export $P4PORT=ssl:1666

and then go try to start the service, I get the same error as the first time.

Let's check the actual connection...

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

Same with: 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

And: 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

However, nmap doesn't show 1666 open... 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

Here's the ifconfig, just for reference.
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

I'm not actually a networking guy by trade - and I'm still learning *nix - so I'm in way over my head, and I have to get that Perforce depot back online. Everything is there, the machine is just suddenly refusing to take connections - remote OR local - on 1666 for whatever reason. All the other services that have been working correctly are either still working or back to working. It's just this one.

1 Answers1

0

Mystery solved, finally.

This Perforce installation was a release from 2021, p4d/2021.2/LINUX26X86_64/2264565 (I found this going through the logs). At some point, the installed helix / p4 packages got caught in an apt-get upgrade (they shouldn't have been, they were manual downloads & installs of .deb packages), and that put the latest 2022 version on the machine.

Turns out, the latest Perforce Server release does not work on that old machine, or maybe it's that it doesn't work on Ubuntu 18.04. Either way, installing an early 2021 release worked. And, you can - in fact - drop all the depot files from a depot backup into a new, empty depot, and it'll work.

Most baffling 5 days I've ever spent beating on a command line.