[HINWEIS] - SVN-Repository ist zu svn.fhem.de umgezogen

Begonnen von Markus Bloch, 11 Dezember 2016, 15:15:15

Vorheriges Thema - Nächstes Thema

Markus Bloch

Hallo zusammen,

am Samstag den 17.12.2016 wurde das SVN-Repository von FHEM auf eine neue Plattform umgezogen, welche durch FHEM e.V. bereitgestellt wird. Das neue Repository ist nun unter https://svn.fhem.de/ erreichbar. Mit diesem Schritt ist auch das SVN nun unter den Schirm von fhem.de gewandert.

Um auch auf der neuen Plattform Änderungen an den eigenen Modulen durchführen zu können, bitten wir daher alle aktiven Developer uns einen SSH Public-Key per Mail an svn@fhem.de zu schicken. Wir werden dann den Zugang entsprechend auf der neuen Plattform einrichten. Um die Differenzen zwischen SourceForge Username und Forum-Username zu beseitigen wird ausschließlich der Forum-Username (einsehbar im Forum unter Menü Profil->Benutzerkonto) für die neue SVN-Plattform verwendet.

Detaillierte Informationen wie man auf das neue Repository zugreifen kann, gibt es unter https://svn.fhem.de/.

Für evtl. Fragen stehe ich hier gerne zur Verfügung.

Viele Grüße

Markus

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Loredo

Hallo Markus,


wurde eine Umstellung auf Git damit vollkommen verworfen?
Bitte etwas mehr Infos über den Fahrplan.






Danke & Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Volker Kettenbach

Ja, sehr schade, dass es nicht git ist.
So etwas wie github.com ist was wirklich feines.

Markus Bloch

Hallo zusammen,

es gab in der Vergangenheit entsprechende Überlegungen generell auf git umzusteigen. Dabei standen die Vorteile von git (Pull Request, Branch/Merge) den Aufwänden für fhemupdate sowie das Anleiten aller Developer gegenüber. Da es Unentschieden ausging, bleiben wir weiterhin auf SVN.

Betateilchen hatte damals ein GIT-Repository aufgebaut. Die Resonanz war jedoch nicht sehr hoch.

Daher haben wir uns entschieden die neue Platform ebenfalls auf SVN zu belassen.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Loredo

Wirklich schade.


Trotz alledem: Der neue Server hat natürlich Dampf, also vielen Dank für die Mühe beim Umzug generell :-)




PS - wenn Zeit ist:
https://securityheaders.io/?q=wiki.fhem.de&followRedirects=on
https://www.ssllabs.com/ssltest/analyze.html?d=wiki.fhem.de&s=88.99.31.202&latest (OCSP Stapling)


Sofern gewünscht gebe ich gerne Hilfestellung.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig


rudolfkoenig

Ich habe jetzt etliche Hinweise von securityheaders.io befolgt, nur HPKP mit Letsenrypt ist mir suspekt, und deswegen noch nicht implementiert. Den Rueckgabewert von ssllabs wg. OCSP Stabling habe ich nicht verstanden: Dauert ewig, liefert aber A+. OCSP stapling sollte doch zu verringerte Kommunikation fuehren, und damit eher schneller sein.

Die Absicherung von fhem.de ist wg. dem FHEM update (vertraegt sich nicht mit redirect auf HTTPS, obwohl mit HTTPS selbst keine Probleme hat) und die statistics Seite (ich kriege keine funktionierende Content-Security-Policy Header-Zeile hin) nicht vollstaendig.

Loredo

Zitat von: rudolfkoenig am 13 Dezember 2016, 11:17:35
nur HPKP mit Letsenrypt ist mir suspekt, und deswegen noch nicht implementiert.


Ja kann ich verstehen, muss man erstmal verstehen (und sollte man auch). Man kann sich da schon ins Knie schießen :-)
Mit Letsencrypt macht es deshalb nur Sinn die CA zu pinnen und nicht das eigene Zertifikat. Zusammen mit zwei Backup-Zertifikaten (letztendlich nichts weiter als zwei auf Halde generierte Private Keys, um sich den dazugehörigen Public-Key im Ernstfall schnell noch signieren zu lassen) ist man da auf einer recht sicheren Seite was den Betrieb angeht. Auch wenn man so "nur" das CA Zertifikat pinnt so ist es doch trotzdem besser als gar nichts zu pinnen.
Außerdem kann man natürlich erstmal nur den Testmodus setzen und erhält zusammen mit dem report-uri-Flag (siehe auch https://www.report-uri.io fürs Sammeln der Reports) auch ein hübsches Reporting für "was wäre wenn", bevor man das ganze produktiv/restriktiv setzt.


Zitat von: rudolfkoenig am 13 Dezember 2016, 11:17:35
Die Absicherung von fhem.de ist wg. dem FHEM update (vertraegt sich nicht mit redirect auf HTTPS, obwohl mit HTTPS selbst keine Probleme hat) und die statistics Seite (ich kriege keine funktionierende Content-Security-Policy Header-Zeile hin) nicht vollstaendig.


Das gleiche Reporting Verfahren kann man übrigens auch für CSP machen. Wie das funktioniert erklärt die Seite report-uri.io prima und stellt auch entsprechende Header-Generatoren bereit. Damit solltest du auch eine funktionierende CSP zusammenklicken und für den Testbetrieb aktivieren können.


Zitat von: rudolfkoenig am 13 Dezember 2016, 11:17:35
Den Rueckgabewert von ssllabs wg. OCSP Stabling habe ich nicht verstanden: Dauert ewig, liefert aber A+. OCSP stapling sollte doch zu verringerte Kommunikation fuehren, und damit eher schneller sein.


Aktuell ist OCSP nicht aktiviert, für ein einfaches Handling würde ich empfehlen über SSL-Offloading nachzudenken statt es den Apachen machen zu lassen. HAproxy macht OCSP Stapling eigentlich sehr einfach aktivierbar und kümmert sich dann selbstständig darum regelmäßig eine signierte Antwort vom OCSP Server von Letsencrypt einzuholen.


Die Aktivierung von OCSP führt auch nicht dazu, dass der SSLlabs Test schneller geht. Der baut ja nicht nur eine SSL Session auf, sondern prüft auch noch jede Menge an Angriffsvektoren aktiv aus. OCSP bringt dem Browser des Besuchers etwas, da er keine eigene Verbindung zum OCSP Server von Letsencrypt aufbauen muss (hier liegt der Zeitgewinn, den du vermutlich ansprichst). Gleichzeitig wird der OCSP Dienst bei Letsencrypt natürlich weniger belastet und der Besucher behält seine Privacy, da man sein Surfverhalten nicht zentral anhand der OCSP Abfragen nachverfolgen kann.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

Hier mal die .htaccess Konfiguration, wie ich sie bei mir verwende:




# STS
Header always set Strict-Transport-Security "max-age=15552000; preload"


# CSP: Production phase
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.googleapis.com https://*.gstatic.com https://*.wp.com; style-src 'self' 'unsafe-inline' https://*.googleapis.com https://*.gstatic.com; img-src *; media-src *; font-src 'self' data: https://*.googleapis.com https://*.gstatic.com; connect-src 'self' data:; report-uri https://XXXYYYZZZ.report-uri.io/r/default/csp/enforce"
Header always set X-Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.googleapis.com https://*.gstatic.com https://*.wp.com; style-src 'self' 'unsafe-inline' https://*.googleapis.com https://*.gstatic.com; img-src *; media-src *; font-src 'self' data: https://*.googleapis.com https://*.gstatic.com; connect-src 'self' data:; report-uri https://XXXYYYZZZ.report-uri.io/r/default/csp/enforce"
Header always set X-WebKit-CSP "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.googleapis.com https://*.gstatic.com https://*.wp.com; style-src 'self' 'unsafe-inline' https://*.googleapis.com https://*.gstatic.com; img-src *; media-src *; font-src 'self' data: https://*.googleapis.com https://*.gstatic.com; connect-src 'self' data:; report-uri https://XXXYYYZZZ.report-uri.io/r/default/csp/enforce"


# HPKP: Evaluation phase for LetsEncrypt CA pinning (1xLE-CA + 2xBackup-Key)
#Header always set Public-Key-Pins-Report-Only 'pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="; pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="; pin-sha256="Ggrghh/nWGX5PHVSRU4FeplPG5infxvSO6MdsFfwSvE="; pin-sha256="l1vvZm6RNJ9lqI9PKtQGTw+cXNeB6PN8osfE2GA18XQ="; max-age=2592000; report-uri="https://XXXYYYZZZ.report-uri.io/r/default/hpkp/reportOnly"'


# HPKP: Production phase for LetsEncrypt CA pinning (1xLE-CA + 2xBackup-Key)
Header always set Public-Key-Pins 'pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="; pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="; pin-sha256="Ggrghh/nWGX5PHVSRU4FeplPG5infxvSO6MdsFfwSvE="; pin-sha256="l1vvZm6RNJ9lqI9PKtQGTw+cXNeB6PN8osfE2GA18XQ="; max-age=2592000; report-uri="https://XXXYYYZZZ.report-uri.io/r/default/hpkp/enforce"'


# CORS
Header always set Access-Control-Allow-Origin "https://www.XXXYYYZZZ.com"


# Apache Webserver
ServerSignature Off



Wie man sieht habe ich zunächst HPKP evaluiert (Public-Key-Pins-Report-Only) und nachdem über einen Zeitraum keine Meldungen im Reporting über Inkompatibilitäten aufgetaucht sind schließlich live geschaltet.




Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

Zitat von: rudolfkoenig am 13 Dezember 2016, 11:17:35
Die Absicherung von fhem.de ist wg. dem FHEM update (vertraegt sich nicht mit redirect auf HTTPS, obwohl mit HTTPS selbst keine Probleme hat)


Da die HTTP-Header alle rein clientseitig interpretiert werden, bleibt für das fhem-Update (so man es nicht daraufhin erweitern wollen würde) nur den HTTP-Redirect im Webserver auf HTTPS so umzubauen, dass er für die Update-URI nicht angewendet wird. Da fhem-Update den Strict-Transport-Security Header bisher nicht interpretiert, wird dort auch keine HTTPS Verbindung forciert. Wenngleich es wünschenswert wäre diesen Header zukünftig zu beachten, aber für das Update könnte man auch erstmal eine Ausnahme machen, wenn HTTPS da noch Probleme macht.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig


Loredo

Auf www.report-uri.io, alternativ auch auf deinem eigenen Server, wenn du das vom Browser gesendete JSON selbst verarbeiten möchtest (das Header Attribut "report-uri:" kann man ja beliebig setzen). Da das aber recht viel Aufwand ist das richtig zu tun und ein Browser eine solche Information auch nur im Fehlerfall sendet, sehe ich das nicht kritisch an es an einen externen Dienst wie diesen zu senden. Die übertragenen Informationen beinhalten auch nichts schützenswertes, sondern eh nur das, was der Browser als Fehlermeldung wirft.


Gruß

Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

An die KOPP_FC und PRESENCE Maintainer: bitte die Links zu http://svn.code.sf.net im Modul anpassen.

betateilchen

Wer auf macOS Sierra trotz korrektem ~/.ssh/config Eintrag Probleme hat, per svn+ssh:// das Repository zu erreichen, sollte kontrollieren, dass die Rechte auf das keyfile korrekt auf 400 stehen. Bei der Generierung des keyfiles mit ssh-keygen werden die Rechte auf 600 gesetzt, was macOS in aktuellen Versionen wohl nicht mehr zulässt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Loredo

Ich habe hier diese Probleme zwar nicht feststellen können, mag aber auch daran liegen, dass ich das Keyfile mit Passwort geschützt habe und ssh-agent für die Bereitstellung des Keys verwende. Vielleicht also noch eine Alternative dazu.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

betateilchen

#15
@Rudi:

  • im aktuellen Makefile wird folgende Datei kopiert http://fhem.de/fhemupdate/controls_fhem.txt
  • seit ein paar Tagen wird die Anforderung dieser Datei per wget mit einem HTTP Error 403 beantwortet, weshalb die nightly builds nicht mehr funktionieren.
  • das "forbidden" deutet darauf hin, dass eine ACL aktiv ist, die einen direkten Abruf der Datei nicht zulässt? In 98_update.pm wird die gleiche URL verwendet.

wget -qO .f/$(MODDIR)/FHEM/controls_fhem.txt http://fhem.de/fhemupdate/controls_fhem.txt

Danke für eine Lösung!
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Markus Bloch

Mit curl funktioniert es bei mir:

root@NAS:~# curl -v  http://fhem.de/fhemupdate/controls_fhem.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0> GET /fhemupdate/controls_fhem.txt HTTP/1.1
> Host: fhem.de
> User-Agent: curl/7.50.3
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 16 Dec 2016 15:57:11 GMT
< Server: Apache/2.4.18 (Ubuntu)
< X-Xss-Protection: 1; mode=block
< Last-Modified: Fri, 16 Dec 2016 07:16:04 GMT
< Accept-Ranges: bytes
< Content-Length: 119802
< Vary: Accept-Encoding
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Pragma: no-cache
< Content-Type: text/plain
<
{ [989 bytes data]
REV 12787
DIR unused
MOV www/pgm2/fhemweb_multiple.js unused
MOV www/pgm2/fhemweb_noArg.js unused
MOV www/pgm2/fhemweb_slider.js unused
MOV www/pgm2/fhemweb_svg.js unused
MOV www/pgm2/fhemweb_textField.js unused
MOV www/pgm2/fhemweb_time.js unused
MOV www/pgm2/darktouchpadsvg_defs.svg unused
MOV www/pgm2/darktouchpadsvg_style.css unused


Mit wget klappt es ebenfalls nicht. Ich schau mir das mal an.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

wget ist explizit via user-agent geblockt:

root@NAS:~# wget -d --user-agent="curl/7.50.3" http://fhem.de/fhemupdate/controls_fhem.txt
Setting --user-agent (useragent) to curl/7.50.3
DEBUG output created by Wget 1.12 on linux-gnueabi.

--2016-12-16 17:17:36--  http://fhem.de/fhemupdate/controls_fhem.txt
Resolving fhem.de... 88.99.31.202, 2a01:4f8:10a:806::2
Caching fhem.de => 88.99.31.202 2a01:4f8:10a:806::2
Connecting to fhem.de|88.99.31.202|:80... connected.
Created socket 3.
Releasing 0x00065818 (new refcount 1).

---request begin---
GET /fhemupdate/controls_fhem.txt HTTP/1.0
User-Agent: curl/7.50.3
Accept: */*
Host: fhem.de
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Fri, 16 Dec 2016 16:17:36 GMT
Server: Apache/2.4.18 (Ubuntu)
X-Xss-Protection: 1; mode=block
Last-Modified: Fri, 16 Dec 2016 07:16:04 GMT
Accept-Ranges: bytes
Content-Length: 119802
Vary: Accept-Encoding
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: text/plain
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

---response end---
200 OK
Registered socket 3 for persistent reuse.
Length: 119802 (117K) [text/plain]
Saving to: `controls_fhem.txt'

100%[===================================================================================================================================================================================================>] 119,802     --.-K/s   in 0.1s

2016-12-16 17:17:36 (879 KB/s) - `controls_fhem.txt' saved [119802/119802]

root@NAS:~#


Warum dies so konfiguriert ist, muss Rudi beantworten. :)
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

justme1968

rudi hat es blockiert weil es sekündlich abgerufen wurde und er nicht wusste von wem oder warum.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

betateilchen

Dann sollte Markus besser die oben gepostete Lösung wieder entfernen :D
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

betateilchen, ich bin bereit fuer Ausnahmen, ich habe nur keine Lust auf 300G/Monat sinnlosen Traffic.

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Als Alternative: Lege die controls-Datei irgendwo im SVN Zweig ab, denn im Rahmen der Paketerzeugung erfolgt ohnehin als erster Schritt ein "svn update". Dann braucht man das wget überhaupt nicht mehr, sondern muss die Datei einfach nur an die richtige Stelle kopieren/verschieben.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Markus Bloch

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Hallo zusammen,

die Migration ist abgeschlossen. Das neue Repository ist nun schreibbar und jeder, der bereits einen Account hat, kann nun Änderungen einchecken.

Sollte es Probleme beim Check-In geben, bitte hier melden.

Viel Spaß.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

rudolfkoenig

 
ZitatLege die controls-Datei irgendwo im SVN Zweig ab

An sich eine gute Idee, leider war es aufwendiger zu implementieren:
- ich musste das ReadOnly svn checkout fuer fhemupdate.pl auf ReadWrite stellen, und habe dafuer einen Benutzer fhemupdate auf dem svn Server anlegen muessen.
- im controls_fhem.txt steht in der ersten Zeile die aktuelle Revision (weiss jemand, wozu?). Nach Einchecken dieser Datei erhoeht sich diese Zahl, was zu eine Endlosschleife fuehrt. Ich habe das hoffentlch unterbunden, bin aber nicht sicher, ob ohne Nebeneffekte.


Markus Bloch

Zitat von: rudolfkoenig am 17 Dezember 2016, 19:45:04
- im controls_fhem.txt steht in der ersten Zeile die aktuelle Revision (weiss jemand, wozu?). Nach Einchecken dieser Datei erhoeht sich diese Zahl, was zu eine Endlosschleife fuehrt. Ich habe das hoffentlch unterbunden, bin aber nicht sicher, ob ohne Nebeneffekte.

Für 98_version.pm. Siehe dazu https://forum.fhem.de/index.php/topic,49215.msg409056.html#msg409056

Könnte man ja nun alternativ auch mit $Id$ bestücken als Kommentar.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

betateilchen

Zitat von: rudolfkoenig am 17 Dezember 2016, 19:45:04
An sich eine gute Idee, leider war es aufwendiger zu implementieren:

Danke für Deine Unterstützung.

Eben habe ich ein entsprechend angepasstes Makefile eingecheckt, das mit cp anstatt wget arbeitet.
Die Paketgenerierung für das target deb funktioniert damit (getestet) problemlos und ohne wget.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Btw. der "Poller" hat von wget auf curl umgestellt, und pollt alle 5 Sekunden.
Es gibt zwei Andere, die es alle 120 Sekunden machen.

Hat jemand eine Ahnung, wozu ein regelmaessiges update gut sein soll? Die Datei aendert sich doch nur einmal am Tag, um 7:45. Versprochen!

Habt ihr Ideen, wie man sowas sinnvoll unterbinden kann?

justme1968

es gibt irgendwo im forum threads in denen ein update status für tabletui und fhemweb implementiert wird. eventuell verwendet jemand so etwas mit einem viel zu kleinen intervall.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Markus Bloch

mit curl/wget? ich glaube nicht. Das müsste dann ja mit einem fhem-Useragent kommen.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

betateilchen

Zitat von: rudolfkoenig am 17 Dezember 2016, 20:15:59
Habt ihr Ideen, wie man sowas sinnvoll unterbinden kann?

fail2ban auf den Request der controls Datei triggern.
Dann wird der "Angreifer" bei zu kurzen Intervallen automatisch gesperrt.

Oder einfach mal eine Ankündigung hier im Forum machen, dass ein Abruf dieser Datei in solch kurzen Intervallen überhaupt keinen Sinn macht, weil sich die Datei nur einmal pro Tag ändert.

Wir als Entwickler wissen das ja (vermutlich) aber 99% aller User wissen das nicht und haben vermutlich einfach irgendwo per copy&paste etwas kopiert, ohne wirklich zu wissen, was dahintersteckt und was sie damit auslösen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

Moin!

Ich bekomme bei Checkin-Versuch : POST of '/fhem/!svn/me': 403 Forbidden (https://svn.fhem.de)
Putty-Session offen, Server antwortet mit
Using username "hexenmeister".
Authenticating with public key "imported-openssh-key"
Server refused to allocate pty
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops atomic-revprops partial-replay inherited-props ephemeral-txnprops file-revs-reverse ) ) )


Was mache ich falsch?

LG
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Markus Bloch

Hallo Alexander,

weil du den Check-Out über HTTPS und nicht SSH gemacht hast.

Du musst den Session-Namen, welchen du im PuTTY hinterlegt hast in Tortoise benutzen:

svn+ssh://SESSIONNAME/

Bsp: svn+ssh://svn.fhem.de/trunk/fhem/


Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Tobias

#34
Hi,
beim ersten Anlegen des Repos via Doku bekomme ich einen Fehler... Das ReadOnly auschecken funktioniert aber
Ich denke es ist "/root/.subversion/config" gemeint. Ich habe mich strikt nach Anleitung https://svn.fhem.de/ gehalten. Da steht nix von einer Anpassung  dort...

Achso, ich checke via Linu Shelle aus
root@www:/usr/local/svn# svn co svn+ssh://svn.fhem.de/fhem/
svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: Netzwerkverbindung wurde unerwartet geschlossen
root@www:/usr/local/svn#
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

rudolfkoenig


Markus Bloch

Hallo Tobias,

nein, es ist ~/.ssh/config (in deinem Fall /root/.ssh/config) gemeint. Sollte die Datei/Ordner nicht existieren, bitte anlegen. Sonst klappt es nicht. In der Subversion Client-Konfiguration sind keine Anpassungen notwendig.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

@Tobias: Deine Check-Out-URL wird so nicht funktionieren. Entweder svn co svn+ssh://svn.fhem.de/ für alles, oder svn co svn+ssh://svn.fhem.de/trunk/fhem wenn Du nur den Trunk haben möchtest.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Tobias

Danke für die Hinweise. Hier mal die Ausgaben:root@www:/usr/local/svn# ssh -v svn.fhem.de
OpenSSH_6.0p1 Debian-4+deb7u4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 1: Applying options for svn.fhem.de
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to svn.fhem.de [2a01:4f8:10a:806::2] port 55522.
debug1: connect to address 2a01:4f8:10a:806::2 port 55522: Connection refused
debug1: Connecting to svn.fhem.de [88.99.31.202] port 55522.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file id_rsa type -1
debug1: identity file id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 66:41:62:f3:45:ed:a3:59:93:28:c6:84:2d:36:b0:00
debug1: Host '[svn.fhem.de]:55522' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: id_rsa
debug1: No more authentication methods to try.
Permission denied (publickey).
root@www:/usr/local/svn# svn co svn+ssh://svn.fhem.de/
svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: Netzwerkverbindung wurde unerwartet geschlossen
root@www:/usr/local/svn# ls -ail /root/.ssh/
insgesamt 24
2621494 drwx------  2 root root 4096 Dez 19 09:18 .
2621441 drwx------ 10 root root 4096 Sep  2 09:14 ..
2621646 -rw-r--r--  1 root root   73 Dez 19 09:26 config
2621566 -rw-------  1 root root 3243 Dez 12 12:20 id_rsa
2621593 -rw-r--r--  1 root root  744 Dez 12 12:20 id_rsa.pub
2621506 -rw-r--r--  1 root root 1330 Dez 19 09:22 known_hosts
root@www:/usr/local/svn#
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Markus Bloch

Dein Private-Key id_rsa passt nicht zu dem bereitgestellten Public-Key.

Entweder den richtigen Private-Key verwenden, oder stell uns bitte den korrekten Public-Key zur Verfügung. Es ist natürlich nicht ausgeschlossen, dass wir beim Anlegen deines Users einen Tippfehler gemacht haben. Kann ich leider gerade nicht checken, da ich auf Arbeit bin :)

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Wuppi68

Hallo Tobias,

das "Problem" hatte ich auch ...

bei mir Lokal wuppi68 klein geschrieben ... vom Markus Wuppi68 geschrieben

nach der entsprechenden Korrektur in den Config Dateien war alles gut :-)

Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Tobias

So sieht bei mir die config aus, der Username ist direkt aus der id_rsa.pub kopiert. Ist der Bei Euch auch so angelegt?
root@www:/usr/local/svn# cat /root/.ssh/config
Host svn.fhem.de
IdentityFile id_rsa
Port 55522
User Tobias@svn.fhem.de
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

krikan

#42
Lass bitte bei user "@svn.fhem.de" weg:

User Tobias

edit: Und kontrolliere bitte den Pfad bei IdentityFile; Tippfehler user statt User korrigiert

Markus Bloch

Die Bezeichnung, welche im Public-Key hinten drann steht ist nur ein Kommentar, der von ssh-keygen vorbelegt ist. Er hat an sich keine Bedeutung für die Nutzung von SSH sondern dient nur als Kommentarfeld, wenn man mit multiplen Keys arbeitet.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Tobias

Auch mit "user Tobias" ändert sich an der Fehlermeldung nix. Genau diesen Usernamen hatt ich auch Rudi zusammen mit dem Public Key mitgegeben
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Markus Bloch

Ich kann mir das heute Nachmittag gerne anschauen, sobald ich Feierabend habe.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

"User Tobias" bitte dennoch mit großem U schreiben, sonst wird die Zeile nicht erkannt.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

justme1968

das neue repository ist traumhaft schnell im vergleich zu sourceforge :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

hexenmeister

Moin!
Habe wohl gleiches Problem wie Tobias. :(
OpenSSH_6.0p1 Debian-4+deb7u4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/alex/.ssh/config
debug1: /home/alex/.ssh/config line 1: Applying options for svn.fhem.de
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to svn.fhem.de [88.99.31.202] port 55522.
debug1: Connection established.
debug1: identity file id_rsa.ppk type -1
debug1: identity file id_rsa.ppk-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 66:41:62:f3:45:ed:a3:59:93:28:c6:84:2d:36:b0:00
debug1: Host '[svn.fhem.de]:55522' is known and matches the ECDSA host key.
debug1: Found key in /home/alex/.ssh/known_hosts:8
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: id_rsa.ppk
debug1: No more authentication methods to try.
Permission denied (publickey).


Weder meine Keys will der Server nicht (id_rsa, id_rsa.pub, id_rsa.ppk... habe schon alle durchprobiert...)

Was könnte ich dagegen tun?

Grüße
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Markus Bloch

Hallo Alexander,

bitte nicht PuTTY-Private-Keys mit OpenSSH mischen. Das funktioniert nicht. Wenn du auf der Linux-Shell eine SSH-Verbindung machst, benötigst du id_rsa als Private-Key. Wenn du in Windows PuTTY benutzt, benötigst du id_rsa.ppk (PuTTY Private Keyfile)

Du hattest heute um 17:03 Uhr und um 16:56 eine erfolgreiche Verbindung. Du hast also schonmal deinen korrekten Private-Key verwendet.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Zitat von: Tobias am 19 Dezember 2016, 12:56:27
Auch mit "user Tobias" ändert sich an der Fehlermeldung nix. Genau diesen Usernamen hatt ich auch Rudi zusammen mit dem Public Key mitgegeben

Ich sehe keinen Verbindungsversuch mit Username Tobias bei mir im Log. Bitte das "U" am Anfang groß schreiben und nochmal probieren. Wenn du mit einem ssh svn.fhem.de die folgende Ausgabe erhälst, funktioniert die Verbindung:

( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops atomic-revprops partial-replay inherited-props ephemeral-txnprops file-revs-reverse ) ) )


Dann kannst du via svn co .... auschecken.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

hexenmeister

#51
Zitat von: Markus Bloch am 19 Dezember 2016, 17:33:07
Du hattest heute um 17:03 Uhr und um 16:56 eine erfolgreiche Verbindung. Du hast also schonmal deinen korrekten Private-Key verwendet.

Hm, ja,.. mit PuTTY bekomme ich die Verbindung, aber checkout funktioniert nicht (weder mit Tortoise, noch per Commandline).
D:\temp\FHEM_Test2>svn co svn+ssh://svn.fhem.de/fhem/trunk/fhem
svn: E170012: Unable to connect to a repository at URL 'svn+ssh://svn.fhem.de/fhem/trunk/fhem'
svn: E170012: Can't create tunnel
svn: E720087: Can't create tunnel: Falscher Parameter.

Von meinem Linux-System bekomme ich schon gar keine SSH-Verbindung. Auch mit der id_rsa-Datei nicht.

Grüße
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Markus Bloch

Wenn die Verbindung in Putty klappt, kannst du mit dem entsprechenden Session-Namen in Putty, unter der die Verbindung funktioniert, in Tortoise auschecken. Dazu musst du den Putty-Sessionnamen als Hostnamen in der URL verwenden:

svn+ssh://sessionname/

Wenn deine PuTTY-Session also "svn.fhem.de" heist, kannst du mit svn+ssh://svn.fhem.de/ auch auschecken.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Um unter Windows mit Tortoise auszuchecken musst du im Windows Explorer einen Ordner erstellen, dort hineingehen und dann Rechtsklick => "SVN Checkout" machen. Es öffnet sich ein Fenster und dort gibst du die Checkout-URL an.

Ich muss leider wieder ins Auto steigen. Evtl. können auch andere User, bei denen es bereits funktioniert dir weiterhelfen.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

hexenmeister

#54
Danke für die schnelle Antwort.
Leider komme ich nicht weiter. Ich mache eigentlich alles genauso.
s. Anhang


EDIT: Verdammt, ich glaube, ich sehe den Fehler (Tippfehler beim Session-Namen)!

EDIT2: Auschecken geht! Danke für die Hilfe! Allerdings verstehe ich immer noch nicht, warum unter Linux nicht klappt...
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

betateilchen

Zitat von: hexenmeister am 19 Dezember 2016, 17:58:20
Allerdings verstehe ich immer noch nicht, warum unter Linux nicht klappt...

Welche Fehlermeldung bekommst Du denn, wenn Du versuchst, von der Kommandozeile eine ssh Verbindung aufzubauen?


ssh -l <userName> -p 55522 -i ~/.ssh/id_rsa svn.fhem.de

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

chris1284

ich hätte da mal eine frage. das key-pärchen habe ich unter debian erstellt (openssh) in putty zu einen ppk konvertiert. die verbindung funktioniert auch, kann auch änderungen einchecken. nur bekomme  im svn gefühlt 1000 mal die abfrage des passwortes des provate keys. kann man dies unterbinden?

Markus Bloch

Unter Windows durch laden des Private-Keys in Pageant (Putty Agent). Dann musst du nur einmalig die Passphrase eingeben und der Agent authentifiziert alle Anfragen im Hintergrund. Unter Linux nennt sich dass ssh-agent.

Gruß
Markus

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

hexenmeister

Zitat von: betateilchen am 19 Dezember 2016, 19:21:59
Welche Fehlermeldung bekommst Du denn, wenn Du versuchst, von der Kommandozeile eine ssh Verbindung aufzubauen?


ssh -l <userName> -p 55522 -i ~/.ssh/id_rsa svn.fhem.de


Damit komme ich weiter:
ssh -l hexenmeister -p 55522 -i ~/.ssh/id_rsa svn.fhem.de
PTY allocation request failed on channel 0
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops atomic-revprops partial-replay inherited-props ephemeral-txnprops file-revs-reverse ) ) )

Die Verbindung steht also grundsätzlich. Über die konfigurierte Verbindung klappte es erstmal weiterhin  nicht:
ssh -v svn.fhem.de
OpenSSH_6.0p1 Debian-4+deb7u4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/alex/.ssh/config
debug1: /home/alex/.ssh/config line 1: Applying options for svn.fhem.de
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to svn.fhem.de [88.99.31.202] port 55522.
debug1: Connection established.
debug1: identity file id_rsa type -1
debug1: identity file id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 66:41:62:f3:45:ed:a3:59:93:28:c6:84:2d:36:b0:00
debug1: Host '[svn.fhem.de]:55522' is known and matches the ECDSA host key.
debug1: Found key in /home/alex/.ssh/known_hosts:8
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: id_rsa
debug1: No more authentication methods to try.
Permission denied (publickey).


Erst als ich im  ~/.ssh/config 'IdentityFile id_rsa' durch 'IdentityFile ~/.ssh/id_rsa' ersetzt habe, klappte es endlich. Vlt. nutzt das jemanden noch :)

Vielen Dank!

Grüße
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Markus Bloch

Zitat von: hexenmeister am 19 Dezember 2016, 22:44:35
Erst als ich im  ~/.ssh/config 'IdentityFile id_rsa' durch 'IdentityFile ~/.ssh/id_rsa' ersetzt habe, klappte es endlich. Vlt. nutzt das jemanden noch :)

Das (und der Username) wird auch das Problem bei Tobias sein.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

betateilchen

Zitat von: hexenmeister am 19 Dezember 2016, 22:44:35
Erst als ich im  ~/.ssh/config 'IdentityFile id_rsa' durch 'IdentityFile ~/.ssh/id_rsa' ersetzt habe, klappte es endlich. Vlt. nutzt das jemanden noch :)

Naja, das mit der fehlenden Pfadangabe ist aber doch eher ein typischer Linux-Anfängerfehler  8)

Prima dass es nun funktioniert.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: chris1284 am 19 Dezember 2016, 21:59:22
nur bekomme  im svn gefühlt 1000 mal die abfrage des passwortes des provate keys. kann man dies unterbinden?

Man kann auch Schlüsselpaare ohne Passwort generieren...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

Zitat von: betateilchen am 20 Dezember 2016, 07:02:39
Naja, das mit der fehlenden Pfadangabe ist aber doch eher ein typischer Linux-Anfängerfehler  8)
Hm, ja, mit Linux beschäftige ich mich zwar schon länger, jedoch zu wenig und nur, wenns wirklich sein muss ;D
Habe beim Befolgen der Anleitung nicht mitgedacht. Man sollte diese um einen entsprechenden Hinweis ergänzen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Tobias

#63
Hi Markus,
Username war korrekt, auch die Groß/Kleinschreibung. Es lag ab Pfad des Identityfiles. Jetzt funktioniert es :)
Danke für die Unterstützung. Ev. sollte der Hinweis auch in die https://svn.fhem.de Webseite?

Bekomme aber warnings angezeigt:
root@www:/usr/local/svn/fhem# svn up
svnserve: warning: cannot set LC_CTYPE locale
svnserve: warning: environment variable LC_ALL is de_DE.UTF-8
svnserve: warning: please check that your locale name is correct
Revision 12839.
root@www:/usr/local/svn/fhem#


So sieht meine locale aus:
root@www:/usr/local/svn/fhem# locale
LANG=de_DE.UTF-8
LANGUAGE=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=de_DE.UTF-8
root@www:/usr/local/svn/fhem#


Ideen? Oder einfach ignorieren?
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Markus Bloch

Hallo Tobias,

dein lokales Linux scheint nur die Sprache (Locale) deutsch (de_DE.UTF-8) zu verstehen. Bei der Verbindung zu unserem SVN versucht SSH ebenfalls eine Session mit der Sprache Deutsch aufzubauen, welches der Server aber nicht kennt.

Du müsstest daher englisch (en_US.UTF-8) nachinstallieren. Beispielhaft ist das hier beschrieben: http://stackoverflow.com/questions/11300633/svn-cannot-set-lc-ctype-locale

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Zitat von: Tobias am 20 Dezember 2016, 07:25:23
Username war korrekt, auch die Groß/Kleinschreibung. Es lag ab Pfad des Identityfiles. Jetzt funktioniert es :)
Danke für die Unterstützung. Ev. sollte der Hinweis auch in die https://svn.fhem.de Webseite?

Ich habe es nochmal präzisiert:

add the following lines to your SSH config file ~/.ssh/config:

    Host svn.fhem.de
    IdentityFile <full path to your private key file>
    Port 55522
    User <your username>


Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

betateilchen

Zitat von: Markus Bloch am 20 Dezember 2016, 07:37:11
Du müsstest daher englisch (en_US.UTF-8) nachinstallieren. Beispielhaft ist das hier beschrieben:

Auf Debian-basierten Distributionen reicht normalerweise ein


dpkg-reconfigure locales


auf der Konsole, dabei wird man als Benutzer komplett durch die Auswahl und Aktivierung geführt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Benni

Hallo,

ich kann plötzlich nicht mehr auf das svn-Repository zugreifen.
Am 15.01. habe ich das letzte mal Änderungen eingecheckt, da haben update und commit noch problemlos funktioniert.

Heute erhalte ich bei einem update plötzlich folgende Fehlermeldung:


Updating '.':
svn: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.fhem.de'
svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: E210002: Network connection closed unexpectedly


ein ssh -v svn.fhem.de liefert folgende Ausgabe:


OpenSSH_7.2p2, LibreSSL 2.4.1
debug1: Reading configuration data /Users/benni/.ssh/config
debug1: /Users/benni/.ssh/config line 1: Applying options for svn.fhem.de
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to svn.fhem.de [88.99.31.202] port 55522.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file fhemsvn type -1
debug1: key_load_public: No such file or directory
debug1: identity file fhemsvn-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to svn.fhem.de:55522 as 'Benni'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:aekRckgeP3UWEwumpa1KbpiNVeFNlIlsXU8DC6fhH9k
debug1: Host '[svn.fhem.de]:55522' is known and matches the ECDSA host key.
debug1: Found key in /Users/benni/.ssh/known_hosts:25
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: fhemsvn
no such identity: fhemsvn: No such file or directory
debug1: No more authentication methods to try.
Permission denied (publickey).


Ich wüsste nicht, dass ich bei mir irgendetwas an den ssh oder svn Einstellungen geändert hätte  :-\


betateilchen

Zitat von: Benni am 23 Januar 2017, 10:33:04

debug1: Trying private key: fhemsvn
no such identity: fhemsvn: No such file or directory
debug1: No more authentication methods to try.
Permission denied (publickey).


Ich wüsste nicht, dass ich bei mir irgendetwas an den ssh oder svn Einstellungen geändert hätte  :-\

der nicht gefundene private key muss bei Dir lokal liegen - prüfe trotzdem mal Deine ssh Konfiguration
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

@Benni: dein Eintrag auf svn.fhem.de ist seit 19.12 unveraendert.
Der eingetragene public-key endet auf "volOMGmebw== Benni@svn.fhem.de"

Benni

Also manchmal versteh' ich's einfach nicht  ::)

In meiner ssh-config war bisher nur der Dateiname der zu verwendenden Schlüsseldatei eingetragen. Ich habe jetzt den vollen Pfad zur Datei eingetragen und jetzt läuft's.

Keine Ahnung, warum das aber bisher funktioniert hat.  :-\

Vielen Dank für eure schnelle Unterstützung!

Gruß Benni.


hexenmeister

Moin!

Gerade habe ich versucht, mein Modul upzudaten.

SSH-Session wollte nicht (dabei ging es schon mal):
ZitatUsing username "hexenmeister".
Authenticating with public key "imported-openssh-key"
Server refused to allocate pty
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops atomic-revprops partial-replay inherited-props ephemeral-txnprops file-revs-reverse ) ) )

Commit hat natürlich auch nicht funktioniert:
ZitatCommit
D:\Develop\fhem\fhem\FHEM\42_SYSMON.pm
D:\Develop\fhem\fhem\FHEM\42_SYSMON.pm
Commit failed (details follow):
Commit blocked by pre-commit hook (exit code 1) with output:

THIS REPOSITORY IS WRITE LOCKED

The FHEM SVN repository has moved to https://svn.fhem.de/
If you still want to contribute, see
https://forum.fhem.de/index.php/topic,62348.0.html
This error was generated by a custom hook script on the Subversion server.
Please contact your server administrator for help with resolving this issue.

Eine Idee, was diesmal falsch sein kann?

*frustriert*
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Benni

#72
Klingt so, als würdest du versuchen, auf das alte Repository bei sourceforge zuzugreifen.

Kannst ja mal mit


svn info


prüfen, mit welchem remote-Repository dein lokales verknüpft ist.

hexenmeister

Aaasche auf...!  >:(
Genau so war das, hatte noch die alte Verzeichnisse nicht gelöscht und natürlich in der Eile verwechselt. Danke für der Stoß in die richtige Richtung!
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

betateilchen

Bei Gelegenheit könnte mal jemand das FHEM-Häuschen auf svn.fhem.de gegen die aktuelle Variante (wie auf fhem.de) austauschen. Das Logo befindet sich im SVN.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig


Wuppi68

Zitat von: rudolfkoenig am 05 März 2017, 10:45:17
Erledigt.

Danke - hatte schon überlegt ob ich die hoheitliche Aufgabe wirklich war nehmen sollte ;-)
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

rudolfkoenig

ZitatDanke - hatte schon überlegt ob ich die hoheitliche Aufgabe wirklich war nehmen sollte ;-)
Ich gehe davon aus, dass du nicht genau weisst, worum es geht: auf dem Vereinsrechner, svn-VM, im HTML "Document Directory" eine Datei austauschen. Wenn du das auch kannst, dann ist irgendetwas mit unserer Sicherheit faul, bitte beschreiben.

Wuppi68

habe zu schnell gedacht und bin gedanklich aus der Kurve geflogen :-)

Duckundwech

Ralf
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Hauswart

Hat jemand den TortoiseSVN Projektmonitor im Einsatz? Wie konfiguriere ich diesen?
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Markus Bloch

Du legst ein neues Projekt im Projektmonitor an und verwendest folgende URL:

https://svn.fhem.de/fhem/

Das ist die öffentliche Read-Only HTTP URL für SVN.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

HomeAuto_User

Guten Tag,
ich habe von Hr. König einen SVN Zugang erhalten aber mir gelingt kein Zugang via Putty.
Soabld ich die Verbindung aufbaue, kommt eine Abfrage von einem Passphrase.
Bei der Erstellung hatte ich einen definiert aber dieser wird nicht akzeptiert.

ZitatUsing username ...
Authenticating with public key ...
Passphrase for key "xxxxx":

Da ich die Freischaltung via E-Mail weitergeleitet hatte ich meinen Schluessel nicht in dem "Einzeiler-Format" wie
   ssh-rsa AAAAB3...IvgE= rsa-key-20171216 ... gesendet hatte, so wurder er zusammengeklebt von Rudi.
Kann es sein, das dort etwas schief lief? Leider wusste er auch nicht weiter, weil ich mir den Key via PuttyGen erstellt hatte.

Über eine Hilfestellung wäre ich erfreut um eine Verbindung herstellen zu können.
Mfg Marco
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

betateilchen

Generiere ein neues Schlüsselpaar ohne passphrase, um erstmal sicherzustellen, dass Deine Konfiguration grundsätzlich funktioniert.

Und dass putty & Co nicht gerade die besten Voraussetzungen für FHEM Development sind, ist nur meine ganz persönliche Meinung.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

HomeAuto_User

Hallo,
Zitat von: betateilchen am 17 Dezember 2017, 17:34:42
Generiere ein neues Schlüsselpaar ohne passphrase, um erstmal sicherzustellen, dass Deine Konfiguration grundsätzlich funktioniert.

Und dass putty & Co nicht gerade die besten Voraussetzungen für FHEM Development sind, ist nur meine ganz persönliche Meinung.
ich werde das ganze nochmal angehen und mich ggf. auf Linux dazu durchfuchsen. Es ist natürlich schwierig als "Neueinsteiger" sich an Doku´s zu halten, welche nicht sehr ausgereift scheinen. ???
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

CoolTux

Du hast aber schon Deinen public Keyfile an Markus gesendet, oder?
Zitat
Module developers can get read/write access to the repository via SSH. You need to provide your SSH public key (if you dont have one, generate it on Linux via ssh-keygen -t rsa -b 4096 -C "myusername@svn.fhem.de" or on Windows via PuTTYgen) and your FHEM forum username via mail to svn@fhem.de together with the name of modules you want to contribute.
https://svn.fhem.de/
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.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

HomeAuto_User

Zitat von: CoolTux am 19 Dezember 2017, 15:02:12
Du hast aber schon Deinen public Keyfile an Markus gesendet, oder?https://svn.fhem.de/

Ja diesen hatte ich schon versendet und eine Info bzw. Reaktion von Hr. König erhalten.
Ich hatte den Schlüssel mit PuttyGen erstellt und ihm hingesandt.

ZitatDa ich dein Schluessel in dem "Einzeiler-Format" wie
   ssh-rsa AAAAB3...IvgE= rsa-key-20171216
benoetige, habe ich es zusammengeklebt. Wenn dabei was schiefgegangen ist,
bitte nochmal in diesem Format schicken.

Ich bin auch hinzugefügt als User aber erhalte eben die Passphrase eingabe, welche nicht akzeptiert wird.
Da ich bei der Generierung einen Passphrase vergab, werde ich den neuen Scchlüssel ohne probieren und hinsenden.
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

CoolTux

Zum testen stimme ich Dir zu. Das solltest Du dann aber ganz schnell wieder ändern auf "mit Passphrase"

Am besten unter Linux mit ssh-key-gen generieren. Kenne Putty nur von kurzen Aufgaben die ich mal erledigen musste, das war einfach ein Kraus mit dem Teil.
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.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

HomeAuto_User

Zitat von: CoolTux am 19 Dezember 2017, 15:13:22
Zum testen stimme ich Dir zu. Das solltest Du dann aber ganz schnell wieder ändern auf "mit Passphrase"

Am besten unter Linux mit ssh-key-gen generieren. Kenne Putty nur von kurzen Aufgaben die ich mal erledigen musste, das war einfach ein Kraus mit dem Teil.

Kann man den generierten Schlüssel in Linux auch in Windows nutzen? So kann ich diesen ja generieren und dann ggf. in Putty einfach als AUTH definieren.
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

CoolTux

Klar kannste das. Ist doch ein normales Keyfile. Musst halt nur dein private Keyfile in Putty integrieren.
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.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

Zitat von: CoolTux am 19 Dezember 2017, 15:13:22
Zum testen stimme ich Dir zu. Das solltest Du dann aber ganz schnell wieder ändern auf "mit Passphrase"

paranoia Modus...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

HomeAuto_User

#90
Hallo,
vielen Dank für die Tips und ich habe nun versucht mein Modul bei aktiver Verbindung hochzuladen.
Erst stolperte ich über Keywords aber dazu wurde ich fündig.

Nun habe ich folgendes Problem bzw. Fehler:
ZitatFehler: Übertragen schlug fehl (Details folgen): 
Fehler: Commit blocked by pre-commit hook (exit code 1) with output: 
Fehler: *** trunk/fhem/FHEM/88_xs1Bridge.pm: EN: No summary description found 
Fehler: print() on closed filehandle $dbg at /var/svn/fhem/hooks/pre-commit line 160. 
Fehler: print() on closed filehandle $dbg at /var/svn/fhem/hooks/pre-commit line 152. 

Ich habe nochmal erneut nachgesehen zwecks Doku, da der Punkt EN: darauf hindeutete aber die Doku ist vorhanden.
Erbitte Hilfe.

MfG

EDIT: HIER  ::)
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

rudolfkoenig

ZitatErbitte Hilfe.
Wie ich das in meinem Email beim Freischalten des Accounts geschrieben habe:
ZitatUnd da ich heute deswegen schon gefragt wurde: in
  https://wiki.fhem.de/wiki/Guidelines_zur_Dokumentation
sind noch einige Details zur Doku.