Балансировка и высокая доступность OpenVPN

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

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

Эту ситуацию можно попробовать решить «малой кровью» спешно не перекраивая всю инфраструктуру и не перенастраивая клиентов.

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

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

А затем в конфигурационном файле просто указываем:

remote ovpn1.example.com
 remote ovpn2.example.com
 remote ovpn3.example.com

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

remote-random

Время переключения задается опцией:

resolv-retry 60

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

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

Как исправить утечку памяти службы Windows Push Notifications в Windows 10/11

Пользователи Windows 10/11 могут заметить, что вся доступная системе память куда-то исчезла. Виновником такой утечки может являться служба WpnUserService_xxxxx, где xxxxx – уникальный идентификатор службы.

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

WpnUserService – это служба Windows Push Notifications User Service отвечающая за обработку локальных push-уведомлений. Вы можете ее завершить или отключить, но это сработает только в текущем сеансе, при следующем входе в систему экземпляр службы будет создан заново.

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

Чтобы устранить проблему перезагрузите систему в безопасном режиме и перейдите в расположение:

%LOCALAPPDATA%\Microsoft\Windows

Где переименуйте или удалите папку Notifications. При следующем входе в систему база уведомлений будет создана заново.

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

☝️ Контроллер домена всегда выключает кеширование записи на тот физический диск где находится база AD.

При совмещении роли контроллера с ролями требующими дисковой производительности: сервер СУБД, сервер 1С, Exchange и т.д. вы получите на выходе жесткие тормоза. Ну или придется городить костыли.

Поэтому всегда выносите контроллер на отдельный ПК или виртуалку!

VPN-протоколы, степени риска

Не так давно, в связи с потребностями наших заказчиков мы провели достаточно объемное исследование на тему рисков использования VPN-протоколов для использования их в корпоративных целях и хотим поделиться некоторыми результатами.

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

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

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

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

🔴 L2TP/IPsec – риски крайне высокие, сигнатуры выгружены для блокировки, кроме того, протокол обладает крайне низкой устойчивостью, есть проблемы в сетях мобильных операторов, проблемы нескольких клиентов из-за одного NAT и т.д.

🟠 IKEv2/IPsec – риски высокие, UDP-сигнатуры прекрасно видны, сам протокол также широко использовался в известных целях. Устойчивость высокая, стабильно работает в сетях различных операторов, но также имеет высокую сложность настройки и отладки.

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

🔴 WireGuard – риски очень высокие, легко детектируется и активно блокируется. Устойчивость высокая, но при этом имеет повышенные накладные расходы на администрирование в корпоративной среде.

🟢 SSTP – риски ниже среднего, это объясняется тем, что протокол проприетарный и в основном применение ограничено экосистемой Windows, ну и, пожалуй, Mikrotik. Для указанных целей практически не используется. Устойчивость высокая, практически не отличим от HTTPS, но при необходимости легко детектируется. Работает даже там, где заблокирован практически весь интернет.

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

🟠 GRE/IPIP – риски низкие, устойчивость также низкая, имеют проблему прохождения NAT, не работают в сетях мобильных операторов, небезопасны. IPIP архитектурно ограничен только IP-трафиком.

🟢 IPsec – риски низкие, в основном используется для корпоративных и магистральных коммуникаций. Устойчивость выше средней, но также присутствуют требования к сторонам соединения (белые адреса и т.д.). Сложность настройки и отладки – крайне высокая, требует специальных знаний и навыков.

🟢 GRE/IPIP over IPsec – риски низкие, устойчивость выше средней. Внешне это тот же IPsec со всеми плюсами и минусами. Внутри привычные GRE/IPIP туннели. Сложность эксплуатации выше средней из-за присутствия IPsec, но значительно ниже, чем у чистого IPsec.

👉 Исходя из вышесказанного для целей удаленного доступа (Road-Warrior) рекомендуются SSL-VPN решения, такие как SSTP или OpenConnect, последний очень хорошо впишется в корпоративную сеть как полноценная замена OpenVPN с возможностью централизованного управления настройками клиентов.

Для соединения площадок (Site-to-Site) следует предпочитать решения на базе IPsec, наилучшим вариантом здесь будет GRE over IPsec, который сочетает сильные стороны IPsec с понятной сетевой моделью туннелей GRE, основанной на классической маршрутизации, а не на политиках.

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

Используем grep для поиска в файлах и потоках

Любой Linux администратор сталкивался с командой grep, которая используется для поиска строк по шаблону в стандартных потоках и текстовых файлах.

Изначально grep был написан одним из основателей UNIX Кеном Томпсоном, когда его начальник Дуглас Макилрой попросил его написать инструмент «для поиска чего-нибудь в файлах». Название утилиты происходит от global regular expression print (глобальный вывод регулярных выражений)

Самый частый сценарий использования grep, когда нам нужно отфильтровать поток ввода-вывода, например:

dpkg -l | grep gimp

Также он может работать и с файлами, хотя многие используют совершенно излишнее:

cat file.txt | grep mystring

В то время, когда можно просто использовать:

grep mystring file.txt

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

▫️A (after) – выводит указанное число сток после вхождения
▫️B (before) – выводит указанное число строк до вхождения
▫️С (context) – выводит указанное число строк до и после вхождения.

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

grep -A5 mystring file.txt

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

Например:

grep -no mystring file.txt

Выдаст:

5:mystring
9:mystring
25:mystring

Также grep умеет искать по нескольким файлам сразу, в этом случае перед выводом искомой строки будет указано имя файла, если вам нужно вывести только имена файлов, в которых найдены вхождения используйте ключ -l:

grep -l mystring file.txt file1.txt file2.txt file3.txt

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

Для того, чтобы игнорировать регистр символов предназначен ключ -i, а ключ -v инвертирует шаблон запроса, так команда:

grep -v mystring file.txt

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

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

grep -E ^((8|\+7)[\- ]?)?(\(?\d{3}\)?[\- ]?)?[\d\- ]{7,10}$ file.txt

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

В этом месте читатели могут вспомнить утилиту egrep, но в настоящий момент она, как и fgrep, объявлена устаревшей и лучше отвыкать от ее использования.

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

Кстати, grep -F – это полная противоположность grep -E, данный ключ предписывает игнорировать метасимволы и подстановочные данные и будет искать строку как есть:

Например:

grep -F 2*(x+y)^2 file.txt

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

Как обустроить современный корпоративный VPN

Сегодня многие пользователи сталкиваются со сложностями в работе VPN-соединений благодаря заботе о нас одного уважаемого ведомства.

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

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

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

Тот же Cloud.ru дает неплохую виртуалку бесплатно в рамках free tier, все что вам останется – это купить белый IP-адрес, который обойдется примерно в 150 руб./мес.

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

Таким образом наша схема приобретает законченные очертания. Приобретаем виртуалку в крупном отечественном датацентре и разворачиваем там VPN-сервер для доступа удаленных сотрудников.

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

Задача выполнена. Удаленные клиенты соединяются с доверенным облаком, блокировки которого гораздо менее вероятны, нежели блокировки офисного адреса, а офис общается с удаленной площадкой по туннелю IPsec, который также имеет крайне невысокий риск блокировки.

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

Как получить кучу проблем на ровном месте и ничего не понять

Прочитал сегодня за утренней чашкой кофе интересную и поучительную статью на Хабре:

✅ Мой Хоррор: Как лишиться доступа к собственной инфраструктуре, расположенной в РФ

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

Поэтому снова пройдемся по списку типовых ошибок.

1️⃣ Самая критичная – все яйца в одной корзине, т.е. вся инфраструктура завернута на единственный домен. Так делать не надо. Домены нынче стоят копейки, поэтому для критической инфраструктуры (DNS, почта и т.д.) обязательно отдельный домен, желательно у другого регистратора и на другие учетные данные.

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

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

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

2️⃣ Вторая ошибка – размещать на основном домене потенциально опасные сервисы, а их там висело ровно три. Кроме легального с точки зрения регулятора VPN к своей инфраструктуре там же было два аналогичных сервиса выглядевших «нелегально», а именно туннели за пределы страны.

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

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

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

3️⃣ Третья ошибка – отсутствие дополнительной точки входа в инфраструктуру. Если мы размещаем в ДЦ свой сервер, то хотя бы об IP-KVM позаботиться не мешало бы. А также поднять (купить) там же отдельную виртуалку на отдельном IP-адресе на всякий пожарный случай. Поднять исходящий канал оттуда куда-нибудь к себе или к третьей площадке.

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

4️⃣ И, нестареющая классика – левые или неактуальные данные владельца домена. И ладно, если это домен технический, как говорится – помер дед Максим… Но если на домен завязана инфраструктура, то он должен быть в статусе VERIFIED и никак иначе.

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

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

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

Блокировки 2026, путь к выживанию. Начало

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

👉 Начнем с блокировки домена, как это происходит и за что может прилететь.

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

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

1️⃣ Нарушение авторских и смежных прав – на первый взгляд тут все понятно, явная пиратка – путь к проблемам. Но не все так просто. Понравилась вам фотография, свободно размещенная в интернете. Вы ее скопировали и использовали на своем сайте как КДПВ (картинка для привлечения внимания).

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

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

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

У одного моего знакомого так заблокировали Youtube-канал (давно, еще до всех этих событий) за видео, где он сравнивал оригинальные картриджи HP с аналогами и пришел к выводу, что нет смысла переплачивать за оригинал.

3️⃣ Информация с возрастными ограничениями. Уже 16 лет как существует N 436-ФЗ "О защите детей от информации, причиняющей вред их здоровью и развитию". Многие считают, что это их не коснется, а зря.

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

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

4️⃣ Запрещенная к распространению информация. А вот тут все гораздо серьезней, здесь кроме блокировки есть шанс получить реальную административку со штрафом, а то и чего похуже.

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

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

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

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

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

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

Визуальный калькулятор подсетей

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

Обычно это решается графическими построениями на бумаге или в Excel, но есть способ лучше – использовать Visual Subnet Calculator, открытый продукт, распространяющийся под лицензией MIT.

Проще и быстрее всего запустить его в Docker:

docker run -d -p 8081:8080 --name visualsubnetcalc ckabalan/visualsubnetcalc:latest

Теперь открываем http://myhost:8081 и начинаем работать. Сначала задаем желаемую сеть верхнего уровня и начинаем делить ее мышкой. Нажатие на сеть нижнего уровня делит ее на две равных подсети, нажатие на сеть верхнего уровня сворачивает все подсети под ней.

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

Утилита имеет четыре режима работы: стандартный и специализированный расчет для AWS, Azure и Oracle Cloud.

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

Контейнеры на Mikrotik

Функция запуска контейнеров формата OCI (Open Container Initiative) была добавлена в RouterOS 7 сравнительно недавно, но вызвала достаточно большой ажиотаж.

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

‼️ Начнем с безопасности. Разработчики предупреждают:

▫️Уровень безопасности устройства с RouterOS равен уровню безопасности того, что запускается в контейнере.

▫️При использовании контейнеров никаких гарантий безопасности не предоставляется.

Уязвимости в контейнере могут привести к получению root-доступа к устройству, а если вредоносный код будет внедрен в RouterBOOT, то вам не поможет даже Netinstall.

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

Пойдем дальше, контейнеры поддерживаются на устройствах с архитектурами arm, arm64 и x86, накопитель для размещения контейнеров должен поддерживать скорость не менее 100 МБ/с и не менее 10k IOPS, хотя сегодня это не проблема, справится любой SATA SSD.

👉 Но если мы посмотрим на роутеры начального уровня (да и не совсем начального), то увидим, что ряд из них не имеет на борту USB, чем сразу выпадают из подходящих для наших целей, а остальные имеют всего 1 ГБ оперативной памяти.

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

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

С контейнерами дело немного получше, но 1 ГБ – это всего 1 ГБ, что по нашим временам крайне мало. Поэтому если вы хотите запустить на ROS контейнер, это должно быть обосновано.

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

Это нормально и уместно. Но когда некоторые товарищи пытаются развернуть там тот же Nextcloud – это ускользает от нашего понимания. 🤦‍♀️

Если вам действительно нужен хост под контейнеризацию, то купите одноплатник – «малинка», «бананка», «репка» - их масса. Или мини-ПК на N100/150, там вообще раздолье по ресурсам.

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

И что это было?

Третьего дня произошла одна не очень приятная история. Один наш заказчик собирался открыть еще одно направление бизнеса. Под это дело еще в далеком 2023 году закупил технику.

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

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

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

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

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

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

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

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

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

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

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

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

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

Виртуализация, контейнеризация, докеризация

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

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

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

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

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

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

2️⃣ Контейнеризация LXC на первый взгляд похожа на виртуализацию, вам также предоставляется как бы отдельный экземпляр операционной системы. Но мы не зря сказали «как-бы».

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

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

На самом деле контейнер предоставляет нам системное окружение выбранной ОС, работающей на ядре хоста и с ресурсами хоста.

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

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

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

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

3️⃣ Теперь перейдем к докеризации. Докер представляет собой контейнер на уровне приложения. Накладные расходы минимальны – докер приложение исполняется на хосте в рамках установленных лимитов.

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

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

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

👆 Что в итоге выбрать – смотрите сами. Все указанные технологии достаточно зрелые, каждая их них имеет свои особенности и недостатки. А грамотный администратор всегда умеет играть от сильных сторон решений.

Как в Linux узнать скорость USB-портов и их текущий режим работы

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

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

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

Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:

lsusb -t

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

Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно:

▫️12М - USB 1.0
▫️480M – USB 2.0
▫️5000M - USB 3.2 Gen 1 (USB 3.0)
▫️10000M - USB 3.2 Gen 2 (USB 3.1)
▫️20000M/x2 - USB 3.2 Gen 2x2

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

Настраиваем таймеры systemd вместо заданий cron

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

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

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

К systemd можно относиться по-разному, но нельзя отрицать, что данная подсистема вывела на новый уровень управление службами в системе Linux и сделала эту задачу гораздо более простой и удобной.

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

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

Да, сron многим привычен, но если рассматривать его сильные и слабые стороны, то в плюсы ему можно записать только простоту, все остальное - обратная сторона медали от этой простоты. Что умеет cron? Запускать задачи по расписанию и уведомлять администратора, если такой запуск завершился неудачей.

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

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

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

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

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

Здесь кроется существенное отличие от cron, запись которого содержит и расписание, и действие, в systemd эта логика разделена: таймер отвечает за управление сервисом, который уже выполняет действие. Для таймеров используются юниты с расширением .timer, в то время как для служб с расширением .service. Чтобы управлять каким-либо сервисом вам понадобится создать для него одноименный таймер.

✅ Читать далее

🚀 Устали от рутины в Python? Автоматизируйте задачи с GPT за 90 минут

Собираем и забираем себе в пользование рабочее решение по практической автоматизации на стыке Python + ИИ.

🕑 Завтра | 12:00 или 19:00 (МСК)
на бесплатном вебинаре покажем, как с помощью GPT превращать Python-скрипты в умные сервисы.

За 90 минут вы:
🔹 разберёте базовую архитектуру «умных» сервисов и поймёте, как они устроены
🔹 увидите, как подключаться по API к GPT-моделям и интегрировать их в Python-проекты
🔹 получите готовый каркас автоматизационной системы, который можно забрать себе и дальше развивать: усложнять сценарии, расширять функциональность и автоматизировать рабочие задачи

Кому будет полезно:
— Python-разработчикам
— Data / ML-инженерам
— ИТ-руководителям и тимлидам
— всем, кто хочет применять GPT в реальных проектах

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

🔗 Регистрируйтесь на вебинар
#реклама
О рекламодателе

Монтирование файловых систем при помощи systemd

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

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

И вот тут нам на помощь снова приходит systemd, предлагая современные методы монтирования файловых систем.

✅ Читать далее