cockpit-devel October 2021

cockpit-devel@lists.fedorahosted.org

3 participants
3 discussions

Cockpit 256, cockpit-machines 255
by Jelle van der Waa 27 Oct '21

27 Oct '21

Happy Wednesday! Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from Cockpit version 256, cockpit-machines version 255: https://cockpit-project.org/blog/cockpit-256.html Summary: - Clean up old self-signed certificates - Storage: Add support for Stratis - Cockpit-machines: translation updates Cockpit 256 is available for download here: - source: https://github.com/cockpit-project/cockpit/releases/tag/256 - Fedora 35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d0454f82b0 - Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-42ab01f71d cockpit-machines 255 is available for download here: - source: https://github.com/cockpit-project/cockpit-machines/releases/tag/255 - Fedora 35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cd7d707018 - Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0a0bce1577

1 0

Cockpit 255 and cockpit-machines 254 released
by Martin Pitt 13 Oct '21

13 Oct '21

Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 255: https://cockpit-project.org/blog/cockpit-255.html Summary: - FreeIPA-issued webserver certificates get auto-renewed - Machines: Support configuring static MAC → IP address mappings You can get Cockpit here: http://cockpit-project.org/running.html Cockpit 255 is available in Fedora 34 and 35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7dc34b336a https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7a8407de1 cockpit-machines 254 is available in Fedora 34 and 35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-694efa1097 https://bodhi.fedoraproject.org/updates/FEDORA-2021-7ccf08dbe0 Or download the tarballs here: https://github.com/cockpit-project/cockpit/releases/tag/255 https://github.com/cockpit-project/cockpit-machines/releases/tag/254 Take care, Martin Pitt

1 0

Kerberos principal for SSO and TLS
by Jochen Kellner 12 Oct '21

12 Oct '21

Hello, I'm running a couple of FreeIPA servers as well as some Debian/Ubuntu/Fedora clients and keep poking at cockpit. I've read the documentation at for TLS at https://cockpit-project.org/guide/latest/https.html and SSO at https://cockpit-project.org/guide/latest/sso.html For SSO with FreeIPA the principal is HTTP/server.example.com(a)EXAMPLE.COM. In the keytab /etc/krb5.keytab we only have the principal host/server.example.com(a)EXAMPLE.COM. On the FreeIPA server we have a principal HTTP/server.example.com(a)EXAMPLE.COM. I also use HTTP/ for normal webservers (on non-FreeIPA servers) as well. The keytab for principal HTTP/ on FreeIPA servers is stored in /var/lib/ipa/gssproxy/http.keytab. That file is not accessibly from cockpit (I symlinked it and got an AVC denial). I could copy the file as /etc/cockpit/krb5.keytab and was able to log on with my kerberos ticket without password. Another possibility is to grant permission to retrieve the keytab to get a second copy - but that both needs redoing whenever I refresh the keytabs. What would be needed to use another principal like cockpit/server.example.com(a)EXAMPLE.COM for the keytab? That way each service would use its own principal and keytab and avoid the retrieval and shared use. Do I miss something else and it's not that complex? For TLS the documentation says to generate the TLS certificate with getcert request -f ${CERT_FILE} -k ${KEY_FILE} -D $(hostname --fqdn) -C \ "sed -n w/etc/cockpit/ws-certs.d/50-from-certmonger.cert ${CERT_FILE} \ ${KEY_FILE}" [I did use ipa-getcert...] When I do that I get an AVC: type=AVC msg=audit(1633548839.586:8895): avc: denied { create } for pid=836449 comm="sed" name="50-from-certmonger.cert" scontext=system_u: system_r:certmonger_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0 According to https://adam.younglogic.com/2018/02/certmonger-selinux-keystores/ something like making the type of /etc/cockpit/ws-certs.d cert_t instead of etc_t works. After that cockpit didn't restart, because it could not read the certificate. "chgrp cockpit-ws /etc/cockpit/ws-certs.d/50-from-certmonger.cert" and "chmod g+r /etc/cockpit/ws-certs.d/50-from-certmonger.cert" finally made cockpit running again. Is that something that should be documented or better added to the cockpit packaging? I'll most likely drop the sed command and the permission fixup in a script in /usr/libexec/certmonger to fix it up. I've used "-K cockpit/$(hostname --fqdn)" as a parameter to ipa-getcert, so the certificate is attached to that service. That way I have no conflict with host certificates or a certificate attached to the HTTP/ principal. That way both the certificate and the keytab are attached to the same cockpit/ principal without interferring with HTTP/ services. Am I on the right track here or do I miss a simpler way? Jochen -- This space is intentionally left blank.

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

cockpit-devel October 2021