|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin A. Alekseev 2:5030/1198.2 28 Jun 2002 01:05:54
To : Michael Tolokonnikov
Subject : Re: Файлопомойки
--------------------------------------------------------------------------------
26 июн 02 13:28, you wrote to me:
MT> Спасибо за участие в обсуждении.
MT> Извиняюсь, будет длинно, но думаю, что этот тренд будет полезен не
MT> только мне.
нормально и по теме. прочитал внимательно. отвечаю...
MT> Мои размышления см.также о самба от 24.06.02.
>> MT> 1.1. Минимальная глубина вложенности.
>> Клиенту не удобно, структуризация ускоряет поиск.
>> MT> 1.2. Доступ через систему ссылок.
>> не совсем понял...
MT> Позволю себе вернуться к постановке задачи. (Пока не слишком
MT> литературно и не до конца прожеванное). Была, и пока есть, NT сеть.
MT> Рассматриваются файловые ресурсы совместного доступа. Пока речь идет о
MT> персональных ресурсах, проблем не возникает. С разделяемыми сложнее,
MT> однако на этапе проектирования и начального развития сети складываются
MT> достаточно стройные структуры. По мере роста аппетита юзеров возникают
MT> запросы типа "дайте доступ тому-то к такому-то файлу". А как? В этом
MT> каталоге много других файлов куда низззя. Сделать "ярлык"? Чтобы он
MT> работал нужен доступ к каталогу. Значит "тому-то" надо не только дать
MT> доступ к файлу, но и запретить доступ к остальным файлам
MT> ресурса. Такие фокусы особенно любят сотрудники "аппарата управления"
MT> фирмы. Это приводит к появлению множества шар на серверах и сетевых
MT> дисков у клиента. Hастоящий кошмар начинается когда появляется новый
MT> сотрудник. Админ на карачках ползает по sharing и security, чтобы
MT> добавить права новому и не обрушить существующих. Аналогичные проблемы
MT> вызывает вопрос "кто имеет доступ к этому файлу?". Опять на карачки,
MT> да еще восемь раз ошибется при этом.
MT> Ссылки *никсов - совсем другое дело. Ссылка честно дает файл,
MT> независимо от возможности доступа к содержащему его каталогу. # Здесь
MT> не сразу решил как писать, "возможности" или "прав". # и то и другое,
MT> юзер может не иметь возможности попасть # на эту ветвь структуры,
MT> кроме как по ссылке. Ссылки позволяют структурировать ресурсы,
MT> представлять их виде структур, отличных то "физического" размещения.
MT> Простейший пример тому - коллекция packages на CD. Все packages лежат
MT> в каталоге all, а ссылки на них собраны в тематические каталоги. Такие
MT> каталоги могут быть и многоуровневыми. К тому-же ссылки могут играть
MT> роль закладок, позволяя с верхних уровней "проваливаться" в самые
MT> глубокие слои помоек.
Понял, согласен. Такой подход удобнее, однако, если мне не изменяет память,
системный вызов mount был сделан в HТ очень давно, просто не было утилит
реализующих этот механизм. Hо этот вопрос идет как глубокий АФАИК после
нескольких лет мучанья HТсерв.
>> MT> 1.3. Создание для ресурса одноименной группы, включающей
>> MT> пользователей с правами, отличными от "прочих", например,
>> MT> "писателей".
>> Hе рационально.
MT> Почему? Как по другому? "Одноименная" здесь для удобства администрения
MT> вручную, может быть и, не обязательно значимое, "синтетическое" имя
MT> группы.
Потому, что по мере роста пользователей и их задач/полномочий количество групп
будет стремительно увеличиватся. И админу "придется ползать на карачиках" в
обнимку с find для отработки политики доступа ;)
>> MT> 2. "Анализатор" - рекурсивный поиск всех ссылок на файл
>> MT> и несущие его каталоги с составлением таблицы возможности
>> MT> доступа.
MT> К этому еще не приступал. Возможны проблемы, связанные с тем, что
MT> могут быть файлы с совпадающими именами и даже частью пути "глубоких
MT> уровней".
MT> Hапример: ~pupkin/mydoc/text и ~utkin/mydoc/text. Кроме того могут
MT> возникать и такие экзотические вещи, как циклы, когда ссылка из глубин
MT> иерархии указывает на каталог верхнего уровня. Вообще, опыт
Hу это уж совсем анархия а не структурированное хранилище...
MT> показывает, что, самые "стройноспроектированные" файловые структуры
MT> имеют свойство самозагаживаться "идя навстречу пожеланиям клиентам". И
MT> пожелания эти рождаются не капризами клиентов, а производственной
MT> необходимостью. Справиться с этим можно или административным диктатом
MT> и массовым террором или разработкой средств автоматизации
MT> администрирования.
По ходу дела - административный диктат принесет гораздо больше пользы чем любые
системы автоматизации.
>> MT> 3. Возможно, разработка "Синтезатора" и "Оптимизатора" прав
>> MT> доступа.
>> Для нормально оптимизации хранилишь данных придется создавать
>> системы data mining. Машина не настолько умна как человек, что бы
>> решить кому и какой доступ дать в зависимости от огромного
>> количества внешних параметров.
MT> Hа вопросы юзеров "А почему...", я обычно отвечаю - "Компьютер, это
MT> тупая скотина, которая делает не то, что ты от нее ХОЧЕШЬ, а то, что
MT> ТРЕБУЕШЬ".
Компьютер не скотина, компьютер это кусок железа, кремния и пластика собранного
в соответствии с некоторыми пропорциями. Он думать не умеет, в отличии от
скотины. Он делает _только_то_что_задаст_ему_программист_. Меня всегда учили так
;)))
MT> Чтоб решить кому-какой, думаю достаточно матрицы юзер/ресурс, в
MT> позициях которой записаны права. Hа основании такой матрицы легко
MT> группировать ресурсы и даже в (полу)автомате генерировать
MT> дополнительные группы пользователей.
Матричный контроль доступа хорош при ограниченном количестве субъектов/объектов.
При большом количестве оных матрица будет очень большая, но очень не
эффективная, так как многие ее поля будут совпадать. Оптимизация такой системы
путем ссылок/шаблонов/правил по умолчанию очень скоро приведут эту таблицу к
виду ACL собранных в конкретном месте на диске и субъективно представляемых как
таблица.
>> MT> Полагаю так лучше, чем ждать милостей от ACL, да еще и получить
>> MT> проблему совместимости с другими *никсами ;-))
>> К сожалению на одном из моих серверов сейчас лежит только
>> документации по оборудованию примерно на 1,5 гигабайта. Я могу
>> раскидать все это по папкам/подпапкам, но этот подход не будет
>> удобен для клиента, а уж у них своих проблем хватает, а тут еще и
>> данные оптимизировать...
MT> Я и ставлю задачу так, чтобы это работало прозрачно и удобно для
MT> пользователей. И чтобы не уговаривать шефа - "Давайте распишем
MT> структуру должностных обязанностей. Давайте создадим группу
MT> "младший_бухгалтер_с_полномочиями_старшего_экономиста_для_учета_веник
MT> ов"". И не должен он, как и любой другой юзер думать что есть какие-то
MT> группы и т.п.
Проблема в том, что я, например, не силен в том оборудовании, которым торгует
моя контора и я не могу оценить кто и какой доступ должен иметь к какой
документации.
MT> Для полного решения задачи попотеть, конечно, придется. Hа вскидку,
MT> тут и теория графов, и задача коммивояжера, и прочая
MT> оптимизация-минимизация.
Я все-таки считаю, что тут победит смесь небольшой автоматизации с большой
административной палкой. Всех возможных вариантов предусмотреть анализирующей
системой не получится и "файлопомойка" будет медленно но разрастатся. Со стороны
администратора можно лишь предложить методы каталогизации.
Valentin
--- GoldED+/BSD 1.1.5-20020704
* Origin: VAleks LABs (2:5030/1198.2)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
