Saturday, January 31, 2009

Доктор Джекилл и мистер Хайд

Я разгадал тебя: ты самозванец.
Тайком пробрался ты на этот остров,
Чтоб у меня отнять мои владенья.
-- Уильям Шекспир, Буря.

На днях ваш покорный слуга нашел в себе силы поправить для FreeBSD порт одной крохотной утилиты. Заставить себя пришлось, поскольку реацией на попытку использование той версии утилиты, что спрятана в густом сумраке дерева портов, как ягода черники в лесу, было неприличное ее гэпание, если ту пытались пустить на, к примеру, amd64.

Ошибка та была давным давно (чуть ли не год назад) исправлена и новая версия почти что bug free утилиты живет с осени прошлого года на Sourceforge. В портах, разумеется, оставалась ссылка на a) старую версию b) безвинно убиенный (по моей просьбе) аккаунт на unixdev.net.

То есть, скачать старую версию как бы вообще нельзя. Тяжка доля maintainer'а своих же глюкал, но доля ленивого maintainer'а, уклоняющегося от общественно-полезного труда, тяжка вдвойне.

Кряхтя сполняю send-pr; чуть погодя читаю из GNATS:

Class Changed
From-To:    maintainer-update->change-request
By:         edwin
When:       Wed Jan 28 22:30:16 UTC 2009
Why:        Fix category (submitter is not maintainer)

Что тут сказать? В патче было изменено, кроме всего прочего, 2 вещи: e-mail и спеллинг фамилии (на более классический). Реакция коммитера получилась такая, словно submitter (сиречь моя скромная персона) -- это коварный злодей, злым умыслом исподтишка попытавшийся, будто начинающий карманник в метро, стащить иго maintainer'ства.

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

State Changed
From-To:    feedback->open
By:         beech
When:       Fri Jan 30 05:46:36 UTC 2009
Why:        Submitter is maintainer

State Changed
From-To:    open->closed
By:         beech
When:       Fri Jan 30 06:05:49 UTC 2009
Why:        Committed, Thanks! 

Страшенна нудьга оце с вами, вельмишановнi панi та панове.

Wednesday, January 21, 2009

How to view logs

Один знакомый меня спросил, показывая пальцем в xterm, где был procmail log: "что это за утилита для просмотра логов?". Почему утилита? xterm выглядел вот так:

Многие испытывают мучения либо набирая каждый раз ``tail -f something'' либо открывая кучу терминалов для глядения на log files. Другие пользуют screen и делают с ним разные полезные штуки. Вы тоже можете сварганить себе log viewer за 5 минут.

Что нам понадобится.

  1. Работающий screen.
  2. Отдельный конфигурационный файл для запуска screen в качестве log viewer. Отдельный -- это затем, чтобы не трогать вашу обычную настройку screen'а.
  3. xterm и утилита tail.

% cat ~/.screenrc.logviewer
startup_message off
hardstatus alwayslastline "%-w%{= bw}%50>%n %t%{-}%+w%<"

screen 0 tail -f -F /var/log/messages
title Messages

screen 1 tail -f -F /home/alex/.procmail/log
title procmail

screen 2 tail -f -F /var/log/maillog
title sendmail

#screen 3 tail -f -F /var/log/samba/log.smbd
#title smbd

screen 3 tail -f -F /var/log/news/news.notice
title news.notice

#screen 4 tail -f -F /var/log/auth.log
#title auth

screen 5 tail -f -F /tmp/twit-list.log
title twit-list

select 1

Самое painful тут было родить описание the hardstatus line на птичьем языке, остальное self-explanatory. Теперь пускайте ваш log viewer:

% xterm -title "Log files" -e screen -c ~/.screenrc.logviewer &

Переход между окнами: Ctrl-a n, где n -- номер окна, выход: Ctrl-a \.

8 myths about pr2nntp

Тут в узких кругах пользователей pr2nntp замеченно появления в головах тумана в виде "скопища рiзних думок". Чтобы сдуть его и снять пелену с глаз, пришлось развенчать несколько мифов.

Миф #1: pr2nntp очень сложно настраивать

Не сложнее чем приготовить себе легкий завтрак. То есть, так чтобы проснулся и сразу все было готово -- это нужно чтобы у вас был персональный Дживс. Для тех кто не является Берти Вустером, придется самому отредактировать текстовый (о ужас!) файл конфигурации.

Миф #2: pr2nntp требует INN, а я помню как в университете писал курсовую работу о настройке INN и почти что свихнулся.

Во-первых, не обязательно INN -- сгодится совершенно любой NNTP-сервер, который вы можете дергать за веревочки для создания своих newsgroups.

Во-вторых, последние версии INN для работы с pr2nntp требует 0 (нуль, здесь нет ошибки) каких-либо правок в конфигурации. То есть вы ставите порт news/inn и забываете о его существовании. И не пытайтесь подозревать самих себя, что в таком случаи вы оставляете INN незащищенным для атак извне -- по умолчанию вам будет дано право подключаться к нему только с локальной машины (так что см. файл /usr/local/etc/news/readers.conf, если требуется все совсем иначе).

Миф #3: pr2nntp конвертирует все feeds в plain text, а в моих feeds есть картинки.

Видите ли вы изображения или нет, зависит исключительно от вашего news reader. pr2nntp умеет составлять письма с raw версией feed (со всем HTML'ом (выделениями, ссылками на что угодно и проч.)). См. screenshot Microsoft Mail.

Миф #4: pr2nntp написан на каком-то древнем, как египетские пирамиды, скриптовом языке. Мне в школе сказали, что Tcl это не cool, он давно умер, а последним кого видели пишущим на Tcl -- это был какой-то сумасшедший студент, потерявшийся в колонии королевских пингвинов в Антарктиде в начале 90-х, откуда потом, взобравшись на снежный холм, он передавал по радио тусклые, как утро на краю земли, стихи о тщете всего сущего.

Так, все вопросы по языку в comp.lang.tcl. По поводу древности идите на www.tcl.tk.

Миф #5: tDOM и pr2nntp требуют разных версий Tcl (8.4 и 8.5) соответственно.

Wrong.

% pkg_info | egrep 'tcl|tDOM'
tDOM-0.8.2          High performance XML data processing with Tcl
tcl-8.5.6           Tool Command Language
tcl-threads-8.5.6   Tool Command Language

% pkg_info -r tDOM\*
Information for tDOM-0.8.2:

Depends on:
Dependency: tcl-8.5.6
Dependency: tcl-threads-8.5.6

Миф #6: elinks вставляет дурацкое поле по левому краю письма, которое не убирается и всех раздражает. Меня особенно!!!! :(((((((

Запустите elinks, нажмите 'o', зайдите в Document->Browsing->Horizontal text margin и поставьте в поле value число 0. Не забудьте сохранить правки.

Миф #7: Мой wget качает и качает все feeds каждый раз заново, а вот FirstRateFooBarRSSreader (buy 2 get 1 for free) -- нет.

Прочтите в документации раздел 2.2 File downloader. Если лень самому возится с puf, скачайте готовый порт. (Update 2009-01-30: или пользуйте стандартный fetch(1) из FreeLSD 7.1, где он, наконец, начал по божески работать в конструкции fetch -mad -o %f %u).

Миф #8: Вот у меня есть несколько feeds, которые редко обновляются и гадкий pr2nntp каждый раз их скармливает целиком INN, а мои пометки на письмах "как прочитанные" испаряются. Так нельзя, я щетаю.

Дело отнюдь не в pr2nntp. Просто у вас за период между обновлением таких feeds проходит столько времени, что INN успевает удалять старые письма в newsgroup, а вы (посредством pr2nntp) отдаете их INN вместе с новыми.

Tuesday, January 20, 2009

screen and libutempter

Совсем внезапно обнаружилось неприятное поведение screen 4.0.3: если xterm у нас собран с поддержкой libutempter, то собрать порт screen на этой же машине не получится (оно валится на этапе configure с совершенно идиотским ``error: Can't run the compiler - internal error. Sorry.''; скучные подробности опускаю -- они ясно видны в config.log). Решением есть 2 варианта:

  1. Временно сделать pkg_delete libutempter\*, собрать порт screen, поставить libutempter обратно.
  2. Отрубить libutempter от xterm (заодно вместе с luit, если хотите иметь человеческую поддержку локали koi8) и снести libutempter.

Второй способ мне нравится больше.

Monday, January 12, 2009

FreeBSD 7.1 and VMware Workstation

(2009/05/07 Update: 3-й эпизод см. тут.)

Полного погружения с open-vm-tools не получилось. Хотя, с другой стороны, максимальный минимализм все-таки преодолен. То есть, если раньше из комплекса tools идущих с VMware Workstation использовалась ровно 1: vmware-guestd (попробуйте догадаться для каких сложных вещей!), то с любознательным щупаньем одновременно свежей FreeLSD 7.1 и не очень свежих open-vm-tools (в портах есть только летняя версия) добавилась insane возможность: содержимое X Primary стало отображаться в Windows clipboard (и наоборот).

(голосом офисного морона): Новые технологии в действии!

Стартовые условия остались прежними. Разница в версии FreeBSD и использовании open-vm-tools вместо идущих проприетарных tools с VMware Workstation.

Порт open-vm-tools ставит, среди прочей чепухи, 1 демон, 4 ядерных модуля и 1 Очень Полезную Программу (о ней в самом конце заметки). 1 из модулей бессмыслен по условиям задачи -- vmxnet.ko; vmmemctl.ko выполняет роль мебели или даже настенной лепки; vmblock.ko и vmhgfs.ko -- это те 2 штуки, которые якобы дают использовать Drag and Drop и shared folders соответственно.

Кто дал тебе имя
Малышка из квартала Симмати?
Зачем так искусно
Губами ласкаешь коралл?
О бездна блаженства!
-- Рубоко Шо, Время Цикад

Автор порта почему-то прописал в /usr/local/etc/rc.d/vmware-guestd вот такое:

[ -z "$vmware_guestd_enable" ] && vmware_guestd_enable="YES"

Это значит, что вам не нужно ничего добавлять в /etc/rc.conf чтобы vmware-guestd стал во тьме ram бегать за цикадами. Зато нужно (это было правдой и раньше, но ваш покорный слуга об этом самым подлым образом хранил молчание) добавить в .vmx файл виртуальной машины строчку:

tools.syncTime = "TRUE"

Иначе время никто не будет синхронизировать (точные сведения из tarball'а см. в guestd/toolsDaemon.c и lib/include/vm_app.h). Это также означает что для минималистической задачи (иметь условно точные 1 раз в минуту часы и ничего более от open-vm-tools), можно собирать порт open-vm-tools-nox11, чтобы не мышеелозить по вкладкам vmware-toolbox.

Btw, vmware-guestd разжирел на свободных харчах и начал предъявлять нахальные требования к ресурсам:

% top | grep guestd
  649 root          1  96    0 18116K   640K select   0:20  0.00%  vmware-guestd

в тоже время когда закрытый предшественник:

% top | grep guestd
  665 root          1  96    0  1620K   308K select   3:49  0.00%  vmware-guestd

[...] африканские слоны и вообще не могут сравнится
с индийскими даже и при равной численности -- последние
далеко превосходят их и размерами, и боевым духом.
-- Тит Ливий, История Рима от основания города, XXXVII, 39, 13

Экзотика, которой являются кернельные модули vmblock.ko и vmhgfs.ko напоминают мне боевых слонов. При первом взгляде они поражают воображение свои видом, а их наездники смотрят на окружающих с тем особенным интересом, который присущ человеку рассматривающему на корточках муравейник в лесу.

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

Как и для всякой экзотики, интерес к vmblock.ko и vmhgfs.ko угасает, когда пытаешься заставить их делать что-то более полезное, чем таємниче виблискування из output команды kldstat.

Drag and Drop между host & guest реализован так: vmblock.ko -- это драйвер "блокирующей" файловой системы. Предполагается, что искомый файл, перед тем как переедет на новое место жительства, сначала попадет в temporally directory (обычно /tmp/VMwareDnD), откуда принимающая программа не получит его (он будет для нее "блокирован") до тех пор, пока тот не перепишется в нее полностью. Принимающая сторона ничего не знает об temporally directory -- она читает смонтированный каталог с симлинками (во FreeBSD это как бы /var/run/vmblock), думая, что они (симлинки) и есть нужный ей файлы, о которых она пролила столько слез.

Хороший пример, как пользовать vmblock filesystem, можно прочесть в патче Chris'a Malley к ядру Linux 2.6.27.

У vmblock есть свои проблемы идеологического свойства (например, такой факт, что реализация этой файловой системы сделана как модуль ядра, а не современным методом Filesystem in Userspace (FUSE)), но в любом случаи, вся эта красота разбивается при попытке монтирования ее в FreeLSD 7.1.

Для еще пущего нагнетания сообщим, что смонтировать ее командой mount вообще не получится, ибо просто нечем монтировать, как вежливо сообщил по этому поводу Ryan Beasley: Unfortunately a standalone mounter for vmblock on FreeBSD was never written. Mounting was embedded in the vmware-user setuid wrapper. А этот самый vmware-user setuid wrapper вообще исключен из состава порта.

Я, как и советовали, полез в vmware-user-suid-wrapper/wrapper-freebsd.c, поправил путь к vmblock.ko в LoadVMBlock(), пересобрал, запустил vmware-user-suid-wrapper в предвкушении и радости появления смонтированного каталога /var/run/vmblock, с чувством схожим на проявления счастья у моей кошки, когда я ей варю рыбу. К несчастью, ожидания накрылись медным тазом, который больше известен под названием паника ядра:

Красиво, правда? Ровно такая же реакция наблюдается при запуске mount_vmhgfs для монтирования shared foldes. Какую из этого можно извлечь мораль? Только ту, что для порта open-vm-tools у вас в /etc/rc.conf должна быть 1 (одна) строчка:

vmware_guest_vmmemctl_enable=YES

Остальное будет ждать лучших времен. Может причина поведения vmblock.ko и vmhgfs.ko есть та, что у меня не самая последняя версия WMware Workstation, а может потому, что не были проведены священные ауспиции и в Workstation многое запуталось и пришло в беспорядок, или потому, что погода нынче такая, когда после утренней пробежки тащишься в парадном синий как лазурит, а под душем чувствуешь себя будто только что поплававший в обществе косатки ниже 60 параллели и вытащенный из воды проплывавшим мимо кораблем со шведскими туристами.

The last tip for today: запустите vmware-user из под иксов, to enable copy and paste to and from your virtual machine, не забыв предварительно поставить галочку в Settings->Options->Guest Isolation вашей виртуальной машины. vmware-user хоть и грязно выругается на невозможность to initialize blocking driver, но для copy and paste дармоедствующий модуль vmblock.ko не требуется.