Bug 1110764

Summary: Fedora Server: Cockpit installed and socket enabled by default
Product: [Fedora] Fedora Reporter: Stef Walter <stefw>
Component: cockpitAssignee: Patrick Uiterwijk <puiterwijk>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: awilliam, dennis, mattdm, mitr, notting, puiterwijk, robatino, sgallagh, stefw
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: cockpit-0.16-2.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-30 20:56:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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

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

  # 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.