Что такое 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

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

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

https://max.ru/join/9O4RfUouLW10N1bPe9sM1iJ-CyRVJvi8WdjY2tZL_Cs

Низкоуровневые интерфейсы ядра 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-администратор.

​​Почему именно systemd?

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

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

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

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

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

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

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

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

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

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

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

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

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

Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.

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

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

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

Настраиваем 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

Осталось добавить пользователя:

useradd -N -M -s /sbin/nologin dante

И установить ему пароль:

passwd dante

Для управления службой используйте:

systemctl start|stop|restart|status danted

Наш прокси сервер готов, можете подключаться.

Роутеры 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, что у них получается наилучшим образом.

Уже было, но лишним не будет

Секта свидетелей чего-то там

Сегодня снова хочется поговорить о таком интересном феномене в IT (хотя это присуще любым отраслям) как секты свидетелей чего-то там, в качестве чего-то там можно подставить: Mikrotik, Linux, BSD, IPv6, Intel/AMD и вообще все что угодно.

Почему именно секта? Да потому что поведение данных товарищей по очень и очень многим пунктам попадает под определение религиозных или коммерческих сект.

Давайте рассмотрим подробнее.

🔆 Распространение учения – любой уважающий себя сектант постоянно проповедует, к месту или ни к месту. Здесь у нас ровно тоже самое. В статье про Windows мы обязательно расскажем про Linux, в статье про NAT будем затирать про IPv6 и т.д. и т.п.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типичный пример – это адепты секты свидетелей BSD, которые кивают то на macOS, то на Juniper, мол там и там BSD. Но никто не знает и не может пояснить, что именно из BSD туда взяли, что с этим сделали и что осталось. Ну и главное – а что получила назад от этого сама BSD.

👉 В завершение просим не воспринимать статью полностью всерьез. Но в каждой шутке есть доля истины…

Как узнать все смонтированные файловые системы?

Раньше можно было сказать: загляните в /etc/fstab, но сегодня изучение этого файла уже не даст полного представления о всех смонтированных ФС.

Можно использовать команду mount, но ее вывод недостаточно удобочитаем.

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

А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом --real. Чтобы получить больше информации воспользуйтесь ключом --help.

Бренды и гарантия в современных условиях

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

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

Стандартная реакция – это же Китай, а может немного переплатить и взять тот же ASUS, MSI или HP? Все-таки бренд… Бренд, но «все-таки»….

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из другого чата, а вы что думаете, коллеги?

Подборка про самосбор

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

🔹 Гарантия по другую сторону баррикад, часть 3, самосбор (https://t.me/interface31/1366)

🔹 Самосбор, почему это не самая лучшая идея (https://t.me/interface31/1441)

🔹 И снова о вреде самосбора (https://t.me/interface31/2062)

🔹 И снова про самосбор серверов (https://t.me/interface31/2137)

🔹 Про сборку (https://t.me/interface31/4774)

🔹 Неочевидные опасности самосбора для опытных (https://t.me/interface31/4776)

👆 А если коротко и по делу, то наше мнение такое: если сборка ПК для вас не является хобби (или работой), и вы не готовы к дополнительным финансовым и/или временным затратам – то оставьте процесс сборки тому, кто получает за это деньги.

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

Self Hosted аналоги AnyDesk

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

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

В идеале – клиент получил единственный файл, установил, продиктовал ID, вы подключились.

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

🔹 Aspia – продукт модульный, что можно записать как в плюсы, так и минусы. Например, для управления ПК вам понадобиться установить на него Host, а для подключения к хосту использовать Client или Console.

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

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

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

Еще один минус – поддерживаемые платформы. Серверная часть собирается автором сугубо под Ubuntu 20.04 и будет работать на указанной ОС, либо Debian 11. Работоспособность на иных ОС не гарантируется.

Клиенты и инструменты управления доступны только под Windows, мобильного клиента нет.

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

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

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

Сервер поднимается на Ubuntu Ubuntu 18.04 – 22.04 или Debian 10/11, поддерживаются отличные от x86 архитектуры, что позволяет развернуть такой сервер на мини-ПК. Поддерживается также работа в Docker.

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

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

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

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

✅ В остальном между программами паритет. Обе быстро работают даже на медленных каналах и имеют достаточно скромные требования к серверной части. Так для начального развертывания будет вполне достаточно VPS с одним ядром, 1 ГБ ОЗУ и 10 ГБ диском.

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

Просто добавь воды сделай TRIM

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

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

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

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

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

А если нет нагрузки, но LA держится на высоких отметках – смотри подсистему ввода-вывода. И точно, тут даже ходить никуда не пришлось, собранные самим Zabbix метрики показывали высокое значение IO wait.

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

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

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

Что надо сделать? Принудительно послать TRIM, после чего буквально в течении ближайших 15 минут все пришло в норму.

Мораль сей истории проста – лечить надо причину, а не симптомы. И всегда искать причинно-следственные связи. Потому что просто так никогда ничего не случается.

Возвращаясь к напечатанному

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

✅ Первый взгляд на Windows 10 Technical Preview

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

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

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

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

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

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

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

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

Если в 2001 году Windows XP была современной системой, то в 2006 ее возможности явно не соответствовали требованиям рынка. Пользователи ждали новую систему и чем дольше было ожидание, тем выше были требования.

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

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

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

При этом каких-либо сильных мотиваторов для перехода на "восьмерку" с привычной и удобной "семерки" не оказалось. Поэтому такой популярности, как у сменившей откровенно устаревшую ХР "семерки", для Windows 8 и не ожидалось, особенно в корпоративной среде, которая вообще отличается сильным консерватизмом.