-----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 :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlMNGVkACgkQeiVVYja6o6MjZACfYnTzjYgrLi5cNLDqa6ATnWVR
MwoAoKfPcwL/hn4/WI3qd8LYk+uAR3Cp
=lMAh
-----END PGP SIGNATURE-----