Another option is to leave the VARIANT same, but introduce a new var like
MANAGED= and then key of that for cockpit vs Ansible vs Puppet, etc.
On Oct 20, 2016 11:07, "Stephen John Smoogen" <smooge(a)gmail.com> wrote:
On 20 October 2016 at 09:37, Major Hayden <major(a)mhtx.net> wrote:
On 10/20/2016 07:32 AM, Stephen Gallagher wrote:
> * Create two variants for use with /etc/os-release such as
> and `VARIANT_ID=server-gui`. This would allow us to deliver a
> systemd presets and firewall configuration to the system. If the
> installed later, the administrator would need to explicitly
> cockpit.socket and grant firewall permission to allow it as a separate
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
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
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
> Major Hayden
> server mailing list -- server(a)lists.fedoraproject.org
> To unsubscribe send an email to server-leave(a)lists.fedoraproject.org
Stephen J Smoogen.
server mailing list -- server(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)lists.fedoraproject.org