Всегда свежие Sysinternals, автоматизируем процесс

Днем мы рассказали о сервисе Sysinternals Live, позволяющем онлайн получить новейшие версии утилит из состава Sysinternals Suite.

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

Скачивать руками каждый раз тоже не сильно хочется, так почему бы не автоматизировать эту задачу? Мы написали простой скрипт на PowerShell, который при запуске соединяется с сервисом Sysinternals Live и синхронизирует его содержимое с локальной папкой tools в директории запуска скрипта.

В комплекте вместе со скриптом Sync-Sysinternals.ps1 идет пакетный файл run-sync.bat, который позволяет быстро запустить скрипт вручную.

Но нам более интересно его выполнение по расписанию, для этого создадим в Планировщике новое задание, допустим с именем Синхронизация Sysinternals Tools.

Выбираем условия запуска:

▫️ Выполнять только для зарегистрированного пользователя
▫️ Выполнять вне зависимости от регистрации пользователя

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

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

▫️ Действие: Запустить программу
▫️Программа или сценарий: powershell.exe
▫️Аргументы: -ExecutionPolicy Bypass -File "F:\VIBE\sysinternals_live\Sync-Sysinternals.ps1"
▫️Рабочая папка: C:\ADM

Сохраняем задание, размещаем по указанному пути (в нашем примере C:\ADM) файл скрипта и запускаем задание вручную. Если вы все сделали правильно – начнется синхронизация.

Быстро выполнить все тоже самое можно командой:

schtasks /create /tn "Sync-Sysinternals" /tr "powershell.exe -ExecutionPolicy Bypass -File \""C:\ADM\Sync-Sysinternals.ps1\"" /sc DAILY /st 02:00 /ru "%USERDOMAIN%\%USERNAME%" /f /rl HIGHEST

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

Файлы можно скачать в комментариях 👇👇👇

📌 Приглашаем на вебинар

«Дефицит ресурсов — не повод для хаоса: как выстроить техподдержку 220 торговых точек всего за 6 недель»

🗓 4 декабря, 11:00

Будет полезно, если:

— Сервис перегружен и нужно наладить его работу с минимумом затрат

— Требуется расширить набор функций и метрик без долгих и дорогих доработок service desk

↓ ↓ ↓

На примере реального кейса спикеры ITSM 365 и SMARTER расскажут:

— Как за 6 недель перевести сотни торговых точек с почты и Excel в сервис деск

— Как объединить команды торговой сети, подрядчиков и вендоров в одной системе

— Как создать в service desk структуру обслуживания, связав заявки с оборудованием, складами и поставщиками

— Витрина услуг, кастомизация заявок, согласование и оценка работ, настройка отчетов и дашбордов — какие функции гарантированно разгрузят ваш сервис.

Регистрируйтесь по ссылке 🔗

#реклама
О рекламодателе

1С в контейнерах. Практическое руководство – 1

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

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

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

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

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

При контейнеризации мы будем исходить из соображений: одна служба – один контейнер. Таким образом у нас напрашивается минимум три контейнера: Сервер 1С:Предприятие, PostgreSQL и веб-сервер.

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

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

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

Скажем, сервер 1С в контейнере с Debian 13 не будет работать лучше, чем с Debian 12, а вот головной боли добавить может и это будет именно ваша головная боль, потому что платформа не поддерживается. У вас даже багрепорт не примут, по этой самой причине.
Но основной смысл перехода от монолита к контейнерам – это, конечно же, гибкое управление ресурсами. Оно же становится основной сложностью для начинающих. Начнем с процессора.

Платформа 1С:Предприятие уровня ПРОФ ограничена по лицензионным соображениям 12 процессорными ядрами (не важно физическими или виртуальными). Таким образом любой современный процессор предоставляет нам ядер больше, чем требуется для 1С.

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

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

При этом не забывайте про базовые настройки железа, рекомендованные для серверов 1С. В частности, это включение Turbo-bust на все ядра, отключение режимов энергосбережения процессора C-State (выключаем или выбираем C0), а также отключаем управление питанием и частотой процессора P-states (выбираем наиболее производительный режим P0).

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

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

1С в контейнерах. Практическое руководство – 2

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

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

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

1️⃣ Начнем с сервера 1С:Предприятие. Цифра, на которую следует ориентироваться – это 1-2 ГБ оперативной памяти на сеанс, можно взять среднее значение 1,5 ГБ и не сильно ошибиться. Понятно, что это среднее значение, реальные цифры могут изменяться от задач.

На одном из наших рабочих серверов с 1С:Бухгалтерия мы получили среднее значение 1,19 ГБ на сеанс, при этом были сеансы потреблявшие 400-700 МБ памяти, а были с потреблением 3-3,5 ГБ. Все зависит от роли и задач пользователя.

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

Отдельного внимания стоят сеансы через веб-сервер, не важно используется для работы тонкий клиент или веб-клиент в браузере. В целях повторного использования (так как создание сеанса – дорогая операция) сеанс сохраняется в течении 20 минут после отключения пользователя.

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

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

2️⃣ И если с сервером 1С все более-менее ясно, то PostgreSQL представляет собой более сложную систему. Любой сервер СУБД имеет тенденцию утилизировать всю доступную память. Но на самом деле достаточно чтобы в нее помещались горячие данные, потому как база 1С:Предприятие может содержать большое количество нормативно-справочной или архивной информации.

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

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

 Размер ОЗУ = Размер базы / 4 + 2 ГБ (но не менее 4 ГБ)

Еще раз напомним – эта формула применима только к типовым базам 1С:Предприятие с нагрузкой ниже среднего.

Для примера мы проверили несколько наших серверов:

🔹 Сервер №1

▫️Размер базы – 33 ГБ
▫️Размер ОЗУ по формуле – 10,25 ГБ
▫️Выделенный размер ОЗУ – 12 ГБ
▫️ Реальное потребление – 8,5 ГБ


🔹 Сервер №2

▫️Размер базы – 28 ГБ
▫️Размер ОЗУ по формуле – 9 ГБ
▫️Выделенный размер ОЗУ – 8 ГБ
▫️Реальное потребление – 3 ГБ

Основное различие баз – в количестве активных пользователей и операций, хотя и там и там установлена типовая 1С:Бухгалтерия.

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

3️⃣ Веб-сервер в клиент-серверном сценарии особых ресурсов не потребляет, так как занимается сугубо проксированием запросов и ресурсы ему можно выделить по остаточному принципу. В расчетах можно исходить из 2-10 МБ на сеанс.

4️⃣ На самом Proxmox, если вы используете ZFS – обязательно настройте выделение памяти для ARC исходя из формулы:

1 ГБ для хоста + 4-5 ГБ на 1 ТБ хранилища (но не менее 3 ГБ)

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

Спрашивают - отвечаем

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

Начнем с того, что бекап – это не просто «бери больше – кидай дальше», а целый комплекс мероприятий. Мы об этом уже писали, напомним еще раз: https://interface31.ru/tech_it/2021/03/kak-pravil-no-organizovat-rezervnoe-kopirovanie-i-spat-spokoyno.html

1️⃣ Если коротко. Самый первый бекап должен быть в "шаговой доступности", в формате позволяющем наиболее быстро восстановиться из него и, желательно, без сжатия. Можно, вопреки мемам, хранить на том же самом сервере.

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

3️⃣ Третья копия - в удаленной локации. Облако, NAS дома в чулане и т.д. Это на случай, когда все плохо и первые два бекапа недоступны или уничтожены. Чаще всего они вам не понадобятся, но иметь такую копию нужно.

👆 А теперь о том, чего делать не надо.

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

А какая задача бекапа? Быстро восстановить рабочую копию данных. При этом стоимость бекапа (а все имеет свою стоимость) не должна превышать стоимость ущерба от потери рабочей копии данных. Грубо говоря, тратить 1000 руб. на замок, чтобы закрыть лопату за 100 руб. - занятие лишенное всякого смысла.

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

❗️ И еще. Не путайте бекапы с архивами. У них разное назначение и архивы тоже нужно бекапить!

Приведет ли ИИ к деградации программирования и обесцениванию профессии программиста?

Очередная часть, начало здесь: https://news.1rj.ru/str/interface31/5303

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

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

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

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

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

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

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

Это как-то повлияло на процесс подготовки инженеров? Создало непреодолимые препоны для входа в профессию? Нет, просто знание CAD и умение в нем работать стало базовым требованием для специалиста. И сегодня от инженера требуется несколько больше, чем просто уметь чертить и читать чертежи.

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

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

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

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

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

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

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

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

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

И это про любую специальность. Не только программирование.

​​Как правильно обновлять 1С

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

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

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

И тут появляется «народный умелец», который говорит, что все это фигня и он быстро и недорого обновит базу из последнего CF и будет все тоже самое, даже лучше. Он сто раз так делал.

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

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

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

Допустим в обновлении А добавлен какой-то новый реквизит и при первом запуске обработчик обновления его заполняет по какому-либо алгоритму.

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

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

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

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

А все почему? Да потому что ожидает увидеть где-то определенное значение, но не видит его. И хорошо, если пустое значение там допустимо. Ну просто будет не попадать куда-то то, что попадать должно.

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

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

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

А кто виноват? Ну конечно же 1С, ведь это все знают, он косая, кривая и никогда нормально не работает.

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

Самохостинг

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

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

Поэтому, когда мы говорим о хостинге, то основным требованием к нему является доступность. У хостеров одним из основных параметров является SLA (Service Level Agreement или соглашение об уровне сервиса), который регламентирует допустимое время простоя и обычно его значения начинаются с 95-99%.

На самом деле это достаточно большие цифры, так 95% допускает простой 18,25 суток в год, а 99% - 3,65 суток.

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

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

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

Ок, давайте просто прикинем. Сервер из неоткуда не берется, его надо купить. Давайте прикинем стоимость платформы на N100 с дисками на 1 ТБ.

Такая машинка по актуальным ценам конца ноября 2025 года обойдется плюс-минус в 40 000 рублей.

Определим ей срок полезного использования в пять лет. В результате получим стоимость владения (не считая затрат на содержание) в размере 8 000 рублей в год или 667 рублей в месяц.

1 ТБ на Яндекс Диске стоит без скидок 191 руб./мес., со скидками 89 руб./мес. и голова не болит.

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

При этом у вас больше не болит голова насчет всей этой кухни. А болеть там на самом деле есть чему.

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

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

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

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

Ну или это будет стоить совсем других денег…

При этом не забываем, что наше оборудование коптит небо, расходует ресурс, стареет, что рано или поздно потребует его замены. У хостера это делает сам хостер, вы просто оплачиваете услугу по тарифу.

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

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

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

Но это уже не про широкий доступ и вопрос доступности тут вообще может уходить на задний план.

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

​​Диагностика правил брандмауэра Mikrotik

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

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

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

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

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

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

Теперь о том, как убирать и добавлять критерии. Есть критерии общие, а есть частные. Общими являются те критерии, под которые попадают большинство проходящих правило пакетов, например интерфейсы входа и выхода.

Потом идут более узкие критерии, скажем, протокол и еще более узкие, такие как порт.

Поэтому убирать критерии начинаем частных к широким, добавляем наоборот.

А если ничего не помогает? То смотрим в правило, после которого перестало работать, возможно неверные критерии выставлены именно в нем.

Другая ситуация - все работает как надо, а счетчик правила не работает. В этом случае выше срабатывает какое-то обобщающее правило.

В этом случае делаем копию правила и передвигаем его наверх до тех пор, пока не заработает счетчик. После чего анализируем правило ниже.

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

Пожароопасность ПК

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

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

Поэтому будем опираться на статистику, нам удалось при помощи ИИ найти и обобщить статистику пожарной службы США за последние несколько лет.

Начнем со специализированных IT-помещений, не являющихся дата-центрами. За год в среднем регистрируется 1 259 пожаров, из которых 78% связаны с ИБП. Именно ИБП является наиболее пожароопасным элементом инфраструктуры.

По мере перехода с кислотно-свинцовых на литий-ионные батареи количество инцидентов с ИБП выросло на 66%. При этом 30% случаев вызвано возгоранием собственно батарей.

Согласно опросу страховой компании Aviva, 54% предприятий сталкивались с инцидентами, связанными с литий-ионными батареями (перегрев, искрение, задымление), а 13% пережили полноценные пожары.

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

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

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

Что касается домашних пожаров, по статистике все той же пожарной службы США по причине электроприборов ежегодно происходит 45 000-55 000 пожаров, что составляет 4.9% всех жилых пожаров и вторую по величине причину возгораний.

Первая причина – кухонное оборудование - 165,600 пожаров, 46%.

Так как бесперебойники дома явление достаточно редкое, то пальму первенства в своей категории держат удлинители – 4 600 домашних пожаров ежегодно или 10% в своей группе. Основные причины возгорания удлинителей – перегрузка по мощности, последовательное включение удлинителей только увеличивает вероятность пожара.

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

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

Блоки питания тоже горят, хотя достаточно редко - 120-150 пожаров в год (или 0,3% в своей категории). Но сбрасывать их со счетов тоже не стоит – раз в год и палка стреляет.

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

Но в целом вероятность пожара от ИБП или удлинителя куда более реальна.

Также довольно интересна статистика пожарной службы Великобритании, 25% пожаров на рабочих местах в офисах связана с возгоранием ПК. При этом статистика не раскрывает более подробную причину пожаров: ИБП, удлинитель, блок питания или еще что-либо.

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

Вышло обновление Proxmox Backup Server 4.1

Раньше была поговорка - до первого сервис-пака не обновляем. Сегодня ситуация поменялась не сильно. Обновлять продуктивные среды имеет смысл только после первого минорного обновления.

Что нового?

▫️ Осуществлена синхронизация с пакетной базой дистрибутива Debian 13.2. Обновлены ядро Linux 6.17.2 и OpenZFS 2.3.4.

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

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

▫️ Добавлена предварительная поддержка ограничения интенсивности обмена данными с хранилищами на базе протокола AWS S3 для снижения негативного влияния передачи резервных копий на другие задачи.

▫️ Web-интерфейс оптимизирован для работы на экранах с высоким разрешением.

▫️ Реализована поддержка автоматического отмонтирования внешних подключаемых хранилищ после завершения синхронизации данных (систему теперь можно настроить так, чтобы при подключении накопителя автоматически запускался процесс синхронизации данных, а после окончания синхронизации накопитель автоматически отмонтировался).

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

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

​​Устанавливаем OpenVPN в LXC-контейнер

Контейнеры LXC пользуются заслуженной популярностью и широко используются в системе виртуализации Proxmox.

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

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

Открываем на хосте виртуализации /etc/pve/lxc/ctid.conf, где ctid.conf – конфигурационный файл нужного контейнера и добавляем в него следующие две строки:

lxc.mount.entry: /dev/net dev/net none bind,create=dir
lxc.cgroup2.devices.allow: c 10:200 rwm

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

Особенности установки УТМ ЕГАИС на Debian 13

Сегодня попробовали установить УТМ ЕГАИС на свежий дистрибутив Debian 13. Сама установка не вызывает особых сложностей и ее можно выполнить по нашей статье:

🔹 ЕГАИС. Устанавливаем УТМ 4.2.0 на Debian (Ubuntu)

При этом, вместо libncurses5:i386 следует устанавливать libncurses6:i386, а библиотека SSL называется libssl3t64 и скорее всего будет установлена по умолчанию.

Сам пакет u-trans тоже ставится без особых проблем, запускается, но не работает. Если вы откроете лог, то увидите, что УТМ не может обнаружить ключ. Странно, ведь инсталлятор увидел Рутокен и инструменты диагностики тоже его видят.

Поэтому читаем лог дальше и находим интересные записи:

/opt/utm/lib/librtpkcsllecp.so: невозможно задействовать исполняемый стек, как требует разделяемый объект

Это значит, что библиотека требует наличия executable stack (исполняемый стек), который отключен в Debian 13 по соображениями безопасности (а также в Ubuntu, начиная с 25.10).

👆 Включить данную технологию не представляется возможным (во всяком случае без глубокого изменения системы), поэтому можно считать, что УТМ ЕГАИС несовместим с Debian 13 и грядущей Ubuntu 26.04 LTS.

😉 Ну если, конечно, разработчики Росалкогольтабакконтроль не перепишут программу, но надежды на это призрачные, с учетом того, что u-trans для Linux до сих пор 32-битное приложение.

С другой стороны, у нас все-таки Linux и каждый тут сам кузнец собственного счастья. Указанные в ошибках библиотеки являются библиотеками PKCS11Lib от Рутокен и поставляются вместе с пакетом УТМ.

Поэтому мы можем заменить их на более современные версии библиотек от Рутокен, которые не требуют executable stack.

Скачать их можно на https://download.rutoken.ru в разделе /Rutoken/PKCS11Lib/Current/Linux/x32/, просто качаем librtpkcs11ecp.so.

Для этого перейдем в домашнюю папку и скачаем библиотеку через wget, в нашем случае это последняя на сегодня версия, вам же потребуется уточнить версию библиотеки:

cd ~ 
wget  https://download.rutoken.ru/Rutoken/PKCS11Lib/Current/Linux/x32/librtpkcs11ecp.so

Затем останавливаем УТМ, заменяем необходимые библиотеки (их там две копии) и снова запускаем УТМ:

supervisorctl stop utm
cp -v librtpkcs11ecp.so /opt/utm/lib/librtpkcs11ecp.so
cp -v librtpkcs11ecp.so /opt/utm/lib/librtpkcs11ecp-replica.so
supervisorctl start utm

После чего все запускается и отлично работает. Посмотреть лог УТМ в реальном времени можно командой:

tail -f /opt/utm/transport/l/transport_info.log

Но данное действие вам придется выполнять всякий раз после переустановки или обновления УТМ.

❗️Также обратите внимание, что данный способ проверен только с токенами Рутокен и работа с JaCarta не проверялась и не гарантируется.

👉 Кроме того, добавим – непосредственной необходимости ставить УТМ ЕГАИС на Debian 13 в текущий момент нет, сервис это сугубо внутренний и при необходимости может эксплуатироваться даже на устаревших версиях системы.

Автоматически обновляем списки адресов Cloudflare на Mikrotik

Что такое Cloudflare – рассказывать не надо (надеюсь) и для чего нам могут потребоваться всегда актуальные списки его адресов – тоже.

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

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

Сам список секрета не представляет и Cloudflare его официально публикует на страничке https://www.cloudflare.com/ips-v4

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

Скрипт в комментариях, добавляем в System – Scripts, проверяем. Если все работает – добавляем в планировщик System – Scheduler и пусть от там тихо, скажем, раз в неделю данный список проверяет и обновляет.

👇👇👇