Давно не брал в руки шашек занимался своими Ruby-новыми проектами. Сегодня попробовал сделать коммит новой версии Mxx_ru в svn-овский репозиторий на RubyForge. Не прошла аутентификация. Там для коммитеров доступ осуществляется через svn+ssh. И вот ssh меня не пускает. Стал разбираться.
Во-первых, svn слишком большой диагностики не дает. Пишет что не получилось и все. И советует из опций ssh в svn-овском конфиге флажок –q убрать. Хотя его там отродясь не было. Опция ssh в конфиге закомментирована была:
[tunnels]
# ssh = $SVN_SSH ssh
Зато, если преобразовать ее вот к такому виду:
[tunnels]
ssh = $SVN_SSH ssh –v –v
то процесс подключения к серверу и взаимодействия с ним очень подробно отображается в stderr. Ключик –v для ssh вообще очень пользительная штука :)
Правда, по-началу, подробная диагностика от ssh причину проблем не показывала. Видно было, что мой ключ найден, но не видно было, чтобы ssh пытался его применить. К счастью, в Google я не забанен и поиск помог найти причину: если права доступа к ~/.ssh/identity даны не только владельцу, то ssh этот ключ молча игнорирует (по крайней мере, при уровне логирования debug2 ssh на этот счет не ругается).
Я пользуюсь ssh-ем из cygwin-а. И после смены рабочей машины содержимое ~/.ssh восстановил из архива. Видимо, не в cygwin-овском shell-е, а в Window-ом. Поэтому права на доступ к файлам ключей были даны всем. И это ssh-у не нравилось. Пришлось вспоминать параметры к chmod :)
Но и после chmod-а по ssh-у подключиться удалось не сразу. Точной причины я не понял. Мне показалось, что дело в несовпадении протокола SSH-протокола. У меня ssh по умолчанию он пытается использовать SSH v2. А на стороне диагностируется версия 1.99. После того, как я в /etc/ssh_config задал для узла rubyforge.org использование версии 1, сразу же удалось подключиться и залогиниться.
Еще года четыре назад я был с ssh-ем если не на “ты”, то хотя бы на довольно панибратском “вы”. А вот глядишь, прошло несколько лет и без man-ов с гуглем уже и старых настроек восстановить не могу :(
После того, как разобрался с svn-ом, начались приключения с ruby, rake и RubyGem-ами. При попытке заставить rake создать результирующий gem-файл, стал получать ошибку:
rake aborted!
193: %1 is not a valid Win32 application. - c:/ruby19/lib/ruby/1.9.1/x64-mswin64_80/zlib.so
Windows у меня 64-битная. И Ruby 1.9.1 так же 64-битный. В нем изначально с дополнительными DLL-ками проблема была. Например, zlib.dll не было. Пришлось разыскивать где-то на стороне. Уже не помню где, но разыскал. А тут вдруг какая-то новая беда с zlib-ом. Причем не понятно, в чем именно проблема.
Пришлось ставить 32-битовую версию Ruby 1.9.1. В ней, правда, так же zlib.dll не оказалось. Но у меня с собой, что называется, было :) Поэтому все заработало. Только вот не могу понять, почему в официальные сборки ruby, которые лежат на ruby-lang.org, не входит тот же zlib.dll изначально? В каком-то стороннем One-Click Installer-е zlib есть, а в официальной сборке нет. Может это наследие Unix-овых корней ruby, где дистрибутив без уже установленного zlib еще поискать нужно?
По ходу дела наткнулся еще на одну неприятную штуку. В поиска решения проблемы с zlib.so поставил себе и Ruby 1.9.2. Попытался прогнать Mxx_ru-шые тесты. Но обломался. Мои исходники рассчитаны на то, что поиск подключаемых через require файлов происходит и в текущем каталоге. А вот в Ruby 1.9.2 эту фичу уже отключили. Зачем не понятно. Но понятно, что под Ruby 1.9.2 нужно будет Mxx_ru адаптировать отдельно :(
Да, и еще оказалось, что на ruby-lang.org 64-битовых Windows-сборок последней версии Ruby 1.9.2 нет. В общем, приключения продолжаются :)
Комментариев нет:
Отправить комментарий