|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Michael Tolokonnikov 2:5020/400 28 Jun 2002 23:58:34
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
