|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Michael Tolokonnikov 2:5020/400 26 Jun 2002 13:28:39
To : Valentin A. Alekseev
Subject : Re: Файлопомойки
--------------------------------------------------------------------------------
Hello Valentin
Спасибо за участие в обсуждении.
Извиняюсь, будет длинно, но думаю, что этот тренд будет полезен не
только мне.
Мои размышления см.также о самба от 24.06.02.
> MT> 1.1. Минимальная глубина вложенности.
> Клиенту не удобно, структуризация ускоряет поиск.
> MT> 1.2. Доступ через систему ссылок.
> не совсем понял...
Позволю себе вернуться к постановке задачи. (Пока не слишком литературно
и не до конца прожеванное).
Была, и пока есть, NT сеть. Рассматриваются файловые ресурсы совместного
доступа.
Пока речь идет о персональных ресурсах, проблем не возникает. С
разделяемыми сложнее, однако на этапе проектирования и начального
развития сети складываются достаточно стройные структуры.
По мере роста аппетита юзеров возникают запросы типа "дайте доступ
тому-то к такому-то файлу". А как? В этом каталоге много других файлов
куда низззя. Сделать "ярлык"? Чтобы он работал нужен доступ к каталогу.
Значит "тому-то" надо не только дать доступ к файлу, но и запретить
доступ к остальным файлам ресурса.
Такие фокусы особенно любят сотрудники "аппарата управления" фирмы.
Это приводит к появлению множества шар на серверах и сетевых дисков у
клиента. Hастоящий кошмар начинается когда появляется новый сотрудник.
Админ на карачках ползает по sharing и security, чтобы добавить права
новому и не обрушить существующих. Аналогичные проблемы вызывает вопрос
"кто имеет доступ к этому файлу?". Опять на карачки, да еще восемь раз
ошибется при этом.
Ссылки *никсов - совсем другое дело. Ссылка честно дает файл, независимо
от возможности доступа к содержащему его каталогу.
# Здесь не сразу решил как писать, "возможности" или "прав".
# и то и другое, юзер может не иметь возможности попасть
# на эту ветвь структуры, кроме как по ссылке.
Ссылки позволяют структурировать ресурсы, представлять их виде структур,
отличных то "физического" размещения. Простейший пример тому - коллекция
packages на CD. Все packages лежат в каталоге all, а ссылки на них
собраны в тематические каталоги. Такие каталоги могут быть и
многоуровневыми. К тому-же ссылки могут играть роль закладок, позволяя с
верхних уровней "проваливаться" в самые глубокие слои помоек.
> MT> 1.3. Создание для ресурса одноименной группы, включающей пользователей
> MT> с правами, отличными от "прочих", например, "писателей".
> Hе рационально.
Почему? Как по другому? "Одноименная" здесь для удобства администрения
вручную, может быть и, не обязательно значимое, "синтетическое" имя группы.
> MT> 2. "Анализатор" - рекурсивный поиск всех ссылок на файл
> MT> и несущие его каталоги с составлением таблицы возможности доступа.
К этому еще не приступал. Возможны проблемы, связанные с тем, что могут
быть файлы с совпадающими именами и даже частью пути "глубоких уровней".
Hапример: ~pupkin/mydoc/text и ~utkin/mydoc/text. Кроме того могут
возникать и такие экзотические вещи, как циклы, когда ссылка из глубин
иерархии указывает на каталог верхнего уровня.
Вообще, опыт показывает, что, самые "стройноспроектированные" файловые
структуры имеют свойство самозагаживаться "идя навстречу пожеланиям
клиентам". И пожелания эти рождаются не капризами клиентов, а
производственной необходимостью. Справиться с этим можно или
административным диктатом и массовым террором или разработкой средств
автоматизации администрирования.
> MT> 3. Возможно, разработка "Синтезатора" и "Оптимизатора" прав доступа.
> Для нормально оптимизации хранилишь данных придется создавать системы data
> mining. Машина не настолько умна как человек, что бы решить кому и какой
> доступ дать в зависимости от огромного количества внешних параметров.
Hа вопросы юзеров "А почему...", я обычно отвечаю - "Компьютер, это
тупая скотина, которая делает не то, что ты от нее ХОЧЕШЬ, а то, что
ТРЕБУЕШЬ".
Чтоб решить кому-какой, думаю достаточно матрицы юзер/ресурс, в позициях
которой записаны права. Hа основании такой матрицы легко группировать
ресурсы и даже в (полу)автомате генерировать дополнительные группы
пользователей.
> MT> Полагаю так лучше, чем ждать милостей от ACL, да еще и получить
> MT> проблему совместимости с другими *никсами ;-))
> К сожалению на одном из моих серверов сейчас лежит только документации по
> оборудованию примерно на 1,5 гигабайта. Я могу раскидать все это по
> папкам/подпапкам, но этот подход не будет удобен для клиента, а уж у них своих
> проблем хватает, а тут еще и данные оптимизировать...
Я и ставлю задачу так, чтобы это работало прозрачно и удобно для
пользователей. И чтобы не уговаривать шефа - "Давайте распишем структуру
должностных обязанностей. Давайте создадим группу
"младший_бухгалтер_с_полномочиями_старшего_экономиста_для_учета_веников"".
И не должен он, как и любой другой юзер думать что есть какие-то группы
и т.п.
Для полного решения задачи попотеть, конечно, придется. Hа вскидку, тут
и теория графов, и задача коммивояжера, и прочая оптимизация-минимизация.
Михаил
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
