updatefhem - backup ausweiten / auslagern
296 views
Skip to first unread message
Martin Fischer
May 24, 2012, 7:45:29 PM5/24/12
to fhem-de...@googlegroups.com
==> backup ausweiten:
das "alte" <updatefhem backup> hat lediglich $modpath/FHEM gesichert. durch
das housekeeping habe ich nun noch $modpath/www hinzugenommen. und da ich
gerade in spendierlaune war ;-) habe ich noch $attr{global}{configfile} ins
archiv mit aufgenommen. da auch ich viel mit include arbeite, war mir bewusst,
das es noch eine baustelle ist.
es wird user geben, die nutzen kein include, dann ist es ok. dann wird es
welche geben, die packen alle includes in eine flache struktur. dann wird es
user geben (so wie mich) die haben eine gewisse struktur unterhalb von
/etc/fhem:
fhem.conf
include/01_iodevices.cfg
include/02_web.cfg
include/09_dummy.cfg
include/10_locations.cfg
include/50_misc.cfg
include/80_structure.cfg
include/99_autocreate.cfg
include/location/DG.sp.cfg
include/location/EG.bz.cfg
include/location/EG.ez.cfg
include/location/...
und andere haben ihre includes womöglich noch weiter / anders strukturiert.
um nun die config zu sichern kann man zwar die einzelnen files auf include
parsen und dann die files mit aufnehmen, das heisst aber auch, dass das archiv
inhaltlich die ganze verzeichnisstruktur mit aufnehmen muss. das gilt dann
auch für FHEM und www.
und dabei kommt dann gleich die nächste baustelle: was machen wir mit
$attr{global}{statefile} $attr{global}{logfile} und logfiles innerhalb von
define sowie fhem.pl (um mal MANDIR und DOCDIR aussen vor zu lassen)?
wir nähern uns dann langsam einem fullbackup. allein mein /var/log/fhem
beträgt 3.2G (ja, ich weiss: messi ;-) )
oder neben FHEM und www noch fhem.pl, $attr{global}{statefile} und
$attr{global}{configfile} inkl. den includes sichern?
oder "back to the roots" und nur das sichern, was über updatefhem auch bezogen
wird? die sicherung der genannten files dann wieder in die verantwortung des
users legen?
anregungen / ideen?
==> backup von updatefhem auslagern:
je nach umfang / aufwand backup komplett von updatefhem als eigenständigen
command auslagern und mit einem restore ergänzen? so das man ein rollback des
updatefhem durchführen kann. was ist dann aber mit evtl. veränderten werten
nach einem update im statefile?
anregungen / ideen?
das "alte" <updatefhem backup> hat lediglich $modpath/FHEM gesichert. durch
das housekeeping habe ich nun noch $modpath/www hinzugenommen. und da ich
gerade in spendierlaune war ;-) habe ich noch $attr{global}{configfile} ins
archiv mit aufgenommen. da auch ich viel mit include arbeite, war mir bewusst,
das es noch eine baustelle ist.
es wird user geben, die nutzen kein include, dann ist es ok. dann wird es
welche geben, die packen alle includes in eine flache struktur. dann wird es
user geben (so wie mich) die haben eine gewisse struktur unterhalb von
/etc/fhem:
fhem.conf
include/01_iodevices.cfg
include/02_web.cfg
include/09_dummy.cfg
include/10_locations.cfg
include/50_misc.cfg
include/80_structure.cfg
include/99_autocreate.cfg
include/location/DG.sp.cfg
include/location/EG.bz.cfg
include/location/EG.ez.cfg
include/location/...
und andere haben ihre includes womöglich noch weiter / anders strukturiert.
um nun die config zu sichern kann man zwar die einzelnen files auf include
parsen und dann die files mit aufnehmen, das heisst aber auch, dass das archiv
inhaltlich die ganze verzeichnisstruktur mit aufnehmen muss. das gilt dann
auch für FHEM und www.
und dabei kommt dann gleich die nächste baustelle: was machen wir mit
$attr{global}{statefile} $attr{global}{logfile} und logfiles innerhalb von
define sowie fhem.pl (um mal MANDIR und DOCDIR aussen vor zu lassen)?
wir nähern uns dann langsam einem fullbackup. allein mein /var/log/fhem
beträgt 3.2G (ja, ich weiss: messi ;-) )
oder neben FHEM und www noch fhem.pl, $attr{global}{statefile} und
$attr{global}{configfile} inkl. den includes sichern?
oder "back to the roots" und nur das sichern, was über updatefhem auch bezogen
wird? die sicherung der genannten files dann wieder in die verantwortung des
users legen?
anregungen / ideen?
==> backup von updatefhem auslagern:
je nach umfang / aufwand backup komplett von updatefhem als eigenständigen
command auslagern und mit einem restore ergänzen? so das man ein rollback des
updatefhem durchführen kann. was ist dann aber mit evtl. veränderten werten
nach einem update im statefile?
anregungen / ideen?
Rudolf Koenig
May 25, 2012, 3:34:07 AM5/25/12
to fhem-de...@googlegroups.com
> anregungen / ideen?
Auf dem FB7390/FB7270 ist es einfach: da ist alles in einem Verzeichnis, und
die Installation kopiert es einfach zur Seite, wenn es merkt, dass da was altes
vorhanden war. Ich fuerchte nur, dass man diese Struktur nicht fuer alle anderen
vorschreiben kann.
Apropos Installation FB7390: da ist das backup _neben_ dem ganzen fhem
Verzeichnis, und nicht da drin. Wenn der user ein update backup durchfuhrt,
dann wird zusaetzlich ein Verzeichnis _im_ fhem angelegt, das ist noch nicht
sehr konsequent. Das ist auch kein Vorwurf, sonder ein TODO, fuer wen auch
immer :)
> ==> backup von updatefhem auslagern:
Gerne.
Auf dem FB7390/FB7270 ist es einfach: da ist alles in einem Verzeichnis, und
die Installation kopiert es einfach zur Seite, wenn es merkt, dass da was altes
vorhanden war. Ich fuerchte nur, dass man diese Struktur nicht fuer alle anderen
vorschreiben kann.
Apropos Installation FB7390: da ist das backup _neben_ dem ganzen fhem
Verzeichnis, und nicht da drin. Wenn der user ein update backup durchfuhrt,
dann wird zusaetzlich ein Verzeichnis _im_ fhem angelegt, das ist noch nicht
sehr konsequent. Das ist auch kein Vorwurf, sonder ein TODO, fuer wen auch
immer :)
> ==> backup von updatefhem auslagern:
Martin Fischer
May 25, 2012, 4:46:22 PM5/25/12
to fhem-de...@googlegroups.com
Am Freitag, 25. Mai 2012, 09:34:07 schrieb Rudolf Koenig:
> > anregungen / ideen?
>
> Auf dem FB7390/FB7270 ist es einfach: da ist alles in einem Verzeichnis, und
> die Installation kopiert es einfach zur Seite, wenn es merkt, dass da was
> altes vorhanden war. Ich fuerchte nur, dass man diese Struktur nicht fuer
> alle anderen vorschreiben kann.
kannst du mir mal ein fertiges fb7390'er archiv senden? ist das richtig, das
> > anregungen / ideen?
>
> Auf dem FB7390/FB7270 ist es einfach: da ist alles in einem Verzeichnis, und
> die Installation kopiert es einfach zur Seite, wenn es merkt, dass da was
> altes vorhanden war. Ich fuerchte nur, dass man diese Struktur nicht fuer
> alle anderen vorschreiben kann.
nur du das image erstellen kannst? bei mir hagelts nur fehler:
tar: ../../priv/fritzbox7390_template.tar: Kann open nicht ausführen: Datei
oder Verzeichnis nicht gefunden
tar: Error is not recoverable: exiting now
cd: 13: can't cd to var
...
ich habe die fhem und fritzbox geschichte bisher komplett ausgeblendet. aber
für das backup und evtl. für das updatefhem wäre ein testarchiv nicht
verkehrt. modpath ist dann das eine oben genannte verzeichnis? ist da dann
alles drin, also fhem.pl, modules, pgm2?
wir kommen wohl nicht um ein testarchiv für mich herum ;-)
> Apropos Installation FB7390: da ist das backup _neben_ dem ganzen fhem
> Verzeichnis, und nicht da drin. Wenn der user ein update backup durchfuhrt,
> dann wird zusaetzlich ein Verzeichnis _im_ fhem angelegt, das ist noch nicht
> sehr konsequent. Das ist auch kein Vorwurf, sonder ein TODO, fuer wen auch
> immer :)
>
> > ==> backup von updatefhem auslagern:
> Gerne.
gleich lieber nur update?) und die backup geschichte. was ich jedoch für
sinnvoll erachte, wäre wenn beides bestandteil von 5.3 wird. will damit sagen,
das du 5.3 dann nicht gleich innerhalb der nächsten 2-4 wochen releasen
willst, da ich nicht weiss wie schnell ich das durch kriege.
wenn wir <updatefhem> auch gleich in <update> umbenennen würden, kommt mir
gerade in den sinn, dann könnte man in fhem-users einen aufruf starten, das
zur zeit sehr stark an diesen beiden befehlen <update> und <backup|restore>
gearbeitet wird. <updatefhem> wird erstmal für diese übergangszeit so
beibehalten wie es aktuell aus dem svn ausgeliefert wird und erfährt höchstens
noch dringende bugfixes. dann könnten wir andere extrem experimentierfreudige
user "einladen" mit allen _unwegsamkeiten_ in der entwicklungsphase <update>
und <backup|restore> zu testen. ohne garantie und auf verlust über die
kontrolle aller geräte ;-)
dann werde ich mir nun wohl mal ein gerüst für <backup> bauen ;-)
any comments?
Martin Fischer
May 25, 2012, 11:19:34 PM5/25/12
to fhem-de...@googlegroups.com
Am Freitag, 25. Mai 2012, 22:46:22 schrieb Martin Fischer:
> [...]
dies ist noch eine testversion! es funktioniert aus meiner sicht alles, bis
auf die geschichte mit modules{Global}{AttrList} nach einem save.
vielleicht erstmal noch nicht über filetimes.txt verteilen.
commandref.html fehlt noch.. liefere ich nach aber evtl. erst am dienstag /
mittwoch, da ich ab morgen unterwegs bin.
es gibt zwei globale attribute:
==> backupdir
unterstützt nun relative, so wie absolute pfade. bei relativ, wird immer von
$modpath ausgegangen und absolute pfade sind halt absolut. mit dieser
behandlung sollte dann auch das mit der fritzbox ( von wegen backup im selben
pfad wie $modpath ) beheben können.
==> backupsymlinks
per default / bzw. nicht gesetzt = no
ist $attr{global}{backupsymlinks} != no, dann werden symlinks mit archiviert
es werden _ALLE_ configfiles, also auch alle includes mit gesichert, sowie das
statefile und _alles_ aus $modpath exklusive dem backupdir, sofern es dort
liegt. was (noch) nicht geht: liegt das backupdir in einem unterverzeichnis im
$modpath dann wird es auch gesichert.
das archiv enthält alle pfade und kann somit direkt im system mittels tar -C /
xzf <file> das komplette backup wieder herstellen.
dadurch habe ich allerdings die blöde ausgabe beim packen, das tar die
führenden "/" entfernt.. lässt sich so nicht unterdrücken.
BITTE TESTEN! und feedback geben... @rudi: bitte auch nochmal die
modules{Global}{AttrList} geschichte prüfen. wenn es wie gedacht nicht geht
muss ich fhem.pl noch anpassen.
so.. mein knapp 4 monate alter sohn wird gerade wach und ich geh jetzt
schlafen ;-)
martin
p.s.: das backup in updatefhem ist noch drin. schmeiss ich erst raus, wenn
backup getestet wurde, bzw. wenn ich <update> ferig habe.
derweil können wir ja schon mal überlegen, wie wir die user nun vollends
verwirren und ihnen mitteilen, das updatefhem nicht mehr geht und dafür
<update> und <backup> neu sind ;-)
> [...]
> dann werde ich mir nun wohl mal ein gerüst für <backup> bauen ;-)
habe fertig und eingecheckt.
dies ist noch eine testversion! es funktioniert aus meiner sicht alles, bis
auf die geschichte mit modules{Global}{AttrList} nach einem save.
vielleicht erstmal noch nicht über filetimes.txt verteilen.
commandref.html fehlt noch.. liefere ich nach aber evtl. erst am dienstag /
mittwoch, da ich ab morgen unterwegs bin.
es gibt zwei globale attribute:
==> backupdir
unterstützt nun relative, so wie absolute pfade. bei relativ, wird immer von
$modpath ausgegangen und absolute pfade sind halt absolut. mit dieser
behandlung sollte dann auch das mit der fritzbox ( von wegen backup im selben
pfad wie $modpath ) beheben können.
==> backupsymlinks
per default / bzw. nicht gesetzt = no
ist $attr{global}{backupsymlinks} != no, dann werden symlinks mit archiviert
es werden _ALLE_ configfiles, also auch alle includes mit gesichert, sowie das
statefile und _alles_ aus $modpath exklusive dem backupdir, sofern es dort
liegt. was (noch) nicht geht: liegt das backupdir in einem unterverzeichnis im
$modpath dann wird es auch gesichert.
das archiv enthält alle pfade und kann somit direkt im system mittels tar -C /
xzf <file> das komplette backup wieder herstellen.
dadurch habe ich allerdings die blöde ausgabe beim packen, das tar die
führenden "/" entfernt.. lässt sich so nicht unterdrücken.
BITTE TESTEN! und feedback geben... @rudi: bitte auch nochmal die
modules{Global}{AttrList} geschichte prüfen. wenn es wie gedacht nicht geht
muss ich fhem.pl noch anpassen.
so.. mein knapp 4 monate alter sohn wird gerade wach und ich geh jetzt
schlafen ;-)
martin
p.s.: das backup in updatefhem ist noch drin. schmeiss ich erst raus, wenn
backup getestet wurde, bzw. wenn ich <update> ferig habe.
derweil können wir ja schon mal überlegen, wie wir die user nun vollends
verwirren und ihnen mitteilen, das updatefhem nicht mehr geht und dafür
<update> und <backup> neu sind ;-)
Rudolf Koenig
May 26, 2012, 4:40:00 AM5/26/12
to fhem-de...@googlegroups.com
> kannst du mir mal ein fertiges fb7390'er archiv senden?
Das darfst Du selber von fhem.de oder AVM herunterladen. Es ist ein tar file,
auch wenn nicht auf .tar endet.
> tar: ../../priv/fritzbox7390_template.tar: Kann open nicht ausf�hren: Datei
> oder Verzeichnis nicht gefunden
Bitte das fb7390-er image von fhem.de unter diesem Namen hinkopieren.
> wenn wir <updatefhem> auch gleich in <update> umbenennen w�rden,
Passt mir unter diesem Namen nicht: in fhem kann man Befehle auch abgekeurzt
eingeben: update ruft z.Zt updatefhem auf. Ich moechte dass die Benutzer
wissen, was sie aufrufen. Sonst gerne.
PanTau
May 30, 2012, 4:36:25 PM5/30/12
to fhem-de...@googlegroups.com
>dadurch habe ich allerdings die blöde ausgabe beim packen, das tar die
>führenden "/" entfernt.. lässt sich so nicht unterdrücken.
Finde es sehr gut, daß Du wieder zurück zum Packen von absoluten Verzeichnissen gegangen bist.>führenden "/" entfernt.. lässt sich so nicht unterdrücken.
Das tar -C <verz> hat, glaube ich viele Probleme (in unserer Diskussion) verursacht.
Kannst Du tar nicht mit angehängtem >>/dev/null 2>&1 aufrufen? Zugegeben, dann sind alle Fehlermeldungen weg.
Sonst eben /dev/null durch <datei> ersetzen, und abhängig vom tar Rückgabewert anzeigen.
Ich mein ja nur, weil Dich die "blöde Ausgabe" offensichtlich _wirklich_ stört :-)
> vielleicht erstmal noch nicht über filetimes.txt verteilen.
> BITTE TESTEN! und feedback geben...
"backup" aufgerufen.
=> sieht ziemlich gut aus, allerdings sind bei mir alle "includes" eh unter <modpath> und das backup sieht aus wie ein Vollbackup von <modpath> ohne backupdir.
Was bei mir aber paßt.
fhem.save leigt bei mir unter /var/tmp, wurde auch gesichert => gut
keine logfiles gesichert => gut ! (bin auch messi :-))
Unlogisch finde ich nur, daß fhem.cfg _zusätzlich_ noch im root des tar archives liegt....
Da gehört es nicht hin, sondern an den Ort wo es eben liegt (da liegt es bei mir auch noch).
Kann man den Commandozeilenaufruf von "fhem.pl pfad_zu_cfg" nicht auch irgendwo abfragen?
>es werden _ALLE_ configfiles, also auch alle includes mit gesichert, sowie das
>statefile und _alles_ aus $modpath exklusive dem backupdir, sofern es dort
>liegt. was (noch) nicht geht: liegt das backupdir in einem unterverzeichnis im
>$modpath dann wird es auch gesichert.
Fakt ist, ich habe attr global modpath /home/FHZ/fhem definiert, backupdir ist nicht definiert, liegt aber unter modpath/backup (der Default halt)
und wird bei mir nicht gesichert.
backupsymlinks weigere ich mich zu testen, nachdem Ihr mir das "-h" bei tar geklaut habt und ich alle Symlinks in meiner FHEM Installation entfernt habe ..... :-)
Martin Fischer
May 31, 2012, 2:03:36 PM5/31/12
to fhem-de...@googlegroups.com
Am Samstag, 26. Mai 2012, 10:40:00 schrieb Rudolf Koenig:
> > kannst du mir mal ein fertiges fb7390'er archiv senden?
>
> Das darfst Du selber von fhem.de oder AVM herunterladen. Es ist ein tar
> file, auch wenn nicht auf .tar endet.
ok.. wie gesagt: ich hatte mich vorher noch nicht mit fritzbox beschäftigt.
> > kannst du mir mal ein fertiges fb7390'er archiv senden?
>
> Das darfst Du selber von fhem.de oder AVM herunterladen. Es ist ein tar
> file, auch wenn nicht auf .tar endet.
schaue ich mir mal an.
> [...]
> > wenn wir <updatefhem> auch gleich in <update> umbenennen würden,
>
> Passt mir unter diesem Namen nicht: in fhem kann man Befehle auch abgekeurzt
> eingeben: update ruft z.Zt updatefhem auf. Ich moechte dass die Benutzer
> wissen, was sie aufrufen. Sonst gerne.
ich glaube, das ich mich da evtl. falsch ausgedrückt habe oder du es falsch
> Passt mir unter diesem Namen nicht: in fhem kann man Befehle auch abgekeurzt
> eingeben: update ruft z.Zt updatefhem auf. Ich moechte dass die Benutzer
> wissen, was sie aufrufen. Sonst gerne.
verstanden hast ;-)
der befehl 'update' würde nach meiner vorstellung 'updatefhem' _komplett_
ablösen und dann gäbe es auch keine missverständnisse bei abkürzungen.
'updatefhem' suggeriert, das fhem aktualisiert wird. hinzu kommt: wenn ich
heute ein fhem _ohne_ pgm2 installiert habe, dann habe ich pgm2 nach einem
'updatefhem' automatisch auf der platte (obwohl ich mich ja vorher explizit
dagegen entschieden habe).
würden wir den befehl jedoch in 'update' umbenennen, dann könnten wir über
parameter steuern, _was_ aktualisiert werden soll:
'update svn install full' - aktualisiert fhem und pgm2 aus svn
'update svn install pgm2' - aktualisiert nur pgm2 aus dem svn
'update stable install fhem' - aktualisiert alle fhem-module inkl. fhem.pl aus
stable
'update svn install <file>' - aktualisiert nur <file> aus svn
man könnte auch dann später auch noch andere webguis o.ä. getrennt updaten.
auch könnten wir noch ein globales attribut hinzufügen: <excludeupdate> wo
dann z.b. eine kommaseparierte liste von dateien aufgeführt werden, die bei
einem update _immer_ ausgelassen werden. wäre z.b. hilfreich, wenn jemand
eigene änderungen an einem modul vorgenommen hat und das nicht durch ein
update überschreiben lassen will.
Martin Fischer
May 31, 2012, 2:21:48 PM5/31/12
to fhem-de...@googlegroups.com
hallo peter,
Am Mittwoch, 30. Mai 2012, 13:36:25 schrieb PanTau:
> >dadurch habe ich allerdings die blöde ausgabe beim packen, das tar die
> >führenden "/" entfernt.. lässt sich so nicht unterdrücken.
>
> Finde es sehr gut, daß Du wieder zurück zum Packen von absoluten
> Verzeichnissen gegangen bist.
was man nicht alles fürs gemeinwohl tut ;-)
> [...]
ins nirvana zu schicken, will ich nicht und eine extra datei anlegen und diese
ggf. noch parsen, könnte weitere fehler nach sich ziehen.. dann "lebe" ich nun
halt mit der meldung von tar ;-)
> > vielleicht erstmal noch nicht über filetimes.txt verteilen.
>
> habe ich aber so bekommen ....
ok.. dann wirst du aber beim starten eine fehlermeldung erhalten, da wie
geschrieben, das globale attribut in fhem.pl noch nicht bekannt ist. dann
werde ich das jetzt wohl mal nachpflegen..
> > BITTE TESTEN! und feedback geben...
>
> [...]
> [...]
unter /etc
> Da gehört es nicht hin, sondern an den Ort wo es eben liegt (da liegt es
> bei mir auch noch).
wo liegt es denn? das geht aus deinen zeilen nicht hervor.
jepp, was auch gemacht wird:
my $configfile = (!defined($attr{global}{configfile}) ? undef : $attr{global}
{configfile});
was steht bei dir unter 'list global' bei 'configfile'?
> [...]
es ja ok. ich will ja kein backup der backups im backup ;-)
allerdings verhielt es sich bei mir anders. vielleicht liegt es aber auch
daran, das du sowie so eine komplett andere struktur als der standard
verwendest und ich dabei was übersehe..
> backupsymlinks weigere ich mich zu testen, nachdem Ihr mir das "-h" bei tar
> geklaut habt und ich alle Symlinks in meiner FHEM Installation entfernt
> habe ..... :-)
;-) dat geht abba ;-) bin ich mir sicher ;-)
gruss martin
Am Mittwoch, 30. Mai 2012, 13:36:25 schrieb PanTau:
> >dadurch habe ich allerdings die blöde ausgabe beim packen, das tar die
> >führenden "/" entfernt.. lässt sich so nicht unterdrücken.
>
> Finde es sehr gut, daß Du wieder zurück zum Packen von absoluten
> Verzeichnissen gegangen bist.
> [...]
> Kannst Du tar nicht mit angehängtem >>/dev/null 2>&1 aufrufen? Zugegeben,
> dann sind alle Fehlermeldungen weg.
> Sonst eben /dev/null durch <datei> ersetzen, und abhängig vom tar
> Rückgabewert anzeigen.
> Ich mein ja nur, weil Dich die "blöde Ausgabe" offensichtlich _wirklich_
> stört :-)
nenene :-) dann lieber diese _blöde_ ausgabe wegen der führenden "/". alles
> dann sind alle Fehlermeldungen weg.
> Sonst eben /dev/null durch <datei> ersetzen, und abhängig vom tar
> Rückgabewert anzeigen.
> Ich mein ja nur, weil Dich die "blöde Ausgabe" offensichtlich _wirklich_
> stört :-)
ins nirvana zu schicken, will ich nicht und eine extra datei anlegen und diese
ggf. noch parsen, könnte weitere fehler nach sich ziehen.. dann "lebe" ich nun
halt mit der meldung von tar ;-)
> > vielleicht erstmal noch nicht über filetimes.txt verteilen.
>
> habe ich aber so bekommen ....
geschrieben, das globale attribut in fhem.pl noch nicht bekannt ist. dann
werde ich das jetzt wohl mal nachpflegen..
> > BITTE TESTEN! und feedback geben...
>
> => sieht ziemlich gut aus, allerdings sind bei mir alle "includes" eh unter
> <modpath> und das backup sieht aus wie ein Vollbackup von <modpath> ohne
> backupdir.
> Was bei mir aber paßt.
schön..
> <modpath> und das backup sieht aus wie ein Vollbackup von <modpath> ohne
> backupdir.
> Was bei mir aber paßt.
> [...]
> Unlogisch finde ich nur, daß fhem.cfg _zusätzlich_ noch im root des tar
> archives liegt....
muss ich mir ansehen. bei mir liegt es sowohl im system als auch im archiv
> archives liegt....
unter /etc
> Da gehört es nicht hin, sondern an den Ort wo es eben liegt (da liegt es
> bei mir auch noch).
jepp, was auch gemacht wird:
my $configfile = (!defined($attr{global}{configfile}) ? undef : $attr{global}
{configfile});
was steht bei dir unter 'list global' bei 'configfile'?
> [...]
> Den Satz bezgl Behandlung backupdir verstehe ich nicht?
> Fakt ist, ich habe attr global modpath /home/FHZ/fhem definiert, backupdir
> ist nicht definiert, liegt aber unter modpath/backup (der Default halt)
> und wird bei mir nicht gesichert.
muss ich mir ansehen. wenn es sich so verhält wie du es beschreibst, dann ist
> Fakt ist, ich habe attr global modpath /home/FHZ/fhem definiert, backupdir
> ist nicht definiert, liegt aber unter modpath/backup (der Default halt)
> und wird bei mir nicht gesichert.
es ja ok. ich will ja kein backup der backups im backup ;-)
allerdings verhielt es sich bei mir anders. vielleicht liegt es aber auch
daran, das du sowie so eine komplett andere struktur als der standard
verwendest und ich dabei was übersehe..
> backupsymlinks weigere ich mich zu testen, nachdem Ihr mir das "-h" bei tar
> geklaut habt und ich alle Symlinks in meiner FHEM Installation entfernt
> habe ..... :-)
gruss martin
Rudolf Koenig
Jun 1, 2012, 3:24:08 AM6/1/12
to fhem-de...@googlegroups.com
> der befehl 'update' w�rde nach meiner vorstellung 'updatefhem' _komplett_
> abl�sen und dann g�be es auch keine missverst�ndnisse bei abk�rzungen.
Ok, aber dann sollte update waehrend der parallel-existenz auch anders heissen.
> hinzu kommt: wenn ich heute ein fhem _ohne_ pgm2 installiert habe, dann habe
> ich pgm2 nach einem 'updatefhem' automatisch auf der platte (obwohl ich mich
> ja vorher explizit dagegen entschieden habe).
Dieser Punkt ist berechtigt, sehe aber nicht, was es mit der "update vs
updatefhem" Diskussion zu tun hat
> 'update svn install full' - aktualisiert fhem und pgm2 aus svn
...
Koennen wir "install" rauslassen? Ich haette gerne ein updatefhem was lieber
nicht perfekt, dafuer aber einfach zu verstehen ist, als andersherum.
> abl�sen und dann g�be es auch keine missverst�ndnisse bei abk�rzungen.
Ok, aber dann sollte update waehrend der parallel-existenz auch anders heissen.
> hinzu kommt: wenn ich heute ein fhem _ohne_ pgm2 installiert habe, dann habe
> ich pgm2 nach einem 'updatefhem' automatisch auf der platte (obwohl ich mich
> ja vorher explizit dagegen entschieden habe).
updatefhem" Diskussion zu tun hat
> 'update svn install full' - aktualisiert fhem und pgm2 aus svn
Koennen wir "install" rauslassen? Ich haette gerne ein updatefhem was lieber
nicht perfekt, dafuer aber einfach zu verstehen ist, als andersherum.
Martin Fischer
Jun 1, 2012, 8:41:42 AM6/1/12
to fhem-de...@googlegroups.com
Am Freitag, 1. Juni 2012, 09:24:08 schrieb Rudolf Koenig:
> > der befehl 'update' würde nach meiner vorstellung 'updatefhem' _komplett_
> > ablösen und dann gäbe es auch keine missverständnisse bei abkürzungen.
>
> > der befehl 'update' würde nach meiner vorstellung 'updatefhem' _komplett_
> > ablösen und dann gäbe es auch keine missverständnisse bei abkürzungen.
>
> Ok, aber dann sollte update waehrend der parallel-existenz auch anders
> heissen.
aus meiner sicht wird es keine parallel-existenz geben.
> heissen.
anwender führt updatefhem durch und danach gibt es nur noch update.
> > hinzu kommt: wenn ich heute ein fhem _ohne_ pgm2 installiert habe, dann
> > habe ich pgm2 nach einem 'updatefhem' automatisch auf der platte (obwohl
> > ich mich ja vorher explizit dagegen entschieden habe).
>
> Dieser Punkt ist berechtigt, sehe aber nicht, was es mit der "update vs
> updatefhem" Diskussion zu tun hat
> > 'update svn install full' - aktualisiert fhem und pgm2 aus svn
> ...
> Koennen wir "install" rauslassen? Ich haette gerne ein updatefhem was lieber
> nicht perfekt, dafuer aber einfach zu verstehen ist, als andersherum.
heute losgegen wollte..
ich werde in einem neuen thread versuchen, die bisherigen ergebnisse mal
zusammen zu tragen.
Reply all
Reply to author
Forward
0 new messages