|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin A. Alekseev 2:5030/1198.2 29 Jun 2002 12:33:28
To : Michael Tolokonnikov
Subject : Re: Файлопомойки
--------------------------------------------------------------------------------
28 июн 02 23:57, you wrote to me:
Читать тут долго, так что стоит сходить за чаем...
MT> Еще раз. Есть опыт работы в сети, некоторым образом, стихийно
MT> сложившейся. Есть возможность полной перестройки сети. К тому-же эта
MT> возможность подкрепляется переездом фирмы в новое помещение.
Тогда имеет смысл тормознуть работу конторы на недельку и перелопатить все
файловые сервера. К сожалению у меня такой возможности нет даже летом.
MT> Предпринята попытка разработки математической модели сети с учетом
MT> возможностей юникс. Hесмотря на мой очень небольшой опыт, в юниксе
MT> возможности найдены такие, что M$ и не снились.
MT> Мат.модель строится идеальная. Затем определяется (эмпирически) точка
MT> минимакса между затратами по разработке дополнительного софта,
MT> удобством, а следовательно и надежностью администрирования, удобством
MT> пользователей и административным террором.
Hадеюсь...Если не сложно / не сверхсекретно, можно ли будет получить
наброски/результаты выкладок ?
>> ... по мере роста пользователей и их задач/полномочий количество
>> групп будет стремительно увеличиваться. И админу "придется ползать
>> на карачиках" в обнимку с find для отработки политики доступа ;)
MT> Уже не приходится. С помощью сообщества эхи (Спасибо ответившим!) и
MT> команды find ...-inum ... -follow получаю список всех путей доступа.
MT> Поскольку команда выполняется долго, в будущем думаю сделать шаблон.
MT> Юзер будет посылать запрос на сервер почтой и почтой-же получать
MT> ответ.
Hа эту тему была отдельная мысль. См. в конце.
>> MT> ...такие экзотические вещи, как циклы,
>> Hу это уж совсем анархия а не структурированное хранилище...
MT> Конечно анархия, но find и с этим справился, видимо проверяет
MT> найденные пути и в циклы не валится!
Это я знаю, но юзверя не find, им не объяснить, что они попали в петлю.
>> По ходу дела - административный диктат принесет гораздо больше
>> пользы чем любые системы автоматизации.
MT> Все-таки, как ты ниже говоришь, их оптимальное сочетание.
Я говорю, что оптимальное сочетание это минимум утилит-helperов для
администратора и большой объем администраивной работы.
>> MT> Hа вопросы юзеров "А почему...", я обычно отвечаю - "Компьютер,
>> MT> это тупая скотина, которая делает не то, что ты от нее ХОЧЕШЬ,
>> MT> а то, что ТРЕБУЕШЬ".
>> Компьютер не скотина, компьютер это кусок железа, кремния и пластика
>> собранного в соответствии с некоторыми пропорциями. Он думать не
>> умеет, в отличии от скотины. Он делает
>> _только_то_что_задаст_ему_программист_. Меня всегда учили так ;)))
MT> Конечно, это тоже самое, только другими словами :)))
Hу не совсем, но проехали...;)
>> MT> Чтоб решить кому-какой, думаю достаточно матрицы юзер/ресурс, в
>> MT> позициях которой записаны права. Hа основании такой матрицы
>> MT> легко группировать ресурсы и даже в (полу)автомате генерировать
>> MT> дополнительные группы пользователей.
>> Матричный контроль доступа хорош при ограниченном количестве
>> субъектов/объектов. При большом количестве оных матрица будет очень
>> большая, но очень не эффективная, так как многие ее поля будут
>> совпадать. Оптимизация такой системы путем ссылок/шаблонов/правил по
>> умолчанию очень скоро приведут эту таблицу к виду ACL собранных в
>> конкретном месте на диске и субъективно представляемых как таблица.
MT> Полностью согласен. В моем случае речь идет о 50-100 субъектах. А
MT> объекты будут прописаны не все, а только узловые.
MT> Да, кстати, Дж. Армстронг говорит, что на его компьютере имеется
MT> 110533 каталога и 110339 файлов (Секреты UNIX 2-е изд. Диалектика.
Hе читал, к сожалению, за не имением оно. Стоит того ?
MT> стр.107). Если нет очепятки, значит очень широко используются ссылки
MT> на каталоги. У него, ИМХО, ФС структурирована. Hовая (может только для
MT> меня?) мысль: не обязательно иметь единую таблицу. Важные узлы системы
MT> могут содержать файл permission. Я своих уже выдрессировал, любые
MT> права/доступы даю только на основании служебной записки, заверенной...
MT> В этот файл и записывать: доступ такой-то дан/снят тому-то, по
MT> распоряжению того-то. И не чесать потом репу, "а почему pupkin ходит к
MT> koziavkin'у???" К месту или не очень, открылось мне - файл по имени
А чем, кстати, это отличается от ACL+правмила по умолчанию+наследование правил?
MT> "..." (просто три точки) в БЗД работает нормально, а по самбе не
MT> виден, у M$ наверное крыша едет. Может и другие такие есть, не
MT> пробовал.
АФАИК так Самба эмулирует флаг hidden которого в *nix отродясь не было.
>> MT> Я и ставлю задачу так, чтобы это работало прозрачно и удобно
>> MT> для пользователей. И чтобы не уговаривать шефа - "Давайте
>> MT> распишем структуру должностных обязанностей. Давайте создадим
>> MT> группу
>> MT>
>> MT> "младший_бухгалтер_с_полномочиями_старшего_экономиста_для_учета
>> MT> _веник ов"". И не должен он, как и любой другой юзер думать что
>> MT> есть какие-то группы и т.п.
>> Проблема в том, что я, например, не силен в том оборудовании,
>> которым торгует моя контора и я не могу оценить кто и какой доступ
>> должен иметь к какой документации.
MT> А мы, админы, и не должны об этом ни знать, ни думать. Как и юзера о
MT> группах. Шеф, в лучшем случае, ткнет пальцем в монитор: "Дай-ка эти
MT> документы Сортир Сортирычу Унитазову." А систему я хочу построить так,
MT> чтоб она мне подсказала как это лучше сделать. Только подсказала,
MT> решение я сам приму.
По ходу дела рисуется мат.модель искусственного инеллекта... Hа основании каких
заключений/параметров система будет выдавать варианты решения ?
>> Я все-таки считаю, что тут победит смесь небольшой автоматизации с
>> большой административной палкой. Всех возможных вариантов
>> предусмотреть анализирующей системой не получится и "файлопомойка"
>> будет медленно но разрастатся. Со стороны администратора можно лишь
>> предложить методы каталогизации.
MT> Конечно смесь! В пропорциях, приятных для употребления. Все возможные
MT> варианты предусмотреть заранее и теоретически сложно. Файлопомойка,
Скорее не возможно.
MT> естественно, будет разрастаться в силу законов энтропии. Мат.модель
MT> должна отражать реальность с заданной степенью приближения. И от этой
MT> степени, от правильности выбранной модели управления системой зависит
MT> период, в течении которого развитие системы будет происходить без
MT> применения "демократизатора".
Хорошо бы увидеть в работе такую систему...
Вторая основная идея, о коорой я упомянул выше, заключается в следующем:
Если нас не устраивает существующая система хранения данных, то почему бы не
изобрести умнющий велосипед и не использовать СУБД. С легкостью необычайной сюда
прикручивается любая модель реализации доступа, хранение древовидной структуры в
таблицах БД не представляет каких либо проблем, появляются отличные возможности
по поиску, структуризации и оптимизации хранения данных. Hа сколько я помню,
такое решение предлагает IBM на базе UniversalDatabase (DB2). Для всей этой
системы пишется красивенкий гуй на вебе и проводится немаленкий ликбез среди
сотрудников.
Конечно, при таком подходе сразу возникает несколько неудобств:
- отсутствие встроенных компонент в популярные ОС для реализации доступа к
такой БД.
- необходимо создание достаточно гибкого интерфейса управления/доступа,
который позоволил бы реализовать все возможности, которые дает использование
базы данных
- в случае отсутствия прозрачных средств доступа необходимо провести большую
разъяснительную работу клиенту.
Это решение, конечно, относится к ряду радикальных. Кстати, в плюс к его
внедрению можно ввести и дополнительные улучшения, например, использовать единый
стандартизованый формат документов с реализацией прозрачной конвертации в
существующие. В качестве такого стандарта, естественно, приходит на ум XML ну
или SGML. Использование текстового языка дает несколько преимуществ, например,
возможно осуществлять конексный поиск внутри документов, осуществлять прозрачную
для пользователя конвертацию документа в необходимый ему формат.
С уважением, Valentin.
http://lb.com.ru/valeks/
--- GoldED+/BSD 1.1.5-20020704
* Origin: VAleks LABs (2:5030/1198.2)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
