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 Erweitern

www/signal/:
chrome-x11-snapshot.png  firefox-x11-snapshot.png  signalcaptcha.desktop  signalcaptcha.reg  signal_install.sh
wobei 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 Erweitern

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?

[Adimarantis]

thirdparty wird eben nicht verteilt (an dem Verzeichnis war ich mit Schuld )
Aber wenn lib verteilt wird (zumindest habe ich da drin Dateien neueren Datums) - warum nicht?
Bisher sind da nur .pm files drin. Gibt es da eine Verzeichnis-Konvention?
Schaut ein wenig nach "lib/FHEM" gefolgt von einem Modulnamen bzw. Oberbegriff aus

Wäre das dann lib/FHEM/Messenger?
oder eher doch lib/FHEM/Scripts?
oder sogar lib/Scripts da eben eigentlich kein FHEM Bestandteil?

[Adimarantis]

Falls Admins mitlesen, erstmal eine Bitte:
Könnt ihr den Signalbot Thread https://forum.fhem.de/index.php/topic,118370.0.html
von "Codeschnipsel" nach "Unterstützende Dienste" verschieben?
Ich wollte das Modul demnächst offiziell einchecken und Codeschnipsel ist wirklich nicht mehr passend - die Historie im Thread aber denke ich ist schon interessant.

Nachdem das mit den zusätzlichen Dateien hier jetzt nicht abschliessend behandelt wurde, habe ich mich für einen anderen Ansatz entschieden:
Die Dateien sind jetzt unter contrib/signal
Dort werden sie über https://svn.fhem.de/fhem/trunk/fhem/ referenziert bzw. nachgeladen.
Ein www/signal wird vom Modul lokal angelegt und verwendet.

Dadurch entsteht zwar eine Abhängigkeit zum SVN Server, aber ohne Internet funktioniert Signal sowieso nicht und die Dateien werden nur anfangs beim Einrichtungsprozess benötigt.

[rudolfkoenig]

Könnt ihr den Signalbot Thread https://forum.fhem.de/index.php/topic,118370.0.html
von "Codeschnipsel" nach "Unterstützende Dienste" verschieben?

Erledigt.

[Christoph Morrison]

Was spricht gegen bin/ neben lib/ für executables?

[rudolfkoenig]

Wenn wir mit bin anfangen, dann muessen wir OS und/oder CPU-Architektur beruecksichtigen, z.Bsp. ueber Unterverzeichnisse.
Ich will ungern damit anfangen, und empfehle stattdessen perl

[Christoph Morrison]

Wenn wir mit bin anfangen, dann muessen wir OS und/oder CPU-Architektur beruecksichtigen, z.Bsp. ueber Unterverzeichnisse.

Ja gut, ist ein Punkt.

Ich will ungern damit anfangen, und empfehle stattdessen perl

Das ja auch nicht völlig Plattform-/Archtitektur-unabhängig ist.

Der TE hat ja gefragt ob er seine Skripte in lib/ packen soll. Im CPAN ist es so, dass (Perl-)Executables in einem bin-Verzeichnis des Moduls liegen, z.B. hier von Perl::Critic (https://fastapi.metacpan.org/source/PETDANCE/Perl-Critic-1.140/bin/). Das finde ich eigentlich als Ort auch charmant.

lib/FHEM/Messenger/Signal/bin ist z.B. ein guter Ort für sowas, finde ich.

[rudolfkoenig]

Das ja auch nicht völlig Plattform-/Archtitektur-unabhängig ist.

Ich meine doch, man muss "nur" die Platform-abhaengigen Probleme im Code loesen, soweit das ueberhaupt sinnvoll moeglich ist.

lib/FHEM/Messenger/Signal/bin ist z.B. ein guter Ort für sowas, finde ich.

Die Haken dabei:
- wenn das per update verteilt werden soll, dann muss ich alle Verzeichnisse manuell in contrib/fhemupdate.pl einbauen, und ausrollen.
- ich bin nicht sicher, ob ich auf einem Linux-Rechner Windows-Binaries haben will, und andersherum => Architektur abhaengiges update noetig?

Ich habe kein Problem damit, wenn sowas einfach gemacht wird, eher damit, wenn das offiziell abgesegnet werden soll, weil ich dann alle weiteren Moeglichkeiten beruecksichtigen muss.

[Christoph Morrison]

Ich meine doch, man muss "nur" die Platform-abhaengigen Probleme im Code loesen, soweit das ueberhaupt sinnvoll moeglich ist.

Nur ist wirklich gut

Die Haken dabei:
- wenn das per update verteilt werden soll, dann muss ich alle Verzeichnisse manuell in contrib/fhemupdate.pl einbauen, und ausrollen.

Ich dachte $FHEMDIR/lib wird sowieso mitverteilt? Unter $FHEMDIR/FHEM/lib würde ich sowas eh nicht sehen.

- ich bin nicht sicher, ob ich auf einem Linux-Rechner Windows-Binaries haben will, und andersherum => Architektur abhaengiges update noetig?

Ist die Verteilung von Binaries nicht eh ein Problem im Lizenzkontext? Da müsste ja auch immer der Quellcode mitgeliefert werden, oder? An sich hätte ich eher weniger Sorge, Windows-Gedöns auf meinem Linux zu haben. Läuft dort vermutlich sicherer als auf Win

[betateilchen]

Hey Kollegen - gehts noch?

Da werden plötzlich 4 * 23 MB als Debian-Pakete in die FHEM svn Struktur eingepackt, die 99% aller Anwender nicht brauchen und die nur unnötigen Traffic verursachen.
Wenn das wirklich ernst gemeint ist und so bleiben soll, werde ich den Betrieb von debian.fhem.de wahrscheinlich in den nächsten Tagen einstellen.

Kann man sich nicht im Vorfeld erstmal ein paar Gedanken machen, welche Auswirkungen an welcher Stelle solche Ideen haben, bevor man sowas einfach eincheckt?

[Adimarantis]

Sorry, an den Traffik, den das erzeugt, wenn es jeder auscheckt habe ich nicht gedacht.
Gelöscht. Ich finde einen anderen Platz.