One thing that I thought of while writing up my overseer email was this: We decided a couple weeks ago that the plan for Fedora 26 was to deliver two slightly different versions of Fedora Server: one with a GUI (Cockpit) and one that only included the capability for another Cockpit instance to manage it. This implies that we need two different default firewall configurations; one for Server w/ GUI and one without.[1]
I see two ways that we could accomplish this:
* Create two variants for use with /etc/os-release such as `VARIANT_ID=server` and `VARIANT_ID=server-gui`. This would allow us to deliver a different default systemd presets and firewall configuration to the system. If the Cockpit GUI was installed later, the administrator would need to explicitly enable cockpit.socket and grant firewall permission to allow it as a separate action.
* Create a helper systemd service that would run as a dependency of the cockpit.socket service and open the firewall while that service is running. (This helper could be installed as part of the fedora-release-server package, so it wouldn't take effect on systems that aren't Fedora Server).
I'm leaning towards the second one (though I'll probably have to come up with new packaging guidelines for how it would work). My concern with this option is that it *is* a deviation from how Fedora generally handles the installation of services; normally installation and starting them are independent. That said, I think an argument can be made that if someone is installing `cockpit-ws` on a Fedora Server system, we can make an assumption that they intend to use it to manage that system.
I don't really like the first option because I'm worried that it will set a precedent that will lead to a combinatorial explosion of variants we need to test. But it *does* give us the option to avoid auto-starting cockpit-ws if we install it later.
Other ideas are of course most welcome.
[1] This is because Cockpit operates on a non-privileged port (9090) and therefore if we leave this port available by default, there's an opportunity for a user process to claim it.
On 10/20/2016 07:32 AM, Stephen Gallagher wrote:
- Create two variants for use with /etc/os-release such as `VARIANT_ID=server`
and `VARIANT_ID=server-gui`. This would allow us to deliver a different default systemd presets and firewall configuration to the system. If the Cockpit GUI was installed later, the administrator would need to explicitly enable cockpit.socket and grant firewall permission to allow it as a separate action.
I lean toward this option because it follows some of the existing processes and it won't create any unexpected firewall changes when the cockpit service is installed or started. For example, if a user installs httpd, they will need to open their own firewall ports after they start the service.
-- Major Hayden
On 20 October 2016 at 09:37, Major Hayden major@mhtx.net wrote:
On 10/20/2016 07:32 AM, Stephen Gallagher wrote:
- Create two variants for use with /etc/os-release such as `VARIANT_ID=server`
and `VARIANT_ID=server-gui`. This would allow us to deliver a different default systemd presets and firewall configuration to the system. If the Cockpit GUI was installed later, the administrator would need to explicitly enable cockpit.socket and grant firewall permission to allow it as a separate action.
I lean toward this option because it follows some of the existing processes and it won't create any unexpected firewall changes when the cockpit service is installed or started. For example, if a user installs httpd, they will need to open their own firewall ports after they start the service.
I am going to lean towards this one also because while we can 'assume' that a person installed cockpit-server to have it active, it isn't what most cranky old sysadmins expect. They expect to be able to install a package and then tomorrow or 10 months later set it up and work and not have to worry about it running or changing their security posture by turning on ports and services they didn't realize it would until they read it.
If we go with the second option there are some paths which we could do with it. 1. Turned off by default. Put it in the manual that to turn it on you do a systemctl <blah> and it will all start working. 2. Turn on by default and document the hell out of it with "Install this and you will have services started up on your server.. We warned you."
-- Major Hayden
server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org
server@lists.fedoraproject.org