Autor Thema: Unterstützung bei Aktualisierung von https://fhem.de/HOWTO_DE.html gesucht!  (Gelesen 10740 mal)

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 833
Kann FHEM noch auf Fritzboxen installiert werden? Dachte, dass hätte AVM mal unterbunden. Wenn's nicht mehr geht, würde ich nämlich alles diesbezüglich weg lassen. Oder eigentlich sowieso.
VPN/Apache-Proxy würde ich auch nicht erwähnen. Das greift zu weit.

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4001
@drhirn:
Vorab: Danke für die Rückmeldung!
Aber bezieht sich deine Antwort auf das txt oder die aktuelle Fassung bei fhem.de?

In dem oben angehängten txt-File findet sich nur an einer Stelle eine Fritzbox. Da geht es um vpn und das sollte m.E. dann inhaltlich auch noch passen, im übrigen ist es wie hier in dem Thread schon als ok besprochen raus.
Und ja, die Installation auf einer Fritte geht wohl noch, wenn man die Dinger genügend verbiegt...

Zu vpn/Apache: vpn würde ich drin lassen, zu Apache/reverseProxy hatte ich das noch mit dem Hinweis drin, dass man das auch nach meinem Eindruck besser woanders unterbringen sollte (wer und wo! Ich habe keine wirkliche Ahnung von sowas und bin daher nicht der Richtige). vpn würde ich deswegen drin lassen, weil es genug Leute gibt, die sonst das Stichwort noch nie als "offizielle" Empfehlung gehört haben und dann einfaches Portforwarding einrichten und sich über Sicherheit gar keinen Kopf machen, weil sie glauben "allowed" wäre ausreichend...

EDIT: anbei eine etwas aktualisierte Fassung (nur ProxyServer durch ReverseProxy ersetzt).
« Letzte Änderung: 07 März 2018, 13:34:58 von Beta-User »
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 833
Sorry, bin irgendwie beim Lesen des txt und der aktuellen Fassung durcheinander gekommen. Im txt steht eh nichts mehr von Fritzbox.

Ok, das VPN-Argument ist gut. Und den Hinweis bzgl. Apache-Text woanders-unterbringen habe ich gelesen. Wollte dich damit nur bestätigen.

Ich denke, wenn sich einer mit ReverseProxy beschäftigen will, ist er eh schon fortgeschritten genug, um selber die Anleitungen im Forum/Wiki zu finden. Das könnte man also auch einfach nur mit einem Satz - wie beim VPN - abhandeln.

Offline Christoph Morrison

  • Developer
  • Full Member
  • ****
  • Beiträge: 390
    • Private Website
EDIT: anbei eine etwas aktualisierte Fassung (nur ProxyServer durch ReverseProxy ersetzt).

Ein paar zufällige Gedanken, während ich das Dokument gelesen habe:

Ich hab mir deinen Vorschlag mal durchgelesen und dabei versucht, alles was ich bereits über FHEM weiß, zu vergessen. Ich bin bereits am zweiten und dritten Absatz gescheitert, denn der Text geht viel zu schnell auf die Ebene, in der man aktiv etwas machen muss und erklärt überhaupt nicht, warum und wann (z.B. welche Kombination aus OS, Plattform und Transceiver führt zu welchen Schritten). Das sollte eigentlich alles in die Sektion über USB-Geräte.

Lustig ist auch, dass die Installation von FHEM (im gleichnamigen Abschnitt und auch sonst wo) eigentlich überhaupt nicht behandelt wird. Was ist mit dem Debian-Paket? Gibt es andere Möglichkeiten, z.B. Docker? Das make-Beispiel wird in vielen Fällen fehlschlagen, da nirgendwo steht, dass man sich FHEM erst mal als Sourcecode runterladen muss (nicht vergessen: Das richtet sich an Anfänger, nicht an Leute die sowas schon mal gemacht haben) und dass man dann auch noch in das entpackte Verzeichnis wechseln sollte, bevor man make ausführt.

Ist telnet wirklich eine "Standard TCP/IP Weboberfläche"?

Der ganze Teil über Sicherheit geht viel zu tief in die Materie und sollte auf eine eigene Seite, die dort natürlich verlinkt ist, ausgelagert werden. Maximal das Thema allowed und das Abraten von port forwardings sollte dort hin. Dito geht der Abschnitt über USB-Geräte in Bereiche, die über "Erste Schritte" weit hinausgehen.

Es sollte einen Bereich geben, in denen wichtige Begriffe und die Kernkonzepte von FHEM erklärt werden (was sind Events/Trigger/Aktoren/Sensoren, etc. pp.)

PERL = Perl
LINUX = Linux

tbc
« Letzte Änderung: 07 März 2018, 18:51:01 von Christoph Morrison »

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4001
Ein paar zufällige Gedanken, während ich das Dokument gelesen habe:
Vorab: Danke für's lesen! Und auch bei der Gelegenheit noch für deine anderen bisherigen Aktivitäten zur Verbesserung der Doku!

Der Text"vorschlag" hält sich erst mal recht eng am historischen Vorbild, aber du hast natürlich recht damit, dass man das  - bzw. auch das gesamte Umfeld der "Einsteiger-Literatur" nochmal gründlich überarbeiten sollte.

Bevor ich hier anfange, auf die berechtigten Kritikpunkte einzugehen: Welches ist die richtige Vorgehensweise für die Weiterbearbeitung des Textes?

Im Wiki habe ich noch keinen Entwurfsmodus entdeckt, mit dem man vorbereitend editieren kann, ohne dass alles gleich online ist. Wäre das eher was für github? Wir können gerne dein Repo nutzen (das du für die Verbesserungsvorschläge eingerichtet hattest)...

Vorschläge sind willkommen, ich freue mich jedenfalls, dass hierzu endlich eine gewisse konstruktive Diskussion in Gang kommt bzw. dann irgendwann auch das Anliegen von krikan erledigt sein sollte :) .
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Christoph Morrison

  • Developer
  • Full Member
  • ****
  • Beiträge: 390
    • Private Website
Bevor ich hier anfange, auf die berechtigten Kritikpunkte einzugehen: Welches ist die richtige Vorgehensweise für die Weiterbearbeitung des Textes?

Ich glaube, ich würde sowas über ein live document wie z.B. Google Docs machen. So ein Wiki ist zwar im Prinzip ein gutes Tool zu Kollaboration im größeren Stil, aber halt nur am gesamten Textkorpus und nicht an einem einzelnen Lemma (= Artikel, Seite, was auch immer). Alternativ gibt es einen Maintainer für eine Seite, der change requests für sie annimmt, ansonsten aber die Oberhoheit hat (wie im Repository). Letzteres bildet MediaWiki über die gesichteten Versionen ab.

Beides funktioniert und beides hat seine Vor- und Nachteile.


Zitat
Im Wiki habe ich noch keinen Entwurfsmodus entdeckt, mit dem man vorbereitend editieren kann, ohne dass alles gleich online ist. Wäre das eher was für github? Wir können gerne dein Repo nutzen (das du für die Verbesserungsvorschläge eingerichtet hattest)...

Ich glaube Github ist dazu zu schwerfällig

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6047
Der Text"vorschlag" hält sich erst mal recht eng am historischen Vorbild, aber du hast natürlich recht damit, dass man das  - bzw. auch das gesamte Umfeld der "Einsteiger-Literatur" nochmal gründlich überarbeiten sollte.
Mir persönlich gefällt gerade die Anlehnung an das kurze, knappe, technische "Original".
Die Zielgruppe ist nach meinem Verständnis ein wenig anders als Erste Schritte bzw. Einsteiger-PDF, die ich nicht ersetzen wollte.
Aber letztlich bestimmt ihr als Bearbeiter und Schreiber, wohin die Reise geht.  :)

Zitat
Welches ist die richtige Vorgehensweise für die Weiterbearbeitung des Textes?
Wiki ist gerade für die gemeinsame Bearbeitung da. Änderungen kann man nachverfolgen, rückgänig machen,..
Auch wenn es direkt online ist, sehe ich kein Problem. Ich hätte dann meine Gedanken beim Lesen eben auch direkt eingearbeitet.
Im Wiki kann man direkt bsw Links passend setzen und kontrollieren, während man bei externen Dokumenten nachher ein- und nachpflegen muss. Finde ich persönlich zu anstrengend. Aber letztlich egal....

@Beta-User: Daumen hoch.

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4001
So, erste Fassung ist online unter https://wiki.fhem.de/wiki/HOWTO.

Sehe das ähnlich, dass das eine Kurzeinführung für Leute sein sollte, die Grundlagenkenntnisse mitbringen und einen schnellen Überblick haben wollen oder eine Kurzreferenz suchen. Nicht komplette noobs (aber wer weiß am Anfang schon alles...?). Daher gefällt auch mir der knappe, sachliche Stil.

Was ich noch geändert habe:
- Installation gekürzt auf den Hinweis, dass das direkt auf fhem.de beschrieben ist
- Den ersten USB-Teil aus der Einleitung zu USB-Devices verschoben, da macht er sich in der Tat besser
- Apache raus
- Schreibweisen auf Linux und Perl geändert
EDIT: - Hinweis auf regex101.com aufgenommen
- diverse Formatierungsversuche...

Wer mag, kann jetzt also gerne direkt verbessern - das ist eine Einladung!

(Ich selbst finde den Editor im Wiki aber echt gewöhnungsbedürftig, aber was soll's. Und den Link auf den Event Monitor in funktionsfähiger Form einzubauen, ist mir leider auch nicht gelungen...)
« Letzte Änderung: 07 März 2018, 22:31:22 von Beta-User »
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline curt

  • Full Member
  • ***
  • Beiträge: 261
Insbesondere (aber nicht nur) bei der Aktualisierung des Abschnitts https://fhem.de/HOWTO.html#security könnte ich Hilfe gebrauchen (siehe auch https://forum.fhem.de/index.php/topic,72629.0/all.html).

So, erste Fassung ist online unter https://wiki.fhem.de/wiki/HOWTO.

Darf ich als immernoch-Neuling dazu etwas sagen?

(Mein persönlicher Hintergrund: FHEM übe ich fleißig, habe immerzu Fragen, immerzu etwas nicht verstanden. Security allgemein kann ich.)

Ich lese also die "erste Fassung" wie frisch geboren. Das bisherige howto kenne ich nicht, habe ich ganz bewusst nicht gelesen. Also bin ich die perfekte Zielgruppe.

Bei der "ersten Fassung" fällt mir beim Überfliegen auf, dass die Ebenen wild durcheinander gehen. Mal WAN, mal intranet, dann mal schalte-Lampe ein. Hmmm.

Ich würde mal umgekehrt fragen wollen: Was ist jetzt eigentlich das Ziel des Dokuments? Beim ersten Überfliegen ist das für mich nur teilweise erkennbar.

Wenn wir "security" ernst nehmen, ist der erste Schritt eine Bedrohungsanalyse. Der zweite Schritt wäre dann, die verschiedenen Bedrohungsebenen genau zu betrachten. Ganz rational haben wir vier:

1) Aktualität des Betriebssystems des FHEM-Wirts. Allgemeine Sicherheit des FHEM-Wirts. Aktualität des FHEM-Daemon.

2) Datenweg WAN (das böse Internet) <-> FHEM-Server. Offene Ports. Aktiv angestoßene unverschlüsselte Übertragung.

3) FHEM im Intranet. Angreifer (gern Agent) greift von innen an. Weitere Bedrohung WiFi-Sicherheit. Ansonsten wie 1).

4) Sensoren/Aktoren die mit dem FHEM-Server interagieren. Unverschlüsselt. Angriffsszenarien. Abwehrmöglichkeiten. (Ggf. Unterpunkt Aktoren via fhemweb: Risiko Codeeinschleusung.)

Ich denke, dass (in meinem Denkbild) der Absatz "Installation" stehen bleiben kann und vielleicht muss. Das bietet dem Techniker einen groben Überblick, wo Schnittstellen zu 1) und 2) aufgemacht werden.

Hingegen passt im Sinne von security der Abschnitt "Einbinden und Konfiguration von Sensoren und Aktoren" überhaupt nicht. Der gehört (anders gestaltet) unter 4). Dort müsste diskutiert werden, wie man z-B. die automatische Erkennung komplett ausschaltet, selektiv einschaltet, fremde Geräte erkennt. [¹]

Nach "Installation" müsste es aus meiner Sicht mit der Abarbeitung der Punkte 1-4 weiter gehen. Und es kann und darf bei "security" wirklich nur um Security gehen - nicht darum, wie man eine Lampe einschaltet.


Bitte nicht böse sein. Ist ja nur eine Einzelmeinung, quasi ein Einzelfall. ;)
Insbesondere @Beta-User : Du hast Arbeit investiert. Und nun kommt einer und mault rum. Ich weiß. Sei bitte nicht böse.

[¹] Neben mein-klein-Haus sind recht viele andere klein-Häuschen bei guten Empfangsbedingungen. Ich habe gut 80 Sensoren/Aktoren meiner Nachbarn bei. Ich weiß, dass da ein Fenster auf ist, wie warm es ist, ich kann Nachbars Garage aufmachen. Könnte - mache ich nicht. no harm to the network.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16076
Kurze Frage, habe es nie gemacht und auch nie getestet. Ist ein Devicename mit Punkt zulässig?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3408
    • _.:|:._
Ja. Siehe fhem.pl/goodDeviceName($)
Informativ Informativ x 1 Liste anzeigen

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 4001
Darf ich als immernoch-Neuling dazu etwas sagen?
[...]
Bitte nicht böse sein.
Gerne! Deswegen diskutieren wir öffentlich und insbesondere hier geht es auch darum, Meinungen und Eindrücke auszutauschen. Also jedenfalls von meiner Seite: Alles gut, der Dank für die investierte Zeit geht in gleicher Weise zurück :D .

Was deine Einwände zum Abschnitt Security angeht, sind das m.E. alles valide Punkte. Es stellt sich - wie auch die Anmerkung von Christoph Morrision aufzeigt - immer die Frage, was noch da reingehört, und was ggf. in einen separaten Artikel. Hier würde ich sagen, dass die Überschrift "Sicherheit" zu pauschal ist. Eigentlich sollte da m.E. _an der Stelle_ nur etwas wie "Absicherung der FHEM-Serverkomponente" stehen. Dazu gehören dann allowed und die dort derzeit aufgeführten Stichworte, was ggf. noch zusammengefasst werden kann.
Auf die weiterführenden Themen sollte ggf. im Rahmen der Planung (https://wiki.fhem.de/wiki/Planung) eingegangen werden oder in einem separaten Artikel, auf den nur im Rahmen eines Hinweiskastens zu verweisen wäre.
(An Christoph Morrision: Ich habe leider keine Ahnung, ob das mit TCP/IP und telnet sachlich korrekt ist, da ich bis dato davon ausgegangen war, dass der ursprüngliche Autor (Rudi?) wußte, was er da schreibt.)

Zur Darstellung der USB-Themen:
Nach meinem persönlichen Eindruck ist das zwar lang, sprengt aber noch nicht den Rahmen. Denn irgendwo muß man ja anfangen, Begrifflichkeiten und Zusammenhänge "im Fluß" darzustellen. Allerdings ist auch hier die Überschrift "USB Geräte" nicht unbedingt glücklich gewählt. Vorschlag hier: "Schnittstellen zur realen Welt, insbesondere USB-Geräte"?
Dazu eine kurze Einführung, dass es eigentlich nur zwei Wege gibt, wie FHEM an Infos aus der Außenwelt kommen kann - via serieller Schnittstelle oder eben via TCP/IP. (Dazu kurz eine Frage: Wer nur ser2net oä. nutzt, benötigt dann auch das libserial-perl-modul, oder?)
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 833
Ich stell jetzt mal ganz provokant eine Frage, die mir beim Durchlesen des HOWTOs gekommen ist: Braucht's das HOWTO überhaupt?
Was ich damit sagen will, wir haben die Installationsanleitung, das HowTo, das "FHEM für Einsteiger"-PDF und die "Ersten Schritte in FHEM". Das ist schon fast etwas Overkill, nicht? Wär's nicht sinnvoller, EINE Anlaufstation zu haben, die dann auch gerne etwas ausführlicher sein darf?

(P.S.: Weil's mir grad aufgefallen ist: Im Anfängerfragen-Bereich heißt's noch "pdf-eBook zum Einstieg in fhem" und "Kleiner fhem-Kurs: Erste Schritte in fhem".)

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6047
Braucht's das HOWTO überhaupt?
Spielverderber.   ;D

Der Ersteller des HOWTOs (Rudi) hatte mit dem Löschen keine Probleme.
Ich fand es aber persönlich als Kurzüberblick statt "Erste Schritte"/"Einsteiger-PDF" ganz sinnvoll und habe Erhaltung befürwortet.
HOWTO ist für den Lesertyp: erst HOWTO, dann commandref. Auch so kann man nämlich zum Ziel kommen.
Darum (und auch aus anderen Gründen) ringe ich in Beta-Users Vorschlag auch mit der Angabe von Hardwareempfehlungen (raspberry); würde das eigentlich gerne herausnehmen.

Ja, wir haben Dopplungen und Überschneidungen. Lösung: ?

Zitat
(P.S.: Weil's mir grad aufgefallen ist: Im Anfängerfragen-Bereich heißt's noch "pdf-eBook zum Einstieg in fhem" und "Kleiner fhem-Kurs: Erste Schritte in fhem".)
Poster (Uli?) bitte ansprechen. Ich mag nicht in fremden Posts editieren.

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 833
Spielverderber.   ;D
Immer ;D

Zitat von: krikan
Darum (und auch aus anderen Gründen) ringe ich in Beta-Users Vorschlag auch mit der Angabe von Hardwareempfehlungen (raspberry); würde das eigentlich gerne herausnehmen.
War mir auch ein Dorn im Auge. Andererseits könnte es uns davor retten, dass alle anfangen, FHEM auf Windows zu installieren. Ein Raspberry ist eine kleine Einstiegshürde.

Zitat von: krikan
Ja, wir haben Dopplungen und Überschneidungen. Lösung: ?
Wie gesagt, eine Anlaufstation. Ein Wiki-Artikel, der mal alles überblicksmäßig abhandelt. Von Installation über Erstkonfiguration über Sicherheit über Einbinden von Geräten über Notifys über ...
Also im Prinzip das HOWTO ergänzt um Informationen aus den anderen Quellen. Mit Links zu weiterführenden Informationen.
Steinigt mich, aber mir ist auf die schnelle keine andere Seite als Beispiel eingefallen. Und meine Finger weigern sich, es zu tippen. Aber wie hier könnte ich mir das vorstellen.

Zitat von: krikan
Poster (Uli?) bitte ansprechen. Ich mag nicht in fremden Posts editieren.
Mach ich.

 

decade-submarginal