February 2014 - server - Fedora mailing-lists

Comparison to Workstation Technical Specification
by Stephen Gallagher 10 Mar '14

10 Mar '14

-----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.ht… -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMNAD8ACgkQeiVVYja6o6PGOACeLR2p4SRhi6KBbWnxzfTITZ4Q TbcAn2g/I74nS15SPMjA39w8ZY9t+7RX =LE7h -----END PGP SIGNATURE-----

23 67

Fedora server implementation straw man
by Kevin Fenzi 07 Mar '14

07 Mar '14

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

13 33

Call for votes: Server Technical Specification
by Stephen Gallagher 05 Mar '14

05 Mar '14

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

15 30

multi-instantiating services via systemd
by Colin Walters 03 Mar '14

03 Mar '14

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.

3 4

Server Technical Specification Working Session Minutes (2014-02-28)
by Stephen Gallagher 28 Feb '14

28 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================== #fedora-meeting-1: Server Technical Specification Working Session (2014-02-28) ============================================================================== Meeting started by sgallagh at 15:00:33 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-28/fedora-meeting… . Meeting summary - --------------- * roll call (sgallagh, 15:00:48) * Logging (mitr, 15:32:40) * "Server will by default store log files locally, and to the maximum extent possible support sending full log data to an external server. For writing to logs, we recommend the syslog or journal APIs, rather than managing application-specific log files. An API for reading the logs will be provided through OpenLMI. We will use rsyslog for forwarding data to a central server. Programs using the recommended APIs will have th (sgallagh, 16:00:31) * Doc will be updated but left unapproved until voting (sgallagh, 16:00:53) * System Installer (sgallagh, 16:02:23) * Updated this section to include note that kickstart (as implemented by pyKickstart and Anaconda) is the supported unattended installation mechanism (sgallagh, 16:02:53) * Firewall (sgallagh, 16:03:08) * Closing Remarks (sgallagh, 17:05:04) * ACTION: sgallagh to fix up the draft and call for a vote by Monday. (sgallagh, 17:05:29) Meeting ended at 17:11:43 UTC. Action Items - ------------ * sgallagh to fix up the draft and call for a vote by Monday. Action Items, by person - ----------------------- * sgallagh * sgallagh to fix up the draft and call for a vote by Monday. * **UNASSIGNED** * (none) People Present (lines said) - --------------------------- * sgallagh (154) * simo (135) * mitr (97) * adamw (51) * nirik (34) * zodbot (4) * pjones (1) * Evolution (0) * tuanta (0) * davidstrauss (0) * mizmo (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/ iEYEARECAAYFAlMQw74ACgkQeiVVYja6o6Nw6wCdHhDXmXmL82KQBDc5/Jxc1Pez VQ0An2qNr+JDnpKpEt8Ptm34XJDXegmE =mC10 -----END PGP SIGNATURE-----

1 0

Server Technical Specification: Agenda and First Draft
by Stephen Gallagher 28 Feb '14

28 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've created a wiki page[1] for the Technical Specification that we are working on. I've copied much of the structure from the Workstation tech spec, as it was well organized. There are quite a few sections in it that I have tagged as UNAPPROVED. I believe we need to make these the agenda for the Tech Spec Working Session today. What we will do is quickly go through each of them. We'll mark any that are uncontested as "Approved" and then go back and discuss any that need discussion. [1] https://fedoraproject.org/wiki/Server/Technical_Specification -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMQkbIACgkQeiVVYja6o6PG+wCeNSl8khjCant8UYUGkTNW+67J UaEAnjBKT+3yIwC+527f7I5grKKQNmCE =czbY -----END PGP SIGNATURE-----

2 1

Re: default file system, was: Comparison to Workstation Technical Specification
by Chris Murphy 27 Feb '14

27 Feb '14

On Feb 26, 2014, at 5:33 PM, Josef Bacik <josef(a)toxicpanda.com> wrote: > > Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. > > OK good, that's definitive. Thanks Josef. So my thought is Workstation WG choices: parity with Server WG, whatever they choose; or plain ext4; or keep things the same with LVM + ext4. And on the question of an alternate choice (what currently appears in the Automatic/Guided path's Partition Scheme pop-up menu) the WG's might consider this too, even whether an alternate is desired. Because from a my personal QA perspective, I'd like to see the two products agree on either the default or an alternate so we don't have four total possible paths combined, which today means 100 testable outcomes. One or two paths is ideal; three might be OK. Four is like… chickens with no heads, running. Chris Murphy

6 7

Re: default file system, was: Comparison to Workstation Technical Specification
by Chris Murphy 27 Feb '14

27 Feb '14

On Feb 26, 2014, at 1:54 PM, Kevin Fenzi <kevin(a)scrye.com> wrote: > Another aspect of xfs we may want to investigate and get feedback from > filesystem folks is how well xfs works on 32bit these days. > > RHEL7 doesn't have a 32bit version in their beta, so they only need to > support 64bit xfs. Does the fact that we expect to have 32bit > workstation and/or server weigh into this decision any? I think the only limit is 16TB max file system, so off hand I'd say no. But this also applies to ext4. I just tested with 3.13.4-200.fc20.i686+PAE. XFS (sdc): file system too large to be mounted on this system. EXT4-fs (sdc): filesystem too large to mount safely on this system. The same 32-bit kernel mounts a 20TB Btrfs volume with no complaints, so I don't know its limit. http://paste.fedoraproject.org/80784/93470280/ XFS mounts with inode64 by default, same as x86_64. So that's good. Chris Murphy

3 4

Server Technical Specification Working Session Minutes (2014-02-27)
by Stephen Gallagher 27 Feb '14

27 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================== #fedora-meeting-1: Server Technical Specification Working Session (2014-02-27) ============================================================================== Meeting started by sgallagh at 15:00:35 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-27/fedora-meeting… . Meeting summary - --------------- * roll call (sgallagh, 15:00:47) * Supported Architectures (sgallagh, 15:08:48) * AGREED: Fedora Server will support ix86, x86_64 and armv7hl architectures on the XFS filesystem (+5, 0, -0) (sgallagh, 15:25:55) * Partitioning and LVM (sgallagh, 15:26:04) * By default, /tmp should be on disk, not a tmpfs (mitr, 15:51:10) * ACTION: sgallagh to talk with anaconda devs about guided vs. custom partition changes (sgallagh, 15:54:18) * For anaconda discussions: 1) do we eliminate the option or give choice - talk to anaconda, 2) do we want LVM by default, 3) thinp by default (sgallagh, 15:56:02) * AGREED: Fedora Server would prefer a single choice for the guided storage setup (+5, 0, 0) (sgallagh, 16:14:42) * AGREED: Fedora Server would prefer the use of LVM backing the non-/boot partitions (+5, 0, 0) (sgallagh, 16:15:11) * No consensus was reached on the topic of LVM thin-provisioning (sgallagh, 16:15:26) * Keep in mind the multiple-disk installation case. (sgallagh, 16:32:25) * Firewall (sgallagh, 16:40:09) * AGREED: Fedora Server will enable firewalld by default (+5, 0, 0) (sgallagh, 16:40:11) * Server Desktop (sgallagh, 16:40:18) * Software Installation (sgallagh, 16:57:58) * AGREED: Available packages will be shown based on the selected install source. Fedora Server will not restrict any from being installed, but does not commit to supporting anything not part of the Roles. (+5, 0, 0) (sgallagh, 17:03:28) Meeting ended at 17:03:33 UTC. Action Items - ------------ * sgallagh to talk with anaconda devs about guided vs. custom partition changes Action Items, by person - ----------------------- * sgallagh * sgallagh to talk with anaconda devs about guided vs. custom partition changes * **UNASSIGNED** * (none) People Present (lines said) - --------------------------- * sgallagh (194) * simo (174) * adamw (77) * nirik (66) * mitr (53) * jwb (31) * pjones- (13) * mizmo (10) * zodbot (6) * tuanta (4) * spot (3) * andreasn_ (3) * abadger1999 (2) * 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/ iEYEARECAAYFAlMPcHQACgkQeiVVYja6o6NbMgCbBntagVCds7opBnb9YewVVcUG VaUAn1G7JZCd6xbVRxAx90ZyGf9p5Or5 =H4R5 -----END PGP SIGNATURE-----

1 0

PRDs/Tech Specs to formal Change Proposals and Change submission deadline
by Jaroslav Reznik 27 Feb '14

27 Feb '14

Hi, at yesterday's FESCo meeting, it was agreed on setting deadlines for Change submission for Fedora 21 [1] and to process PRDs into Change proposals. "AGREED: Fedora Changes Process submission deadline for system-wide changes is April 7th. Deadline for true standalone changes will be sometime later than that. Changes to how fedora is produced for fedora.next are still due on March 3rd. (+7,0,0) (nirik, 18:29:42)" Current deadlines: * March 3rd: Technical Specifications for products & and changes needed for products and deliverables --- very soon! * April 7th: System Wide Changes submission deadline Working Groups teams, please, try to "transform" required changes for your products from PRDs/Technical Specifications into standalone Change proposals (between March 3rd and April 7th). It will help us to scope the release. Also all changes would be trackable the standard way we do it and it's going to help transparency (as Change announcements are being to be part of the process). Self Contained Changes submission deadline will be set later, after the System Wide deadline. If you expect your proposed Self Contained Change will be on the edge and could be escalated to the System Wide, please try to submit it as early as possible too. As some Fedora.next details will be clarified later in the process, System Wide Changes submitted after the deadline will be approved case by case, even after submission deadline. For the details about the Change process, see my previous email to the devel announce list [2]. Thank you for your help with Change process and let me know in case of any questions. Jaroslav [1] https://fedorahosted.org/fesco/ticket/1178 [2] https://lists.fedoraproject.org/pipermail/devel-announce/2014-February/0013…

1 0

Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
by Adam Williamson 27 Feb '14

27 Feb '14

On Fri, 2014-02-21 at 17:08 +0100, Phil Knirsch wrote: > Installer is still a hot topic, but thats nothing we could resolve > during our meeting and which might have to be brought up with FESCO again. So, as cmurf has been trying to point out on desktop@ , we (QA) have some concerns in this area too, and I know the installer team is open to the idea of at least simplifying the non-custom partitioning path to some extent. This is an extremely complex topic area, though, and it may be tricky to get the right things done if multiple teams are considering it in different contexts in different meetings. It would probably be a Very Good Idea to get everyone with an interest - at least anaconda team, the product WGs (except possibly Cloud, depending on whether they intend to use anaconda in their deliverables at all), base WG, and fesco - together in some way to talk about it. devconf would've been great but it already happened. Flock would be great but it's too late. Should we try to set up some kind of special meeting / list / etherpad / wikipage / *something* where we can all talk it over? To give a bit of background and detail in QA's interest: First, to ensure everyone actually knows what we're talking about, we tend to talk about two major partitioning 'paths' in anaconda: 'guided' and 'custom'. 'custom' may also be referred to as 'manual'. In both newUI and oldUI, 'guided' is simply what you get if you don't pick custom partitioning, when you are given the opportunity to do so. In oldUI, you had the screen which gave you about five choices of different partitioning 'approaches' (reformat the entire disk(s), reformat only the Linux partitions, resize existing partitions to create free space, just install into free space, maybe one or two others I forgot). In newUI there's a different workflow after you pick target disks on the Installation Destination spoke which, broadly, accomplishes the same options in a rather different way. Broadly, QA is interested in doing something similar to what desktop wants to do, for slightly different reasons. Historically, QA and anaconda more or less agreed on an approach whereby the 'guided' partitioning path would be expected to work extremely reliably: QA would undertake to test every (well, nearly every) route through that path regularly and proactively, and anaconda would undertake to fix the bugs. Custom partitioning was much more of a 'bonus' thing: if it worked, great. QA would test it as much as we had time for, and anaconda would fix as many bugs as they could after fixing higher priority stuff. I went back and looked at the history, and in the earlier days of Fedora, the guided path was consciously designed to be very 'choice free'. Later in the 'oldUI' days, the path to more complexity in the 'guided' path was opened up by a sort of hack. Some people did not want LVM (after it was made default waaaaay back in FC3 or something), and eventually this demand became so persistent that it was decided to stick a checkbox in the 'guided' partitioning path which let you get a plain ext(3/4) layout instead of an LVM layout. This was always a kind of ugly compromise, it wasn't intended to be a design decision. It was manageable, because a plain ext3/4 layout is a fairly simple thing that isn't likely to break much. This context was kind of lost in the newUI re-design, and the 'I don't want LVM' checkbox kind of got a promotion. It's not a very good UI, and the point of the newUI stuff was to make the UI better, so instead of this 'special' checkbox, newUI used a dropdown menu - and because we were all ra-ra for btrfs at the time and expecting it to be the default Real Soon Now, and we thought we should make it easy for people to test the thing that was soon going to be the default, it got btrfs added. So in F18 we had a dropdown with "LVM", "ext4" and "btrfs" choices (IIRC). With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex. By F20 we'd really kind of lost track of the initial intent, so no-one (including QA) really worried much about adding LVM thinp to the drop-down - it's a drop-down! it's for choices! - and now, we've got *four* major choices on the path that was originally supposed to be very dependable and choice-free and testable and maintainable, and of course we wound up shipping one of them entirely broken out of the box. QA and anaconda have already discussed this and, I think, we came to a tentative agreement that we could look at at least reducing the level of choice in 'non-custom' partitioning, and remembering the original intent we had (which I think both QA and anaconda teams quite like). It may be difficult to entirely drop the selection, but it seems at least reasonable to go back to only having one 'plain partition' choice and one 'LVM' choice (whether it's 'regular' LVM or thinp LVM), and relegating other choices to the 'custom' path. QA's angle on this is that it's really extremely difficult to develop a plausible set of storage release criteria and validation tests with the current situation. If we map out all the possible paths through the 'non-custom' path it still comes out to something like 80, given the current level of choice, and it's pretty impractical to test 80 different routes at every TC/RC build. Or even at every milestone. So if we don't change the design, QA is effectively forced to test only a reduced subset of the 'non-custom' path choices, whether we *plan* to do that or we pretend we're going to test them all but, inevitably, don't. Yet the installer design doesn't really communicate in any way that some paths through 'non-custom' install are more tested/reliable than others. Anyhow, that's kind of where we left off back in December or January, and we probably really ought to get around to looking at this again - and, as I said, incorporating the perspectives of the different Product WGs and the question of variant anacondas (whether any of the Products actually wants one, and if so, whether that's actually viable) pretty soon. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

9 13

Fedora Board Working Group PRD approval
by Josh Boyer 26 Feb '14

26 Feb '14

The Board has reviewed the PRDs for the Cloud, Server, and Workstation products and approves. While there are some reservations in certain areas, the overall goals of each product seem to be well thought out and an benefit to Fedora going forward. Thank you for taking the time to work through these issues. As a next step, the Board would like to see FESCo and the Working Groups discuss marketing of these products, both individually for each product and collectively as the Fedora project deliverables. The Board, FESCo, WGs, Marketing, Ambassadors and web sites team should come up with a broader marketing/branding plan to make the transition to a three main product deliverable world as clear and effective as possible. We look forward to working with these groups in the near future. -The Board

1 0

Re: default file system, was: Comparison to Workstation Technical Specification
by Bill Nottingham 26 Feb '14

26 Feb '14

Kevin Fenzi (kevin(a)scrye.com) said: > Another aspect of xfs we may want to investigate and get feedback from > filesystem folks is how well xfs works on 32bit these days. > > RHEL7 doesn't have a 32bit version in their beta, so they only need to > support 64bit xfs. Does the fact that we expect to have 32bit > workstation and/or server weigh into this decision any? We expect to have a 32-bit workstation or server? Not trying to troll, but I don't know that any of these were specifically discussed or specified in the products - are there any arches where Fedora currently exists that we don't necessarily care about having a particular product on? (For example, if you expand to secondary arches, I'd question the idea of s390 Workstation.) Bill, who does have a 32-bit x86 server under his home desk...

2 1

Re: default file system, was: Comparison to Workstation Technical Specification
by Chris Murphy 26 Feb '14

26 Feb '14

On Feb 26, 2014, at 8:13 AM, Michael Cronenworth <mike(a)cchtml.com> wrote: > Ext4 has its btrfs conversion tool. Changing from ext4 to XFS, for arguably negligible benefits for Workstations, will make it more difficult for Fedora users to transition to btrfs. It's an unlikely path because a.) by default we put ext4 on LVM; b.) the convert tool uses ext4 block size to set btrfs leaf size; c.) the convert tool doesn't set extref, although it easily could. The last two are a cake walk to change compared to the first. On Feb 26, 2014, at 8:20 AM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote: > I agree switching from ext4 to XFS is likely not worthwhile. Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile for Workstation WG to mimic it merely due to simplicity because then we don't need separate installers or composes. On Feb 26, 2014, at 8:24 AM, David Cantrell <dcantrell(a)redhat.com> wrote: > > I think filesystem variance across different Fedoras really impacts QA more > than us. We already support a lot of filesystems, but the real hit is the > QA test matrix. QA already tests the file system layouts being discussed. Perhaps the least tested is XFS on LVM only because the XFS test case doesn't specify LVM, so testers probably split and do some plain partition and some on LVM. If Server WG decides on XFS, it effectively increases the Automatic/Guided/easy/default installer path's "Partition Scheme" pop-up from four to five options, and that is a problem. Adamw and I are working on a proposal to reduce these options to one or two: i.e. a WG chosen product specific default, and maybe "one other" which is decided by Base WG or FESCo. Chris Murphy

5 4

Updated Event Invitation: Technical Specification Working Session
by Stephen Gallagher 26 Feb '14

26 Feb '14

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:20140226T180310Z DTSTAMP:20140226T180310Z UID:c9b04c0e-1158-443f-9059-96fb521d882c SUMMARY:Technical Specification Working Session 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=DAILY;UNTIL=20140228T150000Z DTSTART;TZID=America/New_York:20140227T100000 DTEND;TZID=America/New_York:20140227T120000 DESCRIPTION:We need to sit down and hash out the remaining issues on the F edora Server Technical Specification. I am booking two sessions (Thursday and Friday)\, though I hope not to need both.\n\nPlease join us in #fedora -meeting-1 on Thursday if you would like to participate. LOCATION:#fedora-meeting-1 CLASS:PUBLIC TRANSP:OPAQUE SEQUENCE:2 END:VEVENT END:VCALENDAR

1 0

Updated Event Invitation: Technical Specification Working Session
by Stephen Gallagher 26 Feb '14

26 Feb '14

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:20140226T180107Z DTSTAMP:20140226T180107Z UID:c9b04c0e-1158-443f-9059-96fb521d882c SUMMARY:Technical Specification Working Session 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=DAILY;UNTIL=20140217T150000Z DTSTART;TZID=America/New_York:20140227T100000 DTEND;TZID=America/New_York:20140227T120000 DESCRIPTION:We need to sit down and hash out the remaining issues on the F edora Server Technical Specification. I am booking two sessions (Thursday and Friday)\, though I hope not to need both.\n\nPlease join us in #fedora -meeting-1 on Thursday if you would like to participate. LOCATION:#fedora-meeting-1 CLASS:PUBLIC TRANSP:OPAQUE SEQUENCE:1 END:VEVENT END:VCALENDAR

1 0

boot.fedoraproject.org as a deliverable
by Chris Murphy 25 Feb '14

25 Feb '14

At boot.fedoraproject.org none of the available downloads are UEFI compatible. There is a UEFI pxe boot test case so it looks like it ought to work, but I thought I'd point out that at the moment it's unclear how to do this on UEFI. [1] http://fedoraproject.org/wiki/QA:Testcase_UEFI_pxeboot (This test case might be outdated as it references bootia32, but we aren't supporting 32-bit EFI right now.) Chris Murphy

2 2

Meeting Minutes / February 25, 2014
by Máirín Duffy 25 Feb '14

25 Feb '14

Summary: * Roll call (adamw, 16:00:51) Target roles for F21 (adamw, 16:06:48) ====================================== * AGREED: Domain Controller is accepted as the "primary blocker * AGREED: Database Server is accepted as the "secondary target" role for Fedora 21 (+9/-0) (adamw, 16:10:04) * AGREED: PostgreSQL is accepted as the "initial" database for Fedora 21 (7 pgsql, 1 mariadb, 1 abstain) (adamw, 16:11:11) Install media and high-level view of default packages (adamw, 16:11:53) ======================================================================= * PRD states "Fedora Server will produce two main installation resources, a netinstall image and an offline install iso image that allows one to install and configure featured roles offline." (adamw, 16:13:29) * AGREED: initial maximum size for offline ISO is 4GB (+5/-0) (adamw, 1:18:45) ** AGREED: one deliverable for Fedora 21 will be a 'traditional install' style ISO image capable of deploying the roles we consider ready for release without a network connection (adamw, 16:32:10) * http://boot.fedoraproject.org/download (nirik, 16:34:26) * AGREED: we also plan a minimal deliverable of some kind for Fedora 21, which could be a 'traditional' netinstall image, a boot.fedoraproject.org-style 'anacondaless' image, or just a variant method of deployment from the 'full' deliverable: this requires further consideration (adamw, 16:46:14) * AGREED: sshd will be installed, enabled and running by default when deploying Fedora Server (adamw, 16:58:01) * https://fedoraproject.org/wiki/Server/Polish_Ideas #3 here is how i added it (mizmo, 17:04:43) Action Items ============ * ACTION: sgallagh to send out a mail regarding 'core dependencies' for discussion (adamw, 17:06:28) * ACTION: sgallagh to send a whenisgood for a follow up meeting later this week to discuss the rest of the things we have to settle (adamw, 17:12:14) * ACTION: sgallagh to send whenisgood request for Thursday/Friday (sgallagh, 17:13:25) Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-25/server-wg.2014… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-25/server-wg.2014… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-25/server-wg.2014…

1 0

WG Vote: Server Roles for F21
by Stephen Gallagher 25 Feb '14

25 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have about a week left to formulate our technical document for Fedora 21. To that end, I'd like to call a formal vote of the Working Group on two of the key points: which two roles to focus on for the initial release. Vote A) "Domain Controller" role is our primary blocker target for Fedora 21. Vote B) "Database Server" roles is our secondary target for Fedora 21 Vote B2) If Vote B is approved: MariaDB or PostgreSQL as our initial database. (This does *not* exclude the possibility of creating a Role for the other one in the future, but it sets our priority for this cycle). If these are approved, we will need to start documenting our technical needs to deliver these Roles. A non-exhaustive list: * Public API for setup and configuration (D-BUS based?) * Packages and meta-packages to support it * List of firewall rules/configuration * List of data to back up; possible API to accomplish this * (Human and non-human) resources needed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMHrYcACgkQeiVVYja6o6ORtgCfTw/ocGzzazXlEVmkVp6uLb0V lE4AnifptRBkNQ11UNFx2jlzvorIaBDw =wO32 -----END PGP SIGNATURE-----

10 10

random suggestion: system_identification from CSI / Fedora Infrastructure
by Matthew Miller 25 Feb '14

25 Feb '14

When you ssh into people.fedoraproject.org, you get some information including this bit: Security Category: Low Primary Contact: Fedora Admins - admin(a)fedoraproject.org Purpose: Provide hosting space for Fedora contributors and Fedora Planet This comes from http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html-sing… That's pretty neat. A lot of big organizations may have policies and a system like that, but it strikes me as something that would be neat to integrate into Fedora Server by default. -- Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>

5 5

Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
by Bruno Wolff III 25 Feb '14

25 Feb '14

On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy <lists(a)colorremedies.com> wrote: > >The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install.

6 5

Agenda for Server WG Meeting (2014-02-25)
by Stephen Gallagher 24 Feb '14

24 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So we have less than a week left to put together our technical specification for Fedora 21. We've had some discussion on picking the set of Roles to focus on for the first release. As I see it, we need to discuss and settle on at least the following items: * Target roles for F21 (vote already underway) * Install media and high-level view of default packages * Rel-eng, QA, etc. needs (There will be a separate call for help going out on this) For reference, the Workstation WG has put together an excellent technical specification document[1] and we should probably borrow from it as much as possible (both for uniformity and reduction of effort). [1] https://fedoraproject.org/wiki/Workstation/Technical_Specification -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMLYAMACgkQeiVVYja6o6OyzQCdFSYZTEzLYgyXRrLxpzo5J72G wJwAn0i53R6DhikDlTKjIbfsxeRYURgE =zfkV -----END PGP SIGNATURE-----

2 1

Deadlines
by Adam Williamson 24 Feb '14

24 Feb '14

In case anyone missed it, FESCo's minutes have this: "AGREED: FESCo expects the Tech specs/docs from working groups by March 3rd at the latest" So, we've been off meetings and stuff for three weeks now, we probably should kick back into gear soon :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

9 47

[Fedocal] Reminder meeting : Fedora Server Working Group
by Pierre-YvesChibon 24 Feb '14

24 Feb '14

Dear all, You are kindly invited to the meeting: Fedora Server Working Group on 2014-02-25 from 11:00:00 to 12:00:00 US/Eastern At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Weekly meeting to discuss issues and planning for the Fedora Server Product and SIG. More information available at: [http://fedoraproject.org/wiki/Server](http://fedoraproject.org/wiki/Server) Source: https://apps.fedoraproject.org/calendar/meeting/None/

1 0

[Fedocal] Reminder meeting : Fedora Server Working Group
by Pierre-YvesChibon 24 Feb '14

24 Feb '14

Dear all, You are kindly invited to the meeting: Fedora Server Working Group on 2014-02-25 from 11:00:00 to 12:00:00 US/Eastern At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Weekly meeting to discuss issues and planning for the Fedora Server Product and SIG. More information available at: [http://fedoraproject.org/wiki/Server](http://fedoraproject.org/wiki/Server) Source: https://apps.fedoraproject.org/calendar/meeting/None/

1 0

Self-Introduction: Jonathan Dieter
by Jonathan Dieter 14 Feb '14

14 Feb '14

I'm not sure if this is standard practice, but I figure a quick introduction is worth something. For those who don't know me in the Fedora Project, I wrote the original yum-presto plugin for using deltarpms in Fedora. I'm here because I'm the system administrator for the Lebanon Evangelical School in Beirut Lebanon, and we use Fedora pretty extensively in the school. A vast majority of our desktop systems run Fedora, and our servers are pretty evenly split between CentOS and Fedora (with one token Windows VM for our accountants). I've had good experiences with Fedora as a server (our web server has been running Fedora since 2005), as well as bad experiences (our print server has just been switched to CentOS after a really nasty permissions bug popped up in cups for Fedora 20). I've looked at the PRD, and I hope I'll be a useful participant in this WG. Jonathan

3 2

My Apresentation
by Geraldo Antonio Kuster Junior 12 Feb '14

12 Feb '14

Hello, I am new to the list My nane is Geraldo Kuster My FAS is Kusterjr I live in Brazil I Working with servers in general to more than 5 years and linux server with 1 year or so, study systems development and entered the fedora project about 6 months. I loved the idea as fedora server and therefore chose this SIG. In Fedora prroject i work an FreeMedia and Marketing group. Excuse my English I'm still learning and using Google in a few sentences. *Geraldo Antonio Kuster Jr* *Linux User: 34225*

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server February 2014