server November 2015

server@lists.fedoraproject.org

26 participants
16 discussions

Call for Agenda for Server SIG Meeting (2015-12-01)
by Stephen Gallagher 30 Nov '15

30 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What do we have on the docket for this week? I'd like to get an update on the cloud/server interaction. Last time we discussed it, it was "reply hazy" (pardon the pun). Additionally, I'd like to discuss some more trimming of the Server DVD (removal of some packages that aren't in the default install set to reduce the DVD download size). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZcZvEACgkQeiVVYja6o6MDvgCgoztGdXFqUBd8o4rG1E5eszm5 H0cAn2Xb/P4VoVa9QaNgeZ893VmBSQqN =vHbb -----END PGP SIGNATURE-----

1 0

Call for Agenda for Server SIG Weekly Meeting (2015-11-24)
by Stephen Gallagher 24 Nov '15

24 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't have much on the agenda today. A brief status report, primarily.

1 2

Rolekit Weekly Meeting Minutes (2015-11-24)
by Stephen Gallagher 24 Nov '15

24 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ==================================== #fedora-server: rolekit (2015-11-24) ==================================== Meeting started by sgallagh at 14:33:48 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-server/2015-11-24/rolekitweekly.201… . Meeting summary - --------------- * init process (sgallagh, 14:33:49) * Agenda (sgallagh, 14:34:21) * Agenda Item: Status Update (sgallagh, 14:35:00) * Agenda Item: Nulecule Support (sgallagh, 14:35:10) * Status Update (sgallagh, 14:36:14) * sgallagh and nilsph have been going through the review process for the unit file rework (sgallagh, 14:39:55) * twoerner has been working on firewalld tasks and hasn't had time for rolekit (sgallagh, 14:40:26) * Nulecule Support (sgallagh, 14:48:26) * LINK: https://github.com/libre-server/rolekit/issues/14 (sgallagh, 14:48:48) * ACTION: sgallagh to look into fixing the Vagrant box (sgallagh, 14:54:28) * ACTION: sgallagh to work on developing a generic Nulecule deployment strategy in the next few weeks (sgallagh, 15:00:44) * nilsph volunteers to help (sgallagh, 15:00:47) * Open Floor (sgallagh, 15:01:08) * AGREED: Stick with Review Board for now, re-evaluate in the future if we start seeing a lot of new contributors (sgallagh, 15:32:09) Meeting ended at 15:38:36 UTC. Action Items - ------------ * sgallagh to look into fixing the Vagrant box * sgallagh to work on developing a generic Nulecule deployment strategy in the next few weeks Action Items, by person - ----------------------- * sgallagh * sgallagh to look into fixing the Vagrant box * sgallagh to work on developing a generic Nulecule deployment strategy in the next few weeks * **UNASSIGNED** * (none) People Present (lines said) - --------------------------- * sgallagh (86) * nilsph (37) * twoerner (22) * zodbot (12) * alxgrtnstrngl (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZUhJcACgkQeiVVYja6o6NQ9QCeJRTvEPFJvTbpKLqZEsmT5di5 GoQAn1CVzJOWD4nFw+jrAHi7ApbDbdum =O/S7 -----END PGP SIGNATURE-----

1 0

Should we continue installing docker by default?
by Stephen Gallagher 19 Nov '15

19 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Similar to my thread about the @server-hardware-support group, the @container-management group also takes up a good chunk of space (38MB above the minimal install) in the default Server install, as well as including an additional available-by-default service. Originally, we included Docker for its popularity and because Cockpit and rolekit each had some support for operating with it. In F23 and onwards, rolekit is capable of automatically-installing docker if it is required to support a role, so having it installed by default is no longer critical from that perspective. This leaves Cockpit: one of Cockpit's more popular features is the ability to manage Docker images and containers from the UI. Cockpit has the ability to start Docker on the system if it's installed but not running. I'd like to recommend that Cockpit also grow the capability to install Docker if an administrator wants to use that portion of the UI. This way, we can avoid installing it by default and just deploy it automatically once an Administrator is interested in using it. As a side-note, I think this is a policy we should consider following throughout Server: try to do lazy package installation whenever possible. Much of our philosophy in rolekit, Cockpit and realmd is around installing what we need only when we need it and an administrator has made a clear decision to use it. We should try to make that a consistent policy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZLlA0ACgkQeiVVYja6o6NGGACgjOFv9lUzM2GpJ3GnhqJGXQjs +rUAoK/8tW/PPOxSc6WZUnBSEq/8ZEol =ba62 -----END PGP SIGNATURE-----

8 12

Some analysis on the size of the minimal and Server installs of Fedora 23
by Stephen Gallagher 18 Nov '15

18 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Please keep responses on the devel@ list; I've set it in the Reply-To.) To jump right to the premise: The default Fedora Server install is Way Too Big(TM) and the minimal install (also available on the Fedora Server install media) is also Too Big. I've been trying to do some quick-and-dirty analysis of what is in these default installations in order to figure out where we should be focusing our efforts. I'll point out that there are two goals that we need to keep in mind (and the reasons behind them) in order of increasing importance: 1) Reduce disk space usage. While disk space on physical devices is becoming trivially cheap, disk space on Cloud deployments and rented virtual servers is still comparatively very expensive. We really want to minimize the amount of space that we use for Fedora so that users can fit their applications (the stuff they actually care about) into the remaining space without being forced to buy a larger storage allotment. 2) Reduce maintenance efforts. Every additional piece of software on the system (referred to hereafter as "packages") increases the maintenance burden on an administrator. Universally, administrators prefer to have the smallest number of packages to maintain for a variety of reasons: * Limiting update churn. The more packages on the system, the more often that one will need to run updates. * Limiting security exposure. Every package on the system is another potential privilege-escalation point. Keeping this number under control means a reduced likelihood of a catastrophic breach. (The actual risk here is impossible to quantify, but it can be assumed that less code == less potential vulnerabilities. * Non-expert administrators do not always know what is installed on their systems. This can lead to unintentional breaches as an admin doesn't realize that one or more services needs to be limited (such as in the firewall or via SELinux). With these two goals in mind, the most obvious approach to improving this situation would be by reducing the number of packages installed by default on the Minimal and Fedora Server installs. As a specific goal of the Server Working Group, we want to aim for a world wherein administrators will no longer desire to install the Minimal install and instead will rely on the platform provided by the default Fedora Server install. They do not do this today because the Fedora Server installation is considerably larger. I postulate that this is due primarily to dependency bloat, which is where we should focus our efforts during the Fedora 24 timeframe. I postulate (but have not yet confirmed) that there are likely many places where we could replace Requires: with Recommends: (or even Suggests:) dependencies. In my ideal world, the difference between a Minimal and Server install would be identical to installing the same set of packages with Recommends: on or off. Some highlights of my initial research (with a lot of my raw data in the tarball attached to this email): == Minimal == === Disk Usage === /boot: 79MB /: 755MB === Packages === Total count: 270 ==== Largest 10 packages ==== 14288083: coreutils 14486819: glibc 16648994: grub2 18024040: kernel-modules 27253403: systemd 28453336: python3-libs 36004297: grub2-tools 53295853: kernel-core 86298752: linux-firmware 125178630: glibc-common ==== 10 Longest dependency chains ==== b'kbd': 116 b'dnf-plugins-core': 117 b'plymouth-scripts': 121 b'plymouth': 121 b'firewalld': 122 b'grub2-tools': 125 b'grub2': 131 b'NetworkManager': 138 b'dnf': 144 b'dnf-yum': 145 == Server == == Disk Usage == /boot: 97MB [1] /: 1.2GB === Packages === Total count: 603 ==== Largest 10 packages ==== 18590064: samba-client-libs 22484896: docker 25209005: python-libs 27253403: systemd 28453336: python3-libs 30242477: libicu 36004297: grub2-tools 53295853: kernel-core 86298752: linux-firmware 125178630: glibc-common ==== 10 Longest dependency chains ==== b'abrt-addon-python3': 170 b'abrt-retrace-client': 171 b'abrt-addon-pstoreoops': 171 b'abrt-addon-ccpp': 183 b'abrt-addon-vmcore': 190 b'rolekit': 196 b'abrt-cli': 214 b'cockpit': 216 b'freeipa-client': 249 b'fedora-release-server': 252 ==== Additional Package Groups ==== (These are the package groups we include above and beyond "Minimal Install")[2] I'm not including package sizes here since most of the space comes from their dependencies. * server-product - fedora-release-server: dependency chain length: 252 - cockpit: see below - rolekit: see below - systemd: chain 104 - chrony: 468KiB, chain 111 * server-hardware-support - lm_sensors: chain 139 - openhpi: chain 108 - smp_utils: chain 19 * headless-management - cockpit: chain 216 - PackageKit: chain 137 - rolekit: chain 196 - tog-pegasus: chain 51 * container-management - docker: chain 148 * domain-client - adcli: chain 51 - freeipa-client: chain 249 - oddjob-mkhomedir: chain 107 - realmd: chain 112 - samba-winbind: chain 131 - sssd: chain 157 - samba-common-tools: chain 129 == Notes == [1] The initramfs files are larger on Server. [2] Actually, we have a difference here; Minimal Install forcibly includes the "guest-agents" group; this is only optional on Server. Some specific observations I can make: * The largest difference in the Fedora Server install vs. the minimal install is due to the FreeIPA and Samba packages requiring the inclusion of the Python 2 stack; focusing on eliminating this requirement in Fedora 24 would have the largest impact on both the number of packages and the space on disk. * The largest individual package in both deployments is the glibc-common package. This is primarily due to the 106MiB locale-archive. I'd really like to hear from glibc folks if there is something we can do to break this up into smaller pieces contained in different sub-packages with Suggests: dependencies. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZKhUgACgkQeiVVYja6o6NI/QCfWo3UaXEkfa2vpJmZFnDoYRkl NWMAn23yf2+YMEuRjWd7kiS7OfMR9RMH =3DNl -----END PGP SIGNATURE-----

5 9

What to do with lm_sensors and other server hardware support packages?
by Stephen Gallagher 18 Nov '15

18 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We currently include the following packages in the default server install: * lm_sensors * openhpi * smp_utils Of these packages, lm_sensors pulls in 33MB of dependencies (mostly PERL, including the PERL interpreter). I'm not personally sure if there's sufficient value in lm_sensors to justify installing it by default. (Pulling in an entire language interpreter just to support this one package seems like overkill). openhpi and smp_utils are far more self-contained. openhpi pulls in net-snmp-libs and libsysfs, while smp_utils doesn't have any additional deps that aren't already part of the basic system. That said, I'd like to know what people think about moving the @server-hardware-support group out of the mandatory install set and into the optional install set. All together, we're looking at about 43MB of on-disk usage for these three packages and their dependencies (above the packages in the minimal install). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZLkksACgkQeiVVYja6o6Of2gCgorzRtMbi8rSsv7f4NLshNlX1 3rwAmweyXFYl/PQRof1JoX0uCxPsWVV5 =Yeu+ -----END PGP SIGNATURE-----

4 4

[COMPS] Don't ship @domain-clients by default
by Stephen Gallagher 17 Nov '15

17 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As discussed during today's Server SIG meeting, I've updated comps.xml for Fedora 24 to no longer install the @domain-clients by default (though they are left as a selectable option in Anaconda and available on the DVD for kickstart installs). At the same time, I also dropped tog-pegasus from the @headless-management group since that was there originally to support OpenLMI, which is a dead project. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZLlMAACgkQeiVVYja6o6OtyQCfWAxhPgOBzeO53SjiZRHlJC9n mA8AoIxNoC8P99pjTI1fjpdONUpTFaEU =PEvW -----END PGP SIGNATURE-----

1 0

Server SIG Weekly Meeting Minutes (2015-11-17)
by Stephen Gallagher 17 Nov '15

17 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ========================================================= #fedora-meeting-1: Server SIG Weekly Meeting (2015-11-17) ========================================================= Meeting started by sgallagh at 16:00:22 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2015-11-17/serversig.2015… . Meeting summary - --------------- * roll call (sgallagh, 16:00:22) * Agenda (sgallagh, 16:02:51) * Agenda Item: Reducing the size of the default install (sgallagh, 16:03:30) * Reducing the size of the default install (sgallagh, 16:05:57) * "Size" is defined both as disk space and software attack surface (sgallagh, 16:06:27) * LINK: http://paste.fedoraproject.org/291483/78446144 , anyone? (adamw, 16:40:55) * AGREED: Create an optional ansible-support comps group (+7, 1, -0) (sgallagh, 17:03:57) * AGREED: Remove samba and domain-client from the default install, leave it as optional on the DVD (+8, 0, -0) (sgallagh, 17:03:57) * Open Floor (sgallagh, 17:04:06) Meeting ended at 17:11:08 UTC. Action Items - ------------ Action Items, by person - ----------------------- * **UNASSIGNED** * (none) People Present (lines said) - --------------------------- * sgallagh (147) * simo (61) * adamw (35) * mizmo-wfh (31) * jds2001 (21) * stefw (21) * nirik (18) * zodbot (13) * danofsatx (10) * pbrobinson (2) * misc (1) * acarter (1) * mhayden (0) * mizmo (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZLX8kACgkQeiVVYja6o6PFnACfUAPX9KJkPYBFhgTkZwau8YII LhgAnRFCc3Kyn53nAs+NmTX7hNZEqSBK =mw2j -----END PGP SIGNATURE-----

1 0

Invitation: Fedora Docker & Atomic Tools Demo (Live Broadcast) @ Tue Nov 17, 2015 12pm - 1pm (acarter@redhat.com)
by Amanda Carter 12 Nov '15

12 Nov '15

You have been invited to the following event. Title: Fedora Docker & Atomic Tools Demo (Live Broadcast) Hangout: https://plus.google.com/events/cjehdorihc8n7i06flabjjphk7o The hangout will be broadcast live & posted at http://www.youtube.com/watch?v=bkEXz601kM4 Q&A - #fedora-meeting-1 -- Purpose: The purpose of a demo is to show our stakeholders what we completed this iteration, get feedback from them about the changes & set some context and expectation with them about our direction. Demo Agenda ============ - Adam - update on releng docs migration - Kushal - non-gating tests in auto-cloud - Sayan - bugyou dev preview - Jay - signed repos in koji (client side, hub, task allocation changes) When: Tue Nov 17, 2015 12pm - 1pm Eastern Time Where: Hangout on Air / YouTube live stream Calendar: acarter(a)redhat.com Who: * acarter(a)redhat.com - organizer * twaugh(a)redhat.com * mmcgrath(a)redhat.com * mikeb(a)redhat.com * server(a)lists.fedoraproject.org * rel-eng(a)lists.fedoraproject.org * ttomecek(a)redhat.com * desktop(a)lists.fedoraproject.org * kasingh(a)redhat.com * rcm-tools(a)redhat.com * aos-devel * mikem(a)redhat.com * cloud(a)lists.fedoraproject.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=dGUydWJ2aTR1YzY5cXRza… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account server(a)lists.fedoraproject.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

[F24 Criteria Change] Cockpit Release Criteria
by Stephen Gallagher 10 Nov '15

10 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Recently, we discovered a bug in gnutls that caused Cockpit to be unreachable by recent versions of Google Chrome. It was ambiguous what the release criteria actually means, since it didn't specify which browser applications were blocking. I'd like to propose the following additional wording for Cockpit criteria: * All Cockpit functional criteria must be satisfied when the user is running any of the following blocking browsers: - Mozilla Firefox as shipped in the same Fedora release - Mozilla Firefox of the latest available version on Windows at compose time. - Mozilla Firefox of the latest available version on OSX at compose time. - Google Chrome of the latest available version on Fedora at compose time. - Google Chrome of the latest available version on Windows at compose time. - Google Chrome of the latest available version on OSX at compose time. Alternately, we could decide that it's only *blocking* if the above browsers work with Cockpit when the browser is running on Fedora, but that is somewhat at odds with our reasoning for having a management console as a web UI in the first place: that it is accessible regardless of the client system. Comments welcome, but please keep replies on the test(a)lists.fedoraproject.org list, as that's where criteria decisions are made. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlYpLFwACgkQeiVVYja6o6NF/wCgg6iot1JKOfmAbTZMboBcPvs5 ZIIAnA+YxRAjPMt69lqv2nOR7qXnCYnV =PIuy -----END PGP SIGNATURE-----

9 13

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server November 2015