|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Michael Tolokonnikov 2:5020/400 28 Jun 2002 23:57:57
To : Valentin A. Alekseev
Subject : Re: Файлопомойки
--------------------------------------------------------------------------------
Hello Valentin
Тут резать буду безжалостно, но постараюсь сохранить смысл.
Еще раз. Есть опыт работы в сети, некоторым образом, стихийно
сложившейся. Есть возможность полной перестройки сети. К тому-же эта
возможность подкрепляется переездом фирмы в новое помещение.
Предпринята попытка разработки математической модели сети с учетом
возможностей юникс. Hесмотря на мой очень небольшой опыт, в юниксе
возможности найдены такие, что M$ и не снились.
Мат.модель строится идеальная. Затем определяется (эмпирически) точка
минимакса между затратами по разработке дополнительного софта,
удобством, а следовательно и надежностью администрирования, удобством
пользователей и административным террором.
> ... по мере роста пользователей и их задач/полномочий количество групп
> будет стремительно увеличиваться. И админу "придется ползать на карачиках" в
> обнимку с find для отработки политики доступа ;)
Уже не приходится. С помощью сообщества эхи (Спасибо ответившим!) и
команды find ...-inum ... -follow получаю список всех путей доступа.
Поскольку команда выполняется долго, в будущем думаю сделать шаблон.
Юзер будет посылать запрос на сервер почтой и почтой-же получать ответ.
> MT> ...такие экзотические вещи, как циклы,
> Hу это уж совсем анархия а не структурированное хранилище...
Конечно анархия, но find и с этим справился, видимо проверяет найденные
пути и в циклы не валится!
> По ходу дела - административный диктат принесет гораздо больше пользы чем
> любые системы автоматизации.
Все-таки, как ты ниже говоришь, их оптимальное сочетание.
> MT> Hа вопросы юзеров "А почему...", я обычно отвечаю - "Компьютер, это
> MT> тупая скотина, которая делает не то, что ты от нее ХОЧЕШЬ, а то, что
> MT> ТРЕБУЕШЬ".
> Компьютер не скотина, компьютер это кусок железа, кремния и пластика
> собранного в соответствии с некоторыми пропорциями. Он думать не умеет, в
> отличии от скотины. Он делает _только_то_что_задаст_ему_программист_. Меня
> всегда учили так ;)))
Конечно, это тоже самое, только другими словами :)))
> MT> Чтоб решить кому-какой, думаю достаточно матрицы юзер/ресурс, в
> MT> позициях которой записаны права. Hа основании такой матрицы легко
> MT> группировать ресурсы и даже в (полу)автомате генерировать
> MT> дополнительные группы пользователей.
> Матричный контроль доступа хорош при ограниченном количестве
> субъектов/объектов. При большом количестве оных матрица будет очень большая,
> но очень не эффективная, так как многие ее поля будут совпадать. Оптимизация
> такой системы путем ссылок/шаблонов/правил по умолчанию очень скоро приведут
> эту таблицу к виду ACL собранных в конкретном месте на диске и
> субъективно представляемых как таблица.
Полностью согласен. В моем случае речь идет о 50-100 субъектах. А
объекты будут прописаны не все, а только узловые.
Да, кстати, Дж. Армстронг говорит, что на его компьютере имеется 110533
каталога и 110339 файлов (Секреты UNIX 2-е изд. Диалектика. стр.107).
Если нет очепятки, значит очень широко используются ссылки на каталоги.
У него, ИМХО, ФС структурирована.
Hовая (может только для меня?) мысль: не обязательно иметь единую
таблицу. Важные узлы системы могут содержать файл permission. Я своих
уже выдрессировал, любые права/доступы даю только на основании служебной
записки, заверенной... В этот файл и записывать: доступ такой-то
дан/снят тому-то, по распоряжению того-то. И не чесать потом репу, "а
почему pupkin ходит к koziavkin'у???"
К месту или не очень, открылось мне - файл по имени "..." (просто три
точки) в БЗД работает нормально, а по самбе не виден, у M$ наверное
крыша едет. Может и другие такие есть, не пробовал.
> MT> Я и ставлю задачу так, чтобы это работало прозрачно и удобно для
> MT> пользователей. И чтобы не уговаривать шефа - "Давайте распишем
> MT> структуру должностных обязанностей. Давайте создадим группу
> MT> "младший_бухгалтер_с_полномочиями_старшего_экономиста_для_учета_веник
> MT> ов"". И не должен он, как и любой другой юзер думать что есть какие-то
> MT> группы и т.п.
> Проблема в том, что я, например, не силен в том оборудовании, которым торгует
> моя контора и я не могу оценить кто и какой доступ должен иметь к какой
> документации.
А мы, админы, и не должны об этом ни знать, ни думать. Как и юзера о
группах. Шеф, в лучшем случае, ткнет пальцем в монитор: "Дай-ка эти
документы Сортир Сортирычу Унитазову." А систему я хочу построить так,
чтоб она мне подсказала как это лучше сделать. Только подсказала,
решение я сам приму.
> Я все-таки считаю, что тут победит смесь небольшой автоматизации с большой
> административной палкой. Всех возможных вариантов предусмотреть анализирующей
> системой не получится и "файлопомойка" будет медленно но разрастатся. Со
> стороны администратора можно лишь предложить методы каталогизации.
Конечно смесь! В пропорциях, приятных для употребления. Все возможные
варианты предусмотреть заранее и теоретически сложно. Файлопомойка,
естественно, будет разрастаться в силу законов энтропии. Мат.модель
должна отражать реальность с заданной степенью приближения. И от этой
степени, от правильности выбранной модели управления системой зависит
период, в течении которого развитие системы будет происходить без
применения "демократизатора".
Михаил Толоконников
mtolokonnikov@gm.ru
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
