Hinweis/Notice: updatefhem geändert!

[rudolfkoenig]

                                                   

> 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

[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..

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

[Martin Fischer]

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

[rudolfkoenig]

                                                   

> 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

[Guest]

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

[Guest]

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

[Mr. P]

                                                       

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

[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

[Guest]

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

[Guest]

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

[Mr. P]

                                                       

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

[Oskar]

                                                     

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

[Guest]

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

[Martin Fischer]

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

[Martin Fischer]

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