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

Не включается сетевое обнаружение в Windows 10/11 и Windows Server

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

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

Здоровый консерватизм - это хорошо, но он не должен препятствовать прогрессу. Сегодня мы поговорим об одной часто встречающейся проблеме - не включается сетевое обнаружение в последних версиях Windows 10/11 и Windows Server.

✅ https://interface31.ru/post/ne-vklyuchaetsya-setevoe-obnaruzhenie-v-windows-10-windows-server/

Без лишнего шума и пыли вышла Aspia 3.0. Ключевые изменения в выжимке ниже:

1️⃣ Архитектура, платформы и безопасность (Релиз 3.0.15)

🔹Переход на Qt 6 и кроссплатформенность: компонент Host теперь работает на Linux (X11/Wayland), macOS и Android (ранее был доступен только на Windows). Появился Client для Android.

🔹 Шифрование и безопасность: соединения по умолчанию защищены AES-256 GCM. Для пользователей Router обязательна двухфакторная аутентификация (TOTP).

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

🔹 Сетевой стек: добавлены прямые UDP-соединения (UDP hole punching, UPnP, NAT-PMP, PCP), встроенный STUN-сервер и раздельные порты для хостов, клиентов и релея.

🔹 Видео и сессии: внедрен кодек H.264 с аппаратным ускорением, адаптивный выбор качества, поддержка нового типа сессий Terminal, расширенный буфер обмена (файлы, изображения, HTML) и вкладки в интерфейсе клиента.

🔹 Упразднение Console: отдельная консоль удалена, ее функции интегрированы прямо в Client.

2️⃣ Развитие Host и портативный доступ (3.0.16 — 3.0.22)

🔹 Портативный Quick Support (3.0.22): для Windows добавлена версия хоста, работающая без установки. Ее можно экспортировать прямо из настроек с уже зашитой конфигурацией.

🔹 Экспорт преднастроенных инсталляторов (3.0.21): возможность сгенерировать готовый установочный пакет под развертывание на других ПК.

🔹 Мобильный хост на Android: Добавлен полноценный фоновый режим с уведомлением: хост остается на связи при заблокированном или выключенном экране (3.0.21, 3.0.22).

Появилась опция автоподтверждения захвата экрана.

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

🔹 Стабильность графики и системные фиксы: исправлены сбои аппаратного кодирования H.264 на старых GPU Intel, решены проблемы черного экрана в Wayland (GNOME) и захвата KMS на multi-GPU системах в Linux.

3️⃣ Улучшения Client и администрирования

🔹 Быстрое подключение (Quick Connect / F8): разовое подключение по адресу или роутерному ID без обязательного добавления в базу данных (3.0.20).

🔹 Управление парком машин через роутер: Введено разделение на временные и постоянные хосты с процедурой подтверждения (3.0.15).

Добавлено массовое одобрение временных хостов и пакетное перемещение по группам через Drag-and-Drop (3.0.20).

Quick Support-хосты помечаются отдельно и не могут быть одобрены как постоянные (3.0.22).

🔹 Удобство авторизации: возможность автоматической разблокировки мастер-пароля базы при старте через системное хранилище ключей Windows/macOS (3.0.20).

🔹 Собственные серверы обновлений: добавлена поддержка указания кастомного сервера обновлений и публичного ключа подписи пакетов (3.0.21).

До первого сервис-пака не ставить
 
На фоне некоторых коллег, которые бегут ставить свежий софт сразу после его выпуска, невзирая на то, что разработчик за неделю выпустил семь минорных релизов вспоминаются старые добрые времена, когда интернет был по талонам по карточкам с почасовой тарификацией и никакой мгновенной доставки софта быть не могло.
 
В те годы софт распространялся на физических носителях: дискеты, а позже и компакт-диски. И все косяки, доработки и прочее копились большой массой чтобы быть исправленными или добавленными в большом обновлении, которое называлось сервис-пак.
 
Выпускали их, когда быстро, когда не очень. В зависимости от критичности выявленных проблем и ожиданий пользователей.
 
Так для NT 4 было выпущено целых шесть сервис-паков, не считая Service Pack 6a и Post Service Pack 6a Security Rollup. И самая жесть состояла в том, что, поставив чистую NT 4 с лицензионного носителя вы должны были все эти обновления (числом 8 штук) накатить последовательно.
 
Для Windows 2000 было выпущено четыре сервис-пака и один Update Rollup для закрытия выявленных уязвимостей, для Windows XP сервис-паков было три. Потом этот процесс пошел на убыль.
 
Windows Vista получила всего два сервис-пака, а Windows 7 – один. Но к этому времени широкополосный интернет стал нормой жизни и все изменения и исправления стало можно свободно распространять через Windows Update.
 
Времена прошли, но привычки остались. Любой администратор, заставший те времена помнит, что установка сервис-пака часто была сродни обновлению системы. Менялось многое, добавлялись новые функции, исправлялись ошибки.
 
Поэтому и возникло правило: до первого сервис-пака в прод не ставим. Пусть там все оттестируют, исправят, а тогда уже и мы подтянемся.
 
А мотивация была проста – с косяками нам придется жить и жить долго, пока тот самый сервис-пак не выпустят. И зачем это надо? Совсем не надо! Поэтому посидим на старой версии, пока на новую все исправления не выпустят.

Автоматический перезапуск Aspia в Docker
 
Не так давно мы рассказывали, как запустить популярную систему удаленного доступа Aspia в Docker - https://t.me/interface31/6296/
 
И вот некоторое время назад пользователи начали сталкиваться с проблемами, перестает работать ретранслятор, но сам контейнер остается рабочим и Docker его не перезапускает.
 
С чем связаны падения ретранслятора пока непонятно, но по всем признакам проблема внешняя, так как на совершенно разных установках ретрансляторы падают практически одновременно.
 
Что делать? Перезапускать контейнеры руками? Но это не наш метод, да и где взять столько рук. Поэтому обратимся к средствам автоматизации, существует проект autoheal, который позволяет следить за здоровьем контейнера и перезапускать его, если что-то пошло не так.
 
Откроем docker-compose.yml в папке проекта Aspia и приведем его к следующему виду:

services:
  aspia-server:
    image: paprikkafox/aspia-server:latest
    container_name: aspia-server
    hostname: aspia.example.com
    environment:
      - EXTERNAL_IP=203.0.113.6
    ports:
      - "8070:8070"
      - "8060:8060"
    volumes:
      - ./data/database:/var/lib/aspia:rw
      - ./data/config:/etc/aspia:rw
    restart: always
     labels:
      - "autoheal=true"
    healthcheck:
      test: ["CMD-SHELL", "pidof aspia_relay && pidof aspia_router || exit 1"]
      interval: 10s      
      timeout: 5s        
      retries: 2         
      start_period: 15s  

 
Мы добавили метку, чтобы autoheal мог контролировать данный контейнер и добавили проверки процессов роутера или ретранслятора, если хоть один из них упал, то после двух неудачных проверок контейнер перейдет в статус unhealthy.
 
Теперь создадим отдельную директорию:
 
mkdir  /opt/autoheal
 
И разместим в ней следующий docker-compose.yml:
 

services:
  autoheal:
    image: willfarrell/autoheal:latest
    container_name: autoheal
    restart: always
    environment:
      - TZ=Europe/Moscow
      - AUTOHEAL_CONTAINER_LABEL=autoheal
      - AUTOHEAL_DELAY=2
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

 
В данном случае мы отслеживаем только контейнеры с меткой autoheal=true и перезапускаем их с задержкой в 2 секунды.

Запускаем все это добро и радуемся жизни, схема рабочая, проверена на практике.
 
Но есть один неочевидный момент. По умолчанию autoheal запускается с опцией:
 
AUTOHEAL_ONLY_MONITOR_RUNNING=false
 
Это означает, что он будет мониторить даже незапущенные контейнеры и автоматически будет поднимать их, даже если вы руками их остановите. Чтобы избежать этой ситуации добавьте в секцию environment опцию:

- AUTOHEAL_ONLY_MONITOR_RUNNING=true
 
Подобным образом мы можем отслеживать далеко не только Aspia, но и вообще любой сервис по любому нужному нам показателю, который не приводит к аварийному завершению контейнера, но влияет на его пользовательские характеристики. Главное – правильно написать условия проверки.

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

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

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

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

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

Работаем с жесткими и символическими ссылками в Windows

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

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

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

✅ Читать далее: https://interface31.ru/post/rabotaem-s-zhestkimi-i-simvolicheskimi-ssylkami-v-windows/

Горе от ума или причины упадка FreeBSD

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

Тут, конечно, хочется задать классический вопрос: если ты такой умный, то почему такой бедный? А применительно к ОС хочется спросить, а где ее пользовательская база? И почему так получилось, что из технологического лидера FreeBSD очень быстро превратилась в маргинальную и нишевую систему.

Я почитал материалы 2011 года, когда от FreeBSD отказались два отечественных IT-гиганта – Яндекс и Рамблер. Тогда было сломано много копий, но были и вполне разумные выводы и высказывания, которые, к сожалению, оказались не услышанными.

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

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

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

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

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

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

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

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

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

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

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

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

Само же сообщество было проникнуто духом элитарности и крайне высокой планкой вступления. На любое замечание по работе ПО было принято спрашивать: where are your patches? (Где твои патчи?).

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

В результате народ начал голосовать ногами в сторону более демократичного и развивающегося Linux. А когда «великие архитекторы» проспали ряд технологических новшеств, ногами стал голосовать и бизнес, хотя нерешаемых технических проблем там не было.

Но «элитарный» подход и «это не нужно» - свое дело сделали.