Cap deploy:cold - Problem m. Zugriff auf SVN mittel https (self-certified) und .htaccess-Authentifiz

Community DE
1

Hallo Community,

um während des deployments mit Capistrano auf die Repositiry mittels
https zugreifen zu können, erscheint nach der Anmeldung(SSH) an meinem
Server die Eingabeaufforderung zur Validierung des selbsterstellten
SSL-Zertifikats. Eine der folgenden Eingaben muss gemacht werden:
Ve®werfen, (t)emporär akzeptieren oder §ermanent.

Problem: Die Konsole nimmt zu diesem Zeitpunkt keine Eingabe an und der
Batchvorgang muss abgebrochen werden.
Das gleiche gilt für die Authentifizierung für das SVN Verzeichnis -
keine Eingabe möglich.

Kennt jemand dieses Problem und hat eventuell eine Lösung dafür?
Leider konnte ich bisher nichts vernünftiges finden.

Danke und beste Grüsse,
Roman

2

Roman Sladeczek wrote:

Kennt jemand dieses Problem und hat eventuell eine Lösung dafür?
Leider konnte ich bisher nichts vernünftiges finden.

Ich vermute mal

LC_LANG = C

Jonathan

3

Was passiert, wenn Du außerhalb von cap mit ssh direkt auf Deinen
Server gehst? Ich denke, Du müsstest die gleiche Aufforderung
bekommen, mit “p” permanent akzeptieren können und eigentlich beim
nächsten cap-Versuch Erfolg haben.

Stefan

Stefan T., Stefan Tilkov’s Blog [Stefan Tilkov’s Blog]

4

On Oct 25 2007, at 22:16, Daniel W. wrote:

Mal gespannt obs dafür ne andere Möglichkeit gibt.

Evtl. von einem Rechner, der schon mal auf das repo zugegriffen hat,
~/.subversion/auth/svn.ssl.server/nnnn auf den Zielrechner kopieren,
bevor das repo angefasst wird. (nnnn mit grep herausfinden…)

Gruesse, Carsten

5

Wie Stefan schon geschrieben hat kannst du damit das Problem umgehen.
Also normal die SVN Verbindung per Konsole herstellen,
und das Zertifikat permanent akzeptieren. So hatte ich es damals auch
gemacht. (Machen müssen?)

Mal gespannt obs dafür ne andere Möglichkeit gibt.

Roman Sladeczek schrieb:

6

Hallo Jonathan, Stefan, Daniel, Carsten,

@Stefan, Daniel, Carsten

Wie Stefan schon geschrieben hat kannst du damit das Problem umgehen.
Also normal die SVN Verbindung per Konsole herstellen,
und das Zertifikat permanent akzeptieren. So hatte ich es damals auch
gemacht.

Evtl. von einem Rechner, der schon mal auf das repo zugegriffen hat,
~/.subversion/auth/svn.ssl.server/nnnn auf den Zielrechner kopieren,
bevor das repo angefasst wird. (nnnn mit grep herausfinden…)

Dieser Workaround hat bei mir leider nicht funktioniert.
Die Validierung des Zertifikats habe ich ausserhalb des cap Prozesses
schon gemacht (permanent) und da gibt es keine Probleme. Der Zugriff auf
SVN erfolgt ohne weitere Nachfragen.

cap selbst verlangt trotzdem weiterhin die Validierung.

Das eigentliche Problem ist, dass ich während des Batchvorgangs keine
Eingabe an der Konsole durchführen kann. Denn selbst wenn das Problem
mit dem Zertifikat nicht wäre, könnte ich meine Userdaten bzw. das
Passwort für die Authentifizierung nicht eingeben. Wo ist hier der Hund
begraben?

Mein Problem ist so ziemlich gleichgelagert mit diesem:

http://groups.google.com/group/capistrano/browse_thread/thread/81e3d5aa5d483575/106f07b07a4a50e7
http://groups.google.com/group/capistrano/browse_thread/thread/cf2442eecbcf9881/16f5b72b04510f1d

Nur hat mir diese “Lösung” auch nicht weitergeholfen. Entweder habe ich
Sie nicht verstanden oder das Problem ist nicht wirklich gelöst.

@Jonathan

Ich vermute mal
LC_LANG = C

der Effekt tritt sowohl unter Linux (Fedora6, Suse 10.3) als auch unter
Windows auf!? Oder habe ich Dich jetzt nicht verstanden?

Danke für die Denkanstösse und Ideen. Vielleicht sitze ich einfach nur
schon zu lange vorm Rechner :slight_smile:

Gruss,
Roman

Daniel W. schrieb:

7

Hallo Hendrik,
ich greife jetzt über svn+ssh:// direkt auf die Repo zu. Das scheint
wohl die bessere Alternative zu sein.

Danke nocheinmal an alle für die vielen Tipps.

Gruss,
Roman

Hendrik Volkmer schrieb:

8

Hallo Roman,

Am 25.10.2007 um 23:00 schrieb Roman Sladeczek:

Evtl. von einem Rechner, der schon mal auf das repo zugegriffen
hat, > ~/.subversion/auth/svn.ssl.server/nnnn auf den Zielrechner
kopieren, > bevor das repo angefasst wird. (nnnn mit grep
herausfinden…)

Dieser Workaround hat bei mir leider nicht funktioniert.

Auf welches Repository wird denn da per SSL zugegriffen? Wenn es das
eigene ist, dann gibt’s ja vielleicht die Alternative ssh, wenn das
nicht geht und du cap 2.0 verwendest, könnte deploy_via :copy das
Problem auch umgehen.

Wenn es ein Plugin ist, kann ich generell nur empfehlen, das Plugin
nicht direkt beim deploy aus dem externen Repository zu ziehen
(besser: Selbst Verwalten und z.B. piston http://
piston.rubyforge.org/ verwenden).

Sind zwar alles keine direkten Lösungen, aber vielleicht ist ein
sinnvoller Workaround dabei.

Gruß,
Hendrik

9

nur der Vollständigkeit halber:

mit folgendem Eintrag hat sich mein Problem erledigt:

default_run_options[:pty] = true

Damit werden die erforderlichen Tastatureingaben automatisch gemacht.
Das gilt sowohl für Verbindungen mittels https:// als auch svn+ssh://

Die Erklärung dazu gibt es von Jamis B. himself hier

http://groups.google.com/group/capistrano/browse_thread/thread/13b029f75b61c09d

nachzulesen.

Gruss,
Roman

Hallo Hendrik,
ich greife jetzt über svn+ssh:// direkt auf die Repo zu. Das scheint
wohl die bessere Alternative zu sein.

Danke nocheinmal an alle für die vielen Tipps.

Gruss,
Roman

Hendrik Volkmer schrieb:

und das Zertifikat permanent akzeptieren. So hatte ich es damals auch
Auf welches Repository wird denn da per SSL zugegriffen? Wenn es das

Diese E-Mail wurde vom NOD32 antivirus system geprüft
http://www.nod32.com

rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug

__________ NOD32 2618 (20071026) Information __________

Diese E-Mail wurde vom NOD32 antivirus system
geprüfthttp://www.nod32.com