Wie viele Pakete sind denn gerade in Portage vorhanden,Update

Wie viele Pakete sind denn gerade in Portage vorhanden
Wie viele Pakete sind denn gerade in Portage vorhanden?
Verfasst von Old Man am 29. März 2010 – 15:51
Vorwort
Wie viele Pakete sind denn gerade in Portage vorhanden?
Lösung
find /usr/portage/ -mindepth 3 -maxdepth 3 -type f name Manifest | wc -l
Update Script
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 xorgserver upgedated wird, wird ein „emerge -1 $(qlist -I -C x11drivers/)“ 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 (link suchen)
gentoo_ebuild_update_check_by_maggu2810
http://github.com/maggu2810/gentoo-ebuild-uptate-check
updateScriptVersionChecker
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 xorgserver ü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 x11misc/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/InstallUpdat
eScript
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
Portagelog aktivieren
Portagelog aktivieren
Verfasst von Old Man am 29. März 2010 – 15:50
Vorwort
Da man ja von seinem System alles wissen möchte, gerade wenn sich
Fehler einschleichen, empfehle ich die standardmäßig
deaktivierte Protokollfunktion von Portage einzuschalten.
Bearbeitung
Dies geschieht mittels einer Option in der /etc/make.conf.
So erhält man die volle Kontrolle über die Portageausgaben und kann
beliebige Analysen anwenden.
mkdir /var/log/portage
echo "PORT_LOGDIR=\"/var/log/portage\";" >>
/etc/make.conf
Paketkategorien vom Update ausschliessen
Paketkategorien vom Update ausschliessen
Beim emerge –sync werden ja alle Paket-Kategorien upgedatet. Je nach
dem, kann dies eine Weile dauern.
Und nicht jeder hat eine Flat zur Verfügung.
Beispiel
Ihr benutzt Gnome und braucht keine KDE-Pakete.
Trotzdem werden die KDE-Pakete beim emerge –sync mit upgedatet.
Lösung
Dies kann man mit einen Eintrag in der /etc/make.conf ändern.
Zusätzlich muss man auch eine Liste der Paket-Kategorien erstellen,
die beim Update ausgeschlossen werden sollen.
nano-w /etc/make.conf
Dort fügt man folgenden Eintrag hinzu.
PORTAGE_RSYNC_EXTRA_OPTS="--excludefrom=/etc/portage/rsync_excludes"
Zum erstellen der Liste wird nun die Datei /etc/portage/rsync_excludes
editiert.
nano -w /etc/portage/rsync_excludes
Beispiel einer Eintragung.
kde*
xfce*
Das * ist dafür da, das auch der Inhalt der Paket-Kategorie, vom
Update ausgeschlossen wird.
metadata, eclass, packages, profiles, scripts sollten auf keinen Fall
in der Liste auftauchen. Also Finger weg davon.
Probiert es einfach mal aus. Nur macht nicht sooft ein emerge –sync.
Andernfalls werdet Ihr für eine gewisse Zeit beim Mirror gesperrt.
Hinweis
Eine Übersicht, welche Paket-Kategorien es gibt, findet Ihr hier:
http://gentoo-portage.com/Browse
Lokales Overlay erstellen
Lokales Overlay erstellen
Verfasst von FelixPetzold am 20. April 2010 – 22:35
Warum lokales Overlay?
Ich wollte nur eine bestimmt Version von Skype installieren, die aus
dem Overlay Sabayon stammt. Da in diesem Overlay aber noch jede Menge
Pakete für Gnome drin sind, die ich nicht installieren möchte, habe
ich mich für ein lokales Overlay entschieden, um nur dieses eine Paket
in den Portage Tree einzubinden.
Erstellen
Ich habe mir ein Verzeichnis für mein lokales Overlay erstellt:
sudo mkdir -p /usr/local/portage/overlay
sudo chown portage:portage
/usr/local/portage/overlay
Dann habe ich auf http://gpo.zugaina.org/ nach meinem Paket gesucht,
in dem Fall Skype. Die Download-Links, die euch dort angeboten werden,
laden ein Ebuild runter, in meinem Fall war es
„skype-2.1.0.47.ebuild“. Da Skype aus der Kategorie net-im kommt,
erstellen wir jetzt in unserem Overlay den Ordner net-im und darin den
Ordner Skype und kopieren dort unser Ebuild rein
sudo mkdir -p
/usr/local/portage/overlay/net-im/skype
sudo cp
/home/felix/Downloads/skype-2.1.0.47.ebui
ld /usr/local/portage/overlay/netim/skype/
sudo chown -R portage:portage
/usr/local/portage/overlay/*
Jetzt müssen wir für dieses Ebuild noch das Manifest erstellen
sudo ebuild
/usr/local/portage/overlay/netim/skype/skype-2.1.0.47.ebuild manifest
Als letztes müssen wir Portage nun noch sagen, dass es ein Overlay
gibt, dass benutzt werden soll. Dazu fügen wir folgendes in die
/etc/make.conf ein:
PORTDIR_OVERLAY="/usr/local/portage/overl
ay/"
Dem eigenen Overlay einen Namen geben:
mkdir -p
/usr/local/portage/overlay/profiles
touch
/usr/local/portage/overlay/profiles/repo_
name
echo "my_overlay_name" >>
/usr/local/portage/overlay/profiles/repo_
name
Da es sich bei meiner Skype-Version um ein x86 Paket gehandelt hat,
konnte ich das Paket jetzt mit emerge -av skype installieren. Sollte
euer Paket für ~x86 sein (amd64 / ~amd64 genauso), müsst ihr es noch
demaskieren, wenn ihr ein stable System habt.
Sollte euer Paket Abhängigkeiten haben, die sich mit Hilfe des
normalen Portage-Trees nicht auflösen lassen, kann es sein, dass ihr
weitere Pakete in euer Overlay stecken müsst (man denke an Gnome oder
KDE).
Logrotate
logrotate
Verfasst von niniveh am 19. April 2010 – 20:59
logrotate – rotiert, komprimiert und mailt System-Log Dateien
Das Systemwerkzeug app-admin/syslog-ng sorgt dafür, dass diverse
Vorgänge im Gentoosystem in bestimmten Logdateien eingetragen werden,
so dass der Administrator hier das Gentoosystem auf Fehler und
sonstige Vorgänge überprüfen, bzw. nachlesen kann.
Manche dieser Logdateien werden mit der Zeit überaus groß und dadurch
umständlich zu handhaben, zumal ältere Logdaten mitunter nicht mehr
interessant sind.
Nun kann man diese Logdateien selber komprimieren und leeren. Das
Löschen ist allerdings nicht empfehlenswert, weil manche Logdateien
nicht mehr ohne weiteres erneut angelegt werden können. Oder man
installiert ein Werkzeug, das diese regelmäßigen Aufgaben, archivieren
und löschen älterer Logdateien, automatisiert erledigt.
Hierfür ist Logrotate das richtige Werkzeug.
Und zwar werden je nach Einstellung in der logrotate-Konfiguration zu
festgelegten Zeiten die vorgegebenen Logdateien in Tararchiven gepackt
und nummeriert. Nach einer bestimmten wiederum einstellbaren Anzahl
von Log-Tararchiven wird jeweils das älteste Tararchiv gelöscht, wenn
ein neues dazu kommt (rotiert).
Beispiel /var/log/messages, die Nummerierung erfolgt über die
Datumsangabe der Erstellung nach amerikanischem Format:
ls -l /var/log
[...]
-rw------- 1 root
messages
-rw------- 1 root
messages-20100320.gz
-rw------- 1 root
messages-20100327.gz
-rw------- 1 root
messages-20100404.gz
-rw------- 1 root
messages-20100411.gz
[...]
root
379939 16. Apr 20:30
root
137110 20. Mär 13:20
root
74333 27. Mär 19:30
root
104115
4. Apr 09:40
root
132453 11. Apr 19:40
In der Beschreibung hier möchte ich im wesentlichen darstellen, wie man
logrotate wöchentlich seine Arbeit machen und nur 4 Tarsicherungsachive pro
Logdatei anlegen lässt.
Installieren der entsprechenden Systemlogwerkzeuge und beim booten
starten lassen:
emerge app-admin/syslog-ng app-admin/logrotate
rc-update add syslog-ng default
Um logrotate täglich seinen Dienst erfüllen zu lassen muss man dafür
einen Cronjob in /etc/cron.daily/logrotate.cron erstellen.
Hinweis: In der /etc/crontab kann man einstellen, wann welcher Cronjon
erledigt werden soll. Cron ist hier sehr flexibel.
In dieser Datei wird in unserem Beispiel hier Chron zu den
Einstellungen in der logrotate-Konfigurationsdatei verwiesen.
cat /etc/cron.daily/logrotate.cron
#! /bin/sh
/usr/sbin/logrotate /etc/logrotate.conf
Nähere Beschreibungen Gentoo Linux Cron Guide.
Unten meine Ausgabe der Logrotate-Konfigurationsdatei
/etc/logrotate.conf.
Die Kommentarzeile beschreibt kurz um welche Funktion es sich jeweils
handelt, teilweise schreibe ich deutsch die Funktion dazu.
Genauere Beschreibung mit „man logrotate“ oder in der
deutschsprachigen Manpage:
cat /etc/logrotate.conf
# $Header: /var/cvsroot/gentoo-x86/appadmin/logrotate/files/logrotate.conf,v 1.3 2008/12/24
20:49:10 dang Exp $
#
# Logrotate default configuration file for Gentoo
Linux
#
# See "man logrotate" for details
# rotate log files weekly (täglich oder wöchentlich
rotieren)
weekly
#daily
# keep 4 weeks worth of backlogs (4 Sicherungsarchive
werden hier gehalten, die Zahl kann verändert werden)
rotate 4
# create new (empty) log files after rotating old ones
(neue Logdatei anlegen, nachdem die bisherige
archiviert wurde)
create
# use date as a suffix of the rotated file (Fügt
Erstellungsdatum in den Dateinamen des Logarchives
ein)
dateext
# uncomment this if you want your log files compressed
(Logarchive werden komprimiert)
compress
# packages can drop log rotation information into this
directory (Rotationsinfos in /etc/logrotate.d werden
erfasst)
include /etc/logrotate.d
notifempty
nomail
noolddir
# no packages own lastlog or wtmp -- we'll rotate them
here
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0600 root utmp
}
rotate 1
# system-specific logs may be also be configured here.
Etliche Programme legen für logrotate eigene Konfigurationsdateien
unter /etc/logrotate.d an, so dass diese automatisch von logrotate
erfasst werden.
Logdateien die aber nicht automatisch von logrotate erfasst werden
kann man einfach hinzufügen, indem man sie in der Konfigurationsdatei
einer anderen zusätzlich hinzufügt.
Ich verwende dazu die Datei /etc/logrotate.d/syslog-ng:
cat /etc/logrotate.d/syslog-ng
# $Header: /var/cvsroot/gentoo-x86/app-admin/syslogng/files/syslog-ng.logrotate,v 1.2 2004/07/18 02:25:02
dragonheart Exp $
#
# Syslog-ng logrotate snippet for Gentoo Linux
# contributed by Michael Sterrett
#
/var/log/messages /var/log/emerge.log /var/log/kdm.log
/var/log/xdm.log /var/log/pm-powersave.log
/var/log/pm-suspend.log /var/log/ConsoleKit/history {
sharedscripts
postrotate
/etc/init.d/syslog-ng reload > /dev/null 2>&1
|| true
endscript
}
In der ersten nicht auskommentierten Zeile stehen die vollen Pfade der
Logdateien, die ich mit logrotate erfasst haben möchte, je mit einem
Leerzeichen getrennt:
/var/log/messages /var/log/emerge.log /var/log/kdm.log
/var/log/xdm.log /var/log/pm-powersave.log /var/log/pm-suspend.log
/var/log/ConsoleKit/history
Alles innerhalb der geschweiften Klammern beschreibt was mit diesen
Dateien geschehen soll.
Uhrzeit mit NTP-Server abgleichen
Uhrzeit mit NTP-Server abgleichen
Verfasst von Old Man am 16. April 2010 – 22:29
Vorwort
Immer wieder habe ich mich über meine Systemzeit geärgert. Also habe
ich beschlossen, die Uhrzeit mit dem Internet abzugleichen.
Deswegen habe ich einen NTP-Client installiert, um die Uhrzeit beim
booten mit einem NTP-Server abzugleichen.
Anleitung
Als erstes muss die Zeitzone stimmen. Mit
date
kann man sich die Zeitzone anzeigen lassen, welche im Augenblick
gesetzt ist.
Als nächstes muss der NTP-Client-Dienst installiert werden.
emerge -av ntp
Die
was
Ich
der
NTP-Server sollten in der Datei /etc/ntp.conf angepasst werden,
aber nicht zwingend erforderlich ist.
habe meine auf deutsche Pool Server angepasst. Eine aktuelle Liste
deutschen Pool-Server findest Du auf der NTP-Homepage
nano -w /etc/ntp.conf
# Pools for Gentoo users
#server 0.gentoo.pool.ntp.org
#server 1.gentoo.pool.ntp.org
#server 2.gentoo.pool.ntp.org
#server 3.gentoo.pool.ntp.org
#
server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org
Um die Zeit beim Booten automatisch mit dem Internet abzugleichen,
fügen wir dem Runlevel folgendes hinzu.
rc-update add ntp-client default
Systempartition nach der Installation vergrössern
Systempartition nach der Installation vergrößern
Verfasst von niniveh am 11. April 2010 – 22:12
Vorwort
Für die meisten Linuxdistributionen ist eine 10GB große Systempartion
völlig ausreichend.
Wenn man nun ein Gentoosystem auf eine 10GB große Partition
installiert und /home auf einer weiteren Partition mountet, wird man
spätestens nach der Installation eines großen Desktopmanagements wie
KDE4 feststellen, dass Gentoo erheblich mehr Speicherplatz belegt als
andere Distributionen.
10GB können nach einer Weile des Betriebes zu klein werden.
Nun kann man neu Partitionieren, wenn genügend Festplattenplatz
verfügbar ist und neu installieren.
Aber weil eine Gentooinstallation sehr viel Mühe macht, werden es die
meisten vorziehen ohne Neuinstallation die Systempartition vergrößern
zu können.
Wie das geht beschreibe ich hier.
Diese Anleitung sollte auch bei allen anderen Linux-Distributionen 1
zu 1 anzuwenden sein.
Voraussetzungen
Es muss direkt neben der Systempartition eine nicht benötigte Partition oder
unpartitionierter Festplattenplatz vorhanden sein.
Auf einem anderen hier nicht betroffenen Partition muss genügend freier Platz
sein um das System vorübergehend dort zu speichern.
Es muss eine funktionierende Linux-Live-CD vorliegen. Bevorzugt eine die
hdparm mitbringt, da sonst die Kopiergeschwindigkeit sehr langsam ist.
Annahmen
Wir gehen in unserem Beispiel hier davon aus, dass
Gentoo auf der 10GB großen Partition sdb1 installiert ist.
sdb2 direkt daneben nicht benötigt wird und auch 10GB groß ist.
Auf sda6 werden wir das System vorübergehend ablegen, sie ist mit ext3
formatiert.
Eine Linux Live-CD vorliegt
Dass die Bedienung von fdisk bekannt ist
Vorgehen
Boote die Live-CD und melden dich auf der Konsole als Root an.
Anlegen von Verzeichnissen, in die sdb1 und sda6 eingebunden werden
sollen und diese mounten:
mkdir
mount
mount
mkdir
/mnt/sdb1 /mnt/sda6
/dev/sdb1 /mnt/sdb1
/dev/sda6 /mnt/sda6
/mnt/sda6/gentoo-system
Kopieren des Gentoosystemes:
Die Optionen des cp-Befehles sorgen dafür, dass die Kopie alle Rechte
und relativen Links des Originals erhalten bleiben.
cp -Rpv /mnt/sdb1/* /mnt/sda6/gentoo-system/
Mit fdisk die Partitionen sdb1 und sdb2 (je 10GB in unserem Beispiel)
löschen und sdb1 mit 20GB neu anlegen.
Die neue Partition sdb1 mit ext3 neu formatieren:
mkfs.ext3 /dev/sdb1
Das zuvor gesicherte System von sda6 wieder zurück auf sdb1 kopieren:
cp -Rpv /mnt/sda6/gentoo-system/* /mnt/sdb1/
Mit df -h können wir nach dem kopieren sehen, wie groß die neue
Partition ist und wieviel davon belegt ist:
df -h
Und werden wahrscheinlich sehen, dass sdb1 noch immer nur 10GB groß
ist. Das hat folgenden Grund:
Beim formatieren von sdb1 wurde eine entsprechende Inode Tabelle
geschrieben, die die tatsächliche Partitionsgröße beschreibt. Nun
wurde beim kopieren des Systems die alte Inode-Tabelle auch kopiert
und die beschreibt sdb1 als 10GB groß. Und diese alte Inode-Tabelle
wurde später wieder zurück kopiert. Diese überschreibt die neue,
aktuelle Inode-Tabelle auf sdb1.
Wir legen eine neue
Benötigt werden die
e2fsck es überprüft
resize2fs liest die
aktuelle Inode-Tabelle von sdb1 an.
Programme:
zunächst die Partition,
neue Inode-Tabelle ein.
Zuerst muss sdb1 ausgehängt werden:
umount /mnt/sdb1
Nun lassen wir sdb1 überprüfen und legen die neue Inode-Tabelle an:
e2fsck -f /dev/sdb1
resize2fs -p /dev/sdb1
Danach starten wir das installierte Gentoosystem auf sdb1 und prüfen
nochmals die Partitionstabelle:
df -h
Das Ergebnis solle ungefähr so aussehen:
df -h
Dateisystem
auf
/dev/sdb1
udev
/dev/sdb3
...
Größe Benut
20G
10M
210G
6,3G
176K
28G
Verf Ben% Eingehängt
13G
9,9M
171G
34% /
2% /dev
14% /home
Fertig!
Systembackup mittels rsync
Systembackup mittels rsync
Verfasst von niniveh am 11. April 2010 – 22:01
Vorwort
Es gibt unter Linux viele Möglichkeiten Backups zu erstellen.
Hier beschreibe ich ein Systembackup auf der Konsole mit dem Programm
rsync.
rsync synchronisiert zwei Datensätze und sorgt bei den richtig
gesetzten Optionen dafür, dass beide genau identisch sind.
Bei der ersten Sicherung verhält sich rsync genau wie ein schlichter
Kopierbefehl wie cp -Rpv Quelle Ziel, was bei einem Systembackup
einige Zeit dauert.
Der eigentliche Vorteil von rsync kommt erst bei allen weiteren
Sicherungen zum tragen, denn rsync wird dann nicht erneut das ganzes
System zur Sicherungspartition kopieren, sondern lediglich die
Änderungen.
rsync kopiert dann nicht einmal die geänderten Dateien, sondern nur
die Änderungen innerhalb von Dateien, was das Kopiervolumen und die
benötigte Zeit drastisch reduziert.
Bei einem Systembackup muss zwingend von einem anderen Linuxsystem
gebootet werden.
Entweder von einer beliebige Live-CD oder einem zweiten installierten
System.
Hier beschreibe ich die Sicherung von einem installierten Zweitsystem
nach sdc7 auf einer externen Festplatte.
Die Partition der Sicherung muss ein Dateisystem haben das auch die
Rechteverwaltung von Linux unterstützt wie ext3.
Der Sicherungsbefehl Befehl lautet:
rsync -avPSH --delete Quelle Ziel
Die Optionen sind hier so gesetzt, dass alle Dateien, Verzeichnisse
und Links, die in der Quelle nicht mehr vorkommen, also inzwischen
gelöscht wurden, im Sicherungsverzeichnis auch gelöscht werden. So ist
nach dem Backup die Sicherung identisch mit dem originalen
installieren System.
Ausführung
Starten des Zweitsystems.
Öffne eine Konsole und melde dich als Root an.
Anlegen eines Verzeichnisses für die zu sichernden Partition und für
die Sicherungspartition auf der externen Festplatte:
# mkdir /media/sdb1
# mkdir /media/sdc7
Mounten der zu sichernden System- und Sicherungspartition:
# mount /dev/sdb1 /media/sdb1
# mount /dev/sdc7 /media/sdc7
Die Pfade müssen jeweils angepasst werden.
Anlegen eines Verzeichnisses auf der externen Festplatte, welches die
Gentoosystemsicherung aufnehmen soll:
# mkdir /media/sdc7/gentoo
Sicherung mit rsync durchführen:
# rsync -avPSH --delete /media/sdb1/
/media/sdc7/gentoo
Der Slash (/) am Ende von rsync -avPSH –delete /media/sdb1/ bedeutet,
dass nur der Inhalt vom Verzeichnis sdb1 kopiert wird und nicht dieses
Verzeichnis selber!
Bei der Rücksicherung wird Quelle und Ziel lediglich vertauscht:
In unserem Beispiel also:
# rsync -avPSH --delete /media/sdc7/gentoo/
/media/sdb1
Links:
Linuxclub
Kanotix
Wikipedia rsync
GCC wechseln
GCC wechseln
Vorwort
Manchmal kommt es vor, dass man einfach einen neueren GCC zum
kompilieren benötigt. Gentoo hält auch dafür eine Lösung bereit.
Lösung
Um an einen neueren GCC heranzukommen setzt man diesen in die
/etc/portage/package.keywords
echo 'sys-devel/gcc' >> /etc/portage/package.keywords
und anschliessend wird der GCC dann mit
emerge -av sys-devel/gcc
eingespielt. Es muss nun noch der neue GCC aktiviert werden. Um zu
erfahren welcher GCC gerade aktiv ist, geben wir folgenden Befehl ein.
gcc-config -l
Wir bekommen dann diese oder eine ähnliche Anzeige.
[1] x86_64-pc-linux-gnu-4.6.3 *
[2] x86_64-pc-linux-gnu-4.7.3
Das Sternchen hinter einer Zeile zeigt uns welche GCC Version gerade
aktiv ist. Alle anderen Zeilen zeigen uns an welche weiteren Versionen
auf unserem System
installiert sind und evtl. genutzt werden können. Um den neuen GCC zu
aktivieren geben wir folgenden Befehl ein.
gcc-config 2
Danach müssen wir noch unser Profil aktualisieren
source /etc/profile
Anschliessend überprüfen wir ob der neue GCC aktiviert wurde
gcc-config -l
Wir sollten dann diese oder eine ähnliche Ausgabe bekommen.
[1] x86_64-pc-linux-gnu-4.6.3
[2] x86_64-pc-linux-gnu-4.7.3 *
Da aber bereits installierte Bibliotheken (Librarys) davon ausgehen
das der alte GCC noch aktuell ist, muss man diese mit einem Script auf
den neuen GCC umstellen. Das geht recht einfach mit
fix_libtool_files.sh 4.6.3
Wichtig ist die Versionsangabe, denn diese sorgt dafür das nur die
Bibliotheken, die auf die Version 4.5.4 zeigen, auf die aktivierte GCC
Version umgestellt werden.
Ich wünsche Euch dann viel Erfolg und möge die Macht von emerger immer
mit uns sein.