Как быстро вычислить отвечающие на Ping узлы подсети в терминале Linux

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

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

apt install fping

Затем запустите ее с ключами:

fping -a -g 192.168.172.0/24 2>/dev/null

Разберем части команды подробнее:

▫️Ключ -a – предписывает вывести узлы, которые отвечают на ping

▫️Ключ -g – генерировать узлы назначения из указанного диапазона, можно указать начальный и конечный адреса через пробел или CIDR, как в нашем случае

▫️ 2>/dev/null – подавляет вывод потока ошибок, чтобы не выводить сообщения о недоступных узлах

Как видим, поставленная нами задача решена просто и быстро.

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

fping -h

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

Логическая бомба

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

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

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

Рассмотрим классический пример, очистка устаревших данных, например, бекапов:

find  -type f -mtime +90 -exec rm -rf {} \;

Что делает эта команда? Тупо ищет файлы старше 90 дней и удаляет их. И логических бомб тут сразу несколько.

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

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

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

3️⃣ Теперь – самое неочевидное – find, который не рекомендуется использовать в скриптах в силу ряда особенностей. В частности, если нам попадется файл с пробелами в имени, то строка будет разбита на две, что приведет к неожиданным последствиям. Чаще всего удаление не произойдет, но может случиться разное.

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

Т.е. оставляем не копии за последние 90 дней, а 90 последних копий (или более, если в день создается более одной копии).

Жестко привязываемся к путям и учитываем возможность появления пробелов в имени файла:

find /mnt/backup/ -type f -printf '%T@ "%p"\n' | \
sort -n | \
head -n -90 | \
awk '{print $2}' | \
xargs -I {} rm {}

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

Сортируем от самых старых к самым новым и отбрасываем последние 90 записей. Затем для каждой строки получаем второй аргумент (имя файла в кавычках) и передаем его на удаление.

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

Правильно – из них останется только 90 самых последних и ни одного бекапа, ну или самый последний. Это видно на берегу? Видно. Значит это очередная логическая бомба и надо от нее избавляться.

Допустим, наши бекапы имеют имя base1-YYYY-MM-DD.dump, поэтому добавляем в строку поиска новое условие:

find /mnt/backup/increment/ -type f -name "base1*.dump" -printf '%T@ "%p"\n'

Или даже

find... -name "base1-*-*-*.dump"...

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

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

Шутки в IT бывают разные: бывают достаточно безобидные, а бывают очень злые и деструктивные.

Поэтому мы за первые. Старая добрая шутка на 1 апреля.

🤯🤯🤯

А какие IT-шутки знаете вы?

А в розетку включить не пробовали?

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

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

В общем привез, подключили мы его с моим начальником Колей и стали смотреть, а там совсем беда, не стартует… И так и эдак, ну никак.

Зовем Юру, мол попал ты пацан, мать мертвая, мать в гарантию, а это недели две, а то и месяц, мать то не простая, понтовая.

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

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

- А в розетку включить не пробовали?

Оказалось, что лежащий на столе удлинитель типа «пилот» оказался никуда не подключен, ну как-то так исторически сложилось.

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

Free или Available memory в Linux

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

Например, команда free -m может дать нам такой вывод:



total used free shared buff/cache available
Mem:  60169 27996 9001 8472  23171      22576


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

Почему так? Для этого нужно углубиться в принципы организации памяти в Linux. Кроме занятой процессами памяти – used в системе присутствует еще буферы и кеш - buff/cache, которые содержат разделяемые библиотеки, буферы ввода-вывода и т.д. и т.п., что позволяет системе меньше обращаться к диску.

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

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

А в худшем в вовсе может решить, что сохранить кеш важнее, нежели сохранить процесс и застрелит его при помощи OOM Killer.

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

Также рекомендуем прочесть следующие статьи:

🔹 Linux - начинающим. Что такое пространства подкачки и как они работают

🔹 Linux - начинающим. Что такое OOM Killer и как он работает

tcpdump – сеть как на ладони

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

Иначе можно долго гадать, что происходит и почему не работает то, что «по идее» должно работать. Поэтому не будем гадать, а просто посмотрим трафик своими глазами, в этом нам поможет утилита tcpdump.

Для ее установки выполните:

apt install tcpdump

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

tcpdump -D

Далее мы можем просто запустить:

tcpdump -i enp3s0 

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

▫️port
▫️host
▫️src
▫️dst
▫️tcp
▫️udp
▫️icmp

Например, мы хотим посмотреть все пакеты с портом назначения UDP 34567:

tcpdump -i enp3s0 udp dst port 34567

Указанную нами конструкцию следует читать как: протокол UDP - порт назначения 34567.

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

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

▫️AND
▫️OR

Отдельно для отрицания условия можно использовать

▫️NOT

Например:

tcpdump -i enp3s0 src host 203.0.113.11 and udp dst port 34567

Здесь мы фильтруем по двум условиям: хост источник и протокол - порт назначения пакета.

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

tcpdump -i enp3s0 src host 203.0.113.11 udp dst port 34567

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

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

[протокол] [направление] {host|net|port|portrange} значение

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

tcpdump -i enp3s0 udp dst port 34567 and not src host 203.0.113.11

Если мы хотим захватить определенное количество пакетов, то используйте ключ -с:

tcpdump -i enp3s0 -с 50 src host 203.0.113.11 and udp dst port 34567

Данная команда захватит строго 50 пакетов, соответствующих условию.

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

При работе tcpdump пытается разрешать адреса в DNS-имена, а порты в имена служб, чтобы предотвратить такое поведение используйте ключ -n:

tcpdump -i enp3s0 -n src host 203.0.113.11 and tcp dst port 22

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

tcpdump -i enp3s0 -c 50 src host 203.0.113.11 and tcp dst port 22 -w mydump.pcap

Теперь 50 пакетов, попадающих под фильтр, будут записаны в файл mydump.pcap, если вы не указали количество, то в файл запишется все, что tcpdump успел захватить, пока вы не прервали его работу через Ctrl+C.

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

Гистерезис как средство стабилизации триггеров в Zabbix

Кто постоянно работает с Zabbix знает такое явление как дребезг триггеров (или флаппинг), когда контролируемое значение колеблется около значения срабатывания триггера и приводит к постоянному его срабатыванию и восстановлению.

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

О чем это мы? Давайте возьмем для примера триггер High memory utilization, который имеет следующее выражение срабатывания:

min(/Linux by Zabbix agent/vm.memory.utilization,5m)>{$MEMORY.UTIL.MAX}

Оно означает, что если все значения за последние 5 минут были выше порога, то триггер сработает. Это обусловлено использованием min(), фактически мы берем наименьшее значение за 5 минут и сравниваем с порогом.

Поэтому набор значений:

89 90 91 89 92 95 – не сработает, min = 89

а набор:

91 93 95 91 92 94 – сработает, min = 91

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

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

Примем для этого значения порог срабатывания – 5%, при этом условием восстановления будет то, что за 5 минут ни одно значение не превысит этот порог. Теперь, после срабатывания триггера по памяти (штатное значение 90%) он не перейдет в состояние восстановления до тех пор, пока утилизация памяти стабильно не снизится менее 85%.

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

max(/Linux by Zabbix agent/vm.memory.utilization,5m) < ({$MEMORY.UTIL.MAX} - 5)

Обратите внимание, что здесь мы используем не min(), а max(), так как у нас ни одно значение метрики не должно в течении 5 минут превысить пороговое.

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

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

CrowdSec – как система предотвращения вторжений (IPS)

CrowdSec – это популярное ПО с открытым кодом для предотвращения вторжений, многие считают его современным аналогом Fail2ban, однако это не совсем так.

Также сразу внесем ясность: ни Fail2ban, ни CrowdSec не являются средствами защиты от атак на отказ в обслуживании – DDoS, так как являются достаточно ресурсоемкими приложениями и способны в таком сценарии еще сильнее нагрузить сервер.

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

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

Ключевое различие в подходе к обеспечению безопасности. Fail2ban прост, но в своей простоте он застыл на уровне 15-20 летней давности. Не учитывая современных подходов и сценариев.

Схему работы Fail2ban можно представить в упрощенном виде так:

Лог → Парсинг/Regex → Решение → Действие

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

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

CrowdSec предлагает принципиально иную схему, хотя во многом она похожа на предшественника:

Лог → Парсер → Событие → Сценарий → Решение → Действие

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

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

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

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

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

Но за все надо платить. Бытует мнение, что так как Fail2ban написан на Python, а CrowdSec на Go – последний быстрее и менее ресурсоемкий. Однако это не так.

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

Говорит ли это о том, что Fail2ban устарел? И, да и нет. Если вам нужно что-то простое и незамысловатое – выбор за старым добрым Fail2ban. Но это защита реактивная, которая сработает уже по факту.

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

Что такое современная платформа 1С:Предприятие и нужно ли ее знать администраторам

До сих пор замечаем со стороны коллег пренебрежительное отношение к 1С:Предприятие и нежелание изучать эту платформу или вообще касаться ее. Мол есть «одинэсники» — вот пусть они и занимаются, а мы «тру админы» и у нас другие задачи.

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

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

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

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

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

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

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

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

Не забыто и сетевое взаимодействие, сегодня для интеграции с внешними системами 1С:Предприятие предлагает Web и HTTP (REST) интерфейсы, Odata, работу через веб-сервер, мобильные приложения.

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

Есть много онлайн-сервисов, типа «Моя Бухгалтерия» и т.п., но по мере роста бизнеса их пользователи неизбежно приходят к вопросу: а как нам отсюда перейти на 1С?

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

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

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

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

А 1С:Предприяитие сейчас, это как минимум контур Бухгалтерия + Зарплата и там есть крайне чувствительные моменты, скажем как сроки сдачи отчетности. За ее срыв никого по голове не погладят.

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

Почему современное ПО такое неоптимизированное

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

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

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

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

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

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

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

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

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

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

Погодите, а кто мешает мне сделать все по старинке, качественно и выпустить на рынок действительно серьезный продукт? Никто не мешает, только этот «серьезный» продукт на массовом рынке (а мы говорим именно про массовый рынок) никому не нужен.

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

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

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

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

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

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

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

Что касается ресурсов, то об этом тоже думать никто не будет, как тогда, так и сейчас основной ориентир – средний современный ПК, тянуть старые системы никто не будет.

Сколько сегодня нужно ОЗУ для нормальной работы

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

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

Если мы посмотрим минимальные требования современных ОС, таких как Windows 11 или Ubuntu 24.04, то увидим там от 4 ГБ и выше. У Windows 10 правда до сих пор стоит 2 ГБ, но это было написано давно и неправда, меньше 4 ГБ ей тоже лучше не предлагать.

А вот новая Ubuntu 26.04 вообще порадовала нас минимальными 6 ГБ ОЗУ, вот, как хотите, так это и понимайте…

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

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

В общем сегодня 4 ГБ — это нижний порог работоспособной системы и не важно, что вы на ней запускаете, Windows или Linux. Потому что основные потребители ОЗУ – это не ОС, а прикладное ПО, в первую очередь браузер.

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

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

Сегодня 8 ГБ – стартовый уровень объема ОЗУ, меньше которого уже просто нет смысла и который уже совсем скоро может стать нижним порогом, смотрите требования Ubuntu 26.04 выше.

Если же мы говорим о системе начального уровня, но свободной от ограничений: нормальный офисный ПК, ноутбук для поездок и т.д. и т.п., когда мы хотим нормально работать и отдыхать, но сознательно не предполагаем запуска тяжелых приложений – то 16 ГБ сегодня норма жизни.

Игровая станция? Рабочий ПК специалиста? Меньше 32 ГБ даже не думайте, а лучше сразу 64 ГБ. Когда-то это было роскошью и признаком гиков или крутых спецов, которые знали зачем им столько ОЗУ, теперь это просто объективная реальность.

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

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

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

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

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

​​Про IPsec для самых маленьких

Набор протоколов IPsec широко используется для защиты сетевых соединений, но он же вызывает наибольшее количество затруднений у начинающих пользователей (и не только).

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

При этом IPsec не плодит никаких лишних сущностей: новых соединений, интерфейсов и т.д. и т.п. Т.е. вы как работали с IP, так и продолжаете работать, а IPsec тихо и незаметно делает свое дело.

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

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

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

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

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

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

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

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

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

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

Что это значит? А то, что между узлами А и Б при помощи IPsec будет защищен любой IP-трафик, а не только GRE. Вы можете гонять там что угодно и все это будет также защищено при помощи IPsec.

А если мы поднимем IPsec over GRE, то в этом случае мы создаем между узлами А и Б незашифрованный туннель, но все что ходит в этом туннеле и только шифруется с помощью IPsec. Только то, что в туннеле, а не весь трафик между внешними узлами.

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

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

Стандартное - Нестандартное

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

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

Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо.

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

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

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

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

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

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

- Ну это крутые пацаны из High Load рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…

Или:

- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…

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

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

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

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

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

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

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

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

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

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

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

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