From: "Денис Черносов" <denis0.ru@gmail.com> To: "ALT Linux Community general discussions" <community@lists.altlinux.org> Subject: [Comm] Мысль по поводу организации общего файлохранилища (для обсуждения) Date: Wed, 10 Dec 2008 11:30:26 +0400 Message-ID: <d77783290812092330t40dc325r9a7b5da64faf18e3@mail.gmail.com> (raw) Навеяно вот этой статьей и экспериментами с Ruby On Rails и вдохновением от wiki-технологий: http://www.calculate-linux.ru/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F_%D1%84%D0%B8%D0%BB%D1%8C%D0%BC%D0%BE%D0%B2 Проблема: Чаще всего общие файлохранилища превращаются в файлопомойки, в которых даже хозяева файлов не могут разобраться. Это и перерасход места и потери рабочего времени на поиск и многочисленные дублирования со всеми вытекающими. Плюс целый букет проблем из области безопасности: трудности с настройками резервного копирования утечка корпоративных секретов, нелицензионный софт и пиратский медиаконтент и т.п. Отказ от файловых систем в пользу систем документооборота не всегда оправдан, поскольку накладывает достаточно много других ограничений и лишает традиционных преимуществ - понятность абстракции, высокое быстродействие и т.п. Причины: 1) отсутствие общепринятых паттернов файловой иерархии для большинства случаев (включая соглашения об именовании файлов и каталогов и разделения доступа к ним). Их не предлагают по умолчанию в таких продуктах, как Samba или Nfs (примеры настройек для папок верхнего уровня не в счет - это просто специализация файлопомоек) и этому не учат ни в школах ни на курсах. Замкнутый круг - культуры нет, потому что её нет нигде. 2) отсутствие автоматических средств для быстрой организации умолчальных деревьев каталогов, выставления прав на них, заполнения и актуализации метаинформации о содержимом каталогов, автоматическом перемещении, переименовании, удалении файлов и каталогов. Нет смысла обвинять пользователей в том, что они не хотят выполнять изо дня в день работу более подходящую для роботов. При наличии формализованных соглашений, становится возможным создание скриптов на все случаи жизни (как это сделано в Ruby On Rails). Остается только один вопрос - как, не порождая новых сущностей (хотя бы на стороне клиента) и зависимостей реализовать это на базе samba, nfs, ftp. Очевидно, через адресацию - несуществующий адрес воспринимается, как команда и при осмысленности этой команды и наличии достаточных прав на её выполнение - вуаля! Что интересно - можно прикручивать этот модуль для отработки именно несуществующих адресов, а это практически не повлияет на быстродействие системы в целом. А в качестве доп. вкусностей еще мечты: при наличии проблем, диагностическое сообщение (возможно с предугадываниями, типа "наверное вы хотели вот этого" и/или подсказками - "если хотите того, то начните сначала с этого"). Преимущества: Будучи единожды разработанным, такой модуль будет легко адаптируемым для самых разных файловых (а может и других) систем и ситуаций, потому что каждая команда будет всего лишь набором нескольких элементарных команд... Которые нужно выполнять в контексте безопасности того пользователя, который породил команду. Скрипты будут настраиваемы даже начинающими администраторами. И все эти настройки будут совершаться на стороне сервера. Как доп. опция реализации - позволить клиенту хранить в сетевой домашней папке собственные скрипты и проверять их наличие вместе с общесистемными. Это дополнительный уровень удобства, который также повысит склонность пользователей к формализации структуры каталогов и именования файлов. Что скажете? Баян? Утопия?
next reply other threads:[~2008-12-10 7:30 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-12-10 7:30 Денис Черносов [this message] 2008-12-10 10:24 ` [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения ) Yuri Bushmelev 2008-12-10 11:12 ` Денис Черносов 2008-12-10 11:26 ` Yuri Bushmelev 2008-12-10 11:49 ` Денис Черносов
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=d77783290812092330t40dc325r9a7b5da64faf18e3@mail.gmail.com \ --to=denis0.ru@gmail.com \ --cc=community@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Community general discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 community community/ http://lore.altlinux.org/community \ mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com public-inbox-index community Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.community AGPL code for this site: git clone https://public-inbox.org/public-inbox.git