Dne 17.11.2015 v 11:00 Stef Walter napsal(a): > 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.
Then the should use Recommends, shouldn't they? Vít > > 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 > > >
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
