Linux – Softwaregröße ermitteln

Ihr habt ein RedHat basiertes Linux ( Fedora, CentOS, RHEL ) und das letzte Systemupgrade wollte satte 6,5 GB an OS Updates ziehen ?  Schonmal gefragt, was wohl die installierte Software mit dem fettesten Plattenverbrauch ist ? Abhilfe naht.

Die TOP 20

Eure TOP 20 bekommt Ihr so :

rpm -qa –queryformat ‚%10{size} – %-25{name} \t %{version}\t %{distribution}\n‘ | sort -r -n | head -n 20

Das könnte dann so aussehen:

2107049784 - 0ad-data                  	 0.0.23	 Fedora Project
 573182723 - supertuxkart-data         	 0.9.3	 Fedora Project
 525223953 - wesnoth-data              	 1.14.2	 Fedora Project
 319608404 - naev-data                 	 0.7.0	 Fedora Project
 255255974 - wine-debuginfo            	 1.9.3	 Fedora Project
 233338453 - stellarium                	 0.18.0	 Fedora Project
 232662604 - skypeforlinux             	 8.22.0.2	 (none)
 232447142 - pocl                      	 0.15	 Fedora Project
 231246894 - freedroidrpg-data         	 0.16.1	 Fedora Project
 215009186 - firefox                   	 60.0.1	 Fedora Project
 211907984 - widelands                 	 0	 Fedora Project
 211049524 - linux-firmware            	 20180525	 Fedora Project
 204226588 - fluid-soundfont-lite-patches 	 3.1	 Fedora Project
 199781645 - wine-core                 	 2.10	 Fedora Project
 196211495 - wine-staging-common       	 2.10	 (none)
 193901581 - wine-core                 	 2.10	 Fedora Project
 189052708 - google-chrome-stable      	 67.0.3396.79	 (none)
 164080235 - thunderbird               	 52.8.0	 Fedora Project
 162898103 - clamav-data               	 0.99.4	 Fedora Project
 149740146 - blender                   	 2.79	 Fedora Project

Ich weiß nicht, wieso ich POCL installiert hatte.. aber auf die freien 220 MB freue ich mich jetzt schon 🙂 Das 0.AD soviel Platz zieht ist keine Wunder, bei der Grafik!

 

Fedora – ClamAV 0.99.3 installieren

Es kam gestern doch sehr überraschend in den Medien, daß ClamAV ein Rudel Schwachstellen hat und auf keinem normalen Weg wurde darüber informiert. Es gab weder eine Meldung über die CERTs, noch auf der Redhat Security Mailingliste. Die Schwachstelle ist so gravierend, daß auf unserer Serverfarm sämtliche ClamAVds bis zum Patch deaktiviert wurden.

Abhilfe schaffen

Derzeit gibt es in de Repos noch keine gepatchte Version, obwohl Sie bereits zur Verfügung steht. Wer den Early-Alpha-Beta-Test mitmachen will, der findet die Pakete für Fedora hier : https://koji.fedoraproject.org/

Folgende Pakete solltet Ihr dann downloaden:

clamav
clamav-data
clamav-filesystem
clamav-lib
clamav-server
clamav-update

installiert wird das dann mit „rpm -Uv /pfad/zu/den/rpms/clam*rpm„. Fertig.

 

gleiche RPMs aus verschiedenen Quellen

Ein bisschen speziell ist unser heutiger Fall von Systemupgrade. Wir haben mehrere Repositories/Quellen von RPM Paketen für ein Paket, wollen aber das System per DNF upgraden und ein Paket aus einem bestimmten Repo benutzen.

Das Problem

Wir haben Fedora 25 als OS mit dem Default PHP von Fedora und zwei anderen PHP Versionen von Remi, einem französischen Repository für Serversoftware. Ein Serverupgrade kann man leicht mit

dnf –allowerasing –releasever=26 –setopt=deltarpm=false distro-sync

durchführen. Damit alle zusätzlichen Rpms von Drittrepos auch mitkommen beim Update, muß das jeweilige Repo global aktiviert sein, oder man gibt es in der Zeile mit an :

dnf –enablerepo=remi –allowerasing –releasever=26 –setopt=deltarpm=false distro-sync

Wenn man das in unserer Ausgangssituation tut, bekommt man einen Quellwechsel ins Spiel, denn man nicht unbedingt haben will. Remi hat nämlich eine neuere Version von PHP als das Fedorarepo.

Der Unterschied

Das hat natürlich einen Grund, Remi hat sich genau dem gewidmet, neigt aber dazu ohne umfangreiche Testrepos zuarbeiten. Fedora dagegen hat eine Communitytestumgebung, auf der Tester die Pakete bewerten müssen, bevor Sie ins Stablerepo gepusht werden.

Fedora hat also ggf. die stabiler laufenden Pakete, weil überhaupt jemand mal testhalber so ein Paket installiert hat. Auf einer Serverumgebung wollen wir natürlich genau dies haben, außerdem könnten die Remi Pakete anders kompiliert sein, und daher unerwartete Nebenwirkungen haben, was strikt zu vermeiden ist.

Quellrepowechsel verhindern

Gibt man jetzt das Upgradekommando ein und hat alle Quellrepos aktiviert, sieht Dnf das „neuere“ PHP Paket bei Remi und wechselt die Quelle, genauso, also wenn man das Testrepository aktiviert und dort ein neueres Paket vorhanden ist.

Daher muß man das Remirepo deaktivieren und erstmal normal upgraden. Nach dem Reboot kann man dann einfach dnf update benutzen um die Pakete zu aktualisieren, die im Remirepo vorhanden sind.

Überraschung

Bei unserem Beispiel F25 zu F26 und PHP kommt es zu einem Versionssprung von PHP 7 auf PHP 7.1 . Damit haben wir jetzt ggf. zweimal 7.1. drauf, einmal von Fedora und einmal von Remi, wo man doch eigentlich 7.0 und 7.1. haben wollte.

Also lösen wir das auf, indem wir 7.1 von Remi entfernen und 7.0 aufspielen:

dnf –enablerepo=remi update php56* php72*
dnf –enablerepo=remi erase php71*
dnf –enablerepo=remi install -y php70-php-process php70-php-cli php70-runtime php70-php-imap php70-php-common php70 php70-php-pdo php70-php-mbstring php70-php-json php70-php-pear php70-php-gd php70-php-mcrypt php70-php-mysqlnd php70-php-xml

Glückwunsch. Sie haben jetzt vier PHP Versionen auf Ihrem Server 😀

Mit FedUP, dem eigentlichen Upgradetool, hätte man das so nicht geschafft, da wäre das PHP dann auch von Remi gekommen.