Aktualisierung Installationsanleitung im Wiki

[Morg]

Moin!

Da ich die nötigen - und teils unnötigen - Schritte der Installation von eibd, CometVisu und CometVisu-CGIs gerade frisch hinter mir habe, nehme ich mal den Editorhandschuh von Chris auf und setze mich an die Überarbeitung der Anleitung.

Bevor ich mich da hineinstürze, ein paar inhaltliche Fragen, damit ich nicht in die falsche Richtung arbeite:

1. Soll die Pflege auf Englisch erfolgen, soll eine deutsche Version erstellt werden (gibt es eine!?) oder was wäre gewünscht?
2. Wenn ich die Diskussionen, die ich bisher verfolgt habe, richtig verstanden habe, sollte das Repo an der TU Wien aus der Doku verschwinden (nach Dateilisting Stand ~2006) und durch das Repo bei Wiregate (~2011) ersetzt werden?
3. Ich versuche mich mal parallel an den Sourcen des knxd bei GitHub. Ist es sinnvoll, das jetzt schon zu integrieren? Oder sollte ich / man das später machen, wenn ggf. ein verfügbares Repo dann auch Pakete mit knxd bereit hält?

Weitere Fragen schreibe ich mal hier hinein, soweit sie auftauchen - oder gehört die Diskussion woanders hin?

Gruß
Sebastian

[Chris M.]

1. Deutsch und Englisch wäre der Wunsch. Swiss hat da zur Unterscheidung am Seitenende ein /de bzw. /en angehängt
2.+3. Nun das Repro der TU Wien wird nicht mehr aktiv gepflegt, das dort relevante ist nach GitHub zum knxd weitergezogen. Der WireGate Repository wird gepflegt, da ist ja ein aktives Produkt dahinter

Diskussionen sind hier genau richtig

[Morg]

Ist das Skript "install_eibd.sh" von Michael Albert (http://michlstechblog.info/blog/rasp...r-with-the-pi/) bekannt? Das habe ich auf meinem Raspi mal ausprobiert und es nimmt einem die meiste Arbeit ab. Wäre die Frage, ob man das verlinken soll - im Prinzip macht es ja genau das, was in der Installationsanleitung beschrieben ist... wobei es natürlich die Doku nicht ersetzt

[Chris M.]

Zumindest mir ist es nicht bekannt...

Ein Skript ist grundsätzlich nicht falsch - aber das Problem ist dabei, dass wir so auf eine Quelle verlinken die wir nicht "kontrollieren" können. D.h. wenn die Datei heimlich durch Spyware o.ä. ersetzt wird, würden wir das wohl nicht mitbekommen und die Leute fehlleiten.
=> Ich kann gerne mal Michael Albert fragen, ob er das Script nicht in einem verbreiteten Versionskontrollsystem ablegen will (z.B. unter Open Automation)

[Morg]

Ist mir soweit klar. Ich würde das ggf. unter weiteren Links mit angeben.

Auch wenn es hier im Schwerpunkt um die Installation von CometVisu gehen soll, scheint mir, dass die meisten Nutzer eher Probleme haben, die Voraussetzungen - eibd/knxd - ans Laufen zu bekommen.

Ich könnte ein Debian-Repo mit aktuellen (0.9.0-1) knxd-Binaries anbieten, so dass Debian-User (7.x) das ohne weitere Probleme nutzen/installieren können. Unter squeeze habe ich knxd aufgrund von Problemen mit der libusb nicht ans Laufen bekommen.
Bei Ubuntu habe ich zwar Source- und Binary-Pakete (.deb) erstellt; ich verstehe aber nicht, wie ich die für ähnlich einfachen Zugriff veröffentlichen kann (außer als Binary-Download der .deb....)

Ich würde empfehlen, dass wir die Installation des eibd/knxd in einen gesonderten Wiki-Artikel auslagern (und auf das knxd-Wiki verweisen, falls der Fokus von den reinen Entwicklern mal zu einer "normalen" Doku werden sollte). Das schüfe zum Einen eine klare und klar strukturierte Anleitung für die Installation vom eibd bzw. knxd und würde zum Anderen den Artikel zur Installation von CometVisu deutlich entlasten.

Mein Ansatz:
1. Installation CometVisu / knxd trennen -> 2 Artikel
2. Artikel CV entschlacken, klarer strukturieren
3. Artikel knxd auf aktuellen SW-Stand fokussieren und vereinfachen; Verweis für WG-Nutzer: eibd vorinstalliert, alt. Repo
4. beide übersetzen

Ist das sinnvoll?

[Chris M.]

Ja, das ist Sinnvoll!

Für Ubuntu gibt's doch die PPAs auf Launchpad. Hab die schon paar mal genutzt - aber keine Ahnung wie man da ein eigenes anlegt.
Gerade für den eibd/knxd würde es aber absolut Sinn machen dort fertige Pakete anzubieten.

In der Doku dann darauf verweisen, so wie weiterhin(!) zeigen wie man das per Hand machen kann. (Es gibt viele die verstehen wollen, was da passiert - selbst wenn sie es dann nicht nutzen und den Service eines automatischen Updates nutzen wollen)

Wenn die knxd-Doku entsprechend gut ist (auf eibd brauchen wir hier nicht mehr zu hoffen...), dann können wir CV seitig natürlich gerne darauf verweisen. Die knxd-Doku könnte ich mir unter dessen Wiki (https://github.com/knxd/knxd/wiki) oder unter einer eigenen Web-Seite (GitHub bietet da was an, ich weiß aber nicht wie und v.a. wie gut, man das nutzen kann) vorstellen. Oder wir schreiben's in's CometVisu-Wiki - was genau das gleiche ist wie das OpenAutomation-Wiki

[Morg]

Teil 1 - bitte mal prüfen / probelesen --- und gern ausprobieren --- : http://www.cometvisu.org/wiki/CometV..._prerequisites

Ich habe sowohl die automatischen Wege für Debian (hier: 7) und Ubuntu (hier: 14.04), den automatisierten Debian-Buildprozess (aus den knxd-Sourcen) als auch einen vereinfachten manuellen Weg beschrieben. Letzterer als Rückfallposition kann natürlich nicht zu detailliert werden - erstens ist das immer noch das CometVisu-Wiki, zweitens hängt das sehr stark von der verwendeten Distro und den vorhandenen Paketen ab, da ist ggf. viel Handarbeit gefragt (u.a. libusb, libpthsem usw...)

Den CometVisu-Artikel mache ich gleich. Wenn die soweit passen, übersetze ich die gern noch ins Deutsche.

Das knxd-wiki würde ich zum derzeitigen Entwicklungsstand den Entwicklern überlassen; dafür ist IMHO noch zuviel zu tun, bis z.B. die Debian-Packagereife besteht. Oder man splittet das Wiki in einen Doku- und einen Dev-Teil. Wer macht dazu einen issue auf?

[Morg]

Teil 2 - dito: http://www.cometvisu.org/wiki/CometV...ll_from_Source

Ich bin mir nicht sicher, inwiefern die gesamte Konfiguration vom lighttpd im Artikel - oder im Wiki - bleiben soll. Da es sich aber nur auf die Anpassungen für die Nutzung der CGI-BINs bezieht, hab ichs erstmal im Wiki und im Artikel gelassen.
Die Anteile rrdtool habe ich komplett in die rrdtool-Seite verfrachtet (http://www.cometvisu.org/wiki/CometVisu/rrdtool), das schien mir inhaltlich sauberer.

Was mir auffällt: die Seite "Install prerequisites" müsste ich noch umbenennen, zB in CometVisu/Backend oder Install backend o.ä., auch wenn eigentlich nur der knxd behandelt wird...

[Chris M.]

Sehr schön!

Ich hab's zwar noch nicht praktisch nachgetestet (wer ist freiwillig?), sieht aber schon sehr komplett aus.
Diese Seiten habe ich auch mal auf der Haupt-Seite verlinkt.

Die rrdtool-Seite braucht allerdings noch etwas Polish, gerade hinter die Install Prerequisites fällt die noch ab...

[Morg]

Wenn ich mir die ganzen "Startseiten" zur Installation so ansehe, würde ich Folgendes vorschlagen:

Seite Installation: neu aus "Install from source" + "Installation Wiregate". Die Unterscheidung (de) wiregate / from source halte ich für unlogisch; dann lieber Installation -> Debain / Ubuntu / Wiregate alt / manuell. Im Englischen ist die Seite "Installation" recht... inhaltslos, also auch lieber zusammenfassen.

Ich bin morgen erstmal nicht da, aber vielleicht habe ich morgen abend Zeit, ansonsten im Laufe der Woche - dann fasse ich das alles zusammen und übersetze es noch, so dass wir de/en jeweils einen (hoffentlich) verständlichen und kompletten Satz Dokus haben.

rrdtool habe ich inhaltlich nicht wirklich gelesen, habe das nur zusammengefasst, weil es meiner Meinung nach so sinnvoller (und einfacher zu finden) ist.

[Morg]

Vielleicht kannst du dir die Seite "CometVisu/Installation/de" nochmal vornehmen. Ich kann mit dem Inhalt nicht viel anfangen. Wenn das WG nicht völlig abweichend vom Debian-Standard aufgebaut ist, würde ich aber vermuten, dass da noch Macken drin sind (soll die CometVisu-Konfiguration wirklich nach /etc/cometvisu?)
Wenn du das inhaltlich geprüft, ggf. angepasst hast, würde ich die Seite verschieben nach CometVisu/Installation/Wiregate/de und entsprechend verlinken. Der Standardfall wird in Zukunft wohl die Nutzung auf WG1.1+ sein oder die Installation auf "Fremd"systeme, wie (dann) in CometVisu/Installation/de beschrieben sein soll.

[Chris M.]

Die Seite zur Installation auf dem WireGate ist eher historisch - die stammt noch aus Zeiten, als auf dem WireGate nur die 0.6er Version direkt verfügbar war. Seit dem es die aktuellen Pakete gibt, gilt eigentlich nur noch die Warnung, dass man nicht selbst installieren sollte...

Das die Config-Dateien nach /etc/cometvisu sollen ist richtig. Dieses Verzeichnis wird per Symlink in den Verzeichnisbaum unter /var/www/<cometvisu>/ eingebunden. So sind Upgrades etc. pp. einfacher machbar. Vermutlich sollten wir das auch den ganzen anderen Installationen empfehlen.

[Morg]

Ich sehe jetzt nicht, was das vereinfachen sollte.

Wenn es darum geht, Updates der Visu einzuspielen, muss sowieso der Pfad bekannt sein. Wenn der unter /var/www/cometvisu festgelegt ist, dann ist die Konfig unter .../config genauso bekannt. Wenn der Pfad stattdessen zB unter /usr/share/cometvisu (oder /usr/lib/cometvisu) liegt, könnte man die Konfig unter /etc/cometvisu ablegen.

Auf der anderen Seite soll aber
a) die Konfig beim Update nicht überschrieben werden -> ggf. trennen, aber dann wäre der Pfad der "Userconfig" wieder egal
b) die Konfig ggf. durch den www-user und/oder durch den angemeldeten User geändert werden können -> offene Schreibrechte in /etc, gefällt mir nicht. Durch wwwuser änderbare Dateien sollten nach meinem Verständnis bitte auch im entsprechenden Verzeichnisbaum liegen. Möglich wäre aber auch, /var/www/cometvisu/ weiter zu unterteilen:

/var/www/cometvisu/etc
/var/www/cometvisu/htdocs
/var/www/cometvisu/libs
/var/www/cometvisu/plugins
usw...

Unter htdocs sollten dann nur die Sachen liegen, die tatsächlich durch den Webserver direkt angezeigt werden. Alles, was .pl/.php/.cgi usw. im Hintergrund nutzen, würde ich da raus nehmen. Und dann hätte man mit einem "abgesetzten" etc auch einen getrennten - aber festen /bekannten - Config-Ordner.

Das sind aber nur meine (eher allgemeinen) Gedanken, wie man sowas strukturieren könnte. Ich vermute mal, dass das über die Zeit gewachsen und aus den ursprünglich gedachten Kinderschuh-Verzeichnissen einfach rausgewachsen ist :-)

Ich finde /var/www sowieso seltsam (ist bei mir /srv/www), aber das ist noch ein anderes Thema.

[Chris M.]

Richtig, da ist viel gewachsen

Das /etc/cometvisu/ ist mit dem 0.8er WireGate Paket gekommen und geht auf einen Vorschlag von mit zurück, da vorher die User-Dateien und die (zu aktuallisierenden) Paket-Dateien wild vermischt waren, insb. in verschiedenen Verzeichnissen. D.h. mit /etc/cometvisu/ sind wir schon einen großen Schritt weiter.

Das nächste Release wird ziemlich sicher die 0.9 sein, d.h. wir hätten noch mal die Möglichkeit aufzuräumen. Im FHS (oder was auch immer hier relevant ist...) bin ich nicht sonderlich firm. Wenn es folglich eine bessere Möglichkeit gibt die Sachen zu trennen, die dem User "gehören" und die dem Paket "gehören", bin ich dafür sehr offen (sollten wir aber vermutlich in einem anderen Thread klären )

Da der Editor ein Web-Service ist, wird der auf die Konfig-Dateien schreibend zugreifen müssen. Und dennoch sind das User-Config-Dateien. Also keine Ahnung ob und wie man das sauberer gestalten kann.

Auf /var/www haben wir keinen Einfluss, das ist der WireGate-Default. In der Doku sollten wir für Debian u.ä. natürlich das nehmen, was dort richtig ist.

[Morg]

Letzter Kommentar dazu hier - die Voraussetzung, dass "user files" durch den Webserver geändert werden können/müssen, macht ein strukturiertes Herangehen etwas schwierig. Eine mögliche Struktur habe ich ja oben beschrieben. Da sicherheit kein Thema ist (keine Zugriffskontrolle in der Visu / im Editor), könnte man dem User, der ggf. lokal die Konfig ändert, die Gruppe www-data zuweisen oder ihn mit root-Rechten arbeiten lassen. Debian hält sich auch nicht durchgängig an den FHS

Die Seiten
CometVisu/Installation/[de,en]
CometVisu/Installation/Backend/[de,en]
CometVisu/Installation/WireGate/[de,en]
CometVisu/Installation/RRDtool/en

habe ich im ersten Wurf komplett überarbeitet und jeweils angepasst. Kleinigkeiten wie interne Verlinkungen (Kategorien, [[CometVisu]] statt CometVisu usw) sind ggf. noch offen, aber eher Makeup als Substanz.

Ich habe durch Umbenennen in den o.a. "Namensraum" auch alle Seiten, die mit Installation zu tun haben (und die ich gefunden habe ), etwas zusammengerückt. Ich hoffe, dass damit dem einen oder anderen auch tatsächlich geholfen werden kann

Am Repository habe ich jetzt verfügbar:
Debian 7: knxd, knxd-tools, knxd-examples für i386 und armhf
Ubuntu 14.04: knxd, knxd-tools, knxd-examples, libpthsem20, libpthsem-dev für i386 und amd64

Wenn ich dazu komme, mache ich ggf. noch weitere; das hängt aber davon ab, welche benötigt werden.