Эксперименты показали, что в качестве дисплея надо использовать spice. Потому что clipboard sharing это сильно.
Ради этого стоит потерпеть и то, что при отсутствии в guest-системе соответствующих тулзов курсор будет ей захватываться и без нажатия специальной комбинации клавиш не отпускаться (у SDL такое поведение просто неотключаемо, а у VNC его нет вообще).

Правда, если использовать spice, писать придется на python с использованеием gtk для gui.

Был бы VNC, можно было бы на tcl/tk писать, tk widget vnc-viewer-а бывает. Правда, с другой стороны, разные реализации VNC очень сильно отличаются по производительности, и есть подозрение что у Кристиана Вернера - не самая быстрая и не самая фичастая.

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

Возникает идея - монитор цеплять к unix-domain-сокету, имя которого в файловой системе как-то тесно связано с именем машины (либо имеется общесистемная директория с этими сокетами, либо в директории где лежат все файлы виртуальной машины, имеется сокет monitor). Это соглашение, кстати, позволит иметь параллельный интерфейс для управления машинами из командной строки. Уж по крайней мере, system_powerdown туда сказать из скрипта всяко можно будет.

Соответственно, при желании присоединиться к работающей машине, мы коннектимся к ее монитору, лочим его (если не смогли - значит там кто-то другой уже работает), а потом спрашиваем у qemu на каком порту он ждет в гости spice/vnc клиента. Благо рассказать он об этом умеет. В принципе, конечно, tcp-порт монитора можно из файла конфигурации машины вычитывать. Но тогда придется его там хранить, а значит - оперативно редактировать этот файл конфигурации, если этот порт вдруг оказался занят. Впрочем, при создании снапшотов его все равно редактировать.

Интерфейс должен выглядеть как в левой полосе - элементы управления, а основное поле - экран гостевой системы.
Элементы управления сверху вниз removable диски, usb-устройства, снапшоты, а в самом низу кнопкки shutdown/reboot/etc. Над ними - окошко консоли монитора.
По верху окна вместо меню кнопки клавиш, которые можно туда послать.

Это если мы запустились с параметром "имя машины".

Если без него - то предлагаются варианты "открыть машину"/"создать машину".
При создании машины предлагается всего два варианта сети на выбор - подключиться к существующему бриджу или использовать user networking.

При подключении устройств и дисков должна быть предусмотрена опция "персистентное подклчение". В смысле пытаться при следующем запуске это устройство подключить обратно.

При закрытии GUI у нас должны быть варианты выбора - shudown, suspend, background.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1106795.html. Please comment there using OpenID. Now there are comments

Разобрался, как в jessie запускать kvm от юзера.

1. Юзер должен входить в группу kvm.
2. Файлы виртуальных дисков должны быть доступны ему (группе) на rw (как бы очевидно)
3. Сеть должна быть или user или bridge. Если сеть brige, то /usr/lib/qemu/qemu-bridge-helper должен быть suid root. Он вообще-то специально написан именно для того, чтобы туда suid-бит ставить.

Поигрался со spice. Заставить его таскать файлы из виндов в хостовый spacefm сходу не удалось, но текст через clipboard копируется. Usb redirection там тоже как-то не очень пока работает.

Клиент spicy написан безобразно. А именно при попытке отправить его в бэкграунд моментально получает SIGTTIN.
У них там странная идея пихать ввод со stdin прямо в основной канал протокола.
Ну а соответственно, всем прочим товарищам хинт - хотите пользоваться spicy как честным GUI приложением, запускайте его как

spicy параметры </dev/null

.

Питоновский клиент виджет - это еще более забавная штука. У него ВООБШЕ нет никакой документации. В пакет python-spice-gtk-client не входит даже двухстрочная README - только so-шка и обязательные copyright и сhangelog.

Из этой so-шки pydoc что-то показывает, но ни одного не сгенеренного автоматически gtk docstring-а я не нашел.
На сайте тоже как-то ничего хорошего в плане документации на клиенскую библиотеку сходу не нашел. Есть подозрение что питоновский интерфейс там достаточно тонкая обертка над сишным.

Но блин делать RTFS в проекте, в котором даже в coding convention написано "длина строки 100, а не 80"!

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1106524.html. Please comment there using OpenID. Now there are comments

Обнаружил тут, что не существует удобного GUI для QEMU/KVM.
Есть virt-manager, но он во-первых, требует громоздких библиотек и демонов, да еще и слинкованных со всякими гадостями вроде policykit, во-вторых со снапшотами нифига работать не умеет, в третьих отказывается запускать виртуальную машину, если не находит USB-девайса который был к машине подключен в предыдущий раз.

Есть qemuctrl, который в общем-то похож на то что надо - просто приделывает к окошку меню, но к сожалению, в этом меню не работают как раз самые нужные мне функции - подключение-отключение USB-устройств на лету.

Есть aqemu, но я вообще не понял какую задачу решщали авторы этой софтины. Там есть довольно развесистое управление созданием VM, но нет управления работой, что как раз гораздо важнее. Поскольку машина создается единожды, а работает годами.

Соответственно, возникла мысль написать свою управлялку. Благо развесить по менюшкам посылание команд в монитор qemu и приделать парсинг ответов, несложно. Такой тонкий-тонкий слой, который делает несколько полезных вещей удобными, не мешая делать все остальные имеющимися способами.

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

1. Поддерживать ли работу VM в бэкграунде? Ну то есть большую часть моих случаев покрывает режим, подобный VMWare Workstation - запускаем vm в рамках сессии, что-то с ней делаем, а потом шатдауним. Для этого подойдет режим -video sdl -monitor stdout. С него и надо начинать, как с самого простого.

Но иногда хочется иметь виртуальные машины, работа которых не прекращается с закрытием окна. Стоит ли возиться с монитором по tcp и vnc-дисплеем (кстати, по-моему использование vnc и spice дисплеи, единственный способ сделать, чтобы мышь спокойно пересекала границы окна виртуального экрана).

Или оставить это большим и толстым серверным системам виртуализации - proxmox, libvirtd etc?

Кстати spice отдельно от libvirt бывает?

2. Очевидно, что следует поддерживать операции управления питанием system_powerdown, system_reset, system_wakeup. (кстати, не нашел в документации действия, обратного к system_wakeup - подниматься из саспенда мы умеем, а попадать в него как?)

Не менее очевидно, что нужно уметь управлять removable устройствами - из-за этого проблема и возникла. usb_add/usb_del, eject, change diskdevice filename, Причин возиться с параллельными-последовательными портами и мышами-планшетами я пока не вижу. Хотя команд для управления ими в мониторе море.

3. Хорошо бы поддержать работу со снапшотами. Но для этого надо понять как она там делается.
В принципе мне бы хватило обертки вокруг qemu-img -b. Вообще про снапшоты написано много букв здесь и здесь.

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

Для моего режима работы то, что откат в предыдущее known-good состояние может требовать перезагрузки, а бэкап - выключения виртуальной машины - не критично. Поскольку это применение - рабочая станция для экспериментов.
Но вот увидеть на экране дерево снапшотов (или хотя бы стэк) и по нему поперемещаться - это ценно.

Потому что, как мы знаем, кнопка revert to snapshot - лучший антивирус.

4. В управление сетевыми устройствами и организацию виртуальных локальных сетей лезть не хочется. Для меня это не слишком актуальная задача, а наработок там много. Поскольку основной дизайн-идеей будет "если что-то можно сделать через параметры командной строки qemu, это по-прежнему можно сделать с аналогичным ситаксисом" я лучше сеть не буду трогать совсем. Хотя использование эмулятора, умеющего разные процессоры открывает интересные перспективны. Например запуска каких нибудь сборок конкретных OpenWRT под qemu-system-mips в качестве роутера виртуальной сети. Но вот пусть кому это надо, тот это и дописывает.

5. Формат файла описания виртуальной машины. Боюсь что без него обойтись нельзя. Пробрасывать все опции командной строки в запускаемый qemu и использовать в качестве файла конфигурации скрипт, вызывающий мой gui, как сделано в qemuctl, конечно, можно, но чем-то мне эта идея не нравится.

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

qemu `cat filename.vm`

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

Кстати, с таким форматом файлов, мы можем задачу GUI для создания виртуальных машин не решать совсем. Хотя написать простенький визард на уровне того же virt-manager-а - занятие на пару часов.

Upd Совсем забыл: 6. Отправка в виртуальную машину клавиш, которые родная GUI-среда хоста злобно перехватывает и к приложению не пропускает (Ctrl-Alt-F?, Ctrl-Alt-Backspace, Ctrl-Alt-Del)

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1106342.html. Please comment there using OpenID. Now there are comments

Привет, Habrahabr!
Наша компания известна прежде всего своими решениями в области информационной безопасности. Мы выпускаем такие продукты, как электронные идентификаторы Рутокен и электронные ключи для защиты софта Guardant.
Обычно наши статьи носят сугубо технический характер, но на этот раз речь пойдет о нашей внутренней системе учета социальных выплат для сотрудников.

Несколько слов о предыстории вопроса. Мы — современная российская ИТ-компания, и, как наверное любая ИТ-компания, мы очень любим все автоматизировать. Помимо прочих, в нашей компании существует компенсация выплат на проезд, походы в театр и фитнес. Долгое время сотрудники были вынуждены собирать и хранить билеты, в нужный день предоставлять их в бухгалтерию, а затем получать свои деньги. В конце концов это процедура нам надоела и мы решили написать максимально простое решение для автоматизации этого процесса. Получившуюся систему мы успешно применяем у себя в компании и сегодня передаем ее в Open source.
Читать дальше →

Попробовал воспользоваться выданным на работе eToken для доступа на линукс-машину по ssh.

Естественно, на машине, куда я втыкал токен, уже установлен Safenet Authentication Client, родной софт от производителя токена, который содержит PKCS11-модуль libeTPkcs11.so. С его помощью можно использовать этот токен в firefox-е и еще много где, причем с ключами и сертификатами, созданными виндовым софтом.
Интерес представляло, насколько хорошо поддержка pkcs11 интегрирована в OpenSSH.

Наибольшую сложность составило почему-то преобразование открытого ключа, извлеченного из сертификата средствами OpenSSL в формат openssh-вого identity.pub. Команда

ssh-keygen -i -m pem -f filename.pem

злобно ругается на нераспознаваемый формат.

Это потому что, openssl полностью перешла на PKCS8 форматы а под pem в опции -m ssh-keygen понимается старый формат.

Правильная команда выглядит как

openssl x509 -in fromtoken.crt -noout -pubkey >filename.pem
ssh-keygen -i -m PKCS8 -f filename.pem

Получить старый формат средствами OpenSSL можно, Для этого в команде rsa есть ключик -RSAPublicKey_out
Можно взять ключик, выдрранный командой x509 (выше) из сертификата и сконвертировать.

Сертификат из токена достается командой:

pkcs11-tool --module libeTPkcs11.so --type cert --id <какой-там-у-вас-id> --read-object

Эта команда выдает сертификат в формате der на stdout, поэтому надо либо переназначить в файл, либо сразу направлять в openssl x509, не забыв ей сказать -inform DER.

Пин-кода чтение сертификата по очевидным причинам не спрашивает.

После того, как ключ получен и положен куда надо в authorized_keys дальше все просто:

Либо

ssh -I libeTPkcs11.so куда.надо

и мы попадаем на нужный хост, одноразово обратившись к токену.

Либо

ssh-add -s libeTPkcs11.so

и золотой ключик у вас в агенте. В обоих случаях, конечно PIN спросят.

Агент нормально переживает внезапное выдергивание токена. Правда, ключ в списке остается.
Что интересно, при попытке его удалить (командой

ssh-agent -e libeTPkcs11.so

спрашивают пассфразу.
При выдернутом токене.

Поиграться что-ли еще с pam-pkcs11?

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

Кроме того, в состав pkcs11 входит pkcs11_eventmgr, который позволяет, например, лочить экран при выдергивании токена. Интересно, удастся ли сделать так, чтобы ssh-agent при выдергивании токена "забывал" пассфразу от него, но когда после вставления токена она вводится в screensaver, получал бы ее оттуда средствами pam.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1103668.html. Please comment there using OpenID. Now there are comments