Хорошо, по какой-то причине сегодня утром я не могу подключиться к репозиторию Wordpress SVN и выполнить основные команды SVN (например, checkout, update).
Вот пример того, что происходит:
$ svn co http://svn.automattic.com/wordpress/tags/3.3/
# Adds a bunch of files...
svn: warning: Error handling externals definition for '3.3/wp-content/plugins/akismet':
svn: warning: PROPFIND of '/!svn/vcc/default': could not connect to server (http://plugins.svn.wordpress.org)
Checked out revision 19597.
$ cd 3.3
$ svn update
svn: OPTIONS of 'http://svn.automattic.com/wordpress/tags/3.3': could not connect to server (http://svn.automattic.com)
Тем не менее, когда я выполняю те же самые команды на моем сервере разработки (Linode VPS), он работает нормально.
Я довольно много об этом гуглял и нашел такие страницы:
Многие из этих статей о чем-то говорят, это ваш прокси-сервер. Ну, я не за прокси-сервером:
http://whatismyipaddress.com/proxy-check
Proxy server not detected.
IP 24.21.xxxx.xxx
rDNS FALSE
WIMIA Test FALSE
TOR Test FALSE
Loc Test FALSE
Header Test FALSE
DNSBL Test FALSE
Просто обычное старое домашнее интернет-соединение Comcast.
Кроме того, я могу нормально просматривать SVN-репозиторий WordPress через мой браузер.
Во всяком случае, я как бы зашел в тупик и думаю, мне интересно, есть ли у кого-нибудь какие-либо предложения относительно того, как решить проблему или обойти ее? Я попытался настроить прямой прокси-сервер на установке Apache, которую я запускаю на этом dev-сервере, а затем обновил файл ~ / .subversion / server, но это не сработало, или я настроил что-то неправильно.
Ну, если у кого-нибудь есть какие-нибудь блестящие идеи или объяснения, я бы хотел их услышать ...
Обновление
У меня был сотрудник, проверяющий это на его домашней связи - он также использует Comcast. Он получил такую же ошибку, как и я. Так что, похоже, это какая-то проблема, связанная с Comcast, специфичная для хранилища Wordpress svn. Мне удалось проверить другие общедоступные репозитории через http (например, из Google Code).
Я провел серию тестов и не смог найти никаких скрытых прокси или серверов кэширования между мной и хранилищем.
Я выполнил traceroute по совету Ленивых Барсуков, и вот что я получил:
$ traceroute svn.automattic.com
traceroute to svn.automattic.com (72.233.56.196), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 0.659 ms 0.292 ms 0.185 ms
2 * * *
3 te-5-7-ur01.hollywood.or.bverton.comcast.net (68.85.150.225) 8.792 ms 8.309 ms 9.054 ms
4 xe-3-1-0-0-ar03.beaverton.or.bverton.comcast.net (68.87.216.33) 14.354 ms 24.859 ms 8.753 ms
5 pos-3-8-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.117) 21.869 ms
pos-3-1-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.113) 21.791 ms
pos-3-0-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.109) 22.983 ms
6 pos-0-7-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.85.46) 23.682 ms 25.043 ms 24.675 ms
7 xe-10-3-0.edge1.sanjose1.level3.net (4.71.118.5) 61.048 ms 23.986 ms 24.221 ms
8 vlan80.csw3.sanjose1.level3.net (4.69.152.190) 25.257 ms 25.648 ms
vlan90.csw4.sanjose1.level3.net (4.69.152.254) 24.310 ms
9 ae-82-82.ebr2.sanjose1.level3.net (4.69.153.25) 24.870 ms
ae-92-92.ebr2.sanjose1.level3.net (4.69.153.29) 25.371 ms
ae-91-91.ebr1.sanjose1.level3.net (4.69.153.13) 24.744 ms
10 ae-34-34.ebr4.sanjose1.level3.net (4.69.153.34) 36.011 ms 25.975 ms 36.053 ms
11 ae-5-5.ebr2.sanjose5.level3.net (4.69.148.141) 25.236 ms 25.307 ms 25.305 ms
12 ae-6-6.ebr2.losangeles1.level3.net (4.69.148.201) 31.299 ms 34.076 ms 33.401 ms
13 ae-3-3.ebr3.dallas1.level3.net (4.69.132.78) 59.012 ms 58.604 ms 60.576 ms
14 ae-83-83.csw3.dallas1.level3.net (4.69.151.157) 59.708 ms 65.724 ms
ae-73-73.csw2.dallas1.level3.net (4.69.151.145) 60.383 ms
15 ae-42-90.car2.dallas1.level3.net (4.69.145.196) 60.636 ms
ae-22-70.car2.dallas1.level3.net (4.69.145.68) 59.572 ms 59.758 ms
16 databank-ho.car2.dallas1.level3.net (4.71.170.2) 58.711 ms 59.994 ms 60.561 ms
Я не знаю, необычно ли это или что-то в этом роде. Я попробовал то же самое на моем сервере разработки, и результат выглядел в основном одинаково, за исключением строки 2 с * * *.
Я успешно настроил прямой прокси-сервер на своем сервере dev, поэтому сейчас я взломал решение, но я все еще не совсем понимаю, что происходит ...
Обновление 2
В ответ на вопрос вот как я сконфигурировал вещи для использования моего сервера dev в качестве прокси на данный момент.
Сначала я настроил apache на своем dev-сервере для работы в качестве прокси. Убедитесь, что эти директивы находятся где-то в вашей цепочке файлов конфигурации Apache (httpd.conf, каталог vhosts.d и т. Д.):
Listen 8080
<VirtualHost _default_:8080>
ProxyRequests On
ProxyVia On
ProxyPreserveHost On
<Proxy *>
Order deny,allow
Deny from all
Allow from xxx.xxx.xxx.xxx
</Proxy>
</VirtualHost>
Это предполагает, что у вас есть рабочий Apache, настроенный где-то на сервере разработки (я бы определенно не использовал его на рабочем сервере) с установленным mod_proxy. Порт 8080 является произвольным. По сути, для несопоставленного виртуального хоста (т. Е. Любой запрос, который не соответствует другим настроенным вами хостам), он включит прокси-сервер и прокси-запрос через. Измените «xxx.xxx.xxx.xxx» на свой собственный IP-адрес.
Теперь вам нужно изменить настройки сервера в вашем файле конфигурации Subversion.
В этом файле:
~/.subversion/servers
Найти этот раздел:
[global]
# http-proxy-exceptions = *.exception.com, www.internal-site.org
# http-proxy-host = proxy1.some-domain-name.com
# http-proxy-port = 80
# http-proxy-username = defaultusername
# http-proxy-password = defaultpassword
# http-compression = no
# http-auth-types = basic;digest;negotiate
# No http-timeout, so just use the builtin default.
# No neon-debug-mask, so neon debugging is disabled.
# ssl-authority-files = /path/to/CAcert.pem;/path/to/CAcert2.pem
Раскомментировать http-proxy-host и http-proxy-port. Для хоста используйте запасное доменное имя, которое вы указали на своем сервере разработки или, вероятно, вы можете просто использовать IP-адрес вашего сервера. Затем установите порт на 8080 или что вы использовали.
Это должно направлять все http-запросы Subversion через ваш прокси, который вы только что настроили. Это не влияет на запросы svn или svn + ssh.
Это был мой быстрый взлом, ваш пробег может отличаться, это может быть совершенно небезопасно или сломано и т. Д.