I. Entwicklungssystem einrichten
================================

1. Entwicklungsserver einrichten:
	System von der aktuellen CD installieren. Keine Updates einspielen; 
	die Version des installierten Systems muss mit der Entwicklungs-
	umgebung auf der CD übereinstimmen! System gebrauchsfähig 
	konfigurieren; insbesondere dem User root ein Kennwort vergeben.

2. Eine zweite Festplatte einbauen:
	Im folgenden gehe ich davon aus, dass 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 anschliesst (hdc bzw. hdd). An einer zweiten SCSI-
	Platte muss 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.

3. System starten, als root anmelden und die zweite Platte partitionieren
und formatieren:
>	fdisk /dev/hdb
	hdb1:	primär, mindestens 50 MByte grösser, als die geplante CD (>250MB)
	hdb2:	primär, mindestens so gross, wie die geplante CD (>200MB)
>	mke2fs /dev/hdb1

4. hdb1 verfügbar machen:
>	mkdir /hdb1
In der Datei /etc/fstab folgende Zeile eingefügen (Editor: "joe" oder "mcedit"):
/dev/hdb1	/hdb1	ext2		defaults		1 1
	hdb1 von Hand mounten (passiert beim nächsten Booten automatisch):
>	mount /hdb1
	
5. 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

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

7. Noch zwei Links herstellen:
>	ln -s /hdb1/CD /server
>	ln -s /hdb1/src/ods-server ~/ods


II. Struktur des Entwicklungssystems
====================================

Das Entwicklungssystem besteht aus drei Teilen:

	1. Der lauffähige Schulserver, 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


III. 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 Entwicklungs-
umgebung (~/ods). Dort existiert für jede nachträglich installierte 
Systemkomponente ein Unterverzeichnis. Entfernt man eines davon oder 
fügt ein neues hinzu, muss 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 Installations-
vorgang 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. Ausserdem 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, dass 
in den Unterverzeichnissen "bin", "menue" und "texte" eigene Makefiles 
liegen, in denen alle Dateien aufgelistet sind. Diese Listen muss man 
bei Änderungen entsprechend ergänzen. "Update" schliesslich enthält auf 
CD-Versionen bis 2.0 das ursprüngliche Gerüst von Klaus Füller für 
Updates des Schulservers. 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-Schulservers, 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 Entwicklungs-
umgebung 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-Schulservers vorbehalten. Standard-Linux-Software wie 
den E-Mail-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, 
muss 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ässige Systemdienste des Schulservers 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 Namens-
konventionen erfüllt. Die dort vorhandenen Skripte können als Vorlage 
dienen.

Womit wir beim Aufbau der Unterverzeichnisse in der Entwicklungs-
umgebung 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 anpasst.

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 heisst "doinst.sh" und muss 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 muss 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 muss "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 Entwicklungs-
umgebung 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 Schulserver 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 Namens-
konvention "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 ver-
innerlichen. Die Skripte werden so lange beim Anmelden von sysadm aus-
geführt, bis sie sich aus "/var/adm/setup" entfernen (nach 
"/var/adm/setup/done" verschieben).


IV. Ä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 folgendermassen in die Distribution 
eingebaut:

1. Source Tree aufräumen (spart Platz und Zeit):
>	cd ~/linux
>	make clean

2. 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 muss die entsprechende 
Version der HISAX-ISDN-Treiber einbauen. In diesen unterscheiden sich 
je nach Version die Aufrufparameter, so dass man auch die Skripte der 
Systemverwaltung anpassen muss. Eine weitere Hürde stellt die Plug&Play- 
Unterstützung dar, die korrekt funktionieren muss. Ab Version 2.0 ist 
ausserdem auch das IP-Masquerading vorbereitet, obwohl ich noch keine 
Unterstützung in der Oberfläche eingebaut habe.


V. Testen einer neuen Version
=============================

Um eine neue Distribution zu testen, muss man nicht gleich eine neue 
CD brennen. Stattdessen kann man die zweite Partition auf der 
zusätzlich eingebauten Platte als ISO-Filesystem missbrauchen und 
davon installieren. Dabei wird dann die erste Platte des Entwicklungs-
systems gelöscht. Falls dann Fehler auftreten, muss 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 muss 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, muss 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 muss.

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, 
muss man es unter "/server" von Hand löschen. Gerade bei längeren 
Entwicklungszyklen lohnt sich also regelmässiges 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 gross ist 
und den gesamten c't/ODS-Schulserver als CD-Image im ISO-
9660-Format enthält. Ausserdem wird dabei die Seriennummer in 
"./serial" um eins erhöht.

Das CD-Image lässt 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 Entwicklungs-
umgebung 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, muss man dann lediglich von dieser Diskette booten, wobei 
natürlich keine Schulserver-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.


VI. CD gut, alles gut
=====================

Hat die Distribution sich bewährt, kann man sie auf CD bannen. Dazu 
muss, 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, dass "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


Abschliessend möchte ich noch auf unsere Mailing-Liste für Entwickler des 
c't/ODS-Schulserver hinweisen. Um daran teilzunehmen, senden 
Sie bitte eine E-Mail (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, 1997