On 17.11.2015 02: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: > > 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 These dependencies are really hard to read. A much more clear approach would be to see how many unique dependencies each top level feature brings in. More on that below. > == 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. Some notes about cockpit: Cockpit itself isn't very big, and most of the dependencies seen above are the system services that it can configure (ie: docker, NetworkManager, systemd, storaged). 'cockpit' is a meta-package depending on 'cockpit-xxx' subpackages. These subpackages like cockpit-docker or cockpit-networkmanager depend on things like docker or NetworkManager respectively. If the subpackages that the Fedora 'cockpit' meta-package depend on do not match what system services Fedora Server wants to ship, then we should adjust the meta-package. All that to say, the Cockpit dependencies are actually very light on top of what's already being shipped. Cockpit itself has the following dependencies. - glibc - glib2 - glib-networking - polkit - polkit-libs (*) - grep - keyutils-libs (*) - systemd-libs (*) - pam - json-glib (*) - libpwquality - shadow-utils - bash - krb5-libs - openssl The dependencies that I've noted with a star, can be theoretically removed by copying and pasting some code from those libraries into Cockpit. This seems counterproductive and counter to Fedora's posture, but it is nonetheless possible. A dependency on openssl (used for generating self-signed certificates, when none are available) could be removed by using gnutls. But not sure that would win us anything as far as disk space. Cheers, Stef
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
