Call for votes: Server Technical Specification

Stephen Gallagher sgallagh at redhat.com
Mon Mar 3 13:00:15 UTC 2014


-----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-----


More information about the cockpit-devel mailing list