Update

Aus Arktur
Version vom 3. März 2015, 16:01 Uhr von Hhullen (Diskussion | Beiträge)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Auch wenn es verlockend ist, zuerst Arktur komplett neu zu installieren und dann die lokalen Daten, die Userdaten und die Homeverzeichnisse "irgendwie" rüberzukopieren: das dauert unterm Strich länger als das unten beschriebene Verfahren, und bisher haben fast alle Kollegen (und auch ich) feststellen dürfen, dass dabei vieles nicht mitkopiert wird, insbesondere wenn der Server schon lange in Betrieb ist und der interessierte Systembetreuer ab und zu klitzekleine "Optimierungen" eingeflickt hat.

Inhaltsverzeichnis


Update auf Arktur 3.6 oder 5.x

von Arktur 1.0 und 2.x

ist noch in Arbeit

von Arktur 3.0 bis 3.3

siehe #Update_auf_Arktur_3.4.32e

von Arktur 3.4, 3.6 und 5.x

Dateien, Pakete, DVD

Die Pakete sind wie ein Arktur-Update auf dem alten Rechner zu installieren.

Das lx-Paket ist in eine *.iso-Datei zu "entzippen" und dann entweder unter Windows (einige Programme muckeln dort; "CDBurnerXP" (Freeware) funktioniert, Alcohol auch) oder aber unter Linux zu brennen.

Wer will, kann sie zum Updaten (anders als bei der Erst-Installation) auch als "virtuelle CD" mounten; siehe #Update

Kernel-Update

Es ist ratsam, zuerst bei der alten Installation den aktuellen Kernel zu installieren.

  • Die neueste Version ist (mitsamt Hinweisen zur Installation) bei http://arktur.shuttle.de/CD/beta/slack/ods8/ zu finden.
  • Alternativ kann man auch die Installations-CD von Arktur "stabil" verwenden. Sie liegt im Verzeichnis /slack/ods8.

Der neue Kernel wird installiert ein Update. Danach muss er entsprechend http://arktur.de/FAQ/content/17/79/de/wie-installiere-ich-einen-neuen-kernel.html von Lilo eingebunden werden.

Nach dem Neustart ist der neue Kernel als "Schulserver" der Default-Kernel. Wenn es Probleme geben sollte, kann man im Bootmenü auch wieder auf den alten Kernel umschalten.

Umzug

Annahme: nicht nur die neue Platte ist grösser, sondern sie kommt anschliessend auch in einen neuen Rechner - aber das ist nicht unbedingt erforderlich; sie kann auch anschliessend gegen die bisherige (Haupt-)Platte ausgetauscht werden.

Annahme: Die neue Platte wird vom Rechner als "/dev/sda" erkannt - wenn nicht, dann ändern Sie vorher in Ihrem Ausdruck dieser Anleitung die entsprechenden Benennungen.

Warnung: Einige Kollegen haben versucht, die Partitionen mit Hilfe von Umpartitionier- oder Image-Programmen zu ändern - geht meistens schief.

Wenn der Rechner auch mit dem neuen Kernel einwandfrei läuft, kopieren Sie mit Hilfe des Programms kopiere die alte Installation auf eine grössere Festplatte; heutzutage ist damit auch oft ein Wechsel von IDE-Platte zu S-ATA-Platte verbunden. Falls dieses Programm noch nicht auf dem alten Arktur vorhanden ist: nach dem Download wird es - wiederum mit Hilfe der [Updatefunktion] des sysadm-Menüs - als /root/bin/kopiere eingebunden.


Der Aufruf erfolgt vom laufenden alten Rechners aus dann mit dem Kommando

kopiere 

als root in der Kommandozeile.

Dazu wird die Zielplatte (die neue, grössere) zeitweilig (etwa als "Master" am zweiten IDE-Strang) mit in den alten Rechner eingebaut; notfalls geht das auch per USB-Adapter. Der Rechner muss dazu i.a. erst mal heruntergefahren und nach dem Umbau neu gestartet werden.

  • andere Partitionsgrössen können in "/usr/lib/ods-server/vorlagen/Groessen" definiert werden.

Notfalls geht übrigens auch der Menupunkt "kopieren auf eine andere Platte" der Installations-DVD - da sind einige klitzekleine Unterschiede im Ablauf.

  • es ist bei diesem Weg nicht unmöglich, aber ausgesprochen mühsam und verwirrend, die vor-eingestellten Partitionsgrössen zu ändern.

Die so kopierte Platte kommt in den neuen Rechner und wird dort mit Hilfe der Installations-DVD an den neuen Rechner angepasst:

auf die 2. Konsole, als "root" einloggen,

mount /dev/sda1 /ziel

(sollte meistens passen; "/ziel" ist bereits eingerichtet)

In "/ziel/etc/lilo.conf" und "/ziel/etc/fstab" ist auf die neue Platte umzustellen, meistens von "/dev/hda" nach "/dev/sda". In "/ziel/etc/fstab" und vielleicht in "/ziel/dev/cdrom" muss vielleicht auch das DVD-ROM-Laufwerk angepasst werden.

Dann:

cd
umount /ziel
fsck -y /dev/sda1

Auf Konsole 1, Menupunkt "System wieder bootfähig machen"

Neustart, eventuell Netzwerkkarten, USV usw. anpassen.

Siehe auch

Es ist ratsam, den umgezogenen Rechner erst mal einige Tage auf der neuen Platte auszuprobieren.

Update

Die neueste Version des update-Programms installieren;

bei laufendem Arktur

/root/bin/update

Dabei wird die DVD unter "/cdrom" erwartet; notfalls muss sie vorher von Hand dorthin gemountet werden. Wer sich das Brennen einer DVD ersparen will, kann auch mit einer "virtuellen CD" arbeiten:

Annahme: "ods-v5.1.00.iso" liegt in "/home/tmp"

 mount -o loop /home/tmp/ods-v5.1.00.iso /cdrom

Weiter wird geprüft, ob das Wurzelverzeichnis gross genug ist.

Wenn diese Prüfungen Erfolg hatten, dann wird in etwa 20 Minuten das System upgedatet; nach einigen Kontrollfragen am Anfang haben Sie dann also etwa 15 Minuten Pause.

patchen

Einige Fehlerkorrekturen und Sicherheits-Updates liegen in

und sollten nach-installiert werden.

von Arktur 3.5

Dateien, Pakete, CD

Die Pakete sind wie ein Arktur-Update auf dem alten Rechner zu installieren.

Das lx-Paket ist in eine *.iso-Datei zu "entzippen" und dann entweder unter Windows (einige Programme muckeln dort; "CDBurnerXP" (Freeware) funktioniert, Alcohol auch) oder aber unter Linux zu brennen.

Es ist sicherer, erst mal nur auf Arktur 3.6 upzudaten - die Version braucht nicht so viel Platz. Erst wenn das Umkopieren geklappt hat, kann anschliessend auf diese besser partitionierte Platte umgezogen werden und anschliessend auf Arktur 5.x upgedatet werden.

updaten

  • Menupunkt "Update vorbereiten" von der Installations-CD
  • updaten, wie oben beschrieben
  • "Umzug auf eine besser partitionierte Platte" geht nicht automatisch, weil Arktur 3.5 und 4.0 etwas anders partitioniert sind.
  • umkopieren vor allem für Arktur 3.5

von Arktur 4.0

  • Verfahren zur Übernahme der lokalen Daten und der Homeverzeichnisse
  • "Umzug auf eine besser partitionierte Platte" geht nicht automatisch, weil Arktur 3.5 und 4.0 etwas anders partitioniert sind.

Update auf Arktur 3.4.32e

Dieser Zwischenschritt ist nötig, wenn von Arktur 3.0 bis 3.3 upgedatet werden soll. "Umzug auf eine neue Platte" ist hier heikel, weil "System wieder bootfähig machen" einen neueren Kernel erwartet.

Dateien, Pakete, CD

wie ein Arktur-Update auf dem alten Rechner zu installieren.

Das lx-Paket ist in eine *.iso-Datei zu "entzippen" und dann entweder unter Windows oder aber unter Linux zu brennen.

Wer will, kann sie zum Updaten (anders als bei der Erst-Installation) auch als "virtuelle CD" mounten; siehe #Update

Updaten

  • Anleitung Update auf aktuelle Version

Wenn dann Arktur 3.4.32e brav läuft, kann im nächsten Schritt auf 5.1 (oder neuer) upgedatet werden.

Nacharbeiten, Kontrollen

cronjobs

Es kann sein, dass in der Datei

/etc/crontab

einige Zeilen doppelt sind; die Doubletten müssen entfernt werden.

Netzwerkkarten

Wenn ein neuer Rechner benutzt wird, sind allemal die Modulnamen der Netzwerkkarten zu ändern,

  • entweder per "sysadm"-Menu (entfernen, neu eintragen)
  • oder durch direkten Eingriff in die Datei "/etc/Systemverwaltung/ether":

als "root"

 cd /etc/Systemverwaltung
 co ether

"midnight commander": Modulnamen ändern;

  • die Liste der vermutlich passenden Namen liegt in "/usr/lib/ods-server/vorlagen/ether.lst"
  • "lspci | grep Ether" zeigt, welche Netzwerkkarten erkannt wurden

als "sysadm"

System verwalten
Änderungen aktivieren

Neustart (anscheinend werden nur dann die Änderungen brav übernommen)

quota

Vermutlich muss auch "/etc/quotatab" an die neuen Partitionsnamen angepasst werden.

sendmail

Wenn "sendmail" Probleme hat, dann bleibt viel Post in "/var/spool/clientmqueue" liegen. Oft hilft dann

/etc/init.d/sendmail stop
rm /var/spool/clientmqueue/*
rm /etc/mail/*.db
chgrp -R smmsp /etc/mail /var/spool/clientmqueue
/etc/init.d/sendmail start

Kontrollieren Sie auch, ob insbesondere die Dateien "aliases" und "access" von der alten Installation (sie liegen in /etc-orig/mail) übernommen worden sind.

Squid

"squid" (und ggfs. "squidGuard") muckelt des öfteren. Es kann sinnvoll sein, "squidGuard" erst mal zu deaktivieren; es kann sinnvoll sein, den Squid-Cache erst mal förmlich zu löschen; er wird beim nächsten Start von "squid" automatisch neu aufgebaut.

"squid"-Problemmeldungen landen am Ende von "/var/log/warn", auch noch einige Minuten nach einem Neustart.

"squidGuard": http://arktur.de/FAQ/content/23/202/de/squidguard-bremst-das-system-aus.html

USV

Die USV (genauer: der Datenaustausch) sollte vielleicht erst mal gestoppt werden; sie versorgt den Rechner auch dann eine Weile mit Energie, wenn kein Datenkabel sie mit dem Rechner verbindet.