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

Роутеры Mikrotik и Wi-Fi В комментариях некоторые читатели удивились, мол почему мы назвали «народными» роутеры серии L009, ведь есть же практически такой же по цене hAP ax3 у которого двухдиапазонный современный Wi-Fi. Да, это так, только вот практического толку в этом немного и это давно ни для кого не секрет. Решения Mikrotik в области беспроводной связи всегда отличались странным подходом и крайне специфичной реализацией. И если можно сказать, что роутеры латышам удались отлично, то также честно можно сказать, что с Wi-Fi у них (не считая мосты) – полный провал. Нет, если вам нужно просто покрыть некоторое помещение, чтобы телефончики с него выходили в интернет, но не более - Mikrotik подойдет, в остальном – лучше даже не пытайтесь. В устройствах «классической» линейки вызывало недоумение само применяемое оборудование, которое было устаревшим еще в момент его выхода на рынок. А все потому, что инженеры Mikrotik шли по пути наименьшего сопротивления и использовали для Wi-Fi то, что уже встроено в SoC. Да, это положительно сказывалось на стоимости устройств, но фактически означало что Wi-Fi там просто чтобы был, для галочки. Хотя, как мне кажется, потребитель бы с радостью доплатил за модели с хорошим Wi-Fi. Кстати, по тому же пути они пошли и в линейке L009, странная конфигурация Wi-Fi в нем (только 2,4 ГГц, зато AX), обусловлена наличием такого беспроводного контроллера в SoC, ну а раз он есть, то не пропадать же добру. И вот в новых ARМ моделях появилось вроде бы адекватное и современное железо, те же ax2/ax3 имеют на борту производительный контроллер 802.11ax Qualcomm и, казалось бы, дело должно пойти на лад. Но взять хорошее железо не означает получить хороший результат. Неумелый повар из отличных продуктов точно также сварганит несъедобное хрючево, ровно, как и наоборот. Поэтому чуда не случилось, да Wi-Fi в новых роутерах стал повеселее, но и только. Да, вроде работает, вроде что-то передает, но любой бытовой аналог среднего ценового диапазона делает его с закрытыми глазами. Ходят слухи, что все это потому, что мы не умеем их настраивать. А настроек там много, очень много, по идее, если их освоить мы должны получить космический звездолет, который унесет наш Wi-Fi на недосягаемую высоту. Но ни один гуру так и не раскрыл секрета этих настроек, которые наверно представляют страшную тайну и шепотом передаются на смертном одре от отца к сыну… Я честно пытался дать вторую жизнь Wi-Fi на hAP ax2 и настроить хотя бы устойчивую работу со скоростью тарифа провайдера – 100 Мбит/с, что для AC/AX вообще довольно смешная цифра. Но увы, не осилил и под напором домашних пошел и купил два Xiaomi Router AX3000T, по цене примерно по 3000 рублей, что в пять раз дешевле моего ax2 в современных ценах. Китайцы просто заработали из коробки обеспечив по квартире стабильную связь до 450 Мбит/с по квартире, что для AC клиентов очень неплохо. А домашние спросили почему нельзя было так сделать сразу. На этом вопрос с Wi-Fi для дома и небольшого офиса, куда позиционирует эти устройства Mikrotik, для меня закрыт окончательно и бесповоротно. Не мучайте себя и окружающих, пойдите купите нормальное Wi-Fi устройство, их на рынке много и цены весьма демократичные. В корпоративной среде тоже все как-то не очень, CAPsMAN назвать беспроводным контроллером можно с очень большой натяжкой и только если ты не пробовал ничего слаще морковки. Нет, когда-то это была прорывная в своем сегменте технология, но сегодня это просто средство быстро раскидать настройки по точкам, таким же бестолковым как остальное беспроводное оборудование Mikrotik. А чтобы посмотреть, как должен выглядеть и что уметь современный контроллер беспроводной сети посмотрите на Uni-Fi или Omada, последний вообще можно назвать бюджетным, поддерживающие его точки доступа TP-Link относятся к среднему ценовому диапазону. Поэтому при рассмотрение оборудования Mikrotik мы не берем во внимание Wi-Fi, потому что мы покупаем эти устройства не для этого, а для работы в роли роутера под управлением RouterOS, что у них получается наилучшим образом.

Аукцион выделенных серверов! Серверы дешевеют у вас на глазах! Новые лоты каждый день, скидки до -35% на весь срок аренды. Успейте арендовать, пока лот не ушел другому! Получить предложение #реклама 16+ selectel.ru О рекламодателе

MikroTik L009 – новый народный роутер, замена RB2011 На рынке устройств Mikrotik уже довольно давно появились новые устройства семейства L009, с одной стороны непонятные и противоречивые, с другой, способные занять бюджетную часть рынка. Сам производитель позиционирует их как замену серии RB2011, крайне популярную в свое время, и я сам был владельцем такого устройства. Тут можно сказать одно – давно пора. Под капотом у L009 имеется SoC IPQ-5018, 2*800 MГц ARM 64, 512 MБ RAM и 128 МБ NAND. Из портов в наличии 8 RJ 45 1 Гбит/с, SPF 2,5 Гбит/с и USB 3.0. Набор, в общем и целом, приятный, для продвинутого дома или небольшого офиса – то, что доктор прописал. В наличии классический красный корпус и привлекательная цена. Сегодня купить устройства серии L009 можно примерно за 15 000 рублей, где-то дешевле, где-то дороже. Моделей ровно две: ▫️L009UiGS-RM – классический маршрутизатор без Wi-Fi ▫️L009UiGS-2HaxD-IN – все тоже самое, только с Wi-Fi 6 (aх) И весь прикол в том, что по цене эти два роутера практически не отличаются. Но вся тонкость в деталях. Второй роутер предоставляет беспроводную связь стандарта 802.11ax только в диапазоне 2,4 ГГц. А почему? А потому, что в состав SoC IPQ-5018 уже входит контроллер 802.11ax 2,4 ГГц, а для поддержки 5 ГГц нужно было бы ставить дополнительный чип, что усложнило бы и удорожило производство. А так Wi-Fi в L009 практически ничего не стоит (плюс две антенны). По архитектуре порт ether1 соединен с ЦПУ линией в 1 Гбит/с, остальные ether2-ether8 и spf1 подключены к процессору через Switch-Chip Marvell 88E6190 с общей пропускной способностью в 2,5 Гбит/c. Да, хотелось бы большего, но для бюджетного сегмента устройство достаточно сбалансировано, кроме Wi-Fi. Но Wi-Fi у Mikrotik традиционно слабое место и никто серьезных производительных систем на нем не строит. Поэтому если вам нужен роутер в дом или небольшой офис - L009 неплохой выбор за свои деньги, вариант с Wi-Fi взять можно если вам нужно просто пустить в интернет телефоны в офисе или ТСД на небольшом складе. В остальном особого смысла в этой модели нет. И наконец, к чему это мы все написали. К нам пришли два экземпляра L009UiGS-RM и мы планируем их протестировать. В планах проверить производительность при подключении роутеров между собой, между L009 и Ax^2, производительность NAT и производительность различных типов туннельных соединений. Если вам интересно что-то еще – пишите, по возможности проверим. Но учитывайте, что ресурсы у нас ограниченные, какие-то сложные тесты проводить мы не будем. Поэтому ждем вопросов и пожеланий.

Заговорите свободно на английском через 6 месяцев Я ищу 10 человек, которых лично доведу до свободного владения английским. Без нудной зубрежки и устаревших правил. Только эффективная система и 30-40 минут занятий в день. Меня зовут Сергей Сердюков. Мой авторский метод – английский как "Остров" уже помог тысячам простых людей выучить язык и начать говорить. Хотите попасть в 10-ку тех, кто заговорит на английском через 6 месяцев? Начните с бесплатного вебинара, где я раскрою основы своей методики. Узнайте, как это работает и подходит ли моя система именно для вас. Хотите заговорить свободно и без страха? ⚡ Регистрируйтесь на вебинар и забирайте в подарок PDF ТОП-3000 самых нужных слов, чтобы за 2 месяца начать понимать 80% слов на английском Зарегистрироваться #реклама 16+ eng.int-traf.com О рекламодателе

Настраиваем SOCKS прокси-сервер Dante Dante – мощный и гибкий SOCKS прокси-сервер, который достаточно прост в настройке и присутствует в репозиториях основных систем. Для чего нужен прокси-сервер рассказывать не надо, в первую очередь это контроль исходящего трафика пользователей вашей локальной сети. Тем более что Dante предоставляет обширный инструментарий управления трафиком. Установку мы будем производить в среде Ubuntu 24.02 LTS

apt update
apt install dante-server

После установки откроем файл /etc/danted.conf и приведем его к следующему виду:

logoutput: stdout
internal: 0.0.0.0 port = 1080
external: eth0
socksmethod: username
clientmethod: none
user.privileged: root
user.unprivileged: nobody
user.libwrap: nobody
client pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect error
}
socks pass {
         from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect error
}

Это минимальная рабочая конфигурация. Коротко пройдем по опциям. Сначала мы перенаправляем лог в стандартный поток вывода, это может показаться странным, но в этом случае мы воспользуемся стандартной возможностью логирования systemd и не будем дублировать лог в файлы, это особенно полезно если вы запускаете Dante на слабой VPS или в контейнере. Опция internal обозначает, где и как вы принимаете входящие соединения, можете указать IP-адрес или интерфейс. В нашем случае мы слушаем на всех адресах узла. Опция external указывает адрес или интерфейс, через который соединения выпускаем наружу. Для аутентификации пользователей выбираем socksmethod: username, это включит стандартную аутентификацию по логину и паролю. Секция client pass отвечает за правила подключения клиентов к серверу, а socks pass за прохождение трафика через сервер. В нашем случае разрешен трафик от любого узла к любому узлу. Но мы можем изменить такое поведение. Например:

client pass {
        from: 192.168.0.0/24 to: 0.0.0.0/0
        log: connect error
}
client block {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect error
}

Разрешит выход через сервер только клиентам локальной сети 192.168.0.0/24 и запретит всем остальным. А конструкция

socks block {
        from: 0.0.0.0/0 to: vk.com
        log: connect error
}
socks pass {
         from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect error
}

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

socks pass {
       from: 0.0.0.0/0 to: 0.0.0.0/0 port = 80
       protocol: tcp
       log: connect error
}
socks pass {
       from: 0.0.0.0/0 to: 0.0.0.0/0 port = 443
       protocol: tcp
       log: connect error
}
socks block {
       from: 0.0.0.0/0 to: 0.0.0.0/0
       log: connect error
}

В общем, возможности весьма широкие и большее количество информации вы можете почерпнуть в официальной документации: https://www.inet.no/dante/doc/latest/config/index.html

Выбирать бытовую технику больше не сложно! А создавать уют в доме — исключительно приятно. Канал Techscanner — ваш надежный гид в мире комфорта и умного дома. Подписывайтесь: t.me/+AT18pK1DKCRjY2Ji Здесь вы найдете: — Советы по выбору техники, которая упростит вашу жизнь. — Обзоры и сравнения простым языком и на личном опыте. — Идеи для уюта, чтобы ваш дом был не только функциональным, но и стильным. — Лайфхаки для упрощения домашних дел. Читайте Techscanner, чтобы ваш дом стал умнее, уютнее и удобнее! Подписаться #реклама О рекламодателе

​​Почему именно systemd? Практически после каждой нашей заметки о возможностях systemd в комментариях появляются читатели, которые пишут, что мол, а не проще ли это сделать … и далее идет перечисление простых утилит или скриптов. С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт. Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования. Вы можете мастерски владеть скриптами и автоматизировать все с их помощью, но ваши коллеги не сильно обрадуются этому факту, если им придется принять у вас обслуживание этой системы. Да и самому элементарно можно забыть, где лежит и для чего нужен тот или иной скрипт, особенно если подробного документирования не производилось. Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п. Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами. Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab. Второй плюс – это углубленная интеграция в систему, systemd предоставляет множество удобных инструментов, начиная от управления автозагрузкой и заканчивая средствами логирования. Чтобы посмотреть результат работы скрипта – вам придется самому позаботиться о ведении лога. В systemd все это можно посмотреть «не отходя от кассы», стандартными инструментами. При этом никаких особых усилий к этому прикладывать не придется. Из этого вытекает еще одно большое преимущество юнитов – их гораздо проще отлаживать. Во-первых, у вас уже есть лог, который ведется автоматически. Во-вторых, юниты предсказуемы и работают одинаково, вне зависимости от того, запущены они вручную или другим юнитом. В тоже время отлично работающий при интерактивном запуске скрипт может оказаться неработоспособным при вызове через cron или из другого скрипта просто потому, что оказался запущен в другом контексте, с другими переменными окружения. До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей. Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы. Для традиционного решения этой задачи придется немало поломать голову, выполнить кучу проверок или, как делается чаще всего, пойти по пути костылей и синей изоленты. Скажем, просто поставить задержку, в надежде что за это время сервис, от которого зависит работа успеет подняться. Ну а нет, так нет… Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target. Еще одна важная задача – обработка отказа. Если служба упала – вы можете ее автоматически перезапустить. Но это можно сделать и без systemd, а вот systemd позволяет сделать это грамотно, указав частоту и количество попыток. Если проблема приняла системный характер или находится на другой стороне, то systemd попробует несколько раз перезапустить службу и прекратит это делать, не получив результата. И это гораздо лучше, чем тупо долбить скриптом, вызывая повышенную нагрузку на систему и сеть. Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?

Дистанционное обучение на Дизайнера интерьеров Хотите освоить профессию дизайнера интерьеров, не выходя из дома? Подойдёт новичкам и тем, кто меняет профессию. Новосибирский Государственный Университет Архитектуры, Дизайна и Искусств (НГУАДИ) на цифровой платформе дистанционного образования (dpde.ru) приглашает на онлайн курс «Дизайнер интерьеров»: с нуля за 10 месяцев✨. Учитесь из любого города: материалы 24/7 и поддержка преподавателей ВУЗа. В программе: планировка, стили, цвет и эргономика, документация, ArchiCAD, Photoshop, 3D Max и нейросети для идей/визуализаций. Соберёте портфолио и получите поддержку с трудоустройством. По окончании — диплом НГУАДИ «дизайнер интерьеров» (ФРДО). На этой неделе льготные условия обучения 💻🎓⚡ Узнать больше #реклама 16+ dpde.ru О рекламодателе

Низкоуровневые интерфейсы ядра Linux В комментариях к заметке про Magic SysRq задали вопрос о том, что это за команды такие, которые отличаются одной буквой. Да, это действительно команды одного из низкоуровневых интерфейсов SysRq, которые состоят из одной буквы. Но рассмотрим весь этот механизм более подробно. В Linux существуют две виртуальные файловые системы /proc и /sys для низкоуровневого взаимодействия с ядром системы. Они существуют в оперативной памяти и создаются динамически при загрузке системы, при выключении или перезагрузке их содержимое полностью теряется. 1️⃣ Файловая система /proc изначально подразумевалась для отображения информации о процессах, но со временем стала включать в себя инструменты управления и диагностики ядра. Большая часть файловой системы доступна только для root и только на чтение, например, если мы хотим получить информацию о процессоре, то нам нужно прочитать файл /proc/cpuinfo, я думаю все знают команду:

cat /proc/cpuinfo

Но обычно для этих целей существуют высокоуровневые утилиты, которые читают те же самые файлы, но делают это проще и удобнее для пользователя. На запись, кроме /proc/sysrq-trigger, доступна только директория /proc/sys, которая позволяет менять некоторые параметры ядра, пользовательский интерфейс для нее предоставляет утилита sysctl и в большинстве случаев лучше использовать ее. 2️⃣ Файловая система /sys появилась в ядре 2.6 как замена разросшейся /proc для работы с драйверами и оборудованием. Представляет ряд иерархических структур, группирующих устройства по физическому расположению, классам, шинам и т.п., а также инструменты управления некоторыми параметрами системы. Точно также данная файловая система доступна преимущественно root и поддерживает чтение и запись параметров, которые точно также не сохраняются при перезагрузке. Пример работы с низкоуровневыми интерфейсами оборудования можно посмотреть в нашей статье: ✅ NVMe-over-TCP - практическое знакомство с технологией 👆 В целом работа с низкоуровневыми интерфейсами ядра не представляет особой сложности, но требует определенных знаний и навыков, при этом в повседневной эксплуатации она не требуется, а нужное взаимодействие выполняют высокоуровневые утилиты. Но общие принципы устройства данных интерфейсов и работы с ними должен знать каждый Linux-администратор.

Wildberries: Сердечные скидки на подарки любимым Для влюблённых любой день – праздник. А со скидками до 60% праздник станет еще лучше❤️ Выбирайте романтический декор и подарки для любимых на Wildberries! Перейти на сайт #реклама wildberries.ru О рекламодателе

Наш резервный канал в MAX, на всякий случай, основное движение пока здесь. https://max.ru/join/9O4RfUouLW10N1bPe9sM1iJ-CyRVJvi8WdjY2tZL_Cs

Что такое Magic SysRq и чем он может быть полезен Каждый из нас не раз сталкивался с ситуацией, когда Linux-система впадала в состояние близкое к коме и переставала реагировать на все ваши команды, включая reboot. Неприятно, да. Что делать? Обувать ботинки и спешить в место физического расположения сервера? Не спешите, попробуйте Magic SysRq – это специальные низкоуровневые команды, которые позволяют взаимодействовать даже с наглухо повисшей системой, работало бы ядро. Чтобы перейти в этот режим отправьте:

echo 1 > /proc/sys/kernel/sysrq

А затем обычно следует команда жесткой перезагрузки системы:

echo b > /proc/sysrq-trigger

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

echo r > /proc/sysrq-trigger

Затем пробуем отправить SIGTERM всем процессам (попросим завершиться их по-хорошему). Некоторое время ждем, так как не все могут это сделать мгновенно.

echo e > /proc/sysrq-trigger

А дальше: кто не спрятался – я не виноват, приступаем к принудительному завершению всех активных процессов (посылаем SIGKILL):

echo i > /proc/sysrq-trigger

Чтобы не потерять данные в буферах и кешах принудительно пишем их на диск (посылаем fsync):

echo s > /proc/sysrq-trigger

После чего отмонтируем все файловые системы:

echo u > /proc/sysrq-trigger

А теперь можно и Reset нажать:

echo b > /proc/sysrq-trigger

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

Мужской клуб Wildberries На WB появился новый раздел — «Мужчины выбирают» Там есть всё: от носков до молотков. И есть даже специальные подборки по интересам для геймеров, спортсменов, автолюбителей и вообще всех-всех! Кстати, теперь искать подарки для своих любимых мужчин можно прямо в подборках! Ставим лайк этому лайфхаку ❤️ Перейти на сайт #реклама wildberries.ru О рекламодателе

Режимы выделения виртуальной памяти в Linux Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, нежели ее есть на самом деле. Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле. Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск). И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса. Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения е ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память. Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс. Режим работы этого механизма можно задать при помощи опции

vm.overcommit_memory

Которая может принимать одно из трех значений: 0, 1 и 2 🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память. В таком режиме ядро обычно допускает умеренное избыточное выделение памяти, примерно до 50% от общего размера физической памяти (ОЗУ + подкачка). Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer. Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой. 🔹 vm.overcommit_memory = 1 – выделение память происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих потомков и общую память (веб-сервера). Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer. 🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:

vm.overcommit_ratio = 100

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

CommitLimit = swap_total + (RAM_total × vm.overcommit_ratio / 100)

По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии оперативной памяти. Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно. Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска. В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.

Как работать удаленно с нейросетями? Присоединяйся! Подпишись прямо сейчас, чтобы не потерять: Свежие обзоры нейросетей, которые реально работают — без лишнего хайпа и воды, только проверенная информация, которую можно использовать для заработка. Пошаговые видео-уроки, после которых всё станет понятно — научитесь быстро осваивать новые профессии и автоматизировать рутинные задачи. Как находить клиентов, готовых платить дорого — секреты эффективного поиска заказов и построения стабильного потока заказов. Автоматизация работы — научитесь выполнять 2-часовую работу за 20 минут без выгорания, автоматизируя рутину с помощью нейросетей. Подписаться #реклама 16+ О рекламодателе

🎯Бесплатный вебинар: Инструменты DevOps — что реально используют на проектах в 2026 УЖЕ ЗАВТРА! Если ты: - сисадмин, знакомый с серверами, но Docker и Terraform пока всё ещё «тёмный лес» - разработчик, которому интересно, как всё крутится в проде - уже начал изучать DevOps, но запутался в хаосе инструментов — приходи. Что будет: — как выбрать инструменты, которые реально нужны на проектах — Docker, Kubernetes, Terraform, Ansible без перегруза теорией — CI/CD пайплайны на примерах GitLab CI и GitHub Actions — минимальный мониторинг, который работает без боли 📅 12 февраля, 19:00 (МСК) 💸 Регистрация бесплатная, плюс скидка 10% на обучение (любой тариф) GigaDevOps 👉 РЕГИСТРАЦИЯ ЗДЕСЬ.

Управление сетевыми настройками в Linux Последние годы Linux проделал большой путь унификации, во многом благодаря systemd. Теперь вам не нужно вспоминать приемы работы со службами и автозагрузкой в том или ином дистрибутиве. Все везде делается одинаково. Чего не скажешь о сетевых настройках. Причем, если в графической среде стандартом де-факто давно используется NetworkManager, то в серверном варианте наблюдается полный разброд и шатание. Debian использует службу networking, которая управляет сетевой конфигурацией через ifupdown, надо сказать – порядком устаревший. RHEL и производные полагаются на службу network, использующую скрипты ifup и ifdown. В принципе то же самое, что и в Debian, только все по-другому. Arch и основанное на нем семейство использует netctl собственной разработки, а если вы решите освоить ALT, то познакомитесь с еще одной системой – Etcnet. Ну и Ubuntu тоже не остался в стороне со своим netplan. От такого разнообразия разбегаются глаза и становится довольно тоскливо. Если вы редко работаете с тем или иным дистрибутивом, то для управления сетью вам придется заглядывать в справку. Тем не менее есть инструмент, который позволяет унифицировать работу с сетью, но по какой-то причине до сих пор не пользуется широкой популярностью. Это systemd-networkd, как и весь systemd он очень прост и также строится на основе юнитов соответствующего типа. В простейшем случае нам достаточно создать юнит с типом network и внести в него следующее содержимое:

[Match]
Name=ens33

[Network]
Address=10.8.8.100/24
Gateway=10.8.8.1
DNS=10.8.8.1

Однако, несмотря на простоту, systemd-networkd достаточно мощный сетевой менеджер и позволяет управлять как проводными, так и беспроводными соединениями, мостами, маршрутизацией и многим другим. При этом его основной плюс – унификация, он будет работать везде, где есть systemd. И в целом никто не мешает перейти на systemd-networkd уже сейчас, не дожидаясь пока его завезут из коробки в ваш любимый дистрибутив. Почему? Потому что это наиболее универсально и перспективно. Вам не нужно учить разные сетевые менеджеры, достаточно просто знать systemd-networkd. Также отдельно хотелось бы отметить netplan от Ubuntu. Это не самостоятельный сетевой менеджер, а фронтенд, поддерживающий systemd-networkd и NetworkManager. Netplan позволяет абстрагироваться от конкретного сетевого менеджера и описывать сети декларативно в формате YAML, после чего уже сам netplan сформирует конфигурацию для используемого сетевого менеджера. Это удобно, прежде всего переносимостью, а также возможностью расширения практически для любого дистрибутива и любого сетевого менеджера. Кроме того, у netplan есть интересные возможности, например, проверить сетевые настройки перед их применением. Если что-то пошло не так, то вы не потеряете сетевой доступ к узлу, так как все изменения будут автоматически откачены обратно. Поэтому, глядя на существующий зоопарк технологий мы бы обратили внимание прежде всего на systemd-networkd – он есть везде, где есть systemd, прост, понятен и отлично работает. В перспективе, конечно, хотелось бы видеть единый унифицированный фронтенд по образу netplan, который бы позволял описывать сети в едином формате и применять их без оглядки на используемый менеджер. Как и snap, netplan давно уже вышел за рамки мира Ubuntu и доступен практически в любом дистрибутиве, однако широкого распространения не имеет.

«Вечная отчётность» по интернет-рекламе ушла в прошлое! ⚡Теперь для большинства размещений достаточно отчитываться в ЕРИР только в течение года с даты публикации. После 12 месяцев данные можно не подавать — исключение составляют видеоинтеграции, которые продолжают распространяться на платформах. Мы в Digital Agency Insight уже разобрали: ✅ как считать срок отчётности; ✅ что делать с прошлыми размещениями; ✅ как не получить штраф. 📱Подписывайтесь на наш Telegram — рассказываем просто о сложных изменениях в рекламе, делимся практическими инструкциями и интересными кейсами о маркетинге в России и за рубежом. Узнать больше #реклама 16+ О рекламодателе

Монтирование файловых систем при помощи systemd Казалось бы, монтирование файловых систем в Linux задача простая и не требующая каких-либо доработок. Но очень часто именно в простоте таятся различные сложности и затруднения. Текущая система монтирования уходит корнями еще во времена UNIX и дошла до наших дней без серьезных изменений. Но мир с тех пор серьезно изменился, сегодня в широком ходу сетевые расположения и съемные устройства, работать с которыми классическим образом не слишком удобно. И вот тут нам на помощь снова приходит systemd, предлагая современные методы монтирования файловых систем. ✅ Читать далее

Монтирование файловых систем при помощи systemd Казалось бы, монтирование файловых систем в Linux задача простая и не требующая каких-либо доработок. Но очень часто именно в простоте таятся различные сложности и затруднения. Текущая система монтирования уходит корнями еще во времена UNIX и дошла до наших дней без серьезных изменений. Но мир с тех пор серьезно изменился, сегодня в широком ходу сетевые расположения и съемные устройства, работать с которыми классическим образом не слишком удобно. И вот тут нам на помощь снова приходит systemd, предлагая современные методы монтирования файловых систем. ✅ Читать далее