-----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.
What i've been doing on a number of small devices lately is strip all comments from all files, which frees up a lot of disk space.
I know, this strips copyright headers.
Maybe the minimal packages can be split in two, by moving the comments to a separate package?
On Nov 17, 2015 01:25, "Martijn Ras" martijn.ras@gmail.com wrote:
What i've been doing on a number of small devices lately is strip all
comments from all files, which frees up a lot of disk space.
I know, this strips copyright headers.
Maybe the minimal packages can be split in two, by moving the comments to
a separate package?
That would be illegal in many places so I don't think so
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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:
- 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 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/17/2015 05:00 AM, Stef Walter wrote:
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:
- 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 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.
Just to loop back on this, here's the set of packages pulled in by Cockpit when installed atop "Minimal": [root@minimalrpmdeps ~]# dnf install cockpit Last metadata expiration check performed 0:38:32 ago on Tue Nov 17 15:35:02 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository
Size ================================================================================ Installing: audit-libs-python3 x86_64 2.4.4-2.fc23 fedora 96 k btrfs-progs x86_64 4.2.2-1.fc23 fedora 563 k checkpolicy x86_64 2.4-1.fc23.1 fedora 262 k cockpit x86_64 0.83-1.fc23 updates 36 k cockpit-bridge x86_64 0.83-1.fc23 updates 154 k cockpit-docker x86_64 0.83-1.fc23 updates 43 k cockpit-networkmanager noarch 0.83-1.fc23 updates 35 k cockpit-shell noarch 0.83-1.fc23 updates 618 k cockpit-storaged noarch 0.83-1.fc23 updates 42 k cockpit-ws x86_64 0.83-1.fc23 updates 390 k cryptsetup x86_64 1.6.8-2.fc23 fedora 126 k device-mapper-multipath x86_64 0.4.9-80.fc23 fedora 121 k device-mapper-multipath-libs x86_64 0.4.9-80.fc23 fedora 221 k docker x86_64 1:1.8.2-14.git8f9eabc.fc23 updates 6.9 M docker-selinux x86_64 1:1.8.2-14.git8f9eabc.fc23 updates 56 k dosfstools x86_64 3.0.28-1.fc23 fedora 111 k gdisk x86_64 1.0.1-1.fc23 updates 199 k iscsi-initiator-utils x86_64 6.2.0.873-29.git4c9d6f9.fc23 updates 424 k iscsi-initiator-utils-iscsiuio x86_64 6.2.0.873-29.git4c9d6f9.fc23 updates 84 k json-glib x86_64 1.0.4-2.fc23 fedora 131 k libatasmart x86_64 0.19-8.fc23 fedora 47 k libblockdev-btrfs x86_64 1.1-2.fc23 fedora 32 k libblockdev-utils x86_64 1.1-2.fc23 fedora 32 k libcgroup x86_64 0.41-7.fc23 fedora 67 k libsemanage-python3 x86_64 2.4-4.fc23 fedora 113 k libssh x86_64 0.7.2-2.fc23 fedora 199 k libstoraged x86_64 2.2.0-1.fc23 updates 119 k mdadm x86_64 3.3.4-2.fc23 updates 408 k mozjs17 x86_64 17.0.0-14.fc23 updates 1.4 M ntfs-3g x86_64 2:2015.3.14-3.fc23 fedora 290 k ntfsprogs x86_64 2:2015.3.14-3.fc23 fedora 297 k policycoreutils-python-utils x86_64 2.4-14.fc23 fedora 214 k policycoreutils-python3 x86_64 2.4-14.fc23 fedora 1.8 M polkit x86_64 0.113-4.fc23 fedora 127 k polkit-pkla-compat x86_64 0.1-6.fc23 fedora 43 k python-IPy-python3 noarch 0.81-13.fc23 fedora 42 k setools-libs x86_64 3.3.8-7.fc23 fedora 441 k storaged x86_64 2.2.0-1.fc23 updates 363 k storaged-lvm2 x86_64 2.2.0-1.fc23 updates 66 k tar x86_64 2:1.28-6.fc23 fedora 944 k
Transaction Summary ================================================================================ Install 40 Packages
Total download size: 18 M Installed size: 58 M
If we dropped cockpit-docker, this gets considerably smaller (and we are discussing whether to keep Docker in the default install of Fedora Server at all):
[root@minimalrpmdeps ~]# dnf install cockpit-bridge cockpit-networkmanager cockpit-shell cockpit-storaged cockpit-ws Last metadata expiration check performed 0:40:09 ago on Tue Nov 17 15:35:02 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository
Size ================================================================================ Installing: btrfs-progs x86_64 4.2.2-1.fc23 fedora 563 k cockpit-bridge x86_64 0.83-1.fc23 updates 154 k cockpit-networkmanager noarch 0.83-1.fc23 updates 35 k cockpit-shell noarch 0.83-1.fc23 updates 618 k cockpit-storaged noarch 0.83-1.fc23 updates 42 k cockpit-ws x86_64 0.83-1.fc23 updates 390 k cryptsetup x86_64 1.6.8-2.fc23 fedora 126 k device-mapper-multipath x86_64 0.4.9-80.fc23 fedora 121 k device-mapper-multipath-libs x86_64 0.4.9-80.fc23 fedora 221 k dosfstools x86_64 3.0.28-1.fc23 fedora 111 k gdisk x86_64 1.0.1-1.fc23 updates 199 k iscsi-initiator-utils x86_64 6.2.0.873-29.git4c9d6f9.fc23 updates 424 k iscsi-initiator-utils-iscsiuio x86_64 6.2.0.873-29.git4c9d6f9.fc23 updates 84 k json-glib x86_64 1.0.4-2.fc23 fedora 131 k libatasmart x86_64 0.19-8.fc23 fedora 47 k libblockdev-btrfs x86_64 1.1-2.fc23 fedora 32 k libblockdev-utils x86_64 1.1-2.fc23 fedora 32 k libssh x86_64 0.7.2-2.fc23 fedora 199 k libstoraged x86_64 2.2.0-1.fc23 updates 119 k mdadm x86_64 3.3.4-2.fc23 updates 408 k mozjs17 x86_64 17.0.0-14.fc23 updates 1.4 M ntfs-3g x86_64 2:2015.3.14-3.fc23 fedora 290 k ntfsprogs x86_64 2:2015.3.14-3.fc23 fedora 297 k polkit x86_64 0.113-4.fc23 fedora 127 k polkit-pkla-compat x86_64 0.1-6.fc23 fedora 43 k storaged x86_64 2.2.0-1.fc23 updates 363 k storaged-lvm2 x86_64 2.2.0-1.fc23 updates 66 k
Transaction Summary ================================================================================ Install 27 Packages
Total download size: 6.5 M Installed size: 20 M
I don't think we want to remove any of the other portions of Cockpit at this time (or its capabilities will be significantly reduced).
I think in my ideal world, we would have Cockpit become capable of interacting with PackageKit so that it could install whatever portions of the system the admin wanted to manage on demand, rather than ahead of time.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/25/2015 07:00 AM, Peter Robinson wrote:
I think in my ideal world, we would have Cockpit become capable of interacting with PackageKit so that it could install whatever portions of the system the admin wanted to manage on demand, rather than ahead of time.
Why not dnf API?
Because PackageKit is distro-agnostic and I assume Cockpit wants to continue to work with non-Fedora/RHEL/CentOS distributions.
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:
- 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 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
On Mon, Nov 16, 2015 at 08:39:24PM -0500, Stephen Gallagher wrote:
==== Largest 10 packages ==== 14288083: coreutils 14486819: glibc 18024040: kernel-modules 27253403: systemd
I've been working on making systemd packaging slightly more modular: https://fedoraproject.org/wiki/Changes/systemd_package_split
This has been discussed during the recent systemd.conf2015 and also on the mailing list (http://lists.freedesktop.org/archives/systemd-devel/2015-November/034917.htm...).
For server this is unlikely to have a significant impact, but for container cases it can save about ~15MB of disk space.
--
16648994: grub2 36004297: grub2-tools b'grub2-tools': 125 b'grub2': 131
This is fairly big... It also pulls in fedora-logos, bringing the total up to 60MB. systemd-boot and other minimalists look really nice in comparison.
--
- 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.
Is there any progress on https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging ?
Zbyszek
On Tue, Nov 17, 2015 at 02:01:56PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Is there any progress on https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging
I think it's this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=156477
in which case it looks like it's done (I didn't test it though ...)
It doesn't help unless you use the special _install_langs define when installing glibc, and then you've got to choose which locales you want to install, which I suppose will make some speakers unhappy.
Rich.
On Wed, Nov 18, 2015 at 10:15:58PM +0000, Richard W.M. Jones wrote:
On Tue, Nov 17, 2015 at 02:01:56PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Is there any progress on https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging
I think it's this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=156477
in which case it looks like it's done (I didn't test it though ...)
It doesn't help unless you use the special _install_langs define when installing glibc, and then you've got to choose which locales you want to install, which I suppose will make some speakers unhappy.
Thanks, #156477 is very interesting. It seems to work as designed, /usr/lib/locale/locale-archive becomes nice and small.
Couple of questions though:
1. Why even install non-utf8 locales? Shouldn't they be killed with fire?
glibc defaults to including them, (e.g. %_install_langs=en_US includes en_US.iso88591, en_US.iso885915, en_US.utf8) but this approx. triples the size of /usr/lib/locale/locale-archive.
https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base... uses %_install_langs C:en:en_US:en_US.UTF-8 which installs C C.utf8 POSIX en_AG en_AG.utf8 en_AU en_AU.iso88591 en_AU.utf8 en_BW en_BW.iso88591 en_BW.utf8 en_CA en_CA.iso88591 en_CA.utf8 en_DK en_DK.iso88591 en_DK.utf8 en_GB en_GB.iso88591 en_GB.iso885915 en_GB.utf8 en_HK en_HK.iso88591 en_HK.utf8 en_IE en_IE.iso88591 en_IE.iso885915@euro en_IE.utf8 en_IE@euro en_IN en_IN.utf8 en_NG en_NG.utf8 en_NZ en_NZ.iso88591 en_NZ.utf8 en_PH en_PH.iso88591 en_PH.utf8 en_SG en_SG.iso88591 en_SG.utf8 en_US en_US.iso88591 en_US.iso885915 en_US.utf8 en_ZA en_ZA.iso88591 en_ZA.utf8 en_ZM en_ZM.utf8 en_ZW en_ZW.iso88591 en_ZW.utf8 which is unlikely to be intentional.
2. What about non-glibc stuff? /usr/share/locale/ is 800MB on my system. It would be nice to trim this down too. Afaics, #156477 or the glibc subpackaging proposal will not help here at all.
Zbyszek
Am 19.11.2015 um 01:46 schrieb Zbigniew Jędrzejewski-Szmek:
- What about non-glibc stuff? /usr/share/locale/ is 800MB on my system. It would be nice to trim this down too. Afaics, #156477 or the glibc subpackaging proposal will not help here at all
800 MB?
on my desktop it's 459 MB on servers between between 89 MB and 124 MB
interesting where these differences are from and yes it's large because it's around 10% of the whole rootfs
On 19/11/15 09:11, Reindl Harald wrote:
Am 19.11.2015 um 01:46 schrieb Zbigniew Jędrzejewski-Szmek:
- What about non-glibc stuff? /usr/share/locale/ is 800MB on my
system. It would be nice to trim this down too. Afaics, #156477 or the glibc subpackaging proposal will not help here at all
800 MB?
on my desktop it's 459 MB on servers between between 89 MB and 124 MB
interesting where these differences are from and yes it's large because it's around 10% of the whole rootfs
Well it entirely depends on what packages are installed.
On my desktop it's 894Mb, on a stripped down firewall box it's only 107Mb.
It's not just glibc - anything that installs translations will be putting stuff in /usr/share/locale/*/LC_MESSAGES.
Tom
On Thu, Nov 19, 2015 at 09:16:53AM +0000, Tom Hughes wrote:
On 19/11/15 09:11, Reindl Harald wrote:
Am 19.11.2015 um 01:46 schrieb Zbigniew Jędrzejewski-Szmek:
- What about non-glibc stuff? /usr/share/locale/ is 800MB on my
system. It would be nice to trim this down too. Afaics, #156477 or the glibc subpackaging proposal will not help here at all
800 MB?
on my desktop it's 459 MB on servers between between 89 MB and 124 MB
interesting where these differences are from and yes it's large because it's around 10% of the whole rootfs
Well it entirely depends on what packages are installed.
On my desktop it's 894Mb, on a stripped down firewall box it's only 107Mb.
It's not just glibc - anything that installs translations will be putting stuff in /usr/share/locale/*/LC_MESSAGES.
Some top "offenders":
--- /usr/share/locale/uk/LC_MESSAGES --------------- 1.1 MiB [##########] libvirt.mo 856.0 KiB [####### ] inkscape.mo 564.0 KiB [#### ] gas.mo 564.0 KiB [#### ] cross-gas.mo 520.0 KiB [#### ] util-linux.mo 512.0 KiB [#### ] evolution-3.18.mo 496.0 KiB [#### ] iso_639_3.mo 444.0 KiB [### ] coreutils.mo 428.0 KiB [### ] pidgin.mo 344.0 KiB [## ] gimp20.mo 284.0 KiB [## ] gnupg2.mo 252.0 KiB [## ] libgphoto2-6.mo 252.0 KiB [## ] gimp20-std-plug-ins.mo 248.0 KiB [## ] iso_3166_2.mo 244.0 KiB [## ] gutenprint.mo 236.0 KiB [## ] kunitconversion5.mo 232.0 KiB [## ] cross-binutils.mo 232.0 KiB [## ] binutils.mo 224.0 KiB [# ] gtk30-properties.mo 220.0 KiB [# ] bash.mo 212.0 KiB [# ] NetworkManager.mo 208.0 KiB [# ] libgweather-locations.mo 200.0 KiB [# ] virt-manager.mo
(That's just for one language, for other languages the order is different, but not too much.)
Zbyszek
On Mon, 2015-11-16 at 20:39 -0500, Stephen Gallagher wrote:
==== 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
I'm not sure what you mean by "dependency chain" here, I honestly doubt we have any A->B->C->... chains between packages exceeding, I dunno, 30 in length. Perhaps this means "installing this package installs a graph with this many package nodes"? Or more succinctly, "10 largest dependency subtrees"?
- server-hardware-support
- lm_sensors: chain 139
A bunch of that is perl. The old desktop live images fought pretty hard to keep perl out, I suspect the sysadmin heritage of the stuff in the server image will make that a bit harder to accomplish.
One other thing the desktop live image had going for it was a concrete numeric goal to aim for. Since we're considering disk space in the context of cloud images, would it make sense to define a target in terms of (say) dollar cost of storage in Amazon EBS for a year?
- 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.
Tsk, another instance of "python3 by default" not implying what we might have hoped.
- ajax
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/17/2015 11:16 AM, Adam Jackson wrote:
On Mon, 2015-11-16 at 20:39 -0500, Stephen Gallagher wrote:
==== 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
I'm not sure what you mean by "dependency chain" here, I honestly doubt we have any A->B->C->... chains between packages exceeding, I dunno, 30 in length. Perhaps this means "installing this package installs a graph with this many package nodes"? Or more succinctly, "10 largest dependency subtrees"?
Right, maybe "dependency chains" is the wrong term. What it means is that this is the total number of packages (which are probably shared with others) necessary to support this package.
- server-hardware-support - lm_sensors: chain 139
A bunch of that is perl. The old desktop live images fought pretty hard to keep perl out, I suspect the sysadmin heritage of the stuff in the server image will make that a bit harder to accomplish.
I'm pretty willing to consider making lm_sensors an optional component, but it will need to be discussed in terms of the Personas we work against.
One other thing the desktop live image had going for it was a concrete numeric goal to aim for. Since we're considering disk space in the context of cloud images, would it make sense to define a target in terms of (say) dollar cost of storage in Amazon EBS for a year?
That's an interesting approach. I'll have to look into that.
- 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.
Tsk, another instance of "python3 by default" not implying what we might have hoped.
In today's Server WG meeting[1], we came up with an approach to removing these packages from the default install while not losing the functionality they provide (hooray for auto-installation).
[1] https://lists.fedoraproject.org/pipermail/server/2015-November/002135.html
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/18/2015 01:43 PM, Dan Williams wrote:
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.
Just for the record, we do not actually include NetworkManager-tui in the default Server install. We only have NetworkManager (which includes nmcli) and NetworkManager-libnm.
We have had *requests*[1] to include NetworkManger-tui in the default install, which I keep forgetting to discuss with the Server SIG, but thus far we have not included it. My personal feeling is that we shouldn't need NM-tui if we have Cockpit (though I acknowledge that the latter is nowhere near as feature-complete).
[1] Most recently was from Dennis Gilmore who was asserting that he needed it because nmcli couldn't create new interfaces. I'm pretty sure that's incorrect, but I didn't have a handy pointer to give him.
"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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/17/2015 06:17 PM, Dan Williams wrote:
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.
It was actually included in the tarball I sent in the original email, but: NetworkManager-libnm-1.0.6-6.fc23.x86_64 NetworkManager-1.0.6-6.fc23.x86_64
Yeah, I think NetworkManager is probably fine. It doesn't appear to be using any packages that aren't also used by many other projects. I need to figure out some better metrics for tracking this stuff down.
NM definitely requires a lot of packages, but it seems obvious that the problem is deeper in the stack. Some package further back probably has a large number of dependencies.
I just spent a little time tracing the dependency chain down and it looks like it's getting most of the chain from dbus->systemd->cryptsetup-libs->device-mapper-libs (at this point the dependencies hit a cycle with systemd...)
The next largest dependency chain is with util-linux which appears to depend on a large number of small storage-related and low-level tools.
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
Dne 17.11.2015 v 02:39 Stephen Gallagher napsal(a):
b'dnf-plugins-core': 117
Nice to have, however Minimal installation can live without it.
b'plymouth-scripts': 121 b'plymouth': 121
This really does not need to be on minimal installation.
And you can save a lot of data if you purge locales. Debian has this nice utility: https://packages.debian.org/sid/localepurge
On Wed, Nov 18, 2015 at 9:30 AM, Miroslav Suchý msuchy@redhat.com wrote:
Dne 17.11.2015 v 02:39 Stephen Gallagher napsal(a):
b'dnf-plugins-core': 117
Nice to have, however Minimal installation can live without it.
b'plymouth-scripts': 121 b'plymouth': 121
This really does not need to be on minimal installation.
And you can save a lot of data if you purge locales. Debian has this nice utility: https://packages.debian.org/sid/localepurge
As Debian admits on that page, it's a bit of a hack, but it would make sense to make a DNF plugin that could do the same thing, if we have no better options right now.
On Wed, Nov 18, 2015 at 03:30:54PM +0100, Miroslav Suchý wrote:
b'dnf-plugins-core': 117
Nice to have, however Minimal installation can live without it.
Since protected_packages is part of this, I don't agree. Sure, it's technically removable, but if someone starts from minimal and builds up, we don't want to surprise them. (This is the same reason the javascript stuff is a hard requirement of policykit, even though technically it's pluggable.)
On Wed, Nov 18, 2015 at 10:10 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Nov 18, 2015 at 03:30:54PM +0100, Miroslav Suchý wrote:
b'dnf-plugins-core': 117
Nice to have, however Minimal installation can live without it.
Since protected_packages is part of this, I don't agree. Sure, it's technically removable, but if someone starts from minimal and builds up, we don't want to surprise them. (This is the same reason the javascript stuff is a hard requirement of policykit, even though technically it's pluggable.)
Yes, please leave this installed. It should be in every Fedora install.
(It should really be integral to dnf itself, but we seem to have lost that battle.)
josh
b'plymouth-scripts': 121 b'plymouth': 121
This really does not need to be on minimal installation.
I agree, also it looks like in CentOS 7 minimal install there are also some bootloader-related images in /usr/share/backgrounds/* which are also pretty big. I assume the same for fedora.
Locale is about 100 MB (installed size), this is worth investigating as well. Some spins might not need them:
localedef --list-archive | grep -iv 'en_US' | xargs localedef -v --delete-from-archive mv /usr/lib/locale/locale-archive /usr/lib/locale/locale-archive.tmpl /usr/sbin/build-locale-archive
Also cracklib library can be compressed (and it works just fine):
gzip -9 /usr/share/cracklib/pw_dict.pwd
Few (little bit more dirty) tricks are in our Foreman Discovery Image (Fedora/CentOS based distro to server as MaaS discovery tool):
https://github.com/theforeman/foreman-discovery-image/blob/master/25-minimiz...
Here, it's little bit extreme (we are removing RPM database, all documentation etc) because the distro runs from memory (as Live one). Posting this here because it's relevant.
Any more tips how to save more space are highly appreciated!
-
Adam Jackson -
Dan Williams -
Jason L Tibbitts III -
Josh Boyer -
Lukas Zapletal -
Martijn Ras -
Matthew Miller -
Miroslav Suchý -
Neal Gompa -
Peter Robinson -
Pádraig Brady -
Reindl Harald -
Richard W.M. Jones -
Stef Walter -
Stephen Gallagher -
Stephen John Smoogen -
Tom Hughes -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek