​​Стандартные systemd target в Linux

Говоря о юнитах systemd, нельзя не отметить такой тип юнита как таргет (цель, taget). Таргет – это особый тип юнита, который позволяет объединить несколько юнитов в группу и управлять ими как единым целым.

Вы можете создать собственный таргет из взаимозависимых служб и, скажем, одновременно перезапускать все относящиеся к веб-серверу службы: веб-север, СУБД, PHP и т.д.

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

Посмотреть список стандартных целей можно командой:

systemctl -–type=target

После чего мы увидим список всех активных таргетов, чтобы увидеть полный список используйте команду:

systemctl -–type=target -–all

Что в этом полезного и для чего мы можем их использовать? Прежде всего для указания зависимостей. Допустим нам нужно, чтобы наша служба запускалась после того, как будет инициирована сеть, нет ничего проще:

After=network.target

Если вы используете сетевые файловые системы, такие как NFS или CIFS/SMB и ваша служба должна запуститься после того, как они будут смонтированы:

After=remote-fs.target

И не нужно ничего придумывать, systemd уже подумала за вас.

У некоторых целей может быть сразу несколько вариантов, например, существуют сразу три сетевых таргета:

▫️ network-pre.target
▫️ network.target
▫️ network-online.target

Цель network-pre.target представляет собой точку состояния системы перед запуском сетевых служб и может быть использована для запуска тех служб, которые обязательно должны быть активны на момент запуска сети, например, брандмауэр.

Данная цель должна использоваться как Before=network-pre.target или Wants=network-pre.target.

Собственно network.target обозначает состояние запуска всех сетевых служб системы и для прочих юнитов, которым нужна сеть мы должны использовать After=network.target, т.е. состояние после того, как все сетевые службы были запущены.

И, наконец, network-online.target – это точка состояния системы, когда все сетевые службы успешно и гарантированно запущены. Используется только с Wants= и After=, используется в основном для устаревших служб или сценариев, которые некорректно работают с After=network.target.

Отдельного разговора заслуживают Boot targets – цели загрузки, эти таргеты являются аналогами уровней запуска init. Существуют следующие загрузочные таргеты:

▫️ poweroff.target (runlevel 0) – выключение системы
▫️ rescue.target (runlevel 1) – режим восстановления системы
▫️ multi-user.target (runlevel3) – многопользовательский режим (консольный режим без графики)
▫️ graphical.target (runlevel 5) – режим графического окружения
▫️ reboot.target (runlevel 6) – перезагрузка системы

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

Узнать текущее состояние по умолчанию можно командой:

systemctl get-default

А установить новую цель загрузки можно командой:

 systemctl set-default graphical.target

При этом graphical.target имеет одну особенность, при отсутствии графики он запускается и работает аналогично multi-user.target и поэтому не следует удивляться, увидев его в системе без графической оболочки или в контейнере.

По-умолчанию graphical.target для систем без графического окружения используют Debian и Ubuntu.

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

systemctl isolate multi-user.target

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

Ну и напоследок весьма злая шутка:

systemctl set-default reboot.target 👻👻👻

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

​​Linux – права файловой системы

Все знают, что Linux унаследовал и использует классическую систему прав UNIX, которая строится вокруг трех субъектов: владельца, группового владельца и остальных, каждый из которых имеет право на чтение – r, запись – w и исполнение – х.

Записываются права посимвольно слева на право: владелец – группа – прочие, для каждого указываются доступные права – rwx, отсутствующее право заменяется прочерком, например:

rw- r—- r—-

Обозначает право на запись и чтение для владельца и только чтение для группы и прочих.

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

Т.е. приведенный набор прав можно записать как:

110 100 100

Или в более привычной восьмеричной форме:

644

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

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

755 -> 111 101 101 -> rwx r-x r-x

Т.е. полные права у владельца и чтение и исполнение для остальных.

Теперь перейдем от файлов к директориям, директория — это такой особый тип файла, который содержит записи о файлах, содержащихся в этой директории.

И права тут значат немного иное: r - право получения имен файлов в каталоге (но не их атрибутов), x - право получения доступа к файлам и их атрибутам, w - право манипулировать именами файлов, т.е. создавать, удалять, переименовывать.

Минимально разумный набор прав к директории r-x, полный rwx.

Поэтому обычно в Linux используются следующие права по умолчанию: 644 для файлов и 755 для директорий.

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

Право на исполнение файлов по умолчанию не устанавливается.

Это – минимальный набор знаний, которые вы должны иметь о правах доступа к файловой системе Linux.

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

Там также трехбитовая запись, каждый бит в которой (слева-направо) означает:

SUID – SGID – stiky

sticky-бит – он же 001 или 1 – может быть установлен только для каталога, его установка для файлов игнорируется. В переводе stiky означает – липкий, что полностью соответствует его работе.

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

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

SUID – 100 или 4 – право запускать файл с правами его владельца, а не пользователя который его запустил. Широко используется для ряда системных утилит, таких как passwd. Ведь пользователь должен иметь право изменить сам себе пароль, но для этого необходимы права root, что легко решается через установку SUID.

В буквенной записи SUID и SGID заменяют x на s в правах пользователя или группы, установленный sticky-бит заменяет x на t в правах для остальных.

В восьмеричном виде записывается первым октетом. Например, комбинация stiky + SGID + стандартные права 755 может быть записана так:

011 111 101 101 -> 3755 –> rwx r-s r-t

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


Более подробно рекомендуем прочитать в наших статьях:

🔹 Linux - начинающим. Работаем с файловой системой. Теория

🔹 Linux - начинающим. Работаем с файловой системой. Практика

​​Мониторинг. Внешний и внутренний.

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

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

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

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

Что произошло? Упал интернет? Выключили электричество или выбило питающий стойку автомат? А может это просто Zabbix упал?

Чтобы иметь возможность получить ответы на эти вопросы и понадобится внешний мониторинг.

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

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

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

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

При этом важно мониторить также внешний адрес и доступность сервисов на нем. Так если VPN упал, но внешний адрес и порт доступны, то стоит проверить сам VPN-сервер или срок действия сертификатов к нему (как клиентских, так и серверных).

Мы чаще всего реализуем эту схему как Zabbix в качестве внутреннего мониторинга и The Dude на CHR в качестве внешнего. Эта связка позволяет не усложнять схему, все-таки Zabbix сложный и тяжелый продукт, но получать максимум актуальной информации, для проверки сетевой доступности и снятия ключевых показателей The Dude подходит достаточно неплохо.

А как решаете подобные задачи вы? Используете разделение мониторинга на внешний и внутренний?

​​Программные лицензии 1С – как узнать причину слета лицензии и быстро активировать ее заново

Про программные лицензии ходит много мифов, мол они сильно капризные, слетают на ровном месте и т.д. и т.п.

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

При отсутствии этой самой тонкой желтой книжки всегда можете обратиться к нашей статье:

▫️ Особенности применения программных лицензий 1С:Предприятие

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

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

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

Потому что добавлять в конфигурацию оборудование можно, удалять нельзя.

Кстати, после того как вы отключите внешние диски, то запустите 1С еще раз и снова посмотрите Журнал поиска ключа, чтобы четко понимать какие именно накопители будут влиять на текущую лицензию и уже после этого занимайтесь ее восстановлением.

Если у вас нет резервного ПИН-кода, то следует воспользоваться сервисами самообслуживания, либо написать письмо на адрес [email protected]. Письмо желательно писать с того адреса, на который зарегистрирована лицензия.

В нем в произвольной форме указываете номер поставки и просите выдать резервный пин-код.

Если пишите с другого адреса, то укажите также текущий пин-код и сведения о владельце лицензии.

Теперь о сервисах самообслуживания, это быстро и удобно, сейчас их четыре:

▫️ Восстановить данные о лицензии
▫️ Получить текущее состояние пин-кодов
▫️ Получить резервный пин-код
▫️ Получить лицензию из файла

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

​​Установка и запуск нескольких экземпляров сервера 1С:Предприятие на одном компьютере. Платформа Linux

Запуск нескольких экземпляров сервера на одном компьютере является штатной возможностью сервера 1С:Предприятие и позволяет использовать несколько платформ одновременно или разделить сервера на рабочие и тестовые.

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

Процесс установки дополнительных экземпляров сервера 1С:Предприятие на платформе Linux в целом несложен, однако официальная документация скупа и обрывочна, поэтому исправим данный пробел.

https://interface31.ru/tech_it/2023/10/ustanovka-i-zapusk-neskolkih-ekzemplyarov-servera-1spredpriyatie-na-odnom-kompyutere-platforma-linux.html

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

По Windows c задержкой в два дня, а по Linux в три… Интересно почему… Трудности перевода, не иначе.

И, оказывается, за рубежом есть ресурсы по 1С. Надо Борису Нуралиеву написать, он, походу, не в курсе.

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

Но выяснилось, что сей пассажир жив и здоров, пришлось исправить это недоразумение 5 минут назад.

Я все понимаю, но подобное поведения для меня загадка. Зачем? Почему? Что он получил от этого?

Невеселые новости от Oracle Cloud.

При очередном входе система потребовала безальтернативно подключить MFA.

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

Фактически это очень и очень сильно усложняет использование бесплатных VPS от Оracle, особенно с их любовью выключать сервера за "неактивность".

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

​​Ваш Zabbix напрасно поднимает панику, у нас еще много памяти

Не столь давно, после внедрения Zabbix один из заказчиков пожаловался, что Zabbix начал присылать сообщения о том, что недостаточно оперативной памяти, но на самом деле памяти еще достаточно.

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

Так что, Zabbix неправильно считает память или напрасно нагнетает панику? Вовсе нет, давайте разбираться.

Давайте возьмем еще один хост с Proxmox и посмотрим, судя по графику у нас в запасе еще около 10 ГБ свободной памяти, неплохо.

Но если запустим команду:

free -h

То картина существенно изменится, как оказывается свободной памяти у нас всего 2,2 ГБ, а доступной 6,3 ГБ.

При этом у нас 3,8 ГБ разделяемой памяти и 8,3 ГБ буферной/кеша.

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

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

Т.е. если мы сложим вместе used + shared + buff/cache то полученное значение не будет соответствовать total – free.

Теперь давайте разберемся что значит каждый вид памяти:

▫️ used – использованная, память которая напрямую используется рабочими процессами в системе

▫️ free – свободная, это память которая не используется ни одним процессом и может быть выделена незамедлительно.

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

▫️ buff/cache – буфер ввода-вывода и кеш VFS (виртуальной файловой системы), играет очень важную роль, так как позволяет разместить в памяти наиболее часто запрашиваемые данные, системные библиотеки и т.п.

▫️ available – доступная, память которая может быть выделена процессу без обращения к пространствам подкачки.

И именно доступная (available) память наиболее точно отображает положение дел с наличием памяти в системе, и именно она используется в триггерах Zabbix.

Proxmox же просто показывает нам used, а остальное помечает свободным. Исходя из этого у нас имеется 10 ГБ «свободной» памяти, на самом деле нам доступно только 6 ГБ, где остальное?

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

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

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

Собственно, это мы и видим в данном случае - 4.7 ГБ памяти содержит «дорогой» кеш и не сможет быть быстро освобождена. Точнее, система будет держаться за этот кеш до последнего, потому что после его очистки плохо станет всем, а пристрелят или отправят в своп только некоторых.

Поэтому в данном случае Zabbix прав, с чем наши заказчики скоро столкнулись, когда OOM Killer начал выключать одну из малоактивных виртуалок.

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

Почему у жесткого диска указан TRIM и что это обозначает?

​​Итак, откуда у жесткого диска команда TRIM

К сожалению, правильный ответ на вопрос дали только 23% читателей. И это действительно диск с SMR, а наличие поддержки TRIM у жесткого диска – 100% признак черепицы.

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

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

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

Более подробно об этом в нашей статье: Что такое черепичная магнитная запись SMR и стоит ли ее избегать?

​​Как внедрять изменения и не остаться у разбитого корыта

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

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

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

Поэтому мы делаем так: планируем и разбиваем на части внедрение, выполняем замеры времени и составляем временной график. Это позволяет оценить сколько времени нам понадобится на то, чтобы все сделать как надо.

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

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

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

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

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

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

Это может усложнить и удлинить процесс, но позволит реализовать его частями. Теперь, если что-то пошло не так – возвращаемся к очередной точке фиксации.

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

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

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

А каких методов планирования придерживаетесь вы? Спринт или спортивная ходьба? Планируете ли откаты?