среда, 8 октября 2008 г.

Управление сертификатами?

У нас в фирме практикуется подписывание и шифрование сообщений. Оно конечно не является строго обязательным, но некоторая информация присылаются в шифрованном виде. В любом случае это очень полезная возможность и неплохо было бы ее иметь.

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

Не знаю почему, но видимо в linux бытует такое мнение, что PGP работает на ключах. Хотя я считаю что инфраструктура шифрования базируется на сертификатах. Это конечно мелочи, но управление сертификатами в линуксе реализовано из рук вон плохо.

Для начала импорт сертификата. Сертификат с закрытым ключем хранится в контейнере pkcs12, gpgsm (утилита для манипулирования сертификатами) в этом формате воспринимает только ключи. Начинаем колдовать.

Сперва обеспечим автоматический запуск gpg-agent. Честно говоря, не знаю как правильно сделать это в kde. Хотя судя по всему здесь описан правильный рецепт (надо дописать себе скриптик для выгрузки). Но есть одна проблема. Иногда gpg-agent может ругаться со словами:

gpg-agent[17182]: can't connect to `/home/gor/.gnupg/S.gpg-agent': В соединении отказано
gpg-agent: нет gpg-agent доступого для данной сессии

Это решается путем добавления флага --use-standard-socket при вызове агента или добавлением опции use-standard-socket в файле конфигурации ~/.gnupg/gpg-agent.conf.

Импортируем закрытый ключ:

$ openssl pkcs12 -in keycert.p12 -out keycert.pem -nodes
$ openssl pkcs12 -in keycert.pem -export -out key.p12 -nocerts -nodes
$ gpgsm --call-protect-tool --p12-import --store key.p12

Непонятно почему, но извлечь ключ сразу из .p12 не получается. Зато получается извлеч сертификат.

$ openssl pkcs12 -in keycert.p12 -out certs.pem -nokeys
$ gpgsm --import certs.pem

Чтобы это все заработало необходимо иметь доверие к корневому сертификату. Списки доверенных сертификатов хранятся в ~/.gpg/trustlist.txt. Там должен быть указан fingerptint корневого сертификата и опциональный флаг. Можно поручить это дело gpg-agent'у, указав ему при запуске опцию --allow-mark-trusted, или allow-mark-trusted в файле ~/.gnupg/gpg-agent.conf.

Но это еще далеко не все. Мы можем попытаться указать сертификат S/MIME в kmail, но на попытку подписи получим сообщение - Ошибка шифрования. Чтобы узнать подробности необходимо включать протокол работы gpgsm. Это можно сделать через настройку kmail, правда я не совсем понимаю как работает socket в качестве файла протокола, я указал просто имя файла. Что касается debug-level, то можно использовать следующие значения: none, basic, advanced, expert, guru. И после включения протокола можно узнать, что для полного счастья gpgsm не хватает dirmngr, это демон хранения CRL (почему он не в зависимостях?).

# emerge dirmngr

После этого в kmail почти все работает. Кроме одного неприятного момента. В окнах pinentry все сообщения выводятся закорючками, хотя судя по логу кодировку она использует системную.

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

PS: Все манипуляции с сертификатами, по идее, призвана обеспечивать программа Kaleopatra. Не знаю в каком формате сертификаты ей нужны, но ни .p12, ни .pem она не воспринимает.

Полезные ссылки:
Mew's S/MIME Support
HOWTO KMail gpg-agent kde
запоминалка gnupg-пароля, используем gpg-agent

суббота, 4 октября 2008 г.

Автоматизация тестирования

За что я люблю свою работу - это за то, что не скучно. Я бы наверное умер бы от скуки лет пять назад, если бы трудился все свое время над одним единственным проектом. Может быть поэтому и бытует мнение, что раз в три года надо менять работу? Мне не скучно. Редкий проект затягивается больше чем на год. Причем разнообразие в моей работе весьм радикально. Позапозавчера я писал под Линукс, позавчера под линукс для ARM, вчера под FreeBSD на Perl, сегодня я занимаюсь автоматизацией тестирования. :) Под Windows я тоже иногда пишу. Между АРМ и Perl почти месяц потратил на поддержку АРМ ЭЦП. И еще жду не дождусь, когда меня допустят до CSP, ух, я его перекопаю. Но это если меня на сервер под FreeBSD не посадят. Что-то мне FreeBSD не нравится, сил нету, хотя мне же под нею и не жить. Жить я предпочитаю в Linux, даже Windows запускаю в виртуали, благо компьютер мощный.

Но ближе к делу. Итак Автоматизация тестирования. Встала тут задача автоматизировать тестирование нашего сервера Континент (здесь могла бы быть ваша реклама, но стоит наша). Чтобы сразу после ночных билдов сервер автоматически инсталлировался, запускался и специальным инструментом, который мы писали на прошлом этапе, тестироватся бы на соответствие.

Собственно сервер представляет из себя замкнутую среду на базе FreeBSD, ни о каких vmware-tools речи там быть не может. Но надо ведь его как-то проинсталлировать без вмешательства человека. А инсталляция происходит в интерактивном режиме, вопрос/ответ.

Три дня я ломал голову над тем как можно постать в гостевую систему в vmware нажатия клавиш. Я посмотрел VI Perl (не работает ни с VMWare Server ни с Workstation), VIX - работает, но список его функций без mware-tools весьма ограничен. Там даже нельзя подключить носитель!

Я сел за Visual Studio и долго изголялся с SendInput, но VMWare Ctrl+G получает благополучно, а после блокировки клавиатуры - ничего не ловит, видимо перехватывает ввод где-то еще глубже, хотя уж куда глубже? SendInput прокачивает на ввод сканкоды.

Нагуглил, что есть filter driver. И даже видел фрагменты кода, как с помощью этого симулировать нажатия на клавиши, но фрагмент кода был весьма невелик, что-то не осилил я эту премудрость. Да и не факт что это сработало бы с vmware.

Причем в процессе разбирательства с SendInput я вспомнил про то, что QEMU позволяет вводить символы в гостевой ОС без блокирования клавиатуры. Проверил свои догадки - точно работает, всмысле вводит все как положено в гостевой системе. Но использование QEMU не входило в наши основные планы, в которые входило создание тима в vmware workstation и тестирование серверов в тиме.

И только под конец рабочего дня, когда я уже отчаялся послать что-то в vmware, мне пришла в голову замечательная мысль. А почему бы мне не автоматизировать инсталляцию с помощью QEMU, при этом вовсе не обязательно в том же QEMU производить и тестирование. Тем более, что QEMU прекрасно поддерживает vmdk.

И вот в пятницу с утреца я довел до ума программку, которая посылает строки в виртуальную машину. После чего засел за Visual Build, который первым делом вызывал QEMU для инсталляции, выжидал определенное время до первого вопроса инсталлятора (Хотите ли вы установить Континент?), и начинал посылать туда 'y', всякие необходимые цифры. После окончания инсталляции дожидается перезагрузки, убивает QEMU, запускает ее снова, уже для загрузки с винта, опять куча вопросов, и наконец последняя перезагрузка, QEMU по halt выключается сам, после чего запускается машина vmware, с уже настроенной рабочей конфигурацией, и сконфигурированный сервер стартует как ни в чем не бывало.

Только потом я уже сообразил, что наверное можно было бы обойтись и без отдельной программки для передачи символов. Visual Build поддерживает различные скрипты, которые наверное вполне могут позволить сделать FindWindow, SetForegroundWindow и SendInput. Но в скриптах я не силен, мне проще отдельную программульку написать.

среда, 1 октября 2008 г.

Windows как второй монитор...

Сейчас стало модно работать за двумя мониторами, или даже за тремя. Причем технология работы различается.

Традиционно двухмониторное рабочее место организуется путем объединения двух мониторов в один виртуальный рабочий стол. Вроде бы не за чем иметь один рабочий стол, достаточно того, чтобы мышка могла переезжать с одного экрана на другой. Это позволить переносить приложения и работать полноценно за обоими мониторами. К сожалению я еще недостаточно ориентируюсь в теме использования нескольких мониторов, и не до конца представляю себе рабочий процесс на двух объединенных в один рабочий стол мониторах. Проверю как нибудь на работе.

Можно поступить немного проще, и сделать один монитор информационным, то есть копипастить будет нереально, но информация будет видна. А X11 позволяет использовать в качестве дисплеев даже экраны соседних компьютеров.

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

Для начала идем с винды на сайт, и жмем кнопку 'Install Cygwin/X now'. В появившемся окне инсталлятора cygwin выбираем xorg-x11-base из категории X11. После окончания установки запускаем cygwin
C:\cygwin\Cygwin.bat
и в появившемся окне запускаем xorg server
$ startx

Теперь можно подключаться удаленно. Для этого надо переустановить переменную DISPLAY и запустить необходимое приложение.
$ DISPLAY=192.168.1.3:0.0 kate &
после чего мы сможем увидеть на windows машине, нет, не kate, а сообщение об ошибке:
... X: client 6 rejected from ip 192.168.1.2
Чтобы windows машина нас пустила, необходимо на ней выполнить команду:
xhost +192.168.1.2.
Теперь снова повторяем вызов kate (к примеру) и видим нашу Катю на рабочем столе Windows.

К сожалению информация о хсте не сохранится до следующего запуска. Чтобы она сохранилась надо редактировать файл /etc/X*.hosts, как написано в man xhost, но что-то у меня пока не сработало...

Только не стоит забывать что само то приложение реально работает на Linux машине, Можно легко дезориентироваться, ибо изображение находится на мониторе виндовой тачки, и управлять им надо виндовой мышкой.

PS: Хотя с другой стороны наверное логично то, что kde desktop не может использовать удаленные рабочие столы. Забросить туда приложение наверное не сложно, а после этого оно становится недосягаемо для текущей мышки - проблема.