Hallo zusammen,
bitte diesen Thread für Fragen/Diskussion zum SVN Umzug von FHEM am 17.12.2016 nutzen.
Neue Platform: https://svn.fhem.de/
Repository-Browser: https://svn.fhem.de/trac/
Informationen für User: https://forum.fhem.de/index.php/topic,62352.0.html
Informationen für Modulentwickler: https://forum.fhem.de/index.php/topic,62348.html
Vielen Dank
Gruß
Markus
Hallo,
ich hätte da gleich eine Frage, wieso zieht man nicht auf github um? Das macht es in vielen Fällen auch für Modulentwickler einfacher Changes von anderen einzuspielen.
Mir ist schon klar, dass ein selbst eingerichtetes SVN günstiger ist, aber Pull Requests und das doch sehr angenehm nutzbare Browser Interface von github macht vieles einfacher für Entwickler.
Gruß,
Dominik
Es gibt Fans von subversion und es gibt Fans von git, mir ist das eigentlich egal.
Wir hatten schon eine Diskussion diesbezueglich, und es ging unentschieden aus.
Damit uns die Umstellungsarbeit (z.Bsp fuer fhemupdate, svn-hook, etc) erspart belibt, beiben wir bis auf Weiteres bei subversion.
Ist klar, aber finde die Entscheidung dennoch schade, da gerade jetzt bei so einem Umzug der richtige Moment wäre um gleich einen Wechsel durchzuführen. Der Trend geht ja ganz klar zu git und weg von svn bei vielen Projekten. Aber gut, vielleicht dann beim nächsten Umzug ;)
Für diejenigen, die (wie ich bis eben) nicht wissen, wie man seine Installation umzieht:
svn relocate https://svn.fhem.de/fhem/trunk/fhem <lokaler Ordner>
sorgt dafür, daß der neue Server anstatt SF genutzt wird.
Hallo Markus, @all,
Rudi hat mir soeben den Zugang via Public-Key eingerichtet. Die Verbindung als solche scheint zu funktionieren.
Eine SSH-Putty Session wird beantwortet:
login as: DS_Starter
Authenticating with public key "rsa-key-20161211"
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 ) ) )
Aber sowohl die Verbindung über TortoiseSVN als auch via Linux-SVN klappt nicht. Die Einrichtung habe ich so vorgenommen wie auf https://svn.fhem.de/ beschrieben.
Hier ein Beispiel mit einem Test-Checkout via Linux:
root@fhemtest:/fhem-code# svn co svn+ssh://svn.fhem.de/ /fhem-code/test
Enter passphrase for key '/sds1/backup/Backup_FHEM/SSH-Key/Putty_private_key.ppk':
Enter passphrase for key '/sds1/backup/Backup_FHEM/SSH-Key/Putty_private_key.ppk':
Enter passphrase for key '/sds1/backup/Backup_FHEM/SSH-Key/Putty_private_key.ppk':
svn: E210002: Unable to connect to a repository at URL 'svn+ssh://svn.fhem.de'
svn: E210002: Um Probleme mit der Konfiguration von SSH zu untersuchen, entfernen Sie die Option »-q« von »ssh« im Abschnitt »[tunnels]« Ihrer Konfigurationsdatei für Subversion.
svn: E210002: Netzwerkverbindung wurde unerwartet geschlossen
root@fhemtest:/fhem-code#
Auf der Seite http://wallyatkins.com/using-a-non-standard-port-with-subversion wird darauf hingewiesen dass man den abweichenden Port auf Serverseite setzen soll um dieses Problem zu lösen. Aber das werdet ihr ganz sicher gemacht haben.
$ cat $HOME/.subversion/config
[tunnels]
sshtunnel = ssh -p <Port>
Mir fällt da momentan nichts ein wo ich noch suchen könnte.
Habt ihr eine Idee für mich ?
Grüße
Heiko
Hallo Heiko,
Bitte zeige mal einen screenshot der entsprechenden Putty-Session, welche du angelegt hast. Bitte zeige auch deine ~/.ssh/config auf deiner fhemtest-Maschine.
Zitat von: DS_Starter am 12 Dezember 2016, 19:30:59
Auf der Seite http://wallyatkins.com/using-a-non-standard-port-with-subversion wird darauf hingewiesen dass man den abweichenden Port auf Serverseite setzen soll um dieses Problem zu lösen. Aber das werdet ihr ganz sicher gemacht haben.
$ cat $HOME/.subversion/config
[tunnels]
sshtunnel = ssh -p <Port>
Hier hast du den entsprechenden Artikel missinterpretiert. Dieser Artikel zeigt die Problematik, wenn man versucht einen abweichenden Port in der URL direkt anzugeben (svn+ssh://user@host
:port). Das funktioniert nicht. Als Lösung wird hierbei empfohlen die
lokale Datei ~/.subversion/config mit den entsprechendem Inhalt zu ergänzen um sich somit ein neues Tunnel-Command zu definieren (ssh -p <Port>). Wenn man dann den Checkout mit der URL svn+sshtunnel://user@host/pfad/ durchführt, wird "ssh -p <Port>" aufgerufen anstatt nur "ssh". Es ist also eine alternative Vorgehensweise zu dem, was auf https://svn.fhem.de/ steht für den Read/Write-Checkout.
Gruß
Markus[/code]
ZitatHier hast du den entsprechenden Artikel missinterpretiert.
Ah, ok . War auf der Suche nach einem Lösungsweg und bin darüber gestolpert.
Meine ~/.ssh/config sieht so aus:
root@fhemtest:/fhem-code# more ~/.ssh/config
Host svn.fhem.de
IdentityFile /sds1/backup/Backup_FHEM/SSH-Key/Putty_private_key.ppk
Port 55522
User DS_Starter
Die Screenshots zu Putty sind angehängt.
Das Keypair habe ich übrigens mit puttygen angelegt. Der Screenshot ist auch noch dabei.
Grüße
Heiko
Hallo Heiko,
bitte in deiner Putty-Session den Hostnamen (NICHT DEN SESSIONNAMEN!!!) folgendermaßen ändern:
DS_Starter@svn.fhem.de
Der Username fehlt. Ist mir beim durchgehen der Anleitung auf svn.fhem.de eben aufgefallen und habe ich bereits korrigiert.
Bitte dann die Session speichern und nochmal versuchen auszuchecken.
Vielen Dank
Gruß
Markus
Hallo Markus,
leider negativ. Im Anhang wieder der Screenshot.
Ob mit meinem Public Key etwas nicht stimmt ?
Ich könnte ihn nochmal statt mit puttygen mit:
ssh-keygen -b 1024 -t dsa -N passphrase -f mykey
neu erstellen und euch neu schicken.
Grüße
Heiko
Hallo Heiko,
du musst im Tortoise den PuTTY Session-Namen (in deinem Fall: "svn.fhem.de") verwenden und nicht die tatsächliche URL.
Also in deinem Fall folgende Check-Out-URL verwenden:
svn+ssh://svn.fhem.de/
In deinem gezeigten Versuch geht der Verbindungsversuch auf den Standardport 22, welchen wir aus Sicherheitsgründen geändert haben.
Gruß
Markus
Ja stimmt natürlich, sorry, hatte ich übersehen.
Grade probiert. Aber am Ergebnis hat das nichts geändert. Sieht genauso aus.
Zitat von: DS_Starter am 12 Dezember 2016, 19:30:59
Hier ein Beispiel mit einem Test-Checkout via Linux:
root@fhemtest:/fhem-code# svn co svn+ssh://svn.fhem.de/ /fhem-code/test
Enter passphrase for key '/sds1/backup/Backup_FHEM/SSH-Key/Putty_private_key.ppk':
Enter passphrase for key '/sds1/backup/Backup_FHEM/SSH-Key/Putty_private_key.ppk':
Enter passphrase for key '/sds1/backup/Backup_FHEM/SSH-Key/Putty_private_key.ppk':
svn: E210002: Unable to connect to a repository at URL 'svn+ssh://svn.fhem.de'
svn: E210002: Um Probleme mit der Konfiguration von SSH zu untersuchen, entfernen Sie die Option »-q« von »ssh« im Abschnitt »[tunnels]« Ihrer Konfigurationsdatei für Subversion.
svn: E210002: Netzwerkverbindung wurde unerwartet geschlossen
root@fhemtest:/fhem-code#
Hallo Heiko,
die gleiche nichtssagende Fehlermeldung hatte ich beim Checkout unter Linux auch.
Habe ssh dann gespraechiger gemacht mit:
export SVN_SSH="ssh -v " Dadurch habe ich festgestellt, dass der mit puttygen generierter privatkey nicht akzeptiert wurde.
Dann habe ich den privatkey in puttygen über "Conversion/Export OpenSSH Key" im OpenSSH-Format gespeichert. Mit dem privatkey konnte ich dann problemlos auschecken.
Vielleicht ist das noch ein Ansatzpunkt.
Gruß, Christian
Hallo Christian,
habe ich jetzt auch so gemacht .... im Linux klappt es jetzt, das CO läuft gerade.
Im TortoiseSVN kriege ich immer noch diesen Error wie in den Screenshots dargestellt.
Aber schon mal ein Fortschritt ... danke für den Tipp.
EDIT: eigenartig ist dass der Privatekey+Keyphrase immer 2mal abgefragt wird. Nach dem 2. mal startet der Checkout.
Grüße
Heiko
Hallo Christian und Markus,
jetzt klappt es auch mit TortoiseSVN.
Ich habe den Usernamen vor der Serveradresse wieder entfernt und mußte auch wieder den ursprünglichen (nicht openssh) private key hinterlegen.
Dann wird der Username und die Keyphrase abgefragt. Und zwar ebenfalls genau 2 mal so wie ich es unter Linux schon beobachtet habe.
Ich vermute dass dieses Verhalten mit dem Problem ingesamt zu tun hat.
Grüße
Heiko
Zitat von: DS_Starter am 13 Dezember 2016, 00:12:32
Ich habe den Usernamen vor der Serveradresse wieder entfernt und mußte auch wieder den ursprünglichen (nicht openssh) private key hinterlegen.
Dann wird der Username und die Keyphrase abgefragt. Und zwar ebenfalls genau 2 mal so wie ich es unter Linux schon beobachtet habe.
Ich vermute dass dieses Verhalten mit dem Problem ingesamt zu tun hat.
Schau Dir bitte einmal ssh-agent für Linux bzw. pageant für Windows an. Damit sollte sich das Problem der mehrfachen Passwortabfragen lösen lassen.
Muss ich als "normaler user" etwas an meinem FHEM ändern?
Nein, für normale User, die ein Update über das "update"-Kommando durchführen, ändert sich nichts.
Nur User, die ihre Installation über SVN updaten, müssen die URL ändern.
Gruß
Markus
ZitatSchau Dir bitte einmal ssh-agent für Linux bzw. pageant für Windows an. Damit sollte sich das Problem der mehrfachen Passwortabfragen lösen lassen.
pagent ist ein schönes Hilfsmittel und dadurch nun absolut stressfrei in Verbindung mit gesetztem Usernamen vor dem Server (DS_Starter@svn.fhem.de).
Danke !
Grüße
Heiko
Hallo zusammen,
das SVN-Repository ist nun auf die neue Infrastruktur umgezogen. Dies bedeutet, dass Änderungen nun nur noch unter https://svn.fhem.de/ verfügbar sind. Das SourceForge-Repository bleibt auf dem aktuellen Stand eingefroren.
Auf den update-Befehl in FHEM hat dies keinen Einfluss, da dieser seine Daten bereits aus dem neuen Repository bezieht.
Viele Grüße
Markus
Hallo zusammen
Habe ebenfalls Probleme mit Putty und Tortoise
Ich bin der Anleitung gefolgt und habe bei PUTTY und Tortoise den gleichen Wortlaut in der Fehlermeldung.
Stimmt was nicht mit meinem Zertifikat oder was mache ich im Einzelnen falsch?
Gruß
Sailor
Hallo Sailor,
du nutzt einen Private-Key der im falschen Format ist. Dein Private-Key ist auf einer Linux-Shell generiert worden und du versuchst diesen gerade mit PuTTY zu nutzen. Im PuTTY Terminal kommt daher die Meldung: "unable to use key file ... (OpenSSH SSH-2 private key)").
Bitte starte PuttyGen und wähle oben Conversions und "Import key". Wähle dort den aktuelles Keyfile aus "id_Sailor.ppk" und dann unten auf "Save private key". Damit wird der Private-Key im PuTTY-Format gespeichert.
Das nun gespeicherte File musst du dann als Private-Key File in deiner PuTTY Session verwenden.
Gruß
Markus
PS: Für Entwickler gibt es extra den Thread https://forum.fhem.de/index.php/topic,62348.msg542767.html#new ;)
Hallo Markus
Zitat von: Markus Bloch am 19 Dezember 2016, 10:00:24
Bitte starte PuttyGen und wähle oben Conversions und "Import key". Wähle dort den aktuelles Keyfile aus "id_Sailor.ppk" und dann unten auf "Save private key". Damit wird der Private-Key im PuTTY-Format gespeichert.
Das nun gespeicherte File musst du dann als Private-Key File in deiner PuTTY Session verwenden.
Faszinierend: Kaum macht man es richtig - Funktionierts!
Danke
Gruss
Sailor
Guten Abend User,
da hier die ähnlichen Dinge schon einmal bei anderen Users auftraten, so verweise ich mal Hilfesuchend auf den von mit geöffneten Post.
https://forum.fhem.de/index.php/topic,123221.msg1177627.html#msg1177627
Vielleicht erreiche ich somit Mithilfe um den Fehler zu finden.
LG Marco