unixforum.org-4

жизнь продолжается в штатном режиме:

>[09:06:38 PM] Виталий Липатов etersoft: Всё, на сегодня переезды закончили

google translate

посмотрите на тринадцатый вариант перевода слова «совет»:

13. counsel

вы всё ещё кипятите верите в непогрешимость гугле-переводчика? тогда мы идём к вам! (улыбка)

upd. упс. я неверно забивал слово в онлайн-словарях. через «c».
p.s. но google translate всё равно погрешим! (улыбка)

unixforum.org-3

из общения с Виталем Липатовым, руководителем компании etersoft.ru, всплыл такой забавный момент:
возможно, проблемы у провайдера, услугами которого пользуется etersoft.ru (на сервере которой, в свою очередь, хостится unixforum.org), связаны с потеплением в спб.

у провайдера самым тривиальным образом могло что-то затопить.

p.s. возникает справедливый вопрос: а не вызвано ли появление этой темы на форуме с тем же самым потеплением? как топик-стартер сам себе отвечаю: может быть, может быть… (улыбка)


upd.20100228.12:46. последние вести от Виталия Липатова:

Ночью вырубило электричество, с раннего утра боролись за живучесть.

unixforum.org-2

опять та же ситуация. форум недоступен. это проблемы у провайдера, услугами которого пользуется etersoft.ru.

unixforum.org

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

разбираюсь.

ждите новостей.

место встречи — здесь.

upd. уже заработало. барабашка? узнаю новости — напишу.

upd. судя по времени постов, форум был не доступен около часа.

upd.20100228 1:27 msk. опять та же ситуация. это проблемы у провайдера, услугами которого пользуется etersoft.ru

евп-2

— извини, я тут разговаривала с клиентом и листочек у тебе на столе попачкала. у меня было недержание чернил.

как вы яхту назовёте…

unixforum.org — это ufo (в сокращении).

unixforum.org — это «у них — форум-оригинал» (в вольном произношении).

слава интернетам

вот сижу, краем сознания слушаю курсы rhct в unixedu.ru (бумажка нужна) и одновременно успеваю ковырять форум, обновляю информацию на страницах-пустышках, куда можно попасть пока dns-ы не обновились.

интернеты рулят, однозначно.

p.s. компьютеры здесь слабые. веб-морда gmail.com ползает медленне самой дряхлой черепахи.

linuxforum.ru -> linuxforum.etersoft.ru

да-да, приходится менять имя.

подробности позже.

upd. ага, этерсофтовский nginx не согласен с таким именем. ждём, пока там не поправят.

upd. временное решение: добавить в /etc/hosts строчку

89.104.102.12 linuxforum.ru

upd. в принципе, чехарда проистекает из того, что доменное имя linuxforum.ru принадлежит человеку, ныне не имеющего к форуму никакого отношения.

upd. mezon отменяется. будет временное имя linuxforum.etersoft.ru
если браузер пишет address not found, добавьте в /etc/hosts

89.104.102.12 linuxforum.etersoft.ru

upd. голосуем за новое имя для форума

upd. голосование прошло. имя выбрано: unixforum.org. настраиваю движок на новый форум. и провожу database maintenance. к утру, надеюсь, закончу. уже и обновления dns докатятся.
если видите страничку с «поломанным» дизайном, или ждите обновления dns, или добавьте в /etc/hosts строчку:

89.104.102.12 unixforum.org

upd. в данный момент идёт rebuild постов.
судя по цифрам, процедура закончится не раньше 20100224 12:00 msk

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

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

в случае каких-либо проблем с доступом к форуму в первую очередь смотрите в этот блог.
пока являюсь одним из администраторов unixforum.org, обязательно буду использвать блог как средство донесения актуальной информации о чём-либо подобном. централизованность такого процесса показала свою эффективность (по крайней мере в этот раз).
ещё раз спасибо всем тем, кто разнёс по интернетам вести в тот памятный субботний день.

цепочка доверия:
http://habrahabr.ru/blogs/linux/85008/
http://forum.linux.lg.ua/index.php?showtopic=1575
http://www.in4.org.ua/2010/02/linuxforumru.html
http://lna.org.ru/forum/index.php/topic,1854
http://juick.com/Fen1x/555421
http://juick.com/diesel/555598
http://muhas.ru/?p=124
http://pskovlug.ru/pg/blog/muhas/read/404/--
http://yarlug.org/blog/news/601.html
http://linuxforum.kz/topic/3309-linuxforum-ru/
http://yvision.kz/community/Linux/31829.html
http://twitter.com/isoMax/status/9382640941
http://www.vega-int.ru:8080/phorum/index.php?showtopic=1465&st=20&gopid=1413438&#entry1413438
http://viktor-w.ru/2010/02/20/linuxforum/
http://game.global.by/forums/showthread.php?t=8580
http://cetki.com/forum/index.php?showtopic=29600
http://www.linux.org.ru/news/russia/4573614
на этом цепочку доверия завершаю. спасибо всем, кто поддержал.

нищета копирастам, пожалуй, не грозит

перепост с ufo.

когда триста лет назад в туманном альбионе благородные сэры выдумали копирайт, это было достаточно гуманное нововведение. ущемлялись права ничтожного меньшинства (книгоиздателей) в пользу чуть большего количества индивидов (авторов), отчего выигрывало подавляющее большинство (всё общество).
к концу двадцатого века соотношение сил изменилось.
ущемлённое меньшинство плавно распухало: всё большее количество людей получало возможность быть «издателями» — создавать копии произведений. пишмашинки, множители, ксероксы, пишущие cd-приводы, флэшки и беспардонно дешевеющие винчестеры, интернет в конце концов, со своими чуть ли не бесплатными предложениями хостинга, файлообменниками, торрент-трэкерами, осликами, казаами и прочими напстерами.
себестоимость и трудоёмкость создания электронной копии произведения упала до нуля.
ещё немного и «издателями» смогут стать _все_.
все 100% населения земли скоро будут ущемлены в правах в пользу ничтожного количества корпораций-«защитников прав авторов».
до зубов вооружённые всё ужесточающимися законами (ими же и пролоббированными), прекрасно финансируемые (_само_финансируемые), с надёжно прикрытыми тылами (всё удлиняющиеся, опять же с их подачи, сроки охраны авторских прав), эти корпорации вполне готовы к сражению со всем человечеством.
вам ещё не стало страшно?

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

ssh-agent

перепост с ufo.

из man ssh-agent:

The idea is that ssh-agent is started in the beginning of
an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program.

скорее всего у вас он уже запущен. см. вывод ps ax | grep ssh-agent. у меня, например:

$ ps ax | grep ssh-agent
 4943 ?        Ss     0:00 /usr/bin/ssh-agent
   /usr/bin/dbus-launch --exit-with-session x-session-manager

т.е. запущен агент поверх dbus-launch, который, в свою очередь, запускает используемый мною x-session-manager (у меня это icewm-session).
поверх всего агент запускается для того, чтобы передать всем потомкам переменную окружения с адресом сокета, через который агент и коммуницирует со всякими ssh*-программами:

$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-XuDwYF4914/agent.4914

ключи _текущему_ экземпляру агента можно добавить командой

$ ssh-add [<файл с ключом, например, ~/.ssh/id_rsa>]

если ключ защищён пассфразой, ssh-add её запросит.
чтобы агент забыл обо всех ключах, нужно сказать:

$ ssh-add -D

о конкретном ключе:

$ ssh-add -d <файл с ключём>

по поводу security:
1. как написано в man ssh-agent, ключи напрямую ssh-клиентам агент не передаёт. т.е., как я понимаю, «разговаривает» с sshd сам агент.
2. идея агента состоит в том, чтобы rsa/dsa-ключи были защищены пассфразой (кстати, добавить/изменить пассфразу к существующему ключу можно командой ssh-keygen -p [-f <файл с ключом>]) и вам не нужно было вводить пассфразу при каждом вызове ssh. а если даже злоумышленник завладеет файлом с ключом, пассфразу ему придётся подбирать долгими зимними вечерами.
3. да, root может добраться до сокета (файл читабелен только для вас, но для root-а это не проблема) и «прикинуться своим»:

# export SSH_AUTH_SOCK=/tmp/ssh-XuDwYF4914/agent.4914
# ssh al@linuxforum.ru
???
profit

на то он и root.
4. у ssh-agent (и у ssh-add) есть ключик -t <секунды или time-format, описанный в sshd_config(5)>. задаёт он максимальное «время жизни» ключа, добавленного агенту.

отсюда вывод — варианты использования ключей по мере возрастания секурности:
1. ключ без пассфразы
2. ключ с пассфразой, добавленный в ssh-agent
3. ключ с пассфразой
выбирать нужный баланс между степенями удобства и безопасности придётся вам самим.

bdist_rpm build error

тащусь я с этого вашего питона…
и с людей, которые на нём проекты делают…

вот пытаюсь для translate.edumandriva.ru взгромоздить на хостовую машину pootle.
просто install, естественно, не подходит. помойка — не наш метод.
вроде бы можно создать rpm:

$ ./setup.py bdist_rpm

но сборка обламывается:

...
running install_data
creating /var/tmp/Pootle-2.0.2-1-buildroot/etc
creating /var/tmp/Pootle-2.0.2-1-buildroot/etc/pootle
error: can't copy 'localsettings.py': doesn't exist or not a regular file
error: Bad exit status from /var/tmp/rpm-tmp.80659 (%install)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.80659 (%install)
error: command 'rpmbuild' failed with exit status 1

видите ли, пейсатели забыли нарисовать файлик MANIFEST.in:

$ cat MANIFEST.in 
include localsettings.py wsgi.py ChangeLog COPYING INSTALL

неужели это так сложно сделать? не меньше часа мне, с питоном и его гитиками мало знакомому, пришлось убить на разбирательства…

p.s. баг-репорт я, конечно, накатал. но осадок всё-таки остался…

немного чтива

GNU/Linux Advanced Administration PDF Book
nixCraft FAQ PDF Collection

ну и вообще, возможно, будет интересно почитать этот ресурс: http://www.cyberciti.biz/.

ipv6 in gnu/linux

попался под руку интересный набор видеороликов про ipv6 в gnu/linux:
http://ipv6.he.net/presentations.php
и про настройку, и про использование, и про dns, и даже про автономные системы немножко.

p.s. слева присобачил баннер от того же he.net, условно показывающий, сколько осталось до ipv4-капца (улыбка).

нравится мне английский язык

mutt and gpg. history of little investigation.

mutt и gpg. история маленького расследования.

как-то за время пользования mutt-ом стало уже привычным видеть:
gpg: Can't check signature: public key not found

но наконец-то оно меня достало.
да, /usr/share/doc/mutt/examples/gpg.rc у меня скопирован в ~/.mutt/, да, в ~/.muttrc добавлена строчка
source ~/.mutt/gpg.rc.
но вот ключи оно самостоятельно получать и проверять не хотит.

начинаю разбираться. вижу в том самом gpg.rc такие строчки:
# This will work when #172960 will be fixed upstream
# set pgp_getkeys_command="gpg --recv-keys %r"
читаю про этот «баг» в дебиановской багзилле и в mutt-овском trac-е. написано, что вместо keyid-ов на место «%r» mutt подставляет email-ы. и gpg обламывается.
даже исходники скачал. даже установил pkspxyc и потестировал.
оказывается, ребяты, такая вот фигня:
pgp умеет получать ключи по email-адресу, но не умеет по keyid-у.
а gpg умеет получать ключи по id-у, но не умеет по email-адресу.
хуже того. mutt вообще с id-ами не работает (насколько я вижу по исходникам) и строчку с id-ом (в виде gpg: Signature made Fri 08 Aug 2008 06:38:37 PM MSD using DSA key ID 545A2506) выдаёт сам gpg на основании сигнатуры. а mutt-у id — до лампочки.
поэтому косметической правкой исходников тут, увы не обойтись (а я так на это надеялся!).

тупик? тупик.
чешу опилки. начёсывается цепочка умозаключений:
gpg ведь вызывается для проверки? вызывается (командой, записанной в pgp_verify_command).
id он при этом из сигнатуры выковыривает? выковыривает.
т.е., id получить можно. а значит, можно и ключ скачать с keyserver-а.
ну, думаю, дело в шляпе. засучиваю рукава и прикидываю, как я эту команду (записанную в pgp_verify_command) заменю на скрипт, который будет этим всем делом заниматься. по ходу дела просматриваю упоминания про keyserver в man gpg.
и.
натыкаюсь на параметр --keyserver-options. у которого есть, в том числе, опция auto-key-retrieve:
This option enables the automatic retrieving of keys from a keyserver when verifying signatures made by keys that are not on the local keyring.
вау! это же прямо то, что мне нужно!
привожу строчку в gpg.rc к виду:
set pgp_verify_command="gpg --keyserver-options auto-key-retrieve --status-fd=2 --no-verbose --quiet --batch --output - --verify %s %f"
проверяю… работает, собака! исправно получает ключики, добавляет в keyring и верифицирует подписанные email-ы.

p.s. понятно, что вооружившись всей этой информацией, я без труда обнаружил вагон подсказок (ведь этому «багу» уже добрых восемь лет!). в том числе и предложение раскомментировать в ~/.gnupg/gpg.conf строчку
keyserver-options auto-key-retrieve
но это уже не интересно. это как после драки кулаками махать: нет того веселья.
проводить самостоятельное расследование гораздо прикольнее, согласитесь!