Записки IT специалиста

​​Некоторые неочевидные особенности корзины Samba

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

Но все эти достоинства имеют и обратную сторону медали. Многие пользователи любят работать с общими файлами непосредственно в общей папке, запуская их на редактирование из сетевого расположения.

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

Несколько раз открыли один и тот же файл – получили несколько экземпляров в корзину. Таким образом, при достаточно интенсивной работе, объем корзины будет приближаться к горячему объему файлового хранилища, а то и превышать его.

И это не какая-то умозрительная ситуация, буквально на днях мы как раз разбирали этот вопрос с представителем заказчика, который был сильно удивлен почему при общем объеме шары в 35 ГБ объем резервной копии у него получался более 50 ГБ.

Поэтому корзину в Samba необходимо чистить, но делать это не в лоб, а точечно, чтобы ненароком не удалить нужное. Здесь можно опираться на расширение - .tmp или характерный формат имени временных файлов Office, которые начинаются с ~$.

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

Boxes – простая настольная KVM-виртуализация

Возвращаясь к вопросу настольной виртуализации в Linux, нельзя не обратить внимание на Boxes. Это простое приложение Gnome предназначенное для работы с виртуальными машинами, в качестве гипервизора используется хорошо знакомый KVM.

Получилось быстро, просто и достаточно удобно. Почему достаточно? Потому что это Gnome-приложение, построенное в соответствии со всеми представлениями «о прекрасном» разработчиков этой системы, ну и со всеми сопутствующими прибабахами.

Но тем не менее Boxes позволяет быстро и просто создавать виртуалки. Можно использовать свой образ или виртуальный диск, либо скачать готовый. В библиотеке готовых образов представлены практически все открытые ОС: Linux (включая отечественный), BSD и даже экзотическая Haiku.

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

Современный подход к организации конфигурационных файлов

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

Но современный подход как раз таки и подразумевает дублирование опций, возможно даже многократное.

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

Некоторые системы прямо подразумевают такой подход, например, systemd, которая категорически не рекомендует править вручную стандартные юниты, а предлагает воспользоваться технологией drop-in.

Аналогичную схему предлагает и Fail2ban, а так или иначе подобный подход поддерживают очень и очень многие приложения.

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

При этом, опции, которые вы переопределили являются более приоритетными. Также многие программы допускают многократное переопределение опций. При этом в итоге применится опция с наибольшим приоритетом.

Что это дает? А это дает гибкость и удобство в управлении конфигурацией. Начнем с того, что современные системы постоянно обновляются и могут обновлять свои конфигурационные файлы.

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

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

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

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

Отдельный толчок в этом направлении дала контейнеризация и докеризация, контейнер Docker неизменяем, мы можем его убить, перезапустить, обновить на новый, и т.д. и т.п. не затрагивая пользовательские данные. За это его и любят.

Да, мы можем подкинуть конфиг снаружи, но зачем подкидывать целое полотно, если пользователю нужно изменить пять-десять строчек? И для самого пользователя это удобнее и нагляднее, потому что он видит в конфиге только то, что он изменил.

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

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

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

P.S. Алиса - художник, она так видит. Но в целом картинка в тему.

Cloud. ru – те же на манеже

Утро пятницы оказалось не добрым, прилегли рабочие виртуалки на Cloud. ru. А чего прилегли? А пес его знает, но мониторинг сработал, как внутренний, так и внешний.

Ладно, пойдем посмотрим… А, вон оно чего, оказывается все плохо и прилег целый регион AZ-1. Печально, наверное, как приличная организация, хостер оповестил своих клиентов об этом прискорбном факте, просто мы что-то пропустили…

Но увы, Cloud. ru не посчитал это нужным, подумаешь, прилегли – сущая мелочь. Тишина на сайте, тишина в телеграм-канале. Только в личном кабинете плашка, для причастных, чтобы прониклись.

На текущий момент работа сервисов частично восстановлена, что-то заработало, что-то нет. Минимальный простой составил около трех часов.

Три часа, у провайдера федерального уровня (ну так они сами себя позиционируют) и полный игнор своих клиентов. А ведь не каждый может оперативно зайти в личный кабинет и понять, что же там случилось.

Да даже если зашел, то понимания не прибавится. Что именно произошло? Надолго ли? Может пора из бекапа на резервной площадке службы раскатывать или стоит подождать.

Ну и напоследок объективный контроль этой самой виртуалки на Cloud. ru, причем это не FreeTier, это коммерческая виртуалка за деньги. Как видим инциденты там постоянно, можно даже сказать – стабильно.

Ребята, ау? Это уровень федерального провайдера? Или самохост в сельском клубе? Где мышка бежала – хвостиком вильнула или уборщица тетя Шура шваброй провода повыдергивала?

Такой «красоты» нет больше ни на одной площадке нормальных провайдеров, даже несколько ниже рангом.

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

​​Как правильно рассчитать бюджет 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 Вт на порт, поэтому таких камер получится подключить только две.

Поэтому внимательно изучайте спецификации и пользуйтесь при расчетах мощностью исходя из класса потребления чтобы не пришлось в очередной раз рассказывать про «китайские» ватты и обосновывать покупку дополнительных устройств.

Почему 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 ведет себя не так как ожидается, то сначала внимательно изучите конфигурационный файл, как самый частый способ внесения изменений. А потом перейдите к более детальной отладке, чтобы точно выяснить какое значение используется в реальности и кто его установил.

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 вполне рабочим.

Их нравы

BSD- сообщество внезапно забурлило, как от пачки дрожжей сами знаете где. Хотя ничего такого мы не думали и не предполагали, да и статья давно не самая свежая.

Но это хороший индикатор отличия современного Linux от современного BSD. Linux-сообщества в основной массе давно прошли этап «элитизма» и стали обычными техническими сообществами.

Нет, не без токсичности, бывает и такое, но, в общем и целом, Linux сегодня достаточно дружелюбен к новичку. Тебя проведут куда надо, покажут что надо, помогут и направят.

Linux шел этому долго, не один год, но в общем смог избавиться от синонима «красноглазие» и стать еще одной альтернативной операционной системой.

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

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

Любая критика воспринимается как личное оскорбление и проявление ненависти. Хотя, казалось бы, применять такие термины к сугубо техническим вопросам неуместно. Ответная реакция тоже нездоровая, пронизанная оскорблениями и снова собственным «элитизмом».

Также явно проскальзывает пренебрежение ко всем остальным, «непричастным», мол админы Proxmox, которые жмут кнопки в веб-интерфейсе – они неполноценные админы, так – нажиматели кнопок.

И все это снова и снова делает BSD крайне далекой от народа и крайне непопулярной системой. Кто-то хочет вступить в такое сообщество? Где существует пренебрежительное отношение ко всем, кто движется хоть чуть-чуть иначе «линии партии»?

Нет. И поэтому и молодежь, и профессионалы ушли в Linux, где можно спокойно обсуждать технические вопросы, не боясь случайно задеть чьи-то «религиозные» предпочтения.

А со стороны BSD-сообщества правильно было бы признать, что с их стороны нет и близко никакого аналога Proxmox, но они постараются…

Хотя это не про BSD, у них все есть, им это не нужно…

​​Алиасы в PowerShell

Многие, кто только начинает изучать 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.

Конкатенация в Windows и Linux

Многие знают команду 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 или нет. Результат всегда будет ожидаем.