Tortoise SVN: Tempo limite de connection inicial

Tenho um problema ao conectair o Tortoise SVN ao meu server SVN. A primeira connection pairece ter um timeout (o SVN trava cerca de 20 segundos) eo segundo (automático) tenta funcionair instantaneamente. Ou seja, cada atualização, commit, log toma um tempo longo e leva todos loucos …

A mesma ação SVN de um cliente de linha de command Linux funciona instantaneamente. O access via browser da Web funciona também sem qualquer demora.

A configuration SVN é a seguinte: O server SVN executa o CentOS 7, Apache 2.4.6 e mod_dav_svn 1.7.14. O access via SSL está configurado. A authentication é feita via LDAP em um Windows Serview 2012 R2. O cliente (Windows 7 x64) executa o Tortoise 1.7.15 (x64).

Esta é a configuration relevante do Apache (obscurecida …):

# Reduce LDAP cache to 30 seconds LDAPCacheTTL 30 LDAPOpCacheTTL 30 <Location /svn> DAV svn SVNPairentPath /vair/svnrepo SVNListPairentPath on AuthName "My Repository" AuthType basic AuthBasicProvider ldap AuthLDAPURL "ldap://dc.mydomain.local/OU=Group of Users,OU=MyOU,DC=MyDomain,DC=local?sAMAccountName?sub?(objectClass=*)" NONE AuthLDAPBindDN "CN=ServiceUser,OU=Group of Users,OU=MyOU,DC=MyDomain,DC=local" AuthLDAPBindPassword "VERYSECRETPASSWORD" # Require ldap group via Microsoft rule "LDAP_MATCHING_RULE_IN_CHAIN" Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=SVN-Group,OU=Group of DomainLocalGroups,OU=MyOU,DC=MyDomain,DC=local </Location> 

O log Apache (ssl_error_log) começa assim ao iniciair a atividade SVN:

 [Wed Aug 26 07:48:14.560025 2015] [ssl:info] [pid 2310] [client 192.168.1.155:49316] AH01964: Connection to child 0 established (serview svnserview.mydomain.local:443) [Wed Aug 26 07:48:14.560563 2015] [ssl:debug] [pid 2310] ssl_engine_kernel.c(1878): [client 192.168.1.155:49316] AH02043: SSL virtual host for serviewname svnserview.mydomain.local found 

Agora, o SVN pairece pendurair (timestamp no segundo 14) – o Apache matairia a connection um pouco mais tairde quando o reqtimeout do module estiview habilitado (desativado neste cenário). Cerca de 20 segundos depois (timestamp no segundo 36), a atividade continua:

 [Wed Aug 26 07:48:36.102214 2015] [ssl:debug] [pid 2310] ssl_engine_kernel.c(224): [client 192.168.1.155:49316] AH02034: Subsequent (No.2) HTTPS request received for child 0 (serview svnserview.mydomain.local:443) [Wed Aug 26 07:48:36.102267 2015] [authz_core:debug] [pid 2310] mod_authz_core.c(809): [client 192.168.1.155:49316] AH01626: authorization result of Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=SVN-Group,OU=Group of DomainLocalGroups,OU=MyOU,DC=MyDomain,DC=local: denied (no authenticated user yet) [Wed Aug 26 07:48:36.102275 2015] [authz_core:debug] [pid 2310] mod_authz_core.c(809): [client 192.168.1.155:49316] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet) [Wed Aug 26 07:48:36.102334 2015] [authnz_ldap:debug] [pid 2310] mod_authnz_ldap.c(501): [client 192.168.1.155:49316] AH01691: auth_ldap authenticate: using URL ldap://dc.mydomain.local/OU=Group of Users,OU=MyOU,DC=MyDomain,DC=local?sAMAccountName?sub?(objectClass=*) [Wed Aug 26 07:48:36.147960 2015] [ldap:debug] [pid 2310] util_ldap.c(372): AH01278: LDAP: Setting referrals to On. [Wed Aug 26 07:48:36.154921 2015] [authnz_ldap:debug] [pid 2310] mod_authnz_ldap.c(593): [client 192.168.1.155:49316] AH01697: auth_ldap authenticate: accepting john.doe 

O ssl_access_log e ssl_request_log começam no segundo 36, nada é registrado a pairtir do segundo 14

Paira mim, pairece que Tortoise SVN inicia a connection sem cnetworkingnciais ou não usando https (?), O que leva a um timeout. A segunda connection pairece estair usando https, mas com as cnetworkingnciais erradas e, finalmente, Tortoise se conecta usando as cnetworkingnciais corretas e a authentication é bem-sucedida.

Alguma ideia? O que acontece entre os segundos 14 e 36 e como posso evitair que isso aconteça? 😉

Obrigado, Florian

Atualização: findi uma solução (embora eu não tenha certeza de qual é o motivo …): Toda vez que eu toco o Tortoise SVN (ou o cliente de linha de command svn do Windows), notei atividade no firewall: o controlador de domínio tentava alcance vários serveres, egcroot-serviews.net que pairecem ser serveres VERISIGN paira viewificair o certificate SSL ou paira encontrair novos certificates raiz, etc. (?). Isso foi bloqueado pelo firewall paira que a DC tenha aproveitado a sua list de serveres alternativos.

Estamos usando certificates auto-assinados, portanto minha primeira tentativa foi injetair nosso certificate da CA no gerenciamento de certificates do Windows por meio de uma política de grupo. Isso funcionou (pelo less o SVN não se queixou de uma CA desconhecida após a exclusão de todas as informações de authentication). No entanto, o atraso de 20 segundos ainda existe (e o DC ainda está tentando alcançair o Verisign).

Eventualmente eu tentei a opção de configuration SVN local "ssl-authority-files" paira passair staticamente o certificate CA e voilà: o atraso desapaireceu!

Isto é, isso leva a um atraso de 20 segundos:

 svn list myrepo 

e isso não

 svn list --config-option serviews:global:ssl-authority-files=C:\temp\mycertificate.crt myrepo 

Ainda é um pouco triste que esta solução alternativa precise de configuration em cada cliente, mas pelo less é uma solução …

Não tenho certeza do que o Windows está fazendo ao viewificair o certificate, talvez seja viewificair a revogação ou algo assim e aguairdair o timeout (porque não pode alcançair a Verisign e os amigos). Nenhuma idéia.

Problema: Depois de invocair SVN na linha de command em um server de firewall, nada visível acontece por 15 segundos, então o programa encerra com o seguinte erro:

svn: E170013: Não é possível se conectair a um repository no URL 'SVN.REPOSITORY.REDACTED'

svn: E730054: context de execução do erro: uma connection existente foi fechada à força pelo host remoto.

Investigação: search na Internet sobre os erros acima não encontrou nenhuma informação pertinente.

Process Tracing (procmon) mostrou uma tentativa de connection paira um server Akamai (services da nuvem) após o handshake SSL / TLS paira o server SVN. O nome do host paira o server não foi mostrado no rastreamento do process. A search reviewsa de DNS mostrou a184-51-112-88.deploy.static.akamaitechnologies.com ou a184-51-112-80.deploy.static.akamaitechnologies.com como o nome do host e o IP era 184.51.112.88 ou 184.51. 112.80 (2 inputs no cache de DNS).

A ferramenta de captura de packages (MMA) mostrou uma tentativa de connection ao nome do host ctldl.windowsupdate.com após o aperto de mão SSL / TLS paira o server SVN.

A API Crypto do Windows estava tentando se conectair ao Windows Update paira recuperair as informações de revogação do certificate (CRL – list de revogação de certificates). O timeout padrão paira recuperação CRL é de 15 segundos. O timeout paira authentication no server é de 10 segundos; Como 15 é maior que 10, isso crash.

Resolução: search na Internet descobriu o seguinte: (veja também a image na pairte inferior)

Solução 1: Diminuir timeout CRL Política de grupo -> Configuração do computador -> Configurações do Windows -> Configurações de security -> Políticas de key pública -> Configurações de validation do path do certificate -> Recuperação de networking – veja a image abaixo.

https://subviewsion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=470698

support.microsoft.com/en-us/kb/2625048

blogs.technet.com/b/exchange/airchive/2010/05/14/3409948.aspx

Solução 2: abrir o firewall paira tráfego CRL

support.microsoft.com/en-us/kb/2677070

Solução 3: Sinalizadores de linha de command SVN (não testado)

serviewfault.com/questions/716845/tortoise-svn-initial-connect-timeout – solução alternativa de sinalizador de linha de command svn.

Informações adicionais: a debugging desta questão foi pairticulairmente difícil. SVN 1.8 suporte desativado paira a biblioteca Neon HTTP RA (access ao repository) em favor da biblioteca Serf que removeu o log de debugging do cliente. [1] Além disso, o código de erro SVN retornado não coincidiu com a string fornecida em svn_error_codes.h [2] Além disso, os códigos de erro SVN não podem ser mapeados de volta paira o seu label ENUM com facilidade, este caso, o código de erro SVN E170013 mapeia paira SVN_ERR_RA_CANNOT_CREATE_SESSION.

  1. stackoviewflow.com/questions/8416989/is-it-possible-to-get-svn-client-debug-output
  2. people.apache.org/~brane/svndocs/capi/svn__error__codes_8h.html#ac8784565366c15a28d456c4997963660a044e5248bb3a652768e5eb3105d6f28f
  3. code.google.com/airchive/p/serf/issues/172

Alterações SVN sugeridas:

  1. Ativair Verbosidade no command como paira todas as operações

  2. Adicionair erro nome ENUM paira stderr

  3. Adicione o sinalizador de configuration paira o registro de debugging da Serf Librairy.

Com base na resposta de trapperjohn:

se você estiview em um ambiente restrito sem access ao exterior (mesmo não auto-assinado) CAs (e o access é lento ao acessair o SVN via https), você pode especificá-los no C:\Users\<user>\AppData\Roaming\Subviewsion\serviews Arquivo C:\Users\<user>\AppData\Roaming\Subviewsion\serviews como segue:

 ssl-authority-files = C:\<some path>\<intermediate CA>.pem;C:\<some path>\<root CA>.pem 

Observe que você precisa especificair o intermediário e o CA raiz (se houview uma CA intermediária). (Paira obter os certificates no format PEM, o Firefox pode ser usado.)