А хотите ли вы увидеть заметки о жизни в прифронтовом городе?
Anonymous Poll
71%
Да
21%
Нет
8%
Не определился
❤5🤮4👌1
Docker в Proxmox
Многие ресурсы уже успели сообщить о поддержке в Proxmox VE 9.1 контейнеров Docker, которые можно теперь запускать нативно. Многие давно ждали этой возможности, но радоваться пока рано.
Дело в том, что никакой нативной поддержки Docker в Proxmox VE нет и не планируется, а текущая реализация представляет собой конвертер образов OCI в LXC контейнеры.
Это привело к ряду специфических ограничений. Так, конвертированный контейнер нельзя обновить, просто скачав новый образ. Вам потребуется повторная конвертация и создание нового контейнера.
Также не поддерживаются привычные Docker технологии, такие как Compose. Все это вызывает по меньшей мере недоумение. По сути, у нас уже не Docker, но еще и не LXC, причем сильные стороны обоих технологий нам в полной мере недоступны.
Зачем это может быть нужно? Сказать сложно, возможно, чтобы быстро запустить Docker-контейнер для тестирования. Потому как в отсутствие compose поднимать что-то сложное – это руками скачать все нужные образы, руками их установить и настроить. А при обновлении повторить всю эту процедуру заново.
Но и тут не все так гладко, как хотелось бы. Мы решили для практического ознакомления запустить что-то простое, но полезное, например Uptime Kuma. Скачали образ, конвертировали в контейнер, и он у нас отказался запускаться из-за конфликта с AppArmor.
Это называется, с чем боролись – на то и напоролись. Решить эту проблему, наверное, можно. Но только зачем? Ладно бы у данной реализации были какие-то ощутимые плюсы, но их нет. Так зачем тратить время непонятно на что и непонятно для чего?
Тогда мы решили взять что-то попроще, скажем официальный образ Nginx и здесь у нас все получилось. Но снова радости от этого мало. Штатно в качестве внешнего хранилища предлагается использовать виртуальные диски, что может быть крайне неудобно в эксплуатации.
Нет, никто не мешает смонтировать через конфигурационный файл туда папку, но в этом случае вы не сможете использовать для нее штатное средство резервного копирования и вам придется изобретать дополнительный велосипед.
В общем мы снова приходим к тому, что проще взять обычный LXC-контейнер и не выпендриваться. Все равно никаких плюсов Docker нам не добавит, а вот проблем и забот значительно прибавится.
Если коротко, то все, что хочется сказать по этому поводу: хотели как лучше – получилось, как всегда. В текущем виде реализация Docker в Proxmox VE не выдерживает никакой критики. У Docker забрали все его сильные стороны и превратили в недоделанный LXC.
Причем сделали это не очень хорошо, учитывая возможные проблемы с AppArmor и различные пока неизвестные подводные камни.
Практическое применение также под большим вопросом, так как это уже не Docker, но и не контейнер. Привычные подходы и инструменты тут не работают. А это снова разные костыли и велосипеды. Причем абсолютно непонятно зачем.
Многие ресурсы уже успели сообщить о поддержке в Proxmox VE 9.1 контейнеров Docker, которые можно теперь запускать нативно. Многие давно ждали этой возможности, но радоваться пока рано.
Дело в том, что никакой нативной поддержки Docker в Proxmox VE нет и не планируется, а текущая реализация представляет собой конвертер образов OCI в LXC контейнеры.
Это привело к ряду специфических ограничений. Так, конвертированный контейнер нельзя обновить, просто скачав новый образ. Вам потребуется повторная конвертация и создание нового контейнера.
Также не поддерживаются привычные Docker технологии, такие как Compose. Все это вызывает по меньшей мере недоумение. По сути, у нас уже не Docker, но еще и не LXC, причем сильные стороны обоих технологий нам в полной мере недоступны.
Зачем это может быть нужно? Сказать сложно, возможно, чтобы быстро запустить Docker-контейнер для тестирования. Потому как в отсутствие compose поднимать что-то сложное – это руками скачать все нужные образы, руками их установить и настроить. А при обновлении повторить всю эту процедуру заново.
Но и тут не все так гладко, как хотелось бы. Мы решили для практического ознакомления запустить что-то простое, но полезное, например Uptime Kuma. Скачали образ, конвертировали в контейнер, и он у нас отказался запускаться из-за конфликта с AppArmor.
Это называется, с чем боролись – на то и напоролись. Решить эту проблему, наверное, можно. Но только зачем? Ладно бы у данной реализации были какие-то ощутимые плюсы, но их нет. Так зачем тратить время непонятно на что и непонятно для чего?
Тогда мы решили взять что-то попроще, скажем официальный образ Nginx и здесь у нас все получилось. Но снова радости от этого мало. Штатно в качестве внешнего хранилища предлагается использовать виртуальные диски, что может быть крайне неудобно в эксплуатации.
Нет, никто не мешает смонтировать через конфигурационный файл туда папку, но в этом случае вы не сможете использовать для нее штатное средство резервного копирования и вам придется изобретать дополнительный велосипед.
В общем мы снова приходим к тому, что проще взять обычный LXC-контейнер и не выпендриваться. Все равно никаких плюсов Docker нам не добавит, а вот проблем и забот значительно прибавится.
Если коротко, то все, что хочется сказать по этому поводу: хотели как лучше – получилось, как всегда. В текущем виде реализация Docker в Proxmox VE не выдерживает никакой критики. У Docker забрали все его сильные стороны и превратили в недоделанный LXC.
Причем сделали это не очень хорошо, учитывая возможные проблемы с AppArmor и различные пока неизвестные подводные камни.
Практическое применение также под большим вопросом, так как это уже не Docker, но и не контейнер. Привычные подходы и инструменты тут не работают. А это снова разные костыли и велосипеды. Причем абсолютно непонятно зачем.
👍35❤3🤡1
Mikrotik засоряет лог OpenVPN сервера сообщениями IP packet with unknown IP version=0 seen
Сегодня будет довольно простая заметка, но как показывает практика, не все знают и имеют желание разбираться с подобными ошибками. Ну и правда, зачем, ведь все работает?
Вчера, несмотря на выходной день, нас попросили помочь с подключением макбука директора к OpenVPN серверу, так как ему надо было в командировку, а туннель что-то не хотел работать.
Открыв лог OpenVPN сервера, мы увидели, что он буквально завален однотипными сообщениями:
Которые массово производили несколько клиентов в лице роутеров Mikrotik. На наш вопрос о том, что эти сообщения делают в логе услышали ответ, что мол это же Mikrotik, там OVPN клиент кривой и вообще это ни на что не влияет.
А вот с последним мы решительно не согласны, лог нужен не для того, чтобы складировать в нем всякий мусор, а подобный информационный шум очень сильно мешает этот самый лог читать и анализировать.
Тем более что к клиенту OpenVPN в исполнении Mikrotik эта запись лога никакого отношения не имеет. Ее источник – сервис обнаружения «соседей», который скрывается в IP -Neighbors.
Для того, чтобы роутер прекратил мусорить в лог следует исключить VPN-интерфейсы из числа доступных этой функции. По-хорошему там следует вообще исключить все интерфейсы кроме локальных, так как это потенциальная угроза безопасности.
В результате мы снова получили чистый и читаемый лог, так что теперь нужные записи в нем не приходится искать как иголку в стоге сена.
Сегодня будет довольно простая заметка, но как показывает практика, не все знают и имеют желание разбираться с подобными ошибками. Ну и правда, зачем, ведь все работает?
Вчера, несмотря на выходной день, нас попросили помочь с подключением макбука директора к OpenVPN серверу, так как ему надо было в командировку, а туннель что-то не хотел работать.
Открыв лог OpenVPN сервера, мы увидели, что он буквально завален однотипными сообщениями:
IP packet with unknown IP version=0 seen
Которые массово производили несколько клиентов в лице роутеров Mikrotik. На наш вопрос о том, что эти сообщения делают в логе услышали ответ, что мол это же Mikrotik, там OVPN клиент кривой и вообще это ни на что не влияет.
А вот с последним мы решительно не согласны, лог нужен не для того, чтобы складировать в нем всякий мусор, а подобный информационный шум очень сильно мешает этот самый лог читать и анализировать.
Тем более что к клиенту OpenVPN в исполнении Mikrotik эта запись лога никакого отношения не имеет. Ее источник – сервис обнаружения «соседей», который скрывается в IP -Neighbors.
Для того, чтобы роутер прекратил мусорить в лог следует исключить VPN-интерфейсы из числа доступных этой функции. По-хорошему там следует вообще исключить все интерфейсы кроме локальных, так как это потенциальная угроза безопасности.
В результате мы снова получили чистый и читаемый лог, так что теперь нужные записи в нем не приходится искать как иголку в стоге сена.
👍52❤3🤮2🤝2
Обновили и актуализировали статью:
🔹 Включаем дедупликацию в Windows 10/11
Технология дедупликации давно известна пользователям серверных редакций Windows и широко используется системными администраторами, позволяя эффективно использовать дисковое пространство.
В клиентских системах данная возможность отсутствует, так как домашние сценарии не предусматривают хранение больших массивов данных, однако может быть легко добавлена, что, несомненно, окажется полезным для специалистов и компьютерных энтузиастов.
🔹 Включаем дедупликацию в Windows 10/11
Технология дедупликации давно известна пользователям серверных редакций Windows и широко используется системными администраторами, позволяя эффективно использовать дисковое пространство.
В клиентских системах данная возможность отсутствует, так как домашние сценарии не предусматривают хранение больших массивов данных, однако может быть легко добавлена, что, несомненно, окажется полезным для специалистов и компьютерных энтузиастов.
👍16🥱5👀2❤1
Конкатенация в Windows и Linux
Многие знают команду
На самом деле команда cat выполняет конкатенацию – т.е. соединение текстовых строк.
Допустим нам надо объединить два текстовых файла. Самый простой вариант:
После чего содержимое второго файла будет добавлено в конец первого. Но здесь мы использовали только перенаправление, а cat просто прочитал второй файл.
А если нужно наоборот, сначала содержимое второго файла, а потом первого?
В этом случае нам как раз потребуется конкатенация с перенаправлением результата в новый файл:
Подобные задачи очень часто встречаются на практике, поэтому подобными инструментами нужно владеть на всех используемых платформах.
Говоря о платформе Windows на ум сразу приходит PowerShell, но, вопреки мнению о скудости и убогости, CMD тоже есть что нам предложить.
Практически полным аналогом команды
И это не «тип» как вы могли подумать, а «тайп», глагол имеющий значение «печатать», сразу можно вспомнить «телетайп».
Те же самые команды будут выглядеть как:
И да, перенаправление в Windows тоже есть и было с незапамятных времен.
При этом работа и cat и type имеет свою особенность, они предполагают, что файл должен заканчиваться последовательностью
Иначе вместо ожидаемого результата:
Вы можете получить и получите:
В Linux это обычно не составляет проблемы, все текстовые редакторы, хоть консольные, хоть графические корректно завершают файл. А вот тот же Блокнот способен доставить проблем.
Ну и наконец PowerShell, для этого у него имеется специальный командлет
Чтобы прочитать содержимое файла выполните:
Но можно написать проще:
Если нужно выполнить конкатенацию, то перечислите нужные файлы через запятую.
В PowerShell указанные выше команды будут выглядеть так:
А так как PowerShell возвращает нам набор объектов по одному на строку, то для него не имеет значения завершается ли файл EOF или нет. Результат всегда будет ожидаем.
Многие знают команду
cat, которая чаще всего используется для чтения файлов, и могут удивляться ее названию, недоумевая – причем тут кошки. На самом деле команда cat выполняет конкатенацию – т.е. соединение текстовых строк.
Допустим нам надо объединить два текстовых файла. Самый простой вариант:
cat two.txt >> one.txt
После чего содержимое второго файла будет добавлено в конец первого. Но здесь мы использовали только перенаправление, а cat просто прочитал второй файл.
А если нужно наоборот, сначала содержимое второго файла, а потом первого?
В этом случае нам как раз потребуется конкатенация с перенаправлением результата в новый файл:
cat two.txt one.txt >> result.txt
Подобные задачи очень часто встречаются на практике, поэтому подобными инструментами нужно владеть на всех используемых платформах.
Говоря о платформе Windows на ум сразу приходит PowerShell, но, вопреки мнению о скудости и убогости, CMD тоже есть что нам предложить.
Практически полным аналогом команды
cat в CMD является type.И это не «тип» как вы могли подумать, а «тайп», глагол имеющий значение «печатать», сразу можно вспомнить «телетайп».
Те же самые команды будут выглядеть как:
type two.txt >> one.txt
type two.txt one.txt >> result.txt
И да, перенаправление в Windows тоже есть и было с незапамятных времен.
При этом работа и cat и type имеет свою особенность, они предполагают, что файл должен заканчиваться последовательностью
EOF (End of File) ну или содержать в конце символ переноса строки.Иначе вместо ожидаемого результата:
строка_файла_1
строка_файла_2
Вы можете получить и получите:
строка_файла_1строка_файла_2
В Linux это обычно не составляет проблемы, все текстовые редакторы, хоть консольные, хоть графические корректно завершают файл. А вот тот же Блокнот способен доставить проблем.
Ну и наконец PowerShell, для этого у него имеется специальный командлет
Get-Content. А так как PowerShell имеет объектную модель, то результатом его работы будет набор объектов, каждый из которых будет содержать строку исходного файла.Чтобы прочитать содержимое файла выполните:
Get-Content -Path one.txt
Но можно написать проще:
Get-Content one.txt
Если нужно выполнить конкатенацию, то перечислите нужные файлы через запятую.
В PowerShell указанные выше команды будут выглядеть так:
Get-Content two.txt >> one.txt
Get-Content two.txt, one.txt >> result.txt
А так как PowerShell возвращает нам набор объектов по одному на строку, то для него не имеет значения завершается ли файл EOF или нет. Результат всегда будет ожидаем.
👍21❤2🔥2👀2
Алиасы в PowerShell
Многие, кто только начинает изучать PowerShell, особенно перейдя из мира Linux, жалуются на его многословность, что может быть неудобно, если вы используете PS непосредственно для администрирования системы.
Да, это так, но этому есть свои основания.
Классические UNIX-оболочки создавались в те далекие и светлые времена, когда компьютеры были большие, объемы памяти маленькие, а скорости передачи данных – медленные. Все это заставляло биться буквально за каждый байт.
Кроме того, в те времена не было ни интернета с гуглом, ни разных синтаксис-помощников, поэтому команды старались делать попроще, чтобы запоминать было легче, пренебрегая удобством чтения кода и наглядной очевидностью.
Да, bash прост, но прост для того, кто в нем постоянно работает. Если это не так, то возможны разные веселые, или не очень, затруднения.
Например, команда:
Еще вполне читабельна и если мы помним, что такое grep, то без труда догадаемся, что мы ищем строку "
И если вы не помните синтаксис grep вам придется непросто. Особенно если нужно изменить часть команды.
Поэтому PowerShell, который разрабатывался значительно позже, обильно полили синтаксическим сахаром, справедливо предполагая, что люди тоже могут читать программы. И не только могут, но и будут.
Поэтому тот же аналог grep в PowerShell выглядит так:
Да, многословно, но даже далекий от PowerShell человек поймет, что мы выбираем строки, содержащие текст
И если мы занимаемся написанием скриптов, то такая многословность нам только в плюс, так как сильно облегчает читаемость кода человеком.
А скрипты в голом блокноте давно уже никто не пишет, есть удобные среды разработки с автодополнением, подсветкой синтаксиса, синтаксис-помощниками и прочими плюшками.
Но как быть, если мы используем PowerShell для административных нужд, каждый раз набирать полное имя команды и ключи в консоли, даже с автодополнением, может быть утомительно.
А вот как раз для этого придумали алиасы. Полный список алиасов команд PowerShell можно посмотреть, выполнив команду:
Если нас интересует конкретная команда, то следует набрать:
А если, наоборот, расшифровать алиас, то следует выполнить:
Также можно создавать свои алиасы, для этого используйте команду:
Таким образом мы легко можем настроить среду согласно своих привычек или просто писать в привычном стиле:
А для тех, кто свои лучше годы отдал работе с Windows, напоминаем, что PowerShell давно доступен и на платформе Linux.
Многие, кто только начинает изучать PowerShell, особенно перейдя из мира Linux, жалуются на его многословность, что может быть неудобно, если вы используете PS непосредственно для администрирования системы.
Да, это так, но этому есть свои основания.
Классические UNIX-оболочки создавались в те далекие и светлые времена, когда компьютеры были большие, объемы памяти маленькие, а скорости передачи данных – медленные. Все это заставляло биться буквально за каждый байт.
Кроме того, в те времена не было ни интернета с гуглом, ни разных синтаксис-помощников, поэтому команды старались делать попроще, чтобы запоминать было легче, пренебрегая удобством чтения кода и наглядной очевидностью.
Да, bash прост, но прост для того, кто в нем постоянно работает. Если это не так, то возможны разные веселые, или не очень, затруднения.
Например, команда:
grep error error.log Еще вполне читабельна и если мы помним, что такое grep, то без труда догадаемся, что мы ищем строку "
error" в файле error.log. Но расширение не является обязательным атрибутом файла и поэтому мы вполне можем встретить:grep error error
И если вы не помните синтаксис grep вам придется непросто. Особенно если нужно изменить часть команды.
Поэтому PowerShell, который разрабатывался значительно позже, обильно полили синтаксическим сахаром, справедливо предполагая, что люди тоже могут читать программы. И не только могут, но и будут.
Поэтому тот же аналог grep в PowerShell выглядит так:
Select-String -Pattern "error" -Path .\errorДа, многословно, но даже далекий от PowerShell человек поймет, что мы выбираем строки, содержащие текст
“error” из файла .\error. И если мы занимаемся написанием скриптов, то такая многословность нам только в плюс, так как сильно облегчает читаемость кода человеком.
А скрипты в голом блокноте давно уже никто не пишет, есть удобные среды разработки с автодополнением, подсветкой синтаксиса, синтаксис-помощниками и прочими плюшками.
Но как быть, если мы используем PowerShell для административных нужд, каждый раз набирать полное имя команды и ключи в консоли, даже с автодополнением, может быть утомительно.
А вот как раз для этого придумали алиасы. Полный список алиасов команд PowerShell можно посмотреть, выполнив команду:
Get-AliasЕсли нас интересует конкретная команда, то следует набрать:
Get-Alias -Definition Select-StringА если, наоборот, расшифровать алиас, то следует выполнить:
Get-Alias slsТакже можно создавать свои алиасы, для этого используйте команду:
Set-Alias -Name grep -Value Select-StringТаким образом мы легко можем настроить среду согласно своих привычек или просто писать в привычном стиле:
sls error errorА для тех, кто свои лучше годы отдал работе с Windows, напоминаем, что PowerShell давно доступен и на платформе Linux.
👍23❤1🔥1🥱1
Их нравы
BSD- сообщество внезапно забурлило, как от пачки дрожжей сами знаете где. Хотя ничего такого мы не думали и не предполагали, да и статья давно не самая свежая.
Но это хороший индикатор отличия современного Linux от современного BSD. Linux-сообщества в основной массе давно прошли этап «элитизма» и стали обычными техническими сообществами.
Нет, не без токсичности, бывает и такое, но, в общем и целом, Linux сегодня достаточно дружелюбен к новичку. Тебя проведут куда надо, покажут что надо, помогут и направят.
Linux шел этому долго, не один год, но в общем смог избавиться от синонима «красноглазие» и стать еще одной альтернативной операционной системой.
А вот BSD от макушки до пяток поражена «элитизмом» и это видно в крайне негативной реакции на наш материал. Ну, потому что критиковать «величественный собор» нельзя, хотя нет, можно, то только причастным.
А это, как мы уже писали, прямое следствие его происхождения из академической среды, когда есть некоторые архитекторы, которые знают как надо и есть все остальные. Которые кушают то, что дают.
Любая критика воспринимается как личное оскорбление и проявление ненависти. Хотя, казалось бы, применять такие термины к сугубо техническим вопросам неуместно. Ответная реакция тоже нездоровая, пронизанная оскорблениями и снова собственным «элитизмом».
Также явно проскальзывает пренебрежение ко всем остальным, «непричастным», мол админы Proxmox, которые жмут кнопки в веб-интерфейсе – они неполноценные админы, так – нажиматели кнопок.
И все это снова и снова делает BSD крайне далекой от народа и крайне непопулярной системой. Кто-то хочет вступить в такое сообщество? Где существует пренебрежительное отношение ко всем, кто движется хоть чуть-чуть иначе «линии партии»?
Нет. И поэтому и молодежь, и профессионалы ушли в Linux, где можно спокойно обсуждать технические вопросы, не боясь случайно задеть чьи-то «религиозные» предпочтения.
А со стороны BSD-сообщества правильно было бы признать, что с их стороны нет и близко никакого аналога Proxmox, но они постараются…
Хотя это не про BSD, у них все есть, им это не нужно…
BSD- сообщество внезапно забурлило, как от пачки дрожжей сами знаете где. Хотя ничего такого мы не думали и не предполагали, да и статья давно не самая свежая.
Но это хороший индикатор отличия современного Linux от современного BSD. Linux-сообщества в основной массе давно прошли этап «элитизма» и стали обычными техническими сообществами.
Нет, не без токсичности, бывает и такое, но, в общем и целом, Linux сегодня достаточно дружелюбен к новичку. Тебя проведут куда надо, покажут что надо, помогут и направят.
Linux шел этому долго, не один год, но в общем смог избавиться от синонима «красноглазие» и стать еще одной альтернативной операционной системой.
А вот BSD от макушки до пяток поражена «элитизмом» и это видно в крайне негативной реакции на наш материал. Ну, потому что критиковать «величественный собор» нельзя, хотя нет, можно, то только причастным.
А это, как мы уже писали, прямое следствие его происхождения из академической среды, когда есть некоторые архитекторы, которые знают как надо и есть все остальные. Которые кушают то, что дают.
Любая критика воспринимается как личное оскорбление и проявление ненависти. Хотя, казалось бы, применять такие термины к сугубо техническим вопросам неуместно. Ответная реакция тоже нездоровая, пронизанная оскорблениями и снова собственным «элитизмом».
Также явно проскальзывает пренебрежение ко всем остальным, «непричастным», мол админы Proxmox, которые жмут кнопки в веб-интерфейсе – они неполноценные админы, так – нажиматели кнопок.
И все это снова и снова делает BSD крайне далекой от народа и крайне непопулярной системой. Кто-то хочет вступить в такое сообщество? Где существует пренебрежительное отношение ко всем, кто движется хоть чуть-чуть иначе «линии партии»?
Нет. И поэтому и молодежь, и профессионалы ушли в Linux, где можно спокойно обсуждать технические вопросы, не боясь случайно задеть чьи-то «религиозные» предпочтения.
А со стороны BSD-сообщества правильно было бы признать, что с их стороны нет и близко никакого аналога Proxmox, но они постараются…
Хотя это не про BSD, у них все есть, им это не нужно…
💯44😁13🤡9❤6🔥5
Docker в LXC-контейнерах Proxmox VE
Рекомендуемым разработчиками Proxmox способом запуска Docker контейнеров является виртуальная машина. Таким образом, говорят они, вы получите все преимущества от обоих платформ.
Но многим пользователям интересен запуск Docker-контейнеров в LXC, потому что LXC-контейнер не содержит прослойки виртуализации и напрямую работает с ресурсами хоста, что увеличивает производительность и уменьшает накладные расходы.
Но при этом следует понимать, что LXC-контейнеры используют ядро хоста и не могут быть мигрированы на другой узел без остановки их работы. Поэтому если вам важна живая миграция вашего Docker-окружения, то следует все-таки остановиться на виртуальных машинах.
В противном случае можно попробовать запустить Docker в LXC, для тестирования мы взяли Proxmox Virtual Environment 9.1.2 и запустили на нем LXC-контейнер с Ubuntu 24.04, при создании контейнера следует установить флаг Nesting (в последних версиях PVE установлен по умолчанию).
Далее просто устанавливаем внутри контейнера Docker по официальной инструкции.
Проверяем:
Все должно работать.
Для проверки мы решили запустить все тот же Uptime Kuma, взяли с официального сайта Compose-файл, откорректировали его под собственные требования и все сразу взлетело и заработало.
Хотя при попытке конвертации образа Uptime Kuma в LXC-контейнер, который является штатным нововведением для «нативного» запуска Docker-контейнеров в Proxmox мы получили конфликт с AppArmor.
Немного поработав с Uptime Kuma и убедившись, что все работает как надо и без ошибок мы решили реализовать задачу посложнее, например, запустить Joplin Server. Снова берем Compose-файл, корректируем, запускаем.
И снова все работает, что, собственно, и предполагалось. Проверять эту связку в «нативном» варианте мы даже не стали, так как это полностью лишено смысла и приведет только к неоправданной ручной работе по запуску и настройке, что прекрасно решается в оригинальном Docker через Compose.
Дальнейшая эксплуатация также не принесла никаких сюрпризов. Возможно в данном решении и есть какие-то подводные камни, но пока все выглядит рабочим и каких-либо затруднений не вызывает.
Поэтому можем считать эксперимент удавшимся, а способ запуска Docker в LXC на Proxmox VE вполне рабочим.
Рекомендуемым разработчиками Proxmox способом запуска Docker контейнеров является виртуальная машина. Таким образом, говорят они, вы получите все преимущества от обоих платформ.
Но многим пользователям интересен запуск Docker-контейнеров в LXC, потому что LXC-контейнер не содержит прослойки виртуализации и напрямую работает с ресурсами хоста, что увеличивает производительность и уменьшает накладные расходы.
Но при этом следует понимать, что LXC-контейнеры используют ядро хоста и не могут быть мигрированы на другой узел без остановки их работы. Поэтому если вам важна живая миграция вашего Docker-окружения, то следует все-таки остановиться на виртуальных машинах.
В противном случае можно попробовать запустить Docker в LXC, для тестирования мы взяли Proxmox Virtual Environment 9.1.2 и запустили на нем LXC-контейнер с Ubuntu 24.04, при создании контейнера следует установить флаг Nesting (в последних версиях PVE установлен по умолчанию).
Далее просто устанавливаем внутри контейнера Docker по официальной инструкции.
Проверяем:
docker run hello-world
Все должно работать.
Для проверки мы решили запустить все тот же Uptime Kuma, взяли с официального сайта Compose-файл, откорректировали его под собственные требования и все сразу взлетело и заработало.
Хотя при попытке конвертации образа Uptime Kuma в LXC-контейнер, который является штатным нововведением для «нативного» запуска Docker-контейнеров в Proxmox мы получили конфликт с AppArmor.
Немного поработав с Uptime Kuma и убедившись, что все работает как надо и без ошибок мы решили реализовать задачу посложнее, например, запустить Joplin Server. Снова берем Compose-файл, корректируем, запускаем.
И снова все работает, что, собственно, и предполагалось. Проверять эту связку в «нативном» варианте мы даже не стали, так как это полностью лишено смысла и приведет только к неоправданной ручной работе по запуску и настройке, что прекрасно решается в оригинальном Docker через Compose.
Дальнейшая эксплуатация также не принесла никаких сюрпризов. Возможно в данном решении и есть какие-то подводные камни, но пока все выглядит рабочим и каких-либо затруднений не вызывает.
Поэтому можем считать эксперимент удавшимся, а способ запуска Docker в LXC на Proxmox VE вполне рабочим.
❤6⚡1
Используете ли вы Docker в Proxmox VE (доступно несколько вариантов ответа)
Anonymous Poll
34%
Да, в виртуалках
13%
Да, в LXC
1%
Да, через конвертацию в LXC
2%
Да, прямо на хосте
4%
Нет, но собираюсь в виртуалке
4%
Нет, но собираюсь в LXC
1%
Нет, но собираюсь через "конвертацию"
19%
Нет
22%
Не использую Docker вообще
18%
Ничего не понятно, но очень интересно
🔥5
Почему PostgreSQL игнорирует мои настройки?
Время от времени сталкиваемся с таким вопросом от читателей и коллег. Обычно он возникает после того, как были изменены настройки в конфигурационном файле, но почему-то не применились.
На самом деле все просто, для конфигурационных файлов PostgreSQL действует правило – если настройка перечислена файле несколько раз, то применятся та из них, которая была прочитана последней.
Как и многие другие Linux-приложения PostgreSQL поддерживает технологию включения (include), т.е. мы может вынести настройки в отдельные конфигурационные файлы, указать к ним путь в настройках приложения, и они будут применены в том месте конфигурации, где подключаются директивой include.
В конфигурационном файле PostgreSQL она располагается в самом конце и применяется последней, что гарантирует перекрытие всех ранее указанных настроек. Сама директория с файлами include (обычно conf.d) может содержать несколько конфигурационных файлов, которые читаются в алфавитном порядке.
Но и это еще не все, многие администраторы и даже разработчики (например, PostgresPRO) практикуют выносит изменения в самый конец конфигурационного файла и на первом скриншоте как раз видна такая секция, сделанная при автоматической оптимизации версии сервера СУБД от PostgresPRO.
Такой подход имеет неоспоримые плюсы. Во-первых, ваши настройки гарантированно применятся и будут иметь приоритет над остальными. Во-вторых, все они в одном месте и вам не надо бегать по всему файлу в поисках измененных строк. И, наконец, ими легко управлять, хотите выключить – просто закомментировали этот блок, целиком или частично.
Но есть одна небольшая проблема, многие из тех, кто правят собственно конфигурационный файл редко докручивают его до самого конца и поэтому остаются в неведении о существовании альтернативного набора настроек.
Хорошо, с этим разобрались, но как узнать какие именно настройки использует сервер СУБД в текущее время? Довольно просто, достаточно выполнить команду:
Она соединится с локальным экземпляром СУБД и выполнить команду
Если же мы хотим узнать откуда именно было получено это значение, то придется пойти более сложным путем – выполнить небольшой SQL запрос, это можно сделать как в консоли, но если вы не владеете консольным кун-фу Postgres, то лучше использовать графический инструмент, скажем PgAdmin.
Данный запрос выведет не только текущее значение параметра, но и его источник, расположение файла источника и номер строки в нем.
Кстати, источником не обязательно может быть конфигурационный файл, это может быть:
▫️ default - значение по умолчанию, самый низкий приоритет
▫️ configuration file - конфигурационный файл, приоритет выше default
▫️ override - параметр изменен через ALTER SYSTEM, имеет более высокий приоритет
▫️ command line - значение командной строки при запуске, часто используется в Docker, имеет еще более высокий приоритет.
▫️ environment variable - значение из переменных окружения, которые могут быть заданы как глобально, так и на уровне отдельного клиента, приоритет еще выше.
▫️ client - установлен клиентом в рамках сессии, имеет максимальный приоритет, но применяется только в рамках текущей сессии и не влияет на остальные соединения.
Поэтому, если ваш PostgreSQL ведет себя не так как ожидается, то сначала внимательно изучите конфигурационный файл, как самый частый способ внесения изменений. А потом перейдите к более детальной отладке, чтобы точно выяснить какое значение используется в реальности и кто его установил.
Время от времени сталкиваемся с таким вопросом от читателей и коллег. Обычно он возникает после того, как были изменены настройки в конфигурационном файле, но почему-то не применились.
На самом деле все просто, для конфигурационных файлов PostgreSQL действует правило – если настройка перечислена файле несколько раз, то применятся та из них, которая была прочитана последней.
Как и многие другие Linux-приложения PostgreSQL поддерживает технологию включения (include), т.е. мы может вынести настройки в отдельные конфигурационные файлы, указать к ним путь в настройках приложения, и они будут применены в том месте конфигурации, где подключаются директивой include.
В конфигурационном файле PostgreSQL она располагается в самом конце и применяется последней, что гарантирует перекрытие всех ранее указанных настроек. Сама директория с файлами include (обычно conf.d) может содержать несколько конфигурационных файлов, которые читаются в алфавитном порядке.
Но и это еще не все, многие администраторы и даже разработчики (например, PostgresPRO) практикуют выносит изменения в самый конец конфигурационного файла и на первом скриншоте как раз видна такая секция, сделанная при автоматической оптимизации версии сервера СУБД от PostgresPRO.
Такой подход имеет неоспоримые плюсы. Во-первых, ваши настройки гарантированно применятся и будут иметь приоритет над остальными. Во-вторых, все они в одном месте и вам не надо бегать по всему файлу в поисках измененных строк. И, наконец, ими легко управлять, хотите выключить – просто закомментировали этот блок, целиком или частично.
Но есть одна небольшая проблема, многие из тех, кто правят собственно конфигурационный файл редко докручивают его до самого конца и поэтому остаются в неведении о существовании альтернативного набора настроек.
Хорошо, с этим разобрались, но как узнать какие именно настройки использует сервер СУБД в текущее время? Довольно просто, достаточно выполнить команду:
psql -U postgres -h 127.0.0.1 -d postgres -c "SHOW min_wal_size;"
Она соединится с локальным экземпляром СУБД и выполнить команду
SHOW, которая покажет используемое значение параметра конфигурации, в нашем случае min_wal_size.Если же мы хотим узнать откуда именно было получено это значение, то придется пойти более сложным путем – выполнить небольшой SQL запрос, это можно сделать как в консоли, но если вы не владеете консольным кун-фу Postgres, то лучше использовать графический инструмент, скажем PgAdmin.
SELECT name, setting, source, sourcefile, sourceline
FROM pg_settings
WHERE name = 'max_wal_size';
Данный запрос выведет не только текущее значение параметра, но и его источник, расположение файла источника и номер строки в нем.
Кстати, источником не обязательно может быть конфигурационный файл, это может быть:
▫️ default - значение по умолчанию, самый низкий приоритет
▫️ configuration file - конфигурационный файл, приоритет выше default
▫️ override - параметр изменен через ALTER SYSTEM, имеет более высокий приоритет
▫️ command line - значение командной строки при запуске, часто используется в Docker, имеет еще более высокий приоритет.
▫️ environment variable - значение из переменных окружения, которые могут быть заданы как глобально, так и на уровне отдельного клиента, приоритет еще выше.
▫️ client - установлен клиентом в рамках сессии, имеет максимальный приоритет, но применяется только в рамках текущей сессии и не влияет на остальные соединения.
Поэтому, если ваш PostgreSQL ведет себя не так как ожидается, то сначала внимательно изучите конфигурационный файл, как самый частый способ внесения изменений. А потом перейдите к более детальной отладке, чтобы точно выяснить какое значение используется в реальности и кто его установил.
👍25🔥8❤2
Как правильно рассчитать бюджет PoE
PoE – это весьма популярный стандарт подключения оконечных сетевых устройств с подачей питания непосредственно по витой паре.
И это действительно удобно, таким образом пропадает необходимость дополнительной разводки электропитания, и вы можете подключить устройство с поддержкой PoE везде, была бы витая пара.
А вот дальше начинаются сложности и неприятные неожиданности, связанные с тем, что бюджет PoE был рассчитан неправильно. Поэтому сегодня разберем все тонкости этого процесса.
Начнем с классов PoE, на сегодня их четыре:
🔹 802.3af (802.3at Type 1), PoE – до 15,4 Вт на порт
🔹 802.3at Type 2, PoE+ - до 30 Вт на порт
🔹 802.3bt Type 3, 4PPoE или PoE++ - до 60 Вт на порт
🔹 802.3bt Type 4, 4PPoE или PoE++ - до 90 Вт на порт
Для примера возьмем что-нибудь совсем простое, на чем, кстати, ошибаются гораздо чаще.
👉 Коммутатор Mercusys MS108GP
▫️ Количество портов PoE - 7
▫️ Стандарты PoE - PoE (802.3af), PoE+ (802.3at)
▫️ Бюджет PoE - 65 Вт
Теперь прикидываем, у нас есть 6 камер с максимальным потреблением 5 Вт – итого 30 Вт. Хватает бюджета? Хватает. Цена привлекательная, покупаем.
После чего мы можем сильно удивиться, когда коммутатор откажется подавать питание на 5 и 6 камеру.
Далее, обычно идут разговоры про китайцев, «китайские» ватты и прочие нелицеприятные вещи, которые не имеют к действительности никакого отношения.
На самом деле коммутатор выделяет мощность на порт не просто так и не столько, сколько попросит устройство, а строго согласно классу потребления последнего.
👉 К стандарту 802.3af относятся 4 класса потребления:
🔹 0 – мощность устройства от 0,44 до 12,95 Вт, мощность на порту 15,4 Вт
🔹 1 - мощность устройства от 0,44 до 3,84, мощность на порту 4 Вт
🔹 2 - мощность устройства от 3,84 до 6,49 Вт, мощность на порту 7 Вт
🔹3 - мощность устройства от 6,49 до 12,95 Вт, мощность на порту 15,4 Вт
👉 Стандарт 802.3at добавляет еще один класс:
🔹 4 - мощность устройства от 12,95 до 25,5 Вт, мощность на порту 30 Вт
Класс потребления устройства коммутатор определяет при его подключении, согласно току классификации. Таким образом устройство еще на этапе определения сообщает свой класс и коммутатор резервирует на порту мощность из своего бюджета согласно классу потребления устройства.
Наши камеры с 5 Вт потребления могут относится как к классу 0, так и классу 2. Если камеры окажутся класса 0, то на каждый порт коммутатор будет резервировать 15,4 Вт мощности и бюджет у нас закончится уже после 4 камеры.
Если же будет класс потребления 2, то нам повезет, на 6 устройств уйдет 42 Вт бюджета и еще запас останется.
Как узнать класс потребления устройства? Очень часто до покупки никак. Такой информации может не быть даже в спецификациях производителя. Поэтому всегда закладываемся по самому плохому варианту.
Особенно внимательно надо подходить к мощным устройствам. Скажем у нас есть уличные камеры с максимальным потреблением 15 Вт, и многие могут вполне «очевидно» рассчитывать подключить к такому коммутатору 4 подобных камеры.
Однако, если вы внимательно читали материал выше, то сразу поймете, что такие камеры – это однозначно класс 4 с резервированием 30 Вт на порт, поэтому таких камер получится подключить только две.
Поэтому внимательно изучайте спецификации и пользуйтесь при расчетах мощностью исходя из класса потребления чтобы не пришлось в очередной раз рассказывать про «китайские» ватты и обосновывать покупку дополнительных устройств.
PoE – это весьма популярный стандарт подключения оконечных сетевых устройств с подачей питания непосредственно по витой паре.
И это действительно удобно, таким образом пропадает необходимость дополнительной разводки электропитания, и вы можете подключить устройство с поддержкой PoE везде, была бы витая пара.
А вот дальше начинаются сложности и неприятные неожиданности, связанные с тем, что бюджет PoE был рассчитан неправильно. Поэтому сегодня разберем все тонкости этого процесса.
Начнем с классов PoE, на сегодня их четыре:
🔹 802.3af (802.3at Type 1), PoE – до 15,4 Вт на порт
🔹 802.3at Type 2, PoE+ - до 30 Вт на порт
🔹 802.3bt Type 3, 4PPoE или PoE++ - до 60 Вт на порт
🔹 802.3bt Type 4, 4PPoE или PoE++ - до 90 Вт на порт
Для примера возьмем что-нибудь совсем простое, на чем, кстати, ошибаются гораздо чаще.
👉 Коммутатор Mercusys MS108GP
▫️ Количество портов PoE - 7
▫️ Стандарты PoE - PoE (802.3af), PoE+ (802.3at)
▫️ Бюджет PoE - 65 Вт
Теперь прикидываем, у нас есть 6 камер с максимальным потреблением 5 Вт – итого 30 Вт. Хватает бюджета? Хватает. Цена привлекательная, покупаем.
После чего мы можем сильно удивиться, когда коммутатор откажется подавать питание на 5 и 6 камеру.
Далее, обычно идут разговоры про китайцев, «китайские» ватты и прочие нелицеприятные вещи, которые не имеют к действительности никакого отношения.
На самом деле коммутатор выделяет мощность на порт не просто так и не столько, сколько попросит устройство, а строго согласно классу потребления последнего.
👉 К стандарту 802.3af относятся 4 класса потребления:
🔹 0 – мощность устройства от 0,44 до 12,95 Вт, мощность на порту 15,4 Вт
🔹 1 - мощность устройства от 0,44 до 3,84, мощность на порту 4 Вт
🔹 2 - мощность устройства от 3,84 до 6,49 Вт, мощность на порту 7 Вт
🔹3 - мощность устройства от 6,49 до 12,95 Вт, мощность на порту 15,4 Вт
👉 Стандарт 802.3at добавляет еще один класс:
🔹 4 - мощность устройства от 12,95 до 25,5 Вт, мощность на порту 30 Вт
Класс потребления устройства коммутатор определяет при его подключении, согласно току классификации. Таким образом устройство еще на этапе определения сообщает свой класс и коммутатор резервирует на порту мощность из своего бюджета согласно классу потребления устройства.
Наши камеры с 5 Вт потребления могут относится как к классу 0, так и классу 2. Если камеры окажутся класса 0, то на каждый порт коммутатор будет резервировать 15,4 Вт мощности и бюджет у нас закончится уже после 4 камеры.
Если же будет класс потребления 2, то нам повезет, на 6 устройств уйдет 42 Вт бюджета и еще запас останется.
Как узнать класс потребления устройства? Очень часто до покупки никак. Такой информации может не быть даже в спецификациях производителя. Поэтому всегда закладываемся по самому плохому варианту.
Особенно внимательно надо подходить к мощным устройствам. Скажем у нас есть уличные камеры с максимальным потреблением 15 Вт, и многие могут вполне «очевидно» рассчитывать подключить к такому коммутатору 4 подобных камеры.
Однако, если вы внимательно читали материал выше, то сразу поймете, что такие камеры – это однозначно класс 4 с резервированием 30 Вт на порт, поэтому таких камер получится подключить только две.
Поэтому внимательно изучайте спецификации и пользуйтесь при расчетах мощностью исходя из класса потребления чтобы не пришлось в очередной раз рассказывать про «китайские» ватты и обосновывать покупку дополнительных устройств.
👍87❤4👌1🥱1
Cloud. ru – те же на манеже
Утро пятницы оказалось не добрым, прилегли рабочие виртуалки на Cloud. ru. А чего прилегли? А пес его знает, но мониторинг сработал, как внутренний, так и внешний.
Ладно, пойдем посмотрим… А, вон оно чего, оказывается все плохо и прилег целый регион AZ-1. Печально, наверное, как приличная организация, хостер оповестил своих клиентов об этом прискорбном факте, просто мы что-то пропустили…
Но увы, Cloud. ru не посчитал это нужным, подумаешь, прилегли – сущая мелочь. Тишина на сайте, тишина в телеграм-канале. Только в личном кабинете плашка, для причастных, чтобы прониклись.
На текущий момент работа сервисов частично восстановлена, что-то заработало, что-то нет. Минимальный простой составил около трех часов.
Три часа, у провайдера федерального уровня (ну так они сами себя позиционируют) и полный игнор своих клиентов. А ведь не каждый может оперативно зайти в личный кабинет и понять, что же там случилось.
Да даже если зашел, то понимания не прибавится. Что именно произошло? Надолго ли? Может пора из бекапа на резервной площадке службы раскатывать или стоит подождать.
Ну и напоследок объективный контроль этой самой виртуалки на Cloud. ru, причем это не FreeTier, это коммерческая виртуалка за деньги. Как видим инциденты там постоянно, можно даже сказать – стабильно.
Ребята, ау? Это уровень федерального провайдера? Или самохост в сельском клубе? Где мышка бежала – хвостиком вильнула или уборщица тетя Шура шваброй провода повыдергивала?
Такой «красоты» нет больше ни на одной площадке нормальных провайдеров, даже несколько ниже рангом.
В общем, почему-то мне так кажется, досидим мы тут баланс и пойдем искать другое пристанище, благо вариантов хватает.
Утро пятницы оказалось не добрым, прилегли рабочие виртуалки на Cloud. ru. А чего прилегли? А пес его знает, но мониторинг сработал, как внутренний, так и внешний.
Ладно, пойдем посмотрим… А, вон оно чего, оказывается все плохо и прилег целый регион AZ-1. Печально, наверное, как приличная организация, хостер оповестил своих клиентов об этом прискорбном факте, просто мы что-то пропустили…
Но увы, Cloud. ru не посчитал это нужным, подумаешь, прилегли – сущая мелочь. Тишина на сайте, тишина в телеграм-канале. Только в личном кабинете плашка, для причастных, чтобы прониклись.
На текущий момент работа сервисов частично восстановлена, что-то заработало, что-то нет. Минимальный простой составил около трех часов.
Три часа, у провайдера федерального уровня (ну так они сами себя позиционируют) и полный игнор своих клиентов. А ведь не каждый может оперативно зайти в личный кабинет и понять, что же там случилось.
Да даже если зашел, то понимания не прибавится. Что именно произошло? Надолго ли? Может пора из бекапа на резервной площадке службы раскатывать или стоит подождать.
Ну и напоследок объективный контроль этой самой виртуалки на Cloud. ru, причем это не FreeTier, это коммерческая виртуалка за деньги. Как видим инциденты там постоянно, можно даже сказать – стабильно.
Ребята, ау? Это уровень федерального провайдера? Или самохост в сельском клубе? Где мышка бежала – хвостиком вильнула или уборщица тетя Шура шваброй провода повыдергивала?
Такой «красоты» нет больше ни на одной площадке нормальных провайдеров, даже несколько ниже рангом.
В общем, почему-то мне так кажется, досидим мы тут баланс и пойдем искать другое пристанище, благо вариантов хватает.
💯22🔥6😁5❤2😱2
Современный подход к организации конфигурационных файлов
Прошлая заметка, про многоуровневую схему настроек в PostgreSQL вызвала ряд интересных откликов. Например, что не стоит вообще запускать службу, если в ее конфигурации дублируются опции.
Но современный подход как раз таки и подразумевает дублирование опций, возможно даже многократное.
Какого-то единого стандарта нет, но очень многие приложения допускают такое дублирование и подразумевают, что будет применено или последнее указанное значение, или параметры из внешних файлов будут иметь приоритет над основной конфигурацией.
Некоторые системы прямо подразумевают такой подход, например, systemd, которая категорически не рекомендует править вручную стандартные юниты, а предлагает воспользоваться технологией drop-in.
Аналогичную схему предлагает и Fail2ban, а так или иначе подобный подход поддерживают очень и очень многие приложения.
Если коротко, то его суть сводится к тому, что основной файл конфигурации, который поставляется вместе с пакетом, следует держать неизменным, а все изменения вносить в дополнительные файлы, которые автоматически подключаются к конфигурации.
При этом, опции, которые вы переопределили являются более приоритетными. Также многие программы допускают многократное переопределение опций. При этом в итоге применится опция с наибольшим приоритетом.
Что это дает? А это дает гибкость и удобство в управлении конфигурацией. Начнем с того, что современные системы постоянно обновляются и могут обновлять свои конфигурационные файлы.
После чего у вас есть нелегкий выбор: или оставить все как есть, или принять новый конфиг и потерять все свои настройки. Ну еще можно заморочиться и попробовать смержить конфиги вручную.
По факту обычно оставляется старый конфиг и вроде бы все хорошо. Но на самом деле не все. Ваш конфиг может происходить от какой-то там бородатой версии, которая не может, не знает и не умеет во все то, что умеет актуальный пакет.
И хорошо, если это только новые функции, а не настройки безопасности или еще что-то важное. И получается, что вы как бы и обновились, но на самом деле не до конца.
И отсюда мы приходим к тому, что стандартный конфигурационный файл пакета было бы неплохо обновлять вместе с пакетом, чтобы получать все новые настройки автоматически. А все свои изменения хранить отдельно и переопределять ими стандартные параметры.
Отдельный толчок в этом направлении дала контейнеризация и докеризация, контейнер Docker неизменяем, мы можем его убить, перезапустить, обновить на новый, и т.д. и т.п. не затрагивая пользовательские данные. За это его и любят.
Да, мы можем подкинуть конфиг снаружи, но зачем подкидывать целое полотно, если пользователю нужно изменить пять-десять строчек? И для самого пользователя это удобнее и нагляднее, потому что он видит в конфиге только то, что он изменил.
С другой стороны, иногда бывает сложно понять, а кто и где внес изменения и почему программа ведет себя «неправильно». Но большинство приложений, допускающих многоуровневые конфигурации имеют встроенные инструменты для вывода итоговой конфигурации, как минимум.
Если освоить эти механизмы, то от такого подхода мы получаем только плюсы, нам не надо больше править конфигурационные файлы, мы можем создать готовые конфиги с переопределенными опциями и просто подкидывать их на готовые системы, не заботясь об исходных файлах.
Также мы можем смело обновляться и получать новые функции, исправления и т.д. и т.п. не боясь потерять свои настройки, все ваши настройки в отдельном файле.
P.S. Алиса - художник, она так видит. Но в целом картинка в тему.
Прошлая заметка, про многоуровневую схему настроек в PostgreSQL вызвала ряд интересных откликов. Например, что не стоит вообще запускать службу, если в ее конфигурации дублируются опции.
Но современный подход как раз таки и подразумевает дублирование опций, возможно даже многократное.
Какого-то единого стандарта нет, но очень многие приложения допускают такое дублирование и подразумевают, что будет применено или последнее указанное значение, или параметры из внешних файлов будут иметь приоритет над основной конфигурацией.
Некоторые системы прямо подразумевают такой подход, например, systemd, которая категорически не рекомендует править вручную стандартные юниты, а предлагает воспользоваться технологией drop-in.
Аналогичную схему предлагает и Fail2ban, а так или иначе подобный подход поддерживают очень и очень многие приложения.
Если коротко, то его суть сводится к тому, что основной файл конфигурации, который поставляется вместе с пакетом, следует держать неизменным, а все изменения вносить в дополнительные файлы, которые автоматически подключаются к конфигурации.
При этом, опции, которые вы переопределили являются более приоритетными. Также многие программы допускают многократное переопределение опций. При этом в итоге применится опция с наибольшим приоритетом.
Что это дает? А это дает гибкость и удобство в управлении конфигурацией. Начнем с того, что современные системы постоянно обновляются и могут обновлять свои конфигурационные файлы.
После чего у вас есть нелегкий выбор: или оставить все как есть, или принять новый конфиг и потерять все свои настройки. Ну еще можно заморочиться и попробовать смержить конфиги вручную.
По факту обычно оставляется старый конфиг и вроде бы все хорошо. Но на самом деле не все. Ваш конфиг может происходить от какой-то там бородатой версии, которая не может, не знает и не умеет во все то, что умеет актуальный пакет.
И хорошо, если это только новые функции, а не настройки безопасности или еще что-то важное. И получается, что вы как бы и обновились, но на самом деле не до конца.
И отсюда мы приходим к тому, что стандартный конфигурационный файл пакета было бы неплохо обновлять вместе с пакетом, чтобы получать все новые настройки автоматически. А все свои изменения хранить отдельно и переопределять ими стандартные параметры.
Отдельный толчок в этом направлении дала контейнеризация и докеризация, контейнер Docker неизменяем, мы можем его убить, перезапустить, обновить на новый, и т.д. и т.п. не затрагивая пользовательские данные. За это его и любят.
Да, мы можем подкинуть конфиг снаружи, но зачем подкидывать целое полотно, если пользователю нужно изменить пять-десять строчек? И для самого пользователя это удобнее и нагляднее, потому что он видит в конфиге только то, что он изменил.
С другой стороны, иногда бывает сложно понять, а кто и где внес изменения и почему программа ведет себя «неправильно». Но большинство приложений, допускающих многоуровневые конфигурации имеют встроенные инструменты для вывода итоговой конфигурации, как минимум.
Если освоить эти механизмы, то от такого подхода мы получаем только плюсы, нам не надо больше править конфигурационные файлы, мы можем создать готовые конфиги с переопределенными опциями и просто подкидывать их на готовые системы, не заботясь об исходных файлах.
Также мы можем смело обновляться и получать новые функции, исправления и т.д. и т.п. не боясь потерять свои настройки, все ваши настройки в отдельном файле.
P.S. Алиса - художник, она так видит. Но в целом картинка в тему.
❤11👌8⚡2🥱2👀2
Boxes – простая настольная KVM-виртуализация
Возвращаясь к вопросу настольной виртуализации в Linux, нельзя не обратить внимание на Boxes. Это простое приложение Gnome предназначенное для работы с виртуальными машинами, в качестве гипервизора используется хорошо знакомый KVM.
Получилось быстро, просто и достаточно удобно. Почему достаточно? Потому что это Gnome-приложение, построенное в соответствии со всеми представлениями «о прекрасном» разработчиков этой системы, ну и со всеми сопутствующими прибабахами.
Но тем не менее Boxes позволяет быстро и просто создавать виртуалки. Можно использовать свой образ или виртуальный диск, либо скачать готовый. В библиотеке готовых образов представлены практически все открытые ОС: Linux (включая отечественный), BSD и даже экзотическая Haiku.
Настроек, в лучших традициях Gnome, откровенно мало. У готовой виртуалки немногим больше. Но при желании вы всегда можете внести изменения вручную в файл конфигурации виртуальной машины.
Возвращаясь к вопросу настольной виртуализации в Linux, нельзя не обратить внимание на Boxes. Это простое приложение Gnome предназначенное для работы с виртуальными машинами, в качестве гипервизора используется хорошо знакомый KVM.
Получилось быстро, просто и достаточно удобно. Почему достаточно? Потому что это Gnome-приложение, построенное в соответствии со всеми представлениями «о прекрасном» разработчиков этой системы, ну и со всеми сопутствующими прибабахами.
Но тем не менее Boxes позволяет быстро и просто создавать виртуалки. Можно использовать свой образ или виртуальный диск, либо скачать готовый. В библиотеке готовых образов представлены практически все открытые ОС: Linux (включая отечественный), BSD и даже экзотическая Haiku.
Настроек, в лучших традициях Gnome, откровенно мало. У готовой виртуалки немногим больше. Но при желании вы всегда можете внести изменения вручную в файл конфигурации виртуальной машины.
🔥7❤5👌5🥱2⚡1