5:04 a.m.
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:
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(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
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.
7:05 a.m.
New subject: Default Firewall in Fedora Server 26
On 10/27/2016 06:04 AM, Subhendu Ghosh wrote:
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.
The issue here is entirely one of the default firewall, which is delivered as a
single XML file at install-time. (Modifications can be made after the fact,
which is the point of option 2 in my original message).
Right now, we have a policy[1] on how to get different defaults landed on the
system for different install targets. This is all predicated on having different
VARIANT_ID values that triggers the installation of the correct file.
In any case, adding MANAGED to os-release would be an incorrect use of that
file. The purpose of it is to indicate vendor-provided data about a system.
MANAGED would be deployment-specific.
[1] https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
8:20 a.m.
New subject: Default Firewall in Fedora Server 26
On Oct 27, 2016 8:05 AM, "Stephen Gallagher" <sgallagh(a)redhat.com> wrote:
On 10/27/2016 06:04 AM, Subhendu Ghosh wrote:
> 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.
>
The issue here is entirely one of the default firewall, which is
delivered as a
single XML file at install-time. (Modifications can be made after the
fact,
which is the point of option 2 in my original message).
Right now, we have a policy[1] on how to get different defaults landed on
the
system for different install targets. This is all predicated on
having
different
VARIANT_ID values that triggers the installation of the correct
file.
In any case, adding MANAGED to os-release would be an incorrect use of
that
file. The purpose of it is to indicate vendor-provided data about a
system.
MANAGED would be deployment-specific.
[1] https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
Having a Variant for every configuration flavor shipped by the vendor seems
wrong. It will cause variant sprawl.
The variant is the product, the different pre-defined configurations do
not make them different products. There should be a second marker for the
flavor of the product.
8:30 a.m.
New subject: Default Firewall in Fedora Server 26
On 10/27/2016 09:20 AM, Subhendu Ghosh wrote:
Having a Variant for every configuration flavor shipped by the vendor
seems
wrong. It will cause variant sprawl.
The variant is the product, the different pre-defined configurations do not
make them different products. There should be a second marker for the flavor of
the product.
Well, that's actually the point of Variant. The *product* is "Fedora". The
pre-defined configuration is "Server Edition".
8:36 a.m.
New subject: Default Firewall in Fedora Server 26
On Thu, Oct 27, 2016 at 09:30:48AM -0400, Stephen Gallagher wrote:
> The variant is the product, the different pre-defined
configurations do not
> make them different products. There should be a second marker for the flavor of
> the product.
Well, that's actually the point of Variant. The *product* is "Fedora". The
pre-defined configuration is "Server Edition".
Another possibility would be to push the divergence up a level, and
make "Fedora Server" the product and have different variants within
that.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:42 a.m.
New subject: Default Firewall in Fedora Server 26
On 10/27/2016 09:36 AM, Matthew Miller wrote:
On Thu, Oct 27, 2016 at 09:30:48AM -0400, Stephen Gallagher wrote:
>> The variant is the product, the different pre-defined configurations do not
>> make them different products. There should be a second marker for the flavor of
>> the product.
> Well, that's actually the point of Variant. The *product* is "Fedora".
The
> pre-defined configuration is "Server Edition".
Another possibility would be to push the divergence up a level, and
make "Fedora Server" the product and have different variants within
that.
That would be remarkably difficult to accomplish, as plenty of stuff in the
distribution (and third-party) keys off of `ID=fedora` vs. `ID=ubuntu`, etc.
4:58 p.m.
New subject: Default Firewall in Fedora Server 26
In the RHEL world that is not true.
On Oct 27, 2016 09:31, "Stephen Gallagher" <sgallagh(a)redhat.com> wrote:
On 10/27/2016 09:20 AM, Subhendu Ghosh wrote:
> Having a Variant for every configuration flavor shipped by the vendor
seems
> wrong. It will cause variant sprawl.
>
> The variant is the product, the different pre-defined configurations do
not
> make them different products. There should be a second marker for the
flavor of
> the product.
Well, that's actually the point of Variant. The *product* is "Fedora". The
pre-defined configuration is "Server Edition".
_______________________________________________
server mailing list -- server(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)lists.fedoraproject.org
2737
days inactive
2737
days old
server@lists.fedoraproject.org
6 comments
3 participants
participants (3)
-
Matthew Miller -
Stephen Gallagher -
Subhendu Ghosh