Меня в systemd пугает концепция «все в одном». Как-то неюниксвейно. Ну и проблемы с переходом: перспектива переписывать под systemd конфиги тоже не разу не радуют.
>не править /etc/systemd/logind.conf, а создавать снипет в /etc/systemd/logind.conf.d/
Тут интересно, как оно расставит приоритеты. Проще поправить logind.conf, я считаю. Вообще, с переходом на это самое, лишнее засыпание было не единственной проблемой: до кучи автомонтирование на скриптах udev отвалилось по причине нововведения с килянием процессов по таймауту…
Надо бы назад на sysv откатиться, благо в дебиане есть такая возможность.
Ну, помимо описания алиасов и заполнения sudoers, у этой небольшой статейки есть еще и вторая часть (:
А по поводу шаблонов, если имеется в виду конструкции типа lxc-.*?, то нет. Более того, указывать потребно полные пути. Писать самому явно не комильфо и получаются такие вещи как-то так:
По крайней мере, дать разрешение на беспарольный запуск команд работающих только на чтение lxc-ls, lxc-info и тому подобное — это, я считаю, вполне оправданно.
Когда я подключаюсь по ssh, всегда использую tmux или screen (на совсем уж древних системах). Отложенные и возобновленные сессии — это очень удобно, плюс мультиплексор имеет свой персональный статусбар, куда можно вывести часики и имя хоста.
Но если уж вот прям никак: мультиплексор нельзя, оконного менеджера нет, кругом только чОрная консоль, то проще набрать три буковки команды top или четыре команды date, чем постоянно держать перед глазами мусор, который, к слову, не будет автоматически обновляться.
Помнится, раньше было очень модно городить conky и выводить туда такую «полезную» информацию, как версия ядра, хостнейм своего локалхоста, несколько штук часов, календарик… Это вот все напоминает.
А по-моему, двухстрочное приглашение — монстроузное приглашение, а вся выведенная информация избыточна и выводится либо средствами оконного менеджера (часы), либо не шибко полезна, чтобы постоянно висеть перед глазами (loadavg).
Для себя я подобрал оптимальную конфигурацию: hostname, текущий каталог с сокращением до половины ширины терминала и информация о свободном месте на текущей файловой системе.
Docker довольно узкоспециализирован. Для изоляции приложений и даже деплоя он, конечно, хорош. Но когда нужен контейнер с полноценной операционной системой, лучше все-таки смотреть на lxc или openvz.
Попробую объяснить. У нас есть куча картинок. В идеале, их все нужно загрузить скопом, не важно там, мышкой или командой и получить список готовых к вставке html-тегов. Желательно, сразу с превьюшками.
Хабрасторадж-то отдаст список загруженных файлов, но теги с превьюшками не построит. Придется их делать и загружать отдельно, плюс соотносить пару превьюшка-оригинал и вставлять все это в текст.
Ладно бы оно нормально работало с curl, скрипт-то сваять не проблема. Но там что-то опять накрутили, и получаем «moved permanetly», что не делай.
Удобства, как говорится, во дворе. Потому я отдаю предпочтения сервисам, которые не столь параноидальны и позволяют взаимодействовать с собой не только посредством тыканья мышкой в браузере.
Да, zfs — штука более чем приятная, а контексте обсуждаемого, с соларис-контейнерами. так вообще просто шик.
Но есть нюансы. На том же основном лаптопе прекрасно работает связка LVM+LUKS, причем получается она, что называется, «из коробки», а вот с brtfs или zfs тут может потребоваться несколько больше телодвижений. Да и со стабильностью, увы, пока не слишком хорошо: так на brtfs поверх dm-crypt вот такая веселуха может всплыть: permalink.gmane.org/gmane.comp.file-systems.btrfs/15564
В случае с LVM доступ по-прежнему простой и удобный, хотя в цепочку действий добавляется необходимость монтирования. Плюсов у LVM много, а в данном случае весьма критично использовать снапшоты в том числе и под машины-клоны. То есть, имеем первый контейнер размером в 2GB, и второй — его копию, но с куда более скромны объемом в сотню метров.
Ну и вообще, LVM штука полезная. Бэкапиться с его помощью просто и приятно.
Про aufs ничего не скажу, сталкиваться покамест не приходилось.
> Реально ли с помощью linux-контейнеров (LCX, Docker) добиться того, чтобы внутри контейнера была запущена отличная от хостовой версия видео-драйвера?
Увы, невозможно. Контейнер работает на ядре хоста со всеми его модулями. Так что здесь только виртуализация и проброс.
Можно, но будут проблемы с построением мостов изнутри контейнера, доступом к хранилищам (например, LVM группам и томам). А так, надо добавить на хосте юзера с uid, например, 31337 и соответствующим gid'ом, а в конфиге контейнера прописать нечто вида:
lxc.id_map = u 0 31337 1
lxc.id_map = g 0 31337 1
И получаем отображение: рут-процессы в контейнере имеют uid/gid свежесозданного юзера. Единичка, если что, это диапазон, указывающий на все остальные uid/gid и как они будут отображаться на хосте.
Вообще, это все еще может быть полезно для синхронизации прав доступа пользователя на хосте и в контейнерах, если uid'ы отличаются.
>Тут же, в конфиге, можно задать и IP, маску, gateway.
Вот только nameserver в конфиге контейнера так не задать. Можно, конечно, попробовать передать через network.script.up… В общем, тут опять же зависит от задачи и фантазии. Нужно много однотипных контейнеров: используем типовой конфиг с небольшими изменениями и сеть описываем как-то вот так.
А может быть нужно воспользоваться дистрибутив-специфичными вещами: потребуется там несколько интерфейсов, обработка событий на up-down, нестандартная маршрутизация итд…
В общем, юзкейсов и способов построения много (:
>Зачем удалять инклюд дефолтного конфига?
Очевидно же: чтобы написать свои правила, которые могут противоречить дефолтному конфигу.
Телодвижений многовато только на первых порах, в момент первичной настройки своего первого контейнера. Да и то, телодвижений — создать контейнер, прописать в конфиге нужные устройства и маунтпоинты, прописать интерфейсы. Может быть в статье это выглядит несколько монстроузно, а на деле делается минут за 20 с кружкой чая. Когда-нибудь, думается, для этого будет сделана гуевая тулза.
А дальше это все клонируется с правкой пары строчек, делаются и удаляются снапшоты при надобности и так далее. Вообще, это все мне очень напоминает будто заново открытые соляровские virtual zones, но я очень рад, что в линуксе такие решения развиваются, полируются и являются при этом свободными.
А отсутствие проблем с дисковым пространством и памятью — это не означает, что всем этим можно разбрасываться направо и налево. Да и отсутствие ли? Я там выше писал про лаптоп, а контейнеры мне нужны и на нем.
>отрабатывать после всех остальных сервисов, в т.ч. и openvpn,
Есть такое дело, верное замечание. На самом деле, устройство достаточно создать один раз и писать это все в rc.local смысла нет. Поглядел сейчас на домашнем десктопе, там все это добро я когда-то закоментировал и, похоже, банально позабыл.
В частности у меня оно выглядит вот так:
/etc/rc.local
#mkdir /dev/net &
#mknod /dev/net/tun c 10 200 &
su user -c 'i2prouter start' &
openvpn /home/user/vpn/my.ovpn
Конечно можно. Их можно править, создавать свои, или вообще создавать образ с помощью того же debbootstrap'a.
Но получить список пакетов с рабочей системы и переложить работу по установке на apt — это может быть проще, чем заниматься правкой и написанием шаблона. Да и не костыль это, а стандартное действие для пакетного менеджера.
Другое дело, когда нужно клепать много однотипных контейнеров на разных хостах — тут действительно проще написать шаблон. В общем, каждой задаче свой инструмент. В этом путь UNIX, да.
Тут интересно, как оно расставит приоритеты. Проще поправить logind.conf, я считаю. Вообще, с переходом на это самое, лишнее засыпание было не единственной проблемой: до кучи автомонтирование на скриптах udev отвалилось по причине нововведения с килянием процессов по таймауту…
Надо бы назад на sysv откатиться, благо в дебиане есть такая возможность.
А по поводу шаблонов, если имеется в виду конструкции типа lxc-.*?, то нет. Более того, указывать потребно полные пути. Писать самому явно не комильфо и получаются такие вещи как-то так:
Потому, я обычно делаю вот так:
Путь срезается до трети ширины терминала. Вот двустороннее приглашение я люблю: справа у меня и выводится
Вообще, люблю подобные обсуждения: всегда можно подсмотреть что-то полезное или поделиться своим.
Когда я подключаюсь по ssh, всегда использую tmux или screen (на совсем уж древних системах). Отложенные и возобновленные сессии — это очень удобно, плюс мультиплексор имеет свой персональный статусбар, куда можно вывести часики и имя хоста.
Но если уж вот прям никак: мультиплексор нельзя, оконного менеджера нет, кругом только чОрная консоль, то проще набрать три буковки команды top или четыре команды date, чем постоянно держать перед глазами мусор, который, к слову, не будет автоматически обновляться.
Помнится, раньше было очень модно городить conky и выводить туда такую «полезную» информацию, как версия ядра, хостнейм своего локалхоста, несколько штук часов, календарик… Это вот все напоминает.
Для себя я подобрал оптимальную конфигурацию: hostname, текущий каталог с сокращением до половины ширины терминала и информация о свободном месте на текущей файловой системе.
Хабрасторадж-то отдаст список загруженных файлов, но теги с превьюшками не построит. Придется их делать и загружать отдельно, плюс соотносить пару превьюшка-оригинал и вставлять все это в текст.
Ладно бы оно нормально работало с curl, скрипт-то сваять не проблема. Но там что-то опять накрутили, и получаем «moved permanetly», что не делай.
Удобства, как говорится, во дворе. Потому я отдаю предпочтения сервисам, которые не столь параноидальны и позволяют взаимодействовать с собой не только посредством тыканья мышкой в браузере.
Но есть нюансы. На том же основном лаптопе прекрасно работает связка LVM+LUKS, причем получается она, что называется, «из коробки», а вот с brtfs или zfs тут может потребоваться несколько больше телодвижений. Да и со стабильностью, увы, пока не слишком хорошо: так на brtfs поверх dm-crypt вот такая веселуха может всплыть: permalink.gmane.org/gmane.comp.file-systems.btrfs/15564
А в дебиан-стейбле у нас 3.16, ага.
Ну и вообще, LVM штука полезная. Бэкапиться с его помощью просто и приятно.
Про aufs ничего не скажу, сталкиваться покамест не приходилось.
Увы, невозможно. Контейнер работает на ядре хоста со всеми его модулями. Так что здесь только виртуализация и проброс.
Можно, но будут проблемы с построением мостов изнутри контейнера, доступом к хранилищам (например, LVM группам и томам). А так, надо добавить на хосте юзера с uid, например, 31337 и соответствующим gid'ом, а в конфиге контейнера прописать нечто вида:
И получаем отображение: рут-процессы в контейнере имеют uid/gid свежесозданного юзера. Единичка, если что, это диапазон, указывающий на все остальные uid/gid и как они будут отображаться на хосте.
Вообще, это все еще может быть полезно для синхронизации прав доступа пользователя на хосте и в контейнерах, если uid'ы отличаются.
Вот только nameserver в конфиге контейнера так не задать. Можно, конечно, попробовать передать через network.script.up… В общем, тут опять же зависит от задачи и фантазии. Нужно много однотипных контейнеров: используем типовой конфиг с небольшими изменениями и сеть описываем как-то вот так.
А может быть нужно воспользоваться дистрибутив-специфичными вещами: потребуется там несколько интерфейсов, обработка событий на up-down, нестандартная маршрутизация итд…
В общем, юзкейсов и способов построения много (:
>Зачем удалять инклюд дефолтного конфига?
Очевидно же: чтобы написать свои правила, которые могут противоречить дефолтному конфигу.
А дальше это все клонируется с правкой пары строчек, делаются и удаляются снапшоты при надобности и так далее. Вообще, это все мне очень напоминает будто заново открытые соляровские virtual zones, но я очень рад, что в линуксе такие решения развиваются, полируются и являются при этом свободными.
А отсутствие проблем с дисковым пространством и памятью — это не означает, что всем этим можно разбрасываться направо и налево. Да и отсутствие ли? Я там выше писал про лаптоп, а контейнеры мне нужны и на нем.
Есть такое дело, верное замечание. На самом деле, устройство достаточно создать один раз и писать это все в rc.local смысла нет. Поглядел сейчас на домашнем десктопе, там все это добро я когда-то закоментировал и, похоже, банально позабыл.
В частности у меня оно выглядит вот так:
/etc/rc.local
Сейчас подредактирую.
Но получить список пакетов с рабочей системы и переложить работу по установке на apt — это может быть проще, чем заниматься правкой и написанием шаблона. Да и не костыль это, а стандартное действие для пакетного менеджера.
Другое дело, когда нужно клепать много однотипных контейнеров на разных хостах — тут действительно проще написать шаблон. В общем, каждой задаче свой инструмент. В этом путь UNIX, да.