Bug 1204739 - Installing Fedora Server netinst ends up with blocked Cockpit port
Summary: Installing Fedora Server netinst ends up with blocked Cockpit port
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dennis Gilmore
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Keywords:
Depends On: 1146487
Blocks: F22BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2015-03-23 12:46 UTC by Marius Vollmer
Modified: 2015-04-01 23:37 UTC (History)
10 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-04-01 23:37:51 UTC


Attachments (Terms of Use)

Description Marius Vollmer 2015-03-23 12:46:45 UTC
Description of problem:

Installing Fedora-Server-netinst-x86_64-22_Alpha.iso into a VM has given me a machine that had the Cockpit port 9090 blocked by the firewall.  I was expecting it to be open by default.

I believe that was because the firewalld zone was "public" instead of "FedoraServer".

I had installed another VM from some other Fedora 22 image, and it was correctly using the "FedoraServer" zone.  That machine was installed as a minimal install and then converted to a Server product by installing the fedora-release-server package.

Comment 1 David Shea 2015-03-23 13:42:09 UTC
Which environment did you select in the software selection spoke? Was fedora-productimg-server installed? Please attach the log files from the installation, which are available in /var/log/anaconda on the installed system.

Comment 2 Stephen Gallagher 2015-03-23 13:56:44 UTC
This is because a recent firewalld update went stable without a corresponding change to the fedora-release package.

We modified how the default configuration gets deployed, but the fedora-release change is needed for firewalld to detect it correctly.

Comment 3 Fedora Blocker Bugs Application 2015-03-23 14:01:06 UTC
Proposed as a Blocker for 22-beta by Fedora user sgallagh using the blocker tracking app because:

 "After system installation without explicit firewall configuration, the system firewall must be active on all non-loopback interfaces. The only ports which may be open to incoming traffic are port 22 (ssh), port 9090 (Cockpit web interface)"

Comment 4 Stephen Gallagher 2015-03-23 14:24:27 UTC
This is also a potential issue for the Cockpit Test Day tomorrow.

Dennis, can we get the fedora-release backport in today so it can be incorporated into the Test Day images?

Comment 5 Marius Vollmer 2015-03-23 14:26:19 UTC
(In reply to David Shea from comment #1)
> Which environment did you select in the software selection spoke?

I left everything at their defaults, as far as possible.  "Fedora Server" was correctly preselected.

Comment 6 Marius Vollmer 2015-03-23 14:28:43 UTC
(In reply to Stephen Gallagher from comment #4)
> This is also a potential issue for the Cockpit Test Day tomorrow.

We have instructions on our page to open the firewall.  So I think people will be OK.

Comment 7 Stephen Gallagher 2015-03-23 14:53:33 UTC
For a more complete explanation:

We have changed the way that Fedora is going to handle per-product differentiation by having packages read from /etc/os-release for the VARIANT=[Workstation|Cloud|Server] and use that to base its decision. This is instead of the Fedora 21 approach which required the use of multiple conflicting release packages that caused issues with installing yum environment groups post-install.

Firewalld was updated to rely on the os-release VARIANT to determine its default configuration, but the fedora-release package hasn't been updated to provide it yet. Hence, Firewalld defaults to its most restrictive settings (the set that it would get from a non-productized Fedora).

Comment 8 Adam Williamson 2015-03-23 16:27:56 UTC
Discussed at 2015-03-23 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-23/f22-blocker-review.2015-03-23-16.02.log.txt . Accepted as a Beta blocker per criterion cited in #c7.

Comment 9 Dennis Gilmore 2015-03-24 16:48:31 UTC
build has been done already

Comment 10 Adam Williamson 2015-03-26 01:18:46 UTC
should this be in ON_QA? did we pull the builds into TC4?

Comment 11 Adam Williamson 2015-03-26 05:41:34 UTC
From the looks of things, https://admin.fedoraproject.org/updates/fedora-release-22-0.14 is intended to fix this, but it's not marked as fixing this bug and so I didn't include it in the TC4 or TC5 requests. Moving bug to ON_QA, if I'm wrong please adjust as appropriate. Thanks!

Comment 12 Adam Williamson 2015-03-27 00:32:59 UTC
The fix for this is in TC5. However for a while you won't get the fixed fedora-release on a network install, so to be sure you're testing the fix, use the TC5 Server DVD (and check the installed fedora-release-server is 22-0.14.noarch).

Comment 13 Adam Williamson 2015-04-01 23:37:51 UTC
Confirmed fixed in TC6, the Server config is applied and port 9090 is allowed. The update has gone stable, so closing.


Note You need to log in before you can comment on or make changes to this bug.