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

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

​​Как правильно редактировать юниты systemd

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

Действительно, сравните сложность написания init-файла и юнита. 🤷🏻‍♀️

И, как всякая хорошо спроектированная и продуманная система systemd предполагает многоуровневую систему управления юнитами.

Начнем с мест их расположения, которые перечислим в порядке повышения приоритета:

▫️ /usr/lib/systemd/system – юниты установленные вместе с пакетами
▫️ /run/systemd/system – юниты, которые создаются автоматически при загрузке системы и существующие только в рамках текущего сеанса
▫️ /etc/systemd/system – юниты, созданные системным администратором

Директория /etc/systemd/system имеет наивысший приоритет и если нам нужно изменить существующий юнит службы, то мы можем скопировать его сюда из /usr/lib/systemd/system и внести свои изменения.

Вроде бы просто, да не совсем. При обновлении пакета юнит в /usr/lib/systemd/system тоже будет обновляться, при этом, в отличии от изменения конфигурационных файлов, никакого предупреждения мы не получим.

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

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

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

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

Скажем, нам нужно внести изменения в работу юнита myservice.service, для этого мы должны создать каталог /etc/systemd/system/ myservice.service.d и поместить в него один или несколько фалов с расширением conf.

Проще всего это сделать с помощью команды:

systemctl edit myservice

Напоминаем, что если вы не указали тип юнита, то по умолчанию он принимается за service, а если вам нужно внести изменения в таймер, то придется указать имя юнита полностью:

systemctl edit myservice.timer

Затем указываем только те опции, которые хотим переопределить или добавить, например:

[Unit]
Requires=новая зависимость
After=новая зависимость

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

Если вы добавите:

[Service]
ExecStart=новая команда

То эта строка будет добавлена к существующим строкам ExecStart в юните, если вы хотите переопределить это значение, то его сначала необходимо сбросить:

[Service]
ExecStart=
ExecStart=новая команда

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

Еще одним достоинством команды systemctl edit является то, что по окончании редактирования конфигурация systemd будет перечитана, а служба перезапущена.

Откатить изменения можно командой

systemctl revert myservice

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

systemctl daemon-reload

И перезапустите службу

systemctl restart myservice

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

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

​​Производительность виртуальных машин и контейнеров Proxmox

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

Мы прогнали несколько различных тестовых пакетов, но так как результат везде получился идентичный, то мы оставили в основном результаты от Nench и добавили тесты памяти из Sysbench.

Формат заметки в телеграм не располагает к многословности. поэтому приступим. Начнем с теста процессора, в настоящий момент в Proxmox 8 для KVM добавили новый тип процессора по умолчанию - x86-64-v2-AES, который выбирается теперь вместо kvm64, мы протестировали их оба.

Контейнер обращается сразу к процессору хоста, в каждом из тестов показано как именно определяется процессор в системе.

Host
AMD Ryzen 3 PRO 4350G
CPU: SHA256-hashing 500 MB
    1.809 seconds
CPU: AES-encrypting 500 MB
    0.668 seconds

KVM
QEMU Virtual CPU version 2.5+ 
(x86-64-v2-AES)
CPU: SHA256-hashing 500 MB
    1,812 seconds
CPU: AES-encrypting 500 MB
    0,705 seconds

Common KVM processor 
(kvm64)
CPU: SHA256-hashing 500 MB
    1.843 seconds
CPU: AES-encrypting 500 MB
    2.070 seconds

CT
AMD Ryzen 3 PRO 4350G
CPU: SHA256-hashing 500 MB
    1.853 seconds
CPU: AES-encrypting 500 MB
    0.681 seconds

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

Память, результат говорит сам за себя:

Mem 7260.77 MiB/sec

KVM
Mem 6951.16 MiB/sec

CT
Mem 7133.17 MiB/sec

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

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

Host
dd: sequential write speed
    1st run:    1621.25 MiB/s
    2nd run:    1907.35 MiB/s
    3rd run:    1811.98 MiB/s
    average:    1780.19 MiB/s

LVM
dd: sequential write speed
    1st run:    1239.78 MiB/s
    2nd run:    1525.88 MiB/s
    3rd run:    1525.88 MiB/s
    average:    1430.51 MiB/s

Qcow2
dd: sequential write speed
    1st run:    1430.51 MiB/s
    2nd run:    1907.35 MiB/s
    3rd run:    1811.98 MiB/s
    average:    1716.61 MiB/s

RAW
dd: sequential write speed
    1st run:    1430.51 MiB/s
    2nd run:    1811.98 MiB/s
    3rd run:    1716.61 MiB/s
    average:    1653.04 MiB/s

Самый быстрый из форматов диска Qcow2, работает практически на скорости хоста, чуть медленнее RAW – примерно на 8%, а вот LVM еще более медленный, отставание составляет уже около 20%.

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

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

Отдельно хотелось бы сказать о параметрах кеширования, включив тот же Write Back (unsafe) мы можем получить очень высокие скорости записи, в несколько раз превышающие скорости хоста, так как в этом случае реальная запись ведется в оперативную память.

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

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

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

​​Маркировка шагает по стране – новые печали для ИП

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

Но в документе есть одна веселая приписка, а именно последний абзац, который требует от предпринимателя, чтобы каждое из мест осуществления деятельности было зарегистрировано в ЕГАИС.

Что это значит? Сейчас многие ИП работают с одним единственным УТМ, к которому подключен единственный токен с подписью и зарегистрирован он либо на один из адресов, либо вообще на домашний адрес ИП.

Возможность регистрировать каждое место деятельности есть, но закон позволяет ИП работать с единственным УТМ.

Теперь на каждое место деятельности понадобится свой УТМ и своя подпись. А это автоматически влечет выпуск подписей на физлиц + МЧД. Работа с МЧД реализована в УТМ начиная с 2562 и в целом работает, но сама стабильность работы этой системы еще далека от идеала.

О злоключениях можно почитать на Инфостарте: https://forum.infostart.ru/forum81/topic302955

А сам бизнес получает новую порцию проблем. Начиная с того, что сама идея читать марки на кегах сопряжена со сложностью передачи этой марки в учетную систему. В кеге 30 или 50 кг, не накатаешься, а самый дешевый вариант – беспроводной сканер ШК – от 10 тыс. руб.

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

А пока наша статья по ЕГАИС в Linux: https://interface31.ru/tech_it/2021/06/egais-ustanavlivaem-utm-420-na-debian-ubuntu.html

Статья актуальна и постоянно пополняется. Сейчас в ней не только то, как установить УТМ, но и как решить некоторые проблемы с памятью и пересобрать пакет со своими настройками, что актуально если УТМ у вас много.

​​А и Б сидели на трубе

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

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

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

Подключаюсь к его ПК через TeamViewer, запускаю SADP – это такая удобная утилита от Hikvision, которая видит камеры по MAC и позволяет цепляться к ним, менять сетевые настройки, ставить пароль и все такое прочее лишний раз не вставая с дивана.

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

Ну как-так, я же стандартный ставил. Ну а вот так, неверно и все!

Ладно, звоню другу, он берет стремянку, лезет, сбрасывает камеру кнопкой.

Все повторяется, снова неверный логин и пароль. Снова стремянка и сброс кнопкой.

Понимаем, что какая-то фигня. Открываем Блокнот, набираем пароль, но в SADP копирование пароля не работает, только ручками.

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

И тут вот наблюдаем изумительную картину: в SADP если была нажата клавиша А, то какую бы вы клавишу не нажали – следующая снова будет А.

Причем такой фокус проявляется только через удаленное подключение, локально все нормально. Отключились и снова подключили TeamViewer – снова стало все нормально.

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

​​VPN и сетевое окружение

Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?

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

Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?

Примерно также, как человек в лесу ищет другого человека.

Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»

А ему каждый активный узел отвечает: «есть, меня зовут Имярек»

Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.

Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.

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

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

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

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

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

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

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

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

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

Это снижает объем широковещания, но целиком проблему не снижает.

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

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

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

А для доступа к удаленным узлам используйте IP-адреса или доменные имена.

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

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

​​Резервные копии Active Direcitory

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

В чем причина? А причина в USN Rollback – главной страшилке системных администраторов былых времён. Сейчас получить USN Rollback все так же можно, но никаких особых последствий у вас не будет.

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

Каждое изменение метаданных AD снабжается специальным идентификатором контроллера домена - Invocation ID - и последовательным номером – USN.

Другие контроллеры, выполнив репликацию, запоминают этот идентификатор и USN, после чего при следующей репликации будут запрашивать объекты с USN указанного номера.

При USN Rollback у контролера уменьшается текущий максимальный номер USN, и он начинает создавать изменения, которые никогда не будут реплицированы, чем переводит базу AD в рассогласованное состояние.

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

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

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

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

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

Что касается восстановления контроллера через родной режим службы восстановления каталогов (вам понадобится резервная копия, сделанная службой Windows Server Backup), то в конце восстановления контроллеру меняют Invocation ID, что заставляет остальные контроллеры считать его новым контроллером в AD и начать репликацию с ним «с чистого листа».

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

В худшем, если бекап был сделан программой не умеющей восстанавливать KД (а именно менять Invocation ID), то вы потеряете контроллер и вам все равно придется настраивать его заново.

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

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

Но мы надеемся, что данной ситуации у вас не возникнет.

​​Чем отличаются DHCP Option 015 (DNS Domain Name) и DHCP Option 119 (Domain Search List)

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

Что такое плоское имя? Это имя компьютера из одного слова, например, SERVER-01 или PC-003.

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

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

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

В тоже время задачу разрешения имен призван решать DNS-сервер, но он не работает с плоскими именами, точнее DNS-клиент дополнит плоское имя до FQDN следующим образом:

SERVER-01.

Что обозначает домен первого уровня SERVER-01, аналогичный RU или COM. Естественно, такой зоны на вашем DNS-сервере найдено не будет и поиск закончится неудачей.

Поэтому нужно научить DNS-клиент правильно дополнять плоские имена до FQDN и для этого предназначена опция DHCP 015 (DNS Domain Name), которая задает имя домена используемое при разрешении имен на DNS-сервере. Также ее часто называют DNS Suffix.

Если мы передали в этой опции домен example.office, то любое плоское имя будет дополнено как:

SERVER-01. example.office.

После чего запрошенное имя будет легко разрешено обслуживающим зону DNS-сервером.

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

http://webserver-005/otchet.pdf

Где указанное плоское имя соответствует веб-серверу филиала на хуторе Гадюкино который использует домен example.gadykino.office.

Как быть в таком случае? Опция 015 не предусматривает передачу нескольких имен, хотя некоторые реализации DHCP-клиентов в Linux умеют разбирать строку, состоящую из нескольких значений.

Поэтому была введена опция DHCP 119 (Domain Search List), которая содержит список доменов используемых для разрешения имен, теперь мы можем передать в нем как example.office, так и example.gadykino.office.

DNS-клиент будет выполнять поиск в порядке следования доменов в списке, поэтому «родной» домен указывайте первым.

Таким образом опции 015 и 119 фактически выполняют одно и то же действие. Только 015 передает единственный домен, а 119 – список доменов.

Что будет, если опции 015 и 119 указаны одновременно? Стандарты не описывают данную ситуацию, поэтому все отдается на откуп конкретной реализации DHCP-клиента.

Общая рекомендация: указывать домен из опции 015 первым в списке доменов опции 119.

Какую из них использовать? Если домен поиска один, то используйте 015, это обеспечит наибольшую совместимость с оборудованием и ПО. Если несколько, то 119.

В доменных сетях от использования опций DHCP 015 и 119 лучше отказаться и настроить домены поиска через GPO используя политику Computer Configuration -> Administrative Templates -> Network -> DNS Client and open DNS Suffix Search List.

​​Окончание поддержки Windows Server 2012 R2

Сегодня, 10 октября, закончилась поддержка Windows Server 2012 R2. Настала пора планировать обновления и переезжать на новую версию. Актуальная версия серверной ОС на сегодня – это Windows Server 2022.

Следует помнить, что серверные версии Windows не поддерживали и не поддерживают бесплатное обновление между версиями и даже Server и Server R2 – это разные продукты.

Право на понижение версии (downgrade) дает возможность использовать с текущей лицензией версии на два выпуска ниже.

Т.е. Windows Server 2022 дает право использовать Windows Server 2019 и 2016.

Лицензии клиентского доступа CAL и удаленного доступа RDS CAL совместимы сверху вниз, т.е. CAL 2022 можно использовать для доступа к системам, работающим на любом выпуске Windows Server ниже 2022, а, например, CAL 2016 уже нельзя использовать для доступа к системам на новых выпусках Windows Server.

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

Теперь о том, как обновляться. Windows Server последних версий (начиная с далекой 2008) поддерживает обновление «на месте» (in place) или говоря привычным языком – поверх.

Некоторые, особенно бывалые админы, могут шарахаться от такого обновления как черт от ладана, но на самом деле это не так страшно, современные системы не перезаписывают системные файлы поверх, как это было до выхода NT 6 (Vista и Server 2008), а разворачивает новый, чистый образ, на который переносит настройки, программы и документы.

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

Обновляться «на месте» можно также на два выпуска вперед, т.е. с Windows Server 2012 R2 можно перейти на Windows Server 2016 или 2019, а для перехода на Windows Server 2022 нужно выполнить два последовательных обновления.

Единственный сценарий, в котором обновление «на месте» не рекомендуется – это обновление контроллеров домена, в этом случае лучше ввести в домен новые контроллеры, на новой версии ОС, а затем понизить и вывести из эксплуатации старые.

А вы уже готовы попрощаться с Windows Server 2012 R2?

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

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

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

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

​​О пользе систем управление конфигурациями или тайная жизнь ваших сетевых устройств

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

🔹 Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized

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

Но дело в том, что Oxidized – это не бекап, резервное копирование только одна из его функций. Гораздо более ценная и полезная – это система контроля изменений, основанная на Git.

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

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

Чтобы не быть голословными расскажем одну реальную историю.

Не так давно мы внедрили новому заказчику Oxidized и через некоторое время обнаружили что конфигурация некоторых роутеров меняется.

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

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

Таким вот образом почему-то работало автоматическое обнаружение часового пояса.

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

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

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

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

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

​​Netrunner 23 - манная каша со вкусом KDE

Не так давно мы рассматривали KDE Neon - дистрибутив от разработчиков KDE, которые предлагают пользователю интересное сочетание плавающих релизов KDE Plasma на базе стабильной платформы Ubuntu LTS, поэтому мы не могли пройти мимо другого аналогичного дистрибутива - Netrunner.

Их объединяет то, что также как и Neon, Netrunner находится под крылом Blue Systems GmbH - крупного спонсора KDE и бывшего главного спонсора Kubuntu.

Но впоследствии их пути разошлись и текущие выпуски Netrunner основаны на Debian.

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

https://interface31.ru/tech_it/2023/10/netrunner-23-mannaya-kasha-so-vkusom-kde.html

​​И снова про рекламу и донаты

Эта тема уже неоднократно поднималась на данном ресурсе и непременно будет подниматься вновь, так уж устроен человек.

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

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

Сегодня мы хотим показать другую сторону этой всей кухни – то, как создаются материалы и сколько времени это занимает.

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

Средняя техническая заметка для Telegram занимает 1-2 часа времени. Потому что нужно найти материал, проверить его, скомпоновать, упорядочить и придумать как уместить все это в 4000 символов.

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

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

Итого по нашему плану имеем 1,5 х 7 = 10,5 часов, полный рабочий день с переработкой. Это только на подготовку коротких заметок в канал.

Но основной контент мы по-прежнему размещаем на сайте. План – от 4 статей в месяц. А вот там все гораздо сложнее.

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

Развернуть систему, проверить все интересующие аспекты, сделать скриншоты – где-то еще часа два. Потому что проверить и посмотреть надо многое, но не все из этого попадет в статью.

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

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

Само написание обзора – час-полтора, затем вычитка, проверка орфографии, пунктуации, стилистики – еще полчаса.

Что имеем в сухом остатке? По минимуму 5,5-6 часов. На обзор, который читается за 5-10 минут. В этом, собственно, и смысл подобных материалов – коротко, но емко дать общую информацию. Полотно на десять экранов вниз с сотней картинок просто никто не будет читать.

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

Затем изучается документация, еще час-два. Потом стенд и кропотливая запись каждого действия.
Сделали? Разворачиваем стенд по новой и дословно воспроизводим записанное. Должны получить полное совпадение результата. В зависимости от сложности еще часа два -три.

Если документация скупа или что-то не получается, то начинается поиск и отладка, тоже часы, но мы их считать не будем.

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

Само написание текста, в зависимости от сложности оформления, еще несколько часов, от двух до четырех.

Итог? Опять по минимуму 9-10 часов, на одну статью.

Итого в месяц получаем 40-50 часов работы с контентом, это полноценная рабочая неделя (пяти или шестидневная).

Можно ли тащить такой объем на энтузиазме? Или донатах, которых за прошлый год набралось целых шесть с хвостиком тысяч рублей? Совмещая это с основной работой, семьей, бытом? Занимаясь этим регулярно, через «лениво» и «не хочу»?

Как минимум семья не поймет, а потом и сам сядешь и подумаешь: «А на фига оно мне надо? Может лучше в лес или на рыбалку?»

​​SMART атрибуты NVMe дисков

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

Ниже будем указывать атрибуты в форме ID Наименование RU (Наименование EN)

🔹 01 Критические предупреждения (Critical Warning) – флаг, указывающий на критические состояния накопителя, не является статическим, может изменять состояние динамически, возможные значения:

▫️0x01 – доступное свободное пространство упало ниже порогового значения
▫️0x02 – температура вышла за пороговые значения (как вверх, так и вниз)
▫️0x03 - надежность подсистемы NVM ухудшилась из-за значительных проблем, связанных со средой передачи данных, включая ошибки, снижающие надежность подсистемы NVM
▫️0x04 – накопитель перешел в режим только чтения
▫️0x08 – устройство энергозависимой памяти (DRAM) вышло из строя

🔹 02 Температура всего устройства (Composite Temperature) – средняя температура накопителя в градусах Кельвина, для перевода в градусы Цельсия необходимо вычесть из значения 273.15. Рекомендации о порогах температур задаются именно для этого значения.

🔹 03 Доступно резервных блоков (Available Spare) – процент оставшихся резервных блоков, в норме 100 и это значение будет уменьшаться

🔹 04 Критический остаток резервных блоков (Available Spare Threshold) - при падении запаса ниже указанного значения для этого поля контроллером будет сформировано событие.

🔹 05 Процент износа (Percentage Used) - показывает процент износа устройства согласно указанного производителем ресурса, 100% обозначает полный износ, значение может превышать 100, максимальное значение 255.

🔹 06 Всего прочитано данных (Data Units Read) - количество прочитанных блоков по 512 байт, единица означает тысячу прочитанных блоков.

🔹 07 Всего записано данных (Data Units Written) - количество записанных блоков по 512 байт, единица означает тысячу записанных блоков.

🔹 08 Количество команд чтения (Host Read Commands) – количество команд чтения, выполненных контролером.

🔹 09 Количество команд записи (Host Write Commands) – количество команд записи, выполненных контроллером

🔹 10 Время занятости контроллера (Controller Busy Time) – время, которое контроллер обрабатывал команды ввода-вывода или когда в очереди находились запросы. Значение представлены в минутах.

🔹 11 Количество включений питания (Power Cycles) – счетчик включений накопителя

🔹 12 Количество отработанных часов (Power On Hours) – общее время работы накопителя в часах, учитывается также время нахождения в режимах энергосбережения

🔹 13 Небезопасных выключений (Unsafe Shutdowns) – количество выключений, когда питания накопителя было отключено прежде, чем он получил от системы уведомление о выключении питания

🔹 14 Количество неисправимых ошибок (Media and Data Integrity Errors) – счетчик неисправимых ошибок ECC, вычисления контрольных сумм CRC или несоответствия LBA

🔹 15 Записей об ошибках в журнал (Number of Error Information Log Entries) – количество записей об ошибках, произведенных в журнал контроллера

🔹 16 Время работы при высокой температуре (Warning Composite Temperature Time) – время, в минутах, которое накопитель работал с превышением порога температуры

🔹 17 Время работы при критической температуре (Critical Composite Temperature Time) - время, в минутах, которое накопитель работал с превышением критического порога температуры

🔹 18 Термодатчик 1 (Temperature Sensor 1) – первый сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего контроллер.

🔹 19 Термодатчик 2 (Temperature Sensor 2) – второй сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего NAND.

​​Стандартные 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 👻👻👻

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