LINUX.ORG.RU

appvm v0.1: приглашаю принять участие в тестировании

 , , , ,


1

3

appvm ― утилита, которая позволяет создавать и управлять «тонкими» виртуальными машины для отдельных приложений с помощью пакетного менеджера Nix. Целью проекта является обеспечение большей изоляции в сравнении с песочницами уровня пользователя, при этом предоставляя возможность относительно простого использования в любом дистрибутиве.

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

Особенности:

  • Qemu.
  • Для всех VM используется одна директория /nix, тем самым каждое последующее приложение в VM не занимает значительного пространства на диске.
  • Для управления виртуальными машинами используется libvirt, для отображения — virt-viewer.
  • Базовая реализация перераспределения памяти на основе memory balloon для уменьшения потребления памяти.

Ограничения:

  • На данный момент не поддерживается автоматическое изменение разрешения внутри виртуальной машины. При этом используется автоматическое масштабирование в virt-manager.
  • Отсутствует индикатор прогресса при сборке новой VM для приложения. При создании первой VM для приложения может показаться, что все зависло, но на самом деле нет.

Любая критика и предложения приветствуются (собственно, тред именно для этого и создан).

>>> GitHub / Руководство по установке

★★★★★

appvm ― утилита, которая позволяет создавать «тонкие» виртуальные машины для отдельных приложений с помощью пакетного менеджера Nix

Т. е. это тупо обёртка над Nix и libvirt — сборщик rootfs для qemu/KVM?

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от commagray

Qubes на минималочках?

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

jollheef ★★★★★ ()
Ответ на: комментарий от Deleted

Чем это лучше packer`а, который умеет в разные VM?

Это для другого совсем. Тут для десктопного использования множества виртуальных машин с наименьшим (в конечном итоге, сейчас это все еще недалеко от proof-of-concept) оверхедом.

jollheef ★★★★★ ()
Ответ на: комментарий от barberry

просто qemu достаточно, а будет kvm или что то.. детали.

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

jollheef ★★★★★ ()
Ответ на: комментарий от t184256

К сожалению, вынужден согласиться. Общий /nix это полезно, но как-то все.

Подскажи мне готовое подобное решение, которое будет отличаться только отсутствием «общего nix». Чтобы я нажал на кнопку «запусти мне браузер», и оно открыло этот браузер в виртуальной машине. При этом не предполагало установку другого дистрибутива (вроде QubesOS).

Ведь если ты считаешь, что в написании этого нет пользы, то значит ты знаешь готовые решения, и это не просто типичная токсичность русскоязычного комьюнити к чем-то новому?

Я в него допилю фичу с общим /nix (потому что иначе слишком большой оверхед по размеру на жестком диске) и с радостью буду использовать.

jollheef ★★★★★ ()
Последнее исправление: jollheef (всего исправлений: 1)
Ответ на: комментарий от jollheef

Разворачивать nixos в libvirt умеет nixops, поднимать контейнер с общим /nix умеет nixos-container.

Твой шелл-скрипт на Go на их фоне выглядит бледно. Точно твоя задача особенна и кому-то нужна?

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

Разворачивать nixos в libvirt умеет nixops, поднимать контейнер с общим /nix умеет nixos-container.

Ключевым в фразе «готовое подобное решение» было «готовое». Я не зря привел в пример QubesOS.

Твой шелл-скрипт на Go на их фоне выглядит бледно.

Моя цель в интеграции для получения нужного результата, а не в удовлетворении людей по «количеству кода в решении».

Хотя кода в итоге может получиться и много, но я его буду стараться писать сразу для апстрима конкретного ПО, что используется. Если получится, то и саму утилитку затащу в апстрим NixOS.

Точно твоя задача особенна и кому-то нужна?

Особенной задача не является, нужной — является.

jollheef ★★★★★ ()
Ответ на: комментарий от jollheef

Ключевым в фразе «готовое подобное решение» было «готовое».

nixops и nixos-container как будто сырее твоего решения.

ты пили, кто ж тебя остановит, раз наши с intelfx «переживания» услышаны и ни капли тебя не притормозили.

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

nixops и nixos-container как будто сырее твоего решения.

Они не сырее, они вообще не являются решением нужной задачи.

ты пили, кто ж тебя остановит, раз наши с intelfx «переживания» услышаны и ни капли тебя не притормозили.

Ты так говоришь, как будто я не ожидал увидеть традиционных «ненужнистов».

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

jollheef ★★★★★ ()
Ответ на: комментарий от jollheef

Ок. Перефразирую: слишком много шума для задачи такого объёма, что её можно решить в 50 строк на условном питоне. У каждого админа локалхоста таких решений задач в ~/bin штук десять наберётся.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Ок. Перефразирую: слишком много шума для задачи такого объёма, что её можно решить в 50 строк на условном питоне.

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

Не говоря о том, что решенные на данный момент проблемы являются только верхушкой айсберга, а дальше еще скрывается много всего до того, как это можно будет поставить рядом с проектами вроде Qubes OS. Если ты и Qubes OS можешь в 50 строк на питоне написать — напиши Рутковской, она будет тебе тоже благодарна.

Собственно для того, чтобы двигаться от proof-of-concept к production-ready решению, мне и нужна обратная связь от потенциальных пользователей.

У каждого админа локалхоста таких решений задач в ~/bin штук десять наберётся.

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

В остальном — мне твои действия напоминают «в интернете кто-то не прав», но только в другом ключе — «в интернете кто-то делает то, что мне не нужно». Не нужно и не нужно, проходи мимо и не бампай тред, если тебе действительно не хочется, чтобы кто-то делился тем, что делает.

jollheef ★★★★★ ()
Ответ на: комментарий от hippi90

Вынеси конфиги и xml из кода, не превращай код в свалку.

Да, конечно.

Не стоит создавать свои директории прямо в хомяке, следуй XDG Base Directory Specification

Вот с этим сложно. appvm/$APP подразумевается как шара, и в .config или в .cache её не засунуть. Но что-то придумать стоит, спасибо.

jollheef ★★★★★ ()
Ответ на: комментарий от anonymous

Действительно, зачем делать точку для шары в каталоге share?

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

/use/share тоже называется share, но это же не значит, что мы должны туда шары втыкать, мы их монтируем в /{media,mnt}, ведь так?

jollheef ★★★★★ ()

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

Довольно долгое время использую Qubes, потому ищу частично тех же возможностей. Извиняюсь за нубские вопросы, сужу как пользователь.

1. Не понял насчет разрешения, на скриншоте вроде все норм, но. При изменении размеров окна, изменяется ли окно приложения с сохранением DPI или зумится картинка? Если второе - как это будет решаться, насколько просто это решить.

2. Что по сети, есть ли удобства чтобы быстро пропустить трафик через другую VM, с запущенным Tor, например, или настроенным файрволом? Аналогично ProxyVM в Qubes.

3. Как организуется доступ к файлам на хосте. Вот когда здесь и сейчас файл нужно открыть в приложении в VM, но доступ по пути его расположения заранее не предусмотрен. Или передать файл из одной VM в другую. (В Qubes для этого есть костыль в виде qvm-copy-to-vm и qvm-move-to-vm).

4. Возможности ограничения ресурсов для VM через данную утилиту? Ограничить доступное ОЗУ например?

5. Каков доступ к Nix store из VM? Для Nix containers в документации предупреждается о небезопасности.

6. На NixOS используется общий Nix Store с хостом?

7. Какая вообще интеграция с NixOS возможна. Сделать чтобы установленный софт не присутствовал в $PATH и запускался только через эту штуку.

8. Насколько вообще сложно брать софт из репозитория Nixpkgs и модифицировать для запуска с AppVM?

anonymous ()
Ответ на: комментарий от anonymous

Довольно долгое время использую Qubes, потому ищу частично тех же возможностей.

Равных Qubes возможностей не будет. По крайней мере пока нет планов на это.

1. Не понял насчет разрешения, на скриншоте вроде все норм, но. При изменении размеров окна, изменяется ли окно приложения с сохранением DPI или зумится картинка? Если второе - как это будет решаться, насколько просто это решить.

На данный момент зумится (с сохранением соотношения сторон). Решить не должно быть сложно, но на данный момент это не работает.

2. Что по сети, есть ли удобства чтобы быстро пропустить трафик через другую VM, с запущенным Tor, например, или настроенным файрволом? Аналогично ProxyVM в Qubes.

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

Путь в рамках текущей идеологии ― сделать отдельное описание на VM, в которой будет настроен iptables на tor-only, и соответственно настроен torbrowser.

Use-case полезный, сегодня вечером постараюсь сделать описание.

4. Возможности ограничения ресурсов для VM через данную утилиту? Ограничить доступное ОЗУ например?

Возможно, но не для каждой VM, а выставить единые настройки для всех. Есть возможность динамически увеличивать (и уменьшать) доступную память для VM в зависимости от того, сколько занято. По умолчанию для каждой VM выдается текущее потребление ОЗУ + 20%, но не меньше гигабайта. Если запустить appvm autoballoon --min-memory=512 --adj-memory=10, то, соответственно, значения будут +10% ОЗУ, но не меньше 512 мегабайт.

5. Каков доступ к Nix store из VM? Для Nix containers в документации предупреждается о небезопасности.

read-only virtfs. Безопасно ровно настолько, насколько безопасен virtfs. В планах есть аудит безопасности virtfs.

6. На NixOS используется общий Nix Store с хостом?

Да.

7. Какая вообще интеграция с NixOS возможна. Сделать чтобы установленный софт не присутствовал в $PATH и запускался только через эту штуку.

По умолчанию так и есть.

8. Насколько вообще сложно брать софт из репозитория Nixpkgs и модифицировать для запуска с AppVM?

Модификация не нужна. Сейчас нужно добавить описание .nix, где указано имя пакета и путь к бинарнику.

jollheef ★★★★★ ()
Ответ на: комментарий от intelfx

Потом этот же жолхиф скажет, что это на самом деле в systemd много шума, а

Первый раз вижу человека, которого волнует не решение задачи, а объем решения.

По отношению к systemd окажется неправильной оценкой.

rotfront ()
Ответ на: комментарий от jollheef

Спасибо за ответы.

2. Одна из самых нужных фичу в Qubes, фактически без готовых аналогов в популярных дистрах. Как только люди без этого живут.

Сейчас пытаюсь пользоваться flatpak c bubblewrap, но там нет таких возможностей в настоящий момент. Ожидал, что с VM будет гибче.

Тор вообще только как пример.

4. Меня больше интересует потолок.

anonymous ()
Ответ на: комментарий от anonymous

Нет, до этого не был знаком. Посмотрел, спасибо.

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

jollheef ★★★★★ ()
Ответ на: комментарий от jollheef

Последний релиз пробовал тот, что на сайте. Оно ещё развивается? Хорошо если так, ожидается релиз?. Subgraph полезет нем, что есть per-app файрвол и проброс трафика через тор для отдельных приложений. В остальных линуксах с этим плохо, кроме Qubes.

anonymous ()
Ответ на: комментарий от anonymous

Последний релиз пробовал тот, что на сайте.

Заглянул сейчас на их сайт — там последний релиз в 2017, то есть точно не то, что я тыкал руками.

Оно ещё развивается?

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

По датам лучше лично спроси, почтовый адрес есть в общем доступе.

jollheef ★★★★★ ()