[gelöst] Automatische Sicherung der Config in einem GIT

[th0nix]

Hallo,

ich möchte gerne meine Config bei gerder speicherung in ein Git Repo einchecken.
Ich habe ein Notify welches auf die Sicherung hört und ein paar GIT Befehle ausführen soll:

Code Auswählen Erweitern


defmod backupCfgGit notify global:SAVE {\
my $now = TimeNow();; \
`git add $attr{global}{configfile}`;;\
`git add $attr{global}{statefile}`;;\
`git commit -m "config save $now"`;;\
`git push http://$attr{$NAME}{git_username}:$attr{$NAME}{git_password}\@$attr{$NAME}{git_host}/$attr{$NAME}{git_git}/ $attr{$NAME}{git_repo}`;;\
}
attr backupCfgGit userattr git_username git_password git_host git_git git_repo
attr backupCfgGit git_username fhemuser
attr backupCfgGit git_password password
attr backupCfgGit git_host 192.168.1.11
attr backupCfgGit git_git fhem.git
attr backupCfgGit git_repo master


Ich habe nun zwei Herausforderungen:

1) Es scheinen die Attribute bist auf $attr{$NAME}{git_repo} nicht verwendet zu werden. Im Log bekomme ich folgenden Fehler:

Code Auswählen Erweitern


2021.02.13 15:43:47 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 39210411) line 7.
2021.02.13 15:43:47 3: eval: my $EVENT=   $evalSpecials->{'%EVENT'};my $EVTPART0=   $evalSpecials->{'%EVTPART0'};my $NAME=   $evalSpecials->{'%NAME'};my $SELF=   $evalSpecials->{'%SELF'};my $TYPE=   $evalSpecials->{'%TYPE'};{
my $now = TimeNow();
`git add $attr{global}{configfile}`;
`git add $attr{global}{statefile}`;
`git commit -m "config save $now"`;
`git push http://$attr{$NAME}{git_username}:$attr{$NAME}{git_password}\@$attr{$NAME}{git_host}/$attr{$NAME}{git_git}/ $attr{$NAME}{git_repo}`;
}
fatal: Der aktuelle Branch master hat keinen Upstream-Branch.
Um den aktuellen Branch zu versenden und den Remote-Branch
als Upstream-Branch zu setzen, benutzen Sie

    git push --set-upstream http://:@// master

Lösung - um die Attribute ansprechen zu können muss AttrVal($SELF,'attribute','')  z.B. AttrVal($SELF,'git_username','') verwendet werden


2) Keine Kind-Prozesse - Wenn ich das ganze ohne Variablen mache bekomme ich folgenden Fehler

Code Auswählen Erweitern


error: waitpid for pack-objects failed: Keine Kind-Prozesse
fatal: Die Gegenseite hat unerwartet abgebrochen.
fatal: Die Gegenseite hat unerwartet abgebrochen.
fatal: Die Gegenseite hat unerwartet abgebrochen.
error: Fehler beim Versenden einiger Referenzen nach 'http://fhemuser:passwort@192.168.1.11/fhem.git'
error: waitpid for git-remote-http failed: Keine Kind-Prozesse

Es spielt auch keine Rolle ob ich den Aufruf über qx() mache.

Lösung - Funktioniert über den Umweg mit  sh -c "os command" gemacht
Beispiel:

Code Auswählen Erweitern

system("sh -c 'git push http://".AttrVal('$SELF','git_username','').":".AttrVal('$SELF','git_password','')."@".AttrVal('$SELF','git_host','')."/".AttrVal('$SELF','git_git','')." ".AttrVal('$SELF','git_repo','')."'" );\

Hat jemand hierzu Ideen zu den zwei Fragen?

Danke schon mal

[betateilchen]

Du könntest ja auch gleich mit configDB arbeiten, da ist die Versionierung beim Speichern automatisch vorhanden.

[th0nix]

Dachte wieso mehr Komplexität mit DB (Sicherung, etc)  Daher der Versuch Backup und Versionierung mit einem Schlag mit GIT zu erledigen.
Aber das Aufrufen von externen Programmen aus dem notify ist wohl eicht nicht so einfach ?

[Otto123]

Hi th0nix,

dein gröbster Denkfehler ist $NAME.
Der ist doch im notify vom auslösendem Device gesetzt, das ist in deinem Fall global?

$NAME und $TYPE enthalten den Namen bzw. Typ des Ereignis auslösenden Gerätes, z.B. myFht und FHT

ein my $NAME='backupCfgGit'; vor deiner letzten Zeile löst Dein Problem ev. zunächst - ist allerdings irgendwie unschön.

Dort wo Du {global} hast, hättest Du $NAME nehmen können.

Gruß Otto

[th0nix]

Lösungen gefunden  - siehe oben

[Otto123]

Ich würde Dich bitten deine Einträge oben zu korrigieren. Das ist irreführend für jemanden der diesen Beitrag mal findet. Bei notify gibt es kein $self, Du hast es Schlussendlich mit DOIF gelöst!

[Beta-User]

$SELF wird doch evaluiert, ist nur nicht dokumentiert....
Aber Passwörter sollte man m.E. woanders speichern: getKeyValue()? (Via setKeyValue() kann man auch gleich den ganzen String hinterlegen...)

[th0nix]

Stimmt ich bin wegen dem Wait auf ein doif umgestiegen. Das $SELF geht aber wie Bet-User sagt auch dort gut -> man sieht es auch in der Varaiblenzuweisung.
Wie sieht ihr es - soll ich das oben rausnehmen / anpassen, da es unkoumentiert ist ?

Bezüglich Passwortspeicherung - Hat jemand ein gutes Beispiel mit getKeyValue ?

[Beta-User]

Im Wiki zu Pi/Email sollte was zu finden sein.

Ich habe auch ein at, das per wget einen ical runterlädt. Das sieht (RAW) schlicht so aus:

Code Auswählen Erweitern

defmod a_get_family_calendar at *23:00 {my $command = getKeyValue('famcal_command');; system($command);; }
Der komplette wget-string ist einfach per setKeyValue außerhalb der config gespeichert...

Rausnehmen brauchst du das mit $SELF m.E. nicht, glaube nicht, das Rudi das je ausbauen will...

Und das mit den "wait" geht auch bequem mit einem FHEM-sleep, ist kein hinreichender Grund für ein DOIF .

[Otto123]

wie Beta-User sagte - ich hatte das mit den Passwörtern/Accounts mal hier dokumentiert https://wiki.fhem.de/wiki/E-Mail_senden#Raspberry_Pi

Ist jetzt ev. OT
Das mit dem $SELF ist mir total neu - und ich bin immer der Meinung: (Es besteht kein Anspruch auf die Beibehaltung von Fehlern) - undokumentierte Features sind aus meiner Sicht erstmal eher als potentielles Fehlverhalten zu werten
Mit $self oder $SELF ? gibt es dann eine weitere Variante zu $name/$NAME und $dev/$DEV - das macht es irgendwie auch nicht leichter. Aber wenn es einen Plan gibt der verfolgt wird ist es ja gut.

[Beta-User]

Bzgl. "$SELF": An einen "Fehler" mag ich nicht glauben, Rudi hatte das mit voller Absicht eingebaut: https://forum.fhem.de/index.php/topic,39058.0.html

Die Frage ist eher, warum er zwar in dem Zusammenhang die Doku angefasst hat, aber diesen Punkt nicht auch gleich mit erledigt hatte: https://svn.fhem.de/trac/changeset/8953/trunk/fhem/FHEM/91_notify.pm... Den Punkt könnte/sollte man ggf. bei Gelegenheit nochmal aufgreifen.

(Von daher gäbe es wohl mit "$ln" eine weitere Variante, aber das dann in "$name" umzubenennen würde vermutlich dann auch nicht unbedingt zur Verringerung der "Variablenverwirrung" beitragen ...)

[Otto123]

Ich glaube auch nicht an einen "Fehler" - aber Rudi hat das selbst mal so in der Art gesagt: Was nicht in der Doku steht muss auch nicht funktionieren.
Der Einbau ist ja schon reichlich alt  - ist das jetzt peinlich für mich es nicht zu wissen? Oder ist die Strategie dort in eine längere Pause geraten? Ich meine für unsere immer wieder gepriesene "nicht unbedingt Verwendung von separaten Dummies" - wäre es ja sehr hilfreich eine ganz einheitliche Ermittlung des Namens des "eigenen" Gerätes für solche Perl Codestückchen zu haben.

[Beta-User]

...das muss man nicht wissen, eben weil es (noch?) nicht in der Doku steht...
Außerdem "braucht" man es nicht unbedingt (es sei denn, man geht "dummy jagen").

Was das "klappt überall" (mit $SELF?) angeht, fände ich das zwar auch wünschenswert, glaube aber nicht daran, dass das gelingen wird. Aber wie meistens: "Jemand" müsste das anschieben und an den passenden Stellen entsprechende Vorschläge machen. Hier würde es vermutlich reichen, es in die cref aufzunehmen.
Bei notify fände ich das auch "dringlich", weil man dann nicht unbedingt den (umständlichen) Weg über Log gehen müßte, um z.B. wärend der Entwicklung von Code Zwischenergebnisse auszuwerfen.

Und grundsätzlich gebe ich dir auch recht, dass kein Anspruch auf Beibehaltung von undokumentierten "Features" besteht und man daher nicht unbedingt empfehlen sollte, diese zu verwenden. Aber anders als in dem "comma separated readingList-dummy"-Thema gibt es hier nicht eine "andere" Doku, sondern eine offenkundig vergessene zu einem beabsichtigten feature. Von daher habe ich hier erst mal noch kein besonders schlechtes Gewissen ...
(Und z.B. in userReadings wäre $SELF was zusätzliches; dann versteht wieder keiner, warum $name und $SELF dasselbe machen. Wäre auch nicht optimal, und der Bezugspunkt ist auch ein anderer, denn $SELF bei notify braucht man eher zur Nachverfolgbarkeit, warum etwas passiert  - oder eben als Bezugspunkt zum Wegschreichen von irgendwas, was man sich an "zentraler Stelle" merken will...)

[rudolfkoenig]

Ich glaube auch nicht an einen "Fehler" - aber Rudi hat das selbst mal so in der Art gesagt: Was nicht in der Doku steht muss auch nicht funktionieren.

Ich habe den Faden verloren: Kann mir jemand konkret beschreiben, was nicht funktioniert?
Und auch noch, warum es wichtig waere, dass es tut?

[Beta-User]

Geht nur darum, dass $SELF (u.a. auch) in notify (seit nämlichem patch aus 2015) als Variable verwendet werden kann, aber das nicht explizit in der cref steht. Funktioniert ansonsten afaik tadellos .