i386, amd64, crypto

Есть у меня очень удобный Eee PC 1015B. Маленький, живет 6 часов от батарейки, потерять не жалко… Ну точнее как не жалко, сама железка стоила 10 тысяч несколько лет назад или даже дешевле, а сегодня таких почему-то больше не делают, так что, если потерять, то не понятно будет чем заменить. Это с одной стороны. С другой стороны, там есть некоторое количество информации, приватность которой меня волнует. Понятно, что надо всё шифровать и т.п.

В тот момент, когда я эту железку купил, шифрование всего диска требовало каких-то телодвижений, а мне было то ли некогда, то ли лень, то ли всё сразу, поэтому я ограничился тем, что все, что очень надо, шифровал в юзерспейсе. Некоторое время назад, инсталлируя очередной ноутбук, использовал cryptsetup прямо из инсталлятора и обнаружил, что он вообще ничего не требует и нормально работает. Так что подумал о том, чтобы всё-таки зашифровать содержимое EeePC.

Решил не париться, проинсталлировать его с нуля, заодно перейти с i386 на amd64, который теперь уже совсем-совсем дозрел. Но так как в нетбуке стоит слабенький Brazos, были некоторые опасения, не станет ли он совсем тормозить из-за дополнительного шифрования. Поэтому померил его производительность старым добрым бенчмарком “Собери ядро 3.16”.

Тестируемая система:
ASUS EeePC 1015B
AMD Brazos C-50 (1ГГц, 2 ядра (на самом деле что-то вроде HyperThreading), 64bit)
RAM 4GB
SSD 256GB (какой-то A-Data)

Результаты:
i386 без шифрования

$ time make -j2 modules
real 241m20.022s
user 443m10.388s
sys 21m6.952s

i386 (chroot на amd64 хосте) с шифрованием

$ time make -j2 modules
real 244m18.927s
user 445m4.748s
sys 21m45.132s

Как видно, включение шифрования почти не дало падения производительности на задачах, где надо не очень интенсивно читать/писать много маленьких файлов.

После этого я решил заодно проверить, насколько сейчас оптимизирована компиляция под amd64 и собрал то же ядро с тем же конфигом, но на amd64 хосте. Результат получился не совсем ожиданный (для меня). Под amd64 всё собралось заметно быстрее:

amd64 с шифрованием

$ time make -j2 modules
real 222m59.369s
user 381m12.240s
sys 29m23.844s

Выигрыш – 10%.

График:
benchmark

Удаление письма из хранилища dovecot

Отправил случайно в список рассылки письмо на много десятков мегабайт и оно разлетелось по всем разработчикам, что не есть хорошо, потому что у всех почта на нашем сервере и сразу полгига места ушло.
Решил удалить его прямо у пользователей из Maildir’ов. Вначале убедился, что ищутся правильные письма:

doveadm search -A FROM git@lvk.cs.msu.su LARGER 10M HEADER X-Git-Newrev 252417435200cca7d6ac33b8be24018100513527

Вроде, всё Ok, пытаюсь удалить:

doveadm -D expunge -A FROM git@lvk.cs.msu.su LARGER 10M HEADER X-Git-Newrev 252417435200cca7d6ac33b8be24018100513527

Получаю:

To avoid accidents, search query must contain MAILBOX in all search branches

Ну, в принципе, логично и правильно, от греха… Но у меня-то случай особый! =) Понятия не имею кто по каким папкам раскладывает коммит-логи, так что надо всё-таки удалять из всех, а не только из явно перечисленных. Пришлось в изысканиях дойти до исходников, где нашел, что можно указать не конкретную папку, а globe:

doveadm -D expunge -A mailbox '*' FROM git@lvk.cs.msu.su LARGER 10M HEADER X-Git-Newrev 252417435200cca7d6ac33b8be24018100513527

Вот так сработало.

Авангард интернет-банкинг vs. Linux

Upd: Более неактуально, там теперь полностью джава.

Садись, малыш, сегодня я расскажу тебе как пользоваться интернет-банкингом Авангарда в Линуксе.

Итак ты являешься клиентом банка Авангард. У тебя должны быть:

  • логин и пароль от интернет-банкинга;
  • карточка с одноразовыми паролями;
  • флэшка с ключом ЭЦП.

С первыми двумя пунктами всё просто: логин с паролем позволяют зайти в веб-интерфейс и получить любую информацию. Если требуется выполнить типовой платеж, то раз в сеанс будет запрошен одноразовый пароль с карточки. Самое интересное происходит в ситуации, когда требуется выполнить какое-либо действие, которое по законодательству требует твоей подписи. Например, хочется открыть вклад. Или поменять какой-нибудь лимит для карточки. Или перевести миллионы в другой банк. Казалось бы надо идти в офис и там писать заявление, но не всё так страшно: в нашей самой лучшей на свете стране есть закон об Электронных Цифровых Подписях и Авангард как раз одну такую ЭЦП с православным ГОСТовским криптоключем внутри тебе сгенерировал.

Но тут-то и кроется подстава: софт, конечно же, кривой. Ну как не то чтобы совсем уж, чего обижать авторов, но не без забавностей.

Для того, чтобы проверить работу цифровой подписи можно попробовать изменить какой-нибудь лимит на закладке “Справочники/Лимиты по картам”.

Во-первых, для работы ЭЦП требуется java-plugin. Не знаю, как там с icedtea (или как там оно зовется), хотя вроде где-то писали, что и он работает, но я не стал оригинальничать и поставил java-plugin от некогда славной фирмы SUN (пакет sun-java6-plugin).

И ничего не заработало. Честно сказать, я это заметил еще месяца полтора назад, что не работают у меня java-апплеты, но списал это на то, что где-то прописалась какая альтернативная джава из gcj или еще какого проекта, и забил. А тут занялся вопросом серьезно – сносил, переставлял… Ничего не помогает. Вместо апплета выдает окошко с надписью “Error. Click for detail”, по клику на которое вызывается java-console с текстом о Class not found и прочих эксепшнах, но главное с ключевой строчкой: “Caused by: java.net.ConnectException: Network is unreachable”

Небольшое расследование вывело на следующую проблему: #560238. Если коротко, то суть ее состоит в том, что Marco d’Itri добавил в пакет netbase установку sysctl’я ломающего некоторый “кривой” софт. Не будем сейчас обсуждать Марко и его маму, равно как кривость сановской джавы и информационность RFC 3493. Просто факт остается фактом. Сейчас сановская джава не сможет подключиться к сети при установленном net.ipv6.bindv6only=1

Так что первым нашим шагом будет открытие /etc/sysctl.d/bindv6only.conf и установку там net.ipv6.bindv6only в значение 0. После чего стоит сказать “/etc/init.d/procps start” Ну это всё пока что актуально только на Debian Squeeze, остальным повезло. (Пока?)

Теперь апплет-таки запускается и, если тебе особенно повезло, радостно сообщает: “Обнаружение программы… Err” с очень содержательным пояснением: “Ошибка обнаружения/скачивания программы шифрования: invalid stream header: 0D0A0D0A”

Тут всё просто и очевидно (да, это сарказм): открываешь настройки IceWeasel/FireFox и разрешаешь там “Third-party cookies”. Они там в разных версиях в по разному называются/находятся, так что проще всего открыть “about:config” и там поставить значение переменной network.cookie.cookieBehavior в 0. Кстати эта проблема, наверняка должна проявляться и под виндой.

Едем дальше: аппет сообщает “Ошибка выполнения программы подписи  : Cannot run program “c:\avn_ib/avn_cc.exe”: java.io.IOException: error=13, Permission denied”. Если посмотреть в домашний каталог пользователя (а именно он является текущим для java-приложений, запускаемых из браузера), то мы радостно обнаружим там каталог “c:\avn_ib” внутри которого действительно есть неисполняемый файл avn_cc.exe

Как ты уже догадался, гений русских программистов бесконечен. Java-апплет всего-лишь является троян-дропперомзагрузчиком для настоящей боевой криптографии. Которая написана, естественно под винду. Ну тут всё просто. Он хочет запускать этот бинарник? Нет проблем! Чтобы работали виндовые программы, ставим wine. Чтобы бинарник можно было запускать напрямую, ставим binfmt-support. (Вообще он рекомендуется вайном, но мало ли, у тебя он не стоит. Ну и в других дистрибутивах пакет может называться иначе, ты уж сам разберись, главное чтобы работал прямой запуск виндовых прог: не только “wine prog.exe”, но и просто “./prog.exe”) Дальше, понятно, надо сделать бинарник avn_cc.exe исполняемым.

Нет, это еще не всё. Теперь апплет выдает нам не менее экзистенциальное “Ошибка выполнения программы подписи: ret 2 команда <c:\avn_ib/avn_cc.exe c:\avn_ib/avn_clb_sign.in>” Надо немного подумать: чтобы бинарник можно было запустить из вайна, он должен быть доступен внутри виндового окружения. А какой путь сейчас у этого бинарника? Правильно Z:\home\user\c:\avn_ib\avn_cc.exe В общем не бывает таких путей в виндовсе. Решаем всё просто:

mv ~/c:\\avn_ib ~/.wine/drive_c/avn_ib&&ln -s ~/.wine/drive_c/avn_ib ~/c:\\avn_ib

Пробуем еще раз… О чудо! Крипто-хрень спрашивает нас где лежит приватный ключик. Ну теперь достаточно воткнуть флэшку с ключом, примонтировать и оно всё само подпишет.

Велик русский Левша. Умеет подковать англицкую джаву.

PS А Авангард и его интернет-банкинг действительно хорош. Ну и MasterCard.Metro у него по самым адекватным тарифам. В общем рекомендую. Кстати, обещают подружиться до конца года(?) с московским наземным транспортом и питерской подземкой.

Spin Debian package

SPIN is a general tool for verifying the correctness of distributed software models in a rigorous and mostly automated fashion. It was written by Gerard J. Holzmann and others in the original Unix group of the Computing Sciences Research Center at Bell Labs, beginning in 1980. The software has been available freely since 1991, and continues to evolve to keep pace with new developments in the field.

http://spinroot.com

Unfortunately Bell Labs use strange non-free copyleft-like license instead of good old GPL. So it could not be included in Debian archive. But as I need Debian package for it, I’ve prepared one and put into my repository.

NeTAMS in Debian

Уж не знаю, имеет ли сегодня это какой смысл, но NeTAMS таки попал в архив Debian. А, с другой стороны, свободных аналогов-то и не видно что-то.

ЗЫ В моем репозитории в секции main лежат бэкпорты под все актуальные дистрибутивы Debian/Ubuntu.

Весёлые картинки

Вчера делал аж два рассказа про Debian. Один про то, как это всё вообще устроено, другой про то как выглядит работа мейнтейнера.
Картинки раз и два.

Upd: Лицензия на второй файл cc-3.0-by-sa, на первый, скорее всего тоже, но надо еще уточнить, потому что я использовал за основу творчество Сэма Хосевара, напишу ему и спрошу.

NeTAMS Debian package попытка вторая

Всё-таки допилил пакет NeTAMS до вменяемого состояния.
NeTAMS из CVS. (По политическим причинам.)

Брать в моем репозитории или напрямую из пула.

Пакеты собраны для Debian Lenny и Ubuntu Intrepid.

Обновление со старых версий пакета не поддерживается (в дальнейшем будет).

OpenVZ в Debian

Два дня назад в Debian Unstable появилось ядро 2.6.26. Особо стоит отметить, что для архитектур i386, ia64 и amd64 существует вариант с OpenVZ. А vserver наоборот выкинули к чертям.

Кстати, все идет к тому что Lenny выйдет без системы виртуализации Xen: в dom0 стабильно может работать только старое ядро 2.6.18, самим Xen’ом уже фактически никто не занимается и даже RedHat, похоже, делает ставку на kvm.

XNeur 0.9.1 вышел

И был упакован. Как всегда в моем репозитории.

Пакеты для Ubuntu Egdy больше не обновляются благодаря кривости этого “замечательного дистрибутива”:

Err http://archive.ubuntu.com edgy/main libxpm-dev 1:3.5.5-1
404 Not Found

ЗЫ kXNeur новый пока не вышел, старый работать не будет. Используйте gXNeur или ждите несколько дней.

Upd: kXNeur вроде допилили, выкладываю тут, так как на dists.xneur.ru у меня доступа нету.

Firefox 3 for Debian Etch

Собрал-таки бэкпорт 3го Лиса для Debian Etch.
На самом деле не Лиса, а Песца (IceWeasel) и не 3го, а 3.0.0rc2 – то что сейчас в testing.
Дополнительно потребовалось сбэкпортить xulrunner, gtk2+, cairo, pango и еще кучу всего. Попробовал поставить на виртуальную машину – gtk2 конфликтует с довольно большим количеством старого софта. Metacity и несколько библиотек я бэкпортнул, openoffice.org рабочий ставится с backports.org. По поводу остального – если что, пишите.

Скачать можно из моего репозитория из секции backports. (Руками тоже можно, но там еще придется кучу зависимостей качать.)

xNeur 0.9.0

Вроде он вышел, но в нем несколько существенных багов. Так что пока пакетов для Debian’а и Ubuntu нет.
Вариантов тут два: если 0.9.1 выйдет достаточно оперативно (а это вроде обещается), то запакую его, а если затянется, то все-таки 0.9.0, но с исправлениями.
В любом случае совсем скоро не ждите.

64 бита и бубны

Собрал-таки 64хбитные ядра с поддержкой OpenVZ. При чем как для архитектуры amd64, так и для i386. С i386 вообще обнаружилось весьма много забавностей. Во-первых, если ядро у тебя 64х-разрядное, а userspace 32х, то OpenVZ не будет стартовать. Потому что егойные 32х-разрядные утилиты не могут корректно работать с 64х-разрядным ядром. Пришлось немного извратиться: поставить пакеты vzctl и vzquota от архитектуры amd64 (при помощи dpkg -i –force-architecture) и, для поддержки 64х-битных бинарников, пакет amd64-libs.

Отдельная песня с драйверами nVidia. В принципе ядерный модуль собирается как для 32ти, так и для 64х разряной системе. Но только если userspace такой же как и ядро. Иначе происходит ошибка на этапе компиляции. Пришлось в чруте с 64х-битной системой собитать module-assistant’ом пакет для amd64, который затем поставил в основную 32х-разрядную систему. Работает.

Ядерные новости

Во-первых, одной строкой:
в официальном репозитории debian proposed-updates для дистрибутива stable появилось ядро 2.6.24. В рамках программый Etch’n’Half. Пакеты называются linux-image-2.6.24-etchnhalf.1-<flavour>.

Ну а теперь о более другом.
Как известно, для виртуализации платформы на уровне ОС ((c) Никита Ющенко) в Линуксе используют одну из двух подсистем vserver или OpenVZ. Первая весьма кривая и убогая (по крайней мере по сравнению со второй), но у нее есть одно неоспоримое преимущество – оно есть в Debian “искаробки”. Но и тут все не слава Богу. Дело в том, что разработчик vserver до сих пор не портировал его на ядро 2.6.24. Как результат свежие ядра в Debian Lenny собираются с выключенным featureset “vserver” и “xen-vserver”. Не знаю как там оно будет дальше, но пока это сильно не комильфо. Потому что ядро из stable я на десктопе не хочу, а с другой стороны мне очень не хочется убивать свою настройку системы с виртуальными машинами, которая у меня тут сложилась, а обновиться до 24го ядра надо.

По счастью есть OpenVZ, портированный на 2.6.24, так что дело за малым – взять стандартное дебиановское ядро, добавить туда OpenVZ патч и собрать ядро. Но это все как-то не debian-way, есть же репозитории с ядрами openvz… Оказалось что нет. Ну точнее есть, но для Etch, а для Lenny-то как раз и нету. Ну раз так – надо не только для себя сделать, но и другим помочь, подумал я и решил собрать такое ядро по всем правилам.

Оказалось весьма забавно и довольно просто (хотя довольно много времени потребовалось на то, чтобы разобраться с системой шаблонов, используемой в сурцовом пакете linux-source-2.6).

В общем в итоге, не без небольших локальных проблем, я переполз на openvz, чего желаю всем, кто использует vserver.

Пакеты для Debian Lenny можно взять в моем репозитории, секция openvz. Архитектура пока только i386. Собирать amd64 под qemu у меня чёй-то желания особого не возникает. Да и соответствующие шаблоны еще надо добавить в пакет исходников для этого.

Сбыча мечт

История изменений для конфигов в /etc? С возможностью откатов? И минимумом лишних телодвижений?

Встречайте etckeeper!

Короткая инструкция:

# etckeeper init

инициализирует репозиторий git. После этого

# cd /etc; git commit -m "Initial commit"

для первого чек-ина. И всё. Можно использовать. Можно пользоваться всеми прелестями git’а для клонирования настроек, merge коммитов между репозиториями и прочего. Пакет использует хуки APT для автоматического коммита после установки/обновления/удаления пакетов, а так же metastore для хранения владельца/прав доступа для файлов.

ЗЫ Пока только в sid. Сейчас сделаю бэкпорт для Etch. Уж больно вкусно.
ЗЗЫ Бэкпорт сделал, лежит в репозитории. Кто будет ставить: потребуется еще бэкпортнутый metastore и git-core, из того же репозитория.