Diskussionsthread EDOMI-Releases/Updates

[gaert]

Hab's mir mal angesehen und ein wenig gepimpt:

• Multiple sed-, yum- und rm-Statements zusammengefasst
• OS-Detection eingebaut

Danke für Deine Mühen! Allerdings habe ich die sed's, yum's usw. bewusst nicht zusammengefasst - das macht's (für mich zumindest) übersichtlicher wenn ich da mal ran muss

Und die OS-Erkennung möchte ich eher nicht integrieren (ich hatte durchaus darüber nachgedacht): Der geneigte User dürfte recht genau wissen, welches OS er vor 2 Minuten installiert hat Aber ich werde dennoch darüber (erneut) nachdenken...

EDIT:
Deine "aus welchem Verzeichnis wurde das Script aufgerufen"-Funktion hat's hingegen ins Script geschafft Danke!

[gaert]

ist auf den Kanaren Sa. Abends nichts los?

Keine Ahnung Ich hänge ja Abends immer vor'm PC... Mein "kleines Hirn" ist bereits atrophiert...

Für Spenden bin ich allerdings stets empfänglich - ich bedanke mich schonmal vorab! Dies gilt natürlich auch für alle anderen Spender und Nichtspender (die ja wiederum potentielle Spender sein könnten)

[gaert]

könnte man dem Visuelement Liste/Tabelle einen Rückgabewert einbauen?

Derartiges steht schon lange uff Liste und wird "zu gegebener Zeit" abgearbeitet...

[gaert]

könntest du die Files unter dem Pfad WWW, die bisher ja ohne bcompiler frei zugänglich waren vor dem Entfernen der Zeilenumbrüche und Whitespaces verschonen?

Sorry, da muss ich Dir leider einen Korb geben. An den Quelltexten soll nicht herumgefummelt werden - auch wenn sich natürlich die wenigsten daran halten dürften. Dies hat einen ganz einfachen Grund: In EDOMI kann sich jederzeit alles Mögliche ändern und dann funktionieren vom Nutzer selbst implementierte Geschichten nicht mehr.

Daher weise ich gerne noch einmal darauf hin, dass nur die Erstellung eigener LBS vorgesehen ist (mit den in der Hilfe erläuterten Funktionen). Alles andere kann sich ohne Vorankündigung ändern!

[skyacer]

Hi,

wollte bei mir das Update von 1.62 auf 1.64 durchführen. In Edomi wird mir nur 1.63 angezeigt und wenn ich von der Homepage die 1.64 nehme sagt er mir auch immer falsche Version. Gibt es nur die Möglichkeit über den Patch zu Updaten?

Grüße

[OleDeluxe]

Hi,
War bei mir grad auch so. Hab dann mit patch auf 1.63 und von da aus dann ganz normal auf 1.64.
Alles ohne Probleme.

Gruß Sven

[gaert]

Der Patch für 1.62 ist leider in der Tat notwendig (sonst hätte ich diesen ja nicht publiziert...).

[SvenA]

Kann es sein, daß man beim Update (auf die 1.63) Fehler in der Art:

FEHLER: Datenbank edomiProjekt.editVisuElement: ZSU anpassen
FEHLER: Datenbank edomiProjekt.editArchivKo modifizieren: ADD cunit
...

bekommt, wenn man noch kein Projekt hat?
Ist eine blanke Installation ohne jegliches Projekt hier.

Kann das in diesem Fall ignoriert werden?

[SvenA]

Hallo!

Ich habe für die RasPi Unterstützung zwei wichtige Anpassungen am "start.sh" Skript machen müssen. Die Änderungen sollten auch ohne Probleme unter CentOS laufen und ändern die Logik nicht ab, sondern starten die externen Skripte nur auf eine andere Weise.

Wäre nett, wenn die Änderung übernommen wird, da das "start.sh" Skript auch Teil jeden Updates ist und andernfalls auf einen RasPi jedesmal nach einem Update die Änderung wieder durchgeführt werden müssten.

Hier der Patch:

--- start.sh.orig    2019-02-17 21:24:12.904816507 +0100
+++ start.sh    2019-02-17 21:30:31.347793337 +0100
@@ -96,8 +96,9 @@
 
     if [ -f /tmp/edomirestore.data ]; then
         
-        sh /tmp/edomirestore.sh &
         echo "EDOMI: Beenden..."
+        exec sh /tmp/edomirestore.sh
+        echo "FEHLER: Restore Skript konnte nicht gestart werden!"
         exit
     
     fi
@@ -141,8 +142,9 @@
 
     if [ -f /tmp/edomiupdate.data ]; then
         
-        sh /tmp/edomiupdate.sh &
         echo "EDOMI: Beenden..."
+        exec sh /tmp/edomiupdate.sh
+        echo "FEHLER: Update Skript konnte nicht gestart werden!"
         exit
     
     fi

Außerdem schlage ich noch diese Skript vor, um eventuellen zukünftigen Änderungen begegnen zu können ohne die Datei patchen zu müssen.

--- start.sh    2019-02-17 21:30:31.347793337 +0100
+++ start.sh2    2019-02-17 21:35:36.251386020 +0100
@@ -4,10 +4,16 @@
 # mySQL-DB-Pfad (absolut)
 MYSQL_PATH="/var/lib/mysql"
 
+# Optionales prestart Script
+PRESTART_SCRIPT="$MAIN_PATH/main/prestart.sh"
+
 echo -e "\033[42m\033[30m--------------------------------------------------------------------------------\033[49m\033[39m"
 echo -e "\033[42m\033[30m                       EDOMI - (c) Dr. Christian Gärtner                        \033[49m\033[39m"
 echo -e "\033[42m\033[30m--------------------------------------------------------------------------------\033[49m\033[39m"
 
+# Optionales Skript laden, wenn ausführbar vorhanden
+[ -x $PRESTART_SCRIPT ] && . $PRESTART_SCRIPT
+
 # PC-Speaker aktivieren
 # modprobe pcspkr

Bisher mußte ich von EDOMI keine einzige Zeile ändern außer in diesem Skript, da dies hier das zentrale Skript darstellt, welches direkt mit dem OS interagiert. Wäre schön, wenn ich durch diese Änderungen auch in Zukunft keinen Code ändern müßte und damit Restore und Update immer funktionieren.

Gruß
Sven

[starwarsfan]

N'abend gaert

Danke für Deine Mühen!

Kein Ding.

Allerdings habe ich die sed's, yum's usw. bewusst nicht zusammengefasst - das macht's (für mich zumindest) übersichtlicher wenn ich da mal ran muss

Nunja, an der Übersichtlichkeit hat sich explizit nichts geändert, da eben extra deswegen jedes Statement auf einer eigenen Zeile steht. Wenn's da Anpassungen gibt, wird eben einfach die entsprechende Zeile geändert oder gelöscht bzw. eine neue Zeile hinzugefügt. Mir wäre es wesentlich wichtiger, dass eben nicht für jeden Step das entsprechende Tool wieder neu gestartet werden muss.

Und die OS-Erkennung möchte ich eher nicht integrieren (ich hatte durchaus darüber nachgedacht): Der geneigte User dürfte recht genau wissen, welches OS er vor 2 Minuten installiert hat Aber ich werde dennoch darüber (erneut) nachdenken...

Freut mich, wenn Du da nochmal drüber nachdenkst, denn wieso das nicht eingebaut werden sollte, möchte sich mir nun wirklich nicht erschliessen. Unabhängig davon, ob der DAU nun noch weiss, welches OS er gerade eben installiert hat: Warum sollte denn dieser Stolperstein mit der Auswahl des korrekten Systems drin bleiben, wenn sich das so elegant automatisieren lässt? Bei ein paar Dutzend Varianten mit jeweils anderen Vorgehensweisen ok, aber hier bei zwei Möglichkeiten?

Deine "aus welchem Verzeichnis wurde das Script aufgerufen"-Funktion hat's hingegen ins Script geschafft Danke!

Feinfein, freut mich!

[gaert]

Kann es sein, daß man beim Update (auf die 1.63) Fehler in der Art:

FEHLER: Datenbank edomiProjekt.editVisuElement: ZSU anpassen
FEHLER: Datenbank edomiProjekt.editArchivKo modifizieren: ADD cunit
...

bekommt, wenn man noch kein Projekt hat?
Ist eine blanke Installation ohne jegliches Projekt hier.

Kann das in diesem Fall ignoriert werden?

Das ist korrekt - denn dann existieren ja die entsprechenden Datenbanken noch gar nicht. Diese Meldung darf dann in der Tat ignoriert werden.

[gaert]

Bei ein paar Dutzend Varianten mit jeweils anderen Vorgehensweisen ok

Genau das ist der Punkt (theoretisch) - natürlich nicht Dutzende aber evtl. später mal "einige" Grundsätzlich aber hast Du natürlich recht... Wie gesagt: Denkprozess ist eingeleitet

[gaert]

SvenA

Der "&"-Parameter stört auf dem RasPi?! Warum? Muss ich mir mal genauer anschauen.

Deine Prestart-Script-Idee ist im Prinzip ja in Ordnung, aber ich verstehe den Sinn nicht wirklich: Wenn der geneigte Nutzer EDOMI auf einem nicht unterstütztem System installiert, weiß er (hoffentlich) was er da macht und kann doch einfach *vor* dem Aufruf der start.sh irgendwelche anderen Scripte aufrufen?!

EDIT:
Hab' mir das mal angeschaut (&-Parameter) - ist tatsächlich eher eine Altlast und wird ab 2.00 entfernt, da an dieser Stelle vollkommen überflüssig

[SvenA]

Deine Prestart-Script-Idee ist im Prinzip ja in Ordnung, aber ich verstehe den Sinn nicht wirklich: Wenn der geneigte Nutzer EDOMI auf einem nicht unterstütztem System installiert, weiß er (hoffentlich) was er da macht und kann doch einfach *vor* dem Aufruf der start.sh irgendwelche anderen Scripte aufrufen?!

Ich könnte zum Beispiel einen Aufruf eines Tools, welches unter einem anderen OS nicht existiert oder einfach anders heißt, durch eine Shell Funktion (oder einen alias) ersetzen und so ohne Änderung des Skripts eine Korrektur machen.

[gaert]

Klar, aber warum rufst Du dieses Script dann nicht einfach *vor* dem Start von EDOMI (start.sh) auf? Also in rc.local bzw. systemd (ab CentOS 7)...