Enterprise hub/ru

Эта страница предназначена для координации усилий различных коммьюнити для использования MediaWiki в корпоративных условиях.

Ресурсы Enterprise MediaWiki

На момент написания этой статьи мы все еще находимся на стадии становления, пытаясь создать сообщество MediaWiki Enterprise, следуя примеру Enterprise MediaWiki BOF на Wikimania 2006. Не вполне понятно, имеет ли смысл иметь сообщество, независимое от основного сообщества MediaWiki, но неплохо иметь эту дискуссию.

Списки рассылки

Список рассылки создан в августе 2006 для решения задач корпоративного использования MediaWiki. It's currently a low traffic list, so feel free to join and introduce yourself: mail:mediawiki-enterprise

IRC

There's not a dedicated IRC channel to enterprise issues, but the best thing to do if you'd like to discuss this is to pop onto the #mediawiki IRC channelchannel to discuss. Make sure that robla is paying attention if he's logged on (for example, by typing "/msg robla there's enterprise stuff on #mediawiki")

Другие каналы

Смотри страницу Communication/ru.

Issues for MediaWiki in the enterprise

Ниже приведены встречающиеся проблемы для пользователей MediaWiki в настройках enterprise. Некоторые проблемы, описанные ниже, обычно не являются проблемами для публичных интернет-версий MediaWiki. В то же время, другие проблемы являются таковыми, но могут быть не такими острыми, как для корпоративных пользователей.

Аутентификация

Большинство из развёрнутых в публичном доступе в Интернете решений на движке MediaWiki использует стандартную базу данных учётных записей, конфигурируемую по умолчанию при установке. Однако корпоративные решения обычно должны быть привязаны к собственной системе аутентификации. Некоторые ресурсы, которые помогут вам с этим:

• Интерфейс AuthPlugin - базовый интерфейс для создания новых аутентификационных плагинов.

Ограничение доступа на чтение

• Authorization plugins - not much as of MediaWiki 1.5....I'm guessing not much has changed. I'm planning to possibly discuss ways in which User.php could be overridden, extended, and/or stabilized as an extension interface. The idea would be a system where group memberships are stored in an external database, as well as capability assignments (e.g. LDAP group "admins" gets the "edit" capability on resource "MediaWiki: namespace") This is admittedly pretty fuzzy right now.

Read-restricted access

The core developers of MediaWiki don't have an interest in limiting read access to portions of a MediaWiki install. Since MediaWiki wasn't designed to be used in this way, it's very difficult to prevent accidental entry points to material for a determined user.

Here are just a few examples of ways of accessing content:

• Page transclusion
• Export hooks
• Page history
• Searching

If page names are meant to be confidential (e.g. "super secret contract between Foo Corp. and Bar Corp."), that just makes matters worse.

One suggestion from the Wikimania BOF:

You might set up a hot mirror. Point authors at the master wiki with htaccess protection, point users at a read-only mirrors. Once you set it up, maintenance is trivial. This tells how to mirror the OpenZaurus wiki: http://wiki.openzaurus.org/Admin/MirrorHowto . You may be able to adapt these instructions to set up your own master and any number of read-only mirrors. My mirrors update nightly; updates up to every 10 minutes should be feasible depending on the number and size of your pages. Contact me if you have any questions: bronson@rinspin.com

One subject for discussion on the mediawiki-enterprise mailing list is what interfaces could be added to the code such that an ACL-maniac extension to MediaWiki could exist, without a big support burden on the core team. [1]

Внешние авторизационные плагины

• What this means: being able to manage group memberships in external database rather than in internal database
• На самом деле не было сделано (?)
• How to do it: override User.php?
• Other hooks?
• OpenID is in MediaWiki svn. It's live at http://wikitravel.org/review/Special:OpenIDLogin
• Page by Page Access Control using Access Control Extension for MediaWiki

Новые механизмы распространения

• Debian package for MediaWiki
• RPM (?)
• Does a PEAR distribution make sense?
• Does it make sense to package MediaWiki extensions as .deb/.rpm/PEAR thingies?
• I mentioned automating maintaining multiple instances using svk during the talk. It works well. I will try to write an article about it in the next few days; check http://u32.net or bug me: bronson@rinspin.com

• New distribution mechanisms. There's already a Debian package for

MediaWiki, I'm assuming there's an RPM out there. Does a PEAR distribution make sense? Does it make sense to package MediaWiki extensions as .deb/.rpm/PEAR thingies?

Structured data in enterprise use

• Wikidata
• Semantic MediaWiki
• Wikicalc http://softwaregarden.com/wkcalpha/

• Structured data - I know that in my last job, there were several

things we used a wiki in lieu of a database for (e.g. we kept a list of new licensees of our technology on a wiki). It was nice, because we had the flexibility to add fields willy-nilly. So, it may be interesting to discuss the enterprise applicability of projects like

WYSIWYG Editing

• Задача интенсивно обсуждается на Hacking Days
• Several non-MediaWiki markup solutions (FCKeditor very popular here)
• Challenge for mainstream solution: lack of formal Wiki-syntax definition

Check MediaWiki+FCKeditor for more info on this. FredCK 14:34, 28 July 2007 (UTC)

Другие возможности

• Marking stable/approved versions of articles
• Обучение
• Possibility to replicate to a local system. This is needed to Consultants with no access from the customersite to the Company Wiki.