У меня есть сервер под управлением Ubuntu Server 18.04, и это локальный сервер, на котором размещаются общий ресурс Samba, медиасервер и сервер Perforce. Я подключаюсь к этому хранилищу через IP-адрес локальной сети (ssl:192.xxx:1666). Все работало отлично, пока...
...Я также пытался добавить установку wiki.js. Было много переборов пакетов и конфигураций. Apache был удален, wiki.js / mongodb / mariadb / postgresql были разбросаны и удалены не один раз, а nginx был установлен и вырван много раз.
Вот почему - (контекст того, что я задумал)вероятновызвало это):
У меня есть DNS-фильтрация для всей сети через PiHole, и с ее помощью я создал локальные DNS-имена и записи CNAME для различных процессов на этом сервере Ubuntu. Идея заключалась в том, что я мог бы указать клиентской машине в другом месте сети, скажем, "perforce.RackServer.net" вместо "192.168.0.x:1666" и получить тот же результат с некоторым обратным проксированием nginx. Мы пытались сделать адресацию понятной для человека, вместо того, чтобы каждый спрашивал у меня IP-адреса и номера портов для всего.
Я сделалнетуспешно настроил nginx. Сейчас он удален. Ничего страшного, я вернусь к нему позже. Вот в чем проблема.
Где-то во всем этом что-то с конфигурацией сети (на машине есть eth0 и eth1) сломалось, и теперь, когда я пытаюсь
#sudo systemctl start helix-p4dctl.service
я получил
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.
Проверка статуса systemctl дает мне:
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.
Это похоже на ошибку, которую я получаю сейчас при попытке удаленного подключения с помощью визуального клиента p4v:
Connect to server failed; check $P4PORT.
connect: 192.168.0.117:1666: Connection refused
Проверка переменной среды P4PORT на сервере дает мне:
...ничего. Это ДОЛЖНО быть ssl:1666 или просто 1666. Раньше было так, до сих пор. Так что если я устанавливаю это так, как должно быть с
export $P4PORT=ssl:1666
а затем пытаюсь запустить службу, получаю ту же ошибку, что и в первый раз.
Давайте проверим фактическое соединение...
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
То же самое с:
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
И:
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 не показывает, что 1666 открыт...
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
Вот ifconfig, просто для справки.
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
На самом деле, я не специалист по сетевому маркетингу, и я все еще изучаю *nix, так что я влип в это, и яиметьчтобы вернуть Perforce depot в онлайн. Все на месте, машина просто внезапно отказывается принимать соединения — удаленные ИЛИ локальные — на 1666 по какой-то причине. Все остальные службы, которые работали правильно, либо продолжают работать, либо снова работают. Это только одна.
решение1
Тайна наконец-то раскрыта.
Эта установка Perforce была выпущена в 2021 году, p4d/2021.2/LINUX26X86_64/2264565 (я нашел это, просматривая логи). В какой-то момент установленные пакеты helix / p4 попали в обновление apt-get (они не должны были попасть, они были ручными загрузками и установками пакетов .deb), и это установило на машину последнюю версию 2022 года.
Оказывается, последняя версия Perforce Server не работает на этой старой машине, или, может быть, она не работает на Ubuntu 18.04. В любом случае, установка раннего релиза 2021 года сработала. И вы можете — на самом деле — перенести все файлы depot из резервной копии depot в новый, пустой depot, и это будет работать.
Самые трудные 5 дней, которые я когда-либо проводил, разбираясь с командной строкой.