-----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.
On 17/11/15 01:39, Stephen Gallagher wrote:
(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:
- 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.
- 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
We might create a coreutils-singlebin package that is built with ./configure --enable-single-binary which would include only the single binary and stubs. I think chromium is using this setup. coreutils-singlebin could Recommends: coreutils-doc, while the standard coreutils package would require coreutils-doc. That would save about 13MB in the install. Caveat is that the single binary would dynamically link all shared libs, which associated startup and mem overhead.
cheers, Pádraig
On 17/11/15 17:03, Pádraig Brady wrote:
On 17/11/15 01:39, Stephen Gallagher wrote:
(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.
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
We might create a coreutils-singlebin package that is built with ./configure --enable-single-binary which would include only the single binary and stubs. I think chromium is using this setup. coreutils-singlebin could Recommends: coreutils-doc, while the standard coreutils package would require coreutils-doc. That would save about 13MB in the install. Caveat is that the single binary would dynamically link all shared libs, which associated startup and mem overhead.
Attached is a proposed split for coreutils.
Original coreutils (14.2MB) is now split to:
coreutils (5.5MB), coreutils-single (1.2MB) and an optional coreutils-common (8.7MB)
coreutils and coreutils-single are mutually exclusive. coreutils requires coreutils-common, though it can be forcefully removed if desired, and only docs and translations are degraded.
I.E. there are 4 possible setups now:
coreutils-single (1.2MB) coreutils-single + coreutils-common (9.9MB) coreutils (5.5MB) coreutils + coreutils-common (14.2MB)
cheers, Pádraig.
On Mon, 2015-11-16 at 20:39 -0500, Stephen Gallagher wrote:
b'NetworkManager': 138
NM does have a larger dep-chain than we'd like, however we did split the package apart a couple releases ago and made sure that WWAN, WiFi, and Bluetooth were no longer required for the server cases. Could you confirm what NetworkManager-* packages are installed on F23 server?
The largest deps should be mostly glib2, systemd/udev, NSS, and D-Bus, all of which should already be on a server install. We'd love to see if anything unexpected snuck into the dep chain.
Dan
"DW" == Dan Williams dcbw@redhat.com writes:
DW> Could you confirm what NetworkManager-* packages are installed on DW> F23 server?
On my custom install (which just lists the packages I need in my kickstart file) I have:
NetworkManager-glib-1.0.6-8.fc22.x86_64 NetworkManager-1.0.6-8.fc22.x86_64 NetworkManager-libnm-1.0.6-8.fc22.x86_64 NetworkManager-config-connectivity-fedora-1.0.6-8.fc22.x86_64 NetworkManager-tui-1.0.6-8.fc22.x86_64
I didn't realize the connectivity-fedora thing had snuck in there; I certainly didn't ask for it so it must be part of a default group. Nothing depends upon it so I'll have to exclude it manually.
- J<
On Tue, 2015-11-17 at 17:36 -0600, Jason L Tibbitts III wrote:
"DW" == Dan Williams dcbw@redhat.com writes:
DW> Could you confirm what NetworkManager-* packages are installed on DW> F23 server?
On my custom install (which just lists the packages I need in my kickstart file) I have:
NetworkManager-glib-1.0.6-8.fc22.x86_64 NetworkManager-1.0.6-8.fc22.x86_64 NetworkManager-libnm-1.0.6-8.fc22.x86_64 NetworkManager-config-connectivity-fedora-1.0.6-8.fc22.x86_64 NetworkManager-tui-1.0.6-8.fc22.x86_64
Thanks; config-connectivity-fedora would indeed be unexpected on Server. Thankfully that's just a config file and has no additional RPM requirements to pull in.
NM-tui needs newt, which pulls in slang, which isn't small (2MB on disk?). I suppose NM-tui could be pulled out of Server since not that many other things require newt, and nmcli is always going to be there anyway.
Dan
"DW" == Dan Williams dcbw@redhat.com writes:
DW> I suppose NM-tui could be pulled out of Server since not that many DW> other things require newt, and nmcli is always going to be there DW> anyway.
For some reason I thought NM-tui _was_ nmcli. There's no reason to have anything other than the command line tool in server, indeed. Some might argue that you don't even need that since you can just edit some files and restart. Are any deps there just because of nmcli?
- J<
On Wed, 2015-11-18 at 11:32 -0600, Jason L Tibbitts III wrote:
"DW" == Dan Williams dcbw@redhat.com writes:
DW> I suppose NM-tui could be pulled out of Server since not that many DW> other things require newt, and nmcli is always going to be there DW> anyway.
For some reason I thought NM-tui _was_ nmcli. There's no reason to have anything other than the command line tool in server, indeed. Some might argue that you don't even need that since you can just edit some files and restart. Are any deps there just because of nmcli?
The only additional dep nmcli pulls in is a readline library.
Dan
"JLT" == Jason L Tibbitts tibbs@math.uh.edu writes:
JLT> On my custom install (which just lists the packages I need in my JLT> kickstart file) I have:
JLT> NetworkManager-glib-1.0.6-8.fc22.x86_64 JLT> NetworkManager-1.0.6-8.fc22.x86_64 JLT> NetworkManager-libnm-1.0.6-8.fc22.x86_64 JLT> NetworkManager-config-connectivity-fedora-1.0.6-8.fc22.x86_64 JLT> NetworkManager-tui-1.0.6-8.fc22.x86_64
Please forgive me, but I have no idea where I actually ran that command. It's certainly not on the minimally installed F23 server where I intended to run it. Too many shells open, I guess.
On the proper machine:
NetworkManager-libnm-1.0.6-8.fc23.x86_64 NetworkManager-1.0.6-8.fc23.x86_64 NetworkManager-config-server-1.0.6-8.fc23.x86_64
which is pretty much what I'd expect.
On Mon, Nov 16, 2015 at 08:39:24PM -0500, Stephen Gallagher wrote:
- 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.
I want to add to this that smaller image size _also_ means less network traffic and faster deployment time, which I also hear from people as an importand factor.
- 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.
And to this: in the large institutions that I've been a part of, protesting that known vulnerabilities in code that isn't run because the daemon is off, or because there's a firewall, or whatever, gets you nowhere with the compliance people.
- 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.
Yes, there's work on this. https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging
server@lists.fedoraproject.org