Im letzten Teil der Anleitung arbeiteten wir bis emerge ‑e system durch. Nachdem wir dies erfolgreich überstanden haben können wir uns dem nächsten Schritt widmen und die ACCEPT_KEYWORDS in der make.conf auf ~x86 setzen.
Ein emerge ‑uDp system und schliesslich emerge ‑uD system bringt uns auf den aktuellen Stand. Hier gilt das Selbe wie beim vorhergegangenen Schritt: Get a life. — Was ich damit sagen möchte ist, dass jetzt ein guter Zeitpunkt ist um sich im Zimmer umzusehen und festzustellen was sich in den letzten Jahren verändert hat. Sollte es vorkommen, dass man ‘Papa’ oder ‘Mama’ gerufen wird ist dies kein neuer Nick sondern mit höchster Wahrscheinlichkeit die eigenen Kinder.
Nachdem das System nun auf Stand kommen jene Pakete bei denen wir schon auswählen dürfen:
Aufgrund der Skalierbarkeit und Einfachheit von Syslog‐ng wähle ich diesen als Syslog‐Daemon. Seine Fähigkeiten auf Netzwerkserver zu loggen könnte sich eventuell als Nützlich erweisen, auch wenn es an einem Feature namens Output‐Buffering fehlt. Zugegeben, wenn mir jemand den Stecker zieht und den Akku klaut ist es besser, wenn die Logs gleich auf der Platte stehen. Also emergen wir einmal syslog‐ng (das NG dabei steht für Next Generation).
emerge syslog‐ng
Da Sicherheit bei den Logs beginnt sollte man diese leserlich halten, was ich durch folgende Config zu erreichen versuche:
options { long_hostnames(off); sync(0); stats(0); };</code>
#Log‐Quellen
source src { unix-stream(„/dev/log“); internal(); };
source kernsrc { file(„/proc/kmsg“); };
#Wohin mit dem Zeug?
destination authlog { file(„/var/log/auth.log“); };
destination syslog { file(„/var/log/syslog“); };
destination cron { file(„/var/log/cron.log“); };
destination daemon { file(„/var/log/daemon.log“); };
destination kern { file(„/var/log/kern.log“); };
destination lpr { file(„/var/log/lpr.log“); };
destination user { file(„/var/log/user.log“); };
destination mail { file(„/var/log/mail/mail.log“); };
destination mailinfo { file(„/var/log/mail/mail.info“); };
destination mailwarn { file(„/var/log/mail/mail.warn“); };
destination mailerr { file(„/var/log/mail/mail.err“); };
destination newscrit { file(„/var/log/news/news.crit“); };
destination newserr { file(„/var/log/news/news.err“); };
destination newsnotice { file(„/var/log/news/news.notice“); };
destination debug { file(„/var/log/debug“); };
destination messages { file(„/var/log/messages“); };
destination console { usertty(„root“); };
destination console_all { program(„ccze ‑r >> /dev/tty12“); };
destination xconsole { pipe(„/dev/xconsole“); };
# Wir wollen ja nicht alles…
filter f_auth { facility(auth); };
filter f_authpriv { facility(auth, authpriv); };
filter f_syslog { not facility(authpriv, mail); };
filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_user { facility(user); };
filter f_debug { not facility(auth, authpriv, news, mail); };
filter f_messages { level(info..warn)
and not facility(auth, authpriv, mail, news); };
filter f_emergency { level(emerg); };
filter f_info { level(info); };
filter f_notice { level(notice); };
filter f_warn { level(warn); };
filter f_crit { level(crit); };
filter f_err { level(err); };
filter f_failed { match(„failed“); };
filter f_denied { match(„denied“); };
#Filter und Ziele verbinden:
log { source(src); filter(f_authpriv); destination(authlog); };
log { source(src); filter(f_syslog); destination(syslog); };
log { source(src); filter(f_cron); destination(cron); };
log { source(src); filter(f_daemon); destination(daemon); };
log { source(kernsrc); filter(f_kern); destination(kern); };
log { source(src); filter(f_lpr); destination(lpr); };
log { source(src); filter(f_mail); destination(mail); };
log { source(src); filter(f_user); destination(user); };
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };
log { source(src); filter(f_debug); destination(debug); };
log { source(src); filter(f_messages); destination(messages); };
log { source(src); filter(f_emergency); destination(console); };
#Alles nochmal hierlang:
log { source(src); destination(console_all); };Um das Logging in vollen Zügen geniessen zu können lasse ich es noch zusätzlich auf der Console 12 mitlaufen, was mit der Zieldefinition destination console_all { program(„ccze ‑r » /dev/tty12“); }; passiert. Das Programm ccze hat den Sinn die Logs je nach Ereignis einzufärben um es leserlicher zu gestalten.
Als Cron Daemon bietet sich Paul Vixie’s vixie‐cron an. Die Standard‐Konfiguration sollte für uns ausreichen, wobei man mit Umgebungsvariablen das Verhalten beeinflussen kann:
SHELL=/bin/sh PATH=/usr/bin:/usr/sbin:/sbin:/bin
* * * * task to doWenn man bei einem Cronjob keine Berichtsmail haben möchte, so sollte man diesen mit „2&1>/dev/null“ zum Schweigen bringen, indem man so seine gesamten Ausgaben nach /dev/null umleitet.
Jetzt wo wir einen Cron‐Daemon am System haben, ist es interessant diesem auch Arbeit zu geben: Das Paket logrotate ist dazu da, die Systemlogs zusammenzuräumen indem es sie aufteilt, packt und alte Logs löscht. Seine Konfiguration für unseren Syslog‐NG sieht folgendermassen aus:
/var/log/auth.log /var/log/syslog /var/log/cron.log /var/log/daemon.log /var/log
/kernel.log /var/log/user.log /var/log/mail/* /var/log/news/* /var/log/debug.log
{
monthly
size 1M
missingok
notifempty
sharedscripts
postrotate
/etc/init.d/syslog-ng reload > /dev/null 2>&1 || true
endscript
}</code>
/var/log/messages {
daily
size 1M
missingok
notifempty
sharedscripts
postrotate
/etc/init.d/syslog-ng reload > /dev/null 2>&1 || true
endscript
}Wichtig dabei ist, dass der Syslogger nach dem Rotieren der Logs neu geladen werden muss damit er weiter in Files schreiben kann!
Die Wahl des Kernels überlasse ich jedem selbst. Ich habe mich für die Gentoo‐Sources entschieden, welche ich noch händisch mit diversen Patches verfeinere. Ein nützliches Werkzeug beim Bauen des Kernels ist genkernel, welches mich mit dem Parameter –menuconfig die Konfiguration des Kernels von Hand erledigen lässt. Danach werden automatisch der Kernel, die Module und ein Initrd gebaut, was ich persönlich als ein angenehmes Feature empfinde. Die einzelnen Kernelkonfigurationen liegen dann nach Versionen benannt in /etc/kernels.
Nach Abschluss des Kernels benötigen wir einen Bootloader. Ich habe mich für GRUB entschieden, da sich dieser on the fly richten lässt. Das heisst für mich, wenn ich die Konfiguration ändern muss kann ich auf eine Shell gelangen um den Kernel im schlimmsten Fall manuell zu laden. Seine in /boot/grub/menu.lst befindliche Konfiguration (oft ein Symlink zu grub.conf) sieht wie Folgt für mich aus:
default 0 timeout 30
splashimage=(hd0,4)/grub/splash.xpm.gz</code>
#———————————————————————————
title=Gentoo Linux (2.6.16-gentoo-r2)
root (hd0,4)
kernel /kernel-genkernel-x86‑2.6.16-gentoo-r2 root=/dev/ram0 init=/linuxrc real_root=/dev/hda5
initrd /initramfs-genkernel-x86‑2.6.16-gentoo-r2
#———————————————————————————
title Windows XP
rootnoverify (hd0,0)
makeactive
chainloader +1Danach geht es ans Einrichten der Konfigurationsdateien. Wichtig dabei sind die fstab, die Keyboardmappings und die rc. Ist dies geschehen setzen wir das Root‐Passwort, verlassen das chroot und rebooten, nach sorgfältigem Unmounten der Dateisysteme.
Wenn das System nun wie geplant bootet und man sich als root einloggen kann, das Netzwerk funktioniert können wir uns auf der Konsole häuslich einrichten — doch dazu an einem anderen Tag.