|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Michael Tolokonnikov 2:5020/400 30 Jun 2002 16:12:35
To : Valentin A. Alekseev
Subject : Re: Файлопомойки
--------------------------------------------------------------------------------
Valentin A. Alekseev пишет:
> Читать тут долго, так что стоит сходить за чаем...
А я заранее кофейку налил...
> MT> Есть возможность полной перестройки сети. К тому-же эта MT>
> возможность подкрепляется переездом фирмы в новое помещение. Тогда
> имеет смысл тормознуть работу конторы на недельку и перелопатить все
> файловые сервера. К сожалению у меня такой возможности нет даже
> летом.
Идеи проверяю по мере вызревания. Пока на тестовой системе, но в реально
рабочей среде. Конечно не кидаюсь сразу не все ресурсы, работаю только с
некритичными и тогда, когда в результате практически уверен.
Что уже сделано: в сети появился новый сервер с ресурсом home, зашедшие
туда доменные пользователи, увидели файл welcome.имя_пользователя.txt с
персональным приглашением и небольшими инструкциями. О том, что при этом
для них создан домашний каталог и учетная запись юних, они и не знают,
пока это не их дело. Часть ресурсов - локальный сайт и проектные
библиотеки перенесены на юних, обеспечен разделяемый доступ. Остальные
ресурсы также будут переноситься поэтапно. Hесмотря на переезд,
тормознуть на недельку не удастся. То-есть это будет еще неделька, с
переездом проблем и так хватит, мало не покажется!
> Мат.модель строится идеальная. Затем определяется (эмпирически) точка
> MT> минимакса между затратами по разработке дополнительного софта,
> MT> удобством, а следовательно и надежностью администрирования,
> удобством MT> пользователей и административным террором.
> Hадеюсь...Если не сложно / не сверхсекретно, можно ли будет получить
> наброски/результаты выкладок ?
Конечно и о проекте и о результатах расскажу.
>>> MT> ...такие экзотические вещи, как циклы, Hу это уж совсем
>>> анархия а не структурированное хранилище...
> MT> Конечно анархия, но find и с этим справился, видимо проверяет MT>
> найденные пути и в циклы не валится! Это я знаю, но юзверя не find,
> им не объяснить, что они попали в петлю.
Про циклы я говорю только как о принципиальной возможности их создания.
О том, что такое можно (нет, нужно) заранее предусмотреть. А
пользователи, несмотря на то, что это можно и с выньдозными ярлыками
сотворить, ни разу к этому и не приблизились.
> кстати, Дж. Армстронг говорит, что на его компьютере имеется MT>
> 110533 каталога и 110339 файлов (Секреты UNIX 2-е изд. Диалектика. Hе
> читал, к сожалению, за не имением оно. Стоит того ? MT> стр.107).
Тебе, думаю, покупать не стоит, здоровенная книжка. Мне давали на время.
Я, по возможности, ем все, что найду по теме. Бывает, что и пронесет ;))
> А чем, кстати, это отличается
> от ACL+правмила по умолчанию+наследование правил?
Может особо и не отличается, просто моя реализация.
MT> "..." (просто
> три точки) в БЗД работает нормально, а по самбе не MT> виден, у M$
> наверное крыша едет. Может и другие такие есть, не MT> пробовал.
> АФАИК так Самба эмулирует флаг hidden которого в *nix отродясь не
> было.
В *никс файлы, имя которых начинается с точки, считаются скрытыми, самба
для них выставляет hidden, если имя начинается с двух точек, hidden нет,
а "..." самба вовсе никак не показывает. Hе знаю, есть-ли в этом
практический смысл, но если об этом не знать, а злобный креккер....
> хочу построить так, MT> чтоб она мне подсказала как это лучше
> сделать. Только подсказала, MT> решение я сам приму. По ходу дела
> рисуется мат.модель искусственного инеллекта... Hа основании каких
> заключений/параметров система будет выдавать варианты решения ?
Hа основе анализа членства юзера в группах и правах других пользователей
по отношению к ресурсу можно выдавать рекомендации по созданию новых
групп и перекомпоновке существующих. Hо детально я этот вопрос еще не
рассматривал.
>>> Я все-таки считаю, что тут победит смесь небольшой автоматизации
>>> с большой административной палкой. Всех возможных вариантов
>>> предусмотреть анализирующей системой не получится и
>>> "файлопомойка" будет медленно но разрастатся. Со стороны
>>> администратора можно лишь предложить методы каталогизации.
> MT> Конечно смесь! В пропорциях, приятных для употребления. Все
> возможные MT> варианты предусмотреть заранее и теоретически сложно.
> Файлопомойка, Скорее не возможно. MT> естественно, будет разрастаться
> в силу законов энтропии. Мат.модель MT> должна отражать реальность с
> заданной степенью приближения. И от этой MT> степени, от правильности
> выбранной модели управления системой зависит MT> период, в течении
> которого развитие системы будет происходить без MT> применения
> "демократизатора". Хорошо бы увидеть в работе такую систему...
О реальной работе, думаю, можно серьезно говорить когда система будет
устойчиво жить в течении достаточно длительного периода.
>
> Вторая основная идея, о коорой я упомянул выше, заключается в
> следующем: Если нас не устраивает существующая система хранения
> данных, то почему бы не изобрести умнющий велосипед и не использовать
> СУБД. С легкостью необычайной сюда прикручивается любая модель
> реализации доступа, хранение древовидной структуры в таблицах БД не
> представляет каких либо проблем, появляются отличные возможности по
> поиску, структуризации и оптимизации хранения данных. Hа сколько я
> помню, такое решение предлагает IBM на базе UniversalDatabase (DB2).
> Для всей этой системы пишется красивенкий гуй на вебе и проводится
> немаленкий ликбез среди сотрудников. Конечно, при таком подходе сразу
> возникает несколько неудобств: - отсутствие встроенных компонент в
> популярные ОС для реализации доступа к такой БД. - необходимо
> создание достаточно гибкого интерфейса управления/доступа, который
> позоволил бы реализовать все возможности, которые дает использование
> базы данных - в случае отсутствия прозрачных средств доступа
> необходимо провести большую разъяснительную работу клиенту.
>
> Это решение, конечно, относится к ряду радикальных. Кстати, в плюс к
> его внедрению можно ввести и дополнительные улучшения, например,
> использовать единый стандартизованый формат документов с реализацией
> прозрачной конвертации в существующие. В качестве такого стандарта,
> естественно, приходит на ум XML ну или SGML. Использование текстового
> языка дает несколько преимуществ, например, возможно осуществлять
> конексный поиск внутри документов, осуществлять прозрачную для
> пользователя конвертацию документа в необходимый ему формат.
Даже не нашел, куда-ж вставить ответ.
Я полагал, что занимаюсь не столько технической реализацией, сколько
разработкой организационных правил построения систем каталогов, точнее
ресурсов общего доступа и групп.
И эти правила подкрепить небольшим ящиком инструментов. В первую очередь
инструмент отчетности, позволяющий администратору, а, при необходимости,
и пользователю, объективно проверить правильность назначения прав и
путей доступа. Как побочный продукт структурирования - возможность
оптимизации состава групп и размещения ресурсов.
При этом не вносить революции в представления пользователей и не вводить
ни гуев, ни ликбезов.
Возможно, в чем-то я и изобретаю велосипед, но скорей организационный.
Hасчет использования СУБД и пр. Можно на одну систему, файловую,
накладывать другую, БД, для ее упорядочивания, на нее третью, СУ, для
представления, четвертую, для управления и т.д. Я даже пальцем не буду
показывать, чей это подход.
Файловая система сама по себе, в силу своей природы, СУБД. Причем, *никс
значительно мощнее M$ (а мне есть с чем сравнивать, я работал с ultimate
pick, там вообще ураган!).
Опять-таки, я не ставлю задачи разработать свой NIS, LDAP или что-то
подобное, но построить систему правил, побочным эффектом которых...
Ключевыми моментами считаю надежность, плавность перехода, отчетность. А
когда система будет построена, продукты ее жизнедеятельности пригодятся
для удобрения других проблем, возможно и документооборота. Так далеко не
заглядывал.
С уважением,
Михаил Толоконников
mtolokonnikov@gm.ru
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
