Hallo @all,
über das SVN wird ab sofort eine angepasste Version von updatefhem
ausgeliefert. Hintergrund ist das mittlerweile unübersichtlich gewordene
Verzeichnis $modpath/FHEM. Bei der Installation von pgm2 wurden bisher alle
Dateien (.png, .gplot, .css, usw.) ebenfalls in $modpath/FHEM abgelegt.
Künftig soll $modpath/FHEM "sauber" gehalten werden, also nur noch reine
Modul-Dateien (*.pm) enthalten.
Das neue updatefhem richtet bei Bedarf (updatefhem housekeeping) die neue
Verzeichnisstruktur www/pgm2 unter $modpath ein. Möchte man die alte Struktur
beibehalten, dann ist updatefhem mit dem Argument
aufzurufen.
Für weitereführende Dokumentation verweise ich auf commadref.html. Im
folgenden habe ich den Auszug für updatefhem angehängt.
Wir (Rudi & ich) haben die neue Funktionen auf diversen OS geprüft. Soweit
sollte es keine Probleme bei der Umstellung geben.
Weiterhin viel Spass mit Fhem...
Gruß Martin
Auszug updatefhem aus commandref.html:
updatefhem [|| [] []|
[]]
Update the fhem modules and documentation from a nightly SVN checkout. For
this purpose fhem contacts http://fhem.de/fhemupdate, compares the stored
timestamps of the local files with the filelist on the server, and downloads
the files changed on the server. For all downloaded modules a reload will be
scheduled if the corresponding module is loaded.
Note: Since Version 5.3 a new directory structure is used by Fhem. The
WebInterface pgm2 is separated from modpath/FHEM directory. The directory
modpath/www/pgm2 is the new home of pgm2 and of its files. It is recommended
to update to the new structure via the arguments.
If is specified, then the complete FHEM directory (containing the
modules), the WebInterface pgm2 (if installed) and the config-file will be
saved into a .tar.gz file. The file is stored with a timestamp in the
modpath/backup directory or to a directory specified by the backupdir global
attribute.
Note: tar and gzip must be installed to use this feature.
If an explicit is given, then only this file will be downloaded.
If is specified, then updatefhem switch your Fhem installation
to the new directory structure for the pgm2 WebInterface. The old files are
archived like the argument and the new files are stored to
modpath/www/pgm2. None of the existing files of pgm2 in modpath/FHEM will be
deleted, but are no longer in use.
If you like to delete the no more needed files for pgm2 in modpath/FHEM, you
should call with the argument . All files of pgm2
are removed from modpath/FHEM and files like .*example.*, .gplot, .html .css,
.js, and .(gif|jpg|png|svg) are moved to modpath/www/pgm2.
If is specified, you could preserve the old directory structure.
All files of pgm2 are updated and stored in modpath/FHEM like the former
(before Fhem 5.3) updatefhem funktion. To update an explicit file to the old
structure append the file as .
Note: After running the housekeeping process, the argument is no
longer necessary and no more supported.
Notes:
If the main program (fhem.pl) is changed, a manual restart of fhem will be
necessary to apply the changes.
After running it is recommended to restart Fhem.
Attributes
backupdir
A folder where updatefhem will store the compressed backup file. Note:
this is a global attribute.
Example:
attr global backupdir /Volumes/BigHD
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo ihr Beiden,
bekomme folgende Fehlermeldung:
Something went wrong during backup:
sh: can't create ./backup/FHEM.2012-05-20_19:03:51.tar.gz: Invalid
argument
tar: short write
The operation was canceled. Please check manually!
Verzeichnis ./backup wurde angelegt, mit Schreibrechten.
Betreibe FHEM auf einer FB7170 mit Freetz und FHEM 5.2 aus dem Archiv
FB7270.
Danke Euch und herzliche Grüße
Jörg
On 20 Mai, 18:15, Martin Fischer
wrote:
> Hallo @all,
>
> über das SVN wird ab sofort eine angepasste Version von updatefhem
> ausgeliefert. Hintergrund ist das mittlerweile unübersichtlich gewordene
> Verzeichnis $modpath/FHEM. Bei der Installation von pgm2 wurden bisher alle
> Dateien (.png, .gplot, .css, usw.) ebenfalls in $modpath/FHEM abgelegt.
>
> Künftig soll $modpath/FHEM "sauber" gehalten werden, also nur noch reine
> Modul-Dateien (*.pm) enthalten.
>
> Das neue updatefhem richtet bei Bedarf (updatefhem housekeeping) die neue
> Verzeichnisstruktur www/pgm2 unter $modpath ein. Möchte man die alte Struktur
> beibehalten, dann ist updatefhem mit dem Argument aufzurufen.
>
> Für weitereführende Dokumentation verweise ich auf commadref.html. Im
> folgenden habe ich den Auszug für updatefhem angehängt.
>
> Wir (Rudi & ich) haben die neue Funktionen auf diversen OS geprüft. Soweit
> sollte es keine Probleme bei der Umstellung geben.
>
> Weiterhin viel Spass mit Fhem...
>
> Gruß Martin
>
> Auszug updatefhem aus commandref.html:
>
> updatefhem [|| [] []|
> []]
>
> Update the fhem modules and documentation from a nightly SVN checkout. For
> this purpose fhem contactshttp://fhem.de/fhemupdate, compares the stored
> timestamps of the local files with the filelist on the server, and downloads
> the files changed on the server. For all downloaded modules a reload will be
> scheduled if the corresponding module is loaded.
>
> Note: Since Version 5.3 a new directory structure is used by Fhem. The
> WebInterface pgm2 is separated from modpath/FHEM directory. The directory
> modpath/www/pgm2 is the new home of pgm2 and of its files. It is recommended
> to update to the new structure via the arguments.
>
> If is specified, then the complete FHEM directory (containing the
> modules), the WebInterface pgm2 (if installed) and the config-file will be
> saved into a .tar.gz file. The file is stored with a timestamp in the
> modpath/backup directory or to a directory specified by the backupdir global
> attribute.
> Note: tar and gzip must be installed to use this feature.
>
> If an explicit is given, then only this file will be downloaded.
>
> If is specified, then updatefhem switch your Fhem installation
> to the new directory structure for the pgm2 WebInterface. The old files are
> archived like the argument and the new files are stored to
> modpath/www/pgm2. None of the existing files of pgm2 in modpath/FHEM will be
> deleted, but are no longer in use.
> If you like to delete the no more needed files for pgm2 in modpath/FHEM, you
> should call with the argument . All files of pgm2
> are removed from modpath/FHEM and files like .*example.*, .gplot, .html .css,
> .js, and .(gif|jpg|png|svg) are moved to modpath/www/pgm2.
>
> If is specified, you could preserve the old directory structure.
> All files of pgm2 are updated and stored in modpath/FHEM like the former
> (before Fhem 5.3) updatefhem funktion. To update an explicit file to the old
> structure append the file as .
> Note: After running the housekeeping process, the argument is no
> longer necessary and no more supported.
>
> Notes:
>
> If the main program (fhem.pl) is changed, a manual restart of fhem will be
> necessary to apply the changes.
> After running it is recommended to restart Fhem.
>
> Attributes
>
> backupdir
> A folder where updatefhem will store the compressed backup file. Note:
> this is a global attribute.
> Example:
> attr global backupdir /Volumes/BigHD
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Jörg,
danke für die zeitnahe Rückmeldung!
Am Sonntag, 20. Mai 2012, 10:06:21 schrieb JoWiemann:
> bekomme folgende Fehlermeldung:
>
> Something went wrong during backup:
> sh: can't create ./backup/FHEM.2012-05-20_19:03:51.tar.gz: Invalid
> argument
> tar: short write
> The operation was canceled. Please check manually!
>
> Verzeichnis ./backup wurde angelegt, mit Schreibrechten.
>
> Betreibe FHEM auf einer FB7170 mit Freetz und FHEM 5.2 aus dem Archiv
> FB7270.
mangels Hardware: kannst Du bitte auf Deiner 7170 'tar --help' absetzen und
das Ergebnis hier posten? Und dabei gleich prüfen ob 'gzip' auf der FritzBox
vorhanden ist. Es scheint als ob es Probleme mit dem Tar auf der 7170 gibt.
Derweil sollte aber 'updatefhem preserve' funktionieren.
Gruß Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin,
hier die Ausgabe von tar help:
/var/mod/root # tar help
tar: invalid option -- e
BusyBox v1.12.4 (2011-03-19 10:21:51 CET) multi-call binary
Usage: tar -[czjxtvO] [-X FILE] [-f TARFILE] [-C DIR] [FILE(s)]...
Create, extract, or list files from a tar file
Options:
c Create
x Extract
t List
Archive format selection:
z Filter the archive through gzip
j Filter the archive through bzip2
File selection:
f Name of TARFILE or "-" for stdin
O Extract to stdout
exclude File to exclude
X File with names to exclude
C Change to directory DIR before operation
v Verbose
Grüße Jörg
On 20 Mai, 19:59, Martin Fischer wrote:
> Hallo Jörg,
>
> danke für die zeitnahe Rückmeldung!
>
> Am Sonntag, 20. Mai 2012, 10:06:21 schrieb JoWiemann:
>
> > bekomme folgende Fehlermeldung:
>
> > Something went wrong during backup:
> > sh: can't create ./backup/FHEM.2012-05-20_19:03:51.tar.gz: Invalid
> > argument
> > tar: short write
> > The operation was canceled. Please check manually!
>
> > Verzeichnis ./backup wurde angelegt, mit Schreibrechten.
>
> > Betreibe FHEM auf einer FB7170 mit Freetz und FHEM 5.2 aus dem Archiv
> > FB7270.
>
> mangels Hardware: kannst Du bitte auf Deiner 7170 'tar --help' absetzen und
> das Ergebnis hier posten? Und dabei gleich prüfen ob 'gzip' auf der FritzBox
> vorhanden ist. Es scheint als ob es Probleme mit dem Tar auf der 7170 gibt.
>
> Derweil sollte aber 'updatefhem preserve' funktionieren.
>
> Gruß Martin
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin,
sorry überlesen. GZIP ist vorhanden.
Grüße Jörg
On 20 Mai, 20:49, JoWiemann wrote:
> Hallo Martin,
>
> hier die Ausgabe von tar help:
>
> /var/mod/root # tar help
> tar: invalid option -- e
> BusyBox v1.12.4 (2011-03-19 10:21:51 CET) multi-call binary
>
> Usage: tar -[czjxtvO] [-X FILE] [-f TARFILE] [-C DIR] [FILE(s)]...
>
> Create, extract, or list files from a tar file
>
> Options:
> c Create
> x Extract
> t List
> Archive format selection:
> z Filter the archive through gzip
> j Filter the archive through bzip2
> File selection:
> f Name of TARFILE or "-" for stdin
> O Extract to stdout
> exclude File to exclude
> X File with names to exclude
> C Change to directory DIR before operation
> v Verbose
>
> Grüße Jörg
>
> On 20 Mai, 19:59, Martin Fischer wrote:
>
>
>
> > Hallo Jörg,
>
> > danke für die zeitnahe Rückmeldung!
>
> > Am Sonntag, 20. Mai 2012, 10:06:21 schrieb JoWiemann:
>
> > > bekomme folgende Fehlermeldung:
>
> > > Something went wrong during backup:
> > > sh: can't create ./backup/FHEM.2012-05-20_19:03:51.tar.gz: Invalid
> > > argument
> > > tar: short write
> > > The operation was canceled. Please check manually!
>
> > > Verzeichnis ./backup wurde angelegt, mit Schreibrechten.
>
> > > Betreibe FHEM auf einer FB7170 mit Freetz und FHEM 5.2 aus dem Archiv
> > > FB7270.
>
> > mangels Hardware: kannst Du bitte auf Deiner 7170 'tar --help' absetzen und
> > das Ergebnis hier posten? Und dabei gleich prüfen ob 'gzip' auf der FritzBox
> > vorhanden ist. Es scheint als ob es Probleme mit dem Tar auf der 7170 gibt.
>
> > Derweil sollte aber 'updatefhem preserve' funktionieren.
>
> > Gruß Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
kannst du bitte mal folgenden befehl manuell auf der fritzbox ausführen:
(tar -C -cf - FHEM | gzip > /FHEM.12345678.tar.gz) 2>&1
wobei du und mit dem mit dem pfad aus deiner config für
modpath ersetzt (also z.b. /usr/share/fhem, was aber auf der fritzbox
abweicht).
danke!
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Martin!
Bei mir wird auf der FRITZ!Box 7390 und auf meiner SuSE-Maschine nach dem
Aufruf von 'updatefhem housekeeping' zwar jeweils angezeigt 'update
finished', aber es hat sich absolut nichts getan.
Schade, denn ich finde eure neue Strategie der geänderten Programmstruktur
gut :-(
Zitat aus dem Logfile der SuSE Maschine:
2012.05.21 10:40:48 4: HTTP FHEMWEB:127.0.0.1:47406 GET /fhem?room=all&cmd=updatefhem+housekeeping
2012.05.21 10:40:48 4: Got http://fhem.de/fhemupdate/filetimes.txt, length: 8531
2012.05.21 10:40:48 4: /fhem?room=all&cmd=updatefhem+housekeeping / RL: 736 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
Was mich allerdings stutzig macht, ist der Text aus deinem Post:
Note: Since Version 5.3 a new directory structure is used by Fhem.
Die Version 5.3. von FHEM ist mir noch nicht über den Weg gelaufen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
hallo..
Am Montag, 21. Mai 2012, 01:53:19 schrieb ilmtuelp0815:
> Bei mir wird auf der FRITZ!Box 7390 und auf meiner SuSE-Maschine nach dem
> Aufruf von 'updatefhem housekeeping' zwar jeweils angezeigt 'update
> finished', aber es hat sich absolut nichts getan.
ja, das ist auch richtig so... denn ([glaskugel on]) ich gehe davon aus, das
du direkt nachdem du den hinweis gelesen hast 'updatefhem housekeeping'
aufgerufen hast. auf deiner maschine(n) befindet sich aber noch das alte
updatefhem. und das schaut halt dann auf dem server nach der datei
die es nicht gibt. deshlab auch ein 'update finish'.
bevor du also 'updatefhem housekeeping' ausführen kannst, muss sich updatefhem
natürlich erstmal selber updaten ;-)
also beim ersten lauf _nur_ 'updatefhem' eingeben, dann solltest du u.a.
sehen, das 99_updatefhem.pm heruntergeladen und neu gestartet wurde.
erst dann kannst du updatefhem mit den argumenten oder
aufrufen.
bitte teil mir mit, ob ich mit meiner glaskugel richtig lag, bevor sich da
tatsächlich noch ein (wenn auch dann nicht erklärbarer) fehler verbirgt.
> Schade, denn ich finde eure neue Strategie der geänderten Programmstruktur
> gut :-(
alles wird gut ;-)
> [...]
>
> Was mich allerdings stutzig macht, ist der Text aus deinem Post:
>
> Note: Since Version 5.3 a new directory structure is used by Fhem.
>
> Die Version 5.3. von FHEM ist mir noch nicht über den Weg gelaufen.
auch das ist richtig! aktuell ist stable 5.2 draussen. mit updatefhem ziehst
du dir eine _entwicklerversion_ aus dem SVN siehe auch
commandref.html#updatefhem: "Update the fhem modules and documentation from a
nightly SVN checkout."
also wird aus dem SVN checkout in naher zukunft die version 5.3. und damit das
nicht vor dem stable release noch angepasst werden muss, steht es schon jetzt
drin ;-)
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Bei mir kommt nach updatefhem auch nur update finished. Die
99_updatefhem.pm ist danach immer noch Version 1519 von Rudi.
Gruß,
Wirrkopf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo zusammen,
updatefhem
gefolgt von einem
updatefhem housekeeping
hat wunderbar funktioniert.
Aber ...
die power6.gplot und die Weathericons
für das Weathermodul mussten händisch nach ./www/pgm2 umkopiert werden.
Keine große Sache aber vielleicht hilft es jemandem der auf der Suche ist
warum seine
Plots (power6) und das Wetter nichtmehr angezeigt werden.
Grüße
Am Montag, 21. Mai 2012 19:35:37 UTC+2 schrieb Wirrkopf:
>
>
> Bei mir kommt nach updatefhem auch nur update finished. Die
> 99_updatefhem.pm ist danach immer noch Version 1519 von Rudi.
>
> Gruß,
> Wirrkopf
>
Am Montag, 21. Mai 2012 19:35:37 UTC+2 schrieb Wirrkopf:
>
>
> Bei mir kommt nach updatefhem auch nur update finished. Die
> 99_updatefhem.pm ist danach immer noch Version 1519 von Rudi.
>
> Gruß,
> Wirrkopf
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
ich zitiere mich mal selber aus einem anderen thread, allerdings etwas
angepasst:
updatefhem holt sich die filetimes.txt von fhem.de. das file kann man sich
auch manuell ansehen unter http://fhem.de/fhemupdate/filetimes.txt für die
alte struktur (verhalten vom altem 'updatefhem' oder über neues 'updatefhem
preserve').
die neue struktur arbeitet mit http://fhem.de/fhemupdate2/filetimes.txt
welches auch die neuen pfade beinhaltet.
bei einem neuen updatefhem werden mit 'updatefhem housekeeping' lediglich die
dateien aus fhemupdate2/filetimes.txt in die neue struktur heruntergeladen.
fehlt also in der filetimes.txt eine datei, weil sie z.b. selber angelegt
wurde oder nicht mehr bestandteil von der aktuellen fhem version ist, dann
fehlt sie auch in pgm2. sie liegt dann aber immer noch im modpath/FHEM, wie du
bereits festgestellt hast.
wenn 'updatefhem housekeeping clean yes' aufgerufen wird, werden ebenfalls die
dateien heruntergeladen, nun jedoch die alten dateien unter modpath/FHEM auch
gelöscht (aber nur die, die auch heruntergeladen werden und zusätzlich wird
_immer_ ein backup erzeugt; d.h. es geht _keine_ datei verloren!), zusätzlich
wird am ende noch ein move von .*(example.*|gplot|html| css|js|gif|jpg|png|
svg) aus dem FHEM nach www/pgm2 durchgeführt.
hättest du also 'updatefhem housekeeping clean yes' ausgeführt, dann würde die
genannten datein nicht gelöscht werden, da nicht in filetimes.txt aber durch
das clean mit dem darin verbundenen move wären sie schliesslich doch im
www/pgm2 gelandet und du hättest nichts davon bemerkt :-)
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Montag, 21. Mai 2012, 10:35:37 schrieb Wirrkopf:
> Bei mir kommt nach updatefhem auch nur update finished. Die
> 99_updatefhem.pm ist danach immer noch Version 1519 von Rudi.
wann hast du das updatefhem ausgeführt? vor heute 07:45 uhr? wenn ja, dann
liegt das daran, dass das svn nur einmal am tag gespiegelt wird).
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Mein Weg bei der 7390
erst image7390 5.2 mit neuem Perl vom anfang Mai (ist ja noch alte
Structure)
dann updatefhem
shutdown restart
updatefhem housekeeping
shutdown restart
meine individuellen gplots , *.png , für floorplan und Icons, nach ./
www/pgm2 verschieben
und bei mir lüppt es
On 21 Mai, 21:02, Martin Fischer wrote:
> Am Montag, 21. Mai 2012, 10:35:37 schrieb Wirrkopf:
>
> > Bei mir kommt nach updatefhem auch nur update finished. Die
> > 99_updatefhem.pm ist danach immer noch Version 1519 von Rudi.
>
> wann hast du das updatefhem ausgeführt? vor heute 07:45 uhr? wenn ja, dann
> liegt das daran, dass das svn nur einmal am tag gespiegelt wird).
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo zusammen,
ok, wenn mit
updatefhem housekeeping clean yes alles verschoben worden wäre war es doch
mein Fehler da ich nur ein updatefhem housekeeping ausgeführt habe und
dadurch wohl nur bestimmte gplot-files kopiert wurden und die power6.gplot
in meinem Fall nicht.
Aber vielleicht bin ich ja nicht der einzige der nur ein updatefhem
housekeeping
durchführen lässt und sich dann wundert warum nur eine gplot-Datei fehlt.
Aber es hat sich ja geklärt - ich konnte die Files ja händisch umkopieren
und
somit ist ja alles wieder in Ordnung.
Grüße
Am Montag, 21. Mai 2012 20:59:27 UTC+2 schrieb Martin Fischer:
>
> ich zitiere mich mal selber aus einem anderen thread, allerdings etwas
> angepasst:
>
> updatefhem holt sich die filetimes.txt von fhem.de. das file kann man
> sich
> auch manuell ansehen unter http://fhem.de/fhemupdate/filetimes.txt für
> die
> alte struktur (verhalten vom altem 'updatefhem' oder über neues
> 'updatefhem
> preserve').
>
> die neue struktur arbeitet mit http://fhem.de/fhemupdate2/filetimes.txt
> welches auch die neuen pfade beinhaltet.
>
> bei einem neuen updatefhem werden mit 'updatefhem housekeeping' lediglich
> die
> dateien aus fhemupdate2/filetimes.txt in die neue struktur
> heruntergeladen.
> fehlt also in der filetimes.txt eine datei, weil sie z.b. selber angelegt
> wurde oder nicht mehr bestandteil von der aktuellen fhem version ist, dann
> fehlt sie auch in pgm2. sie liegt dann aber immer noch im modpath/FHEM,
> wie du
> bereits festgestellt hast.
>
> wenn 'updatefhem housekeeping clean yes' aufgerufen wird, werden ebenfalls
> die
> dateien heruntergeladen, nun jedoch die alten dateien unter modpath/FHEM
> auch
> gelöscht (aber nur die, die auch heruntergeladen werden und zusätzlich
> wird
> _immer_ ein backup erzeugt; d.h. es geht _keine_ datei verloren!),
> zusätzlich
> wird am ende noch ein move von .*(example.*|gplot|html|
> css|js|gif|jpg|png|
> svg) aus dem FHEM nach www/pgm2 durchgeführt.
>
> hättest du also 'updatefhem housekeeping clean yes' ausgeführt, dann würde
> die
> genannten datein nicht gelöscht werden, da nicht in filetimes.txt aber
> durch
> das clean mit dem darin verbundenen move wären sie schliesslich doch im
> www/pgm2 gelandet und du hättest nichts davon bemerkt :-)
>
> gruss martin
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Montag, 21. Mai 2012, 21:05:17 schrieb puschel74:
> ok, wenn mit
> updatefhem housekeeping clean yes alles verschoben worden wäre war es doch
> mein Fehler da ich nur ein updatefhem housekeeping ausgeführt habe und
> dadurch wohl nur bestimmte gplot-files kopiert wurden und die power6.gplot
> in meinem Fall nicht.
> Aber vielleicht bin ich ja nicht der einzige der nur ein updatefhem
> housekeeping
> durchführen lässt und sich dann wundert warum nur eine gplot-Datei fehlt.
von einem fehler deinerseits zu sprechen ist so nicht richtig. du hast genau
das getan, was wahrscheinlich (so wie du es sagst) viele machen werden:
'update housekeeping'. was aber dabei vergessen wird: updatefhem weiß nichts
von den dateien, die man selber angelegt/umbenannt hat. darüber muss man sich
halt bewusst sein, hier ggf. dann manuell hand anzulegen.
ein 'updatefhem clean yes' räumt dagegen auf auf, also der benannte move wird
am ende durchgeführt.
ich persönlich würde allen empfehlen _immer_ die variante 'updatefhem clean
yes' zu verwenden. da ja eh _vorher_ ein backup von $modpath/FHEM angelegt
wird, geht auch definitiv _nichts_ verloren.
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> ich persönlich würde allen empfehlen _immer_ die variante 'updatefhem clean
> yes' zu verwenden. da ja eh _vorher_ ein backup von $modpath/FHEM angelegt
> wird, geht auch definitiv _nichts_ verloren.
Dann schlage ich vor updatefhem so zu aendern, dass "housekeeping clean yes"
zum default wird, sonst ist das eine bekannte Falle, was immer wieder fuer
Neulinge erklaert werden muss. Wenn es wichtig ist, dann mit "housekeeping
clean no" als Ausweg, obwohl ich persoenlich diese vielen Parameter als
uebertrieben empfinde. Aber man macht es ja nur einmal.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Dienstag, 22. Mai 2012, 11:14:39 schrieb Rudolf Koenig:
> > ich persönlich würde allen empfehlen _immer_ die variante 'updatefhem
> > clean
> > yes' zu verwenden. da ja eh _vorher_ ein backup von $modpath/FHEM angelegt
> > wird, geht auch definitiv _nichts_ verloren.
>
> Dann schlage ich vor updatefhem so zu aendern, dass "housekeeping clean yes"
> zum default wird, sonst ist das eine bekannte Falle, was immer wieder fuer
> Neulinge erklaert werden muss. Wenn es wichtig ist, dann mit "housekeeping
> clean no" als Ausweg, obwohl ich persoenlich diese vielen Parameter als
> uebertrieben empfinde. Aber man macht es ja nur einmal.
jepp.. man macht es nur einmal.. ich denke wir machen es anders:
der move wird auch bei einem housekeeping durchgeführt und gut is..
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Dienstag, 22. Mai 2012, 11:43:10 schrieb Martin Fischer:
> Am Dienstag, 22. Mai 2012, 11:14:39 schrieb Rudolf Koenig:
> > > ich persönlich würde allen empfehlen _immer_ die variante 'updatefhem
> > > clean
> > > yes' zu verwenden. da ja eh _vorher_ ein backup von $modpath/FHEM
> > > angelegt
> > > wird, geht auch definitiv _nichts_ verloren.
> >
> > Dann schlage ich vor updatefhem so zu aendern, dass "housekeeping clean
> > yes" zum default wird, sonst ist das eine bekannte Falle, was immer
> > wieder fuer Neulinge erklaert werden muss. Wenn es wichtig ist, dann mit
> > "housekeeping clean no" als Ausweg, obwohl ich persoenlich diese vielen
> > Parameter als uebertrieben empfinde. Aber man macht es ja nur einmal.
>
> jepp.. man macht es nur einmal.. ich denke wir machen es anders:
> der move wird auch bei einem housekeeping durchgeführt und gut is..
geändert und eingecheckt.. wird dann ab morgen 07:45 uhr zugänglich sein oder
rudi stößt den manuellen mirror kurz an..
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> geändert und eingecheckt.. wird dann ab morgen 07:45 uhr zugänglich sein oder
> rudi stößt den manuellen mirror kurz an..
Angestossen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Bei mir ist auch nach einem gerade eben durchgeführten updatefhem immer
noch die 99_updatefhem.pm mit svn Version 1519 von Rudi vorhanden.
Wenn ich die filetimes.txt manuell runterlade, steht da als Timestamp für
die 99_updatefhem.pm 2012-05-21_07:45:09. Meine Version hat nen Timestamp
von 06. Mai - ist also definitiv älter.
Hmmm. Ich such mal weiter.
Am Dienstag, 22. Mai 2012 12:14:53 UTC+2 schrieb Rudolf Koenig:
> > ge�ndert und eingecheckt.. wird dann ab morgen 07:45 uhr zug�nglich
> sein oder
> > rudi st��t den manuellen mirror kurz an..
>
> Angestossen.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
So. Fehler gefunden. Es war bereits eine aktuelle filetimes.txt vorhanden
und 99_updatefhem.pm prüft nicht die echten Timestamps, sondern die
Timestamps aus der alten filetimes.txt (wenn ich das mit meinem nicht
wirklich vorhandenen Perl-Kenntnissen richtig gelesen habe) und hat daher
ein Update nicht für notwendig erachtet. Warum beim letzten Mal zwar die
filetimes.txt neu heruntergeladen wurde, aber dazu keine passende
99_updatefhem.pm kann ich nicht mehr sagen. Ich habe jetzt einmal die
filetimes.txt gelöscht und nach einem erneuten updatefhem (was wohl alles
aktualisiert hat, weil es keinen Vergleich mehr hatte) ist jetzt auch die
neue 99_updatefhem.pm da. Housekeeping hat aufgeräumt. Gefällt mir gut.
Am Dienstag, 22. Mai 2012 17:38:27 UTC+2 schrieb Wirrkopf:
> Bei mir ist auch nach einem gerade eben durchgeführten updatefhem immer
> noch die 99_updatefhem.pm mit svn Version 1519 von Rudi vorhanden.
>
> Wenn ich die filetimes.txt manuell runterlade, steht da als Timestamp für
> die 99_updatefhem.pm 2012-05-21_07:45:09. Meine Version hat nen Timestamp
> von 06. Mai - ist also definitiv älter.
>
> Hmmm. Ich such mal weiter.
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hej hej,
das Aufräumen ist wirklich eine gute Idee und klappt auch prima. :-)
Was mir jetzt aber beim Update aufgefallen ist:
Warum wurde das Verzeichnis von FHEMWEB außerhalb des regulären
FHEM-Verzeichnisses abgelegt? Beim Standard-ModPath von '/usr/lib'
gibt es dann plötzlich ein '/usr/lib/www' und ein '/usr/lib/FHEM'...
weiß nicht, wie das andere sehen, aber mir würde es besser gefallen,
wenn das Verzeichnis als Unterverzeichnis von 'FHEM' angelegt würde.
:-)
Greetz,
Gerhard
Am 22. Mai 2012 17:47 schrieb Wirrkopf :
> So. Fehler gefunden. Es war bereits eine aktuelle filetimes.txt vorhanden
> und 99_updatefhem.pm prüft nicht die echten Timestamps, sondern die
> Timestamps aus der alten filetimes.txt (wenn ich das mit meinem nicht
> wirklich vorhandenen Perl-Kenntnissen richtig gelesen habe) und hat daher
> ein Update nicht für notwendig erachtet. Warum beim letzten Mal zwar die
> filetimes.txt neu heruntergeladen wurde, aber dazu keine passende
> 99_updatefhem.pm kann ich nicht mehr sagen. Ich habe jetzt einmal die
> filetimes.txt gelöscht und nach einem erneuten updatefhem (was wohl alles
> aktualisiert hat, weil es keinen Vergleich mehr hatte) ist jetzt auch die
> neue 99_updatefhem.pm da. Housekeeping hat aufgeräumt. Gefällt mir gut.
>
> Am Dienstag, 22. Mai 2012 17:38:27 UTC+2 schrieb Wirrkopf:
>>
>> Bei mir ist auch nach einem gerade eben durchgeführten updatefhem immer
>> noch die 99_updatefhem.pm mit svn Version 1519 von Rudi vorhanden.
>>
>> Wenn ich die filetimes.txt manuell runterlade, steht da als Timestamp für
>> die 99_updatefhem.pm 2012-05-21_07:45:09. Meine Version hat nen Timestamp
>> von 06. Mai - ist also definitiv älter.
>>
>> Hmmm. Ich such mal weiter.
>>
>>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Dienstag, 22. Mai 2012, 18:17:44 schrieb Gerhard Pfeffer:
> das Aufräumen ist wirklich eine gute Idee und klappt auch prima. :-)
das ist prima..
> Was mir jetzt aber beim Update aufgefallen ist:
> Warum wurde das Verzeichnis von FHEMWEB außerhalb des regulären
> FHEM-Verzeichnisses abgelegt? Beim Standard-ModPath von '/usr/lib'
> gibt es dann plötzlich ein '/usr/lib/www' und ein '/usr/lib/FHEM'...
> weiß nicht, wie das andere sehen, aber mir würde es besser gefallen,
> wenn das Verzeichnis als Unterverzeichnis von 'FHEM' angelegt würde.
hm.. also ich nutze schon wirklich sehr, sehr lange fhem.. ich kann mich eben
nicht daran erinnern, das es mal ein anderer pfad war als der, der im Makefile
angegeben ist: MODDIR=/usr/share/fhem
vielleicht liege ich da auch falsch und kann mich tatsächlich nicht mehr
erinnern aber wenn du fhem über das Makefile installiert hast, dann müsste es
halt in /usr/share/fhem landen. und dort sollten dann zumindest vier
verzeichnisse sein: backup contrib FHEM www
man mag mich korrigieren, wenn ich irgend ein wechsel in den letzten 5 jahren
gerade verdrängt habe.. ;-)
aber nun auf deine anmerkung:
mach ein updatefhem backup und installier fhem doch einfach neu. warum neu?
weil ich davon ausgehe, das evtl. die anderen pfade aus dem Makefile wie
BINDIR=/usr/bin
MODDIR=/usr/share/fhem
VARDIR=/var/log/fhem
DOCDIR=/usr/share/doc/fhem
MANDIR=/usr/share/man/man1
ETCDIR=/etc
ggf. auch nicht passen. wenn du keine weiteren lokalen änderungen vorgenommen
hast, nimmst du dann deine alte fhem.config und änderst nach der installation
modpath auf attr global modpath /usr/share/fhem
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Bei mir startete die Update-Odyssee mit dem gleichen Verhalten, wie bei
Wirrkopf:
- Nur filetimes.txt wurde neu runtergeladen, nicht 99_updatefhem.pm. Hatte
das Problem schon gelegentlich, konnte es aber noch nicht eingrenzen, woran
das liegt.
- Filetimes.txt gelöscht (bei laufendem FHEM), updatefhem => alles wird neu
geladen. Problem: es endet mit update finished, KEIN reload modules ...
Gewünschtes Verhalten???
- Hat mir auf alle Fälle dann das updatefhem housekeeping clean yes
"verhagelt". Meldung update finished, aber nichts wurde gemacht. Wäre
zumindest hilfreich, wenn da ne Meldung kommt " no update
performed/necessary..."
- Restart FHEM, updatefhem housekeeping clean yes: Meldung "backup
canceled. /usr/local/lib/backup not writable"
PROBLEM:
Ich habe zwar das moddir mit /usr/local/lib definiert, aber KEIN backupdir.
Offensichtlich wurde aber bei der jetzigen Änderung der defaultbackuppath
von "FHEM.backup" in "backup" umbenannt!
=> Finde ich jetzt unschön, zumindest undokumentiert? Ok, steht jetzt als
neuer default in der commandref, sollte aber auch im Kapitel updatefhem
erwähnt werden?
Weiter:
attr global backupdir FHEM.backup
updatefhem housekeeping clean yes
cp: reguläre Datei »/usr/local/lib/fhem.cfgâ kann nicht angelegt werden:
Keine Berechtigung
Use of uninitialized value $conf in concatenation (.) or string at
/usr/local/lib/FHEM/99_updatefhem.pm line 441.
Use of uninitialized value $conf in concatenation (.) or string at
/usr/local/lib/FHEM/99_updatefhem.pm line 446.
mkdir: kann Verzeichnis »/usr/local/lib/wwwâ nicht anlegen: Keine
Berechtigung
Can't write /usr/local/lib/www/pgm2/FS20.off.png
Problem:
bei mir ist attr global modpath /usr/local/lib. Darin ist ein symlink FHEM
=> /home/FHZ/fhem/FHEM. /home/FHZ/fhem ist das Hauptverzeichnis und enthält
die fhem.pl und die fhem.cfg.
updatefhem versucht nun unter /usr/local/lib Verzeichnisse anzulegen und
hat keine Schreibberechtigung. Ok, aber zumindest nun neu, daß fhem da rein
schreiben will.
Interessanterweise wird das Verzeichnis FHEM.backup unter /home/FHZ/fhem
angelegt, da hat fhem auch Schreibberechtigung.
Es scheint also in 99_updatefhem verschiedene Weisen zu geben, mit dem
modpath umzugehen, bzw. relative Pfade werden nicht bzgl. modpath, sondern
relativ zum Startverzeichnis von fhem.pl gebildet.....
Jetzt spiele ich erst mal ein backup ein und teste weiter ... :-(
Am Dienstag, 22. Mai 2012 17:47:44 UTC+2 schrieb Wirrkopf:
>
> So. Fehler gefunden. Es war bereits eine aktuelle filetimes.txt vorhanden
> und 99_updatefhem.pm prüft nicht die echten Timestamps, sondern die
> Timestamps aus der alten filetimes.txt (wenn ich das mit meinem nicht
> wirklich vorhandenen Perl-Kenntnissen richtig gelesen habe) und hat daher
> ein Update nicht für notwendig erachtet. Warum beim letzten Mal zwar die
> filetimes.txt neu heruntergeladen wurde, aber dazu keine passende
> 99_updatefhem.pm kann ich nicht mehr sagen. Ich habe jetzt einmal die
> filetimes.txt gelöscht und nach einem erneuten updatefhem (was wohl alles
> aktualisiert hat, weil es keinen Vergleich mehr hatte) ist jetzt auch die
> neue 99_updatefhem.pm da. Housekeeping hat aufgeräumt. Gefällt mir gut.
>
> Am Dienstag, 22. Mai 2012 17:38:27 UTC+2 schrieb Wirrkopf:
>
>> Bei mir ist auch nach einem gerade eben durchgeführten updatefhem immer
>> noch die 99_updatefhem.pm mit svn Version 1519 von Rudi vorhanden.
>>
>> Wenn ich die filetimes.txt manuell runterlade, steht da als Timestamp für
>> die 99_updatefhem.pm 2012-05-21_07:45:09. Meine Version hat nen
>> Timestamp von 06. Mai - ist also definitiv älter.
>>
>> Hmmm. Ich such mal weiter.
>>
>>
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Odyssee 2. Teil:
updatefhem backup hat ein leeres tar-Archiv bei mir angelegt.
Ursache:
Tar folgt keinen symlinks...
Rudi hatte in REV 1277 den Aufruf von tar geändert, um das zu unterstützen
tar cf -> tar hcf
Diese Änderung ist nun leider wieder verloren gegangen...
(Ich hoffe das gilt jetzt nicht für alle Änderungen seitdem ...)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hej again,
also irgendwann muss es wohl mal /usr/lib gewesen sein... kann auch
durchaus schon mehr als fünf Jahre zurück liegen. ;-)
Seither hab ich das nie in meinem Configfile geändert und das passt
für mich auch.
Ich hab mir eben mal die 99_updatefhem.pm angesehen und das wwwdir
liegt direkt im modpath. Was spricht dagegen (wenn ohnehin gerade
umgebaut wird), den Inhalt von '$modpath/FHEM' als moddir direkt in
das '$moddir' zu bügeln. Bei '/usr/share/fhem/FHEM' ist mir einfach
ein 'FHEM' zuviel. ;-)
Alternativ könnte man auch noch moddir und wwwdir in der fhem.cfg
vollständig eigenständig konfigurierbar machen.
Greetz,
Gerhard
Am 22. Mai 2012 20:47 schrieb Martin Fischer :
> Am Dienstag, 22. Mai 2012, 18:17:44 schrieb Gerhard Pfeffer:
>> das Aufräumen ist wirklich eine gute Idee und klappt auch prima. :-)
>
> das ist prima..
>
>> Was mir jetzt aber beim Update aufgefallen ist:
>> Warum wurde das Verzeichnis von FHEMWEB außerhalb des regulären
>> FHEM-Verzeichnisses abgelegt? Beim Standard-ModPath von '/usr/lib'
>> gibt es dann plötzlich ein '/usr/lib/www' und ein '/usr/lib/FHEM'...
>> weiß nicht, wie das andere sehen, aber mir würde es besser gefallen,
>> wenn das Verzeichnis als Unterverzeichnis von 'FHEM' angelegt würde.
>
> hm.. also ich nutze schon wirklich sehr, sehr lange fhem.. ich kann mich eben
> nicht daran erinnern, das es mal ein anderer pfad war als der, der im Makefile
> angegeben ist: MODDIR=/usr/share/fhem
>
> vielleicht liege ich da auch falsch und kann mich tatsächlich nicht mehr
> erinnern aber wenn du fhem über das Makefile installiert hast, dann müsste es
> halt in /usr/share/fhem landen. und dort sollten dann zumindest vier
> verzeichnisse sein: backup contrib FHEM www
>
> man mag mich korrigieren, wenn ich irgend ein wechsel in den letzten 5 jahren
> gerade verdrängt habe.. ;-)
>
> aber nun auf deine anmerkung:
>
> mach ein updatefhem backup und installier fhem doch einfach neu. warum neu?
> weil ich davon ausgehe, das evtl. die anderen pfade aus dem Makefile wie
> BINDIR=/usr/bin
> MODDIR=/usr/share/fhem
> VARDIR=/var/log/fhem
> DOCDIR=/usr/share/doc/fhem
> MANDIR=/usr/share/man/man1
> ETCDIR=/etc
> ggf. auch nicht passen. wenn du keine weiteren lokalen änderungen vorgenommen
> hast, nimmst du dann deine alte fhem.config und änderst nach der installation
> modpath auf attr global modpath /usr/share/fhem
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 22.05.2012 um 23:20 schrieb PanTau:
> Odyssee 2. Teil:
>
> updatefhem backup hat ein leeres tar-Archiv bei mir angelegt.
> Ursache:
> Tar folgt keinen symlinks...
>
> Rudi hatte in REV 1277 den Aufruf von tar geändert, um das zu unterstützen
> tar cf -> tar hcf
>
> Diese Änderung ist nun leider wieder verloren gegangen...
Finde ich persönlich richtig. Ich hab Unmengen von Symlinks innerhalb $modpath, wenn die beim restore von regulären Dateien überschrieben würden, wäre ich ... ärgerlich.
> (Ich hoffe das gilt jetzt nicht für alle Änderungen seitdem ...)
Das wiederum hoffe ich auch ;-)
Grüße
Oskar
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
ich habe auch das neue updatefhem mit "updatefhem housekeeping clean yes"
probiert.
Mein modpath ist /usr/local/lib. Die Logs und die Konfiguration sind in
/var/log/fhem.
Zuerst wollte updatefhem /usr/local/lib anlegen:
fhem> updatefhem housekeeping clean yes
Something went wrong during backup:
mkdir: kann Verzeichnis ,,/usr/local/lib/backup" nicht anlegen: Keine
Berechtigung
Ok. Dann habe ich /usr/local/lib/backup angelegt und dem User fhhem die
Berechtigung gegeben dort zu schreiben.
Danach kam die Meldung in fhem*.log:
"cp: reguläre Datei ,,/usr/local/lib/fhem.cfg" kann nicht angelegt werden:
Keine Berechtigung
2012.05.23 23:17:37 1: updatefhem backup: The operation was canceled.
Please check manually!
"
Warum will das Skript mein fhem.cfg nach /usr/local/lib migrieren? Warum
lässt es fhem.cfg nicht einfach da wo es ist?
Ich möchte eigentlich dem User fhem auch keine Schreibberrechtigung für
/usr/local/lib geben.
Gerdard schrieb:
"Bei '/usr/share/fhem/FHEM' ist mir einfach ein 'FHEM' zuviel. ;-) "
Das kann ich voll unterstützen. ich habe modpath auf /usr/local/lib und
nicht auf /usr/local/lib/fhem gesetzt, weil mir dann ein fhem zu viel
vorkommt. Finde ich auch unschön.
Mir fehlt irgendwie der Überblick was updatefhem bzgl. einer
Verzeichnisstruktur erwartet.
Mein Vorschlag wäre die neue Verzeichnisstruktur in commandref.html zu
dokumentieren (oder habe ich das übersehen?)?
Danke!
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
hallo gerhard..
Am Mittwoch, 23. Mai 2012, 00:54:09 schrieb Gerhard Pfeffer:
> also irgendwann muss es wohl mal /usr/lib gewesen sein... kann auch
> durchaus schon mehr als fünf Jahre zurück liegen. ;-)
das glaube ich dir gerne.. ich sagte ja, das ich mich zumindest an die letzten
5 jahre nicht mehr erinner ;-)
> [...]
> Ich hab mir eben mal die 99_updatefhem.pm angesehen und das wwwdir
> liegt direkt im modpath. Was spricht dagegen (wenn ohnehin gerade
> umgebaut wird), den Inhalt von '$modpath/FHEM' als moddir direkt in
> das '$moddir' zu bügeln. Bei '/usr/share/fhem/FHEM' ist mir einfach
> ein 'FHEM' zuviel. ;-)
auch mir ist ein fhem (ob nun gross oder klein) zu viel..
das ist so wie die tollen email adressen @. muss
aber jeder für sich selbst entscheiden. ;-)
wir sind da noch in der diskussion auf der fhem-devel liste und noch nicht
abschliessend zu einem ergebnis gekommen.
aber bis dahin müssen wir erstmal mit der aktuellen struktur leben. zumal das
housekeeping ja auch nur _einmal_ ausgeführt werden sollte.
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo PanTau,
Am Dienstag, 22. Mai 2012, 13:48:25 schrieb PanTau:
> Bei mir startete die Update-Odyssee mit dem gleichen Verhalten, wie bei
> Wirrkopf:
naja.. als "lange Irrfahrt" würde ich das nun nicht bezeichnen ;-)
> [...]
> Ich habe zwar das moddir mit /usr/local/lib definiert, aber KEIN backupdir.
> Offensichtlich wurde aber bei der jetzigen Änderung der defaultbackuppath
> von "FHEM.backup" in "backup" umbenannt!
ja, wurde umbenannt in . Wie bereits Gerhard bzgl. des
default-Pfades auf "mir ist da zumindest ein FHEM
zuviel" angespielt hat und ich das genau so sehe, habe ich es umbenannt.
> => Finde ich jetzt unschön, zumindest undokumentiert? Ok, steht jetzt als
> neuer default in der commandref, sollte aber auch im Kapitel updatefhem
> erwähnt werden?
also undokumentiert ist das nicht. es steht in der commandref.html wo es
meiner ansicht nach auch hingehört. von welchem "Kapitel" sprichst du? habe
ich etwas übersehen?
> Weiter:
> attr global backupdir FHEM.backup
> updatefhem housekeeping clean yes
> cp: reguläre Datei »/usr/local/lib/fhem.cfgâ kann nicht angelegt werden:
> Keine Berechtigung
> [...]
zur erklärung:
tar gibt in der regel die meldung aus "führende / werden entfernt" oder so
ähnlich.. habe das nun gerade nicht im kopf. diese "rückmeldung" gehört aber
meiner meinung nach _nicht_ in die ausgabe einer software, die sich an tar
bedient. deshalb wurde der aufruf von tar etwas angeändert:
tar -C $modpath -cf - $backuppaths
das -C $modpath sorgt nun dafür, das tar vorher in das verzeichnis wechselt.
und dann die pfade/dateien aus $backuppaths sichert.
bevor tar allerdings loslegt, habe ich dem backup noch die sicherung der .cfg
"spendiert". das war vorher nämlich nicht im backup. wegen des geänderten tar
aufrufs und vorallen der unterdrückung der meldung mit den "führenden /" muss
also zu erst die .cfg temporär nach $modpath kopiert werden. dann erfolgt die
sicherung und die .cfg wird wieder aus $modpath entfernt.
soviel zu dem thema der nicht anlegbaren fhem.cfg.
> Problem:
> bei mir ist attr global modpath /usr/local/lib. Darin ist ein symlink FHEM
> => /home/FHZ/fhem/FHEM. /home/FHZ/fhem ist das Hauptverzeichnis und enthält
> die fhem.pl und die fhem.cfg.
> updatefhem versucht nun unter /usr/local/lib Verzeichnisse anzulegen und
> hat keine Schreibberechtigung. Ok, aber zumindest nun neu, daß fhem da rein
> schreiben will.
> Interessanterweise wird das Verzeichnis FHEM.backup unter /home/FHZ/fhem
> angelegt, da hat fhem auch Schreibberechtigung.
> Es scheint also in 99_updatefhem verschiedene Weisen zu geben, mit dem
> modpath umzugehen, bzw. relative Pfade werden nicht bzgl. modpath, sondern
> relativ zum Startverzeichnis von fhem.pl gebildet.....
nein, updatefhem setzt den pfad wie folgt zusammen:
$modpath = $attr{global}{modpath});
$moddir = "$modpath/FHEM";
$wwwdir = "$modpath/www";
es wird also immer auf $attr{global}{modpath}, in deinem fall /usr/local/lib
zurückgegriffen und somit ist eine einheitliche behandlung auf basis des
globalen attributes modpath gegeben. in deinem fall bedeutet das: updatefhem
will in /usr/local/lib folgende verzeichnisse bedienen: backup, FHEM und www.
darüber hinaus die obige thematik bzgl. der .cfg datei und tar. also müsste
demnach /usr/local/lib schreibrechte für fhem bekommen. allerdings würde auch
ich das in einen *nix nicht befürworten.
fhem arbeit per default (siehe Makefile) mit
BINDIR=/usr/bin
MODDIR=/usr/share/fhem
VARDIR=/var/log/fhem
DOCDIR=/usr/share/doc/fhem
MANDIR=/usr/share/man/man1
ETCDIR=/etc
wobei MODDIR quasi der basispfad (attr global modpath /usr/share/fhem) ist.
und genau da versuchen wir ja gerade aufzuräumen. das ursprüngliche FHEM
verzeichniss enthielt bisher _alle_ dateien wie module, images, html, etc. was
das ganze extrem unübersichtlich macht. vorallem dann, wenn man entwickelt und
viel mit der konsole arbeitet.
das problem was wir nun haben: wie soll über updatefhem jegliche abweichung
ausserhalb von "attr global modpath" geprüft werden? es wird immer den einen
oder anderen geben, der die standard einstellung ändert (auch wenn es vor
einigen jahren mal unter /usr/local/lib lag). das erschwert natürlich beiden
seiten (entwickler / benutzer) den automatischen weg.
aktuell diskutieren wir gerade, in wie fern die struktur innerhalb von "attr
global modpath" künftig aussehen soll. das "www" ist neben "FHEM" ja evtl.
auch nur ein anfang. und dann wird _vielleicht_ auch "FHEM" noch umbenannt
(auch wegen der doppelten nennung in "/usr/share/fhem/FHEM" aber auch um
anhand des namens bereits abzugrenzen _was_ in dieses verzeichnis gehört).
aber das ist aktuell in der diskussion und definitiv nicht spruchreif.
um nun aber auch schlussendlich eine lösung anzubieten, würde ich vorschlagen,
das du in deiner config den modpath wie folgt änderst:
"attr global modpath /usr/local/lib/fhem" wobei dann fhem in symlink auf dein
"/home/FHZ/fhem/" ist. das sollte meines erachtens nach erstmal ein gangbarer
weg sein.
wäre einzig noch das problem mit den symlinks im backup aber dazu gleich in
der antwort zu deiner "Odyssee - Teil 2" ;-)
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Dienstag, 22. Mai 2012, 14:20:09 schrieb PanTau:
> [...]
> updatefhem backup hat ein leeres tar-Archiv bei mir angelegt.
> Ursache:
> Tar folgt keinen symlinks...
>
> Rudi hatte in REV 1277 den Aufruf von tar geändert, um das zu unterstützen
ja, das stimmt. wir waren beim wegfall von "-h" also "symlinks folgen" beide
unsicher. aber nun stehen wir erneut vor einem problem:
fhem auf fritzbox wird immer populärer (auch wenn ich persönlich nichts davon
halte ;-) ). und das tar auf der fritzbox kennt "h" als argument nicht. mich
wundert nur, das es vorher mit "h" noch keine rückmeldung gab, das backup auf
der fritzbox nicht funktioniert hat.
welchen tot sollen wir nun sterben? oder welche (mit vertretbaren aufwand für
_beide_ seiten) alternative gibt es?
das einzige was mir spontan einfällt, wäre das "updatefhem backup" erstmal die
verzeichnisse scannt und prüft ob sich dort symlinks befinden. wenn ja dann
tar mit "h", wenn nein dann ohne "h" aufrufen. die frage die ich mir dabei
stelle: welche baustelle reissen wir damit dann auf?
> [...]
> Diese Änderung ist nun leider wieder verloren gegangen...
> (Ich hoffe das gilt jetzt nicht für alle Änderungen seitdem ...)
den letzten satz kann ich gerade nicht nachvollziehen. welche änderungen
sollten "seitdem" _noch_ verloren gegangen sein?
wie bereits geschrieben, hat updatefhem neben der housekeeping geschichte im
kern folgende änderungen/neuerungen erfahren: $modpath/www wird angelegt,
FHEM.backup ist nun backup und bei tar fiel das argument "h" weg, die endung
wurde von .tgz auf tar.gz umgestellt, fhem.cfg wird gesichert und ab morgen
ist der timestamp im archivname dateisystemkonformer
(FHEM-20120524_092616.tar.gz).
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Martin!
Natürlich hatte ich, nachden 'updatefhem housekeeping' auf der SuSE 12.1
Maschine nicht funktionierte, ein normales updatefhem gemacht. Auch die
Versuche an den folgenden Tagen, einschließlich des Löschens der
filetimes.txt haben kein positives Ergebnis bewirkt. So hatte ich mich
schon zu einem Status Quo entschlossen und wollte auf fhem 5.3 warten. Aber
es hat mir keine Ruhe gelassen ud so habe ich das Update heute noch einmal
angeschoben... und siehe da es funktioniert wie von euch geplant. Danke,
wer auch immer das bewirkt hat.
> alles wird gut ;-)
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Donnerstag, 24. Mai 2012, 09:01:23 schrieb ilmtuelp0815:
> Aber
> es hat mir keine Ruhe gelassen ud so habe ich das Update heute noch einmal
> angeschoben... und siehe da es funktioniert wie von euch geplant. Danke,
> wer auch immer das bewirkt hat.
prima, das freut mich zu hören ;-)
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> fhem auf fritzbox wird immer populärer (auch wenn ich persönlich nichts
davon
> halte ;-) ). und das tar auf der fritzbox kennt "h" als argument nicht.
Bei mir schon:
BusyBox v1.19.4 (2012-04-24 14:54:37 CEST) multi-call binary.
Usage: tar -[cxtzjhvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...
Create, extract, or list files from a tar file
Operation:
c Create
x Extract
t List
f Name of TARFILE ('-' for stdin/out)
C Change to DIR before operation
v Verbose
z (De)compress using gzip
j (De)compress using bzip2
O Extract to stdout
h Follow symlinks
X File with names to exclude
T File with names to include
Zugegeben, daß muß nicht immer so sein (habe ne 7390 mit freetz, was den
Unterschied machen kann), aber auch mein OpenWRT Router hat das "h", mein
Ubuntu sowieso.
Mein Windows hat gar kein tar :-) Wie machen das die Kollegen da
eigentlich? Oder wird so eine Randgruppe einfach ignoriert? :-)
Ich finde Kompatibilität wichtig, aber ich brauche auch das Symlink feature.
Könnte man nicht tar -h "probeweise" aufrufen und je nach Rückgabewert,
dann die Version mit oder ohne "h" nehmen?
Vorausgesetzt irgendjemand hat noch Uralt busybox Versionen ohne "h" auf
embedded Systemen...
>> [...]
>> Diese Änderung ist nun leider wieder verloren gegangen...
>> (Ich hoffe das gilt jetzt nicht für alle Änderungen seitdem ...)
>den letzten satz kann ich gerade nicht nachvollziehen. welche änderungen
>sollten "seitdem" _noch_ verloren gegangen sein?
Ich hatte befürchtet das alle Änderungen seit der Rev 1277 weg sein
könnten, falls Du nämlich das "h" nicht absichtlich
entfernt hättest - was ich mir beim besten Willen nicht vorstellen konnte
:-), sondern Deine Änderungen auf einem alten Branch
des SVN gemacht hast - was ich jetzt auch nicht mehr verstehe, so eine Idee
gehabt zu haben - macht ja keiner :-)
>wie bereits geschrieben, hat updatefhem neben der housekeeping geschichte
im
>kern folgende änderungen/neuerungen erfahren: $modpath/www wird angelegt,
>FHEM.backup ist nun backup und bei tar fiel das argument "h" weg, die
endung
>wurde von .tgz auf tar.gz umgestellt, fhem.cfg wird gesichert und
Genau das ist die Doku, die ich in meinem anderen Posting vermisst habe.
Meiner Meinung nach gehört in das Kapitel "updatefhem" eine Auflistung der
"inkompatiblen" Änderungen.
Einfach übersichtlicher, schneller zu finden, auch wenn "backup" woanders
beschrieben wird, aber eben nicht als Änderung.
Ich denke an das nächste Release 5.2 => 5.3, für alle die das hier in der
Gruppe eh schon mitbekommen haben, ist das naklar nicht nötig ...
Gruß
Peter
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> bevor tar allerdings loslegt, habe ich dem backup noch die sicherung der
> .cfg
> "spendiert". das war vorher nämlich nicht im backup.
PANIK: hatte ich bisher noch nicht gemerkt. Gute Sache!. Ich habe
allerdings einige .cfg im gleichen Verzeichnis, die ich per include in
fhem.cfg
einbinde, könnte man die nicht auch mit backuppen? Warum nicht alles unter
modpath backuppen - ok ohne Inhalt von backuppath...?
>
> > Problem:
> > bei mir ist attr global modpath /usr/local/lib. Darin ist ein symlink
> FHEM
> > => /home/FHZ/fhem/FHEM. /home/FHZ/fhem ist das Hauptverzeichnis und
> enthält
> > die fhem.pl und die fhem.cfg.
> > updatefhem versucht nun unter /usr/local/lib Verzeichnisse anzulegen und
> > hat keine Schreibberechtigung. Ok, aber zumindest nun neu, daß fhem da
> rein
> > schreiben will.
> > Interessanterweise wird das Verzeichnis FHEM.backup unter /home/FHZ/fhem
> > angelegt, da hat fhem auch Schreibberechtigung.
> > Es scheint also in 99_updatefhem verschiedene Weisen zu geben, mit dem
> > modpath umzugehen, bzw. relative Pfade werden nicht bzgl. modpath,
> sondern
> > relativ zum Startverzeichnis von fhem.pl gebildet.....
>
> nein, updatefhem setzt den pfad wie folgt zusammen:
> $modpath = $attr{global}{modpath});
> $moddir = "$modpath/FHEM";
> $wwwdir = "$modpath/www";
>
> es wird also immer auf $attr{global}{modpath}, in deinem fall
> /usr/local/lib
> zurückgegriffen und somit ist eine einheitliche behandlung auf basis des
> globalen attributes modpath gegeben.
Einspruch:
wie ich oben geschrieben habe ist bei mir
modpath = /usr/local/lib
und
attr global backupdir FHEM.backup
also kein absoluter Pfad, nur ein Verzeichnisname.
Dieses Verzeichnis wird dann anscheinend nicht unter modpath angelegt,
sondern an dem Ort an dem fhem.pl liegt, bei
mir /home/FHZ/fhem, und das habe ich nirgends als attr global definiert.
99_updatefhem.pl:
if ($attr{global}{backupdir}) {
$backupdir = $attr{global}{backupdir};
} else {
$backupdir = "$modpath/backup";
}
Ich vermute backupdir nicht als absoluten Pfad zu definieren ist halt keine
gute Idee, oder?
> um nun aber auch schlussendlich eine lösung anzubieten, würde ich
> vorschlagen,
> das du in deiner config den modpath wie folgt änderst:
> "attr global modpath /usr/local/lib/fhem" wobei dann fhem in symlink auf
> dein
> "/home/FHZ/fhem/" ist. das sollte meines erachtens nach erstmal ein
> gangbarer
> weg sein.
>
> Meine Lösung ist attr global modpath /home/FHZ/fhem.
Aufruf:
updatefhem
Abbruch mit Hinweis auf Änderung - ok Leute sollen auf Umstieg hingewiesen
werden.
Aber ist es evtl nicht besser "preserve" als default zu nehmen?
Bei updatefhem backup erfolgt ja auch kein Hinweis auf die neuen
Features....
updatefhem housekeeping clean yes
=> HEUREKA!
Gruß
Peter
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Donnerstag, 24. Mai 2012, 13:25:30 schrieb PanTau:
> [...]
> > halte ;-) ). und das tar auf der fritzbox kennt "h" als argument nicht.
>
> Bei mir schon:
> BusyBox v1.19.4 (2012-04-24 14:54:37 CEST) multi-call binary.
>
> Usage: tar -[cxtzjhvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...
> [...]
> Zugegeben, daß muß nicht immer so sein (habe ne 7390 mit freetz, was den
> Unterschied machen kann), aber auch mein OpenWRT Router hat das "h", mein
> Ubuntu sowieso.
zitat dazu von Rudi, der getestet hat (@rudi: das ist _keine_ schuldzuweisung ;-) ).
Am Samstag, 19. Mai 2012, 10:09:54 schrieben Sie:
> - tar funktioniert so auf dem FritzBox nicht, tar hat da folgende
> Optionen: Options:
> c Create
> x Extract
> t List
> Archive format selection:
> File selection:
> f Name of TARFILE or "-" for stdin
> O Extract to stdout
> exclude File to exclude
> X File with names to exclude
> C Change to DIR before operation
> v Verbose
> p ist beim einpacken eh nutzlos, beim h bin ich unsicher, ob das
> gewuenscht ist. --total wird unter OSX auch nicht angeboten, und sollte
> laut web --totals heissen.
du siehst: wir haben uns darüber gedanken gemacht und auch getestet. hier
haben wir wieder das gleiche problem wie mit dem .tar.gz versus .tgz oder mit
/usr/share/fhem versus /usr/local/lib. es ist halt schwer alles zu
berücksichtigen. und im zweifel nimmt man dann erstmal den kleinsten
gemeinsamen nenner. bei dem fritzbox image von avm bzw. rudi fehlt tar halt
die unterstützung für symlinks.
> Mein Windows hat gar kein tar :-) Wie machen das die Kollegen da
> eigentlich? Oder wird so eine Randgruppe einfach ignoriert? :-)
hierzu verweigere ich jetzt mal die aussage. sonst werde ich noch geterrt und
gefedert ;-)
> Ich finde Kompatibilität wichtig, aber ich brauche auch das Symlink feature.
> Könnte man nicht tar -h "probeweise" aufrufen und je nach Rückgabewert,
> dann die Version mit oder ohne "h" nehmen?
ich bin bei dir. nur müssen wir einen weg finden, wie wir das so hinbekommen,
das beide abgedeckt werden. ich werd das mal bei fhem-devel abkippen, ob da
noch die eine oder andere idee vorliegt. denn die zu sichernde verzeichnisse
nach symlinks zu scannen wäre zwar denkbar, was ist aber wenn ein user in
unwissenheit der fehlenden option auf einer fritzbox einfach im $modpath
symlinks anlegt?
> Vorausgesetzt irgendjemand hat noch Uralt busybox Versionen ohne "h" auf
> embedded Systemen...
ja, avm ;-) um nur eines zu nennen! und die liefern fhem sogar in ihrer
laborumgebung an leute aus, die diese mailingslist wahrscheinlich niemals
besuchen ;-)
> [...]
> Ich hatte befürchtet das alle Änderungen seit der Rev 1277 weg sein
> könnten, falls Du nämlich das "h" nicht absichtlich
> entfernt hättest - was ich mir beim besten Willen nicht vorstellen konnte
>
> :-), sondern Deine Änderungen auf einem alten Branch
>
> des SVN gemacht hast - was ich jetzt auch nicht mehr verstehe, so eine Idee
> gehabt zu haben - macht ja keiner :-)
sag niemals nie ;-) aber ich kann dich beruhigen.. in diesem fall war / ist es
definitiv _nicht_ so gewesen..
>> wie bereits geschrieben, hat updatefhem neben der housekeeping geschichte
>> im kern folgende änderungen/neuerungen erfahren: $modpath/www wird
>> angelegt, FHEM.backup ist nun backup und bei tar fiel das argument "h" weg,
>> die endung wurde von .tgz auf tar.gz umgestellt, fhem.cfg wird gesichert
>> und
>
> Genau das ist die Doku, die ich in meinem anderen Posting vermisst habe.
> Meiner Meinung nach gehört in das Kapitel "updatefhem" eine Auflistung der
> "inkompatiblen" Änderungen.
ok.. dann habe ich das jetzt verstanden. das gilt es zu überdenken.
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Donnerstag, 24. Mai 2012, 14:27:45 schrieb PanTau:
> > bevor tar allerdings loslegt, habe ich dem backup noch die sicherung der
> > .cfg
> > "spendiert". das war vorher nämlich nicht im backup.
>
> PANIK: hatte ich bisher noch nicht gemerkt. Gute Sache!. Ich habe
> allerdings einige .cfg im gleichen Verzeichnis, die ich per include in
> fhem.cfg
> einbinde, könnte man die nicht auch mit backuppen? Warum nicht alles unter
> modpath backuppen - ok ohne Inhalt von backuppath...?
ich habe auch viele includes PANIK ;-) ne, spass beseite: klar sollte das mit
rein, ich hatte es nur nicht auf die schnelle umgesetzt. die ganze
housekeeping / backup anpassungen habe ich in - sagen wir mal - einer nacht
und nebel aktion gemacht. was jetzt nicht heisst, das wir / ich nicht getestet
habe, sondern es in zwei nächten umgesetzt wurde. aber so einfach ist das dann
auch wieder nicht, da ja theoretisch der user seine includes über das ganze
system verteilen könnte. dann hilft zwar ein parsen der config nach include,
doch dann muss die struktur auch im backup für den fall eines restores
nachgebildet werden. auch das ist halt noch eine baustelle, die es gilt zu
stopfen.
hier muss ich mal etwas mehr quoten, da sonst der zusammenhang flöten geht..
> [...]
> > nein, updatefhem setzt den pfad wie folgt zusammen:
> > $modpath = $attr{global}{modpath});
> > $moddir = "$modpath/FHEM";
> > $wwwdir = "$modpath/www";
> >
> > es wird also immer auf $attr{global}{modpath}, in deinem fall
> > /usr/local/lib
> > zurückgegriffen und somit ist eine einheitliche behandlung auf basis des
> > globalen attributes modpath gegeben.
>
> Einspruch:
> wie ich oben geschrieben habe ist bei mir
> modpath = /usr/local/lib
> und
> attr global backupdir FHEM.backup
> also kein absoluter Pfad, nur ein Verzeichnisname.
> Dieses Verzeichnis wird dann anscheinend nicht unter modpath angelegt,
> sondern an dem Ort an dem fhem.pl liegt, bei
> mir /home/FHZ/fhem, und das habe ich nirgends als attr global definiert.
> 99_updatefhem.pl:
> if ($attr{global}{backupdir}) {
> $backupdir = $attr{global}{backupdir};
> } else {
> $backupdir = "$modpath/backup";
> }
> Ich vermute backupdir nicht als absoluten Pfad zu definieren ist halt keine
> gute Idee, oder?
hier sehe ich tatsächlich eine ungewollte änderung. da ist mir scheinbar ein
fehler unterlaufen! danke für den hinweis!
es muss korrekterweise heissen:
if ($attr{global}{backupdir}) {
$backupdir = "$modpath/$attr{global}{backupdir}";
} else {
$backupdir = "$modpath/backup";
}
ich werds gleich mal ändern und einchecken. bitte ab morgen > 08:00 uhr (wegen
svn-mirror für updatefhem) mal eine rückmeldung geben.
ftr:
in 5.2 wird $backupdir wie folgt definiert:
my $backupdir = AttrVal("global", "backupdir", "/tmp/FHEM_Backup");
im svn rev. 1519:
## backup by RueBe, simplified by rudi
my $moddir = (-d "FHEM.X" ? "FHEM.X" : "$attr{global}{modpath}/FHEM");
my $bdir = AttrVal("global", "backupdir", "$moddir.backup");
und nu meiner einer ;-)
aber ich denke wir werden das nun auch bald abschliessen ;-)
> > um nun aber auch schlussendlich eine lösung anzubieten, würde ich
> > vorschlagen,
> > das du in deiner config den modpath wie folgt änderst:
> > "attr global modpath /usr/local/lib/fhem" wobei dann fhem in symlink auf
> > dein
> > "/home/FHZ/fhem/" ist. das sollte meines erachtens nach erstmal ein
> > gangbarer
> > weg sein.
> >
> > Meine Lösung ist attr global modpath /home/FHZ/fhem.
oder so :-)
> Aufruf:
> updatefhem
> Abbruch mit Hinweis auf Änderung - ok Leute sollen auf Umstieg hingewiesen
> werden.
> Aber ist es evtl nicht besser "preserve" als default zu nehmen?
gilt zu diskutieren -> fhem-devel
> Bei updatefhem backup erfolgt ja auch kein Hinweis auf die neuen
> Features....
das ist aber auch nicht mit dem umfang bzw. der auswirkung von housekeeping
vergleichbar ;-)
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Freitag, 25. Mai 2012, 00:17:04 schrieb Martin Fischer:
> Am Donnerstag, 24. Mai 2012, 14:27:45 schrieb PanTau:
> > > bevor tar allerdings loslegt, habe ich dem backup noch die sicherung der
> > > .cfg
> > > "spendiert". das war vorher nämlich nicht im backup.
> >
> > PANIK: hatte ich bisher noch nicht gemerkt. Gute Sache!. Ich habe
> > allerdings einige .cfg im gleichen Verzeichnis, die ich per include in
> > fhem.cfg
> > einbinde, könnte man die nicht auch mit backuppen? Warum nicht alles unter
> > modpath backuppen - ok ohne Inhalt von backuppath...?
nachtrag: per default (Makefile) ist ETCDIR=/etc :-) also würde zwar ein
backup von $modpath bei dir wirkung zeigen aber nicht bei anderen.
daran sieht man deutlich wie komplex _freiheit_ sein kann ;-) umso komplexer
die logik die das dann auffangen soll / muss.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Auch auf meiner "normalen" Fritzbox 7390 ist der h parameter bei tar
vorhanden:
BusyBox v1.18.5 (2011-10-27 16:00:43 CEST) multi-call binary.
Usage: tar -[cxtvO] [-X FILE] [-f TARFILE] [-C DIR] [FILE]...
Create, extract, or list files from a tar file
Operation:
c Create
x Extract
t List
Options:
f Name of TARFILE ('-' for stdin/out)
C Change to DIR before operation
v Verbose
O Extract to stdout
h Follow symlinks
exclude File to exclude
X File with names to exclude
T File with names to include
Gruß
René
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
danke rene für die rückmeldung!
Am Freitag, 25. Mai 2012, 02:40:00 schrieb Echo:
> Auch auf meiner "normalen" Fritzbox 7390 ist der h parameter bei tar
> vorhanden:
rudi hat das heute auch noch mal korrigiert. bei der 7390 ist es dabei, bei
der 7270 nicht.
das thema wird gerade auf der fhem-developers liste behandelt.
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo,
habe vorgestern auf meiner FB7390 updatefhem houskeeping clean yes
ausgeführt, ist auch problemlos durchgelaufen.
2012.05.23 10:12:01.815 1: updatefhem Housekeeping finished, 'shutdown restart' is recommended!
2012.05.23 10:12:01.818 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
2012.05.23 10:19:41.779 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 10305)
Was mich nur wundert ist das ich seitdem kein Update mehr erhalte.
Was ich versucht habe:
1. filetimes.txt gelöscht und updatefhem ausgeführt, es wurden alle Dateien erneut heruntergeladen shutdown restart ausgeführt
2012.05.24 10:55:39.367 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
2012.05.24 10:56:09.051 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 4823)
immer noch alte fhem.pl
2. 2012.05.25 13:00:55.678 1: updatefhem updated FHEM/99_updatefhem.pm
damit erhalte ich diese Version: $Id: 99_updatefhem.pm 1569 2012-05-20 15:24:11Z mfr69bs $ ist doch auch schon was älter
dann nochmal updatefhem fhem.pl ausgeführt
2012.05.25 13:12:52.813 1: updatefhem updated ./fhem.pl
2012.05.25 13:12:52.837 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
2012.05.25 13:13:03.378 0: Server shutdown
2012.05.25 13:13:15.378 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 8687)
immer noch die vom 12.05
Woran kann das liegen? Ist das nur bei mir so ?
fragende Grüße
Guido
Am Freitag, 25. Mai 2012 13:00:25 UTC+2 schrieb Martin Fischer:
>
> danke rene für die rückmeldung!
>
> Am Freitag, 25. Mai 2012, 02:40:00 schrieb Echo:
> > Auch auf meiner "normalen" Fritzbox 7390 ist der h parameter bei tar
> > vorhanden:
>
> rudi hat das heute auch noch mal korrigiert. bei der 7390 ist es dabei,
> bei
> der 7270 nicht.
>
> das thema wird gerade auf der fhem-developers liste behandelt.
>
> gruss martin
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
Am 25.05.2012 14:05, schrieb Guido:
> habe vorgestern auf meiner FB7390 updatefhem houskeeping clean yes
> ausgeführt, ist auch problemlos durchgelaufen.
Bei mir genau so.
> Was mich nur wundert ist das ich seitdem kein Update mehr erhalte.
Dito.
> 2. 2012.05.25 13:00:55.678 1: updatefhem updated FHEM/99_updatefhem.pm
> damit erhalte ich diese Version: $Id: 99_updatefhem.pm 1569 2012-05-20 15:24:11Z mfr69bs $ ist doch auch schon was älter
> dann nochmal updatefhem fhem.pl ausgeführt
> 2012.05.25 13:12:52.813 1: updatefhem updated ./fhem.pl
> 2012.05.25 13:12:52.837 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
> 2012.05.25 13:13:03.378 0: Server shutdown
> 2012.05.25 13:13:15.378 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 8687)
>
> immer noch die vom 12.05
>
> Woran kann das liegen? Ist das nur bei mir so ?
Bei mir haben fhem.pl und alle Dateien im FHEM-Verzeichnis bis auf die
von mir erstellten Dateien als Erstellungsdatum den Zeitpunkt des
Herunterladens plus 1 Stunde (Sommerzeit?). Sollte hier nicht das
Dateidatum des Servers erscheinen? Ich glaube, bisher war das so.
Nach manuellem Update der fhem.pl auf Version 1588 von Heute steht nach
dem Neustart im log:
Server started (version =VERS= from =DATE= ($Id$), pid 8706)
Dann habe ich auch die 99_updatefhem.pm aus dem SVN installiert. Danach
noch einmal "updatefhem 99_updatefhem.pm" lädt wieder die alte Datei
herunter.
Viele Grüße,
Christian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo,
ich lasse bei mir grundsätzlich jeden Samstag abend um 21:00 ein updatefhem
mit anschliessendem
shutdown restart durchlaufen.
Ich hab das updatefhem housekeeping clean yes wie früher schonmal in diesem
fred angesprochen
bereits hinter mir.
Heute listet mir fhem im log folgendes
2012.05.26 21:15:47 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 5534)
nach dem restart auf.
Ok, das war vor fast 3 Stunden aber wir waren auch eingeladen und ich bin gerade eben wieder an mein fhem dran gekommen.
Soll das so sein?
Wenn ja ist ja alles ok.
Achso ja. neue Module wurden laut log nicht installiert - siehe
2012.05.26 21:12:30 2: FS20 set Wasserpumpe off
2012.05.26 21:15:00 3: updatefhem : update finished
2012.05.26 21:15:20 0: Server shutdown
2012.05.26 21:15:25 2: Telnet port 7072 opened
2012.05.26 21:15:26 2: FHEMWEB port 8083 opened
2012.05.26 21:15:26 2: FHEMWEB port 8084 opened
2012.05.26 21:15:26 2: FHEMWEB port 8085 opened
2012.05.26 21:15:26 3: Opening CUL1 device /dev/ttyACM0
2012.05.26 21:15:27 3: Setting CUL1 baudrate to 9600
2012.05.26 21:15:27 3: CUL1 device opened
2012.05.26 21:15:27 3: Opening CUNO1 device 192.168.2.28:2323
2012.05.26 21:15:27 3: CUNO1 device opened
2012.05.26 21:15:27 3: Opening CUNO2 device 192.168.2.24:2323
2012.05.26 21:15:27 3: CUNO2 device opened
2012.05.26 21:15:47 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 5534)
Grüße
Am Samstag, 26. Mai 2012 19:39:16 UTC+2 schrieb Christian Herrmann:
>
> Hallo,
>
> Am 25.05.2012 14:05, schrieb Guido:
> > habe vorgestern auf meiner FB7390 updatefhem houskeeping clean yes
> > ausgef�hrt, ist auch problemlos durchgelaufen.
>
> Bei mir genau so.
>
> > Was mich nur wundert ist das ich seitdem kein Update mehr erhalte.
>
> Dito.
>
> > 2. 2012.05.25 13:00:55.678 1: updatefhem updated FHEM/99_updatefhem.pm
> > damit erhalte ich diese Version: $Id: 99_updatefhem.pm 1569
> 2012-05-20 15:24:11Z mfr69bs $ ist doch auch schon was �lter
> > dann nochmal updatefhem fhem.pl ausgef�hrt
> > 2012.05.25 13:12:52.813 1: updatefhem updated ./fhem.pl
> > 2012.05.25 13:12:52.837 1: updatefhem New version of fhem.pl,
> 'shutdown restart' is required!
> > 2012.05.25 13:13:03.378 0: Server shutdown
> > 2012.05.25 13:13:15.378 0: Server started (version 5.2+SVN from
> 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid
> 8687)
> >
> > immer noch die vom 12.05
> >
> > Woran kann das liegen? Ist das nur bei mir so ?
>
> Bei mir haben fhem.pl und alle Dateien im FHEM-Verzeichnis bis auf die
> von mir erstellten Dateien als Erstellungsdatum den Zeitpunkt des
> Herunterladens plus 1 Stunde (Sommerzeit?). Sollte hier nicht das
> Dateidatum des Servers erscheinen? Ich glaube, bisher war das so.
>
> Nach manuellem Update der fhem.pl auf Version 1588 von Heute steht nach
> dem Neustart im log:
> Server started (version =VERS= from =DATE= ($Id$), pid 8706)
>
> Dann habe ich auch die 99_updatefhem.pm aus dem SVN installiert. Danach
> noch einmal "updatefhem 99_updatefhem.pm" l�dt wieder die alte Datei
> herunter.
>
> Viele Gr��e,
> Christian
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo zusammen,
ich habe am 21.05. "updatefhem housekeeping clean yes" durchgeführt. Lief
alles ohne Fehlermeldung durch.
Leider habe ich so das Gefühl, dass ich seither mit "updatefhem" keine
Updates mehr bekomme. Im SVN-Repo befinden sich Änderungen von vor zwei
Tagen, die aber irgendwie nie bei mir ankamen.
Kann es sein, dass da was nicht stimmt?
Gruß, Thorsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Achtung: Sammelantwort für Guido, Christian, puschel74 und thebartman ;-)
Rudi schrieb heute, das er während unserer Test wohl das Uploaden neuer
Dateien zwecks debugging auskommentiert hatte. Das sollte die Ursache Eurer
fehlenden Updates behoben haben.
Also einfach nochmal probieren.
Gruß Martin
Am Freitag, 25. Mai 2012, 05:05:22 schrieb Guido:
> Hallo,
>
> habe vorgestern auf meiner FB7390 updatefhem houskeeping clean yes
> ausgeführt, ist auch problemlos durchgelaufen.
>
> 2012.05.23 10:12:01.815 1: updatefhem Housekeeping finished, 'shutdown
> restart' is recommended! 2012.05.23 10:12:01.818 1: updatefhem New version
> of fhem.pl, 'shutdown restart' is required!
>
>
> 2012.05.23 10:19:41.779 0: Server started (version 5.2+SVN from 2012-05-13
> ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 10305)
>
> Was mich nur wundert ist das ich seitdem kein Update mehr erhalte.
>
> Was ich versucht habe:
>
> 1. filetimes.txt gelöscht und updatefhem ausgeführt, es wurden alle Dateien
> erneut heruntergeladen shutdown restart ausgeführt 2012.05.24 10:55:39.367
> 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
> 2012.05.24 10:56:09.051 0: Server started (version 5.2+SVN from 2012-05-13
> ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 4823)
>
> immer noch alte fhem.pl
>
> 2. 2012.05.25 13:00:55.678 1: updatefhem updated FHEM/99_updatefhem.pm
> damit erhalte ich diese Version: $Id: 99_updatefhem.pm 1569 2012-05-20
> 15:24:11Z mfr69bs $ ist doch auch schon was älter dann nochmal updatefhem
> fhem.pl ausgeführt
> 2012.05.25 13:12:52.813 1: updatefhem updated ./fhem.pl
> 2012.05.25 13:12:52.837 1: updatefhem New version of fhem.pl, 'shutdown
> restart' is required! 2012.05.25 13:13:03.378 0: Server shutdown
> 2012.05.25 13:13:15.378 0: Server started (version 5.2+SVN from
> 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid
> 8687)
>
> immer noch die vom 12.05
>
> Woran kann das liegen? Ist das nur bei mir so ?
>
> fragende Grüße
>
> Guido
>
> Am Freitag, 25. Mai 2012 13:00:25 UTC+2 schrieb Martin Fischer:
> > danke rene für die rückmeldung!
> >
> > Am Freitag, 25. Mai 2012, 02:40:00 schrieb Echo:
> > > Auch auf meiner "normalen" Fritzbox 7390 ist der h parameter bei tar
> >
> > > vorhanden:
> > rudi hat das heute auch noch mal korrigiert. bei der 7390 ist es dabei,
> > bei
> > der 7270 nicht.
> >
> > das thema wird gerade auf der fhem-developers liste behandelt.
> >
> > gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Was ist denn aus Jörg's folgendem Problem geworden
> Something went wrong during backup:
> sh: can't create ./backup/FHEM.2012-05-20_19:03:51.tar.gz: Invalid
> argument
> tar: short write
> The operation was canceled. Please check manually!
Ich bekomme nämlich genau die gleiche Fehlermeldung.
Das von Martin nachgefragte
> kannst du bitte mal folgenden befehl manuell auf der fritzbox ausführen:
>
> (tar -C -cf - FHEM | gzip > /FHEM.12345678.tar.gz) 2>&1
funktioniert bei mir (FritzBox 7270, kein Freetz) ohne Probleme.
JoWiemann wrote:
> Hallo ihr Beiden,
>
> bekomme folgende Fehlermeldung:
>
> Something went wrong during backup:
> sh: can't create ./backup/FHEM.2012-05-20_19:03:51.tar.gz: Invalid
> argument
> tar: short write
> The operation was canceled. Please check manually!
>
> Verzeichnis ./backup wurde angelegt, mit Schreibrechten.
>
> Betreibe FHEM auf einer FB7170 mit Freetz und FHEM 5.2 aus dem Archiv
> FB7270.
>
> Danke Euch und herzliche Grüße
>
> Jörg
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Mittwoch, 30. Mai 2012, 01:19:22 schrieb NeuBeiFhem:
> Was ist denn aus Jörg's folgendem Problem geworden
das kann ich dir nicht sagen, da ich entweder dir rückmeldung von jörg
überlesen habe oder es tatsächlich keine gab. laut meiner liste ist es
letzteres.
aktuell löse ich gerade die backup-fuktion aus updatefhem heraus (siehe auch
fhem-developers). ich denke das sollte dann in dem zuge betrachtet und weiter
verfolgt werden. eine erste _testversion_ von backup ist schon im svn. und
kann über updatefhem bezogen werden.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> aktuell löse ich gerade die backup-fuktion aus updatefhem heraus (siehe auch
> fhem-developers). ich denke das sollte dann in dem zuge betrachtet und weiter
> verfolgt werden. eine erste _testversion_ von backup ist schon im svn. und
> kann über updatefhem bezogen werden.
So ähnlich bin ich über das Problem weggekommen: backup manuell
gemacht und dann im 99_updatefhem die entsprechenden Aufrufe
auskommentiert (nachdem es wohl auch keine Möglichkeit gab, regulär
das Backup auszuschalten.
Peter
On May 31, 9:02 pm, Martin Fischer wrote:
> Am Mittwoch, 30. Mai 2012, 01:19:22 schrieb NeuBeiFhem:
>
> > Was ist denn aus Jörg's folgendem Problem geworden
>
> das kann ich dir nicht sagen, da ich entweder dir rückmeldung von jörg
> überlesen habe oder es tatsächlich keine gab. laut meiner liste ist es
> letzteres.
>
> aktuell löse ich gerade die backup-fuktion aus updatefhem heraus (siehe auch
> fhem-developers). ich denke das sollte dann in dem zuge betrachtet und weiter
> verfolgt werden. eine erste _testversion_ von backup ist schon im svn. und
> kann über updatefhem bezogen werden.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nabend...
bei mir kommt unter updatefhem housekeeping:
Please note: It seems as if 'updatefhem ' has already executed.
The operation is canceled now. Please check manually!
Was kann das sein???
Fritzbox7170 der www/pgm2 Ordner ist auch leer, soll das so sein???
Mfg Steffen
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Mittwoch, 13. Juni 2012, 11:49:13 schrieb Steffen:
> Nabend...
> bei mir kommt unter updatefhem housekeeping:
>
> Please note: It seems as if 'updatefhem ' has already
> executed. The operation is canceled now. Please check manually!
>
>
> Was kann das sein???
>
> Fritzbox7170 der www/pgm2 Ordner ist auch leer, soll das so sein???
ich kann nur vermuten... du hast updatefhem housekeeping mehrfach aufgerufen
und dabei ging irgendwas schief.
der ordner www/pgm2 wird erzeugt und dann wird "aufgeräumt". die meldung, das
housekeeping bereits schonmal aufgerufen wurde, prüft ganz zu beginn ob der
ordner www/pgm2 exisitert. also muss _vorher_ bereits einmal updatefhem
housekeeping aufgerufen worden sein.
wenn der ordner www/pgm2 tatsächlich leer ist, dann kannst du ihn manuell
löschen und danach nochmal das "updatefhem housekeeping [clean yes]" aufrufen.
gruß
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
habe jetzt erst wieder Zeit.
Updatefhem zeigt nun folgendes Ergebnis:
tar: /tmp/fhem.save: No such file or directory
tar: read error: Input/output error
backup done: FHEM-20120617_200157.tar.gz (369130 Bytes)
updated ./CHANGED
updated FHEM/10_CUL_HM.pm
updated FHEM/59_Twilight.pm
updated FHEM/95_holiday.pm
updated www/pgm2/commandref.html
reloading module 59_Twilight
reloading module 95_holiday
update finished
Herzliche Grüße
Jörg
On 31 Mai, 21:02, Martin Fischer wrote:
> Am Mittwoch, 30. Mai 2012, 01:19:22 schrieb NeuBeiFhem:
>
> > Was ist denn aus Jörg's folgendem Problem geworden
>
> das kann ich dir nicht sagen, da ich entweder dir rückmeldung von jörg
> überlesen habe oder es tatsächlich keine gab. laut meiner liste ist es
> letzteres.
>
> aktuell löse ich gerade die backup-fuktion aus updatefhem heraus (siehe auch
> fhem-developers). ich denke das sollte dann in dem zuge betrachtet und weiter
> verfolgt werden. eine erste _testversion_ von backup ist schon im svn. und
> kann über updatefhem bezogen werden.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
hallo jörg,
Am Sonntag, 17. Juni 2012, 11:04:32 schrieb JoWiemann:
> [...]
> Updatefhem zeigt nun folgendes Ergebnis:
> tar: /tmp/fhem.save: No such file or directory
> tar: read error: Input/output error
> backup done: FHEM-20120617_200157.tar.gz (369130 Bytes)
> updated ./CHANGED
> updated FHEM/10_CUL_HM.pm
> updated FHEM/59_Twilight.pm
> updated FHEM/95_holiday.pm
> updated www/pgm2/commandref.html
> reloading module 59_Twilight
> reloading module 95_holiday
> update finished
so ganz schlau werde ich aus deiner mail nicht. bis auf den fehler mit dem
fehlenden /tmp/fhem.save kann ich keine weiteren probleme sehen.
läuft es denn jetzt?
martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin,
Prima Arbeit, was Ihr so in Eurer Freizeit zum Nutzen von vielen stillen Mitlesern und Anwendern so leistet. Bin leider nicht fit in Linux, versuche aber Perl zu verstehen und mein Fhem läuft recht ordentlich.
Zu meiner Frage: im Prozess der Veränderung des Updateprozesses von Fhem erzeugte Mitte Ende das System ein tar File mit einigen . und : ten im Namen. Wie werde ich das wieder los (und ggf auch weitere Update.tar) - die lassen sich offenbar nicht einfach löschen?
Mein System FB 7390 mit fhem als root von der fhem website, CUL ....
Danke
Det.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
hallo det,
Am Montag, 18. Juni 2012, 11:27:14 schrieb Tapir Fink:
> [...]
> Frage: im Prozess der Veränderung des Updateprozesses von Fhem erzeugte
> Mitte Ende das System ein tar File mit einigen . und : ten im Namen. Wie
> werde ich das wieder los (und ggf auch weitere Update.tar) - die lassen
> sich offenbar nicht einfach löschen? Mein System FB 7390 mit fhem als root
> von der fhem website, CUL ....
erstmal danke für die blumen!
die "sonderzeichen" waren mal in der vorherigen backuproutine von RueBe und
werden inzw. nicht mehr (aus genau deinen benannten gründen) benutzt.
unter einen *nix-system musst du diese special characters entweder "escapen"
(entwerten) oder in single quotes (') setzen um sie zu löschen.
beispiel:
DATEINAME-18.06.2012 20:48:10.tar
dann solltest du sie löschen können durch:
rm DATEINAME-18.06.2012\ 20\:48\:10.tar
oder
rm 'DATEINAME-18.06.2012 20:48:10.tar'
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com