Dieses Jahr wurde von der Fachschaft Informatik mal wieder eine Unixeinfuehrung in die Projektwoche aufgenommen, die ich letzten Freitag gehalten habe. Die Vortragsfolien finden sich im Anhang zum Download. Viel Spass damit.
Download: unixeinfuehrung2010.zip
So ab und an kommt es doch mal vor, dass ich mich von FreeBSD zu Open- oder NetBSD verirre. Dann stehe ich jedes mal vor der Frage: Verbrenne ich einen Rohling fuer die Installation oder installiere ich den Kram via Netzwerk? Meist entscheide ich mich dann fuer letzteres. Die Infrastruktur (TFTP- und DHCP-Server) ist sowieso vorhanden.
Gestern war wieder so ein Versuch ein NetBSD5 auf eine Kiste zu buegeln. Es war bei NetBSD mal so, dass es einen extra Installations-Kernel gab. Da brauchte man lediglich die pxeboot-Datei, die dem DHCP-Server hingeworfen wurde und eben diesen Installation-Kern. Mitlerweile hat sich aber eine Kleinigkeit geaendert, denn es wird nur noch der GENERIC-Kern und eine Ramdisk (miniroot.kmod) benoetigt um ins NetBSD-Setup zu gelangen. Um diese Veraenderung zu verstehen bzw. um herauszubekommen, wie es nun tatsaechlich geht, habe ich eine ganze Weile gebraucht. Das NetBSD-Handbuch schweigt sich darueber aus.
Der Anfang dieser Installation ist wie gehabt. Man startet einen TFTP-Server, der die Dateien pxeboot_ia32.bin (fuer NetBSD5 zum Beispiel hier herunterladbar) und kern-GENERIC.tgz (Download hier) ausliefert. Darueber hinaus braucht man mitlerweile noch die entsprechende Ramdisk: miniroot.kmod (gibts hier zum herunterladen)
Unter FreeBSD wuerde das etwa so aussehen: Zunaechst werden die Dateien heruntergeladen und in /tftpboot abgelegt.
cd /tftpboot
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/installation/misc/pxeboot_ia32.bin
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/binary/sets/kern-GENERIC.tgz
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/installation/miniroot/miniroot.kmod
Nun muss noch der TFTP-Server in /etc/inetd.conf aktiviert werden. Dazu wird das Kommentarzeichen vor der Zeile
#tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot
entfernt. Danach kann man dann entweder ein inetd_enable=”YES” in /etc/rc.conf unterbringen und mittels /etc/rc.d/inetd starten, oder aber man fuehrt einfach ein /etc/rc.d/inetd forcestart aus. Beides fuehrt auf jeden Fall dazu, dass der inetd gestartet wird.
Einen laufenden DHCP-Server vorausgesetzt, sollte ein kleiner Eintrag reichen. Ich selber habe einen isc-dhcpd am laufen, den ich um folgende Zeile im Subnet-Bereich der dhcpd.conf ergaenzt habe:
filename "pxeboot_ia32.bin";
Danach noch den DHCP-Server neustarten (/usr/local/etc/rc.d/isc-dhcpd restart) und alles sollte soweit funktionieren.
Sicher koennte man auch der Einfachheit halber einen Eintrag fuer die entsprechende MAC-Adresse machen, aber ich hatte diese gerade nicht zur Hand, als ich den DHCP konfiguriert habe. Sie stand schlichtweg nicht auf dem Device drauf. Also habe ich einfach als globale Einstellung das pxeboot eingetragen. Da sollte man vielleicht noch dran denken das wieder zu deaktivieren. Ansonsten koennte es irgendwann mal komische Ueberraschungen geben, wenn ploetzlich einige Rechner versuchen ein NetBSD aus dem Netz zu booten. 
Nun fehlt eigentlich nur noch eine Sache, die da waere, den Zielrechner zu installieren. Dazu wird er ganz normal angeschlossen und gestartet. Sofern er pxeboot-faehig ist und dies auch aktiviert ist (das ist rechnerabhaengig), sollte der NetBSD-pxeboot kommen. Dort hat man 5 Sekunden lang Zeit die Leertaste zu druecken. Nachdem das erfolgt ist, braucht man eigentlich nur noch zwei Befehle:
load tftp:miniroot.kmod
boot tftp:kern-GENERIC.tgz
Falls man noch Einstellungen mittels userconf machen will, kann man hier noch ein -c anfuegen: boot tftp:kern-GENERIC.tgz -c.
Soweit so gut, sollte eigentlich funktionieren und den Rechner ins Setup booten lassen.
Auch bei diesem Release gibt es die finalen Fedora-Images mal wieder ein kleines Stückchen früher als gewöhnlich zum downloaden: ftp://public.lando.cc/pub/linux/fedora11/.
Ich habe am Wochenende meinen CentOS-Server auf Version 5.3 gehievt, was erstaunlich problemlos funktioniert hat. Nach ein paar Empfehlungen aus einigen Foren, habe ich folgende Updatebefehle gewählt:
yum -y update yum yum clean all yum -y update glibc yum -y update
Nun noch das Plesk-Update durchwuergen – das gabs dann gestern Nacht. Sonst hatte ich ja bei jedem groesseren Plesk-Update eher mit Problemen zu kaempfen. Aber diesmal hat auch das erfreulicher Weise funktioniert. Man sollte sich lediglich die Updateanweisung einmal genauer anschauen. Diese ist auf den Parallels-Seiten zu finden. Das Greylisting funktioniert wunderbar und spart auf meinem Server einiges an Ressourcen an. DNS-Blacklisting ist zwar gut und schoen, bringt aber nicht immer sonderlich viel. Ich denke, dass die Kombination aus DNSBL und Greylisting sehr lange und gut funktionieren wird.
Während meines Studiums komme ich nicht umhin auch mal ein wenig an Software herumzufrickeln – eine davon ist ein KSWS (komplexes SoftWare-System). Zu viert versuchen wir einen Petrinetz-Analyse-Tool aufzubohren, damit es netzwerkfähig wird. Durch den enormen Arbeitsspeicher verbrauch kommt es bei großen Netzen zu Engpässen. Dies versuchen wir dadurch zu umgehen, dass wir die einzelnen Zustände/Schaltvorgänge in einem Cluster zu verteilen, wozu OpenMPI zum Einsatz kommen sollte. Von einem Betreuer erfuhren wir dann, dass sein Nightly-Build-Script auf einem Solaris läuft. Dies stellte ihn vor das Problem, dass er nun versuchen müsste ein OpenMPI auf Solaris zur Verfügung zu stellen, was sich jedoch als schwieriger herausstellte als ihm lieb war.
Ich habe nun schon die eine oder andere Sache mit pkgsrc zu tun gehabt – ein Paketmanagement, dass ursprünglich aus der NetBSD-Ecke kommt. Durch die enorme Portabilität läuft es auf vielen Betriebssystemen wie z.B. Windows – oder eben auch Solaris. Via CVS war pkgsrc schnell ausgecheckt (wie das geht, siehe pkgsrc-Handbuch) und dann ging das Suchen los: pkgsrc auf Solaris, ohne root-Zugriff in irgendeinen Ordner. Das pkgsrc-Handbuch half mir leider nicht viel weiter, also habe ich joerg@netbsd.org mal ein wenig dazu befragt. Er gab mir den Hinweis, dass ich nur ein –prefix beim bootstraping brauche. Der erste Versuch damit gab mir dann die Meldung, dass ich root-Zugriff brauche um durchzulaufen ODER ein –unprivileged benutze. Hier nun mal meine Konfiguration:
Um nun pkgsrc zu installieren, wechselt man nach /users/wwwstud/ug003/pkgsrc/cvs/bootstrap und führt ein:
./bootstrap \
--prefix=/users/wwwstud/ug003/pkgsrc/pkgsrc \
--unprivileged
aus, was zumindest auf SunOS ekas 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Fire-V440 problemlos durchlief. Danach hat man eigentlich alles zur Hand, was man braucht. Was man natürlich noch beachten muss ist das, was einem pkgsrc zum Schluss des bootstraps noch als Hinweis gibt:
Please remember to add /users/wwwstud/ug003/pkgsrc/pkgsrc/bin to your PATH environment variable and /users/wwwstud/ug003/pkgsrc/pkgsrc/man to your MANPATH environment variable, if necessary.
An example mk.conf file with the settings you provided to “bootstrap” has been created for you. It can be found in:
/users/wwwstud/ug003/pkgsrc/pkgsrc/etc/mk.conf
You can find extensive documentation of the NetBSD Packages Collection in /users/wwwstud/ug003/pkgsrc/cvs/doc/pkgsrc.txt.
Hopefully everything is now complete.
Thank you
Das hoffe ich dann natürlich auch, zumal mein eigentliches Problem mit OpenMPI damit noch nicht gelöst ist, denn dies gibts nur im WiP (Work-In-Progress)-Tree von pkgsrc.
Den WiP-Tree erhält man ebenfalls über CVS. Die Anleitung dazu gibt es auf den sourceforge-Seiten des pkgsrc-wip projects. Danach ist der WiP-Tree bei mir dann z.B. unter /users/wwwstud/ug003/pkgsrc/cvs/wip zu finden und man kann im Ordner openmpi ein bmake install clean durchführen. Am Ende hat man dann ein laufendes OpenMPI, dass ohne root-Zugriff auskommt – hoffte ich.
Wieder mal einer dieser merkartigen Fehler: Ich habe ein frisches FreeBSD7.1 auf einem Xeon mit 1GB RAM und 2 SCSI-Platten im Software RAID-1 installiert. Ports-Tree geladen und wollte dann die eine oder andere Anwendung installieren: Ruby, portupgrade, Midnight Commander, … und spaetestens der Midnight Commander faengt an als Abhaengigkeit ein Perl haben zu wollen. Mitten drin brach das ganze aber mit folgendem Fehler ab:
==> Your Makefile has been rebuilt. <==
==> Please rerun the make command. <==
false
*** Error code 1
Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9/ext/DynaLoader.
make config failed, continuing anyway...
Makefile out-of-date with respect to Makefile.PL
Cleaning current config before rebuilding Makefile...
make -f Makefile.old clean > /dev/null 2>&1
../../miniperl "-I../../lib" "-I../../lib" Makefile.PL "INSTALLDIRS=perl" "INSTALLMAN3DIR=none" "PERL_CORE=1" "LIBPERL_A=libperl.so"
Writing Makefile for DynaLoader
==> Your Makefile has been rebuilt. <==
==> Please rerun the make command. <==
false
*** Error code 1
Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9/ext/DynaLoader.
*** Error code 1
Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9.
*** Error code 1
Stop in /usr/ports/lang/perl5.8.
*** Error code 1
Stop in /usr/ports/lang/perl5.8.
Das fand ich dann ein wenig bedenklich. Also fing ich an zu gruebeln, was das sein koennte. Der Versuch ein frisches FreeBSD-Grundsystem zu installieren, scheiterte daran, dass irgendwelche Dateien nicht kopiert werden konnten, weil sie angeblich nicht existierten. Warum aber lief dann bitte das buildworld durch? Neuinstallieren und nochmal probiert. Aenderte nichts, das Perl brach beim selben Fehler wieder ab. Ich weiss nicht mehr genau bei welchem Befehl es war, aber irgendwann gab mir ein Kommando mal zurueck, dass das Systemdatum nicht stimmte. Bah! Widerliches Zeug, also Systemdatum korrigiert und auf ein neues Perl kompiliert – siehe da: geht doch!
Achja, fast haette ich es vergessen, zwischenzeitlich versuchte ich dann auf dem mit dem falschen Systemdatum nochmal ein aelteres Perl (5.6 oder so). Das hatte einen anderen lustigen Effekt: es hing in irgendeine Endlosschleife und erzeugte immer neue Shell/make-Prozesse.
Was es nicht alles gibt und was ein falsches Systemdatum nicht alles anrichten kann. Genug davon für heute, ich geh schlafen.
Ich habe vor einiger Zeit von Plesk 8 auf Plek 9 umgestellt. In der Hoffnung, dass die Parallels-Leute einiges dazugelernt haetten. Aber das war wohl leider noch nicht der Fall. Es sind viele Schritte in die richtige Richtung getan worden (z.B. Umstellung von QMail auf Postfix), aber so buggy haette die Software niemals unters Volk gehen duerfen. Einer der boesesten Fehler haengt mit der Gross- und Kleinschreibung bei Domainnamen und eMail-Adressen zusammen. Sobald Grossbuchstaben im Spiel sind, kommen keine Mails mehr an. Sie werden allerdings auch nicht zum Absender zurueckgeschickt, sondern verschwinden einfach irgendwo. Ich weiss noch nicht wo, aber das finde ich noch heraus.
[Update 2009/03/16:] In den vergangenen Tagen gabs mal wieder ein bisschen Sorgen mit dem Mailing. Einige Mails (an info@) verschwanden, also gings mal wieder auf die Suche. Dabei bin ich ueber die postqueue gestolpert – da waren die ganzen nicht zugestellten Mails also hin. Schwuppdiwupp aussortiert und dann die Queue einfach mal ausgeleert. Danach dann weitergesucht, warum einige Mails zugestellt wurden und einige nicht. Dabei fand ich – wieder mittels postqueue -p – heraus, was das eigentliche Problem war. Der hostname-Eintrag in der main.cf war nicht korrekt. Dazu kamen noch zwei Begrenzungen fuer Postfachgroessen, die ich anpassen musste.
Wie durch Zufall ist mir heute schon das neue Fedora 10 begegnet. Ich habe die wichtigsten ISOs mal zum Download auf meinem FTP abgelegt. Zu finden unter: ftp://public.lando.cc/ . Die Version ist Final. Viel Spass damit.
Leser meines Blogs wissen, dass ich ein Macbook mit Intel Core2Duo-Prozessor habe. Dazu noch 2GB RAM und mitlerweile eine 250GB Festplatte. Warum also nicht ein weiteres Betriebssystem neben dem FreeBSD installieren? Ein Windows fuer unterwegs ist nicht ganz verkehrt. Woher aber nen brauchbaren WLAN-Treiber nehmen? Sicher auf der MacOS 10.5 DVD ist einer drauf. Ich habe aber nur ein 10.4 dazubekommen – und kaufen werde ich mir keine aktuellere Version. Also mal ein bisschen geschaut, was da genau drin ist.
Unter FreeBSD laeuft der eingebaute Atheros-Chip auch noch nicht sauber, unter Windows wird er von vornherein garnicht mit Treibern versorgt. Auch uebers Windows-Update gibts keine Neuerungen. Auf den Apple-Seiten gibts zwar Bootcamp-Updates, diese enthalten aber keine WLAN-Treiber-Updates. Und Treiber an sich findet man bei Apple auch nicht. Also machte ich mich zunaechst auf die Suche mittels Vendor-ID und Subsys-ID, leider ohne Erfolg. Also mal direkt nach dem verbauten Chip gesucht. Die Informationen, die mir zur Verfuegung standen waren etwas duerftig: Atheros 5007 oder 5008, b/g/n-faehig. Zu meinem Glueck gibts da aber nicht allzuviele Modelle von. Nach ein wenig Googlen kam mir eine Mini-PCIexpress-Karte von Gigabyte unter die Finger, die eben diesen Atheros-Chip verwendet: GN-WS50G-RH (1.0). Die Treiber, die Gigabyte dort anbietet, laufen bisher recht brauchbar auf meinem Vista x64. Nun fehlen noch ein paar andere Dinge, z.B. das Apple-Tastatur-Zeug, aber ich glaub dadrauf kann ich auch verzichten.
Nachtrag: Noch bin ich auf der Jagd nach Treibern fuer den integrierten Soundchip. Das ist irgendwas Sigmatel-artiges. Unter FreeBSD laeuft er hervorragend, unter Windows passt jedoch kein Treiber so recht. Wer ne Idee hat, kann mir die ja mal als Kommentar hinterlassen.
So langsam kehrt wieder Ruhe ein. Die beiden Serverumzüge sind fast geschafft. An einigen Ecken und Kanten muss ich noch ein wenig frickeln, aber 95% aller Dinge laufen erstmal wieder. Das heisst fuer mich also bald erstmal: Wochenende.
Achja, was die Alathair-Sphere betrifft: Sie laeuft jetzt auf einem CentOS5 x64 – ohne Probleme. Das auf dem alten Server schien also ein SuSE-Problem gewesen zu sein. Die Zeiten fuer einen Worldsave – wird alle 20 Minuten erstellt – sind auf etwa 4 Sekunden gesunken. Das ist eine Verbesserung von ueber 10 Sekunden im Gegensatz zum alten Server. Weiterhin braucht das riesen Datenbank-Update-Script nun nur noch etwa 11 Minuten statt vorher 18. Eine Geschwindigkeitssteigerung, die wir wohl dem Opteron, 4GB RAM und dem RAID1 zu verdanken haben.
Das Maschinenbau-Forum konnte ohne weitere Schwierigkeiten wieder zum Laufen gebracht werden. Ich warte im Moment nur noch auf das neue SSL-Zertifikat. Warum das so lange dauert, weiss ich nicht.
Auch die anderen Seiten funktionierten ohne Probleme einfach wieder. Es war insgesamt eine doch recht ansehnliche Datenmenge, die den Umzug so derart in die Laenge gezogen hat.