подключение к ejabberd. часть 2.

в предыдущем посте из серии 100000 речь шла о подключении к локальному узлу ejabberd@машина.
для того, чтобы удалённо подключиться к erlang-узлу с таким именем, нужно чтобы имя «машина» разрезолвилось в нужный ip-адрес. проще всего — добавить строку

ip-адрес машина

в файл /etc/hosts.

проверяем резолвинг:

$ host машинамашина has address такой-то

подключаемся:

$ erl -sname новый_узел -setcookie <cookie> -remsh ejabberd@машина

пояснения смотрите в предыдущем посте

p.s. ежели кто из читателей знает более лучшее/универсальное решение — you are welcome.

p.p.s. до встречи через 100000 секунд.

♺ man hosts host hostname

подключение к ejabberd.

для начала нужно узнать erlang-cookie, используемый узлом (node) ejabberd. сам узел по умолчанию так и называется: «ejabberd@машина».
где находится cookie? скорее всего — в домашнем каталоге пользователя, от имени которого запущен ejabberd. а запущен он, скорее всего, от имени пользователя ejabberd. смотрим выдачу

$ ps aux|grep ejabberd

первым полем и будет имя пользователя, от имени которого запущен процесс (тавтология в компьютерных науках, увы, практически неодолима).
узнать домашний каталог пользователя проще всего так:

getent passwd пользователь

предпоследнее поле (поля разделены двоеточием) и будет искомым каталогом. в нём должен лежать файл «.erlang.cookie». на содержимое этого файла я в дальнейшем буду ссылаться так: <cookie>

теперь собственно подключение.
на той же машине, где крутится ejabberd, подключиться к нему можно так:

$ erl -sname новый_узел -setcookie <cookie> -remsh ejabberd@$(hostname -s)

что такое «новый_узел»? просто какое-нибудь уникальное имя. например, «n0».
что такое «$(hostname -s)»? подстановка (средствами bash-а) результата выполнения команды «hostname -s», которая возвращает короткое имя машины. чаще всего узел, на котором работает ejabberd, называется именно по короткому имени. уточнить можно по выводу ps (см. выше): если среди аргументов присутствует -sname — используется короткое имя машины, если -name — полное (возвращаемое командой hostname без опции -s).

небольшое отступление. допустим, полное имя машины — «машина.domain.org». короткое имя — «машина». так вот ejabberd, скорее всего, запущен на узле «ejabberd@машина». и обращаться к нему следует именно так. а узел «ejabberd@машниа.domain.org» — это уже будет совершенно другой узел.

вот, собственно, и всё подключение.

p.s. ежели кто из читателей знает более лучшее/универсальное решение — you are welcome.

p.p.s. до встречи через 100000 секунд.

♺ man erl ejabberd hostname getent ps grep bash

серия 100000

ровно в 1246500000 секунд от начала эпохи unix в этом блоге появится первый пост из несуществующей пока серии 100000.
почему 100000? потому что планирую в дальнейшем раз в сто тысяч секунд публиковать очередной пост из этой серии.
формат этих постов будет выдерживаться в духе «простое решение маленького вопроса».
так как в данный момент в ареале моих интересов расплодились всякие erlang-и с mnesia-ми, именно о них речь поначалу и пойдёт.

p.s. получить текущее время в секундах с начала эпохи unix:

$ date +%s

получить время в человеческом формате из секунд с начала эпохи unix:

$ date -d @секунды

например, время выхода первого поста из серии 100000:

$ date -d @1246500000

♺ man date

коррупция, головотяпство и разгильдяйство в одной коробке

1. набор спо для школ рассылают вместе с набором проприетарщины.
2. два ключевых установочных диска сделаны незагражающимися.

подробнее:
в блоге у Алксниса
в блоге у Новодворского

проприетарная vs свободная модели разработки в контексте качества.

сразу предупреждаю, что извлечение прибыли как цель разработки п.о. я оставляю за рамками. и останавливаюсь лишь на аспекте качества п.о.

если разработчик выбирает проприетарную (п.) модель, значит рассчитывает обойтись штатом своих программистов.
единственное разумное оправдание выбора п. модели — безукоризненная идеальная работа п.о.
если таковой не наблюдается, значит был сделан неверный выбор.
я лично не наблюдал безукоризненной идеальной работы вообще нигде, ни в одном более или менее крупном программном продукте, с которым я сталкивался. вне зависимости от модели его разработки.
отсюда делаю достаточно смелый вывод — в реальной жизни выбор проприетарной модели с точки зрения качества п.о. никогда себя не оправдывает.

sulci jabber bot on debian lenny. «Unbound value Cryptokit.hash_string»

как полагается, скачал исходники из svn, дал команду make.
по мере возникающих ошибок доустанавливал требуемые пакеты.
пока дело не упёрлось в:

ocamlfind ocamlopt -package cryptokit,xml -c sasl.ml
File "sasl.ml", line 27, characters 10-31:
Unbound value Cryptokit.hash_string
make[3]: *** [sasl.cmi] Error 2

розыски уводят в логи jabber-конференций аж 2005-го года.
и нигде, нигде не написано хоть что-то внятное по поводу решения проблемы.
я абсолютно не знаком с ocaml-ом. но методом курения бамбука и научного тыка пришёл к такому выводу:
когда сборка доходит до этого самого cryptokit-а, а пакет libcryptokit-ocaml-dev не установлен, в каталоге site-lib создаётся каталог cryptokit. вот из-за наличия этого каталога сборка и обламывается.
не знаю, что именно там происходит в ocaml-овых глубинах, но, если заглянуть в файл site-lib/cryptokit/META, можно увидеть строку

version = "1.4"

кто и почему решил, что у cryptokit-а есть версия 1.4 — неизвестно. на сайте, куда отсылают (в sulci/README) за cryptokit-ом: http://caml.inria.fr/distrib/bazar-ocaml/ , самая последняя на данный момент версия — 1.3. google тоже ничего про версию 1.4 не знает.

резюмирую.
надо либо удалить каталог site-lib/cryptokit и сделать (на всякий пожарный) make clean.
либо до сборки установить libcryptokit-ocaml-dev.

кстати, вот минимальный набор пакетов, после которых sulci (у меня) благополучно собирается:

libocamlnet-ocaml-dev ocaml-ulex libssl-ocaml-dev libcryptokit-ocaml-dev libgdbm-dev libsqlite3-ocaml-dev

по зависимостям (вроде бы) устанавливается и всё остальное, что необходимо. по крайней мере всё, что перечислено в sulci/README.

ssh туннель — по-простому

что-то уж очень сложные и заумные руководства попадаются, когда ищешь, как создать туннель с помощью ssh.

ya@inner.host:~$ ssh -f -N -R 2345:inner.host:22 user@outer.host

процесс будет висеть в бэкграунде. можно разлогиниваться. главное, машину не выключать.
пользоваться так:

user@outer.host:~$ ssh -p 2345 ya@localhost
ya@localhost's password: — вбиваем пароль для ya@inner.host и попадаем на inner.host

все. вот и вся инструкция. дальше — лишь пояснения и дополнения.

смысл обозначений:
inner.host — машина за nat-ом
ya — ваша учетка на этом inner.host-е.
outer.host — машина, имеющая внешний ip
user — ваша учетка на этом outer.host-е.

p.s. кусочек «inner.host:22» — это способ достучаться до собственного sshd непосредственно с inner.host-а. если sshd слушает на порту 1000 — «inner.host:1000».
кусочек «inner.host:22» вполне можно заменить и на «localhost:22», и на «127.0.0.1:22».

p.p.s. на машине inner.host можно поставить «сторожа», присматривающего за процессом ssh. это потребует настройки беспарольной аутентификации (описана в сети многократно, поэтому опускаю).

ya@inner.host:~$ crontab -e

и добавляем пару строк:

C='ssh -f -N -R 2345:inner.host:22 user@outer.host'
*/10 * * * * pgrep -f "$C" &>/dev/null || $C

проверка на «живость» будет происходить каждые 10 минут.