|Summary:||Fedora Server: Cockpit installed and socket enabled by default|
|Product:||[Fedora] Fedora||Reporter:||Stef Walter <stefw>|
|Component:||cockpit||Assignee:||Patrick Uiterwijk <puiterwijk>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||awilliam, dennis, mattdm, mitr, notting, puiterwijk, robatino, sgallagh, stefw|
|Fixed In Version:||cockpit-0.16-2.fc21||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-07-30 20:56:50 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1043119, 1091301, 1108258|
Description Stef Walter 2014-06-18 11:49:03 UTC
On Fedora Server 21, Cockpit should be installed and have it's systemd socket enabled by default. This will allow it to start when it's TCP port is accessed.
Comment 1 Dennis Gilmore 2014-06-18 15:42:34 UTC
http://fedoraproject.org/wiki/Starting_services_by_default you will need to file a FESCo exception to be allowed to be on by default. as to including by default it just needs added to comps. though we have not yet decided how to differentiate the products.
Comment 2 Stephen Gallagher 2014-06-19 14:08:21 UTC
Dennis, FESCo already approved this exception for Cockpit as part of Cockpit's Change Proposal for Fedora 21. The appropriate tracker bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1091301 In order to track different products' capabilities, it looks like we're likely going to add a new fedora-release-$PRODUCT component (and package) to handle them. Until that happens, the 'distribution' component is probably the most appropriate. I've opened FESCo ticket https://fedorahosted.org/fesco/ticket/1314 to track getting a blanket approval for the Product WGs to make start-up decisions on their own.
Comment 3 Miloslav Trmač 2014-07-21 19:22:02 UTC
All the individual pieces are in place, but they don’t work together: there is a preset for cockpit._socket_, but cockpit’s scripts refer to cockpit._service_. AFAICT (also per the title of this bug), the right way to fix it is s/\.service/\.socket/ in cockpit’s scriptlets
Comment 4 Stef Walter 2014-07-22 10:38:11 UTC
Thanks mitr, made that change.
Comment 5 Adam Williamson 2014-07-23 16:17:00 UTC
Discussed at 2014-07-23 Alpha blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-07-23/f21-blocker-review.2014-07-23-15.59.log.txt . Accepted as a blocker per criterion "Unless explicitly specified otherwise, after system installation the Cockpit web management interface must be running and accessible on its default port (XX).", https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Cockpit_management_interface .
Comment 6 Adam Williamson 2014-07-30 16:53:26 UTC
F21 is not gated via bodhi yet, so the fixed build is already in 'stable', indeed we're one build further along - 0.17-1 , http://koji.fedoraproject.org/koji/buildinfo?buildID=547636 - and on the way to 0.18-1 - http://koji.fedoraproject.org/koji/buildinfo?buildID=549195 . Can someone please re-test and confirm this is now fixed, pace https://bugzilla.redhat.com/show_bug.cgi?id=1123845 ? thanks.
Comment 7 Stef Walter 2014-07-30 20:28:42 UTC
This seems to work. The following command works: # rpm -ql fedora-release-server /usr/lib/systemd/system-preset/80-server.preset /usr/share/licenses/fedora-release-server /usr/share/licenses/fedora-release-server/LICENSE # cat /usr/lib/systemd/system-preset/80-server.preset # # Fedora Server # # The Cockpit web-based system management console enable cockpit.socket # The Fedora Server Role administration API enable rolekit.service # systemctl disable cockpit.socket cockpit.service Removed symlink /etc/systemd/system/sockets.target.wants/cockpit.socket. # systemctl preset cockpit.socket Created symlink from /etc/systemd/system/sockets.target.wants/cockpit.socket to /usr/lib/systemd/system/cockpit.socket. But I'm not sure how to get to a completely blank install state without spending tons of time staring at yum and screwing around with broken upgrades.
Comment 8 Adam Williamson 2014-07-30 20:56:50 UTC
"wait for a viable TC", basically. unfortunately. let's call this good for now, we can reopen if it still happens with the TC.