Arktur:Entwicklersystem
|
Archiv: Dieser Artikel beschreibt nicht die Funktionalität des derzeit aktuellen delixs-Servers. Er beschreibt ältere Schulserver-Funktionen und dient dem Zweck der Archivierung. |
Entwicklungssystem einrichten
Entwicklungsserver einrichten
System von der aktuellen CD installieren. Keine Updates einspielen;
die Version des installierten Systems muß mit der Entwicklungsumgebung auf der CD übereinstimmen!
System gebrauchsfähig konfigurieren; insbesondere dem User root ein Kennwort vergeben.
Eine zweite Festplatte einbauen
Im folgenden gehe ich davon aus, daß diese als Slave am ersten IDE-Kanal hängt und somit die Kennung "hdb" zugewiesen bekommt. Die Kennung ändert sich, sofern man die Platte als Master oder Slave am zweiten IDE-Kanal anschließt (hdc bzw. hdd). An einer zweiten SCSI-Platte muß man eine höhere ID einstellen als am Boot-Device. Die Kennungen "sda"-"sdh" entsprechen den IDs 0-7. Ein gemischter Betrieb von SCSI und IDE ist nicht empfehlenswert.
System starten
Nun als root anmelden und die zweite Platte partitionieren und formatieren:
fdisk /dev/hdb hdb1: primär, mindestens 50 MByte größer, als die geplante CD (>250MB) hdb2: primär, mindestens so groß, wie die geplante CD (>200MB) mke2fs /dev/hdb1
hdb1 verfügbar machen
mkdir /hdb1
In der Datei /etc/fstab folgende Zeile eingefügen (Editor: "joe"):
/dev/hdb1 /hdb1 ext2 defaults 1 1
hdb1 von Hand mounten (passiert beim nächsten Booten automatisch):
mount /hdb1
Die Entwicklungsumgebung von der CD (/usr/src/ods-server.tar.gz) auspacken
cd /hdb1 mount /cdrom tar xzf /cdrom/usr/src/ods-server.tar.gz
Die CD kopieren
mkdir CD
cd CD
(cd /cdrom ; tar cf - . ) | tar xf -
find . -name TRANS.TBL -exec rm -f {} \;
Noch zwei Links herstellen
ln -s /hdb1/CD /server ln -s /hdb1/src/ods-server ~/ods
Struktur des Entwicklungssystems
Das Entwicklungssystem besteht aus drei Teilen:
1. Der lauffähige Kommunikationsserver, der gebootet wird.
2. Eine Kopie der Original-CD auf Festplatte (liegt unter /hdb1/CD und ist unter /server erreichbar). Daraus wird später die neue Distribution erzeugt.
3. Die eigentliche Entwicklungsumgebung (/hdb1/src/ods-server). Entwickler müssen sich immer als User root anmelden und erreichen das entsprechende Verzeichnis mit
cd ods
Arbeiten mit dem Entwicklungssystem
Um mir das Leben nicht unnötig zu erleichtern, habe ich das von Klaus Füller ursprünglich integrierte Versionsverwaltungssystem RCS entfernt. Alle Änderungen werden daher zunächst im laufenden System vorgenommen. Das betrifft sowohl Modifikationen an den Menüs, Skripten und Programmen der Systemverwaltung (unter /usr/lib/ods-server), an den Konfigurations-Dateien der installierten Pakete (meist unter /etc zu finden) sowie das Austauschen bzw. Neuinstallieren von Servern und Systemerweiterungen (bevorzugt unter /usr/lib oder /usr/local).
War eine Änderung erfolgreich, übernehme ich sie in die Entwicklungsumgebung (~/ods). Dort existiert für jede nachträglich installierte Systemkomponente ein Unterverzeichnis. Entfernt man eines davon oder fügt ein neues hinzu, muß dieses auch im Makefile entfernt bzw. eingetragen werden.
Die Namen der Unterverzeichnisse in der Entwicklungsumgebung geben an, welche Software darin enthalten ist: z. B. "Apache" (Web-Server) oder "Squid" (Proxy). Vier Verzeichnissen kommt eine besondere Bedeutung zu: "Installation" enthält die Quellen für den Installationsvorgang sowie die Bootdiskette. Änderungen hieran setzen ein tieferes Verständnis von Linux voraus, andernfalls erzeugt man leicht eine wertlose CD. "Setup" enthält unter anderem ein Skript, das am Ende der Installation ausgeführt wird. Es dient dazu, für verschiedene Verzeichnisse die Benutzerrechte zu korrigieren und weitere Nachbesserungen vorzunehmen. Außerdem enthält es ein buntes Allerlei an Systemdateien mit geringfügigen Änderungen, die keinem bestimmten Installationspaket zugeordnet sind. Da ich Setup gelegentlich dazu benutzt habe, in letzter Sekunde aufgetretene Probleme zu fixen, geht es hier etwas durcheinander zu.
In "Systemverwaltung" liegen alle Menüs, Skripte und Programme der Systemverwaltung sowie die Online-Hilfe. Hierbei ist zu beachten, daß in den Unterverzeichnissen "bin", "menue" und "texte" eigene Makefiles liegen, in denen alle Dateien aufgelistet sind. Diese Listen muß man bei Änderungen entsprechend ergänzen. "Update" schließlich enthält auf CD-Versionen bis 2.0 das ursprüngliche Gerüst von Klaus Füller für Updates des Kommunikationsservers. Dieses hat sich in der Praxis jedoch als unzureichend erwiesen und wurde von mir nochmals überarbeitet. Ab Version 2.1 enthält dieses Verzeichnis das Update von Version 1.0 auf 2.1 als Beispiel. Eine Dokumentation dazu fehlt; allerdings enthalten die Skripte eine recht ausführliche Kommentierung.
Neben den Unterverzeichnissen enthält die Enwicklungsumgebung noch folgende Dateien: Die "HINWEISE_ZUR_SYSTEMENTWICKLUNG", die Sie gerade lesen, die "Lizenz"-Bedingungen des c't/ODS-Kommunikationsservers, die Dateien "m*", welche die CD erzeugen, sowie "serial" und "version", eine Seriennummer, die bei jedem Build hochgezählt wird, und als Versionsdatei auf die CD geschrieben wird. Das "Makefile" steuert die Erstellung der CD (s. später) und ruft die Makefiles sämtlicher Unter- verzeichnisse auf. In älteren Versionen enthielt die Entwicklungsumgebung noch diverse Überbleibsel ohne Funktion, die ich nach und nach getilgt habe.
Bis Version 2.0 enthielt die Entwicklungsumgebung auch noch die Client-Software und die HTML-Dokumentation in den Unterverzeichnisse "Software" und "Doku". Da diese beiden Komponeten jedoch unter Windows gepflegt werden, habe ich die Dateien aus der Entwicklungsumgebung entfernt (was diese erheblich verkleinert und frei von Rechten Dritter macht). Die Sachen liegen sowieso ausgepackt auf der CD; ich führe Änderungen daher direkt in /server durch und erstelle dann die Installations-Archive von dort.
Die Entwicklungsumgebung ist den spezifischen Erweiterungen des c't/ODS-Kommunikationsservers vorbehalten. Standard-Linux-Software wie den EMail-Reader "elm" packt man besser direkt zu den Slackware-Paketen unter /server/slack; im Fall von elm ins Unterverzeichnis "n1", wo die Netzwerksoftware liegt. Damit die Installation dann aber auch klappt, muß man das Archiv noch in die Datei "slack-files" im Unterverzeichnis "./Installation" der Entwicklungsumgebung eintragen.
Noch ein Tip am Rande: Die root-Crontab sollte man nicht verändern. Regelmäßige Systemdienste des Kommunikationsservers ruft man in einem eigenen Skript auf, das unter /usr/lib/ods-server/cron installiert und von cron automatisch ausgeführt wird - sofern es bestimmte Namenskonventionen erfüllt. Die dort vorhandenen Skripte können als Vorlage dienen.
Womit wir beim Aufbau der Unterverzeichnisse in der Entwicklungsumgebung angelangt wären. Diese enthalten zunächst das Verzeichnis "ziel", dessen Inhalt bei der Installation relativ zum "/"-Verzeichnis kopiert wird. Um also eine Datei /usr/lib/test zu installieren, legt man sie als ziel/usr/lib/test ab. Neben "ziel" enthält jedes Unterverzeichnis ein Makefile, das man am besten aus einem bestehenden Verzeichnis übernimmt und anpaßt.
Das Makefile kann verschiedene Aufgaben erfüllen: So empfiehlt es sich, die Konfigurationsdateien eines Server-Pakets direkt im jeweiligen Unterverzeichnis der Entwicklungsumgebung abzulegen, da man daran am häufigstem Änderungen vornehmen wird. Das Makefile kann die Konfigurationsdateien dann in das jeweilige Verzeichnis unter "ziel" kopieren.
Die wichtigste Konfigurationsdatei heißt "doinst.sh" und muß nach "ziel/install" kopiert werden. Sie wird dann nach dem Entpacken des jeweiligen Archivs einmal ausgeführt und gelöscht. Hier werden beispielsweise die Zugriffrechte für Verzeichnisse korrigiert etc. Desweiteren muß das Makefile gegebenenfalls die erwähnten cron-Dateien nach ziel/usr/lib/ods-server/cron packen.
Danach erzeugt es aus dem ziel-Verzeichnis ein gepacktes Archiv, für das sich ein 8-stelliger Name mit tgz-Endung empfiehlt, etwa "odsapach.tgz" für den Apache-Server. Dieses Archiv muß "make" dann noch in das entsprechende Verzeichnis unter /server/slack verbringen. Für ODS-Erweiterungen sind dort drei Unterverzeichnisse vorgesehen: "ods1" für zusätzliche Server, "ods8" für systemnahe Komponenten wie den Kernel, den C-Compiler oder die Libraries. "ods9" ist reserviert für Setup, da die darin enthaltenen Pakete zuletzt installiert werden. Ein gutes Vorbild für ein Makefile, das alle beschriebenen Funktionen ausführt, befindet sich in "~/ods/Apache".
Ich habe es mir angewöhnt, in den Unterverzeichnisse der Entwicklungsumgebung auch die Original-Archive abzulegen, aus denen ich die entsprechenden Server kompiliert habe. Damit ist die Forderung der GNU Public License erfüllt, die Quelltexte weiterzugeben.
Der Kommunikationsserver besitzt noch einen weiteren Mechanismus, um Skripte nach der Installation, beim Einloggen des "sysadm" auszuführen. Dann führt das Programm "Start" in "/usr/lib/ods-server/menue" alle Skripte aus, die es in "/var/adm/setup" findet und die der Namenskonvention "ods.xxx" entsprechen. Im Gegensatz zu den anderen Installationsskripten lassen sich diese auch mit einer "dialog"-Oberfläche versehen. Wie das funktioniert, kann man sich in der Entwicklungsumgebung anhand INN/ods.inn und Squid/ods.proxy verinnerlichen. Die Skripte werden so lange beim Anmelden von sysadm ausgeführt, bis sie sich aus "/var/adm/setup" entfernen (nach "/var/adm/setup/done" verschieben).
Änderungen am Kernel
Wer beispielsweise einen neuen Treiber für eine Netzwerk-Karte integrieren möchte, kommt nicht um das Neukompilieren des Kernels herum. Dazu wechselt man als root in das Verzeichnis "~/linux". Dort befindet sich eine ausführlich Anleitung in der Datei "README". Jedoch sollten Sie kein "make mproper" aufrufen; es löscht zuviel. Die aktuellen Einstellungen des Kernels liegen in der Datei "ods-kommserv".
Hat man einen neuen Kernel kompiliert und getestet (Aufruf von "lilo" nicht vergessen), wird dieser folgendermaßen in die Distribution eingebaut:
Source Tree aufräumen (spart Platz und Zeit)
cd ~/linux make clean
Archiv aus Kernel-Quellen und -Modulen erzeugen
cd / rm -f /server/slack/ods8/lx2029.tgz tar czf /server/slack/ods8/lx2029.tgz lib/modules usr/src/linux zImage
Der Name des Kernel-Archivs sollte entsprechend der Versionsnummer des Kernels gewählt werden (derzeit 2.0.29). Wer eine neue Version einspielen möchte, sollte sich vorsehen: Er muß die entsprechende Version der HISAX-ISDN-Treiber einbauen. In diesen unterscheiden sich je nach Version die Aufrufparameter, so daß man auch die Skripte der Systemverwaltung anpassen muß. Eine weitere Hürde stellt die Plug&Play-Unterstützung dar, die korrekt funktionieren muß. Ab Version 2.0 ist außerdem auch das IP-Masquerading vorbereitet, obwohl ich noch keine Unterstützung in der Oberfläche eingebaut habe.
Testen einer neuen Version
Um eine neue Distribution zu testen, muß man nicht gleich eine neue CD brennen. Stattdessen kann man die zweite Partition auf der zusätzlich eingebauten Platte als ISO-Filesystem mißbrauchen und davon installieren. Dabei wird dann die erste Platte des Entwicklungssystems gelöscht. Falls dann Fehler auftreten, muß man aus der Entwicklungsumgebung und der Original-CD das System wieder mühsam neu zusammenbauen (die Schritte 2 und 3 unter I. auslassen). Wer sich den Luxus leisten kann, benutzt daher für den Test eine dritte Festplatte.
Wichtig: Beim Erzeugen einer Testversion wird die betreffende Partition ohne Rückfrage überschrieben! Man muß also unbedingt im Makefile der Entwicklungsumgebung die Variable PART auf die zweite Partition der zweiten Festplatte einstellen; als Default-Wert ist dort "hdb2" (IDE-Platte als Slave am ersten Kanal) eingetragen. Falls man hier eine Änderung vornimmt, muß man eine entsprechende Bootdiskette erzeugen (vor dem nächsten Schritt!): In der Entwicklungsumgebung unter "./Installation/bootdisk.neu/etc" die Datei "rc.local" editieren und dort die entsprechende Partition in der Variable "altdev" eintragen. Danach in "./Installation" mit "MakeBootdisk" eine neue Bootdiskette erzeugen. Auch dabei wird die freie Partition der zweiten Platte verwendet, die man daher in "MakeBootdisk" vor dessen Aufruf der Variablen "tmpdev" zuweisen muß.
Eine neue Distribution wird in der Entwicklungsumgebung (~/ods) mit dem Befehl
make inst
erzeugt. Das dauert bei mir (Pentium 133, 16 MByte, IDE-Platte) knapp 5 Minuten. Das Makefile löscht alle vorhandenen Installationspakete, generiert sie neu und packt sie an die richtige Stelle unter "/server". Achtung: Make verwaltet nicht die Dateien unter "/server" sondern kopiert nur alles dort hin, was es in der Entwicklungsumgebung vorfindet. Entfernt man beispielsweise ein Paket aus der Distribution, muß man es unter "/server" von Hand löschen. Gerade bei längeren Entwicklungszyklen lohnt sich also regelmäßiges Entrümpeln.
Ist "/server" komplett bestückt, kann man daraus ein CD-Image erzeugen
make cd
Das dauert keine 2 Minuten. Als Ergebnis findet man unter "/var/tmp" eine Datei namens "odscd.iso", die derzeit etwa 110 MByte groß ist und den gesamten c't/ODS-Kommunikationsserver als CD-Image im ISO-9660-Format enthält. Außerdem wird dabei die Seriennummer in "./serial" um eins erhöht.
Das CD-Image läßt sich nun zu Testzwecken auf die zweite Partition der zweiten Platte bringen:
make part
Das dauert knapp 1,5 Minuten. Paranoiker können nun nochmals 4 Minuten damit verbringen, mit
make pcheck
den Inhalt der Partition mit den Dateien unter "/server" zu vergleichen.
Nun benötigt man nur noch eine Bootdiskette, die in der Entwicklungsumgebung mit
make bootdisk
erzeugt wird. Dabei empfiehlt es sich übrigens, die Diskette im Linux-Format zu erstellen
fdformat /dev/fd0H1440
Um die Distribution von der zweiten auf die erste Platte zu installieren, muß man dann lediglich von dieser Diskette booten, wobei natürlich keine Kommunikationsserver-CD eingelegt werden sollte, da sonst von dieser installiert wird. Die Entwicklungsumgebung und das ISO-File auf der zweiten Platte werden dabei nicht verändert.
CD gut, alles gut
Hat die Distribution sich bewährt, kann man sie auf CD bannen. Dazu muß, wie beschrieben, ein ISO-9660-Image unter "/var/tmp/" erzeugt werden:
make inst make cd
Das Brennen dürfte in den meisten Fällen auf einer anderen Maschine erfolgen, auf die man das Image am besten über ein lokales Netz überträgt. Wichtig ist, daß "odscd.iso" nicht als Datei, sondern als Image auf die rohe CD geschrieben wird (s. Doku der Brenner-Software).
Paranoiker können den Inhalt der CD noch mit den Dateien unter /server vergleichen:
make ccheck
Abschließend möchte ich noch auf unser Mailing-Liste für Entwickler des c't/ODS-Kommunikationsserver hinweisen. Um daran teilzunehmen, senden Sie bitte eine EMail (ohne subject) mit dem Inhalt "subscribe schan-developer" an majordomo@listserv.heise.de. Sie sollten innerhalb weniger Minuten eine Bestätigung erhalten.
Axel Kossel
Redaktion c't, Hannover