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 возможно будет чем поделиться по существу и мне сейчас этот сценарий интересен, если появятся практические затыки в реализации.