Kontakt zu Linux Programmierer
Geizhals » Forum » Programmierung » Kontakt zu Linux Programmierer (14 Beiträge, 930 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
..
Re(2): Kontakt zu Linux Programmierer
13.01.2012, 13:36:02
Klingt an sich simpel, nur sind ein paar Fragen offen:

Ist sicher nicht sehr komplex, aber ich wollte nicht alle Details gleich posten.

Es hat sich übrigens bereits jemand gemeldet, werde aber trotzdem deine Fragen beantworten.

1.) Was haben wir
als Toolchain zur Verfügung? sed?awk?bash?Nur sh? Oder soll es ein binary
werden?

sed, awk, bash: ja
Binary lieber nicht

2.) Rollback und Uninstall: Sind wir die einzigen, die die betroffenen Config-Dateien verändern? Oder pfuschen da auch andere rein?

2a.) Wenn andere Reinpfuschen: Wie sollen wir reagieren, wenn wir einen Eintrag in der Datei von A auf B geändert haben, jemand anders auf C - und wir sollen nun
Rollbacken?

Im Verlauf des Nachdenkens hat die Änderung von Konfigdateien an Priorität verloren (kommt vielleicht später wieder dazu).
Wenn Dateien geändert werden, kommen die eher als neue Version mit und werden über die alte kopiert. Das ist ein sehr geschlossenes System, wo das in den meisten Fällen gemacht werden kann.

Grundsätzlich sind wir die einzigen, die etwas verändern. Falls jemand anderer das gemacht hätte, sollten wir es aber erkennen können und abbrechen.

3.) Wieviel Platz haben wir für das Backup der zu modifizierenden
Dateien? Sind wir eher CPU-Constraint oder Storage-Constraint?

CPU ist sicher nie ein Problem, weil es sich nur um wenige Dateien (max. 20) und Größen handelt. Storage kann ein Problem sein, nachdem aber nur eine Generation (die, die wir gerade updaten) gesichert werden soll, sollte das auch kein Thema sein.

4.) Woher kommen die Informationen, wie die Permissions gesetzt werden sollen? Extra-Files? Aus dem Netz abzuholen, ... ?

Es sollten grundsätzlich alle Aktion über ein File gesteuert werden. Also, welche Dateien wohin kopiert werden, Rechte setzen, ...

5.) Kommunikation mit dem User: Sieht er die
Script-Ausgabe, oder brauchen wir Mail, ... als Mittel?

Reine Commandline zur Ausgabe, aber Logging für Details vor allem im Fehlerfall.

6.) Rollback nur eines
Schrittes (zB config ändern), wenn er fehl schlug? Oder mehr
Transaktionskontrolle mit Rollback mehrerer Schritte?

Rollback des ganzen Updates.
Wenn ein Fehler passiert, egal wann und wo, muss danach wieder der Zustand vor dem Start des Updates vorhanden sein.

Wenn Du das ganze etwas präzisierst (zB Muster mit Dummy-Dateien), Ist- und Soll-Zustand - wirst vielleicht noch heute eine Info hier gratis bekommen  

Die Dateien, die installiert werden, sind nichts besonderes. Dummy also nicht nötig.
Die Aktionen sind derzeit
- Directory anlegen/löschen
- Datei an die richtige Stelle kopieren (inkl. ersetzen einer vorhandenen)
- Datei löschen
- Rechte setzen
- Symlink erstellen
- Aufruf anderer Linux commands mit definierten Argumenten, zB useradd, tar

Reicht das?

13.01.2012, 13:36 Uhr - Editiert von steiger, alte Version: hier
Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
...
Re(3): Kontakt zu Linux Programmierer
13.01.2012, 15:22:54
sed, awk, bash: ja

Du hast also alles, was man braucht...


Wenn Dateien geändert werden, kommen die eher als neue Version mit und werden über die alte kopiert. Das ist ein sehr geschlossenes System, wo das in den meisten Fällen gemacht werden kann.

Ok. Dann wird es überhaupt simpel.

Ich würde eine Steuerdatei vorschlagen, die mal so aussieht:

payload=/mnt/bla.tar
installer_dir=/installer


Die "Payload" wird installiert und ist ein tar.

Beim Install:
  Fileliste im tar (tar -tf) in installer_dir erzeugen und installer_dir sichern
  Alle Files, die durch das tar überschrieben werden, vorher wegsichern (neues tar erzeugen, kommt in /installer_dir
  Files auspacken.
  im Fehlerfall: erzeugtes tar zurückschreiben.

Beim Uninstall:
  schauen, ob es ein erzeugtes tar gibt - wenn nein: Abbruch, SW nicht installiert
  Files aus Fileliste in installer_dir löschen
  erzeugtes tar entpacken.
  erzeugtes tar und Fileliste löschen

Durch das tar würden gleich die richtigen Permissions auf  die Files kommen... Oder soll man bei "fremden" Files die permissions setzen? Dann könnte man ein

root.root 755 /file 

an die Configdatei dranpappen.
  

Natürlich kann man alles andere in deiner Liste auch per Steuerdatei machen - nur glaube ich, dass
- ein tar viel erschlagen könnte
- die Steuerdatei seeehr ähnlich wie ein Shellscript aussehen würde. Welchen Sinn macht es dann aber, eine extra-Steuerdatei zu haben?



Wenn Du aber eh schon jemand an der Hand hast - der wird Dich sicher mit solchen Fragen nerven |-D

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
 

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung