[todo] [Software 0000073]: Config-Robot überarbeiten

[todo-notifyer at hostsharing.net]

Das folgende Problem wurde geschlossen. 
====================================================================== 
https://todo.hostsharing.net/view.php?id=73 
====================================================================== 
Berichtet von:              sm
Zugewiesen an:              _niemand
====================================================================== 
Projekt:                    Software
Problem ID:                 73
Kategorie:                  Paketkonfiguration
Reproduzierbarkeit:         zufällig
Auswirkung:                 schwerer Fehler
Priorität:                  hoch
Status:                     geschlossen
Lösung:                     wird nicht behoben
Erledigt in Version:        
====================================================================== 
Erstellt am:                17.12.2002 18:16 (CET)
Letzte Aktualisierung:      19.08.2006 15:14 (CEST)
====================================================================== 
Zusammenfassung:            Config-Robot überarbeiten
Beschreibung: 
Das für den Config-Robot benutzte Makefile und die Skripte
sollten besser dokumentiert und fehlertoleranter sein.

Die Ausführung wurde z.B. mit Fehlern beim Target publish
abgebrochen und verhinderte damit das Generieren der
virtusertable.
====================================================================== 

---------------------------------------------------------------------- 
 sm - 08.02.03 12:09  
---------------------------------------------------------------------- 
Bei der Analyse der Überlastsituation vom 7.2. ist aufgefallen, daß
das zentrale reconfigure-Script in mindestens 5 Instanzen lief und
damit auch zur erhöhten Last beigetragen hat.  Zusätzlich ist nicht
auszuschließen, daß das parallele Neugenerieren von Konfigurations-
dateien nicht auch zu inkonsistenten Daten führt.

Als erste Maßnahme wurde in /root/bin/reconfigure ein Locking-
Mechanismus eingebaut, der ein atomares Lock in Form eines Ver-
zeichnisses anlegt und sich bei einem vorhandenen Lock nach dem
Versenden einer Mail wieder beendet.  Dadurch sollte das Script nun
nur noch maximal in einer Instanz laufen. 

---------------------------------------------------------------------- 
 sm - 08.02.03 13:34  
---------------------------------------------------------------------- 
Es ist zu überlegen, in wieweit das Makefile, welches heute für die
meisten Config-Dateien verwendet wird, weiter benutzt werden soll.
Im Prinzip ist der Make-Mechanismus sinnvoll, da so die Abhängigkeiten
dargestellt werde können und ein Programm gestartet wird, wenn neue
Dateien angelegt wurden.

Dieser Mechanismus wird jedoch heute so auch nicht verwendet, so daß
zusätzlicher Overhead entsteht, weil zunächst alle Dateien von Make
überprüft werden und dieses nochmals durch das eigentliche Skript
passiert.  Bei der Verwendung von Make ergibt sich auch ein Problem,
wenn während des Laufes an den Quelldateien editiert wird.  In diesem
Fall werden die Änderungen ggfs. weder in diesem noch einem folgenden
Config-Lauf übernommen.

Ich schlage die folgende Architektur vor:

1) Es gibt zwei zentrale Timestamp-Dateien, die vom reconfigure-
   Script verwaltet werden.  Zu Begin eines Laufes findet ein Move der
   zweiten Datei auf die erste Datei statt und dann wird mit touch die
   zweite Datei neu angelegt.  Das reconfigure-Script ermittelt die
   vorgenommenen Änderungen durch folgendes Kommando:

   find /home/pacs/*/etc/passwd -newer timestamp1 -not -newer timestamp2 

   Damit werden nur die Dateien ermittelt, die nach dem letzten Lauf,
   aber vor diesem Lauf modifiziert wurden.

2) Die einzelnen Skripte werden mit der Liste der Dateinamen aufgerufen.
   Ein Skript prüft also nicht weiter, welche Dateien geändert wurden,
   sondern arbeitet nur die Liste ab.  Jedes Skript bearbeitet außerdem
   nur die Deltas, so daß nicht die komplette Konfiguration neu erstellt
   werden muß.

3) Wenn alle Skripte gemäß Punkt 2) arbeiten, haben wir außerdem eine
   einfache Migration auf die bereits diskutierte Push-Variante.  Eine
   vom User z.B. über ein Spooldir übergebene Änderung kann dann einfach
   von dem bereits existierenden Skript eingepflegt werden.

4) Die Skripte arbeiten gemäß der Unix-Philosophie, daß keine Meldung
   eine gute Meldung ist.  Die Ausgabe von reconfigure beinhaltet also
   nur noch Fehlermeldungen, so daß diese auch per Mail verschickt werden
   können.

5) Für reconfigure kann durch eine --force Option der Test des ersten
   Timestamps deaktiviert werden.  Damit lassen sich also alle 
   Konfigurationen erstellen, so daß hierüber z.B. nach einem Schwenk
   auf den zweiten Server zentral alle Einstellungen aktivieren lassen. 

---------------------------------------------------------------------- 
 paul - 11.09.04 23:39  
---------------------------------------------------------------------- 
Wir wollen auf ein Push-Konfigurationssystem (hsadmin*,
https://todo.hostsharing.net/view.php?id=221) umsteigen.
Vorher noch den alten Konfigurationsmechanismus grundlegend umzubauen ist
IMO nicht sinnvoll.

Andere Meinungen? Sonst: Bug schließen! 

---------------------------------------------------------------------- 
 paul - 17.12.04 20:41  
---------------------------------------------------------------------- 
Seit über drei Monaten kein Einspruch gegen das Schließen. 

Problem-Historie 
Änderungsdatum  Benutzername   Feld                     Änderung             
====================================================================== 
11.09.04 23:39  paul           Problemnotiz hinzugefügt: 0000950                
   
17.12.04 20:41  paul           Status                   zugewiesen => erledigt
17.12.04 20:41  paul           Lösung                   offen => wird nicht
behoben
17.12.04 20:41  paul           Problemnotiz hinzugefügt: 0001148                
   
17.12.04 20:41  paul           Status                   erledigt => geschlossen
19.08.06 11:24  mi             Status                   geschlossen =>
zugewiesen
19.08.06 11:24  mi             Bearbeitung durch        mi => _niemand      
19.08.06 15:14  mi             Status                   zugewiesen =>
geschlossen
======================================================================