Server File Diffs to Fedora Rawhide

[Stef Walter]

So this may be obvious to some of you, but how do we handle the case
where installed files need to be different between Fedora Server and
other Fedora flavors?

For example for Cockpit to be installed by default we need to:

* Add the cockpit service to all relevant zone files in
   /usr/lib/firewalld/zones (currently owned by firewalld rpm).
   See 'man firewalld.zone' and 'man firewalld.service'

* /etc/pam/sshd needs an addition module, for Cockpit reauthorize to
   work with added servers. See:

https://github.com/stefwalter/cockpit/blob/reauthorize/doc/reauthorize.md

... and likely others.

So I guess the question is how do we adapt behavior of rpms that are
installed both on Fedora Server *and* on other Fedora flavors.

Follow up question: How would I install Fedora Server today? What and
where are the diffs from the usual Fedora Rawhide represented? Is Fedora
Server still a completely theoretical construct at this point?

Cheers,

Stef

[Kevin Fenzi]

On Fri, 27 Jun 2014 12:36:32 +0200
Stef Walter  wrote:
> So this may be obvious to some of you, but how do we handle the case
> where installed files need to be different between Fedora Server and
> other Fedora flavors?

You try and avoid that. ;)
> For example for Cockpit to be installed by default we need to:
> Add the cockpit service to all relevant zone files in
> /usr/lib/firewalld/zones (currently owned by firewalld rpm).
> See 'man firewalld.zone' and 'man firewalld.service'

Can firewalld just add them conditionally somehow ? 
Or detect cockpit somehow and dynamically add them?
> /etc/pam/sshd needs an addition module, for Cockpit reauthorize to
> work with added servers. See:
>
> https://github.com/stefwalter/cockpit/blob/reauthorize/doc/reauthorize.md
>
> ... and likely others.

ugh.

I suppose rolekit could make these changes when it enables roles?
> So I guess the question is how do we adapt behavior of rpms that are
> installed both on Fedora Server *and* on other Fedora flavors.

You should not and cannot change files in other packages from your
package, thats just a bad idea.
> Follow up question: How would I install Fedora Server today? What and
> where are the diffs from the usual Fedora Rawhide represented? Is
> Fedora Server still a completely theoretical construct at this point?

Yeah, I think we are all still theoretical? Or did we put in an initial
kickstarts? We should do that soon...

kevin

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/27/2014 11:07 AM, Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 12:36:32 +0200 Stef Walter 
> wrote:
> > So this may be obvious to some of you, but how do we handle the
> > case where installed files need to be different between Fedora
> > Server and other Fedora flavors?
>
> You try and avoid that. ;)

We discussed this at length on the Fedora Devel list some months
ago[1]. I'm trying to remember the exact decision we came down to, but
I think that all of the "best" solutions involved carrying certain
virtual Provides: in the fedora-release-$PRODUCTNAME packages and
using the new rich dependencies in RPM to do something like:

foo.spec:
Requires: foo-config-default or foo-config-server or foo-config-cloud
Requires: not fedora-release-server or foo-config-server
Requires: not fedora-release-cloud or foo-config-cloud

foo-config-default.spec:
Conflicts: foo-config-server
Conflicts: foo-config-cloud

foo-config-server.spec:
Conflicts: foo-config-default
Conflicts: foo-config-cloud

foo-config-cloud.spec:
Conflicts: foo-config-default
Conflicts: foo-config-server

So packages would be able to ship different default configuration sets
based on which (if any) of the known Products were installed.

This kind of fell off my radar and I need to pull in Panu and Jan (as
well as the FPC) about coming up with a plan here.
> > For example for Cockpit to be installed by default we need to:
> > Add the cockpit service to all relevant zone files in
> >
> > /usr/lib/firewalld/zones (currently owned by firewalld rpm). See
> > 'man firewalld.zone' and 'man firewalld.service'
>
> Can firewalld just add them conditionally somehow ? Or detect
> cockpit somehow and dynamically add them?
> > /etc/pam/sshd needs an addition module, for Cockpit reauthorize
> >
> > to work with added servers. See:
> >
> > https://github.com/stefwalter/cockpit/blob/reauthorize/doc/reauthorize.md

... and likely others.
> ugh.
>
> I suppose rolekit could make these changes when it enables roles?
> > So I guess the question is how do we adapt behavior of rpms that
> > are installed both on Fedora Server *and* on other Fedora
> > flavors.
>
> You should not and cannot change files in other packages from your 
> package, thats just a bad idea.
> > Follow up question: How would I install Fedora Server today? What
> > and where are the diffs from the usual Fedora Rawhide
> > represented? Is Fedora Server still a completely theoretical
> > construct at this point?
>
> Yeah, I think we are all still theoretical? Or did we put in an
> initial kickstarts? We should do that soon...

[1] https://lists.fedoraproject.org/pipermail/devel/2014-March/196546.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlOtkAAACgkQeiVVYja6o6OAmACgn5Zei2S6uO8JLPLYiMQCsDP7
> c/IAnjR9yKQXyCPjOw2FPVymoiKHtK8w
> =sQWi
> -----END PGP SIGNATURE-----

[Thomas Woerner]

On 06/27/2014 05:07 PM, Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 12:36:32 +0200
> Stef Walter  wrote:
> > So this may be obvious to some of you, but how do we handle the case
> > where installed files need to be different between Fedora Server and
> > other Fedora flavors?
>
> You try and avoid that. ;)
> > For example for Cockpit to be installed by default we need to:
> > Add the cockpit service to all relevant zone files in
> > /usr/lib/firewalld/zones (currently owned by firewalld rpm).
> > See 'man firewalld.zone' and 'man firewalld.service'
>
> Can firewalld just add them conditionally somehow ?
> Or detect cockpit somehow and dynamically add them?

Adding distribution/package/spin or flavour specific configuration in 
the firewalld code is not what I want to have. This could make behaviour 
and/or code analysis a hard task or impossible.
> > /etc/pam/sshd needs an addition module, for Cockpit reauthorize to
> > work with added servers. See:
> >
> > https://github.com/stefwalter/cockpit/blob/reauthorize/doc/reauthorize.md
> >
> > ... and likely others.
>
> ugh.
>
> I suppose rolekit could make these changes when it enables roles?

I would say a role in rolekit could do this.
> > So I guess the question is how do we adapt behavior of rpms that are
> > installed both on Fedora Server *and* on other Fedora flavors.
>
> You should not and cannot change files in other packages from your
> package, thats just a bad idea.

I suggest to have configuration sub packages for server installs versus 
configuration sub packages for the normal installation.
> > Follow up question: How would I install Fedora Server today? What and
> > where are the diffs from the usual Fedora Rawhide represented? Is
> > Fedora Server still a completely theoretical construct at this point?
>
> Yeah, I think we are all still theoretical? Or did we put in an initial
> kickstarts? We should do that soon...
>
> kevin

Thomas
> server mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/server

[Stef Walter]

On 30.06.2014 13:43, Thomas Woerner wrote:
> On 06/27/2014 05:07 PM, Kevin Fenzi wrote:
> > On Fri, 27 Jun 2014 12:36:32 +0200
> > Stef Walter  wrote:
> > > So this may be obvious to some of you, but how do we handle the case
> > > where installed files need to be different between Fedora Server and
> > > other Fedora flavors?
> >
> > You try and avoid that. ;)
> > > For example for Cockpit to be installed by default we need to:
> > > Add the cockpit service to all relevant zone files in
> > > /usr/lib/firewalld/zones (currently owned by firewalld rpm).
> > > See 'man firewalld.zone' and 'man firewalld.service'
> >
> > Can firewalld just add them conditionally somehow ?
> > Or detect cockpit somehow and dynamically add them?
>
> Adding distribution/package/spin or flavour specific configuration in
> the firewalld code is not what I want to have. This could make behaviour
> and/or code analysis a hard task or impossible.
> > > /etc/pam/sshd needs an addition module, for Cockpit reauthorize to
> > > work with added servers. See:
> > >
> > > https://github.com/stefwalter/cockpit/blob/reauthorize/doc/reauthorize.md
> > >
> > > ... and likely others.
> >
> > ugh.
> >
> > I suppose rolekit could make these changes when it enables roles?
>
> I would say a role in rolekit could do this.

"Fedora Server" is not a role, and neither is "Cockpit".

For this particular case, I've sent an email to the openssh maintainer
to see if perhaps we can have an optional pam.d include that we then
populate.
> > > So I guess the question is how do we adapt behavior of rpms that are
> > > installed both on Fedora Server *and* on other Fedora flavors.
> >
> > You should not and cannot change files in other packages from your
> > package, thats just a bad idea.
>
> I suggest to have configuration sub packages for server installs versus
> configuration sub packages for the normal installation.

Yes, that sounds like a good solution for firewalld having different
ports open by default on different flavors of Fedora.

Cheers,

Stef

[Simo Sorce]

On Fri, 2014-06-27 at 12:36 +0200, Stef Walter wrote:
> So this may be obvious to some of you, but how do we handle the case
> where installed files need to be different between Fedora Server and
> other Fedora flavors?
>
> For example for Cockpit to be installed by default we need to:
>
> Add the cockpit service to all relevant zone files in
> /usr/lib/firewalld/zones (currently owned by firewalld rpm).
> See 'man firewalld.zone' and 'man firewalld.service'
>
> /etc/pam/sshd needs an addition module, for Cockpit reauthorize to
> work with added servers. See:
>
> https://github.com/stefwalter/cockpit/blob/reauthorize/doc/reauthorize.md
>
> ... and likely others.
>
> So I guess the question is how do we adapt behavior of rpms that are
> installed both on Fedora Server *and* on other Fedora flavors.

So these are basically all configuration items, I can see two ways to go
about this:

1. in the .spec file we have a flavor based conditional that runs
scriplet only if the install target is of the right flavor.
This has the problem that if we allow switching flavor after install I
am not sure there is a way to run the conditional scriplets easily.
yum reinstalling a package after the switch can be considered a
reasonable workaround for F21 ?

2. Drop configuration scripts in some per-flavor area, and have a way to
run these after first-boot or via a yum/dnf plugin that runs at the end
of a transaction ?
This looks more flexible but would also require more infrastructure we
do not have at the moment.
> Follow up question: How would I install Fedora Server today? What and
> where are the diffs from the usual Fedora Rawhide represented? Is Fedora
> Server still a completely theoretical construct at this point?

I do not think we have anything on the ground yet, but we should
certainly start working on it.

Simo.