client della riga di comando SVN: checkout rifiutato quando la password LDAP cambiava "svn: OPTIONS di" (repo) "autorizzazione fallita" (ma funziona in TortoiseSVN)

3

Quando si utilizza il client svn della riga di comando / terminale, un collega riceve "svn: OPTIONS di" [repo] "... autorizzazione non riuscita" messaggio di errore quando tentano di eseguire il checkout del repository come copia locale di lavoro.

Di solito erano in grado di farlo, ma recentemente hanno dovuto cambiare la loro password (politica di sicurezza periodica di routine). E ha smesso di funzionare. NOTA: il comando svn check richiede una password ogni volta (che forniscono - cioè la loro nuova.)

Ma stranamente non hanno problemi con Tortoise SVN, funziona su quello. Forniscono i loro soliti login e nuova password e funziona.

La nostra configurazione è una macchina CentOS Linux virtualizzata con diversi account utente Linux in cui avviene lo sviluppo e il repository centrale SVN si trova su un server separato, l'autenticazione utilizza il nostro login LDAP (cioè lo stesso accesso aziendale utilizzato per accedere alle nostre macchine Windows) ). Effettuiamo il login come utenti Linux al nostro server di sviluppo dalle nostre macchine Windows, utilizzando gli strumenti SSH terminali standard, ad es. PuTTY o MobaXTerm o CygWin.

Quando cambio la mia password non ho lo stesso problema, sono in grado di effettuare il checkout.

Ho visto molte domande su questo messaggio di errore dalla ricerca di vari forum su google, ma nessuno mi ha ancora fornito una soluzione.

Una delle soluzioni che ho trovato suggerisce di cancellare o rimuovere una cache locale contenente l'autenticazione, in una cartella .subversion, lo abbiamo provato ma abbiamo ancora lo stesso problema. Ho anche provato a visitare un'altra cartella.

Quindi sembra che abbiamo eliminato ogni traccia di password memorizzate nella cache, ma continua a essere rifiutata.

Potrebbe esserci un altro posto sulla nostra macchina CentOS Linux che memorizza nella cache il login Cosa si intende per OPZIONI (potrebbe essere un'impostazione da qualche parte sulla nostra macchina di sviluppo o sul server di repository SVN?) Potrebbe essere una cache Proxy HTTP delle credenziali del mio collega memorizzata da qualche parte - quindi dobbiamo cancellarlo quando viene cambiata una password?

(erroneamente pubblicato su superuser.com (che riguarda gli utenti), quindi chiuso lì e spostato qui)

    
posta therobyouknow 24.07.2012 - 11:29
fonte

2 risposte

3

La causa principale è molto probabilmente un problema con la serie di caratteri. Per spiegare, la nostra configurazione SVN utilizza l'autenticazione LDAP, il che significa che il login / password che usiamo per SVN è lo stesso di quello che usiamo per l'accesso all'account aziendale di rete Windows PC, che è una comoda soluzione popolare che richiede un solo account per entrambi. Tuttavia, di solito impostiamo / aggiorniamo la nostra password tramite la normale modifica della password di Windows (CTRL-ALT-DEL) e crediamo che il set di caratteri ISO in Windows sia diverso da quello utilizzato per la CLI SVN in Linux.

La nostra password non funzionava perché conteneva un simbolo di cancelletto che può essere interpretato in modo diverso con un set di caratteri o mappatura dei tasti diverso nella password di LDAP di Windows che cambia rispetto all'autenticazione SVN LPAP di Linux a causa della mancata corrispondenza nel set di caratteri usato. (Credito a WanDisco folk per averci assistito con le indagini, in tutta onestà siamo arrivati contemporaneamente alla stessa conclusione durante una chiamata, non lavoriamo per loro ma usiamo i loro servizi, dovrei dare credito dove è dovuto.)

    
risposta data 07.08.2012 - 16:59
fonte
6

Scommetto che SVN di Tortoise legge diverse opzioni di configurazione rispetto a SVN CLI. SVN può leggere la sua configurazione da molte fonti diverse . Vorrei provare a giocare con impostazioni come store-auth-creds nel file o nel registro INI per utente.

    
risposta data 24.07.2012 - 15:53
fonte

Leggi altre domande sui tag