Event Invitation: Fedora Server Working Group Meeting
by Stephen Gallagher
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20140312T132733Z
DTSTAMP:20140312T132733Z
UID:a70e3837-d30b-47b7-8025-a5131e259ab2
SUMMARY:Fedora Server Working Group Meeting
STATUS:CONFIRMED
ORGANIZER:mailto:sgallagh@redhat.com
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:serve
r(a)lists.fedoraproject.org
RRULE:FREQ=WEEKLY
DTSTART;TZID=America/New_York:20140318T110000
DTEND;TZID=America/New_York:20140318T130000
DESCRIPTION:Restoring this regularly scheduled meeting. It appears to have
fallen off many calendars.
LOCATION:#fedora-meeting-1
CLASS:PUBLIC
TRANSP:OPAQUE
SEQUENCE:0
END:VEVENT
END:VCALENDAR
9 years
Fedora Server WG Meeting Minutes (2014-03-11)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================
#fedora-meeting-1: Server Working Group Weekly Meeting (2014-03-11)
===================================================================
Meeting started by sgallagh at 15:02:08 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-11/fedora-meeti...
.
Meeting summary
- ---------------
* roll call (sgallagh, 15:02:18)
* Firewall (sgallagh, 15:07:05)
* AGREED: If the user hasn't specified firewall status explicitly,
interactive role deployment will inform the user whether the
service's ports have been opened by default" to either the 2nd or
the 3rd paragraph of the Firewall section of the tech spec. It must
be possible to query the API for the required state of the firewall
to support the role, which can then be compared to the active
firewalld state. (sgallagh, 15:23:59)
* ACTION: sgallagh to update the Technical Specification with this
phrasing (sgallagh, 15:24:12)
* Implementation of Roles (sgallagh, 15:25:00)
* For Fedora 21, we address upgrade compatibility through policy
rather than enforcement. Any core piece of a Role is expected to
coordinate with that Role before upgrading (the responsibility is on
the package maintainer, not the Role owner). (sgallagh, 16:04:21)
Meeting ended at 17:00:25 UTC.
Action Items
- ------------
* sgallagh to update the Technical Specification with this phrasing
Action Items, by person
- -----------------------
* sgallagh
* sgallagh to update the Technical Specification with this phrasing
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (150)
* mizmo (90)
* simo (78)
* adamw (77)
* mitr (54)
* nirik (32)
* zodbot (8)
* tuanta (7)
* Evolution (0)
* davidstrauss (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMfQYYACgkQeiVVYja6o6PXqQCfTF6cYtsjd1jlLuBEtrGM94a6
WDEAn3o14CNRZx628DVk0TsjqPbm83pk
=hShy
-----END PGP SIGNATURE-----
9 years
Call for Agenda for Server WG Meeting (2014-03-11)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Suggested items:
* Finalize firewall decision (I think the thread on the list has
mostly come to a close)
* Implementation discussion of Roles.
Also, the USA has its DST shift this weekend. In general, do we want
to keep the same UTC time (so US attendees shift to 10am EDT/7am PDT)
or do we want to push it back one hour UTC?
I know that 7am is hard for PDT, but 6pm may also be difficult for CET.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMZ0MwACgkQeiVVYja6o6Nv9wCgqxwVcM+V5a8Who0Pwj/g3Iwy
QGQAoKo/CyLo/qSa3S0O1iwNdGdEgyM4
=M9/Z
-----END PGP SIGNATURE-----
9 years
Comparison to Workstation Technical Specification
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So, the Workstation group has done a truly fantastic job these last
couple of weeks designing their Technical Specification[1]. At today's
Server WG meeting, the topic came up about the "Core Services and
Features" section of this document. I think that much of it is reusable
for the Server Technical Specification, so I'm going to go through it
and make comments and recommendations. Please add your own thoughts and
I'll get them up on the wiki tomorrow.
> === File system ===
>
> The default file system type for workstation installs should be
> btrfs.
The default file system is definitely up for some debate, but I'd make
an argument for using XFS atop LVM[1] for the default filesystem in
the Fedora Server, at least in part because Red Hat's storage experts
have done the research for us already and determined that XFS is the
recommended fit for Red Hat Enterprise Linux 7.
Btrfs still makes me somewhat nervous, given that its upstream doesn't
consider it stable[3].
>
> === Service management ===
>
> Systemd provides ways to control and monitor the activity and
> status of system services, resources they require, etc. System
> services are expected to provide systemd units. See the systemd
> [http://0pointer.de/public/systemd-man/systemd.unit.html
> documentation].
>
I think we want to go along with this, but make a stronger statement
about systemd units.
"System services *must* provide systemd units to be included in the
Fedora Server standard installation."
> === Logging ===
>
> The systemd journal will be used as the local storage backend for
> system logs. For 'managed' scenarios (e.g the 'developer in a
> large organization' use case of the PRD), it will be possible to
> collect the logs in a centralized location, off the local machine.
>
> Applications and services can either use the syslog API or the
> journal APIs for their logging. See the journal API
> [http://0pointer.de/public/systemd-man/sd-journal.html
> documentation].
>
I agree with this as well. We should focus on the use of journald as
the preferred log aggregator and make sure that it is fully capable of
aggregating those logs centrally. The advantages provided by
journald's structured logging will make processing of those logs much
easier.
That said, for the immediate future I think we also need to mandate
that the system MUST continue to be capable of exporting traditional
syslog messages to existing log aggregation systems.
> === Networking ===
>
> Network devices and connections will be controlled by
> NetworkManager. This includes support for VPN, which is relevant
> for 'corporate' scenarios. Applications are advised to use
> higher-level APIs (such as
> [https://developer.gnome.org/gio/stable/GNetworkMonitor.html
> GNetworkMonitor] in GIO) to monitor online status.
>
This is going to be the contentious point, I expect. We've already
seen some chatter on this list around systemd-networkd and of course
there's a long history of wariness around NetworkManager as a
replacement for traditional network scripts.
This will need to come to a vote, but here are my feelings on the matter:
== Network Scripts ==
+ Powerful, stable and widely deployed.
- Configuration requires modification of a large number of plaintext
files. Central management of this configuration is difficult and
generally requires tools like Puppet and Chef to be deployed to do
so reliably.
- Complex configuration is highly prone to accidents necessitating a
visit from the "crash cart" in the data center.
== Network Manager ==
+ Powerful and (now) stable with support for enterprise features like
bridging and bonding.
+ Consistent API allows for simplified configuration with fewer
opportunities for producing an unusable system.
+ Default networking stack for RHEL 7 means it will get considerable
bugfixing resources allocated to it.
- Requires a running daemon on the system (though work is under way to
have the daemon shut down except when needed)
- Bad PR history means that some administrators view it unfavorably
== systemd-networkd ==
+ Very low overhead, tight integration with low-level plumbing
- Immature with few features. Only saw its first release this month.
- Not currently available on Fedora[4]
My personal view is that NetworkManager is the best option *today*
(understanding full well that there will need to be a fair amount of
marketing effort to educate people on how far it has come in the last
couple years), while systemd-networkd may become a highly interesting
option in the future. Given our focus in Fedora Server on making
configuration more approachable, I can't really see us recommending
network scripts as the *default* offering.
> === Firewall ===
>
> A firewall in its default configuration may not interfere with the
> normal operation of programs installed by default.
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.
> 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).
> === SELinux ===
>
> SELinux will be enabled in enforcing mode, using the targeted
> policy.
>
+1000
The base install and all approved Server Roles must operate in
targeted enforcing mode.
> === 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
> 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.
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)
> === Session tracking ===
>
> Logind will be used as the session tracking facility.
>
> Applications that need to interact with sessions can use the
> logind
> [http://www.freedesktop.org/software/systemd/man/sd_session_is_active.html
>
>
library API], the
> [http://www.freedesktop.org/wiki/Software/systemd/logind/ D-Bus
> API], or a higher-level API
>
+1
> === 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).
> === 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.
For single-server manipulation, I think we should focus on supporting
yum/dnf.
> === 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).
> === 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.
> === 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.
> === 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.
> === Input Methods ===
>
> The input method framework on the workstation is provided by ibus.
> Input methods and keyboard layouts can be configured in the
> control-center, and selected in shell keyboard menu. The supported
> application toolkits all support ibus.
>
I'm not sure this is a situation we need to get ourselves involved in.
Most interaction will be in the shell, so hopefully the LOCALE setting
will be sufficient.
> === 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
> === 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
> === 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 :)
> === Application Integration ===
>
> Installed applications are expected to install a desktop file in
> /usr/share/applications and an application icon in the hicolor
> icon theme.
>
> Packaged applications are also expected to provide
> [http://people.freedesktop.org/~hughsient/appdata/ appdata] for
> use in the application installer.
>
Not applicable
> === System Installer ===
>
> The desired installation experience for the workstation product is
> to limit the pre-installation user interaction to the minimum. The
> storage configuration UI should be focused on the classes of
> hardware that are expected in workstation-class machines. Package
> selection is not necessary: the installer will install the
> workstation product as defined. Tweaks, customizations and software
> additions should be performed after the installation.
>
> One aspect of storage configuration that will be needed is support
> for dual-boot setups (preserving preexisting Windows or OS X
> installations), since e.g. students may be required to run
> software on those platforms for their coursework.
>
> gnome-initial-setup already provides support for post-install user
> creation, language selection, timezone configuration, etc. If
> necessary, it should be extended to cover all required setup
> tasks.
I'm not even sure where to begin here. The system installer discussion
probably needs to have its own thread.
[1] https://fedoraproject.org/wiki/Workstation/Technical_Specification
[2] I haven't got an opinion on traditional LVM vs. thinly-provisioned
LVM at this point.
[3] https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F
[4]
http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMNAD8ACgkQeiVVYja6o6PGOACeLR2p4SRhi6KBbWnxzfTITZ4Q
TbcAn2g/I74nS15SPMjA39w8ZY9t+7RX
=LE7h
-----END PGP SIGNATURE-----
9 years
Fedora server implementation straw man
by Kevin Fenzi
ok, so I figure I will see if I can't get some discussion going on
implementation plans. Here's a straw man proposal for everyone to knock
holes in and propose better ways to do our implementation. ;)
* Our deliverable will be a iso image similar to the current netinstall
iso image. It will be that + all packages needed to install/deploy
our featured roles and base things they need. This will allow
installing from the net or using the iso stand alone to install
server roles.
* We add comps groups for each featured server role we support. So, for
example: 'server-freeipa'. This comps group has all the packages
listed we want to install to setup the role as we determine is best.
This may include packages that are not direct dependencies on the
server pacakges.
* The roles use cockpit to manage and configure the server role post
install. If there's a way (not sure if there is), we could look at
adding a anaconda 'spoke' for the server install that runs this at
install time for folks that want to configure then? Or on firstboot.
* We create a new fedora-server-$role package for each role. This role
package contains the 'glue' we add to turn this into a fedora server
role from just a install with the packages and local config. We will
need to come up with guidelines and what these packages will contain,
but:
1 A way to express what items should be monitored when the role is
installed/running. Perhaps /etc/server/$role/monitoring/ports and
processes and such.
2 A way to express data that should be backed up if you want to
backup the role. Perhaps /etc/server/$role/backups/datadirs and
configdirs or databases.
3. We may want to change systemd presets to indicate things that
should be running/enabled/etc when the role package is installed.
4. Anything else we need to impement an "API" for roles. Are we going
to define this soon?
5. We can tie this package to specific versions of requirements. So,
for example, if there's a new freeipa update and we haven't valided
fedora-server-freeipa with it, the requirement can be on the older
version and the users will not be updated until we push an update to
this package.
6. We setup specific bodhi requirements (like critpath) for server
role packages, requiring specific testing before they can go stable.
7. We may have a fedora-server-base or fedora-server-common package
to contain common/base stuff all roles need/user and make the role
packages require it. We would need to be very careful about updates
of this however.
* Users can install fedora-server-freeipa via yum/dnf after the fact,
or via the iso image/anaconda.
* Users can decide they don't care about our valueadding/glue and
remove fedora-server-freeipa and it will just go back to a machine
with all those packages installed (ie, uninstalling shouldnt
hopefully do anything other than allow them to remove required
packages and ignore our old glue).
ok. Poke holes away. ;)
kevin
9 years
Call for votes: Server Technical Specification
by 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-----
9 years
multi-instantiating services via systemd
by Colin Walters
Hi,
So we haven't talked a huge amount about Docker here, but one of the
key advantages I see that it brings to the table is
"multi-instantiating" services. This is where the RPM model for things
like apache is weak.
RPM encourages a one-to-one relationship between the package (binaries)
and its datastore. For example, httpd and /var/www/html.
Of course many services that it makes sense to "multi-instantiate" can
be easily configured to do so - but you're more "on your own" if you do
so. Again for example with httpd, you have to carefully label your new
directories as httpd_sys_content_t.
So here's the idea (and this also plays into how I am dealing with /var
with OSTree) - what if we patched services like httpd to read an
environment variable that systemd set (say SYSTEMD_UNIT), and assume
they find data named after that environment variable?
With apache, it would look in
/var/www-$(SYSTEMD_UNIT)/html
The benefit of this level of indirection would be that you could do:
$ ln -s /usr/lib/systemd/system/httpd.service
/etc/systemd/system/httpd-mycustomer01.service
$ systemctl start httpd-mycustomer-01.service
Now if we get to the ideal where all directories in /var are generated
via systemd-tmpfiles, when you started this unit systemd would
precreate /var/www-$(SYSTEMD_UNIT) and also take care of SELinux
labeling.
We'd like also want to read /etc/httpd-$(SYSTEMD_UNIT) instead of the
default as well.
If we took this to the ultimate conclusion, we'd probably discourage
these services from having any default configuration at all. You
wouldn't start httpd.service, you'd always make unit files after vhosts.
9 years