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.
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.
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.
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)"
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?
(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.
(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.
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).
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.
build has been done already
should this be in ON_QA? did we pull the builds into TC4?
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!
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).
Confirmed fixed in TC6, the Server config is applied and port 9090 is allowed. The update has gone stable, so closing.