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@gmail.com> wrote:
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
>



--
Stephen J Smoogen.
_______________________________________________
server mailing list -- server@lists.fedoraproject.org
To unsubscribe send an email to server-leave@lists.fedoraproject.org