Журнал Витуса

Вот есть у меня сейчас несколько опенсурсных проектов, которыми может быть стоит заняться, пока не устроился на фулл-тайм работу

1. переписать gost-engine на новый, появившийся в openssl 3.x интерфейс провайдеров.
2. Если уж взялся, за провайдеров то покопаться в pkcs11 провайдере - вдруг там можно малой кровью допилить до поддержки гостовских алгоритмов. Правда плату за это надо требовать с Aktiv, потому что играться я буду с ruToken. А они вряд ли так сильно заинтересованы в этом.
3. Посмотреть что у нас в Postgres с провайдерским интерфейсом openssl и может чего на коммитфест залить на предмет и алгоритмов, и токенов на клиенте. В 18 версию уже не успею, так хоть в 19.
4. По-моему в собственно утилите openssl явно не хватает ключиков для работы с ключами и, особенно, сертификатами на токенах. Но не уверен что пропихнуть соответствующий патчик будет легко даже с помощью beldmit.
5. Написать упрощенный CA для маленьких интранетов. Который будет ориентирован на генерацию ключа вместе с сертификатом, потому что и для внутрикорпоративных сайтов, и для openvpn это основной юз-кейс, когда администратор CA и администратор сайта/VPN - одно лицо. А то что CA.pl, что easy-rsa требуют два движения для получения сертифката - сначала создать ключ и заявку, а потом на заявку выписать сертификат. А здесь основное должен быть даже не код, а лежащий максимально близко к коду, чуть ли не в виде встроенного хелпа учебник по правильному обращению с сертифкатами и ключами. (надо irenedragon попытаться привлечь).
6. Вспомнить про ctypescrypto и переписать ее под 3-е версии и python, и openssl (возможно пригодится для юнит-тестов на провайдеры. А возможно, для юнит-тестов на провайдеры надо портануть ctypescrypto на Platypus )
7. Написать аналог calcurse но с бэкэндом пригодным для синрхронизации vdirsyncer. Под этот проект я даже когда-то репозиторий завел.
8. Была у меня еще идея про линуксовый management interface для openvpn Правда из-за отсутствия у меня теперь необходимости ходить в конторскую openvpn оно как-то менее актуально стало.
9. vws тоже надо бы переписать с нуля под третий питон и девятый qemu. Но может стоит подождать пока 12-й qemu выйдет.

Выяснил сегодня, что в fossil появилась возможность автоматического миррора в git-репозитории.
Ну то есть возможность экспорта и реэкспорта там была столько. сколько я этот инструмент использую.

А вот теперь в версси 2.9 Ричард Хипп прикрутил туда более автоматическую миррорилку и сам миррорит код fossil на гитхаб.

Подумал и сделал гитхаб миррор vws.

Теперь думаю
а) а не сделать ли фоссиловские мастер-репозитории для dyngo и ctypescrypto у которых сейчас на гитхабе мастер-репозиторий.
б) а не сделать ли на гитхабе клоны фоссиловских репозиториев моей фантастики
в) а не оживить ли гит-репозитории в https://wagner.pp.ru/git/fiction, приделав туда автопуш из соответствующих фоссиловских репозиториев, где идет работа.

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

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

В общем, в пятницу я поднял версию до 0.4.

Теперь оно умеет нормально выставлять права на shared машины, чтобы все пользователи группы kvm имели к ним доступ. Появилась, наконец поддержка автостарта машин при загрузке хоста, а при шатдауне оно пытается аккуратно гасить все машины - как автостартованные, так и нет. Надо бы еще сделать так чтобы vws list от рута показывал приватные машины всех пользователей. А vws start от рута слал бы в эротическое путешествие.

vws list научился показывать MAC и IP-адреса машин. Причем MAC и для остановленных тоже.

Разобрались тут наконец как правильно конфигурить bridge, чтобы винда не принимала его при каждом запуске за новую сеть.

Практика показала что не хватает сетевой прозрачности.

Хочется, чтобы указав host:vm или vm@host (не знаю, как лучше) можно было бы получить запущенный локально remote-viewer котоорый через ssh port forwarding конектится к машине на указанном хосте. Помимо некоторой экономии траффика по сравнению с запуском remote-viewer на хосте и форвардинга X-ового интерфейса через ssh, это позволит пробрасывать USB-устройства с рабочего места оператора в виртуальную машину.

Вот только думаю - завести под это дело отдельную команду, или навесить эту функциональность на vws start.

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

Еще назрел полноценный парсинг и редактирование start-файлов. Вот интересно, есть ли библиотека для python, которая максимально точно эмулирует разбор командной строки shell-ом?

Поскольку приходится на работе активно пользоваться виртуальными машинами, допинал до более менее полной задуманной фукциональности свою легковесную обертку над qemu/kvm.

( Что оно может )

( Что оно пока не может )

( Где его берут )

Разобрался, наконец, как в QEMU включить USB redirection по spice-протоколу.
Оно там конечно требует три строчки матерных ругательств на каждый пробрасываемый порт, но работает.
Собственно, на этом все мои потребности в удовлетворении виртуальными машинами практическиу удовлетворены. Можно было бы свои скрипты и не писать. Но раз уж начал, надо будет добить.

Далее, установил, что в пакет virt-viewer, входит клиент remote-viewer, который не проявляет никакого излишнего интеллекта, и, соответсвенно не требует его от сервера. Просто указываешь ему в командной строке spice:// url и поехал. Удобный GUI для проброса USB у него есть.

Вот чего не хватает, так это столь же удобного UI для подключения-отключения iso-образов к CD-ROM виртуальной машины.

Все что удалось выяснить по поводу опций командной строки для SPICE описал здесь

Эксперименты показали, что в качестве дисплея надо использовать 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.

Обнаружил тут, что не существует удобного 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)