Call for votes: Server Technical Specification

[Stephen Gallagher]

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

https://fedoraproject.org/wiki/Server/Technical_Specification

This document follows the format of the Workstation Technical
Specification. We have discussed many of the points here at length on
the various mailing lists as well as in two IRC working sessions over
the last two days.

FESCo has requested that we submit this document for review by the end
of the day on Monday, March 03rd (to give FESCo time to review it
before the meeting on Wednesday, March 05th).

I have made two additional modifications to the document aside from
what was discussed in the meetings:

1. Based on other conversations on the mailing list and in other IRC
   channels, I propose we punt on the question of supported container
   technology (particularly since our first set of Roles will not use
   containers). We will probably want to revisit a Container Host Role
   for Fedora 22.

2. I have added a first pass at defining the API for the Server Roles
   that will be implemented by the Server SIG alongside the Cockpit
   Project.

What we need right now is a vote of the Server Working Group
membership whether we feel this document is in sufficiently good shape
to send to FESCo, who intends to use it to gauge estimates for the
Fedora 21 schedule. Please cast your votes as soon as possible (I
realize this may mean giving up an hour of your weekend to read the
document). If you have serious concerns, please raise them immediately.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMQ26YACgkQeiVVYja6o6MQgQCeLDSHOLogtA+SNFfhzKAH/id6
> 5jAAn2PgxKXhvHt9g4UIO1glUmEu6I13
> =RRlO
> -----END PGP SIGNATURE-----

[Simo Sorce]

On Fri, 2014-02-28 at 13:55 -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> https://fedoraproject.org/wiki/Server/Technical_Specification
>
> This document follows the format of the Workstation Technical
> Specification. We have discussed many of the points here at length on
> the various mailing lists as well as in two IRC working sessions over
> the last two days.
>
> FESCo has requested that we submit this document for review by the end
> of the day on Monday, March 03rd (to give FESCo time to review it
> before the meeting on Wednesday, March 05th).
>
> I have made two additional modifications to the document aside from
> what was discussed in the meetings:
>
> Based on other conversations on the mailing list and in other IRC
> channels, I propose we punt on the question of supported container
> technology (particularly since our first set of Roles will not use
> containers). We will probably want to revisit a Container Host Role
> for Fedora 22.
>
> I have added a first pass at defining the API for the Server Roles
> that will be implemented by the Server SIG alongside the Cockpit
> Project.
>
> What we need right now is a vote of the Server Working Group
> membership whether we feel this document is in sufficiently good shape
> to send to FESCo, who intends to use it to gauge estimates for the
> Fedora 21 schedule. Please cast your votes as soon as possible (I
> realize this may mean giving up an hour of your weekend to read the
> document). If you have serious concerns, please raise them immediately.

I think the document is in good enough shape to be presented to FESCo
next Monday. +1

Simo.

[Stephen Gallagher]

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

On 02/28/2014 01:55 PM, Stephen Gallagher wrote:
> https://fedoraproject.org/wiki/Server/Technical_Specification
>
> This document follows the format of the Workstation Technical 
> Specification. We have discussed many of the points here at length
> on the various mailing lists as well as in two IRC working sessions
> over the last two days.
>
> FESCo has requested that we submit this document for review by the
> end of the day on Monday, March 03rd (to give FESCo time to review
> it before the meeting on Wednesday, March 05th).
>
> I have made two additional modifications to the document aside
> from what was discussed in the meetings:
> Based on other conversations on the mailing list and in other
>
> IRC channels, I propose we punt on the question of supported
> container technology (particularly since our first set of Roles
> will not use containers). We will probably want to revisit a
> Container Host Role for Fedora 22.
> I have added a first pass at defining the API for the Server
>
> Roles that will be implemented by the Server SIG alongside the
> Cockpit Project.
>
> What we need right now is a vote of the Server Working Group 
> membership whether we feel this document is in sufficiently good
> shape to send to FESCo, who intends to use it to gauge estimates
> for the Fedora 21 schedule. Please cast your votes as soon as
> possible (I realize this may mean giving up an hour of your weekend
> to read the document). If you have serious concerns, please raise
> them immediately.

For the record, I am +1 to this version of the document being sent to
FESCo.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMQ3hEACgkQeiVVYja6o6PFjACgqf1jmJdDqon/XP2sjrGVQRwV
> HYUAn1u1IGYkRahhOrtASrq9qbMwlLe2
> =0/2t
> -----END PGP SIGNATURE-----

[Kevin Fenzi]

On Fri, 28 Feb 2014 13:55:34 -0500
Stephen Gallagher  wrote:

...snip...
> What we need right now is a vote of the Server Working Group
> membership whether we feel this document is in sufficiently good shape
> to send to FESCo, who intends to use it to gauge estimates for the
> Fedora 21 schedule. Please cast your votes as soon as possible (I
> realize this may mean giving up an hour of your weekend to read the
> document). If you have serious concerns, please raise them
> immediately.

In general I am +1 to sending to fesco. ;)

Some minor nits:

* I think we should drop the note about armv8... it not only needs
  hardware available, but promotion from secondary arch, etc. I'd love
  to support it, but I don't think we should try and do so before it's
  been fully brought up.

* I don't know that there are any tech limitations for /boot not on
  lvm. But there's still an important case that needs it: encrypted /

* Did we want to list the media? ie, a network install iso and a non
  network install iso and sizes?

Looks great otherwise, although I am sure we need to flesh it out some
and add things we havent thought of yet. ;)

Thanks for writing things up!

kevin

[Adam Williamson]

On Fri, 2014-02-28 at 13:55 -0500, Stephen Gallagher wrote:
> https://fedoraproject.org/wiki/Server/Technical_Specification
>
> This document follows the format of the Workstation Technical
> Specification. We have discussed many of the points here at length on
> the various mailing lists as well as in two IRC working sessions over
> the last two days.
>
> FESCo has requested that we submit this document for review by the end
> of the day on Monday, March 03rd (to give FESCo time to review it
> before the meeting on Wednesday, March 05th).
>
> I have made two additional modifications to the document aside from
> what was discussed in the meetings:
>
> Based on other conversations on the mailing list and in other IRC
> channels, I propose we punt on the question of supported container
> technology (particularly since our first set of Roles will not use
> containers). We will probably want to revisit a Container Host Role
> for Fedora 22.
>
> I have added a first pass at defining the API for the Server Roles
> that will be implemented by the Server SIG alongside the Cockpit
> Project.
>
> What we need right now is a vote of the Server Working Group
> membership whether we feel this document is in sufficiently good shape
> to send to FESCo, who intends to use it to gauge estimates for the
> Fedora 21 schedule. Please cast your votes as soon as possible (I
> realize this may mean giving up an hour of your weekend to read the
> document). If you have serious concerns, please raise them immediately.

I'd like to see if we can at least reach a consensus with the Desktop WG
on the filesystem question before I vote +1 on this. Josh has said he's
going to take another look at the situation.

[Adam Williamson]

On Fri, 2014-02-28 at 14:48 -0700, Kevin Fenzi wrote:
> I don't know that there are any tech limitations for /boot not on
> lvm. But there's still an important case that needs it: encrypted /

There's some background at
https://bugzilla.redhat.com/show_bug.cgi?id=1036705 and related bugs. As
I understand it, dlehman's current position is that he doesn't believe
LVM devs, btrfs devs etc are sufficiently committed to supporting /boot
on those volumes that it is safe for anaconda to offer this choice. As
of right now, for grub2, anaconda does not allow /boot to be on anything
but a raw partition or a RAID device, and only allows the ext, xfs and
btrfs filesystems. /boot cannot be a btrfs *subvolume*, but it can be
raw partition formatted with the btrfs filesystem (I don't think you can
achieve this with the UI, though, so it's kickstart-only).

[Josh Boyer]

On Fri, Feb 28, 2014 at 6:49 PM, Adam Williamson  wrote:
> On Fri, 2014-02-28 at 13:55 -0500, Stephen Gallagher wrote:
> > https://fedoraproject.org/wiki/Server/Technical_Specification
> >
> > This document follows the format of the Workstation Technical
> > Specification. We have discussed many of the points here at length on
> > the various mailing lists as well as in two IRC working sessions over
> > the last two days.
> >
> > FESCo has requested that we submit this document for review by the end
> > of the day on Monday, March 03rd (to give FESCo time to review it
> > before the meeting on Wednesday, March 05th).
> >
> > I have made two additional modifications to the document aside from
> > what was discussed in the meetings:
> >
> > Based on other conversations on the mailing list and in other IRC
> > channels, I propose we punt on the question of supported container
> > technology (particularly since our first set of Roles will not use
> > containers). We will probably want to revisit a Container Host Role
> > for Fedora 22.
> >
> > I have added a first pass at defining the API for the Server Roles
> > that will be implemented by the Server SIG alongside the Cockpit
> > Project.
> >
> > What we need right now is a vote of the Server Working Group
> > membership whether we feel this document is in sufficiently good shape
> > to send to FESCo, who intends to use it to gauge estimates for the
> > Fedora 21 schedule. Please cast your votes as soon as possible (I
> > realize this may mean giving up an hour of your weekend to read the
> > document). If you have serious concerns, please raise them immediately.
>
> I'd like to see if we can at least reach a consensus with the Desktop WG
> on the filesystem question before I vote +1 on this. Josh has said he's
> going to take another look at the situation.

To be clear, the Workstation WG is looking at delivering a live image
by default.  The live image itself is ext4 on top of a raw DM device.
I am not sure if that can be changed to use XFS instead of ext4, but I
don't think LVM makes sense on the live image itself.  I will be
mostly asking about the "install to hard disk" default path when I
bring it up.

josh

[Adam Williamson]

On Fri, 2014-02-28 at 20:02 -0500, Josh Boyer wrote:
> On Fri, Feb 28, 2014 at 6:49 PM, Adam Williamson  wrote:
> > On Fri, 2014-02-28 at 13:55 -0500, Stephen Gallagher wrote:
> > > https://fedoraproject.org/wiki/Server/Technical_Specification
> > >
> > > This document follows the format of the Workstation Technical
> > > Specification. We have discussed many of the points here at length on
> > > the various mailing lists as well as in two IRC working sessions over
> > > the last two days.
> > >
> > > FESCo has requested that we submit this document for review by the end
> > > of the day on Monday, March 03rd (to give FESCo time to review it
> > > before the meeting on Wednesday, March 05th).
> > >
> > > I have made two additional modifications to the document aside from
> > > what was discussed in the meetings:
> > >
> > > Based on other conversations on the mailing list and in other IRC
> > > channels, I propose we punt on the question of supported container
> > > technology (particularly since our first set of Roles will not use
> > > containers). We will probably want to revisit a Container Host Role
> > > for Fedora 22.
> > >
> > > I have added a first pass at defining the API for the Server Roles
> > > that will be implemented by the Server SIG alongside the Cockpit
> > > Project.
> > >
> > > What we need right now is a vote of the Server Working Group
> > > membership whether we feel this document is in sufficiently good shape
> > > to send to FESCo, who intends to use it to gauge estimates for the
> > > Fedora 21 schedule. Please cast your votes as soon as possible (I
> > > realize this may mean giving up an hour of your weekend to read the
> > > document). If you have serious concerns, please raise them immediately.
> >
> > I'd like to see if we can at least reach a consensus with the Desktop WG
> > on the filesystem question before I vote +1 on this. Josh has said he's
> > going to take another look at the situation.
>
> To be clear, the Workstation WG is looking at delivering a live image
> by default.  The live image itself is ext4 on top of a raw DM device.
> I am not sure if that can be changed to use XFS instead of ext4, but I
> don't think LVM makes sense on the live image itself.  I will be
> mostly asking about the "install to hard disk" default path when I
> bring it up.

Yes, that's what I'm talking about: the installation path, not the
format used on the deliverable.

In case anyone's not aware, the association between the format used for
the live image itself and the formats allowed for the installed /
partition no longer exists, that was broken back around F18.

[Josh Boyer]

On Fri, Feb 28, 2014 at 8:09 PM, Adam Williamson  wrote:
> On Fri, 2014-02-28 at 20:02 -0500, Josh Boyer wrote:
> > On Fri, Feb 28, 2014 at 6:49 PM, Adam Williamson  wrote:
> > > On Fri, 2014-02-28 at 13:55 -0500, Stephen Gallagher wrote:
> > > > https://fedoraproject.org/wiki/Server/Technical_Specification
> > > >
> > > > This document follows the format of the Workstation Technical
> > > > Specification. We have discussed many of the points here at length on
> > > > the various mailing lists as well as in two IRC working sessions over
> > > > the last two days.
> > > >
> > > > FESCo has requested that we submit this document for review by the end
> > > > of the day on Monday, March 03rd (to give FESCo time to review it
> > > > before the meeting on Wednesday, March 05th).
> > > >
> > > > I have made two additional modifications to the document aside from
> > > > what was discussed in the meetings:
> > > >
> > > > Based on other conversations on the mailing list and in other IRC
> > > > channels, I propose we punt on the question of supported container
> > > > technology (particularly since our first set of Roles will not use
> > > > containers). We will probably want to revisit a Container Host Role
> > > > for Fedora 22.
> > > >
> > > > I have added a first pass at defining the API for the Server Roles
> > > > that will be implemented by the Server SIG alongside the Cockpit
> > > > Project.
> > > >
> > > > What we need right now is a vote of the Server Working Group
> > > > membership whether we feel this document is in sufficiently good shape
> > > > to send to FESCo, who intends to use it to gauge estimates for the
> > > > Fedora 21 schedule. Please cast your votes as soon as possible (I
> > > > realize this may mean giving up an hour of your weekend to read the
> > > > document). If you have serious concerns, please raise them immediately.
> > >
> > > I'd like to see if we can at least reach a consensus with the Desktop WG
> > > on the filesystem question before I vote +1 on this. Josh has said he's
> > > going to take another look at the situation.
> >
> > To be clear, the Workstation WG is looking at delivering a live image
> > by default.  The live image itself is ext4 on top of a raw DM device.
> > I am not sure if that can be changed to use XFS instead of ext4, but I
> > don't think LVM makes sense on the live image itself.  I will be
> > mostly asking about the "install to hard disk" default path when I
> > bring it up.
>
> Yes, that's what I'm talking about: the installation path, not the
> format used on the deliverable.

OK, great.
> In case anyone's not aware, the association between the format used for
> the live image itself and the formats allowed for the installed /
> partition no longer exists, that was broken back around F18.

Sheepishly, I was unaware of that until very recently.  It admittedly
clears a few conversations up, while complicated some of the thoughts
I had around defaults.  I guess that's what I get for not installing
every release.  I mean, I had no reason to install from a live image
either, but still.  Oh well.

josh

[Truong Anh Tuan]

----- Original Message -----
> From: "Kevin Fenzi" 
> To: "Stephen Gallagher" 
> Cc: [e-mail]
> Sent: Saturday, March 1, 2014 4:48:33 AM
> Subject: Re: Call for votes: Server Technical Specification
>
> On Fri, 28 Feb 2014 13:55:34 -0500
> Stephen Gallagher  wrote:
>
> ...snip...
> > What we need right now is a vote of the Server Working Group
> > membership whether we feel this document is in sufficiently good shape
> > to send to FESCo, who intends to use it to gauge estimates for the
> > Fedora 21 schedule. Please cast your votes as soon as possible (I
> > realize this may mean giving up an hour of your weekend to read the
> > document). If you have serious concerns, please raise them
> > immediately.
>
> In general I am +1 to sending to fesco. ;)

Although I have not got much time to attend recent meetings (due by my
trip to FOSSASIA 2014), after reading all meeting logs, discussion on
this mailing list, and the wiki page, I vote another +1 to sending this
to FESCo.
> Some minor nits:
> I think we should drop the note about armv8... it not only needs
> hardware available, but promotion from secondary arch, etc. I'd love
> to support it, but I don't think we should try and do so before it's
> been fully brought up.

+1. I share this with Kevin. We should not say anything before it comes.
> Thanks for writing things up!

+1 :)

Kind regards,
Tuan

[Chris Murphy]

On Feb 28, 2014, at 4:56 PM, Adam Williamson  wrote:
> On Fri, 2014-02-28 at 14:48 -0700, Kevin Fenzi wrote:
> > I don't know that there are any tech limitations for /boot not on
> >
> > lvm. But there's still an important case that needs it: encrypted /
>
> There's some background at
> https://bugzilla.redhat.com/show_bug.cgi?id=1036705 and related bugs. As
> I understand it, dlehman's current position is that he doesn't believe
> LVM devs, btrfs devs etc are sufficiently committed to supporting /boot
> on those volumes that it is safe for anaconda to offer this choice. As
> of right now, for grub2, anaconda does not allow /boot to be on anything
> but a raw partition or a RAID device, and only allows the ext, xfs and
> btrfs filesystems. /boot cannot be a btrfs *subvolume*, but it can be
> raw partition formatted with the btrfs filesystem (I don't think you can
> achieve this with the UI, though, so it's kickstart-only).

Re: btrfs devs are committed to supporting /boot on Btrfs for some time. It works now. GRUB legacy has some minimal support (maybe it was just single device, not sure). GRUB2 supports booting any Btrfs volume including multiple devices, except profiles raid5/6. Support includes lzo or zlib compression, multiple device single, raid0, raid1, raid10, and even appears to tolerate degraded (multiple device with one device missing) volumes.

The problem with /boot on Btrfs looks to be exclusively a Fedora bug with grubby [1]. No other distro I've tested has a problem with /boot on Btrfs except Fedora. Even three year old Ubuntu with its old grub2 and ancient (in Btrfs terms) kernels can do this.

The summary of the cause is that grubby becomes confused about subvolumes, fails to update grub.cfg, and therefore kernel updates, in effect, aren't usable. The work around is to use grub2-mkconfig to write out a new grub.cfg - so obviously it's possible for this to work.

As for LVM, GRUB2 finds /boot on a conventional LV, it doesn't on thinp LVs. I'm not sure what the status of that works is, if there is even any planned, but it seems like it'd need to come from the LVM folks to contribute to GRUB to make it happen.

As for md RAID, I've tested GRUB finding /boot on md linear, raid0, raid1, raid10, raid5 and raid6 and it works up to the limit of the BIOS to present the minimum number of disks. So if there are problems here I'm not sure where they area, maybe in the initramfs?

GRUB2 has no issue finding /boot files on XFS. [2]

Chris Murphy

[1]
https://bugzilla.redhat.com/show_bug.cgi?id=864198

[2]
Although, XFS does not have a bootloader pad, unlike ext4. So there's no such thing as embedding grub "to a partition" (into the VBR) if its XFS formatted. Anaconda doesn't support this since newui anyway, so it shouldn't be a problem but there are still some people who think this is a good idea and for them I say use extlinux and ext4 which are designed for this use case.

[Máirín Duffy]

Hi,

On 02/28/2014 01:55 PM, Stephen Gallagher wrote:
> If you have serious concerns, please raise them immediately.

I'll +1 but my concerns are as follows:

- The Accessibility section makes no statements about Cockpit's a11y or 
required state of a11y; is the web ui designed in such a way to be 
usable by those using screen readers? I've not used it but with the 
general popularity if JS frameworks that aren't necessarily 
screen-reader friendly it is a concern.

- Encryption - I think this was raised elsewhere in the thread but we 
should probably have a section to talk about encryption support (altho 
we missed this in PRD :-/) This would affect the filesystem and install 
defaults specifications.

- Appearance - ok maybe this is stupid but it would be nice to have 
installed and configured by default a nice console font like inconsolata 
or something like that with reasonable fallbacks for i18n.

- Backup - we talk about roles req lists of things to back up - do we 
have a blessed backup system(s) we support tying into?

~m

[Stephen Gallagher]

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

On 02/28/2014 06:49 PM, Adam Williamson wrote:
> I'd like to see if we can at least reach a consensus with the
> Desktop WG on the filesystem question before I vote +1 on this.
> Josh has said he's going to take another look at the situation.

Based on the comments provided by Ric Wheeler (Red Hat's storage and
filesystems lead) on the devel@ discussion about filesystems[1][2], I
think it really may make sense for the Workstation and Server groups
to differ in their defaults here.

I'm don't think this will realistically add to QA's workload, as long
as each Product has only one default partitioning path.

As Ric notes, XFS-on-LVM is the most common real-world deployment of
at least Red Hat Enterprise Linux servers. It seems sensible to share
that. Beyond that, we know that this is primarily a default for the
GUI install. Anyone doing a production deployment is likely going to
be using kickstart and a custom layout. So I'd argue that the
selection here should focus on being "good enough" and not necessarily
"perfect".

The main reason I want to see the default be XFS-on-LVM is because the
default is the path that will see the most QA testing. If this really
is the layout that most people will approximate with their custom
deployments, then this is the best use of our limited resources.

[1] https://lists.fedoraproject.org/pipermail/devel/2014-March/196190.html
[2] https://lists.fedoraproject.org/pipermail/devel/2014-March/196193.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMUepgACgkQeiVVYja6o6PwxACgiTN1+fjskhf1FjoYPQRixYnz
> skUAn3Xf/aGduSaaVjfHOpZ6JYrFzK3l
> =t4tC
> -----END PGP SIGNATURE-----

[Stephen Gallagher]

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

On 03/02/2014 09:58 PM, Máirín Duffy wrote:
> Hi,
>
> On 02/28/2014 01:55 PM, Stephen Gallagher wrote:
> > If you have serious concerns, please raise them immediately.
>
> I'll +1 but my concerns are as follows:
> The Accessibility section makes no statements about Cockpit's
>
> a11y or required state of a11y; is the web ui designed in such a
> way to be usable by those using screen readers? I've not used it
> but with the general popularity if JS frameworks that aren't
> necessarily screen-reader friendly it is a concern.

This is a really good question, actually. I'm CCing the Cockpit
development list to get a response from them.

That being said, I think our accessibility efforts in the first
release need to be "best reasonable effort". We want to support them,
but we need to figure out where our limited resources are best spent
in the short term. In the medium to long term, this becomes vastly
more important.
> Encryption - I think this was raised elsewhere in the thread but
>
> we should probably have a section to talk about encryption support
> (altho we missed this in PRD :-/) This would affect the filesystem
> and install defaults specifications.

I'd actually be slightly in favor of leaving encryption support to the
custom path, for several reasons:

1) Encrypting a filesystem means that startup/reboot cannot be handled
unattended. Someone will need to provide a password (or insert
security device, etc.)

2) Servers in the "pets" category tend to remain running all the time.
Encryption is only useful when the drive has been removed from the
machine.

2b) Even if the drive is encrypted only for theft protection, in order
to accomplish unattended install, the admin will have to customize the
mechanism they use to provide the decryption key, in which case
they're likely doing a custom install of the filesystem anyway.

3) While much less so than it once was, encryption requires CPU time
to be used on I/O, which is often wasteful in a server environment.

So I'd suggest that Fedora Server recommends the use of LUKS for disk
encryption and makes it available in the custom configuration path only.

Thoughts?
> Appearance - ok maybe this is stupid but it would be nice to
>
> have installed and configured by default a nice console font like
> inconsolata or something like that with reasonable fallbacks for
> i18n.

Perfectly reasonable. Mind if I phrase it as:

"The Fedora Server team will consult with the Fedora Design Team to
select a suitable console font."
> Backup - we talk about roles req lists of things to back up - do
>
> we have a blessed backup system(s) we support tying into?

No, we've discussed that in the past. We don't currently want to try
to dictate that (though in the future we may provide a Role for such a
solution). At present, what we want to do is provide a programmatic
interface for a backup solution to learn dynamically what we want it
to back up (rather than requiring admins to maintain a whitelist
themselves).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMUfN8ACgkQeiVVYja6o6NLtgCgpflOWctFvpIxcfxN3eqDDhw1
> dcMAn2/8CqGN5+KrVGzkqO1Rx1a4wuw0
> =NOix
> -----END PGP SIGNATURE-----

[Simo Sorce]

On Mon, 2014-03-03 at 08:00 -0500, Stephen Gallagher wrote:
> I'd actually be slightly in favor of leaving encryption support to the
> custom path, for several reasons:

I am not reasons inline.
> Encrypting a filesystem means that startup/reboot cannot be handled
>
> unattended. Someone will need to provide a password (or insert
> security device, etc.)

This is true, and should be made clear at install time, but I think we
should still encourage people to do encryption by prominently asking if
they want it.
> Servers in the "pets" category tend to remain running all the time.
>
> Encryption is only useful when the drive has been removed from the
> machine.

Which is common, I had raid disk fail in colocation. When they change a
disk for me I have no freaking idea what they are going to do with them.
The disk is not necessarily completely dead. It may just fail in writing
but be perfectly accessible for reading. People should have prayers as
the only recourse when a disk fail and some stranger gets in possession
of the old disk.
> 2b) Even if the drive is encrypted only for theft protection, in order
> to accomplish unattended install, the admin will have to customize the
> mechanism they use to provide the decryption key, in which case
> they're likely doing a custom install of the filesystem anyway.

I think we could put encryption keys in the boot partition.
Then have a *decommission* command that will wipe the boot. The rest of
the disk is encrypted with a lost key at this point and unreadable.

If the /boot is on a totally different disk, you do not even need the
wipe step.
> While much less so than it once was, encryption requires CPU time
>
> to be used on I/O, which is often wasteful in a server environment.

It is often marginal given the CPUs we have today.
If you have a heavy I/O bound load then the CPUs are almost always
idling wait for data to be written/read from platters anyway. With CPUs
having AESNI instructions, this is really not a concern anymore in most
cases. (ARM 32 may be an exception to this rule)
> So I'd suggest that Fedora Server recommends the use of LUKS for disk
> encryption and makes it available in the custom configuration path only.
>
> Thoughts?

See above, I think we should encourage the use of encryption and test it
as a common deployment scenario.

Simo.

[Andreas Nilsson]

On 03/03/2014 02:00 PM, Stephen Gallagher wrote:
> On 03/02/2014 09:58 PM, Máirín Duffy wrote:
> > I'll +1 but my concerns are as follows:
> > The Accessibility section makes no statements about Cockpit's
> >
> > a11y or required state of a11y; is the web ui designed in such a
> > way to be usable by those using screen readers? I've not used it
> > but with the general popularity if JS frameworks that aren't
> > necessarily screen-reader friendly it is a concern.
>
> This is a really good question, actually. I'm CCing the Cockpit
> development list to get a response from them.

Hi, good question! We in the Cockpit team haven't really talked about 
before. Thanks for bringing it up!
The framework we're using in Cockpit is Patternfly [1] that buils on top 
of Bootstrap [2], and it seems there is a plugin available that makes 
things vastly better for screen readers.
https://www.paypal-engineering.com/2014/01/28/bootstrap-accessibility-plugin...

1. https://www.patternfly.org/
2. http://getbootstrap.com/

- Andreas

[Stephen Gallagher]

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

On 03/03/2014 08:47 AM, Simo Sorce wrote:
> On Mon, 2014-03-03 at 08:00 -0500, Stephen Gallagher wrote:
> > I'd actually be slightly in favor of leaving encryption support
> > to the custom path, for several reasons:
>
> I am not reasons inline.
> > Encrypting a filesystem means that startup/reboot cannot be
> >
> > handled unattended. Someone will need to provide a password (or
> > insert security device, etc.)
>
> This is true, and should be made clear at install time, but I think
> we should still encourage people to do encryption by prominently
> asking if they want it.
> > Servers in the "pets" category tend to remain running all the
> >
> > time. Encryption is only useful when the drive has been removed
> > from the machine.
>
> Which is common, I had raid disk fail in colocation. When they
> change a disk for me I have no freaking idea what they are going to
> do with them. The disk is not necessarily completely dead. It may
> just fail in writing but be perfectly accessible for reading.
> People should have prayers as the only recourse when a disk fail
> and some stranger gets in possession of the old disk.

True, I didn't have colocation on my mind when I wrote this. That's an
excellent point.
> > 2b) Even if the drive is encrypted only for theft protection, in
> > order to accomplish unattended install, the admin will have to
> > customize the mechanism they use to provide the decryption key,
> > in which case they're likely doing a custom install of the
> > filesystem anyway.
>
> I think we could put encryption keys in the boot partition. Then
> have a *decommission* command that will wipe the boot. The rest of 
> the disk is encrypted with a lost key at this point and
> unreadable.
>
> If the /boot is on a totally different disk, you do not even need
> the wipe step.

An interesting idea, but it doesn't help if you hit the situation
above (where writes fail but reads are okay). You wouldn't be able to
wipe the key at that point.

Even if the /boot is on a different disk, you have a problem where if
that disk is the one that dies, you lose access to all your other
data, unless you've got a key escrow system in place.

A magical solution that I could see would be for us to be able to
retrieve the key from a network location (such as the FreeIPA Domain
Controller?) during system start. We'd have to have network access
prior to mounting disks, of course.

And also we'd have to be enrolling in a domain during the installation
step, or else we wouldn't be able to escrow the key. Also we'd need to
be encrypting the communication, which means that we'd be relying on
the keytab (which would have to be available to /boot). This would
still be a better situation than having the password on the local
system, though. Since at least we could disable the host in FreeIPA as
the decommissioning step.

If we could implement all of that, I'd be in favor of making
encryption (and this escrow) the default.

Thoughts?
> > While much less so than it once was, encryption requires CPU
> >
> > time to be used on I/O, which is often wasteful in a server
> > environment.
>
> It is often marginal given the CPUs we have today. If you have a
> heavy I/O bound load then the CPUs are almost always idling wait
> for data to be written/read from platters anyway. With CPUs having
> AESNI instructions, this is really not a concern anymore in most 
> cases. (ARM 32 may be an exception to this rule)

Yeah, I'd like to ask the ARM folks if they have numbers on this.
> > So I'd suggest that Fedora Server recommends the use of LUKS for
> > disk encryption and makes it available in the custom
> > configuration path only.
> >
> > Thoughts?
>
> See above, I think we should encourage the use of encryption and
> test it as a common deployment scenario.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMUjcIACgkQeiVVYja6o6P5vACbBOeBmXiIbt1ZQQJVm5cRiolT
> SOsAn29K5qqSVDvXGh15f8H2rFNfK9im
> =WizS
> -----END PGP SIGNATURE-----

[Bill Nottingham]

Josh Boyer ([e-mail]) said:
> To be clear, the Workstation WG is looking at delivering a live image
> by default.  The live image itself is ext4 on top of a raw DM device.
> I am not sure if that can be changed to use XFS instead of ext4, but I
> don't think LVM makes sense on the live image itself.

My recollection from trying recently was that XFS-root didn't always work
OOTB on the live image, but that was mainly an issue with certain livecd
creation tools that was fixable rather than anything inherent.

Bill

[Miloslav Trmač]

2014-02-28 19:55 GMT+01:00 Stephen Gallagher :
> https://fedoraproject.org/wiki/Server/Technical_Specification

<snip>
> What we need right now is a vote of the Server Working Group
> membership whether we feel this document is in sufficiently good shape
> to send to FESCo, who intends to use it to gauge estimates for the
> Fedora 21 schedule.

+1.

Non-blocking comments regarding the role definition:

- "A mechanism to install optional components of a role after
   deployment." Do we really need this?  Could we do without this complexity?
   - The firewall configuration: the mechanism to open/close ports
   shouldn't be a role-specific API; couldn't the role just provide a
   firewalld service definition, and leave the enabling/disabling to the
   standard firewalld mechanisms?

Mirek

[Miloslav Trmač]

2014-03-03 15:12 GMT+01:00 Stephen Gallagher :
> A magical solution that I could see would be for us to be able to
> retrieve the key from a network location (such as the FreeIPA Domain
> Controller?) during system start. We'd have to have network access
> prior to mounting disks, of course.

In fact such a thing has been designed (but AFAIK not implemented) for
FreeIPA a few years ago, broadly along the lines of your description.
> If we could implement all of that, I'd be in favor of making
> encryption (and this escrow) the default.

It would be kind of ugly that installing a domain-joined server results in
an encrypted system and installing a stand-alone server presumably
doesn't.  Or would we recommend encrypting even the non-domain-joined
server?  In a homogenous Fedora deployment, the only such server should be
FreeIPA (with all the critical Kerberos data), so offering to encrypt it by
default would probably be justifiable.

In any case, if we support encryption in the installer GUI, the user needs
to make a choice; not necessarily in the partitioning dialog where it is
offered currently.
    Mirek

[Stephen Gallagher]

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

On 03/03/2014 10:09 AM, Miloslav Trmač wrote:
> 2014-02-28 19:55 GMT+01:00 Stephen Gallagher <[e-mail] 
> >:
>
> https://fedoraproject.org/wiki/Server/Technical_Specification
>
> <snip>
>
> What we need right now is a vote of the Server Working Group 
> membership whether we feel this document is in sufficiently good
> shape to send to FESCo, who intends to use it to gauge estimates
> for the Fedora 21 schedule.
>
> +1.
>
> Non-blocking comments regarding the role definition:
> "A mechanism to install optional components of a role after
>
> deployment." Do we really need this?  Could we do without this 
> complexity?

We need this. In the case of FreeIPA (for example) this allows us to
install the DNS server or the Winsync capabilities (among other things).
> The firewall configuration: the mechanism to open/close ports
>
> shouldn't be a role-specific API; couldn't the role just provide a 
> firewalld service definition, and leave the enabling/disabling to 
> the standard firewalld mechanisms?

We need to figure out the actual implementation, yes. That's going to
require some actual design work.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMUnKQACgkQeiVVYja6o6OGdgCgl/5v99CwSiLkPNk2602QIzUX
> bQwAniLXsMK7EfxVr0XsiiucWbK6SN7K
> =nAp1
> -----END PGP SIGNATURE-----

[Josh Boyer]

On Fri, Feb 28, 2014 at 6:49 PM, Adam Williamson  wrote:
> On Fri, 2014-02-28 at 13:55 -0500, Stephen Gallagher wrote:
> > What we need right now is a vote of the Server Working Group
> > membership whether we feel this document is in sufficiently good shape
> > to send to FESCo, who intends to use it to gauge estimates for the
> > Fedora 21 schedule. Please cast your votes as soon as possible (I
> > realize this may mean giving up an hour of your weekend to read the
> > document). If you have serious concerns, please raise them immediately.
>
> I'd like to see if we can at least reach a consensus with the Desktop WG
> on the filesystem question before I vote +1 on this. Josh has said he's
> going to take another look at the situation.

I took a look.  There was a lot of discussion, but I don't think we're
going to reach consensus here.  Workstation still eventually wants to
default to btrfs.  Switching to XFS now and then switching to btrfs
for the next release (or the one after) seems like fairly pointless
churn to most people.  Workstation is most likely going to remain on
ext4 for the first release.

josh

[Miloslav Trmač]

2014-03-03 16:15 GMT+01:00 Stephen Gallagher :
> > "A mechanism to install optional components of a role after
> >
> > deployment." Do we really need this?  Could we do without this
> > complexity?
>
> We need this. In the case of FreeIPA (for example) this allows us to
> install the DNS server or the Winsync capabilities (among other things).

Couldn't we just always install the files, and only enable/disable the
functionality using the "configuration interface to modify high-level
configuration options"?
    Mirek

[Stephen Gallagher]

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

On 03/03/2014 10:34 AM, Miloslav Trmač wrote:
> 2014-03-03 16:15 GMT+01:00 Stephen Gallagher <[e-mail] 
> >:
> > "A mechanism to install optional components of a role after
> >
> > deployment." Do we really need this?  Could we do without this 
> > complexity?
>
> We need this. In the case of FreeIPA (for example) this allows us
> to install the DNS server or the Winsync capabilities (among other
> things).
>
> Couldn't we just always install the files, and only enable/disable
> the functionality using the "configuration interface to modify
> high-level configuration options"? Mirek

BIND 9 at least is kind of heavy-weight to pull onto the system unless
you're actually using it. I'm not sure there won't be other cases in
the future that would be even larger to have lying around. That said,
if we consider the potential disk space waste acceptable, I'm okay
with this.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMUo6sACgkQeiVVYja6o6O33wCgn9VNoceZeNIzzskuY+/lz9UD
> x7cAn17ZSzYZTwXtpX+thOCR7o2a3NQc
> =+IUD
> -----END PGP SIGNATURE-----

[Simo Sorce]

On Mon, 2014-03-03 at 10:45 -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/03/2014 10:34 AM, Miloslav Trmač wrote:
> > 2014-03-03 16:15 GMT+01:00 Stephen Gallagher <[e-mail] 
> > >:
> > > "A mechanism to install optional components of a role after
> > >
> > > deployment." Do we really need this?  Could we do without this 
> > > complexity?
> >
> > We need this. In the case of FreeIPA (for example) this allows us
> > to install the DNS server or the Winsync capabilities (among other
> > things).
> >
> > Couldn't we just always install the files, and only enable/disable
> > the functionality using the "configuration interface to modify
> > high-level configuration options"? Mirek
>
> BIND 9 at least is kind of heavy-weight to pull onto the system unless
> you're actually using it. I'm not sure there won't be other cases in
> the future that would be even larger to have lying around. That said,
> if we consider the potential disk space waste acceptable, I'm okay
> with this.

BIND9 is nothing compared to the truckload of dependencies the CA
(dogtag) pulls in (a lot of java related stuff). And the CA is something
you install only on a couple of IPA Servers, not all of them in a large
infrastructure.

So perhaps we can just pull in all the packages for now.

Simo.

[Stephen Gallagher]

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

On 03/03/2014 10:14 AM, Miloslav Trmač wrote:
> 2014-03-03 15:12 GMT+01:00 Stephen Gallagher <[e-mail] 
> >:
>
> A magical solution that I could see would be for us to be able to 
> retrieve the key from a network location (such as the FreeIPA
> Domain Controller?) during system start. We'd have to have network
> access prior to mounting disks, of course.
>
> In fact such a thing has been designed (but AFAIK not implemented)
> for FreeIPA a few years ago, broadly along the lines of your
> description.
>
> If we could implement all of that, I'd be in favor of making 
> encryption (and this escrow) the default.
>
> It would be kind of ugly that installing a domain-joined server
> results in an encrypted system and installing a stand-alone server
> presumably doesn't.  Or would we recommend encrypting even the
> non-domain-joined server?  In a homogenous Fedora deployment, the
> only such server should be FreeIPA (with all the critical Kerberos
> data), so offering to encrypt it by default would probably be
> justifiable.
>
> In any case, if we support encryption in the installer GUI, the
> user needs to make a choice; not necessarily in the partitioning
> dialog where it is offered currently.

I've added the following sentence to the "File system" section:

"An option will be provided in the Fedora Server installer to enable
disk encryption."

I trust that FESCo will understand that this is a statement of intent
whose details will be worked out as we go along.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMU3f8ACgkQeiVVYja6o6NL6wCgjQQZdAzQspLRVrs7XjG+3UsZ
> nsQAn1vKqcmDXgQR2yxHhEhkHFqA7h/Q
> =oNyu
> -----END PGP SIGNATURE-----

[David Timothy Strauss]

+1, as long as we truly pursue a containers host for F22+.

[Stephen Gallagher]

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

On 03/03/2014 06:05 PM, David Timothy Strauss wrote:
> +1, as long as we truly pursue a containers host for F22+.

Well, there's nothing stopping an interested party from attempting to
build such a role in F21, but we (the Server SIG/WG) probably won't
have an opportunity to test it sufficiently for promotion to a
"featured" Role.

Also, I want to remind people that the lack of a Server Role for
something does not mean that we are somehow preventing the use of this
technology. The kernel will have all the namespacing capabilities
provided by upstream, so nothing stops our users from manually
installing libvirt-lxc and using it.

Given that part of our reasoning for the Fedora.next effort is to
maintain relevance in a changing landscape, I would certainly +1 an
effort to make a Container Host (possibly powered by Docker.io) as one
of the focus Roles for Fedora 22.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMVFR0ACgkQeiVVYja6o6Oo1ACeNHO0WSCdUF9G9V+H3oNE0nuO
> UjEAn0z6t57on9AqXIUe0YmmB0TwyCx4
> =hHap
> -----END PGP SIGNATURE-----

[Matthew Miller]

On Mon, Mar 03, 2014 at 06:49:49PM -0500, Stephen Gallagher wrote:
> On 03/03/2014 06:05 PM, David Timothy Strauss wrote:
> > +1, as long as we truly pursue a containers host for F22+.
>
> Given that part of our reasoning for the Fedora.next effort is to
> maintain relevance in a changing landscape, I would certainly +1 an
> effort to make a Container Host (possibly powered by Docker.io) as one
> of the focus Roles for Fedora 22.

A Docker host is one of the Cloud WG's focuses for F21. Perhaps what we
should aim for for F22 is a way to provision this and other "cattle-type"
systems (like openstack nodes) to real hardware.

[Colin Walters]

On Tue, Mar 4, 2014 at 8:02 AM, Matthew Miller 
 wrote:
> A Docker host is one of the Cloud WG's focuses for F21. Perhaps what 
> we
> should aim for for F22 is a way to provision this and other 
> "cattle-type"
> systems (like openstack nodes) to real hardware.

Yes, but I'd say it *also* falls under the Server group's domain.  I 
think the present Server group is focused on Roles, so we'll have to 
figure out what pieces fall where.

To me the biggest question is around whether or not Fedora ships an 
official Docker base image (or more than one), and what degree of 
support/promotion occurs for that.

Also, in case anyone hasn't seen it, I recently posted about the 
"Fedora Atomic Initiative":
https://lists.fedoraproject.org/pipermail/devel/2014-March/196257.html

There's a common discussion thread here about how RPM-derived content 
(docker images, OSTree trees) are built and maintained.

[Matthew Miller]

On Tue, Mar 04, 2014 at 06:52:53PM +0000, Colin Walters wrote:
> Yes, but I'd say it *also* falls under the Server group's domain.  I
> think the present Server group is focused on Roles, so we'll have to
> figure out what pieces fall where.

Yep. And I'm not worried about some overlap, as long as we can do it without
being overwhelmingly confusing.
> To me the biggest question is around whether or not Fedora ships an
> official Docker base image (or more than one), and what degree of
> support/promotion occurs for that.

We _are_ planning to do that.