Comparison to Workstation Technical Specification

Tue Feb 25 22:29:45 UTC 2014

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

Replies inline; I cut out the places where we were in agreement.

On 02/25/2014 04:47 PM, Simo Sorce wrote:
> On Tue, 2014-02-25 at 15:42 -0500, Stephen Gallagher wrote:

>>> === Firewall ===
>>> 
>>> A firewall in its default configuration may not interfere with
>>> the normal operation of programs installed by default.
> 
> I do not understand what "normal operation" means here. What is
> normal is in part determined by what the user of the system wants
> to accomplish.
> 
>> I would extend this statement to include that the deployment of
>> Server Roles should also adjust the firewall operation in a
>> manner consistent with user expectation.
> 
> Are we going to use something like firewalld or something else ? 
> Should we have the firewall configured by default, or not ?
> 

I think that we should have a firewall configured by default, yes.

>>> We should detect when the system is on a public or untrusted 
>>> network and prevent the user from unwanted sharing of e.g.
>>> music or other media in this situation. A firewall (and network
>>> zones as currently implemented by firewalld) may or may not be
>>> part of a solution to this.
>>> 
>> 
>> The concept of network zones should probably be basically ignored
>> for Fedora Server, as we should generally default to closing all
>> ports except for those made available for installed Roles. (Also,
>> the Role configuration should optionally be able to specify on
>> which interfaces it wishes to operate, so we can restrict
>> internal vs. external operation in a multi-homed environment).
> 
> What do we gain from a firewall that any application can poke holes
> at ? Can someone state the benefits, or a situation where the
> default configuration would be safer with a firewall ?
> 

This is not "any application". This is Server Roles. If a Server Role
can't be seen through the firewall, it's broken. As I noted above, I
do think that part of Role configuration needs to be whether it's
visible on certain interfaces.

>>> === Problem reporting ===
>>> 
>>> Problems and error conditions (e.g. kernel oopses, Selinux
>>> AVCs, application crashes, OOM, disk errors) should all be
>>> reported in the systemd journal.
>> 
>> Ack
> 
> Is there another place they may be reported to ?
> 

They each have individual places where they might end up if not drawn
together in the journal. This is basically just formalizing the
current plan of record with journald.

>>> Sending this information to a central place (like abrt does for
>>>  crashes today) should be possible, but not mandatory.
>>> Depending on the use case, it may be turned off, enabled
>>> manually on a case-by-case basis, or entirely automatic without
>>> user intervention.
>>> 
>> 
>> 
>> In the case of the Fedora Server, I think that reporting
>> information to a central location must be mandatory. Most servers
>> in real-world deployment are headless in a datacenter somewhere.
>> Administrators will need to be able to see all issues from a
>> standard console.
> 
> There is a problem with sending information from things like abrtd
> to a central location by default, in that sensitive information may
> get disclosed unless the log server is reached only through
> authenticated and encrypted connections. Ideally we have a way to
> signal the trustworthiness of the log and change behavior
> accrodingly and automatically. Whether we can do this in the
> short/medium term I do not know.
> 
> But technically rsyslog can secure connections and even do mutual 
> authentication as it supports both TLS and GSSAPI. I also discussed
> at DevConf.cz with the rsyslog maintainer some secure
> store-and-forward techniques to use with ephemeral encryption keys
> and such so it is an option.
> 
>> Also, we need to keep in mind that the majority of servers will
>> *not* have visibility to the internet, so transmitting ABRT
>> results directly to Bugzilla is often impossible. We will need to
>> be able to aggregate the issues on a network-local management
>> server. (Note: IMHO this is not a blocker requirement on F21)
> 
> Whether it is "possible" or not automatic transmission is almost
> always inappropriate IMO. Too much potentially sensitive info can
> be transmitted with these kinds of reports, they have to be
> validated and approved for transmission by an admin.
> 
> I think this should be an actual requirement for the Server
> platform.
> 

You make excellent points. This is a piece we're going to have to
spend some time thinking about. I hope that Miloslav will chime in
here, as he has a lot of first-hand knowledge on this front.

>> 
>>> === Account handling ===
>>> 
>>> SSSD is providing the backing storage for identity management.
>>> For 'managed' scenarios (e.g. the 'developer in a large
>>> organization' use case of the PRD), it will be possible to
>>> configure it to rely on a directory service for this
>>> information. The accountsservice is providing a D-Bus interface
>>> for user account information; this may be integrated into SSSD
>>> at some point.
>>> 
>>> Depending on their needs, application and services can either
>>> use the POSIX APIs (getpwent(), etc) or the accountsservice
>>> D-Bus interface to obtain user information.
>>> 
>> 
>> 
>> As the Fedora Server is more likely than Workstation to require 
>> central management, I think we need to adopt this
>> wholeheartedly. Also, realmd should be considered a core piece of
>> our story, as it enables automatic configuration of SSSD with
>> either FreeIPA (our Domain Controller Role) or Active Directory
>> (Microsoft Windows Domain Controller).
> 
> +1 (though I have a conflict of interest here :-)
> 

I am, of course, equally guilty of this conflict of interest. :)

>>> === Software updates ===
>>> 
>>> gnome-software will use PackageKit with the hawkey backend to 
>>> obtain and install software updates for packaged applications
>>> and the OS itself. The recommendation for applications is to
>>> use the PackageKit APIs to interact with the underlying
>>> packaging system.
>>> 
>> 
>> 
>> Software updates on a server system should be designed in such a
>> way that they can be enforced centrally. With Fedora Server, this
>> probably means picking one of the common config management
>> systems such as Puppet, Chef, Red Hat Satellite or else relying
>> on OpenLMI for performing central software upgrades.
> 
> I think you forgot spacewalk here.
> 

It wasn't meant to be an exhaustive list.

>> For single-server manipulation, I think we should focus on
>> supporting yum/dnf.
> 
> I think yum/successor CLI tool should be the default here indeed.
> 
>>> === Miscellaneous system information ===
>>> 
>>> System locale, timezone, hostname, etc. will be managed
>>> through the services provided by systemd for this purpose. See
>>> developer documentation for 
>>> [http://www.freedesktop.org/wiki/Software/systemd/localed/ 
>>> localed], 
>>> [http://www.freedesktop.org/wiki/Software/systemd/timedated/ 
>>> timedated] and 
>>> [http://www.freedesktop.org/wiki/Software/systemd/hostnamed/ 
>>> hostnamed]
>>> 
>> 
>> 
>> I also think we should stick with the systemd-offered mechanisms
>> for this functionality (and I know that Cockpit is already
>> interfacing with much of it).
> 
> To be honest I find hostnamed quite inadequate for a server case as
> it introduced confusion in the naming and by default will mangle
> perfectly valid fqdns that the admin want to assign to the
> machine.
> 
> I think we should carefully evaluate these mechanisms.
> 
> For example, messing up with the hostname often has annoying 
> consequences when a server is enrolled into a central identity 
> management system.
> 

True, we probably want to work with them to disallow hostname changes
while a machine is enrolled in a domain. I think that the interface
here is what we want; we can work on improving the execution.

> 
>>> === Virtualization ===
>>> 
>>> libvirt-daemon will be used to manage virtualization
>>> capabilities.
>>> 
>> 
>> 
>> We probably want to use libvirt-daemon for virtualization and
>> focus on systemd-nspawn for containerization.
> 
> what about libvirt-lxc/docker ?
> 

Docker is moving away from libvirt-lxc towards systemd-nspawn (and I
believe the latest releases have experimental support for this
already). I think we probably want to meet them there.

>>> === Display manager ===
>>> 
>>> gdm will be used as the display manager. It is responsible for
>>>  showing a login screen on each seat. It will be able to
>>> launch both X-based sessions and Wayland sessions.
>>> 
>>> Desktop environments are expected to make themselves known as
>>> an available session option on the login screen by dropping a 
>>> .desktop file into /usr/share/xsessions (or its wayland 
>>> equivalent).
>>> 
>>> Other facilities provided by the display manager include screen
>>>  unlock authentication and user switching.
>>> 
>> 
>> 
>> Display manager is irrelevant to the Server product.
> 
> We already discussed in some cases we will need them as some
> server software unfortunately need a grpahical session for 
> installation/configuration purposes.
> 
> So we should have at least a recommendation of how to start a
> graphical session if required, even if it is just a manual startx
> or if the recommendation is to use Xvnc and a vnc client or other
> similar options.
> 

Valid points. We should start by deciding if we want to bite this off
right now or defer it for a future release, though. Getting this right
might be a challenge.

>>> === Accessibility ===
>>> 
>>> The accessibility support in the workstation includes a screen
>>>  reader, a high-contrast theme and a zoom capability, amongst 
>>> others. The screen reading is provided through orca, which runs
>>> as a session service and requires the at-spi infrastructure. 
>>> Applications are expected to provide suitable information to
>>> the screen reader via the toolkit's accessibility support.
>>> Applications are also expected to work acceptably in the
>>> high-contrast theme. The zoom is implemented in the desktop
>>> shell and does not need any application support.
>>> 
>> 
>> 
>> Accessibility on the server is a topic I'm fairly comfortable
>> with deferring to the management tools such as Cockpit and
>> Katello/Foreman. On the pure command-line, I think the most we
>> can do is assert that any interactive operation we enable should
>> have a configurable timeout to deal with potentially slow
>> typists.
> 
> We should at least support braille devices out of the box for
> console interaction IMO.
> 

I hadn't thought of that. Thanks for bringing it up.

>>> === Graphics ===
>>> 
>>> The workstation session will switch to using a Wayland
>>> compositor as soon as feasible. Until then, it will be based on
>>> X11. Even after the switch, an X server will be included, so
>>> applications can either connect to Wayland natively, or run as
>>> an X client.
>>> 
>> 
>> 
>> Not applicable
> 
> See above.

Ack

> 
>>> === Media support ===
>>> 
>>> Sound hardware and audio streams will be managed by pulseaudio.
>>>  Applications are recommended to use the 
>>> [http://gstreamer.freedesktop.org/documentation/ gstreamer] 
>>> framework for media playback.
>>> 
>> 
>> 
>> Not applicable
> 
> There are server side media streamers, DLNA, etc.. we can defer
> taking any action but it is incorrect to say that a server os has
> nothing to do with media support.
> 

Well, I'm not sure that fits in terms of our Fedora Server platform at
least. We might want to explicitly state it as a non-goal though.

>>> === Appearance ===
>>> 
>>> The workstation will ship with a single theme, which will have
>>>  support for the included toolkits: gtk3, qt and gtk2.
>>> Applications are expected to work well with this theme, as well
>>> as with the high-contrast theme that is used for accessibility.
>>> The theme will include a dark variant that applications can opt
>>> into using (this is most suitable for certain content-focused
>>> applications). The theme also includes an icon theme that
>>> provides named icons according to the icon-naming spec, plus
>>> symbolic variants.
>>> 
>>> We will be using the Adwaita theme, with a yet-to-be-written qt
>>>  variant.
>>> 
>> 
>> 
>> As for "appearance", my view is that Cockpit should be the
>> official "face" of the Fedora Server. Opinions welcome :)
> 
> Should we say something about how the shell is configured,
> defaults, bash-completion, vim-enhanced/emacs/other plugins ?
> 

Perhaps... I'm not sure if we need to go to that particular level of
detail, but if you want to write it up, I'm sure no one will argue :)