Call for Agenda for Server SIG Meeting (2015-12-01)
by Stephen Gallagher
-----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-----
8 years
Rolekit Weekly Meeting Minutes (2015-11-24)
by Stephen Gallagher
-----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.2...
.
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-----
8 years
Should we continue installing docker by default?
by Stephen Gallagher
-----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 years
Some analysis on the size of the minimal and Server installs of Fedora 23
by Stephen Gallagher
-----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-----
8 years
What to do with lm_sensors and other server hardware support packages?
by Stephen Gallagher
-----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-----
8 years
[COMPS] Don't ship @domain-clients by default
by Stephen Gallagher
-----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-----
8 years
Server SIG Weekly Meeting Minutes (2015-11-17)
by Stephen Gallagher
-----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.20...
.
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-----
8 years
[F24 Criteria Change] Cockpit Release Criteria
by Stephen Gallagher
-----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-----
8 years
