Verzeichnisstruktur - zusätzliche Dateien für Modul unter "www"

[Adimarantis]

Hallo,

Ich möchte demnächst den Signalbot ins normale update/svn überführen.
Dazu plane ich aber eine Reihe zusätzlicher Dateien die ich unter "www/signal" ablegen möchte, damit sie als "href" aus der FW_detailFn zugreifbar sind:

Ds würde dann so aussehen:

Code: [Auswählen]

www/signal/:
chrome-x11-snapshot.png  firefox-x11-snapshot.png  signalcaptcha.desktop  signalcaptcha.reg  signal_install.shwobei die beiden "signalcaptcha" Dateien immer dynamisch erzeugt werden und nicht ins svn müssten.

Die größte Frage hierbei ist das installer shell script. Ich habe es aktuell unter www damit es erstens auch zum Download zur Verfügung steht und zweitens automatisch aktualisiert werden kann (sollte möglichst immer zur Modulversion passen).
Die beiden .png sind Screenshots als Hilfestellung bei der Benutzerführung der Registrierung.

Gibt es Bedenken zu diesem Vorgehen?

Gruß,
Jörg

[Dr. Boris Neubert]

Hallo,

na ja, es wird dadurch nicht qualitativ schlimmer, als es schon ist, zementiert nur das Problem, dass unter /opt nur statische Dateien gehören aber FHEM dort standardmäßig Logs, .gplot-Dateien etc. hinschreibt. Ich beziehe mich auf das Debian-Package.

Filesystem Hierarchy Standard

Keine Einwände.

Viele Grüße
Boris

[rudolfkoenig]

Achtung: neue Unterverzeichnisse werden nicht automatisch per update verteilt, dafuer muss ich fhemupdate.pl anpassen und installieren.


Die FHEM Installation entsprach vor 10+ Jahren dem Linux FileSystem Standard, damit hatte ich aber deutlich mehr Probleme als mit dem einen Verzeichnis unter /opt. Wer FHEM mit dem (angepassten) Makefile installiert, der sollte weiterhin diesen Standard folgen koennen.

[Adimarantis]

Ok - kannst du dann schon mal vorsorglich ein Verzeichnis "signal" unter "www" anlegen?

Danke,
Jörg

[rudolfkoenig]

Ungern, erst wenn was eingecheckt ist.

Normalerweise begrenze ich auch die Datei-Endungen (z.Bsp. .css/.js oder .png/.jpg), in diesem Fall scheint es aber eine Sammelsurium fuer unterschiedlichste Aufgaben zu sein. Nach Gefuehl haette ich etliche (.reg, .sh, .desktop) eher im Wiki verortet.
Alternativ koennte man sie nach contrib packen, und im DetailFn ein Link dahin (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/signal) ?
Bin aber nicht tief in der Materie drin, moeglicherweise sind diese Vorschlaege nicht sinnvoll.

[betateilchen]

Die größte Frage hierbei ist das installer shell script. Ich habe es aktuell unter www damit

Installationsskripte unter ./www abzulegen finde ich nicht besonders glücklich gewählt.

[Adimarantis]

Also die pngs kann ich dir gleich hinlegen.
Das .reg und .desktop wird nicht verteilt sondern dynamisch erzeugt wenn der User den Registration Wizard verwendet - da brauchst du also nichts zu machen.
Bleibt eigentlich nur das .sh als "Sonderlocke" - und contrib wird ja nicht per update aktualisiert.

Ich könnte zwar einen Download link nach svn.fhem.de einfügen, aber die Download Option ist eher optional, da das Script ja auf dem FHEM Server (und sogar mit sudo) ausgeführt werden muss.
Wer von Windows aus auf seinen Raspi zugreift müsste das Script also immer erstmal umkopieren.

Wenn .sh ein blocking point ist, dann sehe ich höchstens noch die Option eine Unterroutine ins Modul einzubauen, die einen entsprechenden Download macht um es userfreundlich zu gestalten.
Oder es gibt einen besseren Vorschlag wo ich es hinlegen könnte?

Jörg

[betateilchen]

da das Script ja auf dem FHEM Server (und sogar mit sudo) ausgeführt werden muss.
Wer von Windows aus auf seinen Raspi zugreift müsste das Script also immer erstmal umkopieren.

Du solltest auch daran denken, dass ein Skript, was in oder unterhalb von ./www per update ausgeliefert wird, nach dem Update ohnehin nicht ausführbar ist.
Der Benutzer muss die Datei vernutlich immer zuerst manuell anpassen, bevor sie benutzt werden kann. Dann kann er die Datei auch gleich von irgendwoher laden.

[rudolfkoenig]

Der Benutzer muss die Datei vernutlich immer zuerst manuell anpassen, bevor sie benutzt werden kann.

Alternativ ruft man den per "sh /opt/FHEM/www/signal/XXX.sh" auf.
Wegen einer Datei will ich jetzt keinen Aufstand ausloesen.

[Adimarantis]

Wie gesagt am "www" hängt mein Herzblut hier gar nicht, sondern an der automatischen Verteilung.
Vielleicht ist die Frage ja schon mal aufgetauscht oder wir lösen das gleich konsistent für die Zukunft.
Ich könnte mir z.B. auch ein Verzeichnis "scripts" under "FHEM" vorstellen. Evtl. kann man da dann sogar das +x flag setzen.

Jörg

[betateilchen]

Wegen einer Datei

Principiis obsta!

[betateilchen]

Ich könnte mir z.B. auch ein Verzeichnis "scripts" under "FHEM" vorstellen. Evtl. kann man da dann sogar das +x flag setzen.

Grundsätzlich gibt es dafür ja schon einen etablierten Mechanismus:
In contrib gibt es eine Datei namens executables. Alle Dateien, die dort drinstehen, bekommen vom Makefile automatisch das x-Flag.
Allerdings wird diese Datei, weil sie in contrib liegt, auch nicht per update aktualisiert.
Irgendwie ein bisschen ein Problem, bei dem sich die Katze in den Schwanz beißt.

[Beta-User]

Wenn man sowieso shell+sudo für die Ausführung braucht und das ganze Linux-Spezifisch ist: Warum dann nicht gleich den kompletten Befehl einschließlich voranstehendem wget in die Doku aufnehmen? Dann wäre nur zu klären, ob es ein bestimmtes Verzeichnis ist, von wo aus man das absetzen muss und könnte die Datei "updatefest" evtl. auch gleich wieder Löschen, wenn sie abgearbeitet ist?
Von wo die Datei dann letztendlich (jeweils aktuell) kommt, wäre dann ziemlich egal...

[Adimarantis]

Code: [Auswählen]

Principiis obsta!Kann mir zwar denken was das heisst (hatte kein Latein) - Google behauptet es bedeutet: Steh mir von Anfang an im Weg!

Ich will hier eben auch keinen Präzedenzfall schaffen, deswegen mein Vorschlag eines evtl. konsistenteren Ansatzes.

Wenn contrib verteilt würde, dann würde ich das auch sofort nutzen - da sind ja schon andere Shellscripts. Wird es aber leider nicht.

[betateilchen]

Wenn contrib verteilt würde, dann würde ich das auch sofort nutzen - da sind ja schon andere Shellscripts. Wird es aber leider nicht.

Ich könnte mir z.B. auch ein Verzeichnis "scripts" under "FHEM" vorstellen. Evtl. kann man da dann sogar das +x flag setzen.

Es wurden in der letzten Zeit schon neue Verzeichnisse (lib, thirdparty) unterhalb von FHEM hinzugefügt, die auch per update verteilt werden.
Könntest Du Dein script nicht dort sinnvoll unterbringen?