Delixs - Benutzerbeiträge [de]

Benutzer:Lars

2007-03-16T00:05:31Z

Lars:

Aufgrund einer externen Bitte die Benutzerseite zu füllen, gebe ich mich hiermit zu erkennen: mein Name ist Lars Vogdt (ehem. Rupp) und wo(ran) ich arbeite, kann man am einfachsten [http://en.opensuse.org/User:Lrupp hier] erkennen.

Da mein Wille zur Mitarbeit an Arktur von Erwin Flohr als "taktische Einmischung" angesehen wird und meine Hilfsangebote seiner Meinung nach nur darauf ausgerichtet sind "Leute abzuwerben" (siehe eine entsprechende [http://www.celvina.de/arktur/schan-developer/0603/7324.html Email]), habe ich die entsprechenden [http://www.celvina.de/arktur/schan-developer/0603/7325.html Konsequenzen] gezogen und meine Mitarbeit eingestellt.

Ich bitte dies bei eventuellen Anfragen/ Rückfragen zu berücksichtigen.

FAQ:Arktur4/SUSEInstallationsserver

2006-03-23T20:25:14Z

Lars: Link korrigiert

__NOTOC__

== Arktur als SUSE-Installationsserver ==

'''Ich würde gerne mal die "Installationsserver"-Fähigkeiten von Arktur testen wollen.'''

Dazu wäre nötig:

* eine SUSE LINUX Distribution (ab 9.1 bis 10.1), welche auf Arktur ins FTP-Verzeichnis kopiert und damit freigegeben wird
* eine Boot-CD (sollte der CD1 der entsprechenden Distri entsprechen)
* eine der XML-Dateien von hier: http://www.linux-schulserver.de/download/Linux/suse/xml/ Diese sollte auch in ein Verzeichnis auf dem FTP-Server kopiert werden.

Dann die Boot-CD einlegen und unter den Optionen den Bootprompt (das
Feld unterhalb der normalen Installationsoptionen) öffnen und dort
folgende Zeile (also alles in eine! Zeile) eingeben:

<pre>
load_ramdisk=1 autoyast=ftp://arktur/<pfad_zum_xml_file>
install=ftp://arktur/<pfad_zu_den_Instalationsdateien_der_DVD_oder_CD>
</pre>

Über Rückmeldungen wäre ich sehr erfreut. Dann könnten wir ggf. über eine extra-Boot-CD (wie beim OSS) oder ein PXE-Image für die Installation über PXE nachdenken. Auch ein Betrieb von Diskless Clients über Arktur und einen separaten Terminalserver wäre dann denkbar.

-- aus einer Mail von Lars Rupp

----
<div align="right">[[FAQ|zurück]] | [[Hauptseite]]</div>

Hilfe:Angabe von Wiki- und Weblinks

2006-01-26T13:20:16Z

Lars: fix type

== Hinweis zum Namensraum ==

=== interne Links im wiki ===

Links sollten immer eine einheitliche Schreibweise haben, also

:<code>Woher:Wohin|Anzeigename</code>

Dabei ist zu beachten, daß Links '''immer''' mit einem Großbuchstaben anfangen müssen. Das heißt, sowohl das "Woher" als auch das "Wohin" müssen unbedingt groß geschrieben werden.

----

Am einfachsten ist es an einem Beispiel erklärt.

Wird aus Tools auf Klausurumgebung verwiesen, dann sollte der Link so aussehen:

<nowiki>[[Tools:Klausurumgebung|Klausurumgebung]]</nowiki>

Und das ganze sieht dann so aus:

* [[Tools:Klausurumgebung|Klausurumgebung]]

Wird dann aus der Klausurumgebung auf einen weiteren Unterpunkt verlinkt, dann:

<nowiki>[[Klausurumgebung:Automatisches Erstellen und Abspeichern|Automatisches Erstellen und Abspeichern]]</nowiki>

Und das ganze sieht dann so aus:

* [[Klausurumgebung:Automatisches Erstellen und Abspeichern|Automatisches Erstellen und Abspeichern]]

=== Externe Links (Weblinks) ===

Diese können einfach in den laufenden Text ohne jegliche Formatierung eingefügt werden.

Auch dazu ein Beispiel:

* <code><nowiki>Das ist ein Link zu http://www.heise.de/ct/schan den man anklicken kann.</nowiki></code>

Und so sieht er dann im Text aus:

* Das ist ein Link zu http://www.heise.de/ct/schan den man anklicken kann.

Entwickler-Hinweise

2005-06-09T15:49:25Z

Lars:

Hier gibt es einige Informationen über die Entwickler von Arktur und auch die entsprechenden Dokumente, um an Arktur selbst mitzuentwickeln:

* Die [http://arktur.schul-netz.de/team.php Personen], die an der Arktur-Entwicklung beteiligt sind

* Dokumentation über einzelne, wichtige [[Skripte und Dateien]]

* [[Entwickler-Dokumentation]]

----

1. Präambel

Bestimmung des Projekts c't/ODS-Schulserver (alias Arktur); Zweck und Ziel; 'Arktur-Community'

2. Allgemeine Richtlinien der Zusammenarbeit

* Einteilung und Struktur der [[Arbeitsgruppen]]
* Beschreibung der technischen Hifsmittel:
** [[SVN-Repository]]
** [[Mantis]] - ein System zur Fehlermeldung
** [[FTP-Server]]
** [[Entwickler-Mailingliste]]
** ...

Arktur:SVN-Repository

2005-06-09T15:48:21Z

Lars: Link zum Repository eingefügt

Die Entwicklung der "Arktur 3.5.x"-Versionen erfolgt mit Hilfe des Versionsverwaltungssystems "subversion" (SVN). Durch dieses System wird sowohl die gleichzeitige Arbeit mehrere Entwickler an dem Projekt, als auch die Verwaltung mehrere unterschiedlicher Versionen ermöglicht.

Das SubVersion-Repository für Arktur liegt hier:
:::'''http://fsn.by.schule.de:81/svn/arktur4/'''

Wer erst einmal ein wenig testen möchte, für den ist ein Sandkasten eingerichtet:
:::http://fsn.by.schule.de:81/svn/sandbox

== Informationen für SVN-Einsteiger ==

* http://subversion.tigris.org - Die subversion-Projektseite
* http://svnbook.red-bean.com - Die offizielle SVN-Dokumentation (englisch)
* http://tortoisesvn.tigris.org - Windows-Client für SVN
* c't Artikel "Check it out! - CVS-Nachfolger: Versionierung mit Subversion", Ausgabe 18/2004, S. 180f

== Das "Arktur 3.5" - Repository ==

* [[kurze Schritt-für-Schritt-Anleitung zur Erzeugung eines eigenen Arktur-CD-Images]]
* [[Aufbau der Entwicklungsumgebung]]
* http://fsn.by.schule.de:81/svn/arktur35 - HTTP-Link zum Repository
* http://fsn.by.schule.de/cgi-bin/viewcvs.cgi/?root=arktur35

Fehlermeldungen:Mantis

2005-06-09T15:44:28Z

Lars: Layout

Keine Software ist ohne Fehler. Und gerade ein solch komplexes System wie ein Schulserver, auf welchem Software läuft, die Millionen von Codezeilen umfasst, wird wahrscheinlich immer Fehler haben.

Um Fehler zielgerichtet und schnell beseitigen zu können und auch auf zusätzliche Wünsche von Anwendern reagieren zu können, gibt es sogenannte "Bugtracking"-Systeme wie Mantis.

Für Arktur wurde ein solches Bugtracking-System eingerichtet wo Benutzer gefundene Fehler melden können:
:::'''http://arktur.schul-netz.de/mantis/'''

== Was ist überhaupt ein Bug? ==

Grundsätzlich sind Software-Bugs sind nicht nur Fehler, sondern können auch Anforderungen oder Wünsche an eine Software sein. Wer sich detailliert über Bugs informieren möchte, den verweisen wir einmal direkt an [http://de.wikipedia.org/wiki/Programmfehler Wikipedia].

== Warum macht man BugTracking? ==

In Projekten mit mehreren Leuten ist Kommunikation sehr wichtig darüber:
* was gemacht werden soll/kann
* wer daran arbeitet (oder wofür niemand verantwortlich ist)
* wie Bugs voneinander abhängig sind
* was Andere davon halten

== Wie Mantis funktioniert ==

Mantis beinhaltet u.a. folgende Features:

* komplett Internetbasiert
* Verwaltet verschieden Projekte und Komponenten (u.a. Arktur 3.4, 3.5 und 4)
* Erfasst u.a.:
** den BugStatus (Neu, Bestätigt, Gelöst, Irrelevant, ...),
** Bug Reporter,
** Bug Verantwortlicher,
** Beobachter
* Bugs können voneinander abhängen (ein Bug kann z.B. die Lösung eines anderen blockieren)
* Jeder kann Kommentare zu Bugs eingeben / Dateien anhängen
* ein Bug hat eine Priorität ( P1 = sehr wichtig .. P5 = unwichtig)
* enthält eine Email Benachrichtigung zum Beobachten von Bugs (nach Wunsch)
* Sehr starke Suchoptionen

Eine gute Anleitung zu Mantis gibt es u.a. bei der [https://helpdesk.pdv-systeme.de/mantis/pdv_doc_de.html PDV-SYSTEME Gesellschaft für Systemtechnik mbH]

Fehlermeldungen:Mantis

2005-06-09T15:34:35Z

Lars:

Keine Software ist ohne Fehler. Und gerade ein solch komplexes System wie ein Schulserver, auf welchem Software läuft, die Millionen von Codezeilen umfasst, wird wahrscheinlich immer Fehler haben.

Um Fehler zielgerichtet und schnell beseitigen zu können und auch auf zusätzliche Wünsche von Anwendern reagieren zu können, gibt es sogenannte "Bugtracking"-Systeme wie Mantis.

Für Arktur wurde ein solches Bugtracking-System eingerichtet wo Benutzer gefundene Fehler melden können:
http://arktur.schul-netz.de/mantis/

== Was ist überhaupt ein Bug? ==

Grundsätzlich sind Software-Bugs sind nicht nur Fehler, sondern können auch Anforderungen oder Wünsche an eine Software sein. Wer sich detailliert über Bugs informieren möchte, den verweisen wir einmal direkt an [http://de.wikipedia.org/wiki/Programmfehler Wikipedia].

== Warum macht man BugTracking? ==

In Projekten mit mehreren Leuten ist Kommunikation sehr wichtig darüber:
* was gemacht werden soll/kann
* wer daran arbeitet (oder wofür niemand verantwortlich ist)
* wie Bugs voneinander abhängig sind
* was Andere davon halten

== Wie Mantis funktioniert ==

Mantis beinhaltet u.a. folgende Features:

* komplett Internetbasiert
* Verwaltet verschieden Projekte und Komponenten (u.a. Arktur 3.4, 3.5 und 4)
* Erfasst u.a.:
** den BugStatus (Neu, Bestätigt, Gelöst, Irrelevant, ...),
** Bug Reporter,
** Bug Verantwortlicher,
** Beobachter
* Bugs können voneinander abhängen (ein Bug kann z.B. die Lösung eines anderen blockieren)
* Jeder kann Kommentare zu Bugs eingeben / Dateien anhängen
* ein Bug hat eine Priorität ( P1 = sehr wichtig .. P5 = unwichtig)
* enthält eine Email Benachrichtigung zum Beobachten von Bugs (nach Wunsch)
* Sehr starke Suchoptionen

Eine gute Anleitung zu Mantis gibt es u.a. bei der [https://helpdesk.pdv-systeme.de/mantis/pdv_doc_de.html PDV-SYSTEME Gesellschaft für Systemtechnik mbH]

Entwickler-Hinweise

2005-06-09T15:20:32Z

Lars:

Hier gibt es einige Informationen über die Entwickler von Arktur und auch die entsprechenden Dokumente, um an Arktur selbst mitzuentwickeln:

* Die [[Personen]], die an der Arktur-Entwicklung beteiligt sind

* Dokumentation über einzelne, wichtige [[Skripte und Dateien]]

* [[Entwickler-Dokumentation]]

----

1. Präambel

Bestimmung des Projekts c't/ODS-Schulserver (alias Arktur); Zweck und Ziel; 'Arktur-Community'

2. Allgemeine Richtlinien der Zusammenarbeit

* Einteilung und Struktur der [[Arbeitsgruppen]]
* Beschreibung der technischen Hifsmittel:
** [[SVN-Repository]]
** [[Mantis]] - ein System zur Fehlermeldung
** [[FTP-Server]]
** [[Entwickler-Mailingliste]]
** ...

Arktur:Entwickler-Mailingliste

2005-06-09T15:19:31Z

Lars:

Die [http://arktur.schul-netz.de/cgi-bin/mailman/listinfo/arktur4 Entwickler-Mailingliste] wurde eingerichtet, damit sich die unterschiedlichen Entwickler von Arktur besser und schneller koordinieren können.

Das [http://wvbg.bndlg.de/pipermail/arktur4/ Archiv der Liste] ist zwar öffentlich - aber eine Anmeldung in der Liste selbst muss erst genehmigt werden. Dazu ein Ausschnitt aus einer Email:

== Philosophie und Konfiguration dieser Liste ==

Ziel war und ist, mit dieser Liste mehrere Beiträge dafür zu leisten, dass die Nutzer von Arktur wieder Vertrauen in die Entwickler und die Entwicklung von Arktur haben können.

1. Problem: Versions-Chaos

Version 3.5 ist fertig, alle Entwickler dieser Version haben erklärt, an der Version 4 mitzuarbeiten. Damit entspricht m.E. die Version 3.5 dem "stable"-Zweig und die Version 4.0 der developer-Version. Da nun alle Entwickler mehr oder weniger an der gleichen Version arbeiten, aber auf jedem Fall im gleichen Team sind, sollte diese Linie deutlich werden.

2. Problem: Streitereien in schan-dev und inzwischen auch schan-user

Da es eine geschlossene und private Liste ist, mit klar definierten Verhaltenskodex, den jeder mit der Anmeldung akzeptiert hat, dürften diese Probleme hier nicht auftreten oder können im Keim erstickt werden.

Da der Gedankenaustausch hier in dieser Liste erfolgt, sollte schon wegen der geringeren Präsenz in schan-dev weniger Reibungspotential vorhanden sein. Außerdem besteht die Chance, das Informationen aus dieser Liste nach
schan-dev bzw. schan-user deutlich ausgereiftere Lösungen oder durchdachtere Konzepte darstellen und somit auch weniger Angriffsfläche für Pauschalurteile und oberflächliche Kritiken bieten.

3. Problem: Verunsicherung der Anwender durch andere Entwickler

Die Entwicklung von vorgestellten Lösungen sollte für den Anwender nachvollziehbar sein. Dazu wird m.E. ein wichtiger Beitrag durch das öffentliche Listenarchiv geleistet. Ebenso, wenn die Informationen aus dieser Liste nach schan-user (möglichst regelmäßig) in hoher Qualität und seriöser Form bereitgestellt werden. Auf sachliche Hinweise und Kritik sollte reagiert, alles andere ausnahmslos ignoriert werden.

4. Problem: Arktur 4 wird nicht fertig = unendliche Geschichte

Es wurde mehrfach zum Ausdruck gebracht, das ein Feature-Freeze nicht nur ausgerufen, sondern unbedingt einhalten werden sollte. (Als eine positive Erfahrung der Version 3.5 bietet sich m.E. der gezielte Einsatz von Mantis an. Dabei würden nebenbei noch zu lösende Aufgaben aufgelistet und es würde die Übernahme von Aufgaben durch andere Entwickler transparent.)

5. Problem: nur Reiner kennt sich mit dieser Version aus und kann helfen

Schon durch diese Liste, das gemeinsame Ziel (eben Arktur 4), die Arbeit in der Liste und nicht mehr per PM (Transparenz), und durch "gemeinsames" Erstellen der Doku sollte deutlich werden, dass die Weiterentwicklung
durch eine größere Zahl von Entwicklern gewährleistet ist. Dieser Punkt bedeutet für mich, dass die Teilnehmerliste ebenso wie das Archiv offen zugänglich sein sollte.

6. Problem: Arbeitsweise wird durch andere aufgezwungen

Außer den unter Punkt 2 und 3 genannten Problemen wurde die eigentliche Funktion einer Liste zum Gedankenaustausch und der Koordination nicht mehr gerecht. Deshalb geschah vieles per PM, auch der Aufbau dieser Liste.

Mit der Einrichtung dieser Liste wurde m.E. der erste Schritt getan, das Ruder selbst in die Hand zu nehmen. Und es sind die Voraussetzungen vorhanden, das Ruder nicht mehr aus der Hand zu geben. Dieses Selbstvertrauen wird von den Entwicklern erwartet und sollte auch gezeigt werden. Das bedeutet neben der schon erwähnten offenen Teilnehmerliste und dem offenen Archiv sollte m.E. auch auf dem Portal diese Liste präsent sein (ohne gleich aufdringlich und dominierend zu werden).

7. Problem: die Angst von Entwicklern vor weiteren Störungen

Ich wurde in mehreren Antworten auf die Gefahr eines gerichtlichen Vorgehens zum Erzwingen der Teilnahme an dieser Liste gewarnt, was sicher keiner will. Der Hinweis auf eine private Liste war für mich überzeugend. Um dieser konkreten Gefahr auch eine schlüssige Argumentation entgegen setzen zu können, habe ich ganz bewußt die Zustimmung zu diesen Verhaltenskodex vollständig und ohne jegliche Änderung als eine Bedingung für diese Liste gemacht. Da es eine private Liste ist, ist es die Liste zur Unterstützung von Arktur 4 (und 3.5) und in diese _private_ Liste
kommt nur, wer von Reiner, Thomas oder jemanden, der durch diese beiden beauftragt wurde, eingeladen ist.

Da mit dem Erstellen dieser Liste sich Reinhold und ich sich sehr weit aus dem Fenster gelehnt (und auch schon zu spüren bekommen) haben, ist mein Vorschlag, dass Reiner, Thomas, Reinhold und ich die Aufnahme, im hoffentlich nie eintretenden Fall aber auch den Ausschluss aus dieser Liste, übernehmen.

So die Philosophie zum Erstellen dieser Liste und entsprechend wurde diese vorerst konfiguriert. Diese Konfiguration ebenso wie die Philosophie steht hiermit zur Diskussion.

Ich stehe aber auch auf dem Standpunkt, dass wir diese Liste nicht zum Selbstzweck geschaffen haben. Das bedeutet, dass die Diskussion über diese Liste zügig über die Runden gebracht wird. Das läßt sich m.E. auf zweierlei Weise beschleunigen: da es als private Liste zur Unterstützung der Arbeit von Reiner und Thomas deklariert ist, sollten ihre Entscheidung respektiert werden (= Machtwort). Die zweite Möglichkeit sehe ich darin, dass man sich per PM darüber verständigt. Sollten sich neue Überzeugungen oder Sichtweisen ergeben, werden diese in der Liste dargestellt. Ich habe selbstverständlich auch nichts gegen die Diskussion darüber in der Liste.

Mir geht es nur darum, dass wir uns in dieser Liste nicht ewig mit der Liste selbst beschäftigen, sondern diese Liste zur eigentlichen Arbeit an Arktur 4 und 3.5 genutzt werden kann.

Ein technischer Hinweis: wenn man mit einem Zeichensatz anders als ISO-8859-1 schreibt, wird die Signatur als Anhang mitverschickt. Das ist nicht ganz optimal, lässt sich aber nicht anders lösen, außer man verzichtet ganz auf die Signatur.

Das Webinterface für die Liste einschließlich Archiv und Teilnehmerliste erreicht man über

http://arktur.schul-netz.de/cgi-bin/mailman/listinfo/arktur4

Sollten alle mit dieser Lösung leben können, wäre das von meiner Seite alles in Hinblick auf die Liste gewesen. Ansonsten bitte ich Probleme in die Liste zu posten oder per PM an mich heranzutragen.

Entwickler-Hinweise

2005-06-09T15:11:02Z

Lars:

Entwickler-Hinweise

2005-06-09T14:56:38Z

Lars:

Hier gibt es einige Informationen über die Entwickler von Arktur und auch die entsprechenden Dokumente, um an Arktur selbst mitzuentwickeln:

* Die [[Personen]], die an der Arktur-Entwicklung beteiligt sind

* Dokumentation über einzelne, wichtige [[Skripte und Dateien]]

* [[Entwickler-Dokumentation]]

----

1. Präambel

Bestimmung des Projekts c't/ODS-Schulserver (alias Arktur); Zweck und Ziel; 'Arktur-Community'

2. Allgemeine Richtlinien der Zusammenarbeit

* Einteilung in Arbeitsgruppen
* Struktur der Arbeitsgruppen
* Verhältnis der Entwickler zu den Maintainern, zum Gesamtprojektprojekt-Maintainer
* Beschreibung der technischen Hifsmittel:
* deren Nutzung; z.B. ein CVS;
* Umfang dessen, was dort niedergelegt und bearbeitet wird p.p

Delixs:Entwickler-Dokumentation

2005-06-09T14:49:30Z

Lars:

Derzeit ist diese Seite eine Kopie der Entwickler-Dokumentation von des [http://www.eisfair.de Eisfair]-Projektes. Nach einigen Diskussionen dürfte hier aber bald die "Arktur-Dokumentation für Entwickler" stehen.

== Grundlagen ==

Arktur 4 basiert auf einer glibc mit der Versionsnummer 2.3; diese wird von allen modernen Distributionen unterstützt. Daher können die meisten Binaries direkt kopiert und auf Arktur ausgeführt werden.

Falls jemand genauere Informationen zu den betroffenen Distributionen hat, soll er sich bitte melden. Binärdateien von SUSE 9.0 sind ohne Probleme zu benutzen.

=== Der Umfang der Arktur-Basis-Pakete ===

Das Base-Package ist recht reichhaltig mit Tools ausgestattet (viel mehr als während der Beta-Versionen); im Normalfall sollte man mit den Programmen, die darin enthalten sind, gut auskommen. Falls allerdings bestimmte Programme von vielen Package-Entwicklern genutzt werden, die nicht im Base-Package enthalten sind, kann über eine Integration in das Base-Package nachgedacht werden. Es sollte auf jeden Fall vermieden werden, dass bestimmte Packages dasselbe Programm enthalten.

== Erstellung eines Installationspackages ==

Ein Installationspaket für Arktur ist im wesentlichen ein mit gzip komprimiertes Tar-Archiv, in dem neben den eigentlichen Dateien des Paketes noch einige weitere Informationen/ Scripts enthalten sein müssen. Diese sind:

{| border=1
!Bestandteile
!Status
|-
| Paket-Info-Datei
| zwingend
|-
|Installationsscripts
|optional
|-
|Menüs für Setup
|optional
|}

Das Paket selbst spiegelt den Dateibaum ab dem root-Verzeichnis, also ``/'' wieder. Eine zu installierende Datei /usr/bin/foo muss also im Tar-Archiv als usr/bin/foo (ohne absoluten Pfad, also relativ!) abgespeichert sein. Als Beispiel denken wir uns ein Paket ``bar'', welches als Dienst unter eisfair laufen soll. Der dazughörige Daemon soll ``bard'' heissen. Ausserdem soll noch eine Konfigurationsdatei etc/bard.conf und eine Shared-Library usr/lib/foo.so.1 dazugehören.

Dokumentation zu diesem Package können wir im Verzeichnis /usr/share/doc/bar ablegen. Dort legen wir die selbstgeschriebene Hilfedatei ``bar.txt'' ab.

Damit dieser Dienst gestartet wird, braucht man noch eine rc-Datei, welche unter /etc/init.d/bard gespeichert werden soll. Dann sieht der ``Baum'' im Archiv folgendermaßen aus:

etc/bard.conf Konfiguration
etc/init.d/bard rc-Datei
usr/sbin/bard Executable als Daemon
usr/lib/foo.so.1 Shared Library

Nun zu den zusätzlichen Dateien, welche die Installation/ Administration des Pakete regeln.

=== Paket-Info-Datei ===

dev-info-naming Diese Datei ist zwingend, d.h. sie sollte immer im tar-Archiv enthalten sein. Sie muss in var/install/packages liegen und den Namen des Packages haben. Als Package-Name sollten nur die Kleinbuchstaben a-z, die Zahlen 0-9 und der Bindestrich verwendet werden. Eine Versionsnummer sollte nicht mit im Paketnamen enthalten sein, damit man nicht bei Updates plötzlich mehrere verschiedene Packages auf seinem Arktur sieht. Beispiel für Package ``bar'': var/install/packages/bar - Dateiname entspricht Paketname!

Der Aufbau dieser Paket-Info-Datei entspricht vollständig dem Format der Info-Datei, die auch für die Paketbeschreibungen zuständig sind.

=== Installationsscripts ===

Man kann zwei Installationsskripte im Tar-Archiv unterbringen, nämlich

tmp/preinstall.sh Script vor dem Auspacken
tmp/install.sh Script nach dem Auspacken

Diese Scripts sind optional, sie müssen also nicht zwingend vorhanden sein. PACKAGE ist der Paketname, z.B. apache. Das Archiv wird beim Herunterladen im Verzeichnis /tmp gespeichert. Anschließend wird versucht, die Datei tmp/preinstall.sh zu extrahieren. Wenn sie existiert, wird sie anschließend ausgeführt. Der Zweck ist einfach: Hier können vorbereitende Kommandos ausgeführt werden (z.B. Löschen einer alten Version). Anschließend wird das komplette tar-Archiv ausgepackt, und zwar immer vom Root-Verzeichnis ``/'' ausgehend, so daß alle Dateien im richtigen Verzeichnis landen. Als letztes wird versucht, die Datei /tmp/install.sh auszuführen, falls sie existiert. Diese kann beim Aktivieren von Services (z.B. unseres bard-Programmes) genutzt werden, hier ein Beispiel:

#!/bin/sh
cd /etc/rc2.d \# in's rc-Verzeichnis, Runlevel 2
ln -sf ../init.d/bard S50bard \# Boot-Script linken
ln -sf ../init.d/bard K50bard \# Kill-Script linken

# Menüs für eis-Administration erweitern, s.u.:

/var/install/bin/add-menu \
/var/install/menu/setup.services.menu \
/var/install/bin/setup.services.bard \
``Foo Services''
exit 0

=== Deinstallation ===
/var/install/deinstall/<PACKAGE> Das Script muss zwingend vorhanden sein. Seine Aufgabe besteht in der Entfernung aller Paketdateien und der entsprechenden Menüeinträge. Dazu zählen auch:
* Chronjobs
* Systembenutzer
* Benutzergruppen
Sonstige eingefügte Einträge in paketfremden Dateien.
Bei der Entfernung von Bibliotheken ist gegebenenfalls eine Abhängigkeitsprüfung zu anderen Paketen durzuführen.

=== Dokumentation und Changelog ===

Im Verzeichnis /usr/share/doc/<PACKAGE> ist eine Datei changes.txt anzulegen, in dem die Veränderungen, die von Version zu Version am Paket durchgeführt werden, kurz beschrieben werden.

Bewährt hat sich eine Form wie in folgendem Beispiel:

1.0.6 --> 1.0.7
---------------
- added file /bin/bigone
- deleted obsolete variable ONE in
/etc/config.d/master
- renamed /etc/old to /etc/new
-
-

1.0.5 --> 1.0.6
---------------
- modified some comments in /etc/this
-
-

Es sollten also die letzten Änderungen jeweils oben in der Datei changes.txt stehen. Uralte Änderungen können mit der Zeit entfallen.

Die eigentliche Dokumentation soll ebenfalls im Verzeichnis /usr/share/doc/<PACKAGE> abgelegt werden, ebenfalls im Textformat und PACKAGE.txt heissen. Weiteres siehe Dokumentation. Zusätzliche Dokumentation, die den Originalquellen normalerweise beiliegt (man-Pages, README, etc.), sollte nicht mitgeliefert werden.

=== Menüs für SysAdm ===

Auch die Menüs sind optional und werden nur für eine spätere Administration benötigt. Das SysAdmin-Menü basiert auf einfachen Shell-Scripts und ist als Übergangslösung gedacht, bis eine komfortable Oberfläche (über Browser bedienbar) zur Verfügung steht. Unter /var/install befinden sich auf dem eisfair-Server folgende Unterverzeichnisse:

{|
|bin
|Shell-Scripts
|-
|menu
|Menü-Dateien
|-
|packages
|Paket-Info-Dateien, s.o.
|}

Die Menü-Dateien haben folgende Struktur:

{|
!TITEL
|
|-
|Kommando
|Beschreibung
|-
|Kommando
|Beschreibung
|}

Hier ein Beispiel des Hauptmenüs setup.menu:

EIS/FAIR simple setup
/var/install/bin/setup.packages Package administration
/var/install/bin/setup.services Service administration
/var/install/bin/setup.users User administration

Die Menüs sind hierarchisch. Die Struktur wird durch den Dateinamen klar:

setup.menu Hauptmenü
setup.packages.menu Untermenü Packages
setup.services.menu Untermenü Services
setup.users.menu Untermenü Users

Diese Strukturen kann man beliebig tief führen und auch an gewünschter Stelle erweitern. Der Befehl

/var/install/bin/add-menu \
/var/install/menu/setup.services.menu \
/var/install/bin/setup.services.bard \
``Foo Services''

im Installationsskript erweitert nun das Menü setup.services.menu um eine weitere Zeile, nämlich:

/var/install/bin/setup.services.bard ``Foo Services''

Es erscheint also dann unter ``Service administration'' ein weiterer Menüpunkt ``Foo Services''. Das Shell-Script /var/install/bin/setup.services.bard ist einfach ein weiterer Start eines Untermenüs. Es kann z.B. so aussehen:

#! /bin/sh
/var/install/bin/show-menu \
/var/install/menu/setup.services.bard.menu

Und setup.services.bard.menu folgendermaßen:

Foo administration
/var/install/bin/bard-status Show status of inetd
/var/install/bin/bard-stop Stop inetd
/var/install/bin/bard-start Start inetd

Die 3 Scripts bard-status usw. starten nun keine weiteren Untermenüs, sondern führen dann tatsächlich Funktionen aus. Sie können z.B. so aussehen:

------------------ schnipp -------------------------
#! /bin/sh
# bard-status
pid=`cat /var/run/bard.pid 2>/dev/null`

status=dead

if [ ``$pid'' != ``'' ]
then
kill -0 \$pid
if [ \$? = 0 ]
then
status=alive
fi
fi

if [ $status = alive ]
then
echo ``bard is running''
else
echo ``bard is not running''
fi
echo
/var/install/bin/anykey
------------------ schnapp -------------------------
------------------ schnipp -------------------------
#! /bin/sh
# bard-start
sh /etc/init.d/bard start
echo
/var/install/bin/anykey
------------------ schnapp -------------------------
------------------ schnipp -------------------------
#! /bin/sh
# bard-stop
sh /etc/init.d/bard stop
echo
/var/install/bin/anykey
------------------ schnapp -------------------------

Das Shell-Script /var/install/bin/anykey fragt den Benutzer lediglich nach der ENTER-Taste als Bestätigung.

Zusammenfassend noch mal alle Dateien in unserem bard-Package:

Dateiname Funktion
etc/bard.conf Konfiguration
etc/init.d/bard rc-Datei
usr/sbin/bard Executable als Daemon
usr/lib/foo.so.1 Shared Library
var/install/bin/setup.services.bar Knoten im Menü-Baum
var/install/bin/bard-status Blatt im Menü-Baum
var/install/bin/bard-stop Blatt im Menü-Baum
var/install/bin/bard-start Blatt im Menü-Baum
var/install/menu/setup.services.bar.menu Menü-Datei
var/install/packages/bar Package-Info-Datei
usr/share/doc/bar/bar.txt Dokumentation zum Pacakge
usr/share/doc/bar/changes.txt Changelog-Datei

== Standardskripte ==

In der aktuellen Version von Arktur sind folgende Skripte verfügbar, die man benutzen sollte, um Standardfunktionen anzubieten.

/var/install/bin/anykey wartet auf ENTER
/var/install/bin/add-group fügt eine neue Gruppe zum System hinzu
/var/install/bin/add-menu erstellt einen Menüeintrag für das Setup
/var/install/bin/add-user fügt einen neuen Benutzer zum System hinzu
/var/install/bin/ask wartet auf Eingabe von y(es) oder n(o)
/var/install/bin/check-version überprüft ein Paket auf seine Version
/var/install/bin/del-menu entfernt einen Menüeintrag aus dem Setup
/var/install/bin/edit startet den Editor zum Editieren der Konfiguration
/var/install/bin/remove-user entfernt einen Benutzer vom System

Damit wird vermieden, dass diese Sachen von jedem Paketentwickler neu implementiert werden müssen. Welche Parameter das Skript jeweils erwartet, ist im Skript selbst am Anfang beschrieben.

== Konfiguration von Paketen ==

Die Konfiguration von Paketen kann in der Datei /etc/config.d/PACKAGE festgehalten werden. Die einzelnen Zeilen sollten folgender Notation entsprechen: VARIABLE='Wert'

Kommentare können mit `#' eingeleitet werden. Beispiel für /etc/config.d/inet (Package ``inet'')

#---------------------------------------------------
# Configuration of inet package
#---------------------------------------------------

START_TELNETD='no'
START_FTPD='yes'
START_SSH='yes'

Beispiel für /etc/config.d/apache (Package ``apache'')

#---------------------------------------------------
# Configuration of apache package
#---------------------------------------------------

START_APACHE='yes'
DOCUMENT_ROOT='/var/www'

Beispiel für /etc/config.d/mail (Package ``mail'', auszugsweise)

#---------------------------------------------------
# Configuration of mail package
#---------------------------------------------------

START_POP3='yes'
START_IMAP='yes'

POP3IMAP_CREATE_MBX='no'

POP3IMAP_USE_MAILONLY_PASSWORDS='no'
POP3IMAP_TRANSPORT='default'

== INFO-Datei ==

Diese Datei soll eine bessere Übersicht über die verfügbaren Pakete und notwendige Verwaltungsdaten bereitstellen.

Hinweis: Die bisherige Info-Datei, die im Package selbst enthalten ist, bleibt erhalten. An ihrem Format ändert sich nichts.

Damit ein späterer Umstieg auf einen XML-Parser möglich ist, bitte die Sonderzeichen, die XML eine Sonderbedeutung haben, entsprechend maskieren oder vermeiden.

=== Namen und Pfad ===

Der Info-Datei erhält den Dateinamen des Packages zuzüglich ,,.info``. Sie steht im selben Verzeichnis wie das zugehörige Package.

Beispiel: Wenn der Pfad zum Package ,,slrn.tar.gz`` ,,http://www.meine-domain.de/eisfair/``lautet (also die Adresse das Paketes ,,http://www.meine-domain.de/eisfair/slrn.tar.gz``ist), dann heisst die zugehörige Info-Datei ,,slrn.tar.gz.info``; deren Adresse lautet somit ,,http://www.meine-domain.de/eisfair/slrn.tar.gz.info``.

=== Format ===

Die Info-Datei hat eine XML-Struktur, die folgendermassen aussieht:

<package>
...
</package>

Innerhalb des Package-Tags sind die unten beschriebenen Tags erlaubt. Die Werte sind, soweit nicht anders gekennzeichnet, Freitext. Werte, die nicht Freitext sind, sind case-sensitiv (auf Groß- und Kleinschreibung achten!). Freitexte dürfen folgende Zeichen nicht enthalten: ``<'', ``>'',''$''.

Jedes Tag (bis auf <description>) muss mit Starttag, Wert und Endtag in genau einer Zeile stehen.

<name>
: Der Name des Packages
<short>
: Eine Kurzbeschreibung (max 60 Zeichen)
<version>
: Die Version des Packages; Kein Freitext (siehe unten)
<date>
: Das Releasedatum dieser Version
<author>
: Der Name des Authors, inklusive EMail-Adresse
<status>
: Der Status des Packages (siehe unten); Kein Freitext
<section>
: Der Bereich, dem dieses Package angehört (siehe unten); Kein Freitext URL zur Homepage
<require-package>
: Der Name eines Packages, das zur korrekten Funktion dieses Packages zwingend vorausgesetzt wird
<sub-package>
: ...
<description>
: Eine ausführlichere Beschreibung des Programmes, Hinweise, Tips, Patches ...

Die Reihenfolge der Tags ist beliebig. Die Tagnamen müssen in Kleinbuchstaben gesetzt sein. Im folgenden weitere Beschreibungen der Tags.

version

Dieser Wert muss folgendem Schema entsprechen: X.Y.Z, wobei

X Hauptversion
Y Unterversion
Z Patchlevel

<status>

Dieser Wert besteht aus einem der folgenden Möglichkeiten:

unstable
Das Paket wurde noch nicht getestet. Eine Installation ist nur Experten zu empfehlen, da dieses Paket noch erhebliche Fehler und Ungereimtheiten enthalten kann. Jedes Paket erhält zu Beginn diesen Status.

testing
Dieses Paket wurde schon getestet und die gröbsten Fehler wurden beseitigt. Es können allerdings noch Fehler auftreten, allerdings läuft es im Standardbetrieb stabil. Ein Package erhält erst diesen Status, wenn mindestens 5 Benutzer dieses Package installiert haben und alle gemeldeten Fehler vom Autor beseitigt wurden.

stable
Dieses Paket ist ausreichend getestet, daß es auch in vielen Kombinationen mit anderen Programmen und Treibern wie erwartet arbeitet. Dokumentation ist vorhanden. Ein Paket erhält erst diesen Status, wenn es vorher den Status ``testing'' besaß und ein allgemeiner Konsens (in der Developer-Mailingliste o.ä.) darüber besteht.

<section>

Dieser Wert ordnet das Package in eine bestimmte Kategorie ein. Darüber lässt sich eine Menüauswahl o.ä. realisieren. Es existieren folgende Möglichkeiten für diesen Wert:

* admin - admin-tools zum installieren und konfigurieren
* utils - sed, grep, links und co - alles was auf der console hilft
* devel - gcc und co
* game - spieleproxies etc
* interpreter - perl, ruby, python und co.
* lib - zlib, openssl und co
* net - alles rund ums netzwerk
* news - alles rund um news
* mail - alles rund um mail
* misc - alles andere
* web - alles rund ums web
* database - Datenbanken und Frontends
* drivers - Treiber, Kernel-Module

(danke an Oliver Dawid)

<require-package>

Diese Wert definiert eine Abgängigkeit zwischen dem beschriebenen Package und einem anderen Package. Dieses Package wird durch seinen Dateinamen (inklusive relativem Pfad zum aktuellen Package oder absoluter URL) angegeben. Sollte eine bestimmte Mindestversion gefordert werden, so kann diese optional durch ein Leerzeichen getrennt hinter dem Dateinamen angegeben werden.

Ist das beschriebene Package von mehrere Packages abhängig, so kann das <require-package>-Tag mehrfach vorkommen. Gibt es keine Abhängigkeiten, so kann es entfallen.

Die (immer vorhandene) Abhängigkeit zum Package ''base'' muss nicht explizit genannt werden, es sein denn, eine bestimmte Version wird vorausgesetzt.

Beispiele:

<require-package>inet.tar.gz.info</require-package>
<require-package>../updates/update.tar.gz.info 1.0.5</require-package>
<require-package>http://download.eisfair.org/packages/updates/update.tar.gz.info 1.0.5</require-package>

<sub-package>

Das Tag <sub-package> gibt an, welche Unterpakete vom Hauptpaket selbständig geladen werden. Diese Angaben dienen lediglich der Information, z.B. für eisfair-Download-Mirror-Systeme.

Syntax:

<sub-package>LOCATION</sub-package>

Die Form von LOCATION entspricht derselben wie für <require-package>.

Update eines Packages

Wenn ein Package upgedatet wird, sind folgende Punkte zu beachten:

* updaten des <version>-tags
* eventuell Rückstufung des <status>-Tags

Beispiel

Anbei ein kleines Beispiel, daß obige Definitionen illustrieren soll.

<package>
<name>inet</name>
<short>Inet services (pure-ftpd \& ssh, inetd, telnet)</short>
<version>0.10.4</version>
<date>2002/01/02</date>
<author>Joerg Hoh, joerg@joerghoh.de</author>
<status>stable</status>
<section>net</section>
<require-package>base tools</require-package>
<description>
Dieses Package beinhaltet einen Grundstock an Internet-Diensten:

-pureftpd: FTP-Server (pure-ftpd.sourceforge.net, Version 1.0.2)
-sshd: SSH-Server, inklusive Generator für eigenen SSH-Keys,
SSH-Client
(www.openssh.org, Version 3.0.2p1)
-inetd: Wird von vielen anderen Diensten benötigt
-telnet: Dienst zur Fernadministration; SICHERHEITSRISIKO!!
Für weitere Informationen:
http://www.joerghoh.de/eisfair/doc/inet.html
</description>
</package>

== Dokumentation ==

Zu jedem Paket sollte es Dokumentation geben, in der zumindest folgende Punkte genauer erklärt werden:

* Welche weiteren Pakete werden benötigt?
* Der Installationsablauf
* Eventuelle Konfigurationsdateien und die in ihr definierten Variablen
* Die Punkte im Setup-Programm, soweit sie dieses Paket betreffen
* Die Funktionen des Pakets
* Wie arbeitet dieses Paket mit anderen Pakete zusammen?

Die Texte, die in dieser Dokumentation enthalten sind, wurden mithilfe von LATEXverfasst. Daraus lassen sich sehr einfach andere Formate (wie PDF und das geforderte Textformat für die Dokumentation unter /usr/share/doc) erzeugen.

Wer ebenfalls LATEXbenutzen will, der kann sich von Jörg Hoh (joerg@eisfair.org) das dazu notwendige Style-File besorgen.

== Gruppen- und User-IDs ==

Um weiteres Chaos zu vermeiden, wurde jetzt eine Liste von uids und gids festgelegt, an die sich alle weiteren Packages halten sollte. Die Liste wurde aus den Einträgen von Debian Woody und SuSE gemischt, wobei im Zweifelsfall Debian das letzte Wort hatte.

Username uid gid
root 0 0
daemon 1 1
bin 2 2
sys 3 3
lp 4 7
games 5 5
man 6 100
mail 8 8
news 9 9
uucp 10 10
proxy 13 13
at 25 -
postgres 26 26
majordom 30 31
postgres 31 32
wwwrun 30 33
backup 34 34
operator 37 37
list 38 38
irc 39 39
ftp 40 49
gnats 41 41
exim 42 42
named 44 44
postfix 51 51
mysql 60 2
zope 64 2
sshd 71 65
firebird 84 84
nobody 65534 65534
identd 100 65534

Gruppenname gid
root 0
daemon 1
bin 2
sys 3
adm 4
tty 5
cdisk 6
lp 7
mail 8
news 9
uucp 10
proxy 13
kmem 15
dialout 20
fax 21
voice 22
cdrom 24
floppy 25
tape 26
sudo 27
audio 29
dip 30
majordom 31
postgres 32
www-data 33
backup 34
operator 37
list 38
irc 39
src 40
gnats 41
trusted 42
utmp 43
video 44
ftp 49
staff 50
postfix 51
maildrop 59
games 60
man 62
sshd 65
users 100
maschines 777
nobody 65533
nogroup 65534

Wer meint, daß in dieser Liste ein Eintrag fehlt, der solle sich melden.

== Definition regulärer Ausdrücke ==

Reguläre Ausdrücke sind wie folgt definiert:

Regulärer Ausdruck: Eine oder mehrere Alternativen, getrennt durch '|', z.B. 'ro|rw|no'. Trifft eine der Alternativen zu, trifft der ganze Ausdruck zu (hier wären 'ro', 'rw' und 'no' gültige Ausdrücke).

Eine Alternative ist eine Verkettung mehrerer Teilstücke, die einfach aneinandergereiht werden.

Ein Teilstück ist ein ``Atom'', gefolgt von einem einzelnen '*', '+', '?' oder '{min, max}'. Die Bedeutung ist wie folgt:

* 'a*' - beliebig viele a's einschließlich kein a
* 'a+' - mindestens ein a, sonst beliebig viele a's
* 'a?' - kein oder ein a
* 'a{2,5} - zwei bis 5 a's
* 'a{5} - 5 a's
* 'a{2,} - mindestens 2 a's

Ein ``Atom'' ist ein

* regulärer Ausdruck eingeschlossen in Klammern, z.B. (a|b)+ trifft auf eine beliebige Zeichenkette zu, die mindestens ein a oder b enthält, sonst aber beliebig viele und in beliebiger Reihenfolge
* ein leeres Paar Klammern steht für einen ``leeren'' Ausdruck
* ein Ausdruck mit eckigen Klammern '[]' (siehe weiter unten)
* ein Punkt '.', der auf irgend ein einzelnes Zeichen zutrifft, z.B. '.+' trifft auf eine beliebige Zeichenkette zu, die mindestens ein Zeichen enthält
* ein '^' steht für den Zeilenanfang, z.B. '^a.*' trifft auf eine Zeichenkette zu, die mit einem a anfängt und in der beliebige Zeichen folgen, 'a' oder 'adkadhashdkash'
* ein '$' steht für das Zeilenende
* ein '
' gefolgt von einem der Sonderzeichen '^.[$()|*+?{'` steht für genau das zweite Zeichen ohne seine spezielle Bedeutung
* ein normales Zeichen trifft auf genau das Zeichen zu, z.B. 'a' trifft auf genau 'a' zu.

Ein Ausdruck mit rechteckigen Klammern bedeutet folgendes

* '[x-y]' - trifft auf irgend ein Zeichen zu, das zwischen x und y liegt, z.B. '[0-9]' steht für alle Zeichen zwischen 0 und 9; '[a-zA-Z]' für alle Buchstaben, egal ob groß oder klein

* '[^x-y]' - trifft auf irgendein Zeichen zu, das nicht im angegebenen Intervall liegt

* '[:character_class:] - trifft auf ein Zeichen der Zeichen-Klasse zu. Relevante Standardzeichenklassen sind: alnum, alpha, blank, digit, lower, print, punct, space, upper, xdigit.

Beispiele für Reguläre Ausdrücke

Sehen wir uns das mal an einigen Beispielen an:

Numerisch: Ein numerischer Wert besteht aus mindestens einer, aber beliebig vielen Zahlen. Mindestens ein, aber beliebig viele drückt man mit '+' aus, eine Zahl hatten wir schon als Beispiel. Zusammengesetzt ergibt das:

NUMERIC = '[0-9]+' oder alternativ
NUMERIC = '[[:digit:]]+'

NOBLANK: Ein Wert, der keine Leerzeichen enthält ist ein beliebiges Zeichen (außer dem Leerzeichen) und davon beliebig viele:

NOBLANK = '[^ ]*'

bzw. wenn der Wert zusätzlich auch nicht leer sein soll:

NOBLANK = '[^ ]+'

Disk und Partition: Gültige Bezeichner für eine Disk beginnen mit hd bei IDE-Disks bzw sd bei SCSI-Disks. Dann folgen Buchstaben von a-z (a für die erste Disk, b für die 2., ...) und bei Partitionen die Zahlen 1-8 (1-4 für die ersten 4 Partitionen, die Primär bzw. Extended (nur eine) sein können und 5-8 für die logischen Partitionen innerhalb einer extended Partition). Die Ausdrücke sehen dann wie folgt aus:

DISK = '(hd|sd)[a-z]'
PARTITION = '(hd|sd)[a-z][1-8]'

Sehen wir uns das ganze nochmal am Beispiel der IP-Addresse an. Eine IP-Adresse besteht aus 4 Octets, die mit einem '.' getrennt sind. Ein Octet kann eine Zahl zwischen 0 und 255 sein. Definieren wir als erstes ein Octet. Es kann

eine Zahl zwischen 0 und 9 sein: [0-9]
eine Zahl zwischen 00 und 99: [0-9][0-9]
eine Zahl zwischen 100 und 199: 1[0-9][0-9]
eine Zahl zwischen 200 und 249: 2[0-4][0-9]
eine Zahl zwischen 250 und 255 sein: 25[0-5]

Da sich die ersten drei Teile stark ähneln, kann man sie zusammenfassen:

* ein Zahl zwischen 0 und 199: 1?[0-9]?[0-9] (die ersten beiden Stellen können, aber müssen nicht da sein)

Das ganze sind Alternativen, also fassen wir sie einfach mittels '|' zu einem Ausdruck zusammen: '1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]' und haben damit ein Octet. Daraus können wir nun eine IP-Adresse machen, 4 Octets mit Punkten voneinander getrennt (der Punkt muß mittels backslash gequotet werden, da er sonst für ein beliebiges Zeichen steht). Basierend auf der Syntax der Exp-Files sieht das ganze dann wie folgt aus:

OCTET = '1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]'
IPADDR = '((RE:OCTET)\.){3}(RE:OCTET)'

== Erweiterte Prüfungen der Konfiguration ==

Manchmal ist es notwendig, komplexere Überprüfungen durchzuführen. Beispiele für solche komplexeren Dinge wären z.B. Abhängigkeiten zwischen Paketen oder Bedingungen, die nur erfüllt sein müssen, wenn Variablen bestimmte Werte annehmen. So muß z.B. bei Auswahl eines PCMCIA-ISDN-Adapters auch das PCMCIA-Paket installiert werden.

Um diese Überprüfungen durchführen zu können, kann man in /etc/check.d/<PACKAGE>.ext kleinere Tests schreiben. Die Sprache besteht aus folgenden Elementen:

1. Schlüsselwörter:

* Kontrollfluß:

o if (expr) then statement else statement fi
o foreach var in set_var do statement done
o foreach var in var_n do statement done

* Abhängigkeiten:
o provides package version x.y.z
o depends on package version x.y

* Aktionen:
o warning ``warning''
o error ``error''
o fatal_error ``fatal error''
o set var = value
o stat (filename, res)
o split (string, set_variable, character)
2. Datentypen: strings, numerische Werte, Versionsnummern, Arrays
3. Logische Operationen: <, ==, >, !=, !, &&, ||, =, copy_pending

== Kommunikation mit dem Nutzer ==

Mit Hilfe von Funktionen kann man Nutzer warnen, einen Fehler signalisieren oder die Prüfung sofort abbrechen. Das Format sieht wie folgt aus:

* warning ``text''
* error ``text''
* fatal_error ``text''

Im Text kann man auf Variablen Bezug nehmen, indem man einfach den Namen mit einem vorangestellten '$' oder '%' Zeichen in den Text schreibt (evtl. in eingeschlossen, um den Variablenamen vomm umgebenden Text abzugrenzen). mkfli4l versucht den darauffolgenden Text (Ziffern, Zahlen, '_') als Variablennamen zu interpretieren und setzt bei einem vorangestellten '$' den Inhalt der Variablen an dieser Stelle ein, wenn Sie definiert ist, bzw bei einem vorangestellten '%' den vollständigen Namen der aktuellen %-Variable. Sonst steht der originale Text da. Will man wirklich ein '$' oder ein '%' im Text haben, schreibt man '$$' bzw. '%%'.

=== Zuweisungen ===

Benötigt man aus irgend einem Grund eine temporäre Variable, kann man diese einfach mit ``set var [= value]'' anlegen. Die Variable darf kein Config-Variable sein. Läßt man den ``= value'' Teil weg, wird die Variable einfach auf ``yes'' gesetzt, so daß man sie hinterher einfach in einer if-Anweisung testen kann. Wird ein Zuweisungsteil angegeben, kann hinter dem Gleichheitszeichen alles stehen, normale Variablen, Indizierte Variablen, Zahlen, Zeichenketten, Versionen.

=== Arrays ===

Will man auf einzelne Elemente einer %-Variablen (eines Arrays) zugreifen, kann man das wie gewohnt mit %_var[index] tun, wobei für jedes % Zeichen ein [ Index ] auftauchen muß.

Abfragen von Eigenschaften einer Datei - stat

stat() ermöglicht es, Eigenschaften einer Datei abzufragen. Zur Verfügung gestellt wird im Augenblick lediglich die Größe einer Datei, andere Attribute sind aber leicht hinzuzufügen. Abfragen sehen wie folgt aus (wobei die verwendeten Parameter nur Beispiele sind):

stat (``unix/Makefile'', test)

Danach sind zwei Variablen definiert:

* test_res: Resultat des Systemrufs stat() (``OK'', wenn Systemruf erfolgreich, sonst Fehlermeldung des Systemrufs)
* test_size: Größe der Datei

Das könnte dann z-B. so aussehen:

stat (``unix/Makefile'', test)
if (``$test_res'' == ``OK'')
then
warning ``test_size = $test_size''
else
error ``Error '$test_res' while trying to get size of ...''
fi

=== Auseinandernehmen von Parametern - split ===

Oftmals werden Variablen mir mehreren Parametern belegt, die dann in Startup-Scripten erst wieder auseinandergenommen werden. Will man diese bereits vorher auseinandernehmen und Tests mit ihnen durchführen, nimmt man split.

split (string, %_var, character)

Der String kann durch eine Variable, %-Variable oder direkt als String angegeben werden. mkfli4l zerlegt ihn an den Stellen, an denen das Trennzeichen auftaucht und erzeugt je eine Instanz der %-Variablen. Über diese kann man dann hinterher Tests laufen lassen. Steht zwischen zwei Trennzeichen nichts, wird eine Instanz mit einer leeren Zeichenkette als Wert erzeugt. Ausnahme ist ' ', hier werden alle whitespaces konsumiert und keine leeren Variablen erzeugt.

Sollen die bei der Zerlegung entstandenen Elemente in einem numerischen Kontext verwendet werden (z.B. als Index), muß das beim Aufruf von Split spezifiert werden. Das geschieht durch das zusätzliche Attribut 'numeric'. Der Aufruf sieht dann wie folgt aus:

split (string, %_var, character, numeric)

=== Kontrollfluss ===

if (expr)
then
statement
else
statement
fi

Eine klassische if-Konstruktion, wie man sie kennt. Ist die Bedingung war, wird der then-Teil ausgeführt, ist die Bedingung falsch, wird der else-Teil ausgeführt.

Will man Tests über %-Variablen durchführen, muß man jede einzelne Variable testen. Dazu gibt es das foreach-Statement in zwei Varianten:

foreach loop_var in set_var
do
statement
done

Diese Schleife iteriert über alle %-Variablen, angefangen bei eins bis zum in der dazugehörigen (in /etc/check.d/<PACKAGE>.txt stehenden) Variable_n stehenden Index n. Die Laufvariable loop_var nimmt dabei die jeweiligen Werte der %-Variablen an.

Das Statement kann dabei eine der oben beschriebenen Funktionen if, foreach, provides, depends, warning, error oder fatal_error sein.

Will man genau eine %-Variable testen, kann man diese mittels var_%[index] auswählen. Der index kann dabei eine normale Variable, ein String, oder wiederum ein indiziertes Array sein.

foreach loop_var in var_n
do
statement
done

Diese Schleife läuft von 1 bis var_n. Man kann die Schleifenvariable loop_var dazu benutzen, um _% Variablen zu indizieren. Will man also nicht nur über eine _% Variable iterieren, sondern über mehrere gleichzeitig, nimmt man diese Variante der Schleife und verwendet die loop_var zum Indizieren mehrerer _% Variablen.

=== Expressions ===

Die Expressions erlaubt so gut wie alles, was man von einer Programmiersprache gewöhnt ist. Ein in einem Ausdruck auftauchender Wert 'val' kann eine Variable, ein String oder ein indiziertes Array sein. Variablen in Strings werden dabei wie oben beschrieben ersetzt. Ein Test auf die Gleichheit zweier Variablen könnte also so aussehen:

var1 == var2
``$var1'' == ``$var''

Zu beachten ist dabei, daß der Vergleich in Abhängigkeit vom Typ der Variable erfolgt, der in /etc/check.d/<PACKAGE>e festgelegt wurde. Variablen, die als Typnamen einen mit NUM beginnenden Namen haben erhalten einen numerischen Typ. Ist einer der beiden Variablen numerisch, erfolgt der Vergleich auf numerischer Basis, d.h. die Zeichenketten werden in Zahlen umgewandelt und dann vergleichen. Sonst erfolgt der Vergleich auf String-Basis; ein Vergleich von '05' und '5' geht ergibt ungleich, ein Vergleich von '18' und '9' ergibt '18' < '9'.

Für den Vergleich von Versionen wird das Hilfkonstrukt numeric(version) eingeführt, welches den numerischen Wert für einen Versionsstring für Vergleichszwecke bestimmt . numeric(version) == sub_version + 1000 * minor_version + 10000 * major_version:

Eine Vollständige Auflistung aller Ausdrücke ist in Tabelle 35.1 zu finden.

Tabelle 35.1: Logische Ausdrücke
expr true if
id id == 'yes'
val == val strings/numerische Werte sind identisch
val != val strings/numerische Werte sind verschieden
val == number numerischer Wert von val == number
val != number numerischer Wert von val != number
val < number numerischer Wert von val < number
val > number numerischer Wert von val > number
val == version numeric(val) == numeric(version)
val < version numeric(val) < numeric(version)
val > version numeric(val) > numeric(version)
( expr ) Ausdruck in Klammern ist wahr
expr && expr beide Ausdrücke sind wahr
expr || expr mind. einer der beiden Audrücke ist wahr
copy_pending(id) siehe Beschreibung

Prüfen, ob in Abhängigkeit vom Wert einer Variable ein File kopiert wurde: copy_pending

Mit den im Check-Prozeß gewonnenen Informationen prüft die Funktion copy_pending() ob in Abhängigkeit vom Wert einer Variable ein File kopiert wurde, oder nicht. Das kann man verwenden, um z.B. zu testen, ob der vom Nutzer angegebene Treiber auch wirklich existiert und kopiert wurde. copy_pending akzeptiert den zu prüfenden Namen in Form einer Variablen oder eines Strings. Im String werden Ersetzungen wie oben beschrieben durchgeführt, so daß man z.B. mittels einer foreach Schleife und einem ``%loop_var'' alle Inkarantionen einer %-Variable prüfen kann.

copy_pending() prüft dazu, ob

* die Variable aktiv ist (wenn sie von einem opt abhängt, muß dieses auf 'yes' gesetzt sein)

* die Variable in einem opt/package.txt File referenziert wurde

* ob in Abhängigkeit vom aktuellen Wert ein File kopiert wurde.

Ein kleines Beispiel für die Anwendung all dieser Funktionen findet man im template package.

=== Systemdateien aktualisieren ===

Manchmal ist es notwendig Einträge zu Systemdateien hinzuzufügen bzw. diese zu ändern. Damit die Dateien nicht direkt bearbeitet werden müssen, wurde ab dem base-Paket v1.0.8 eine einheitliche Schnittstellenfunktion realisiert. Initial wurden Funktionen für das Aktualisieren von /etc/host.allow, /etc/host.deny, /etc/services und /etc/inittab implementiert.

/etc/host.allow

Will ein Programm Einträge zu der Datei /etc/hosts.allow hinzufügen, so muß es eine Datei /etc/hosts.allow.<package-name> schreiben, die wie folgt aussehen sollte:

#
# /etc/hosts.allow.nfsserver list file generated by /var/install/config.d/nfsserver.sh v1.0.1-3
#
portmap: 192.168.6.0/24
lockd: 192.168.6.0/24
rquotad: 192.168.6.0/24
mountd: 192.168.6.0/24
statd: 192.168.6.0/24

Um die Änderungen bzw. Ergänzungen abschließend zu übernehmen muß noch das Programm '/var/install/bin/update-hosts.allow <package-name>' aufgerufen werden. Bei der Deinstallation des Paketes muß nur die Datei /etc/hosts.allow.<package-name> gelöscht und erneut das update-hosts.allow- Script aufgerufen werden.

/etc/host.deny

Will ein Programm Einträge zur Datei /etc/hosts.deny hinzufügen, so muß es eine Datei /etc/hosts.deny.<package-name> schreiben, die wie folgt aussehen sollte:

#
# /etc/hosts.deny.nfsserver list file generated by /var/install/config.d/nfsserver.sh v1.0.4-1
#
portmap: ALL
lockd: ALL
mountd: ALL
rquotad: ALL
statd: ALL

Um die Änderungen bzw. Ergänzungen abschließend zu übernehmen muß noch das Programm '/var/install/bin/update-hosts.deny <package-name>' aufgerufen werden. Bei der Deinstallation des Paketes muß nur die Datei /etc/hosts.deny.<package-name> gelöscht und erneut das update-hosts.deny- Script aufgerufen werden.

/etc/services

Will ein Programm Einträge zur Datei /etc/services hinzufügen, so muß es eine Datei /etc/services.<package-name> schreiben, die wie folgt aussehen sollte:

#
# /etc/services.antispam list file generated by /var/install/config.d/antispam.sh v1.2.2
#
spamd 783/tcp # SpamAssassin daemon

Um die Änderungen bzw. Ergänzungen abschließend zu übernehmen muß noch das Programm '/var/install/bin/update-services <package-name>' aufgerufen werden. Als Basis wird immer die Datei /etc/services.std verwendet deren Einträge dann ersetzt bzw. zu der neue Einträge hinzugefügt werden. Bei der Deinstallation des Paketes muß nur die Datei /etc/services.<package-name> gelöscht und erneut das update-services-Script aufgerufen werden.

/etc/inittab

Will ein Programm Einträge zur Datei /etc/inittab hinzufügen, so muß es eine Datei /etc/inittab.<package-name> schreiben, die wie folgt aussehen sollte:

#
# /etc/inittab.vbox list file generated by /var/install/config.d/vbox.sh v1.0.4-1
#
I6:2345:respawn:/usr/local/vbox/sbin/vboxgetty -d /dev/ttyI6
I7:2345:respawn:/usr/local/vbox/sbin/vboxgetty -d /dev/ttyI7

Um die Änderungen bzw. Ergänzungen abschließend zu übernehmen muß noch das Programm '/var/install/bin/update-inittab <package-name>' aufgerufen werden. Als Basis wird immer die Datei /etc/inittab.std verwendet deren Einträge dann ersetzt bzw. zu der neue Einträge hinzugefügt werden. Bei der Deinstallation des Paketes muß nur die Datei /etc/inittab.<package-name> gelöscht und erneut das update-inittab-Script aufgerufen werden.

=== Debug-Modus ===

Wird die Option -debug an die genannten Scripte übergeben, so werden detailliertere Informationen über eventuell gefundene Fehler ausgegeben.

Beispiel

Die Implementierung wird am Beispiel der Konfiguration des nfsserver-Paketes gezeigt:

...

pgmname=`basename $0`

# set file names
configfile=$testroot/etc/config.d/nfsserver
generate_hostsallow=/etc/hosts.allow.nfsserver

# other parameters
nfsserver_version="v1.0.1-3"

...

echo "#"
echo "# $generate_hostsallow list file generated by $pgmname $nfsserver_version"
echo "#"

...

# set access rights
chown root $generate_hostsallow
chgrp root $generate_hostsallow
chmod 0640 $generate_hostsallow

# update file
/var/install/bin/update-hosts.allow $pgmname

...

== ip-up/down Mechanismus ==

Sollen gewisse Aktionen nach dem Start bzw Stop einer Internetverbindung durchgeführt werden, dann kann man in das Verzeichniss /etc/ppp/ Skripte ablegen, die diese Aktionen durchführen. Der Name des Skripts bestimmt, wann es aufgerufen wird. Es gelten daher folgende Namenskonventionen (alle Namensteile sind durch einen Punkt (.) voneinander getrennt.

* Der Anfang wird durch die Namen ,,ip-up`` oder ,,ip-down`` gebildet. Ein Skript, dessen Name mit mit ,,ip-up`` beginnt, wird beim Starten der Internetverbindung ausgeführt, eines mit ,,ip-down`` im Namen nach Beendigung einer Internetverbindung.
* Der nächste Namensteil ist eine dreistellige Zahl. Diese definieren die Reihenfolge, in der die Skripte abgearbeitet werden. Die Zahlen von 000 bis 100 sind für das Routing- und Basis-Paket selbst reserviert, alle anderen Pakete dürfen die Zahlen von 101 bis 999 benutzen.
* der letzte Namensteil ist frei wählbar und sollte im Normalfall Aufschluss darüber geben, was dieses Skript macht bzw zu welchem Paket es gehört.

Als Beispiel sei

ip-up.010.dns

genannt, welche als Bestandteil des Routing-Pakets nach dem Start der Internetverbindung die DNS-Server im System bekannt macht.

ACHTUNG
In den ,,ip-down,, Skripten dürfen keine Aktionen durchgeführt werden, die eine erneute Internet-Einwahl zur Folge hat.

ACHTUNG
Diese Skripts dürfen nicht mit
exit 0
abgeschlossen werden.

Innerhalb der Skripte können folgende Variablen benutzt werden:

$real_interface
- das aktuelle Interface
$interface
- das imond-Interface
$tty
- verbundenes Terminal, möglicherweise leer
$speed
- die Verbindungsgeschwindigkeit
$local
- die eigene IP-Adresse
$remote
- die IP-Adresse der Gegenstelle

== Hinweise und Tricks ==

Um Probleme mit den Benutzerrechten (zum Beispiel Dateien, die einem User mit der ID 501 gehören, der auf dem eisfair-Server gar nicht existiert) zu verhindern, empfiehlt es sich, Packages mit

tar -czv --owner=root --group=root -f package.tar.gz *

zu verpacken. Damit gehören die entpackten Dateien erstmals dem Superuser; dieser Zustand kann, sofern er gewünscht ist, in dem Installationsskript tmpinstall.sh geändert werden.

Entwickler-Hinweise

2005-06-09T14:28:48Z

Lars: