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

Настройка Wi-Fi роуминга в Windows

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

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

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

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

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

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

netsh wlan show profiles

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

netsh wlan show profiles MyWi_Fi

В данном случае нас интересует параметр Автопереключение.

И, наконец, установим требуемое значение:

netsh wlan set profileparameter name=MyWi_Fi autoswitch=Yes

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

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

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

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

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

Про Docker, секреты и рекомендации «ведущих собаководов»

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

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

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

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

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

Итак, когда мы говорим Docker, понимая его «взрослое» и серьезное применение, то мы держим в уме CI/CD, инфраструктура как код и т.д. и т.п.

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

И если мы явно пропишем секреты в .env (переменных окружения) или compose-файле, то они попадут в коммиты и историю Git, будут доступны при инспекции контейнера или чтении его окружения, осядут в логах, дампах, кешах.

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

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

Чтобы этого избежать, даже на уровне Docker Compose (а мы сильно углубляться не будем) есть возможность монтировать такие ресурсы как отдельную сущность – secrets.

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

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

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

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

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

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

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

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

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

Ну а ежели у вас другие сценарии, то рекомендации «ведущих собаководов» - ваша настольная книга.

Удаленно настраивать брандмауэр – это к дальней дороге?

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

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

Создадим в укромном месте, например в /root, скрипт flush.sh и добавим в него следующее содержимое.

▫️Для iptables:

#!/bin/bash
iptables-save > /root/iptables_backup.bak

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t filter -F
iptables -t nat -F
iptables -t mangle -F
iptables -t raw -F

iptables -X

▫️Для nftables:

#!/bin/bash
nft list ruleset > /root/nftables_backup.nft

nft flush ruleset

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

Для его запуска нам потребуется утилита at, установим ее если не установлена:

apt install at

Сделаем скрипт исполняемым:

chmod +x /root/ flush.sh

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

at now + 15 minutes -f /root/flush.sh

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

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

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

Для этого сначала узнаем его идентификатор командой:

atq

А затем удаляем командой:

atrm <ID_задания>

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

Настраиваем TLS защиту собственного сервера Joplin

Вчера мы рассказали (https://t.me/interface31/5557), как быстро установить собственный сервер заметок Joplin при помощи Docker, но у него есть один недостаток – он работает по незащищенному протоколу HTTP и публично публиковать такие сервисы категорически не рекомендуется.

Как быть? Ничего сложного, технически Joplin Server – обычное веб-приложение, а следовательно все наши вопросы решит установленный перед ним обратный прокси и поддержкой HTTPS.

Вариантов тут великое множество, если у вас уже есть подобная инфраструктура, то имеет смысл рассматривать ее. Если же нет, то будем обходиться собственными силами и желательно сделать это максимально просто.

Исходя из этого мы решили использовать веб-сервер Caddy, почему именно его, а не NGINX/ Angie? Потому что Caddy предельно прост и вы это сами скоро увидите.

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

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

Создаем папку проекта и compose-файл в ней:

mkdir -p /opt/joplin
nano /opt/joplin/docker-compose.yml

Приводим его содержимое к следующему виду:

services:
  db:
    image: postgres:17
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    restart: always
    environment:
      POSTGRES_PASSWORD: MyPa$$worD
      POSTGRES_USER: joplin-user
      POSTGRES_DB: joplindb

  app:
    image: joplin/server:latest
    container_name: joplin-server
    depends_on:
      - db
    restart: always
    environment:
      APP_PORT: 8080
      APP_BASE_URL: https://joplin.example.com
      DB_CLIENT: pg
      POSTGRES_PASSWORD: MyPa$$worD
      POSTGRES_DATABASE: joplindb
      POSTGRES_USER: joplin-user
      POSTGRES_PORT: 5432
      POSTGRES_HOST: db

  caddy:
    image: caddy:2
    restart: always
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - ./data/caddy:/data
      - ./config/caddy:/config

Что изменилось в нем, кроме добавления секции caddy? Мы убрали проброс портов для контейнера Joplin, теперь он полностью изолирован во внутренней сети.

Также обратите внимание на APP_BASE_URL, теперь там https://joplin.example.com, т.е. явно указан протокол – HTTPS и отсутствует внутренний порт, потому что именно так мы будем обращаться к серверу через обратный прокси.

Следующим шагом следует создать конфигурационный файл для Caddy:

mkdir -p /opt/joplin/caddy
nano /opt/joplin/caddy/Caddyfile

После чего внесем в него следующее содержимое:

joplin.example.com {
    reverse_proxy app:8080
}

И всё? И всё! Этим и хорош Caddy, не нужно ничего расписывать, он сам по умолчанию получит для указанного домена сертификаты Let’s Encrypt и настроит максимально надежное современное шифрование.

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

docker compose up -d

Теперь открываем указанный в APP_BASE_URL адрес и убеждаемся, что наш сервер работает по защищенному протоколу с сертификатом Let’s Encrypt и максимальным уровнем шифрования.

Покорение новой вершины закончилось в баре: история проекта Blackcomb

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

Но позвольте, а причем тут бар и горные вершины? Обо всем по порядку. Вся эта история начинается с проекта Whistler, в котором разработчики объединили две ветви разрабатывающихся операционных систем на основе ядра Windows NT - Neptune и Odyssey.

Так появилась Windows XP, одна из самых популярных операционных систем и решение объединить пользовательскую и корпоративную ветви систем оказалось в итоге правильным. А кодовое имя проекта было взято по имени горы и одноименного горнолыжного курорта Whistler, где любили кататься на лыжах сотрудники Microsoft.

После удачи с Windows XP разработчики явно поверили в себя и выкатили на следующую ОС весьма амбициозные планы – практически полный переход на .NET, новую систему драйверов, новый интерфейс и новую файловую систему WinFS, которая должна была стать больше СУБД, чем традиционной файловой системой.

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

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

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

Для нового проекта выбрали тоже символичное имя – Longhorn, в честь бара Longhorn Saloon, расположенного между горами Whistler и Blackcomb на том же курорте. Про то, насколько любили посещать это заведение сотрудники Microsoft история умалчивает.

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

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

В результате обновленный Longhorn вышел в 2007 году как Windows Vista и стал одним из самых больших провалов в истории Microsoft.

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

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

В результате через два года Vienna вышла на рынок под именем Windows 7 и повторила успех Windows XP, став для многих культовой ОС.

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

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

На фото обе вершины и долина с баром Longhorn Saloon между ними.

Устанавливаем собственный Joplin-сервер

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

Официально Joplin Server предусматривает использование Docker, других способов установки не предусмотрено. Для хранения базы заметок предлагается использовать PostgreSQL. В итоге у вас получится два контейнера: один для сервера Joplin, второй для СУБД.

Для установки создадим отдельный каталог, например, /opt/joplin и разместим там файл docker-compose.yml со следующим содержимым:

services:
  db:
    image: postgres:17
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    restart: always
    environment:
      POSTGRES_PASSWORD: MyPa$$worD
      POSTGRES_USER: joplin-user
      POSTGRES_DB: joplindb

  app:
    image: joplin/server:latest
    container_name: joplin-server
    depends_on:
      - db
    ports:
      - "8080:8080"
    restart: always
    environment:
      APP_PORT: 8080
      APP_BASE_URL: http://joplin.example.com:8080
      DB_CLIENT: pg
      POSTGRES_PASSWORD: MyPa$$worD
      POSTGRES_DATABASE: joplindb
      POSTGRES_USER: joplin-user
      POSTGRES_PORT: 5432
      POSTGRES_HOST: db

Он достаточно прост и в особых комментариях не нуждается. Отдельно стоит обратить внимание только на APP_BASE_URL – укажите там именно тот адрес, по которому вы будете реально обращаться к серверу, если вы укажете joplin.example.com, а обращаться будете, скажем, как 192.168.1.100 – то ничего работать не будет.

Сохраняем файл и запускаем:

docker compose up -d

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

Сам Joplin Server – приложение предельно простое, даже примитивное, особо смотреть и настраивать здесь нечего.

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

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

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

Это удобно, если у вас есть две независимые базы, скажем на компьютере и телефоне и вы хотите их объединить и использовать совместно.

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

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

RouterOS long-term 7.20.7 – наконец то дождались!

Новый год порадовал нас выходом первой long-term версии RouterOS 7. В линейке Mikrotik канал long-term не имеет четко обозначенных сроков поддержки, но это самый стабильный и консервативный канал с достаточно редким выпуском мажорных версий.

Это означает появление некоторого островка стабильности, среза операционной системы, на котором разработчики сказали: «Стоп, хватит, система в таком виде готова, оставляем так».

Именно с появлением long-term можно серьезно рассматривать переход на RouterOS 7 в продуктивных средах, опираясь на long-term как опорную точку.

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

Мы пробовали писать статьи по RouterOS 7, но написав парочку отказались от этой затеи, так как тексты переделывать приходилось бы через релиз-два.

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

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

AppArmor-шум или тонкие настройки логов в LXC-контейнерах Proxmox

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

apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-803_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log"

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

Но что это вообще за записи? Давайте разберемся. Как мы можем видеть источником записи является служба rsyslogd контейнера, которая хочет получить доступ к dev-log хоста, чтобы что-то записать в системный лог, но AppArmor ей в этом препятствует.

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

Но мы пойдем немного дальше и подумаем, а нужны ли нам вообще системные логи в контейнерах? Чтобы посмотреть, что systemd-journald туда пишет запустите:

journalctl -f

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

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

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

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

Начнем:

systemctl stop rsyslog 
systemctl mask rsyslog

Затем создадим директорию

mkdir -p /etc/systemd/journald.conf.d

А в ней создадим и откроем на редактирование файл:

nano /etc/systemd/journald.conf.d/00-journal.conf

В который внесем следующее содержимое:

[Journal]
Storage=volatile
RuntimeMaxUse=64M
ForwardToSyslog=no

Первые две строки предписывают использовать для логов оперативную память и задают доступный размер (в нашем случае 64 МБ).

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

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

Сохраняем содержимое файла и перезапускаем службу:

systemctl restart systemd-journald

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

И снова про рекламу и донаты

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

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

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

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

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

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

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

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

Итого по нашему плану имеем 1,25 * 30 = 37,5 часов в месяц, без чуть-чуть рабочая неделя. Это только на подготовку коротких заметок в канал.

Но основной контент мы по-прежнему размещаем на сайте. План – от 4 статей в месяц. А вот там все гораздо сложнее.

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

Развернуть систему, проверить все интересующие аспекты, сделать скриншоты – где-то еще часа два. Потому что проверить и посмотреть надо многое, но не все из этого попадет в статью.

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

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

Само написание обзора – час-полтора, затем вычитка, проверка орфографии, пунктуации, стилистики – еще полчаса.

Что имеем в сухом остатке? По минимуму 5,5-6 часов. На обзор, который читается за 5-10 минут. В этом, собственно, и смысл подобных материалов – коротко, но емко дать общую информацию. Полотно на десять экранов вниз с сотней картинок просто никто не будет читать.

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

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

Сделали? Разворачиваем стенд по новой и дословно воспроизводим записанное. Должны получить полное совпадение результата. В зависимости от сложности еще часа два -три.

Если документация скупа или что-то не получается, то начинается поиск и отладка, тоже часы, но мы их считать не будем.

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

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

Итог? Опять по минимуму 9-10 часов, на одну статью. Или около 40 часов в месяц.

Итого в месяц получаем 80 часов работы с контентом, это две полноценных рабочих недели.

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

Как минимум семья не поймет, а потом и сам сядешь и подумаешь: «А на фига оно мне надо? Может лучше в лес или на рыбалку?»

Мониторинг - он такой разный

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

📉 Начнем с совсем простых инструментов. Таких как Системный монитор в Windows или, например, nmon в Linux.

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

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

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

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

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

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

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

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

🏆 Ну и наконец такие монстры уровня предприятия как Zabbix. Многие представляют его как пульт управления ядерным реактором. Где мигают лампочки, рисуются графики, постоянно меняются показатели.

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

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

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

У опытных админов на панели Zabbix обычно всего два виджета: проблемы и история проблем.

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

Токсичность – наша национальная черта? Привычка?

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

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

И вот случилась у нее беда. Сгорел SSD в ноутбуке. Большинство она восстановила, что-то было продублировано, но осталась одна мелочь – 3D-объект воздушных шариков, он был простой, бесплатный, скачанный с сайта с бесплатными объектами.

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

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

Самым первым делом ей объяснили, что она дура. Ну это классика жанра, пропускаем мимо ушей. Дальше ей пояснили, что такое нарисовать самому – пять минут делов, а после посыпались услуги сделать тоже самое от 10 до 25 тыс. руб.

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

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

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

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

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

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

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

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

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

Я думаю, что читателям все это знакомо. Но возникает вопрос, что является причиной тому? Тяжелое наследие СССР, 90-х, царской России (нужное подчеркнуть), менталитет, национальные особенности?

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

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

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

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

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

Непонятно одно, зачем это?

Прочитал сегодня новости о выпуске первой версии MiDesktop -форка KDE версии 1, адаптированного для современных систем Linux.

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

А там очень интересно все: в проекте использован тулкит Osiris, который является форком Qt 2 для решения лицензионных проблем и ограничений ветки Qt 1.

Серьезно? Qt2 в 2026 году? С разрешениями от FHD и выше? Требованиями к экранам, сглаживанию и т.д. и т.п. Оказывается серьезно и вообще они бы Qt1 использовали, если бы не лицензионные ограничения.

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

Нравятся заложенные в KDE 1 идеи и принципы? Ну так развивайте их, адаптировав к современным технологиям. И примеры тому есть. Например, Trinity Desktop Environment (TDE) – который развивает основные идеи KDE 3.5, посмотреть на него можно в операционной системе Q4OS на базе Debian.

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

Есть среда Mate, которая взялась развивать старый добрый GNOME2, но и там от основоположника остались только основные идеи, а так это вполне современная система.

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

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

MiDesktop в текущем виде – проект мертворожденный. Потому что KDE 1 в 2026 году в своем оригинальном виде никому не нужна. Нравятся какие-то идеи или концепция внешнего вида? Так выделите их, сформулируйте и развивайте на современном технологическом уровне.

Распределенные системы или история одного блекаута

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

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

Однако критерием истины является практика. А также сильное влияние имеет ряд совсем нетехнических вопросов. Когда все хорошо ими особо никто не задается. А когда становится не очень хорошо, то всплывает классическое: кто виноват и что делать?

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

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

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

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

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

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

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

Стала появляться связь? Можем начать принимать карты. Появилась связь с офисом – хорошо, нет – и так проживем.

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

Появился интернет? Уже есть сетевая связность, возможность получить поддержку, передать или получить документы и т.д. и т.п.

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

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

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

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

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