[linux-l] Bug Tracker der sich gescheit updaten lässt

[Peter Ross]

Quoting Olaf Radicke <briefkasten at olaf-radicke.de>:

> Hallo Peter,
>
>> Peter Ross <Peter.Ross at bogen.in-berlin.de> hat am 14. August 2015 um 03:52
>> geschrieben:
>> Sowie Du etwas konfiguriert hast, musst Du diese Konfiguration anwenden.
>
> Ja und? Wenn sich das Konfigurationsformat in einer Version verändert,
> erwarte ich, das die Applikation die alte Konfiguration konvertiert und
> ggf. sinnvolle Standardwerte für neue Parameter setzt.

Das Format hat sich meines Wissens nicht geaendert.

Es ist Sache des Paketmanagements, ob die Konfiguration beim Update  
erhalten bleibt.

Ich mache generell keine Paketupdates, da ich die schon genannten  
Jails verwende.

Update heisst neues Jail unter /jails/<jailname>/<zeitstempel>,  
Konfiguration (aus dem Subversion-repository) und dann wird das alte  
durch das neue Jail ersetzt.

Auf die Art und Weise habe ich die alte Version zur Verfuegung, wenn  
was schiefgeht. (Bei Redmine kommt noch ein mysqldump dazu).

Generell ist eine Konfiguration nichts wert, wenn masn sie nicht aus  
einer "Vanilla-Installation" heraus rekonstruieren kann.

Sicher kannst Du was anderes als die Shell nehmen  Die Shell hat den  
Vorteil, dass sie ueberall vorhanden ist, und in "gut kontrollierten"  
Umgebungen (wie einer frischen Installation ohne nutzergenerierte  
Dateien) kann man durchaus deterministisches Verhalten erwarten.

Das Dir gegebene Beispielskript habe ich fuer einige Jahre erfolgreich  
verwendet, wie viele andere, die ich in inzwischen 20 Jahren  
Unix-Administration geschrieben habe. Defensives Testen gehoert  
natuerlich auch dazu. Zumeist haben meine Skripte einen  
"Testlaufparameter", dann wird das Skript mit echo="echo"  
durchgefuehrt (vort jedem Kommando steht ${echo}, so dass statt der  
Ausfuehrung angezeigt wird, was geschrieben werden soll.

>> Wenn ein Programm eine Datenbank verwendet, kann sich die Struktur
>> aendern, deshalb das Migrationsskript.
>
> Die Anwendung sollte erkennen können, auf welchen Versionsstand sich
> die DB befindet. Schon alleine um sicherzustellen, das eine DB nicht
> korrupt geht. Das Konvertieren der DB sollte die Applikation übernehmen,
> denn die Entwickler sollten ihre DB besser kennen als die Admins.

Wenn Dein Update via Paketmanager die DB-Migration enthaelt, merkst Du  
davon gar nichts.

Wenn nicht, denn darfst das alles gern in Dein "olaf-redmine.deb"  
verpacken, dann hat sich das.

>> Das alles laesst sich in einem Skript durchfuehren. Nichts, was
>> irgendwie Deiner Aufmerkdsamkeit beduerfte, wenn das Skript da ist.
>
> Bash ist nicht gerade für seine Fehlertoleranz bekannt.

Das war gar keine bash. #!/bin/sh

> Zudem sind Bash-Skripte langsam.

Kann jemand mal jemand mit diesem Unfug aufhoeren? Es geht hier um den  
Aufruf von weniger als einer Handvoll Binaries, bei einer  
Installation, die Du vielleicht einmal im Quartal ausfuehrst.. Selbst  
in Assembler geschrieben wuerdest Du vielleicht 'ne Millisekunde pro  
Quartal "gewinnen".

>> Ich habe langsam das Gefuehl, es gibt im Linux-Lager Bestrebungen, das
>> System undurchschaubar zu machen, und das Sicherheit keine Rolle mehr
>> spielt.
>
> Es gibt ja (mittlerweile) unter Linux verschiedene Container-
> Technologieehen mit unterschiedlichen Ansätzen und Schwerpunkten.
> Unter Linux ist die Sache ja erst im Kommen. Da ist klar, das
> man dann erst mal Lehrgeld zahlt.

Man koennte statt der halbdurchdachten Neuerfindung des Rades durchaus  
auch seit Jahren funktionierende Systeme verwenden, wie z.B.  
FreeBSD/jails/ZFS.. Aber "nichts ist gut, wenn es nicht aus unserem  
Stall stammt und da vermurkst wurde".

Anyway, von Pragmatik kann eh wohl kaum die Rede sein, wenn jemand  
Redmine ausschliesst, weil das Kopieren von drei Konfigurationsdateien  
und einem Skriptaufruf seinem Schoenheitsideal wieder spricht..

Soll Deine Software vielleicht neben einer "schoenen" Installation  
auch noch eine Funktion haben??

Es gruesst
Peter