You are not logged in.
I followed instructions from https://cockpit-project.org/running#archlinux:
sudo pacman -S cockpit
sudo systemctl enable --now cockpit.socket
It appears there is more that goes on behind the scenes to get cockpit working. The socket is supposed to listen for incoming connections, and then startup other cockpit related services. When I tail the logs for cockpit.service, it says this upon URL requests:
[root@archlinux cockpit]# journalctl -u cockpit -f
Dec 03 13:21:40 archlinux systemd[1]: Starting Cockpit Web Service...
Dec 03 13:21:40 archlinux systemd[1]: Started Cockpit Web Service.
Dec 03 13:21:40 archlinux cockpit-tls[64890]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Dec 03 13:21:40 archlinux cockpit-tls[64890]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Dec 03 13:21:40 archlinux cockpit-tls[64890]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Dec 03 13:21:40 archlinux cockpit-tls[64890]: cockpit-tls: connect(https-factory.sock) failed: Connection refused
If I manually start this service:
systemctl start cockpit-wsinstance-https-factory.socket
I can get to the cockput gui in a browser, but I am unable to enable this cockpit-wsinstance-https-factory.socket:
[root@archlinux cockpit]# systemctl enable cockpit-wsinstance-https-factory.socket
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Has anyone been able to get this working or know what is going wrong? I just wanted to play around with cockpit, not sure if I would actually want it all the time.
Thanks in advance.
Offline
Not sure but quote below may be helpful for the TLS issues, quoted from cockpit's project guide pages
The cockpit-tls program expects the RUNTIME_DIRECTORY environment variable to be set to an empty directory (preferably in /run/) that is only accessible by the system user under which it is running. This contains the Unix sockets for communicating with the cockpit-ws instances, and in the future, state information about client certificates. This variable is normally set by the cockpit.service systemd unit.
In addition, cockpit-tls will use the XDG_CONFIG_DIRS environment variable from the XDG basedir spec to find its certificates and the cockpit.conf(5) configuration file.
"the wind-blown way, wanna win? don't play"
Offline
I think the TLS messages are more of a warning, as they still occur when I manually startup that secondary service which makes it work.
Offline
I must of tried to get this working awhile ago and had some old systemd unit files leftover in /etc/systemd/system that I cleared out and reinstalled and it is back to working again. I think the issue may have been that I had a non-standard port configured likely using a drop-in unit but I needed to do a full override to configure the non-standard port. I say this after reading this off their https://cockpit-project.org/guide/133/listen.html:
... systemd allows multiple Listen directives to be declared in a single socket unit. To change the activation port instead of adding a second port, use a full override unit instead of a snippet.
Offline