Die Migration der Suse/Slackware basierten Arktur-Schulserver 4.0 Version auf die Debian basierte delixs-Version 1.0 wird hier beschrieben.
Die Migration der Suse/Slackware basierten Arktur-Schulserver 4.0 Version auf die Debian basierte delixs-Version 1.0 wird hier beschrieben.
Zeile 29:
Zeile 27:
=== Analyse der 4er Pakete ===
=== Analyse der 4er Pakete ===
Die 4er Pakete sind auf der Installations-CD im Unterverzeichnis /slack enthalten. /slack wiederum enthält Unterverzeichnisse die die Pakete strukturieren sollen:
Die 4er Pakete sind auf der Installations-CD im Unterverzeichnis /slack enthalten. /slack wiederum enthält Unterverzeichnisse die die Pakete strukturieren sollen:
Der Grundgedanke ist, den alten Server nicht zu verändern. Stattdessen wird ein 2ter neuer Server aufgesetzt um dann die Nutzdaten vom alten Arktur4 auf den neuen Server übers Netz kopieren zu können.
Alles was programmiert wird, soll sich an diese Richtlinien halten. Einige Dinge wie die Paketerstellung & -verwaltung, sowie die Konfiguration des Installers müssen sich auch an die "Debian Policy" halten.
Vorteil:
Sollte der neue Server noch nicht einwandfrei funktionieren, kann der alte unverändert wieder in Betrieb genommen werden.
== Arbeiten mit dem LDAP ==
Wir brauchen dazu ein Archivprogramm, das sowohl mit Posix-ACLs als auch EAs umgehen kann. GNU-tar kann dies nicht. Die rsync Version von Arktur4 ist nicht kompatibel zu der bei Delixs installierten Version. Daher fiel die Wahl auf bsdtar.
Diese beiden aus Debian lenny portierten Archive enthalten uuencode & bsdtar als statisch gelinkte Programme. Sie sind daher ausführbar auf Arktur4rc1 bis Arktur4rc6. Möglicherweise auch auf älteren 4er Versionen bzw 3er & 5er Varianten.
=== einen Dump erzeugen ===
Auf Arktur4 auszuführen:
Der Aufruf von "slapcat" liest den gesamten LDAP-Baum aus und zeigt diesen auf der Konsole im LDIF-Format an. Um diesen Dump zu speichern, muss er in eine LDIF-Datei umgelenkt werden
Anm.: den LDAP wieder starten reicht nicht, weil etliche Dienste direkt vom LDAP abhängen und diese Änderungen zum Teil nicht mitbekommen. Also Server neu starten.
Sollte es z.B. nur um Entwicklerarbeiten am LDAP gehen, dann reicht statt dessen
/etc/init.d/ldap start
''Die folgenden Code-Beispiel dienen nur zur Demonstration des Zugriffs auf den LDAP, wie in der betreffenden Überschrift angegeben. Um die bestmögliche Verständlichkeit der Scripte zu gewährleisten, wurden keinerlei Raffinessen eingebaut. Um verschiedene Möglichkeiten zu demonstrieren, wurde (wenn möglich) für jedes Script eine andere Art der Schreibweise gewählt. Es ist also ratsam, auch einen Blick auf andere (ähnliche) Beispiele zu werfen. Alle angegebenen Scripte sind, so wie sie angegeben sind (korrekte Rechtevergabe und Linux-zeilenumbrüche vorausgesetzt), lauffähig. Es wird dabei vorausgesetzt, dass es den Eintrag für'' '''mmustermann''' ''mit der GID=101 gibt. Außerdem, dass die LDAP-Base 'dc=erg,c=de' ist. Die Scripte können unter diesem Vorausetzungen und Anpassung der LDAP-Base als Grundlage für eigene Experimente verwendet werden.''
=== ausgewählte Attribute von einem Eintrag anzeigen ===
[[Kategorie:ArchivDebianLenny]]
Es wird hier demonstriert, wie man von einem Eintrag ausgewählte Attribute ausliest. Der DN spielt dabei eine besondere Rolle. Er wird immer bereitgestellt.
In diesem Beispiel wird eine Liste als Value von attrs übergeben. Da das nicht direkt geht, wird eine Referenz auf eine Liste übergeben. Deswegen die eckigen Klammern.
Zur Ausgabe folgende Bemerkung: $mesg stellt ein Objekt dar, in der alle gefundenen Einträge (Entries) der Suche enthalten sind und stellen damit eine Liste dar.
Hier wird aber nur Element gefunden bzw. ermittelt und deswegen wird mit $entry = $mesg->shift_entry; dieses eine Element aus der Liste geholt.
<source lang="perl">
#!/usr/bin/perl -w
use strict;
use Net::LDAP;
my ($ldap, $mesg, $entry, @liste);
# wir verbinden uns mit den LDAP, sonst Abbruch mit Fehlermeldung
$ldap = Net::LDAP->new('127.0.0.1',version => 3) or die "$@";
$ldap->bind or die "konnte mich nicht mit dem Server verbinden";
# der Aufruf von get_value erfolgt im Listenkontext, der mehrere Values
@liste = $entry->get_value('objectClass');
foreach my $element (@liste) {
print 'objectClass: ', $element, "\n";
}
__END__
</source>
=== einen (kompletten) Eintrag anzeigen ===
Wenn alle Attribute ermittelt werden sollen, dann wird einfach 'attrs' nicht angegeben.
Mit $entry->attributes erhalten wir die Liste der vorhandenen Attribute und können damit für jedes Attribut den Value dazu abfragen.
Da die skalaren ebenso wie die multiplen Values korrekt behandelt werden sollen, wird hier $entry->get_value($attr) durch die Klammer im Listenkontext aufgerufen und immer als Schleife abgearbeitet.
<source lang="perl">
#!/usr/bin/perl -w
use strict;
use Net::LDAP;
my ($ldap, $mesg, $entry);
# wir verbinden uns mit den LDAP, sonst Abbruch mit Fehlermeldung
$ldap = Net::LDAP->new('127.0.0.1',version => 3) or die "$@";
$ldap->bind or die "konnte mich nicht mit dem Server verbinden";
# wenn Fehlercode, dann das Script mit Fehlermeldung sterben lassen
$mesg->code and die $mesg->error;
# wir trennen uns vom LDAP
$ldap->unbind;
# wir geben jetzt die Liste der Einträge aus (jeweils DN und uid)
foreach my $entry ($mesg->entries) {
print 'dn: ', $entry->dn, "\n";
print 'uid: ', $entry->get_value('uid'), "\n\n";
}
__END__
</source>
=== Attribute eines Eintrags hinzufügen ===
Im folgenden Script wird gezeigt, wie man ein Attribut einem Eintrag hinzufügt. Da dieses Mal nicht nur Einträge aus dem LDAP gelesen werden, sondern in den LDAP geschrieben wird, brauchen wir die entsprechenden Rechte. Dazu müssen wir das LDAP-Passwort ermitteln und einen .
<source lang="perl">
#!/usr/bin/perl -w
use strict;
use Net::LDAP;
my ($ldap, $mesg, $pass);
# da wir in den LDAP schreiben, holen wir uns zuerst das LDAP-Passwort
open DATEI, '<', '/etc/ldap.secret'
or die "konnte ldap.secret nicht oeffnen, $!\n";
$pass = <DATEI>;
chomp($pass); # falls Zeilenumbruch, diesen entfernen
close DATEI;
# wir verbinden uns mit dem LDAP
$ldap = Net::LDAP->new('127.0.0.1', version => 3) or die "$@";
$ldap->bind( dn => 'cn=admin,dc=erg,c=de',
password => $pass )
or die "konnte mich nicht mit dem Server verbinden, $!\n";
# wir fügen dem Lehrer mmustermann seine Mailadresse hinzu
Diese Seite sollte nochmals überarbeitet werden. Eine Begründung befindet sich in der Regel unter Diskussion (oben).
Abschnitt: Migration Arktur 4.0rc5 -> delixs 1.0
Die Migration der Suse/Slackware basierten Arktur-Schulserver 4.0 Version auf die Debian basierte delixs-Version 1.0 wird hier beschrieben.
Vorüberlegungen
Wie bootet die Version 4
Beschreibung
Die Verwaltung der Version 4 im Betrieb
Wie wird die Version 4 aktualisiert
Analyse der 4er Pakete
Die 4er Pakete sind auf der Installations-CD im Unterverzeichnis /slack enthalten. /slack wiederum enthält Unterverzeichnisse die die Pakete strukturieren sollen:
a1 ap1 d1 a1 ap1 d1 gra1 kern n1 ods1 ods2 ods3 ods8 ods9
Nicht alle Pakete in diesen Unterverzeichnissen müssen migriert werden, einige, wie z.B. die Kernel-Pakete sollen nicht migriert werden. Ziel der Migration soll ja sein, möglichst viel von Debian zu übernehmen.
Die Pakete in den Unterverzeichnissen a1, ap1, d1, a1, gra1 und n1 enthalten weitestgehend ganz gewöhnliche Linux-Pakete ohne Arktur-spezifische Anpassungen. Solche Pakete können meist direkt aus der Debian Distribution übernommen werden. Einige enthalten aber doch Anpassungen, meist erkennbar daran, das es ein "install/doinst.sh" script gibt. Dieses script sollte dann anayliert werden.
In den Unterverzeichnissen ods1, ods2, ods3 und ods9 befinden sich die Pakete, die am meisten Aufwand bei der Migration erfordern.
In ods8 befinden sich zwei Kernel-Pakete und das Paket software.tgz welches Windows Programme enthält. Hier muss also zunächst nichst getan werden.
Schauen wir uns mal exemplarisch eines der aufwendigen Pakete an und was zu tun ist, damit es erfolgreich migriert werden kann.
Das openldap.tgz Paket
Um die Config-Details und den Ablauf der Konfigurationsscripte zu analysieren werden Scripte eingesetzt, die garantieren sollen, dass jedes Paket auf dieselbe Art analysiert wird.
Der Grundgedanke ist, den alten Server nicht zu verändern. Stattdessen wird ein 2ter neuer Server aufgesetzt um dann die Nutzdaten vom alten Arktur4 auf den neuen Server übers Netz kopieren zu können.
Vorteil:
Sollte der neue Server noch nicht einwandfrei funktionieren, kann der alte unverändert wieder in Betrieb genommen werden.
Wir brauchen dazu ein Archivprogramm, das sowohl mit Posix-ACLs als auch EAs umgehen kann. GNU-tar kann dies nicht. Die rsync Version von Arktur4 ist nicht kompatibel zu der bei Delixs installierten Version. Daher fiel die Wahl auf bsdtar.
Diese beiden aus Debian lenny portierten Archive enthalten uuencode & bsdtar als statisch gelinkte Programme. Sie sind daher ausführbar auf Arktur4rc1 bis Arktur4rc6. Möglicherweise auch auf älteren 4er Versionen bzw 3er & 5er Varianten.
