Руководство администратора

Панель: https://<сервер или VIP>:7443/. В кластере можно открывать любой узел — изменения конфигурации выполняет координатор и рассылает всем узлам.

Язык панели — русский или английский: переключатель RU / EN в шапке панели и на странице входа. Выбор запоминается в браузере. Переводятся и сообщения сервера (ошибки, состояния); журнал службы и журнал аудита показываются как записаны.

1. Как HopeDFS представляет Linux-папки для Windows

Файлы, положенные в папку средствами Linux (scp, rsync, NFS), получают NTFS-разрешения наследованием от родительской папки — как при копировании в папку на Windows Server.

Доступ к тем же файлам из Linux (локально или по NFS) идёт мимо NTFS-разрешений — их проверяет только HopeDFS. Права Linux новых файлов задаются в «Параметрах SMB» (по умолчанию 0664/0775).

2. Общие папки

«Общие папки» → «Создать шару»:

• Общие: имя (с $ на конце — скрытая), роль (сетевое имя, через которое шара доступна), путь Linux, описание, шаблон NTFS-разрешений корня:
• Стандартный — Администраторы и SYSTEM: полный доступ; CREATOR OWNER: полный доступ на вложенные; Пользователи: чтение и выполнение + создание папок и файлов (каждый правит только своё);
• Все прошедшие проверку — изменение;
• Только администраторы;
• Домашние папки — пользователи создают папку первого уровня и видят только свою (вместе с ABE);
• Не менять — оставить существующие разрешения.
• Разрешения общего ресурса — как вкладка «Разрешения» в «Расширенной настройке общего доступа»: полный доступ / изменение / чтение, разрешить или запретить. Итоговый доступ = шара ∧ NTFS.
• Дополнительно: перечисление на основе доступа (ABE), автономные файлы (кэширование), шифрование SMB 3 для шары, только чтение, лимит подключений, квота (размер диска для клиента = квота), запрещённые расширения (*.exe, *.mp4), переход по символическим ссылкам, временное отключение.
• Предыдущие версии: расписание снимков (по умолчанию 07:00 и 12:00, как теневые копии Windows) и глубина хранения.

Файл, не изменившийся с прошлого снимка, связывается с ним жёсткой ссылкой и места не занимает; изменённый копируется через reflink — на XFS (reflink=1) и Btrfs мгновенно и без расхода места, пока файл не изменят. На ext4 reflink нет: первый снимок — полная копия данных шары, каждый следующий — копии изменённых файлов. Для таких шар раздел «Предыдущие версии» показывает предупреждение; следите за свободным местом на томе или размещайте шары с частыми снимками на XFS/Btrfs.

В корне каждой шары HopeDFS держит три скрытых файла-ловушки защиты от шифровальщиков (!!_Archive_2019.docx, ~~_backup_finance.xlsx, ЯЯ_Резерв_договоры.pdf, раздел 17). Пользователи их не видят; не удаляйте и не меняйте их по сети — это будет воспринято как атака.

Шары также можно создавать и удалять из Windows: «Управление компьютером» → «Подключиться к другому компьютеру» → «Общие папки» (пути вида C:\srv\data\Папка переводятся по таблице томов в «Параметрах SMB»).

3. NTFS-разрешения

Два равноценных способа:

1. Windows Проводник: свойства файла/папки → «Безопасность» → «Изменить» / «Дополнительно» (наследование, владелец, аудит, действующие права). Требуется право «Смена разрешений» на объекте (администраторы сервера имеют его всегда через привилегии).
2. Панель → «Файлы и разрешения»: выберите шару и папку/файл: - Разрешения — список записей (явные и унаследованные), «Добавить» (выбор пользователя/группы, тип, «Применяется к», общие или дополнительные разрешения), «Отключить наследование» (преобразовать в явные или удалить), «Заменить все записи разрешений дочернего объекта»; - Аудит — записи SACL (успех/отказ), события пишутся в «Журнал аудита»; - Владелец — смена владельца, при необходимости рекурсивно; - Действующие права — что получит выбранный пользователь с учётом групп, NTFS и разрешений шары.

Содержимое папки загружается частями по мере прокрутки, поэтому папки с сотнями тысяч файлов открываются так же быстро, как маленькие; над списком — число объектов и поиск по части имени (ищет сервер по всей папке, без учёта регистра).

4. Пользователи и вход

• Локальные учётки — пользователи и группы сервера (общие для всех узлов кластера). Встроенные группы: Administrators, Users, Guests, Backup Operators и др. Члены Administrators входят в панель с полным доступом и имеют привилегии резервного копирования/смены владельца на шарах. Ограниченный доступ к панели (только нужные разделы, только просмотр) выдаётся ролями — раздел 18. В свойствах учётки можно указать адрес электронной почты — на него придёт ссылка, если пользователь забудет пароль к панели (раздел 22).
• Домен. HopeDFS не является контроллером домена (не обслуживает Kerberos, LDAP, DNS, NETLOGON) — он подключается к существующему домену (Active Directory, HopeDC, Samba AD) только по LDAPS, TCP 636. Открытый LDAP 389 и RPC/NETLOGON (135, 49152+) не используются. Имена ролей в DNS HopeDFS регистрирует сам: в MS AD — записями зоны в каталоге по тому же LDAPS, в HopeDC / BIND / FreeIPA — динамическим обновлением DNS (53) с ключом TSIG (раздел 16).

«Домен» → «Подключить сервер к домену»: 1. DNS-имя домена и контроллер (DNS-имя или IP). 2. Доверие сертификату контроллера — сертификат проверяется всегда. Варианты: - корневой CA домена установлен в Linux (/usr/local/share/ca-certificates + update-ca-certificates) или вставлен в панели — тогда контроллер указывают по DNS-имени из поля SAN его сертификата (сертификаты AD CS для контроллеров его содержат); - «Получить сертификат контроллера» → сверить отпечаток SHA-256 с контроллером → «Доверять этому сертификату» (подходит для самоподписанных сертификатов и подключения по IP). 3. Учётка с правом создавать учётки компьютеров (пароль передаётся только по LDAPS и не сохраняется).

Для каждой роли создаётся учётка компьютера ИМЯ$ с SPN cifs/ и HOST/. По её ключам HopeDFS сам проверяет билеты Kerberos — при входе пользователей к контроллеру не обращается.

Как входят пользователи: - доменные — Kerberos: клиент обращается по имени роли (\\HOPEFS\Шара), нужна DNS-запись A HOPEFS → VIP (HopeDFS регистрирует её сам, раздел 16); - локальные учётки сервера — NTLM (в т.ч. при обращении по IP); - NTLM для доменных учёток не поддерживается: проверить его можно только на контроллере через NETLOGON, а HopeDFS связывается с доменом исключительно по LDAPS. В журнале такой вход отклоняется с подсказкой. - вход доменных администраторов в веб-панель — проверкой пароля на контроллере по LDAPS (bind); - клиенты Linux входят по Kerberos так же (mount -t cifs //hopefs/Шара /mnt -o sec=krb5 при билете kinit), в том числе клиенты, не требующие взаимной проверки подлинности.

Выбор пользователей и групп в Windows. На вкладке «Безопасность» шары HopeDFS кнопка «Добавить» открывает стандартное окно выбора; Windows спрашивает у сервера, член ли он домена (интерфейс DSSETUP), и предлагает искать в домене сервера. Локальные учётки сервера — «Размещение» → имя сервера.

Контроллер с несколькими доменами (HopeDC с несколькими доменами, глобальный каталог леса AD). HopeDFS выбирает базу поиска по контексту имён, совпадающему с указанным DNS-именем домена. Учётку для подключения указывайте как user@домен — короткое Administrator на таком контроллере неоднозначно.

«Проверить связь» показывает состояние сертификата каждого контроллера, LDAPS-вход и поиск, ключи Kerberos. Группы администраторов панели задаются в «Параметрах подключения».

Служебная учётка для поиска в каталоге (необязательно, рекомендуется для рабочей установки). Поиск в каталоге (выбор пользователей и групп, имена владельцев, «Действующие права») выполняется под служебной учёткой, если она задана, иначе — под учёткой компьютера роли (HOPEFS$). Отдельная учётка делает поиск независимым от пароля HOPEFS$ и видимым в журналах контроллера. Настройки учётки в домене: - член только группы «Пользователи домена» (прав чтения каталога достаточно); - «Срок действия пароля не ограничен» — иначе поиск остановится, когда пароль истечёт; - запрет локального входа и входа через службы удалённых рабочих столов (групповая политика).

Пароль служебной учётки проверяется входом по LDAPS при сохранении. «Проверить связь» показывает, под какой учёткой идёт поиск, и предупреждает, если служебная учётка не задана, не входит или у неё ограничен срок действия пароля. Для входа пользователей в шары по Kerberos служебная учётка не используется. Проверку сертификата можно отключить только переменной окружения HOPEDFS_LDAP_INSECURE_TLS=1 (небезопасно, для тестового стенда; панель показывает предупреждение).

При добавлении новой роли после подключения к домену выполните подключение повторно — будет создана учётка для её имени.

Пароль учётки компьютера роли. HopeDFS хранит пароль ИМЯ$ (из него выводятся ключи Kerberos) и сам его не меняет. Если пароль сменили в домене, билеты Kerberos будут шифроваться новым ключом и вход доменных пользователей перестанет работать. «Проверить связь» это обнаружит (сравнивается версия ключа msDS-KeyVersionNumber в домене и у HopeDFS), в журнале службы отказ входа будет с той же подсказкой. Обновить: «Домен» → «Учётки компьютеров ролей» → «Пароль»: - Пароль уже сменили в домене — ввести новый пароль; HopeDFS проверит его входом этой учёткой по LDAPS и сохранит вместе с новой версией ключа; - Сбросить пароль — HopeDFS сам задаст новый случайный пароль по LDAPS учёткой с правом сброса пароля (она не сохраняется); удобно для плановой смены или если новый пароль неизвестен.

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

5. Мониторинг

• Обзор — шары и заполненность, сеансы, нагрузка, состояние домена и ролей.
• Сеансы и файлы — подключённые пользователи и открытые файлы с возможностью закрыть (как fsmgmt.msc). В кластере данные показываются по узлу — выберите узел-владелец роли.
• Журнал аудита — входы (успешные/неудачные), отказы в доступе, изменения разрешений, действия администраторов, события SACL, атаки шифровальщиков. Файл: /var/log/hopedfs/audit.jsonl.
• Защита от шифровальщиков — инциденты; при открытом инциденте красный баннер показывается на всех страницах панели, оповещение уходит на webhook (раздел 17).
• Журнал службы — /var/log/hopedfs/hopedfs.log.*; уровень детализации — «Параметры SMB» → узел (после перезапуска).

6. Параметры SMB

Рабочая группа, описание сервера, диапазон версий SMB (минимум 2.0.2, SMB1 не поддерживается), обязательная подпись, шифрование всех шар, отказ клиентам без шифрования, NTLM вкл/выкл, гостевой и анонимный доступ, таймаут простоя сеансов, права Linux для новых файлов, таблица томов Windows → Linux, срок сеанса панели.

7. Пространства имён DFS

«Пространства DFS» → корень Company на роли HOPEFS со ссылками Finance → \\fs2\finance, Docs → \\HOPEFS\Docs. Клиенты открывают \\HOPEFS\Company\Finance и прозрачно попадают на цель. Несколько целей у ссылки — клиент выберет доступную. В корне пространства папки-ссылки видны в Проводнике как папки (как на Windows-сервере пространства — точки повторной обработки DFS), поэтому переход двойным щелчком из \\HOPEFS\Company в Finance работает так же, как ввод полного пути. Цели упорядочиваются по сайту клиента: сначала серверы его сайта, затем по стоимости связи сайтов (сайты AD или таблица «Репликация площадок» → «Сайты и подсети», см. раздел 15). Папку, реплицируемую между площадками, можно опубликовать в пространстве имён одной кнопкой — ссылка получит целями все её копии.

Доменное пространство — \\hope.local\Company вместо \\HOPEFS\Company: путь не привязан к серверу, серверов пространства может быть несколько (отказоустойчивость, разные площадки), а клиентов к ним направляет контроллер домена. Конфигурация хранится в AD так же, как у Windows Server 2008+ (CN=Dfs-Configuration,CN=System, объекты msDFS-Namespacev2 / msDFS-Linkv2), поэтому HopeDFS можно подключить сервером к пространству, созданному в Windows, а серверы Windows и HopeDFS могут обслуживать одно пространство вместе. Папками пространства, где есть серверы HopeDFS, управляйте из панели HopeDFS: консоль «Управление DFS» вносит изменения через сервер пространства по RPC (NETDFS), которого в HopeDFS нет.

• «Доменное пространство» → имя, роль, учётка администратора домена (создавать объекты в Dfs-Configuration может администратор; пароль не сохраняется). Автономное пространство с тем же именем переводится в доменное вместе с папками. Учётке компьютера роли делегируется право вести пространство — дальше папки меняются в панели без администратора.
• Второй сервер: на нём «Пространства DFS» → «Доменные пространства в Active Directory» → «Подключить этот сервер». Папки сервер берёт из каталога; изменения, сделанные в консоли Windows или на другом сервере, подхватываются при сверке (раз в 30 минут и по «Опубликовать сейчас»).
• «Отключить сервер» убирает этот сервер из пространства; последний сервер (или флажок «удалить целиком») удаляет пространство из каталога.
• MS AD: контроллеры начинают направлять клиентов к новому пространству после репликации каталога и обновления кэша корней (до 15 минут; сразу — после перезапуска службы DFS на контроллере). Серверы пространства Windows подхватывают изменения папок в течение часа.
• HopeDC: объекты пространства HopeDC хранит, но направлять клиентов к доменным пространствам (отвечать на запрос корня) он пока не умеет — до выхода соответствующей версии HopeDC используйте автономные пространства. Требования к HopeDC — 06_ТЗ_HopeDC_публикация.md.
• FreeIPA / ALD Pro: доменных пространств DFS нет (это объекты схемы AD).

8. Дедупликация данных

«Общие папки» → свойства шары → вкладка «Дедупликация». По расписанию HopeDFS находит одинаковые файлы и объединяет их на уровне блоков файловой системы через reflink (системный вызов FIDEDUPERANGE — ядро побайтно сверяет данные перед объединением, повредить файлы нельзя). Аналог Data Deduplication в Windows Server, но на уровне ФС. Требуется XFS (reflink=1) или Btrfs; на ZFS дедупликация включается средствами самой ФС (zfs set dedup=on), на ext4 reflink нет. В свойствах шары виден результат последнего прогона (сэкономлено, групп, файлов) и кнопка «Запустить сейчас». Открытые на запись файлы не трогаются; служебная папка снимков .hopedfs пропускается.

9. NFS

Раздел «NFS» и вкладка «NFS» в свойствах шары. Встроенный сервер NFS 4.0, 4.1 и 4.2 экспортирует те же папки, что и по SMB, на одном порту TCP (по умолчанию 2049), без отдельных portmap/mountd/NLM. Доступ проверяется теми же NTFS-дескрипторами, разрешениями общего ресурса, мандатными метками, квотами и фильтрами файлов, что и по SMB; пространство имён единое (файл, созданный по NFS, виден по SMB и наоборот), открытия и блокировки — общие с SMB.

Подключение клиента Linux

mount -t nfs4 сервер:/Шара /mnt/share                  # AUTH_SYS (uid/gid)
mount -t nfs4 -o sec=krb5p сервер:/Шара /mnt/share     # Kerberos с шифрованием

Корень сервер:/ — псевдо-ФС со списком шар роли, к адресу которой подключился клиент.

Проверка подлинности (поле «Проверка подлинности» в свойствах экспорта; клиент получает список через SECINFO, неподходящий способ — ошибка WRONGSEC):

Для Kerberos сервер должен быть в домене, а у учётки роли — SPN nfs/<имя роли> и nfs/<имя роли>.<домен> (для новых подключений к домену добавляются автоматически; для уже подключённых — кнопка «Обновить SPN» в разделе «Домен»; для FreeIPA/ALD Pro — служба nfs/… в импортированном keytab). Нужен AES (по умолчанию во всех современных доменах).

Права (NFSv4-ACL ↔ NTFS). Атрибуты acl (4.0) и dacl/sacl (4.1) — это тот же NTFS-дескриптор: маски прав совпадают с правами Windows побитно, флаги наследования переводятся по смыслу, субъекты — имя@домен (OWNER@/GROUP@/EVERYONE@ → CREATOR OWNER/CREATOR GROUP/Все). Изменение ACL с клиента Linux (nfs4_setfacl) сразу видно на вкладке «Безопасность» в Windows и наоборот; унаследованные записи сохраняются, для папок пересчитывается наследование. Нужно право «Смена разрешений» (WRITE_DAC), для аудита (sacl) — привилегия SeSecurity.

Блокировки и состояние. LOCK/LOCKT/LOCKU с семантикой POSIX (частичное снятие, смена типа), сессии NFSv4.1 со слотами и кэшем ответов, для NFSv4.0 — кэш повторных запросов (DRC) и кэш ответов владельцев (повтор запроса не выполняется дважды), аренда 90 с. Сервер «вежливый»: состояние клиента с истёкшей арендой хранится ещё до половины срока аренды и освобождается раньше, только если мешает другому клиенту; после этого старый stateid в 4.0 получает NFS4ERR_EXPIRED. Блокировки одного владельца сливаются (как в POSIX). Блокировки SMB для клиентов NFS обязательны (как в Windows), блокировки NFS между клиентами NFS — рекомендательные (как у Linux knfsd). Открытие режимами совместного доступа (deny) и удаление открытого по SMB файла согласованы между протоколами.

Защита от шифровальщиков действует и для клиентов NFS (раздел 17).

NFS 4.2: копирование на сервере (cp на клиенте Linux не гоняет данные по сети), CLONE (мгновенные копии через reflink на XFS/Btrfs), SEEK (разреженные файлы), ALLOCATE/DEALLOCATE (fallocate).

Не поддерживается: делегирования (кэширование файла на клиенте — клиент работает без них), pNFS, блочные и символьные устройства на шарах (FIFO и сокеты — можно), RDMA.

Кластер. NFS работает на адресе роли (VIP) и переезжает вместе с ней. Дескрипторы файлов постоянные (как у knfsd, на основе дескрипторов ядра) — переживают переименование и перезапуск службы; после переключения на другой узел с общим томом клиенты продолжают работу, с репликацией — повторяют LOOKUP.

Включение/выключение сервера и смена порта применяются после перезапуска службы.

10. Мандатное управление доступом (МРД)

Раздел «Мандатный доступ». Мандатная модель уровней конфиденциальности и категорий поверх дискреционных NTFS-разрешений. В отличие от решений, где метки действуют только для Linux-клиентов, HopeDFS сам выполняет проверку доступа, поэтому МРД действует и для клиентов Windows по SMB, и для NFS.

• Метка объекта — уровень (0..=255) и набор категорий; хранится в xattr. Задаётся на вкладке «Метка (МРД)» в свойствах файла/папки («Файлы и разрешения»), можно рекурсивно.
• Допуск субъекта — максимальный уровень и категории; задаётся по SID (пользователь или группа) в разделе «Мандатный доступ».
• Правила. Чтение — допуск доминирует над меткой (не читать выше своего уровня). Запись: режим «Равенство» — только на своём уровне (строгий сеанс), режим «Доминирование» — как Windows MIC (No-Write-Up). Запись в каталог (создание элементов) — по доминированию; новый объект получает уровень создателя. Администраторы с правом SeSecurity меткам не подчиняются (управляют метками).
• Отказы по МРД пишутся в «Журнал аудита».

11. Вход доменных пользователей по IP-адресу

По умолчанию Windows использует Kerberos только при обращении к серверу по имени. Чтобы доменные пользователи могли подключаться и по IP-адресу (\\10.0.0.50\Шара), HopeDFS регистрирует в домене имена служб (SPN) учёток ролей по их IP-адресам (cifs/10.0.0.50). Это включено по умолчанию при вводе в домен (флажок «Регистрировать SPN по IP-адресам ролей»). Дополнительно на клиентах Windows нужно включить параметр TryIPSPN — скачайте TryIPSPN.reg в разделе «Домен» («Вход по IP-адресу») и раздайте его групповой политикой. Там же — кнопка «Обновить SPN» (после смены плавающих IP или добавления узлов). NTLM для доменных учёток по-прежнему не поддерживается (связь с доменом только по LDAPS); по IP-адресу работает именно Kerberos.

12. Подключение к FreeIPA / ALD Pro

HopeDFS подключается к домену FreeIPA / ALD Pro по LDAPS так же, как к AD (раздел «Домен» → «Подключить», учётка администратора домена, например admin). Тип каталога определяется автоматически. Отличия от AD:

1. Нужен ipa-adtrust-install на контроллере — иначе у пользователей и групп нет Windows-совместимых SID (ipaNTSecurityIdentifier) и HopeDFS откажется подключаться с понятным сообщением.
2. Системная учётка для поиска создаётся автоматически: uid=hopedfs-<узел>,cn=sysaccounts,cn=etc,… (штатный для FreeIPA способ подключения сторонних служб; пароль генерирует и хранит только HopeDFS, пароль администратора не сохраняется). При выводе из домена учётка удаляется.
3. Ключи служб выдаёт контроллер. Создайте службы и получите keytab: ipa service-add cifs/<роль>.<домен> ipa service-add nfs/<роль>.<домен> ipa-getkeytab -p cifs/<роль>.<домен> -k hopedfs.keytab ipa-getkeytab -p nfs/<роль>.<домен> -k hopedfs.keytab и импортируйте файл кнопкой «Импорт keytab» в разделе «Домен». После этого пользователи входят по Kerberos в шары (SMB) и экспорты NFS (krb5/krb5i/krb5p).
4. Группы пользователя берутся из memberOf (включая вложенные), SID — из ipaNTSecurityIdentifier; в «Выборе пользователей» и на вкладке «Безопасность» видны имена вида IPA\ivanov.

Проверено на стенде из тех же компонентов, что использует FreeIPA (389 Directory Server со схемой FreeIPA и MIT Kerberos KDC): подключение с проверкой сертификата LDAPS, вход по Kerberos по SMB и NFS, проверка прав по группам FreeIPA, изменение ACL с клиента NFS. Перед вводом в эксплуатацию рекомендуем пробное подключение к вашему контроллеру ALD Pro.

13. Типовые проблемы

14. Лицензия и редакции

Лицензирование устроено так же, как в HopeDC и Hope Mail Server: лицензия — ключ, подписанный сервером лицензий собственной парой ключей HopeDFS, публичный ключ вшит в программу. Лицензия привязана к узлу (отпечаток узла — идентификатор установки ОС machine-id) и хранится на нём (/var/lib/hopedfs/license.key). Условия использования — Лицензионное соглашение (раздел 20; карточка «Лицензионное соглашение» в этом же разделе).

Остальные возможности (SMB, NTFS-разрешения, домен, снимки, DFS, квоты, NFS, МРД, публикация в сети, защита от шифровальщиков, роли с плавающим IP на одиночном сервере) доступны во всех редакциях. Окно «Сравнить редакции» — в разделе «Лицензия».

Получение лицензии. «Настройки» → «Лицензия»: скопируйте или скачайте запрос (.req с отпечатком узла) и передайте на сервер лицензий; полученный ключ (---BEGIN HOPE LICENSE KEY---) вставьте в «Ключ лицензии». Либо «Онлайн-активация» — узел сам обратится к серверу лицензий со своим отпечатком. Ключ проверяется сразу: подпись, отпечаток узла, продукт (HopeDFS), срок. Сервер лицензий может переопределить лимиты в самой лицензии (shares_limit, storage_limit_gb в ГиБ; 0 — без ограничений) и разрешить кластер в редакции ниже Enterprise (features: ["cluster"]), репликацию между площадками — в Free (features: ["dfsr"]).

Превышение лимитов. Существующие общие папки и доступ пользователей продолжают работать; нельзя только создавать новые общие папки (ни в панели, ни из Windows через «Управление компьютером»). Объём считается по всем общим папкам узла (без служебной папки снимков .hopedfs, вложенные папки и жёсткие ссылки — один раз). Полный обход общих папок выполняется при запуске службы, при добавлении шары и раз в 6 часов; между ними пересчитываются только папки, изменённые через HopeDFS (SMB, NFS, панель, репликация), — раз в 20 секунд. Поэтому большие шары (терабайты, миллионы файлов) не нагружают диск постоянными обходами. Файлы, записанные мимо HopeDFS (из консоли сервера), попадут в подсчёт при ближайшем полном обходе или после перезапуска службы.

Блокировка записи (+25%). Объём данных может превышать лимит редакции не более чем на 25%. При достижении порога (Free — 62,5 ГБ, Standard — 2,5 ТБ, при лимите из лицензии — лимит × 1,25) запись новых данных в общие папки блокируется: создание файлов и папок, дозапись и увеличение файлов (в т.ч. серверное копирование) получают «Недостаточно места на диске» (STATUS_DISK_FULL), Проводник показывает 0 байт свободно. Чтение, удаление, переименование, изменение разрешений и перезапись существующих данных без увеличения размера работают. Панель показывает красный баннер и шкалу «лимит → порог блокировки». Блокировка снимается автоматически, когда объём опускается ниже порога: занятый объём уточняется каждые 20 секунд (запись по SMB учитывается сразу). В журнале службы и аудите — события «⛔ … запись заблокирована» и «✅ … снова разрешена».

Окончание срока лицензии. Управление замораживается: все разделы панели доступны только для просмотра, кнопки изменений неактивны, API изменений и управление шарами/сеансами из Windows (srvsvc) отвечают отказом. Общие папки, доступ пользователей, NTFS-разрешения из Проводника, снимки по расписанию, кластер и репликация продолжают работать. Заморозка снимается сразу после применения действующей лицензии. Удаление лицензии возвращает узел в редакцию Free.

Кластер. Отказоустойчивый кластер — только в редакции Enterprise, и лицензия Enterprise нужна каждому узлу. Создать кластер, пригласить узел и присоединиться к кластеру можно только с действующей лицензией Enterprise (координатор дополнительно проверяет лицензию присоединяемого узла). Если у узла уже работающего кластера лицензия стала не Enterprise (удалена, заменена на Standard), кластер не разваливается — роли, переключение и репликация работают, — но панель показывает предупреждение, а приглашать новые узлы нельзя, пока на всех узлах не будет Enterprise. Роли с плавающим IP на одиночном сервере доступны во всех редакциях.

Как в HopeDC, лицензия не реплицируется: у каждого узла своя лицензия на свой отпечаток (выбор узла — вверху раздела «Лицензия»; таблица «Лицензии узлов кластера» показывает все узлы). Конфигурация общих папок в кластере общая, поэтому для неё действует самый строгий лимит среди лицензий живых узлов и наибольший занятый объём (так же — порог блокировки записи); сообщение об отказе называет узел, лицензия которого ограничивает кластер. Заморозка — по лицензии узла, к панели которого подключён администратор.

15. Репликация между площадками (как DFS-R)

Раздел «Отказоустойчивость» → «Репликация площадок». Это аналог службы DFS Replication Windows Server: одна и та же общая папка на серверах HopeDFS разных площадок (центральный офис, филиалы, резервная площадка) с одинаковым содержимым. Пользователи каждой площадки работают со своим сервером на скорости локальной сети, изменения расходятся между серверами. Доступно в редакциях Standard и Enterprise (лицензия нужна каждому участнику).

Как устроено

• Группа репликации — набор участников (серверов HopeDFS) и реплицируемых папок. Участник — одиночный сервер или отказоустойчивый кластер целиком. Папка группы на каждом участнике — одна из его общих папок (имена и пути на разных серверах могут отличаться).
• Писать можно на любом участнике. Изменения отслеживаются по событиям SMB, NFS и панели, а изменения мимо HopeDFS (scp, rsync, работа на сервере) находит сверка дерева — раз в час и по кнопке «Синхронизировать». Каждое изменение получает версию; у каждого участника — база версий папки (<шара>/.hopedfs/dfsr/<папка>/versions.redb, как база DFS-R на томе).
• Участник сам забирает изменения у партнёров и получает от них подсказку «есть новое» — обычно изменение доходит до других площадок за секунды.
• По сети идут только изменённые части файла (поблочное сравнение, как RDC в Windows): после правки 4 КБ в файле 5 МБ передаются десятки килобайт, а не весь файл. Переименование и перемещение файлов и папок, копии уже имеющихся файлов выполняются у получателя локально, без передачи данных. Мелкие файлы передаются пакетами. Целостность каждого файла проверяется по SHA-256. Передача сжимается (отключается в параметрах группы).
• Вместе с файлом реплицируются NTFS-разрешения (при изменении разрешений папки наследование пересчитывается у получателя), атрибуты, время создания и изменения, альтернативные потоки, метки мандатного доступа, режим Unix. Не реплицируются символические ссылки и специальные файлы, владелец Unix (uid/gid) — права задаёт NTFS-дескриптор.
• Конфликты. Если один файл изменили на двух площадках до того, как изменение разошлось, побеждает последняя запись (как в DFS-R). Проигравшая версия не теряется: она переносится в ConflictAndDeleted на том участнике, где лежала. Туда же попадают файлы, удалённые на других участниках. Квота ConflictAndDeleted — 660 МБ на папку (настраивается), старые записи удаляются первыми. Кнопка «ConflictAndDeleted» у папки — список с восстановлением: восстановленный файл снова реплицируется на все площадки.
• Удаление папки на одной площадке при одновременном создании в ней файлов на другой — папка возвращается вместе с новыми файлами (как в DFS-R).
• Открытые файлы. Изменение файла, открытого пользователем на сервере-получателе, применяется после закрытия файла. Файл, который сейчас записывается, учитывается после окончания записи.

Одновременную работу с одним файлом на разных площадках DFS-R не согласует (нет блокировок между серверами) — это так и в Windows. Типовые сценарии: каждый филиал работает со своими документами, рассылка из центра в филиалы (участники «только чтение»), сбор данных филиалов в центр, резервная площадка.

Требования

• Между участниками открыт 7443/tcp (тот же порт, что панель). Обмен идёт напрямую, системный HTTP-прокси не используется.
• Часы серверов синхронизированы (NTP): расхождение больше 5 минут — запросы отклоняются.
• На каждом участнике — лицензия Standard или Enterprise, одна и та же версия HopeDFS.

Настройка

1. На сервере с актуальными данными: «Создать группу» — имя группы, имя папки и общая папка этого сервера. Этот сервер — основной участник: его содержимое главное при первичной синхронизации.
2. «Участник» → адрес сервера другой площадки (fs-spb.corp.local или IP; для кластера — адрес роли или любого узла), логин и пароль администратора того сервера. Учётные данные используются один раз, чтобы тот сервер дал согласие. Проверьте показанный отпечаток сертификата — он должен совпадать с отпечатком на странице «Репликация площадок» того сервера; после подключения он закрепляется.
3. Выберите общую папку на подключаемом сервере для каждой папки группы, при необходимости — «только чтение».
4. Начнётся первичная синхронизация нового участника: он получает содержимое партнёров. Его файлы, совпадающие с основным, остаются на месте без передачи; отличающиеся — переносятся в ConflictAndDeleted и заменяются версией группы; файлы, которых у группы нет, — переносятся в PreExisting (.hopedfs/dfsr/<папка>/PreExisting, с исходными путями). Как и в Windows, на новом участнике во время первичной синхронизации лучше не работать с файлами папки. Для больших объёмов заранее скопируйте данные (rsync/robocopy) — совпадающие файлы не передаются.
5. При необходимости — «Опубликовать в DFS»: в пространстве имён этого сервера появится ссылка, целями которой будут копии папки на всех участниках.

Добавить папку в группу — «Папка» (общая папка этого сервера), затем «Общие папки участников» — сопоставление на остальных серверах (список их общих папок запрашивается у них).

Параметры группы

Участник «только чтение» получает изменения, но клиенты не могут записывать в его папку по SMB и NFS, а изменения, сделанные на нём мимо HopeDFS, откатываются к версии группы (как read-only replicated folder в Windows). Его изменения другим участникам не передаются.

Состояние

У каждой папки: режим (первичная индексация, первичная синхронизация, восстановление базы, работает), объектов в базе версий, очередь локальных изменений, время последней сверки; по каждому партнёру — состояние («синхронно», «ожидают N изменений», «вне расписания», «ошибка» с текстом), отставание (сколько изменений партнёра ещё не получено), время последнего обмена, сколько получено и сколько сэкономлено передачей только изменённых частей. В журнале службы — события с префиксом 🔀.

Сайты

Вкладка «Сайты и подсети». Сайт клиента и серверов определяется по IP-адресу: подсети и связи сайтов читаются из Active Directory по LDAPS (раздел конфигурации, CN=Sites), а таблица, заданная вручную, дополняет и уточняет их (для FreeIPA/ALD Pro и рабочей группы — единственный источник). Связь сайтов имеет стоимость; для ссылок DFS цели упорядочиваются так: серверы сайта клиента, затем по наименьшей стоимости пути, цели одной стоимости — в случайном порядке (распределение нагрузки). Свой сайт каждый участник определяет сам и сообщает остальным.

Кластер как участник

Отказоустойчивый кластер подключается к группе как один участник. Репликацией папки занимается узел, обслуживающий роль её общей папки; при переносе роли репликация продолжается на новом узле (база версий лежит в папке шары и переезжает вместе с общим томом). Запросы партнёров, пришедшие на другой узел, пересылаются владельцу роли. Закрепляются сертификаты всех узлов кластера. Адрес участника — адрес роли (VIP) или DNS-имя; подойдёт и адрес любого узла.

Безопасность

Обмен — HTTPS с закреплёнными отпечатками сертификатов участников (подмена сервера не пройдёт) и подписью каждого запроса ключом группы (HMAC-SHA256, защита от повтора по времени). При исключении участника ключ группы меняется — исключённый сервер больше не может получать данные. Файлы на исключённом сервере и на всех участниках при удалении группы сохраняются.

Отличия от DFS-R Windows

• Реплицируются серверы HopeDFS между собой; включить HopeDFS в группу репликации Windows DFS-R нельзя (переход с Windows — перенос данных и настройка группы в HopeDFS).
• Конфигурация групп хранится на участниках, а не в Active Directory; домен не нужен.
• Нет отчётов о работоспособности в формате DFS-R и dfsrdiag — состояние и отставание показывает панель и REST API.

16. Публикация в сети

Раздел «Публикация в сети»: как компьютеры находят сервер и его общие папки. Всё включается само после подключения к домену; панель показывает состояние по каждому имени и папке («Опубликовать сейчас» — повторить сразу). В кластере роль публикует узел, который её обслуживает (роль без плавающего IP — координатор); после переноса роли публикацию продолжает новый владелец.

Имена и DNS

Для каждой роли регистрируется запись A (AAAA) <роль>.<домен> → адрес роли (плавающий IP, у роли без VIP — адреса узла, а у сервера, установленного с BIND, — этот адрес). Для плавающего IP — и обратная запись PTR, если на сервере DNS есть зона обратного просмотра. Записи обновляются при смене адресов и имён и раз в 30 минут; записи удалённых ролей и псевдонимов удаляются.

«Проверить сервер и ключ» находит зону и создаёт и сразу удаляет пробную запись — так видно, принят ли ключ (некоторые серверы на неподписанное обновление отвечают «успешно», ничего не меняя). Сервер не в домене — укажите зону и сервер DNS вручную.

Псевдонимы. «Псевдонимы» у роли — дополнительные имена сервера: например, имя старого Windows-сервера, чтобы пути \\FILES\Docs и ярлыки продолжили работать после переезда. Каждое имя: регистрируется в DNS (записью A с адресом роли — так его разрешает любой сервер и клиент), видно в «Сети», сервер отвечает на него как на своё имя. Для входа доменных пользователей по Kerberos нужны SPN псевдонима: после изменения — «Домен» → «Обновить SPN» (учёткой с правом записи servicePrincipalName).

Общие папки в Active Directory

В свойствах общей папки — «Опубликовать в Active Directory» и ключевые слова. В каталоге создаётся объект «Общая папка» (volume) с путём \\<роль>.<домен>\<папка>, описанием и ключевыми словами — по умолчанию под учётной записью компьютера роли, как публикует Windows («Управление компьютером» → «Общие папки» → «Опубликовать»), или в заданном подразделении. Пользователи находят папку через «Сеть» → «Поиск в Active Directory» → «Общие папки». Изменение описания, переименование и снятие с публикации применяются сами.

Права в MS AD: первую публикацию выполните кнопкой «Учёткой администратора…» — HopeDFS делегирует учётке компьютера роли создание и удаление общих папок в её контейнере, дальше всё делается без администратора. HopeDC не принимает LDAP-вход учёток компьютеров — с ним задайте служебную учётку в разделе «Домен» или публикуйте учёткой администратора. FreeIPA / ALD Pro объектов «Общая папка» не имеют.

Папка «Сеть» Windows

Сервер виден в папке «Сеть» Проводника — как компьютер Windows с включённым сетевым обнаружением (протокол WS-Discovery): каждая роль и каждый псевдоним — отдельным компьютером с именем домена или рабочей группы. Двойной щелчок открывает список общих папок. Нужно открыть 3702/udp (многоадресная рассылка) и 5357/tcp (install.sh открывает их сам). Обнаружение работает в пределах сегмента сети (подсети), как у Windows; клиенты в других подсетях находят сервер по DNS. Выключается переключателем на вкладке «"Сеть" Windows».

Доменные пространства DFS

См. раздел 7: \\домен\Пространство хранится в AD, клиентов к серверам пространства направляет контроллер домена.

17. Защита от шифровальщиков

Шифратор на заражённом компьютере портит не только локальные файлы, но и подключённые сетевые диски — то есть шары HopeDFS. Каждое его изменение проходит через сервер, поэтому HopeDFS распознаёт атаку и останавливает её, пока испорчены единицы файлов. Раздел «Безопасность» → «Защита от шифровальщиков». Работает во всех редакциях; включена по умолчанию (режим «Блокировать», средняя чувствительность).

Как распознаётся атака

Реакция

• Блокировать (по умолчанию): источник атаки — учётная запись (или компьютер — настраивается) — сразу получает «только чтение» на всех шарах сервера и всех узлов кластера, включая уже открытые файлы. Остальные пользователи работают как обычно.
• Только оповещать: инцидент без блокировки — для первой недели на новом сервере, чтобы убедиться в отсутствии ложных срабатываний.
• Всегда: инцидент в панели, красный баннер на всех страницах, событие «Шифровальщик» в журнале аудита, запись в журнале службы, при желании — POST JSON на webhook (Slack, Mattermost, Teams или свой обработчик).

Сохранность и восстановление

• Как только источник совершил первое подозрительное действие, перед каждым его изменением файл копируется («страховочная копия»), а удаление превращается в перенос в хранилище защиты. Обычных пользователей это не касается — на их работу защита не влияет.
• При обнаружении делается снапшот затронутых шар (если у шары включены снапшоты — инкрементально).
• Хранилище защиты (<шара>/.hopedfs/ransom/) и снапшоты клиентам SMB недоступны: шифратор не может их удалить, в отличие от теневых копий Windows.
• В инциденте — журнал файлов и вкладка «Восстановление»: исходные версии возвращаются из страховочных копий или из снапшота, сделанного до первого касания файла шифратором; зашифрованные копии и записки переносятся в карантин (.hopedfs/ransom/quarantine/<инцидент>/). Ничего не удаляется. Файлы, которые пользователь законно создал или изменил в эти минуты и которые не похожи на зашифрованные, не трогаются.
• Копии без инцидента хранятся сутки, копии и карантин инцидента — 30 дней после его закрытия.

Включите расписание снапшотов у важных шар (свойства шары → «Предыдущие версии»): первые файлы атаки, испорченные до того, как источник стал подозрительным, восстанавливаются только из снапшота.

Что делать при инциденте

1. Отключите компьютер-источник от сети, проверьте его антивирусом или переустановите систему.
2. Смените пароль учётной записи.
3. Инцидент → «Восстановление» → «Восстановить».
4. «Разблокировать» и «Закрыть инцидент». «Ложное срабатывание» снимает блокировку и добавляет учётку в исключения.

Исключения и тонкая настройка

Служебные учётки и серверы резервного копирования, которые пишут на шары зашифрованные архивы, добавьте в исключения (учётные записи или IP-адреса). Расширения законно «случайных» файлов (gpg, hc, pfx, kdb…) не считаются признаком. Списки сигнатур редактируются; «По умолчанию» возвращает встроенные.

Проверка без риска: подключите шару тестовой учётной записью, включите показ скрытых файлов и переименуйте файл-ловушку — учётке запретится запись, появится инцидент. Затем «Разблокировать» и «Закрыть инцидент».

NFS

Защита действует и для клиентов NFS 4.0/4.1/4.2 — тот же анализ при закрытии файла, те же ловушки и сигнатуры, общая с SMB блокировка: источник, пойманный по SMB, не может писать и по NFS, и наоборот. Отличия: - Клиенты без Kerberos (sec=sys): номер пользователя сообщает сам клиент, сменить его ничего не стоит, поэтому при атаке блокируется и учётка, и компьютер (IP) — независимо от параметра «Кого блокировать». С Kerberos (krb5, krb5i, krb5p) пользователь проверен, блокировка — как для SMB. - Ловушки видны клиентам Linux (атрибута «скрытый» там нет). Изменение и переименование ловушки по NFS — атака; удаление — нет: его может сделать обычная очистка папки (rm, rsync --delete). Удалённые ловушки сервер восстанавливает сам. - Запрет записи источнику атаки по NFS — ошибка доступа (EACCES) на создание, запись, удаление, переименование и изменение атрибутов; чтение работает.

18. Роли и права панели

«Безопасность» → «Роли и права». Разграничение прав администраторов веб-панели: какие разделы видит пользователь и в каких может вносить изменения. Права проверяет сервер на каждом запросе API (в том числе перенаправленном в кластере другому узлу), интерфейс лишь скрывает недоступное.

Кто входит в панель. - Полный доступ без назначения — члены локальной группы Administrators сервера (в том числе через вложенные группы), Domain Admins, Enterprise Admins и групп администраторов из «Домен» → «Параметры подключения». Так было и до появления ролей — существующие установки работают без изменений. - По роли — любой локальный или доменный пользователь, которому (или группе которого) назначена роль. Остальным вход отклоняется: «у пользователя нет прав на панель HopeDFS».

Роли. Системные, не изменяются: | Роль | Права | |---|---| | Администратор | полный доступ ко всем разделам, включая «Роли и права» | | Аудитор | просмотр всех разделов, никаких изменений |

Свои роли — «Создать роль» (или «Создать копию» существующей): название, описание и матрица прав — повторяет меню панели, по каждому разделу две галочки: - Просмотр — раздел виден в меню, данные доступны для чтения; - Изменение — создание, правка, удаление в разделе (включает просмотр).

Галочка группы меню («Файловый сервер», «Безопасность», «Отказоустойчивость», «Настройки») отмечает все разделы внутри. «Обзор», «Журнал аудита» и «Журнал службы» — только просмотр. «Полный доступ (администратор)» равнозначен системной роли «Администратор».

Действия, не относящиеся к одному разделу: списки общих папок, узлов и ролей кластера, меток МРД и окно выбора пользователей и групп доступны любой роли (нужны в нескольких разделах). «Проверить связь» с доменом и проверка DNS в «Публикации» — действия просмотра.

Назначения — вкладка «Назначения» → «Назначить роль»: пользователи или группы (локальные и доменные, через окно выбора) и роль. У пользователя или группы одна роль; если пользователь получает роли из нескольких назначений (свою и групп), права складываются. Доменные группы пользователя берутся при входе, локальные — по текущему составу: изменение назначений и состава локальных групп действует на открытые сеансы сразу, без повторного входа. Удаление локальной учётки или группы снимает и её назначение.

Защита от расширения прав. Пользователь с ролью без полного доступа, которому выдано изменение «Ролей и прав» или «Локальных учёток», не может: - создать или изменить роль с правами, которых нет у него самого, выдать полный доступ; - назначить или снять роль шире своей; - менять учётки и группы, права которых в панели шире его прав: администраторов, членов Administrators, группы с назначенной широкой ролью, — менять им пароль, включать в Administrators, менять состав таких групп; - менять список групп администраторов в настройках домена.

Что видит пользователь с ролью. В меню — только разделы с правом просмотра; при входе открывается первый доступный. В разделе без права изменения в шапке — метка «Только просмотр», кнопки действий неактивны. Открытый по ссылке недоступный раздел — «Нет доступа к разделу». Под именем пользователя в меню — его роли.

Аудит. Создание, изменение и удаление ролей, назначение и снятие ролей пишутся в журнал аудита (в кластере — на координаторе, ?node=all в журнале показывает записи всех узлов); отказ во входе без прав — событие panel_login с отметкой «нет прав на панель».

Пример — оператор общих папок: «Общие папки» (изменение), «Сеансы и файлы» (изменение), «Предыдущие версии» (изменение), «Файлы и разрешения» (просмотр), «Обзор». Служба безопасности: «Журнал аудита», «Защита от шифровальщиков» (изменение), «Мандатный доступ» (изменение), «Сеансы и файлы» (просмотр).

19. Обновления

«Настройки» → «Обновления» (только администратор с полным доступом, как в HopeDC). Новые версии HopeDFS ставятся из панели — онлайн или из файла для закрытого контура. Из панели ставятся сборки 1.1.0 и новее; первая установка 1.1.0 — скриптом развёртывания.

Версия. Версия HopeDFS — номер сборки, как в HopeDC: v151, v152… (каждая новая сборка — следующий номер). Вверху — текущая версия, время сборки и архитектура, доступная версия и итог последней проверки. hopedfs --version на сервере показывает то же («HopeDFS 151 (сборка …)»). Сборки до v151 нумеровались 1.x.y (1.5.0 соответствует v150); любой номер сборки считается новее версии 1.x.y, поэтому узлы с прежней нумерацией обновляются из панели как обычно. Тот же номер показывают «Обзор», «Кластер» и «Репликация».

Онлайн-источник. Сервер обновлений (или внутренний веб-сервер организации) публикует манифест — JSON:

{
  "stable": { "version": "152", "url": "hopedfs_v152.gz", "sha256": "<sha256 файла .gz>", "notes": "Что нового" },
  "beta":   { "version": "153-beta", "url": "...", "sha256": "...", "notes": "..." }
}

version — номер сборки (можно с v: v152). Можно без каналов — один объект {version, url, sha256, notes}; относительная ссылка считается от адреса манифеста. Без sha256 пакет не устанавливается; скачанный пакет с другой суммой отклоняется (повреждён или подменён). Канал (stable/beta), адрес и автопроверка (раз в сутки, о новой версии — запись в журнале службы) общие для всех узлов кластера. Используйте HTTPS; http — только во внутренней доверенной сети.

Из архива (закрытый контур). Загрузите hopedfs.gz из комплекта поставки (или распакованный бинарник): пакет распаковывается и проверяется — исполняемый файл Linux нужной архитектуры, пробный запуск --version от непривилегированного пользователя (nobody), версия не ниже 1.1.0; показываются версия и SHA-256 файла — сверьте её с контрольной суммой поставщика (hopedfs.gz.sha256). Поле «Версия» необязательно: если указать, пакет с другой версией будет отклонён.

Установка («Установить v152», подтверждение): 1. служба проверяет пакет ещё раз и передаёт его установщику — прежнему бинарнику, запущенному отдельной временной службой systemd (systemd-run), чтобы перезапуск HopeDFS его не остановил; 2. установщик сверяет SHA-256, сохраняет текущий бинарник как /opt/hopedfs/hopedfs.prev, ставит новый и перезапускает службу; 3. ждёт до 90 секунд, пока панель ответит новой версией; иначе возвращает прежний бинарник и перезапускает службу — «Откат выполнен», причина — journalctl -u hopedfs.

Ход установки (загрузка, проверка, замена бинарника, перезапуск) виден на странице; во время перезапуска панель узла несколько секунд недоступна, подключения SMB/NFS переподключаются сами. Журнал установщика — journalctl -t hopedfs-update. Конфигурация, учётки, лицензия и данные не затрагиваются. Запуск установки и её итог (установлено / не установлено с причиной), загрузка и удаление пакета, смена источника — в журнале аудита.

Кластер. Список узлов с их версиями; узлы обновляются по одному — выберите узел вверху страницы (действия выполняются на нём). Перед обновлением узла, обслуживающего роли, приостановите его в «Кластере», чтобы роли переехали заранее. Разные версии на узлах допустимы на время поэтапного обновления.

Требования. Сервер под управлением systemd (systemd-run, systemctl) — как при установке install.sh; иначе раздел предложит обновить скриптом развёртывания. При истёкшей лицензии раздел работает.

20. Лицензионное соглашение (EULA)

Использование HopeDFS регулируется Лицензионным соглашением с конечным пользователем — договором присоединения (ст. 428, п. 5 ст. 1286 ГК РФ). Текст на русском языке встроен в программу; он же — документ 8 «Лицензионное соглашение» (Лицензионное соглашение).

Где посмотреть текст: - страница https://<сервер>:7443/eula — без входа (ссылка на странице входа «Используя HopeDFS, вы принимаете условия Лицензионного соглашения»), с кнопкой печати; - раздел «Лицензия» → карточка «Лицензионное соглашение» → «Открыть соглашение»; - на сервере: hopedfs --eula (текст без разметки, редакция и SHA‑256) и файл /opt/hopedfs/EULA.txt (кладёт install.sh, обновляет сама служба после обновления из панели).

Принятие. При первом входе в панель (и после выхода новой редакции соглашения) вместо разделов показывается окно с текстом соглашения и галочкой «Я прочитал(а) Лицензионное соглашение, принимаю его условия от имени организации… и подтверждаю свои полномочия»: - «Принимаю» — доступно только полному администратору панели (члены Administrators, группы администраторов домена, роль «Администратор»); пользователи с ограниченной ролью видят «Соглашение должен принять полный администратор панели» и кнопку «Выйти»; - «Не принимаю» — выход из панели.

Фиксируются редакция и SHA‑256 текста, учётная запись, IP‑адрес, браузер (User‑Agent), время, имя узла и версия HopeDFS — в /var/lib/hopedfs/eula_acceptance.json (права 0600) и в журнале аудита (событие eula). Сведения видны в разделе «Лицензия». Каждый узел кластера хранит свою запись — соглашение принимается на каждом узле, в панель которого входят администраторы.

До принятия: API панели отвечает 428 (code: "eula_required") — кроме входа, сведений о сеансе и самого соглашения. Службы от принятия не зависят: SMB, NFS, кластер, репликация между площадками, межсерверные обращения (в том числе настройка репликации с другого сервера) работают всегда.

Английский интерфейс показывает русский текст с пометкой, что юридически действует русский текст (п. 20.6).

Для автоматизированных стендов принятие можно задать переменной окружения HOPEDFS_EULA_ACCEPTED=1 (в разделе «Лицензия» будет отмечено, что запись о принятии отсутствует). В рабочей установке не используйте.

Компоненты третьих лиц — отдельный документ 9: перечень компонентов с открытым исходным кодом, их правообладателей и тексты лицензий. В программу не встраивается; входит в комплект документации и предоставляется по запросу (Лицензионное соглашение, п. 11.1).

21. Путеводитель: «Начало работы» и подсказки

В панель встроен путеводитель, который ведёт оператора с первого входа (как в HopeDC). У него две части.

1. «Начало работы» — чек-лист первичной настройки сервера. Кнопка «Начало работы N/M» — в шапке панели; N/M — сколько обязательных пунктов выполнено. При первом входе полного администратора (после принятия Лицензионного соглашения) чек-лист открывается сам. Каждый пункт объясняет, зачем он нужен и когда считается выполненным; «Перейти» открывает нужный раздел.

Состояние пунктов определяется по настройкам при каждом открытии — отмечать вручную ничего не нужно. Если пункт сделан иначе, чем проверяет панель (например, время синхронизирует аппаратный источник), полный администратор нажимает «Отметить»; отметка общая для узла, снимается кнопкой «Снять отметку» и пишется в журнал аудита. Чек-лист виден только полному администратору панели.

2. Подсказки по страницам. При первом открытии раздела панель подсвечивает его ключевые элементы и в карточке объясняет, что с ними делать. Управление: «Далее» / «Назад» (или стрелки ← →), «Пропустить» или Esc — закрыть подсказку этой страницы, «Не показывать подсказки» — выключить их для своей учётной записи. Кнопка «?» в шапке в любой момент повторяет подсказку текущей страницы; повторить все подсказки заново — ссылка «Повторить подсказки по страницам» внизу чек-листа. Подсказки показываются всем пользователям панели, но только в разделах, разрешённых их ролью.

Прогресс (пройденные подсказки, выключены ли они, открывался ли чек-лист) хранится на узле отдельно для каждой учётной записи (по SID) — в файле onboarding.json каталога данных (права 0600). На другом компьютере или в другом браузере подсказки повторно не показываются, у нового оператора начинаются сначала. В кластере прогресс у каждого узла свой.

API. GET /api/onboarding — состояние путеводителя текущей учётки (и чек-лист — для полного администратора). POST /api/onboarding с полем action: tour_done (+id), tours_reset, tours_off, tours_on, checklist_seen, mark (+id, done; только полный администратор). Доступно любому вошедшему пользователю панели, в том числе при замороженном управлении (истёкшая лицензия).

22. Почта, уведомления и восстановление доступа

Сервер исходящей почты

Раздел «Настройки → Почта и уведомления». HopeDFS не принимает почту — он отправляет письма через сервер почты организации (Exchange, Hope Mail Server, Postfix и т. п.):

«Отправить тестовое письмо» отправляет письмо с параметрами, введёнными в форме, — их можно проверить до сохранения. Ошибка показывается понятным текстом: сервер не отвечает, отклонил вход, сертификат не прошёл проверку, сервер не предлагает вход на этом подключении. Исходящие соединения — к серверу почты по выбранному порту (587, 465 или 25).

Уведомления

Включите «Отправлять уведомления по почте», укажите получателей (по одному адресу в строке или через запятую, до 50) и отметьте галочками, о чём сообщать:

Письма уходят сразу при событии, в фоне. Состояния (место, квоты, срок лицензии, обмен репликации) проверяются раз в 5 минут; письмо приходит при переходе через порог и при возврате в норму, а не каждые 5 минут — отметки хранятся в /var/lib/hopedfs/notify_state.json и переживают перезапуск службы. Не больше 20 писем в час по одному событию. Каждый узел кластера сообщает о своих событиях; тема письма начинается с [HopeDFS <узел>]. «Проверить» отправляет получателям письмо со списком выбранных событий. «Журнал отправки» показывает последние письма и ошибки (/var/lib/hopedfs/notify_log.json, 100 записей).

Восстановление доступа к панели

На странице входа — ссылка «Забыли пароль?» (как в HopeDC). Два способа:

• По почте — для локальных учёток сервера. Пользователь вводит имя учётки или адрес почты из её свойств. Если учётка есть и включена, создаётся одноразовая ссылка сброса пароля (действует 30 минут): при настроенном сервере почты и указанном адресе она уходит письмом на этот адрес, иначе записывается на сервере в файл /var/lib/hopedfs/password_reset_link.txt (права 0600). Ответ одинаковый для любых имён — по нему нельзя узнать, существует ли учётка. По ссылке открывается страница «Новый пароль»; новый пароль действует и для панели, и для подключения к шарам. Новый запрос гасит прежнюю ссылку. В конфигурации хранится только SHA-256 ссылки, поэтому в кластере ссылка работает на любом узле. Пароль доменной учётки меняется в домене.
• Аварийное — когда почты нет, сервер в закрытом контуре или все администраторы потеряли пароли. Панель показывает код запроса с отпечатком узла (как запрос лицензии). Код передаётся вендору любым каналом; вендор выпускает токен восстановления, подписанный ключом сервера лицензий HopeDFS, с новым паролем. После вставки токена панель показывает, для какого сервера и учётки он выпущен, и предупреждает, если отпечаток не совпадает или срок истёк. Токен принимается только на этом узле, до срока действия и один раз. Пароль учётки (по умолчанию Administrator) становится паролем из токена; если учётки нет, она создаётся в группе Administrators. Сразу после входа смените пароль.

Каждый запрос, смена пароля и отклонённый токен пишутся в журнал аудита (событие password_reset) и, если включено, приходят уведомлением. Не больше 10 попыток каждого действия за 15 минут с одного адреса. Сброс из консоли сервера по-прежнему доступен: hopedfs set-password Administrator '…'.

Формат аварийного токена (для сервера лицензий): RS256-JWT, ключ — тот же, что у лицензий HopeDFS; утверждения sub — отпечаток узла, purpose — admin-recovery, product — HopeDFS, iss — HOPE-LICENSE-SERVER, exp — срок, new_password — новый пароль (не короче 8 символов), user — учётка (необязательно, по умолчанию Administrator), jti — идентификатор для однократного применения.

API. Без входа: POST /api/auth/recover-request (identifier), GET /api/auth/recover-check?token=, POST /api/auth/recover-reset (token, password), GET /api/auth/recovery-request (код запроса), POST /api/auth/recover-emergency (token). С правом раздела «Почта и уведомления»: GET /api/mail, PUT /api/mail/smtp, PUT /api/mail/notify, POST /api/mail/test, POST /api/mail/test-notify.

23. Тема оформления и язык панели

В шапке панели рядом с переключателем языка RU / EN — переключатель темы из трёх кнопок: ☀ светлая, ☾ тёмная, 🖥 как в системе (тема следует за настройкой операционной системы и меняется вместе с ней). Те же переключатели есть на страницах входа и восстановления доступа.

Тема и язык — личные настройки учётной записи. Выбор сохраняется на сервере — в конфигурации кластера по SID учётки (поле user_prefs), поэтому действует на любом узле кластера и с любого устройства. При входе панель один раз применяет настройки учётки: тема не выбиралась — светлая (а не тема предыдущего пользователя этого браузера); язык не выбирался — запоминается тот, с которым выполнен вход. На общем компьютере каждый пользователь видит свою тему и свой язык. Менять свои настройки может любая учётка с доступом к панели, в том числе с ролью «только просмотр» и при истёкшей лицензии. При удалении локальной учётки её настройки удаляются.

Тема переключается без перезагрузки страницы с плавным переходом; при открытии панели нужная тема ставится до первой отрисовки, без вспышки светлого экрана. Последний выбор хранится и в браузере (localStorage) — для быстрого старта и для страницы входа. Печать всегда выполняется в светлых цветах.

API. POST /api/auth/prefs — {"theme": "light|dark|system", "lang": "ru|en"} (любое из полей), ответ — действующие настройки учётки. Настройки также приходят в ответе на вход (/api/auth/login, поле prefs) и в /api/auth/me. В кластере запрос выполняет координатор (как любое изменение конфигурации).