Update Script

Verfasst von FelixPetzold am 20. April 2010 - 21:53

Das Script liegt jetzt in Version 2.1 vor, und wird als Ebuild ausgeliefert. Version 2.1 bringt einen eigenen Installer mit, der online nach der neuesten Version sucht. Das Script benutzt >=portage-2.2_rc67 und verlangt dies auch zum Installieren. Das wird allerdings von autounmask für euch erledigt.
Originalbeschreibung auf englisch unter http://www.felixpetzold.de/Gentoo/update/GentooLinuxUpdateScript.html

Was hat sich verändert?
Ein Durchlauf dauert jetzt nicht mehr 40 Minuten (bei mir auf einem Acer Aspire 7738G), sondern nur noch 8. Und das, obwohl Funktionen dazugekommen sind. Aber wie kommt es dazu? Ganz einfach. Die Checks, die bei jedem Update sein müssen, werden auch jedes Mal ausgeführt. Der "gentoo_ebuild_update_check_by_maggu2810" wird jetzt nur noch 1x in der Woche ausgeführt und das neue "gentoo-decruft" von bell wird 1x im Monat ausgeführt.
Neu ist auch, dass das Script reagiert, wenn Firefox, Thunderbird oder xorg-server upgedated werden. Wurde Firefox (oder Firefox-bin) upgedated, werden anschließend adobe-flash, swfdec und swfdec-mozilla neu installiert. Wurde Thunderbird (oder Thunderbird-bin) upgedated, wird noch ein "emerge -1 enigmail" ausgeführt. Und wenn der xorg-server upgedated wird, wird ein "emerge -1 $(qlist -I -C x11-drivers/)" ausgeführt. Solltet ihr eins der überwachten Pakete nicht installiert haben, wird das erkannt und die Überwachung findet für dieses Programm nicht statt.

Hier mal ein Listing eines Programmdurchlaufes:

  • update_sources - Diese Funktion updated layman, portage und eix
  • get_old_versions - Diese Funktion speichert die Versionsnummern der überwachten Programme
  • update_system - Hier wird das System upgedated. Sollte ein Fehler auftauchen, geht es mit "emerge --resume --skipfirst" weiter, bis es nix mehr zum updaten gibt
  • get_new_versions - Diese Funktion speichert wieder die Versionsnummern der überwachten Programme
  • react_on_version_differences - Diese Funktion reagiert, falls es bei den überwachten Programmen Updates gab
  • emerge_depclean - Hier wird "emerge --depclean" ausgeführt
  • lafilefixer_fixit - Hier wird lafilefixer ausgeführt
  • preserved_rebuild - Hier wird "emerge @preserved-rebuild" ausgeführt
  • pearl_cleaner - Hier wird der pearl cleaner ausgeführt
  • check_broken_librarys - Als letztes noch ein "revdep-rebuild"
  • cfg_update - Ein "cfg-update -ua" spielt schon mal die Configs ins System ein, die als automatisch (-a) markiert sind, und die etc-update auch erledigen würde, bever es zu den Updates kommt, wo es euch fragt, ob ihr diese Configs überschreiben wollt.
  • clean_system - Hier werden "eclean packages" und "eclean distfiles" ausgeführt
  • exit_update - Hier wird dafür gesort dass der User erfährt, wenn es Fehler gab

Zusätzlich wird noch mitinstalliert:

gentoo-decruft von bell kann nach der Installation von der Konsole aus aufgerufen werden und wird 1x im Monat von einem Cronjob ausgeführt. Dauer bei mir ca 1 Std.
Der ebuild check von maggu2810 wird 1x in der Woche von einem Cronjob ausgeführt und kann nach der Installation auch von der Konsole aus aufgerufen werden.
updateScriptVersionChecker is ein Installer/Updater für dieses Script und wird 1x in der Woche von einem Cronjob ausgeführt

Installation:
Schritte, die ihr schon erledigt habt, könnt ihr überspringen.

lokales Overlay
Ein lokales Overlay nutzt man, um Software, die man selber geschrieben hat, oder bei der man an den ebuilds rumgespielt hat, in den portage tree aufzunehmen.

mkdir -p /usr/local/portage/overlay # Den Pfad zum lokalen Overlay erstellen
mkdir -p /usr/local/portage/overlay/profiles/ # profiles Ordner im Overlay erstellen
echo "local overlay" >> /usr/local/portage/overlay/profiles/repo_name # Dem Overlay einen Namen geben
chown -R portage:portage /usr/local/portage/overlay # So soll das sein

Jetzt habt ihr ein lokales Overlay mit dem Namen "local overlay". Damit portage davon weiß, müsst ihr das jetzt in die /etc/make.conf eintragen

echo "PORTDIR_OVERLAY=\"/usr/local/portage/overlay\"" >> /etc/make.conf

Jetzt habt ihr ein lokales Overlay, dass zwar leer ist, aber immerhin von Portage und meinem Installer erkannt wird. In diesem Ordner liegt dann hinterher unter app-admin/update/ der ganze Quellcode, falls ihr das Script später an eure Bedürfnisse anpassen wollt.

Elogv
elogv ist ein Betrachter für elog messages, die von portage gespeichert werden können, wenn man das einstellt. Dies werden wir hier tun. Die elog messages sind der Text, der beim kompilieren so durchläuft. Da dort aber viel durchläuft, brauchen wir einen Filter. Wir stellen portage so ein, dass nur messages mit dem Status "warn" und "error" gespeichert werden. Status "error" bedeutet dass ein Paket nicht gebaut werden konnte (warum auch immer, das steht dann da) und "warn" bedeutet, dass es eine Meldung gibt, dass die Software von euch möchte, dass ihr etwas tut. Eine typische Warnmeldung wäre diese hier:

Zitat:
* You must rebuild all drivers if upgrading from xorg-server 1.X
* or earlier, because the ABI changed. If you cannot start X because
* of module version mismatch errors, this is your problem.

* You can generate a list of all installed packages in the x11-drivers
* category using this command:
* emerge portage-utils; qlist -I -C x11-drivers/

Führt man das nicht aus, wacht man nach dem Neustart ohne Maus und Tastatur auf. Daher war es gut, dass portage uns diese Nachricht gespeichert hat. OK, in dem Fall egal, weil mein Script den xorg-server überwacht unnd das automatisch macht, aber solche Meldungen gibt es von einer ganzen Reihe von Programmen.

OK, richten wir es ein:
emerge -av elogv # elogv installieren
echo "PORTAGE_ELOG_CLASSES=\"log warn error info qa\"
PORTAGE_ELOG_SYSTEM=\"echo:log,info,warn,error save:warn,error\"" >> /etc/make.conf # Portage sagen, wie es mit elog messages in Zukunft verfahren soll

Zitat:
Beispiel 1 (nur warn und error wird gespeichert, das reicht):
PORTAGE_ELOG_CLASSES="log warn error info qa"
PORTAGE_ELOG_SYSTEM="echo:log,info,warn,error save:warn,error"

Beispiel 2 (+info messages)
PORTAGE_ELOG_CLASSES="log warn error info qa"
PORTAGE_ELOG_SYSTEM="echo:log,info,warn,error save:info,warn,error"

Beispiel 3 (Beispiel von elogv selbst)
PORTAGE_ELOG_SYSTEM="save"
and at least one out of
PORTAGE_ELOG_CLASSES="warn error info log qa"

Jetzt müsst ihr nach einem Update nur noch "elogv" als root aufrufen und bekommt alle wichtigen Nachrichten. Sollten keine da sein, gibt es nix zu tun. Um elogv als User zu starten, müsst ihr in der Gruppe portage sein.

Findet ihr Nachrichten, geht ihr wie folgt vor:
Mit den Pfeiltasten hoch und runter könnt ihr zwischen den Nachrichten hin und her springen.
Mit der Leertaste könnt ihr in den Nachrichten scrollen.
Und mit "dd" löscht ihr eine Nachricht.
Mit "q" beendet ihr das Programm, es schließt sich aber auch, wenn ihr alles gelöscht habt

layman
layman ist ein Tool um auf verschiedenste Overlays zuzugreifen und sie in den eigenen portage tree mit aufzunehmen. Hier (http://gpo.zugaina.org/) findet ihr mehr dazu, wass ihr in layman alles einfügen könnt.

echo "app-portage/layman git subversion
dev-util/subversion -dso" >> /etc/portage/package.use
emerge -av layman

Dann geht ihr in die layman.cfg und stellt sicher, dass dort "storage : /var/lib/layman" und nicht der alte Pfad drin steht !!!
nano -w /etc/layman/layman.cfg

Jetzt muss layman gesynct werden. Damit layman eine make.conf in seinem Verzeichnis erstellt, muss 1x ein Overlay eingefügt werden, dass danach sofort wieder gelöscht werden kann. Diese make.conf von layman machen wir dann Portage in der /etc/make.conf durch einen source Eintrag bekannt.
layman -S
layman -a maggu2810-overlay
layman -d maggu2810-overlay
echo "source /var/lib/layman/make.conf" >> /etc/make.conf

Mit layman -S könnt ihr alles syncen, mit layman -L seht ihr, was alles verfügbar ist, und mit layman -a foo richtet ihr foo bei euch ein. Mit layman --help erfahrt ihr den Rest.

cfg-update
cfg-update ist das Tool, mit dem ich bei euch die Config files, die als "automatisch" von Portage markiert sind, in euer System einspiele. Dann habt ihr, wenn ihr später "etc-update" oder "dispatch-conf" oder "cfg-update -u" ausführt nur noch die Configs zu behandeln, um die sich ein Mensch kümmern muss. cfg-update braucht ein diff-Tool, um zu funktionieren. Gnome User haben es hier einfach, durch das USE-Flag "gnome" wird hier dev-util/meld als Abhängigkeit installiert.

emerge -av cfg-update
nano -w /etc/cfg-update.conf

Ich habe wie gesagt meld als MERGE_TOOL in der cfg-update.conf. Ihr seht ja, welche Möglichkeiten ihr habt, aber eins der Tools müsst ihr eintragen.

Zitat:
# +----------+
# | MERGETOOL \
# +------------+-------------------------------------------------------------+
# | The recommended tool for merging is xxdiff but you can also use other |
# | tools if you don't like xxdiff. The Supported tools are listed below: |
# +----------+-----+--------------------------+------------------------------+
# | xxdiff | GUI | KDE (or Gnome with QT) | |
# | kdiff3 | GUI | KDE (or Gnome with QT) | |
# | meld | GUI | Gnome (or KDE with GTK) | |
# | gtkdiff | GUI | Gnome (or KDE with GTK) | STAGE 3 not supported! |
# | gvimdiff | GUI | Gnome (or KDE with GTK) | STAGE 3 not supported! |
# | tkdiff | GUI | Gnome (or KDE with TK) | |
# | vimdiff | CLI | Systems without X | STAGE 3 not supported! |
# | sdiff | CLI | Systems without X | STAGE 3 not supported! |
# | imediff2 | CLI | Systems without X | STAGE 3 not supported! |
# +----------+-----+--------------------------+------------------------------+
MERGE_TOOL = /usr/bin/meld

Startet ihr cfg-update ohne Parameter mit "cfg-update" bekommt ihr die Hilfe angezeigt.

OK, jetzt ist alles eingerichtet und funktioniert. Wie ihr mit den Tools täglich umgehen müsst, erkläre ich euch später.

BitKiller ~ # emerge -pv update

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] app-admin/update-2.1_rc3 USE="X daily -weekly" 0 kB [1]

Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /overlay
BitKiller ~ #

Wie ihr seht, gibt es 3 Use-Flags bei dem Script. Das USE-Flag X wird von eurem Profiel bestimmt und ist schon gesetzt oder nicht. Bei diesem USE-Flag geht es eher darum, dass auf Servern keine Abhängigkeiten mit xorg-x11 entstehen. Ohne USE="X" wird x11-misc/xdialog nicht mit installiert und am Ende des Updates der Xdialog nicht aufgerufen.

Für euch sind die USE-Flags "daily" und "weekly" interessant. Ich nutze und empfehle "daily" !!! OK, was passiert, wenn ihr was auswähl:
daily:

  • Das Update Script wird täglich ausgeführt
  • Der ebuild_check wird wöchentlich ausgeführt
  • Der cruft_check wird monatlich ausgeführt
  • Der update_check nach einer Neueren Version des Scriptes wird wöchentlich ausgeführt.

weekly:

  • Der cruft_check wird monatlich ausgeführt # wie bei daily
  • Der update_check nach einer Neueren Version des Scriptes wird wöchentlich ausgeführt. # wie bei daily
  • Das Update Script wird wöchentlich ausgeführt
  • Der ebuild_check wird monatlich ausgeführt

Ich empfehle:
echo "app-admin/update daily" >> /etc/portage/package.use

Mein Script erkennt euren lokalen Overlay Ordner alleine. Es sieht in der make.conf nach, um rechtschreibfehlern vorzubeugen. Es ist egal, aus welchem Ordner heraus ihr es startet. Es erstellt in eurem lokalen Overlay den Order app-admin und da drin den Ordner update, geht dort rein, läd die latest-version.txt von mir runter, läd dann die neueste Version runter, entpackt sie, erstellt für euch das Manifest, installiert autounmask, stellt mit autounmask alle Abhämgigkeiten her und installiert das Script.

wget http://www.felixpetzold.de/Gentoo/update/InstallUpdateScript
chmod +x InstallUpdateScript
./InstallUpdateScript
rm InstallUpdateScript

Jetzt müsst ihr nur noch in der /etc/conf.d/update euren Usernamen einstellen.
nano -w /etc/conf.d/update

Zitat:
USER_NAME="felix # Bei mir

Das ist der User, der eine Datei auf den Desktop bekommt, wenn bei dem Updaten Pakete bei waren, die sich nicht bauen lassen. Da elogv das Gleiche liefert, wird diese Option bald optional.

Jetzt ist alles installiert und konfiguriert. Ihr könnt jetzt als root folgende Befehle ausführen:
update - Das Script, was 1x am Tag von Cron gestartet wird.
updateScriptVersionChecker - Das Script, was 1x wöchentlich nach Updates sucht
gentoo_ebuild_update_check_by_maggu2810 - Der ebuild check von maggu2810, der von Cron 1x die Woche gestartet wird
gentoo-decruft - Das Script von bell, das von Cron 1x im Monat gestartet wird

Die Befehle 2-4 würde ich eher Cron überlassen. Klar, gucken muss sein.

Wie läuft das jetzt mit Cron und automatisch und so? Muss ich nix mehr machen?

Also, wenn ihr (oder cron) das Script habt laufen lassen, ist es ja irgendwann fertig. Schön, jetzt ist alles upgedatet. Aber eine Programme brauchen manchmal Nachbehandlung und schreiben das dann in die elog messages. Alles was dort auftaucht (wenn ihr die empfohlenen Einstellungen übernommen habt) müsst ihr lesen und verstehen und nach gesundem Menschenverstand befolgen. Also führt ihr nach Ende des Scripts (oder wenn ihr wisst, dass Cron es hat laufen lassen) "elogv" aus. Ihr habt nix falsch gemacht, wenn dort steht, dass es keine messages gibt und elogv wieder aus ist. Das kommt öfter vor. Aber wenn dort was steht, dann befolgt es auch.
Nachdem ihr in elogv alles durch habt, müsst ihr nur noch die Config Dateien updaten. Das geht mit "cfg-update -u", "etc-update" und "dispatch-conf". Sucht euch eins aus, die Reihenfolge ist meine Bewertung.

Und das wars. Ihr müsst nach dem Script wirklich nur 2 Befehle (elogv + cfg-update -u) ausführen.

Und so sieht dann nen Durchlauf aus:
Update-Script v2.1 for Gentoo Linux by Felix Petzold
----------------------------------------------------
Syncing Portage, Eix & Layman.
Finished

Saving installed version-nr of firefox, thunderbird and xorg-server
Found www-client/firefox-3.6.8-r1
Found x11-base/xorg-server-1.8.2
Finished

Updating System.
Finished

Getting new version-nr of firefox, thunderbird and xorg-server
Found www-client/firefox-3.6.8-r1
Found x11-base/xorg-server-1.8.2
Finished

Checking version differences to react on updates
Finished

Running emerge --depclean.
Finished

Running lafilefixer --justfixit
Finished.

Running emerge @preserved-rebuild.
Finished

Running perl-cleaner --all
Finished.

Running revdep-rebuild.
Finished

Running cfg-update -ua
Finished

Running eclean packages.
Finished

Running eclean distfiles.
Finished

Exiting update script