mrrc
-
Posts
93 -
Joined
-
Last visited
Posts posted by mrrc
-
-
2 минуты назад, Olegin сказал:
В предыдущем посте не ту картинку вставил
Теперь ход мысли стал ясен.
Имеется небольшая задержка между выполнением команды из шелла и эффектом в сетевом окружении, но это не страшно, просто вначале сбило с толку. Благодарю, далее нужно построить скрипт.
-
5 минут назад, Olegin сказал:
Можете проверить, что это тоже самое, что из гуя
Действительно требуемый флаг проставляется на папку, однако ее исчезновение из списка шар не происходит!
Если же то же самое сделать из гуя, функционал работает правильно и папка пропадает из видимых.Может помимо установки флага через synoshare --setbrowse нужно и smb-сервис дергать? Иначе чего нет эффекта 🤨
-
5 минут назад, Olegin сказал:
Думаю, что это тоже самое что и из гуя - только на всю папку общего доступа.
Видимо эта функция работает как-то иначе (применительно к доступу по FTP\WebDAV), нежели целевая "Скрыть эту папку общего доступа в меню Сетевое окружение", когда общая папка не показывается в списке шар при smb доступе с рабочих станций.
Да и смысл то в том, чтобы накладывать на требуемые общие папки данный Restrictions после очередной процедуры репликации.
С синтаксисом не поможете?
-
В документации описывается переменная share_browsable:
Цитата1, show a shared folder in "My Network Places." 0, hide a shared
folder in "My Network Places."
Hiding a shared folder in "My Network Places" does not affect its
access right. The access right of the hidden shared folder will remain
unchanged. Users who have the proper access rights to the shared
folder can still access it by entering "\\server name\shared folder
name".Команда, которая устанавливает в свойствах папки галочку "Скрыть эту папку общего доступа в меню Сетевое окружение".
Переменная задается через команду synoshare, пытаюсь через терминал выстроить корректный синтаксис, но пока неудачно. Есть свежие головы?
После успеха планирую описать требуемые мне папки в скрипте и выполнять его через планировщик задач на целевом сервере после выполнения задач репликации.
-
Речь идет о репликации посредством инструментария Snapshot Replication, да.
Инструмент выбран осознанно из-за удобства быстрого восстановления работоспособности системы хранения и сохранности привязки всех прав доступа доменных пользователей к соответствующим шарам.
Пока целевая хранилка не используется пользователями по назначению (кроме как дополнительного DC обслуживаемой площадки), возможно поможет отключение в файловых службах сервиса SMB как такового. Скорее всего на выполнения репликаций и дополнительного бэкапирования необходимого Hyper Backup это не повлияет и решит задачу, но все равно в будущем хранилка будет использоваться по назначению для доступа к контенту по SMB для пользователей удаленной площадки, как я планирую.
Тоже думал в сторону выполнения скрипта над общими папками после выполнения ежесуточных процедур репликации, например проставляя атрибут скрытия данных реплицированных папок в "сетевом окружении". Но примера схожей реализации пока не нашел на просторах.
-
Имеются две территориально удаленные площадки с пользователями, соединенные между собой, на каждой размещено по одной хранилке, обе хранилки входят в доменную структуру, вернее сами являются DC для той площадки, на которой расположены.
С основной площадки ежесуточно настроена репликация общих папок на собрата на удаленную площадку.Проблема в следующем, что реплицируемые общие папки видны и доступны для чтения пользователям, что порой может создавать непонимание в структуризации хранилища данных.
Скрытие данных папок вручную в сетевом пространстве удаленной площадки, впрочем как и изменение прав к папкам работает до первой очередной репликации, когда все настройки видимость восстанавливается. Репликация, как инструментарий для резервирования, вещь весьма удобная, но описанный выше нюанс досаждает.
Есть идеи, как сделать общие папки с репликами на целевом сервере невидимыми\недоступными?
Надеюсь, понятно описал суть проблемы. -
26 минут назад, dj_nsk сказал:
а вы ждёте от него настройки правил маршрутизации
Не, не привередничаю)
Как раз-таки простота и унификация базовых подготовительных действий подразумевает отсутствие необходимости танцев с бубном, направленных предоставить интернет загрузчику для возможности автоматизации выполнения сборки.
Сценарий с DHCP применим не всегда же по месту. -
4 часа назад, dj_nsk сказал:
Не уверен, но - это искали?
К данному пункту изначально и обратился, но был удивлен отсутствием в нем возможности полноценно настроить сетевые настройки подключения. Там задаются только ip\mask, но конфигуратору загрузчика для сборки нужен доступ в интернет..
-
3 часа назад, mrrc сказал:
Да ладно?
Arc удивил, столь юзабилити приятный во всех отношениях загрузчик заставил спотыкнуться на пустом месте.
Маршрут и днс задал через командную строку загрузчика.
ip route add 0.0.0.0 via static_ip_address vi /etc/resolv.conf -
3 часа назад, mrrc сказал:
Что-то растерялся.
Парни, так я не ошибся и не нашел, а в ARCe действительно в конфигураторе не задать сетевые настройки статикой для возможности сборки\дальнейшей настройки DSM. Да ладно?
-
Что-то растерялся.
При отсутствии DHCP при конфигурировании загрузчика где задается шлюз\днс? Для ip\mask есть соответствующий раздел, но он не содержит требуемых значений.
-
В 04.02.2024 в 10:45, XPEH сказал:
В первом приближении система выглядит так
Создал для тестирования сценарий пока в едином сетевом сегменте, правда в качестве контроллера основного домена (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 возможно будет чем поделиться по существу и мне сейчас этот сценарий интересен, если появятся практические затыки в реализации.
-
3 минуты назад, XPEH сказал:
Synology Hyper Backup
Видимо на одном из этапов процедуры восстановления "Системы полностью"..
-
37 минут назад, XPEH сказал:
Пользователи иногда посещают и работают из другого офиса и им удобно иметь один домен и пароль, а также доступ к иx собственным папкам
Схожий сценарий с одним из моим теперешних объектов.
А от не доменных учеток, заведенных локально на АРМах в разных офисах, в которых подцеплены сетевые папки требуемые пользователю, отказались? Просто домен с территориально разнесенной инфраструктурой площадок пока все еще вызывает осторожность у меня.
-
6 минут назад, XPEH сказал:
при востановления после катастрофы просто востановить из бэкапа то, что понадобится. Например права на доступ.
А какие средства резервного копирования позволят нам с вами сделать подобное избирательное восстановление?
-
56 минут назад, XPEH сказал:
С пользователями возможно решение через домен.
Да, это вроде рабочий вариант и вы вот его подтверждаете положительным опытом применения.
А как решали повторным перенавешиванием прав пользователей по доступу к общим папкам или необходимость благо не возникала?
-
9 часов назад, XPEH сказал:
HA (High Availability)
Да, с учетом наличия двух как раз поддерживаемых HA девайсов в виде RS1619xs+ будем по итогу смотреть в эту сторону.
Но одно другого не исключает, поэтому интересны все варианты по теме.
8 часов назад, i926 сказал:mrrc имел другое ввиду. Тут обычная синхронизация серверов
На самом деле, HA возможен ну далеко не всегда по понятным причинам и тему поднял для общего понимания по вариативности решений, упрощающих и ускоряющих действия по восстановлению работоспособности в случае нештатных ситуаций. По итогу пока приходим к тому, что приложений, умеющих гибко работать по миграции базы заведенных пользователей не находится, а встроенный Export/import, который как минимум позволил бы развернуть имевшиеся аккаунты пользователей в новой среде по факту не работает как задумано?
-
15 часов назад, dj_nsk сказал:
Не, посмотрел внимательнее в ключе вопроса, не обнаружил обсуждаемого функционала в С2.
Это бэкап\восстановление в облако (весьма тормознутое) с определенными опциями.Может не обнаружил очевидного, конечно, но меня бы уже давно поправили, я думаю.
Отчасти то, про что говорим, это функционал встроенного функционала Export/import пользователей в одноименном разделе конфигурации. Это хотя бы тот минимум, который позволил бы переносить целиком учетки пользователей, ну а распределение прав к папкам общего доступа следующий ручной этап.
Экспорт по умолчанию в html\cvs, но принимающий аналогичный по dsm девайс не дает возможности принять данные, и не совсем очевидно, переносятся ли пароли списка пользователей. Кто-нибудь разобрался с этой возможностью?
-
1 час назад, i926 сказал:
Задумка у вас "мегамногоплановая", как осуществите, поделитесь обязательно ....)))
Да я бы сказал самая обыденная, подобный механизм предполагался мною если не в базе, то за счет расширенного функционала приложений, в том же функционале репликаций общий папок и механизме аварийного переключения\развертывания на другой устройстве.
Гляну вечером, в ссылке от @dj_nsk на одном из скринов присутствует файл user_account, вроде же в С2 шла речь про гибкие возможности. Только сомневаюсь, что можно взять такой архив с учетками накатить на новую локацию с восстановлением всех взаимосвязей в части прав доступа к развернутым общим папкам))
-
3 часа назад, dj_nsk сказал:
что там что-то подобное и озвучивалось (синхронизация данных по распределённым площадкам).
Это несколько иное, для территориально распределенных потребителей в виде Hybrid Share.
3 часа назад, dj_nsk сказал:А так, ваша же тема - это не "бэкап", а "катастрофоустойчивое решение". Искать его среди задач для бэкапа - не совсем верно.
Ну выйти с вопросом и ТЗ нужно же как-то для обвязки вопроса, применительно к реализациям сени.
-
5 часов назад, dj_nsk сказал:
это?
Облачную их хранилку я не пробовал, у вас имелся опыт в ключе вопроса?
Если гибкость решения позволит выполнить резервирование данных аккаунтов с их привязкой по правам доступа к общим папкам, то да. Но в любом случае, бэкап объемов самих данных общих папок в облако не предполагается в принципе в наше непростое время.
-
Выполнять репликации данных общих папок на территориально удаленное устройство, имея возможность оперативно "поменять" источник с целевым сервером местами, выполнив переключение. Удобно, понятно, прозрачно. Но, как быть с пользователями и их правами доступа к реплицируемым общим папкам, они то не передаются при репликациях и переключении источник\целевой сервер. Если их три, ладно, а если тридцать?
Отдельного инструмента, который бы умел сепаратно выполнять именно этот важный элемент резервирования и восстановления общей работоспособности NAS как NAS я не нахожу.
Либо систему\пакеты\данные целиком, либо какие-то их составляющие, но базу пользователей системы с привязкой по правам доступа к общим папкам решения нет?
Синхронизация папок и видимость папок с репликами на целевом сервере
in Програмное обеспечение
Posted
Через Планировщик задач под утро я и планирую шлифовать.
Просто в терминологии DSM это скрипт, заданный пользователем.
В сценарии выполнения построчно пропишу на каждую реплицируемую папку отдельную команду установки соответствующего флага.
Думаю так.