2012-08-14 6 views
11

Kiedy uruchomić wiersz polecenia svn od Jenkins shell otrzymuję ten błąd:wiersz polecenia SVN w Jenkins nie ze względu na świadectwo niedopasowania serwerze

D:\Jenkins\jobs\Merge Trunk to Stable\workspace\stable>svn up --trust-server-cert --non-interactive 
Updating '.': 
svn: E175002: Unable to connect to a repository at URL 'https://xxx/stable' 
svn: E175002: OPTIONS of 'https://xxx/stable': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://xxx) 

Ale gdy uruchamiam to samo z okna wiersza poleceń CMD to jest OK:

D:\Jenkins\jobs\Merge Trunk to Stable\workspace\stable>svn up 
Updating '.': 
At revision 1797. 

lub

D:\Jenkins\jobs\Merge Trunk to Stable\workspace\stable>svn up --trust-server-cert --non-interactive 
Updating '.': 
At revision 1797. 

Każdy pomysł jak rozwiązać ten problem ??

+0

Czy musisz dodać gdzieś odciski palców serwera dla tego serwera? – fduff

+0

Nie o tym wiem. Naprawdę nie rozumiem tego pytania ... Wiem, że nazwa certyfikatu serwera nie jest zgodna. Nie sprawiło mi to wcześniej problemu. –

+0

Miałem na myśli coś podobnego do pliku serwera Tortoise/Network/Subversion; może tam być brakujące ustawienie, ale to tylko domysły. – fduff

Odpowiedz

15

Dość stare pytanie, ale wciąż całkiem żywe.

Problem polega na tym, że akceptowana pamięć podręczna certyfikatów (a także pamięć podręczna nazw użytkowników/haseł) jest przypisana do użytkownika, a ponieważ Jenkins działa jako inny użytkownik (najprawdopodobniej SYSTEM), nie ma pojęcia zwykłej pamięci podręcznej użytkownika.

Nie wszyscy klienci SVN pozwalają ci zrobić "echo p" (nie działa to dla mnie), a --trust-server-cert najwyraźniej też nie działa w tym przypadku.

To, co zadziałało dla mnie, to open a console window as SYSTEM, i wykonaj tam interaktywny kod akceptacji-logowania-hasła.

Ponieważ wszystkie dane są zapisywane w pamięci podręcznej, należy to zrobić tylko raz, i od tego czasu wszystkie żądania będą działać pod różnymi adresami: svn up.

+1

plusone - Trzy lata później nadal problem, a Twoja odpowiedź mnie uratowała! Dzięki. –

6

W końcu udało mi się rozwiązać problem! To, co zrobiłem, jest po prostu wpisane w skrypcie Jenkinsa:

echo p | svn up --username <usr> --password <pwrd> 

To rozwiązało! ponieważ echo emulowało wejście ręczne, aby trwale zaakceptować certyfikat.

głównej przyczyną jest fakt, że skrypty powłoki Jenkins uruchomić pod użytkownikiem usług Windows - w ten sposób korzysta z innego miejsca dla pamięci podręcznej profilu użytkownika (w C:\Windows\System32\config\systemprofile\AppData\Roaming\Subversion zamiast %USERPROFILE%\AppData\Roaming\Subversion\)

0

Być może, certyfikat wydawany jest inna nazwa hosta (nie xxx, ale coś podobnego do xxx.twojafirma.com). Jeśli tak, to wykonaj czyste zamówienie z tą nazwą hosta.

0

echo p | svn commands

Pracował wielki Jenkins w wierszu poleceń okna wsadowego. Wykonanie tej czynności spowoduje trwałe zaakceptowanie certyfikatu użytkownika Jenkins w polu Build.

0

Uruchamianie poleceń Svn przez Jenkinsa na niewolniku dawało mi trudności. Zrobiłem, co następuje:

Jeśli jesteś na systemie UNIX następnie poniższy link: http://www.microhowto.info/howto/configure_subversion_to_trust_a_given_ssl_certificate.html

Jeśli jesteś na systemie Windows, a następnie zrobić:

cd %APPDATA%\Subversion\ 

Następnie edytować plik w tym katalogu server poprzez usunięcie # znak z elementu ssl-authority-files i zaktualizuj ścieżkę do miejsca przechowywania pliku certyfikatu SSL.

Zmień również poniższe, jeśli podoba ci się przechowywanie poświadczeń.

store-passwords = yes 
store-ssl-client-cert-pp = yes 

Gdy to zrobisz, będzie trzeba także dodać certyfikat do komputera z systemem Windows, wykonując Add the Cert to the Trusted Root CA Store

0

może to wydawać się okropnym odpowiedź, ale po wyczerpaniu innych te, które nie działa dla mnie z powodu innych problemów, wybieram przejście na serwer SVN, aby nie używać SSL.

To była tylko opcja, ponieważ po prostu skonfigurowałem ten serwer i pracowałem w całkowicie wewnętrznej sieci, ale całkowicie wyeliminowałem problem. I skończyły mi się inne opcje i czas.

Ja również sugeruję tylko to, że ktoś nie zdaje sobie sprawy, że to nawet opcja. Używanie SSL sprawiłoby, że czułbym się znacznie lepiej bez względu na ekspozycję serwera.

0

Miał ten sam problem z Jenkinsem i Window 7. Rozwiązałem to, przechodząc do usług i wybierz Jenkins i przejdź do Log-on i wprowadź poświadczenia administracyjne i ponownie uruchom usługę Jenkins.

Mam nadzieję, że to rozwiąże problem.

Powiązane problemy