Zusätzliche Funktion bei updatefhem

Begonnen von Guest, 18 Oktober 2011, 10:50:17

Vorheriges Thema - Nächstes Thema

Guest

Originally posted by: <email address deleted>

Hallo,

ich habe bei updatefhem den Parameter    backup   eingebaut. Dadurch
werden alle Dateien des Verzeichnises, in dem die Module liegen, in
ein anderes Verzeichnis kopiert. Dadurch hat man im Problemfall eine
vorherige Version seiner Module.
Das andere Verzeichnis kann durch das Globalattribut  backupdir
festgelegt werden oder als Standard wird /tmp/FHEM_Backup genommen.
Ist das Verzeichnis nicht vorhanden, versucht  backup  das Verzeichnis
anzulegen.
Wichtig ist zu beachten, das der fhem-user auch die Berechtigung hat,
das Verzeichnis anzulegen bzw. darin zu schreiben.
Aufruf der neuen Funktion erfolgt über   updatefhem backup   oder wenn
nur ein einzelnes Modul geladen werden soll über   updatefhem backup
  . In dem letzten Fall wird auch nur das angegebene Modul
in das Backupverzeichnis kopiert. Selbstverständlich funktioniert auch
noch   updatefhem .

Viele Grüße,

RueBe

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Hi RueBe,

eine Backupfunktion finde ich eine ausgezeichnete Idee, aber warum mit
einem separaten Parameter?
Ich hätte jetzt erwartet, dass "updatefhem" ab sofort halt eine Kopie
vor dem Ersetzen anlegt - als Param höchstens "restore", um das Backup
wieder einzuspielen... ;-)

/tmp halte ich für etwas problematisch, das liegt bei vielen Systemen
in der RAMDisk oder wird beim Booten gelöscht.
Um sicher zu sein, dass FHEM hineinschreiben darf würde sich doch eher
das FHEM-Verzeichnis anbieten? Oder erzeugt das dann andere Probleme?

--
cu/2
T.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Hallo Tom,

es gibt da, wie immer im Leben ein sowohl als auch. Wenn ich backup
voll automatisch mache, dann kann es mir passieren, das ich etwas
überschreibe, das ich gar nicht überschreiben möchte, mache ich es
nicht automatisch sondern mit einem Parameter, dann habe ich daran zu
denken,
diesen Parameter zu setzen. Ich habe mich da für die zweite Lösung
entschieden, da es nicht viel Aufwand ist und ich alles unter
Kontrolle
habe.

/tmp deswegen, weil das so ziemlich der einzige Ort im Filesystem ist,
wo es keine Probleme mit dem Ordner- und Dateirechten gibt.
Wobei /tmp ja auch nur der Standardwert ist, denn niemand gezwungen
ist zu nehmen. Dafür steht ja das global Attribut backupdir zur
Verfügung.
Bei Benutzung von backupdir bist du aber dafür verantwortlich, dafür
zu sorgen, das der user fhem auch in diesem Verzeichnis schreiben
darf.
Das fhem Verzeichnis würde ich nicht dafür nehmen, denn wenn ich mit
diesem Verzeichnis ein Problem habe, dann nützt mir auch der backup in
dem
Verzeichnis wohlmöglich nichts mehr. Ich für mich persönlich habe das
Backup auf eine andere Platte gelegt.

Ich könnte mir auch vorstellen, das sich jemand findet, der mit ein
wenig Perl und einem notify sogar eine Versionsroutine zu updatefhem
backup bastelt.

Viele Grüße,
RueBe

On 18 Okt., 16:25, Tom wrote:
> Hi RueBe,
>
> eine Backupfunktion finde ich eine ausgezeichnete Idee, aber warum mit
> einem separaten Parameter?
> Ich hätte jetzt erwartet, dass "updatefhem" ab sofort halt eine Kopie
> vor dem Ersetzen anlegt - als Param höchstens "restore", um das Backup
> wieder einzuspielen... ;-)
>
> /tmp halte ich für etwas problematisch, das liegt bei vielen Systemen
> in der RAMDisk oder wird beim Booten gelöscht.
> Um sicher zu sein, dass FHEM hineinschreiben darf würde sich doch eher
> das FHEM-Verzeichnis anbieten? Oder erzeugt das dann andere Probleme?
>
> --
> cu/2
> T.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

borsti67

                                                 

Moin,

> es gibt da, wie immer im Leben ein sowohl als auch. Wenn ich backup

na klar, drum frag' ich ja. ;)

> voll automatisch mache, dann kann es mir passieren, das ich etwas
> überschreibe, das ich gar nicht überschreiben möchte, mache ich es

ok, ich kann mir zwar gerade keinen konkreten Einsatz vorstellen, aber
Du hast da vermutlich mehr Ahnung als ich.
Meine Annahme wäre gewesen, dass die aktuelle FHEM-Version funktioniert
und somit vor einem Update IMMER zu sichern wäre, so dass ich bei einem
Problem NACH dem Update wieder einen Schritt zurück kann. Eine
richtiggehende Versionierung wäre wohl "Overkill"...

> Wobei /tmp ja auch nur der Standardwert ist, denn niemand gezwungen
> ist zu nehmen. Dafür steht ja das global Attribut backupdir zur
> Verfügung.

keine Frage!

> Bei Benutzung von backupdir bist du aber dafür verantwortlich, dafür
> zu sorgen, das der user fhem auch in diesem Verzeichnis schreiben
> darf.

Genau da habe ich (persönlich) aber gerade ein Problem mit. Ich sehe
mich als Anwender, der von der System-Ebene keine Ahnung hat (bzw haben
muss). Es war schon recht aufwendig (für mich) überhaupt UPDATEFHEM zum
Laufen zu bekommen, da die Standardrechte nach der Installation nicht
gepasst haben...
Nun kann man natürlich argumentieren, dass man dann die Finger vom
Update lassen soll, aber das halte ich nicht für korrekt: Man nehme z.B.
die neue Funktionalität der Oster-Berechnung, auf die ich um ein Haar
hätte verzichten müssen, und die nun Teil des Paketes wurde. Wer weiß,
wann es für meine Plattform ein neues installierbares Release-Paket
geben wird?

> Das fhem Verzeichnis würde ich nicht dafür nehmen, denn wenn ich mit
> diesem Verzeichnis ein Problem habe, dann nützt mir auch der backup in
> dem
> Verzeichnis wohlmöglich nichts mehr.

hmmm, das kann ich natürlich nicht beurteilen, ohne Deine
Backup-Strategie zu kennen. 8-) Sofern Du lediglich die Dateien
kopierst, die "geupdated" werden sollen, sehe ich da kein Konfliktpotential.
Aber sei's drum, viel wichtiger ist, dass so eine Funktion jetz
überhaupt mit vorgesehen ist!

> Ich könnte mir auch vorstellen, das sich jemand findet, der mit ein
> wenig Perl und einem notify sogar eine Versionsroutine zu updatefhem
> backup bastelt.

So in der Art, einen Counter hinter den Dateinamen anzuhängen? Könnte
sogar ohne notify gehen (es sei denn Du meinst, per notify das Update zu
triggern). Grübel... =8)

Gruss
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
cu/2
Borsti
---
FHEM 5.8 auf Synology DS211j (bis 11/17) | FHEM 6.0 auf Raspi Zero W (bis 11/20) | FHEM 6.2 als VM in Synology DS1815+ (ab 11/20)

Guest

Originally posted by: <email address deleted>

Ich sehe schon, da habe ich aus der Sicht eines Linuxkundigen
vielleicht
mir die Sache zu einfach gemacht.... :-)))

Ok, fasse ich mal zusammen:
1. es sollte eine Möglichkeit geben, dieses Backup automatisch zu
machen
2. vielleicht noch ein restore, falls ein Update mal schief gegangen
ist
3. den Speicherort am besten systemkonform anlegen, ohne das der
Benutzer sich darum kümmern muss

zu 1: läßt sich wohl machen, im Global ein Attribut wie etwa
backupautomatik  (sehr sperrig, muss ich noch darüber grübeln)
zu 2: das könnte man sicher einbauen
zu 3: das ist ein wenig schwieriger, weil die Systeme, auf denen FHEM
läuft nun mal unterschiedlich sind. Muss ich noch eruieren,
 ob man z.B. die Sicherung im Homeverzeichnis des fhem-Benutzers ohne
Probleme unterbringen kann. Macht mir insofern Bauchschmerzen
weil auf meinem Ubuntu der fhem-user als Homeverzeichnis /var/log/fhem
hat, wo eigentlich nur log-Dateien hinein gehören.

Ok, ich würde sagen, da wartet noch ein wenig Arbeit auf mich....stay
tuned!

Viele Grüße,

RueBe

On Oct 18, 9:06 pm, borsti wrote:
> Moin,
>
> > es gibt da, wie immer im Leben ein sowohl als auch. Wenn ich backup
>
> na klar, drum frag' ich ja. ;)
>
> > voll automatisch mache, dann kann es mir passieren, das ich etwas
> > überschreibe, das ich gar nicht überschreiben möchte, mache ich es
>
> ok, ich kann mir zwar gerade keinen konkreten Einsatz vorstellen, aber
> Du hast da vermutlich mehr Ahnung als ich.
> Meine Annahme wäre gewesen, dass die aktuelle FHEM-Version funktioniert
> und somit vor einem Update IMMER zu sichern wäre, so dass ich bei einem
> Problem NACH dem Update wieder einen Schritt zurück kann. Eine
> richtiggehende Versionierung wäre wohl "Overkill"...
>
> > Wobei /tmp ja auch nur der Standardwert ist, denn niemand gezwungen
> > ist zu nehmen. Dafür steht ja das global Attribut backupdir zur
> > Verfügung.
>
> keine Frage!
>
> > Bei Benutzung von backupdir bist du aber dafür verantwortlich, dafür
> > zu sorgen, das der user fhem auch in diesem Verzeichnis schreiben
> > darf.
>
> Genau da habe ich (persönlich) aber gerade ein Problem mit. Ich sehe
> mich als Anwender, der von der System-Ebene keine Ahnung hat (bzw haben
> muss). Es war schon recht aufwendig (für mich) überhaupt UPDATEFHEM zum
> Laufen zu bekommen, da die Standardrechte nach der Installation nicht
> gepasst haben...
> Nun kann man natürlich argumentieren, dass man dann die Finger vom
> Update lassen soll, aber das halte ich nicht für korrekt: Man nehme z.B.
> die neue Funktionalität der Oster-Berechnung, auf die ich um ein Haar
> hätte verzichten müssen, und die nun Teil des Paketes wurde. Wer weiß,
> wann es für meine Plattform ein neues installierbares Release-Paket
> geben wird?
>
> > Das fhem Verzeichnis würde ich nicht dafür nehmen, denn wenn ich mit
> > diesem Verzeichnis ein Problem habe, dann nützt mir auch der backup in
> > dem
> > Verzeichnis wohlmöglich nichts mehr.
>
> hmmm, das kann ich natürlich nicht beurteilen, ohne Deine
> Backup-Strategie zu kennen. 8-) Sofern Du lediglich die Dateien
> kopierst, die "geupdated" werden sollen, sehe ich da kein Konfliktpotential.
> Aber sei's drum, viel wichtiger ist, dass so eine Funktion jetz
> überhaupt mit vorgesehen ist!
>
> > Ich könnte mir auch vorstellen, das sich jemand findet, der mit ein
> > wenig Perl und einem notify sogar eine Versionsroutine zu updatefhem
> > backup bastelt.
>
> So in der Art, einen Counter hinter den Dateinamen anzuhängen? Könnte
> sogar ohne notify gehen (es sei denn Du meinst, per notify das Update zu
> triggern). Grübel... =8)
>
> Gruss
> Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

*grins*

> 1. es sollte eine Möglichkeit geben, dieses Backup automatisch zu
> machen

das wäre sicherlich toll - und im Zusammenhang mit "3." kam ich ja
darauf, dies als einen Unterordner von "FHEM" machen zu wollen. Immer
vorausgesetzt wie gesagt, dass dies keine anderen
Probleme/Sicherheitslücken aufreißt, immerhin ist das ja quasi auch das
Web-Verzeichnis.

> 2. vielleicht noch ein restore, falls ein Update mal schief gegangen
> ist

Das Tüpfelchen auf dem "i". :D
Für den Linux-und/oder-Perl-Unkundigen dürfte auch ein manuell gemachtes
Backup nicht viel nützen, wenn er denn bei Bedarf nicht weiß, wie er
daraus wieder ein lauffähiges System herstellen kann.

Ich fürchte aber, das wäre ziemlich viel Arbeit (insbesondere, wenn man
eine denkbare Versionierung von vornherein berücksichtigen will)... :-/

> Ok, ich würde sagen, da wartet noch ein wenig Arbeit auf mich....stay
> tuned!

klingt, als wärst Du immer noch motiviert. ;) Feini!

Gruss
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

eppi

                                               

Hallo zusammen
Auch ich habe mich vor einiger Zeit mit dem Backup von FHEM
beschäftigt und mir ein kleines Script geschrieben. Um das ganze zu
automatisieren, kann man einen Cron Job oder in Fhem einen "at"
definieren.
Das Script (backup-fhem.sh) sichert folgendes:
fhem.cfg
fhem.pl
FHEM Module Verzeichnis
FHEM Log Verzeichnis
cgi-bin Verzeichnis (brauche ich u.a für PGM5)
www Verzeichnis (standard verzeichnis meines webservers)
Scripte Verzeichnis (hier habe ich alle meine *.sh Scripte abgelegt)

Zusätzlich bietet das Script die Option das Backupverzeichnis in ein
tar-Verzeichnis zu packen und dieses auf einen externen FTP Server zu
laden.

Vielleicht kann es ja auch jemand brauchen ;=)
Gruss Dani



Inhalt des backup-fhem.sh:
#!/bin/bash
#FHEM-5.1-Backup-Script
#Version 0.87
#last update: 22.10.2011
#
#
#***********************************************************************************************
#***********************************************************************************************
#HIER DAS ZIELVERZEICHNIS (DESTINATION) DES BACKUP ANGEBEN, STANDARD
IST DAS USER HOME VERZEICHNIS.
#
#Backup-Verzeichnis (Zielverzeichnis des FHEM-Backup)
#Zum Beispiel nach /root/FHEM-Backup
fhem_backupdir="/$HOME/FHEM-Backup";
#***********************************************************************************************
#
#AENDERUNGEN DER FHEM 5.1 VERZEICHNISSE
#Angabe der Pfade von Verzeichnissen mit Dateien die gesichert werden
sollen (Standardpfade aus FHEM 5.1). Wenn die Standardpfade verändert
wurden, können sie hier entsprechend angepasst werden.
#WENN DAS ENTSPRECHENDE VERZEICHNIS NICHT GESICHERT WERDEN SOLL,
EINFACH DAS "Y" DURCH "N" ERSETZEN.
#
fhem_log_save="Y";
fhem_mod_save="Y";
fhem_scr_log="/var/log/fhem";
fhem_scr_mod="/usr/share/fhem";
#***********************************************************************************************
#
#WEITERE VERZEICHNISSE DER FHEM FRONTEND'S, DIE GESICHERT WERDEN
SOLLEN
#WENN DAS ENTSPRECHENDE VERZEICHNIS NICHT GESICHERT WERDEN SOLL,
EINFACH DAS "Y" DURCH "N" ERSETZEN.
fhem_www_save="Y";
fhem_scripte_save="Y";
fhem_cgibin_save="Y";
fhem_scr_www="/var/www";
fhem_scr_scripte="/usr/local/bin";
fhem_scr_cgibin="/usr/lib/cgi-bin";
#***********************************************************************************************
#
#WEITERE EINZELNE DATEIEN DIE GESICHERT WERDEN SOLLEN
#WENN DIE ENTSPRECHENDE DATEI NICHT GESICHERT WERDEN SOLL, EINFACH DAS
"Y" DURCH "N" ERSETZEN.
#FHEM.cfg Datei
fhem_cfg_save="Y";
fhem_cfg_name="fhem.cfg";
fhem_cfg_scr="/etc";
#
#
#FHEM.PL Datei
fhem_pl_save="Y";
fhem_pl_name="fhem.pl";
fhem_pl_scr="/usr/bin";
#***********************************************************************************************
#
#SOLL ZUSAETZLICH EINE ARCHIV_DATEI ERSTELLT WERDEN UND DIESE AUF
EINEN FTP HOST GESICHERT WERDEN?
fhem_ftp_save="Y";
ftp_host="ftphost.com";
ftp_username="deinusername";
ftp_password="deinpasswort";
ftp_dest_dir="html/fhembackup";
#***********************************************************************************************
#
#
#
#***********AB HIER NICHTS MEHR AENDERN!!!
******************************************************
#Verzeichnisse im Backupordner
fhem_backupsubdir="Backup`date +-%Y-%m-%d_%H-%M-%S`";
fhem_dest_log="log";
fhem_dest_mod="mod";
fhem_dest_www="www";
fhem_dest_scripte="scripte";
fhem_dest_cgibin="cgi-bin";
#
#Unterverzeichnis erstellen mit Datum und Zeit des Backups
mkdir -p $fhem_backupdir
cd $fhem_backupdir
mkdir $fhem_backupsubdir/
cd $fhem_backupsubdir/
#
#Logs sichern
if [ $fhem_log_save = "Y" ] ; then
   mkdir $fhem_dest_log/
   cp -p -r -f /$fhem_scr_log/ /$fhem_backupdir/$fhem_backupsubdir/
$fhem_dest_log
fi
#
#Module sichern
if [ $fhem_mod_save = "Y" ] ; then
   mkdir $fhem_dest_mod/
   cp -p -r -f /$fhem_scr_mod/ /$fhem_backupdir/$fhem_backupsubdir/
$fhem_dest_mod
fi
#
#Webfrontends sichern
if [ $fhem_www_save = "Y" ] ; then
   mkdir $fhem_dest_www/
   cp -p -r -f /$fhem_scr_www/ /$fhem_backupdir/$fhem_backupsubdir/
$fhem_dest_www
fi
#
#Scripte sichern
if [ $fhem_scripte_save = "Y" ] ; then
   mkdir $fhem_dest_scripte/
   cp -p -r -f /$fhem_scr_scripte/ /$fhem_backupdir/$fhem_backupsubdir/
$fhem_dest_scripte
fi
#
#cgi-bin sichern
if [ $fhem_cgibin_save = "Y" ] ; then
   mkdir $fhem_dest_cgibin/
   cp -p -r -f /$fhem_scr_cgibin/ /$fhem_backupdir/$fhem_backupsubdir/
$fhem_dest_cgibin
fi
#
#fhem.cfg sichern
if [ $fhem_cfg_save = "Y" ] ; then
   cp -p -r -f /$fhem_cfg_scr/$fhem_cfg_name /$fhem_backupdir/
$fhem_backupsubdir
fi
#
#fhem.pl sichern
if [ $fhem_pl_save = "Y" ] ; then
   cp -p -r -f /$fhem_pl_scr/$fhem_pl_name /$fhem_backupdir/
$fhem_backupsubdir
fi
#archiv erstellen und auf FTP Host sichern
if [ $fhem_ftp_save = "Y" ] ; then
   tar -czvf fhem-$fhem_backupsubdir.tar.gz /$fhem_backupdir/
$fhem_backupsubdir
   cd $fhem_backupdir/$fhem_backupsubdir
   ftp -n $ftp_host <   quote USER $ftp_username
   quote PASS $ftp_password
   prompt off
   binary
   cd $ftp_dest_dir
   put fhem-$fhem_backupsubdir.tar.gz
   quit
END_SCRIPT
rm $fhem_backupdir/$fhem_backupsubdir/fhem-$fhem_backupsubdir.tar.gz
fi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Hallo!

Habe zur Zeit Fhem auf Firtzbox7170 am laufen aber mehr schlecht als recht,
fritzi steigt öfters aus;-), nun wollte ich auf so einen kleinen Server
wechseln mit debian oder ubuntu habe auf beiden schon Fhem zum laufen
gebracht zum Test zweck.
Nun wollte ich fragen ob ich meine ganzen Einstellungen  von der Fritzbox
auf Linux per backup/export/import übertragen könnte???
Mfg Ewies

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

rudolfkoenig

                                                   

> Nun wollte ich fragen ob ich meine ganzen Einstellungen  von der Fritzbox
> auf Linux per backup/export/import übertragen könnte???

Import/export gibt es nicht, aber man kann es mit etwas kopieren und editieren
problemlos durchfuehren.

Die Konfiguration liegt in fhem.cfg, die aktuellen Geraete-Stati in der Datei
fhem.state, und alle logs im log Verzeichnis, diese Dinger sind mitzunehmen.

In fhem.cfg muss man alle Pfade anpassen, oder man installiert fhem auf dem
neuen Geraet aehnlich wie auf dem Fritzbox: da sind die Pfade (bis auf
/dev/...) relativ zum Startverzeichnis. Das .deb Paket verwendet dagegen eine
andere, im Vergleich deutlich komplexere Verzeichnisstruktur. Wenn man fhem via
.tar.gz installiert, dann kann man diese Pfade am Anfang der Makefile
spezifizieren.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com