Quelltext von Seite Arktur:Entwicklersystem ansehen

__NOTOC__


== 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:

<pre>
	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
</pre>

=== hdb1 verfügbar machen ===

<pre>
	mkdir /hdb1
</pre>

In der Datei /etc/fstab folgende Zeile eingefügen (Editor: "joe"):

<pre>
/dev/hdb1	/hdb1	ext2		defaults		1 1
</pre>

hdb1 von Hand mounten (passiert beim nächsten Booten automatisch):

<pre>
	mount /hdb1
</pre>
	
=== Die Entwicklungsumgebung von der CD (/usr/src/ods-server.tar.gz) auspacken ===

<pre>
	cd /hdb1
	mount /cdrom
	tar xzf /cdrom/usr/src/ods-server.tar.gz
</pre>

=== Die CD kopieren ===

<pre>
	mkdir CD
	cd CD
	(cd /cdrom ; tar cf - . ) | tar xf -
	find . -name TRANS.TBL -exec rm -f {} \;
</pre>

=== Noch zwei Links herstellen ===

<pre>
	ln -s /hdb1/CD /server
	ln -s /hdb1/src/ods-server ~/ods
</pre>

== 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

<pre>
	cd ods
</pre>

== 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) ===

<pre>
	cd ~/linux
	make clean
</pre>

=== Archiv aus Kernel-Quellen und -Modulen erzeugen ===

<pre>
	cd /
	rm -f /server/slack/ods8/lx2029.tgz
	tar czf /server/slack/ods8/lx2029.tgz lib/modules usr/src/linux zImage
</pre>

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

<pre>
	make inst
</pre>

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

<pre>
	make cd 
</pre>

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:

<pre>
	make part
</pre>

Das dauert knapp 1,5 Minuten. Paranoiker können nun nochmals 4 Minuten damit verbringen, mit

<pre>
	make pcheck
</pre>

den Inhalt der Partition mit den Dateien unter "/server" zu vergleichen.

Nun benötigt man nur noch eine Bootdiskette, die in der Entwicklungsumgebung mit 

<pre>
	make bootdisk
</pre>

erzeugt wird. Dabei empfiehlt es sich übrigens, die Diskette im Linux-Format zu erstellen

<pre>
	fdformat /dev/fd0H1440
</pre>

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:

<pre>
	make inst
	make cd
</pre>

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:

<pre>
	make ccheck
</pre>

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