mrrc

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

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

Действительно требуемый флаг проставляется на папку, однако ее исчезновение из списка шар не происходит! Если же то же самое сделать из гуя, функционал работает правильно и папка пропадает из видимых. Может помимо установки флага через synoshare --setbrowse нужно и smb-сервис дергать? Иначе чего нет эффекта 🤨

Видимо эта функция работает как-то иначе (применительно к доступу по FTP\WebDAV), нежели целевая "Скрыть эту папку общего доступа в меню Сетевое окружение", когда общая папка не показывается в списке шар при smb доступе с рабочих станций. Да и смысл то в том, чтобы накладывать на требуемые общие папки данный Restrictions после очередной процедуры репликации. С синтаксисом не поможете?

В документации описывается переменная share_browsable: Команда, которая устанавливает в свойствах папки галочку "Скрыть эту папку общего доступа в меню Сетевое окружение". Переменная задается через команду synoshare, пытаюсь через терминал выстроить корректный синтаксис, но пока неудачно. Есть свежие головы? После успеха планирую описать требуемые мне папки в скрипте и выполнять его через планировщик задач на целевом сервере после выполнения задач репликации.

Речь идет о репликации посредством инструментария Snapshot Replication, да. Инструмент выбран осознанно из-за удобства быстрого восстановления работоспособности системы хранения и сохранности привязки всех прав доступа доменных пользователей к соответствующим шарам. Пока целевая хранилка не используется пользователями по назначению (кроме как дополнительного DC обслуживаемой площадки), возможно поможет отключение в файловых службах сервиса SMB как такового. Скорее всего на выполнения репликаций и дополнительного бэкапирования необходимого Hyper Backup это не повлияет и решит задачу, но все равно в будущем хранилка будет использоваться по назначению для доступа к контенту по SMB для пользователей удаленной площадки, как я планирую. Тоже думал в сторону выполнения скрипта над общими папками после выполнения ежесуточных процедур репликации, например проставляя атрибут скрытия данных реплицированных папок в "сетевом окружении". Но примера схожей реализации пока не нашел на просторах.

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

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

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

Arc удивил, столь юзабилити приятный во всех отношениях загрузчик заставил спотыкнуться на пустом месте. Маршрут и днс задал через командную строку загрузчика. ip route add 0.0.0.0 via static_ip_address vi /etc/resolv.conf

Парни, так я не ошибся и не нашел, а в ARCe действительно в конфигураторе не задать сетевые настройки статикой для возможности сборки\дальнейшей настройки DSM. Да ладно?

Что-то растерялся. При отсутствии DHCP при конфигурировании загрузчика где задается шлюз\днс? Для ip\mask есть соответствующий раздел, но он не содержит требуемых значений.

Создал для тестирования сценарий пока в едином сетевом сегменте, правда в качестве контроллера основного домена (RWDC) выступает станция с 2012R2 с DNS, в дополнение к ней поднят Synology Directory Server в роли RODC и DNS сервером. В общем и целом схема понятна, развернута и частично работает, учетки пользователей синхронизируются между RWDC и RODC, за исключением главного. Пользователи и их пароли не реплицируются на RODC, когда прописываем их в группе с запрещением\разрешением репликации паролей RODC как разрешенные. Ни при первичной авторизации, ни при ручном добавлении через оснастку расширенных политик репликаций паролей на RWDC. Результурующая политика также отрабатывается правильно по учетке разрешенного на предыдущем шаге пользователя. Бьюсь и не могу понять, где моя ошибка. Соответственно если "ложится" основной контроллер домена с 2012R2, то у win-клиент с доменной учеткой утрачивает доступ к хранилкам, подключенным к домену, в т.ч. и на которой развернут сам RODC. ДНС при этом работает, доменные хосты резолвятся и серверы пересылки отрабатывают внешний мир, но т.к. сохраненных пользовательских учеток и их хешей паролей на RODC в одноименном разделе оснастки "Учетные записи, пароли которых хранятся на данном контроллере домена только для чтения" (там появились только комп с win-клиентом, сам RODC, krbtgt_12726 пользователь и дополнительная хранилка, включенная в домен) нет, но обращение висит или сразу вываливается с ошибкой. У клиента в качестве основного DNS первым идет RODC (можно и RWDC, не суть). После "оживления" основного контроллера все приходит в норму.

Ну вот видите сколь полезный и немассовый по примененному решению положительный опыт. А разворачивание схемы DC под Windows в роли RWDC и сопряжение с Synology Directory Server в роли RODC (быть может, наоборот) возможно у кого-то имелся? В части подводных камней и нюансов настройки.

В продолжении ранее затронутой темы в одном из топиков по реализации домена с территориально разнесенной инфраструктурой, когда пользователи могли бы мигрировать между офисами и использовать свои доменные учетные записи для авторизации на АРМах, поступило предложение вынести этот вопрос в отдельную одноименную тему на случай, если кому-то обсуждение окажется полезным и будет что дополнить. Будем считать для порядка и для практики (на практике так скорее всего и будет), что хотя бы в одном из офисов DC работает на базе Synology\Xpenology в виде развернутой на ней виртуальной среде или в виде приложения Synology Directory Server. Сценарий из практики. Имелся "главный офис" с работающим RWDC (Read Write Domain Controller), инфраструктура разрастается, сформировался территориально удаленное производство, временный канал связи между ними поднят, и туда постепенно перебираются "АРМ-ы" из главного офиса, ранее уже включенные в домен (работоспособность по месту имеется, первичный ДНС основного DC им доступен на АРМах, доменные учетки работают, хоть там пока и слабоватый канал связи между офисами) и ставятся новые пока без вхождения в домен. Пользователи периодически могут мигрировать между офисами. Нужно принимать решение, как действовать в части поддержания доменной инфраструктуры на обеих площадках или отказа от нее в удаленной агломерации. Для отказоустойчивости среды передачи данных по имеющейся апробированной практике поднимается RODC (Read Only Domain Controller) в удаленном офисе для обслуживания тамошних пользователей как дополнение к основному. В общем уважаемому @XPEH возможно будет чем поделиться по существу и мне сейчас этот сценарий интересен, если появятся практические затыки в реализации.

Видимо на одном из этапов процедуры восстановления "Системы полностью"..

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

А какие средства резервного копирования позволят нам с вами сделать подобное избирательное восстановление?

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

Да, с учетом наличия двух как раз поддерживаемых HA девайсов в виде RS1619xs+ будем по итогу смотреть в эту сторону. Но одно другого не исключает, поэтому интересны все варианты по теме. На самом деле, HA возможен ну далеко не всегда по понятным причинам и тему поднял для общего понимания по вариативности решений, упрощающих и ускоряющих действия по восстановлению работоспособности в случае нештатных ситуаций. По итогу пока приходим к тому, что приложений, умеющих гибко работать по миграции базы заведенных пользователей не находится, а встроенный Export/import, который как минимум позволил бы развернуть имевшиеся аккаунты пользователей в новой среде по факту не работает как задумано?

Не, посмотрел внимательнее в ключе вопроса, не обнаружил обсуждаемого функционала в С2. Это бэкап\восстановление в облако (весьма тормознутое) с определенными опциями. Может не обнаружил очевидного, конечно, но меня бы уже давно поправили, я думаю. Отчасти то, про что говорим, это функционал встроенного функционала Export/import пользователей в одноименном разделе конфигурации. Это хотя бы тот минимум, который позволил бы переносить целиком учетки пользователей, ну а распределение прав к папкам общего доступа следующий ручной этап. Экспорт по умолчанию в html\cvs, но принимающий аналогичный по dsm девайс не дает возможности принять данные, и не совсем очевидно, переносятся ли пароли списка пользователей. Кто-нибудь разобрался с этой возможностью?

Да я бы сказал самая обыденная, подобный механизм предполагался мною если не в базе, то за счет расширенного функционала приложений, в том же функционале репликаций общий папок и механизме аварийного переключения\развертывания на другой устройстве. Гляну вечером, в ссылке от @dj_nsk на одном из скринов присутствует файл user_account, вроде же в С2 шла речь про гибкие возможности. Только сомневаюсь, что можно взять такой архив с учетками накатить на новую локацию с восстановлением всех взаимосвязей в части прав доступа к развернутым общим папкам))

Это несколько иное, для территориально распределенных потребителей в виде Hybrid Share. Ну выйти с вопросом и ТЗ нужно же как-то для обвязки вопроса, применительно к реализациям сени.

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

Выполнять репликации данных общих папок на территориально удаленное устройство, имея возможность оперативно "поменять" источник с целевым сервером местами, выполнив переключение. Удобно, понятно, прозрачно. Но, как быть с пользователями и их правами доступа к реплицируемым общим папкам, они то не передаются при репликациях и переключении источник\целевой сервер. Если их три, ладно, а если тридцать? Отдельного инструмента, который бы умел сепаратно выполнять именно этот важный элемент резервирования и восстановления общей работоспособности NAS как NAS я не нахожу. Либо систему\пакеты\данные целиком, либо какие-то их составляющие, но базу пользователей системы с привязкой по правам доступа к общим папкам решения нет?