Is there a non-obvious effect of changing network from DHCP to Static for Cockpit service?

I’ve enabled Cockpit for a new os install on a headless sandbox server.

First I got the service working on local host. This was easy and it has been running for about a week–permanent between restarts.I’ve followed the instructions to open TCP ports and permissions with firewall-cmd and selinux 2. Selinux is set to enforcing

Finally today, with some trial and error, I was able to remote from another computer on the local network, using SSH key authentication (see note #1 below for what I think fixed it)

Up to now I had been using DHCP on both my client personal computer and this new sandbox server, Because I want to limit access to the server only through my client pc, I switched over to static:

/etc/sysconfig/network-scripts/ifcfg-eno1
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="none"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPADDR="192.168.0.5"
PREFIX="24"
GATEWAY="192.168.0.1"
DNS1="8.8.8.8"
DNS1="8.8.4.4"
NAME="eno1"
UUID="[stuff here]"
DEVICE="eno1"
ONBOOT="yes"

I brought networking down and then back up.
$ sudo nmcli connection down eno1 && sudo nmcli connection up eno1

No obvious problems. I can ping google DNS, I can browse the net, and I can SSH from my client PC into the Sandbox Server. What I can’t do is login using Cockpit. The service is Kaput, and I can’t get it to restart.

The cockpit service shows status failed:

 systemctl status cockpit.socket
[sudo] password for snagglepuss:
● cockpit.socket - Cockpit Web Service Socket
   Loaded: loaded (/usr/lib/systemd/system/cockpit.socket; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/cockpit.socket.d
           └─listen.conf
   Active: failed (Result: resources) since Mon 2019-11-11 17:43:37 EST; 4h 8min ago
     Docs: man:cockpit-ws(8)
   Listen: 192.168.0.6:9090 (Stream)
           192.168.0.5:9090 (Stream)
  Process: 4995 ExecStopPost=/bin/ln -snf /usr/share/cockpit/motd/inactive.motd /run/cockpit/motd (code=exited, status=0/SUCCESS)
Nov 11 17:43:37 durian systemd[1]: Starting Cockpit Web Service Socket.
Nov 11 17:43:37 durian systemd[1]: cockpit.socket: Failed with result 'resources'.
Nov 11 17:43:37 durian systemd[1]: Failed to listen on Cockpit Web Service Socket.

Of course I checked the cockpit conf files that I didn’t accidentally enter the wrong IP information:

/etc/systemd/system/cockpit.socket.d/listen.conf
[Socket]
ListenStream=
ListenStream=192.168.0.5:9090
ListenStream=192.168.0.6:9090

/etc/cockpit/cockpit.conf
[WebService]
Origins = https://192.168.0.6:9090 https://192.168.0.5:9090
AllowUnencrypted = False

I’ve tried to restart the service:

$ sudo systemctl restart cockpit
A dependency job for cockpit.service failed. See 'journalctl -xe' for details.

Following breadcrumbs…

journalctl -xe
Nov 12 08:02:15 durian systemd[1]: Failed to listen on Cockpit Web Service Socket.
    -- Subject: Unit cockpit.socket has failed
    -- Defined-By: systemd
    -- Support: https://access.redhat.com/support
    --
    -- Unit cockpit.socket has failed.
    --
    -- The result is RESULT.
    Nov 12 08:02:15 durian systemd[1]: Dependency failed for Cockpit Web Service.
    -- Subject: Unit cockpit.service has failed
    -- Defined-By: systemd
    -- Support: https://access.redhat.com/support
    --
    -- Unit cockpit.service has failed.
    --
    -- The result is RESULT.
    Nov 12 08:02:15 durian systemd[1]: cockpit.service: Job cockpit.service/start failed with result 'dependency'.
    Nov 12 08:02:15 durian systemd[1]: Starting Cockpit motd updater service...
    -- Subject: Unit cockpit-motd.service has begun start-up
    -- Defined-By: systemd
    -- Support: https://access.redhat.com/support
    --
    -- Unit cockpit-motd.service has begun starting up.
    Nov 12 08:02:15 durian sudo[11657]: pam_unix(sudo:session): session closed for user root
    Nov 12 08:02:15 durian systemd[1]: Started Cockpit motd updater service.
    -- Subject: Unit cockpit-motd.service has finished start-up
    -- Defined-By: systemd
    -- Support: https://access.redhat.com/support
    --
    -- Unit cockpit-motd.service has finished starting up.
    --
    -- The start-up result is RESULT.
    Nov 12 08:04:30 durian sudo[11690]: snagglepuss : TTY=pts/0 ; PWD=/home/snagglepuss ; USER=root ; COMMAND=/bin/journalctl -xe
    Nov 12 08:04:30 durian sudo[11690]: pam_systemd(sudo:session): Cannot create session: Already running in a session or user slice
    Nov 12 08:04:30 durian sudo[11690]: pam_unix(sudo:session): session opened for user root by snagglepuss(uid=0)

This gives reason: Dependency failed for Cockpit Web Service
Evidently ome other service is failing and with more time I will find it.
Maybe it’s related to SELinux (most inexplicable problems get back to SELinux for me).

I checked sealert:

sealert -a /var/log/audit/audit.log
100% done
found 0 alerts in /var/log/audit/audit.log

Next, I will work though this fedoraproject troubleshooting page: Debugging systemd problems, but maybe someone else has had this problem or understand how changing from DHCP to Static would cause Cockpit service to fail?


[1]: Right now I’m guessing it was the mix of localhost and the LAN IP because of something in Cockpit docs: “By default cockpit will not accept crossdomain websocket connections. Use this setting to allow access from alternate domains. Origins should include scheme, host and port, if necessary” (https://cockpit-project.org/guide/latest/cockpit.conf.5.html) I dunno, but after I changed this I was able to remote in from client PC.

1 Like

Binding to a specific interface/address usually makes more problems than it solves due to race conditions.
Nowadays you should use either firewall or zero trust model to provide network access management.
If you really need interface binding, better use the loopback interface which should initialize fast enough to not lead to a race condition, otherwise your units should depend on network-online.target.

I think you’re saying several things at once here. Allow me to parse it out inline.

Regarding my Cockpit config files,

/etc/systemd/system/cockpit.socket.d/listen.conf
/etc/cockpit/cockpit.conf

I should just use loopback settings (127.0.0.1:9090) or don’t bind to specific LAN address. (just use 9090?)

To only permit Cockpit to work with a specific LAN address I should use firewall to deny all connections except from a specific LAN address

Regarding the error, Dependency failed for Cockpit Web Service,

Do I understand you correctly?