|
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) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.unix.bsd/1011d1ea0735.html, оценка из 5, голосов 10
|