web-dev-qa-db-ja.com

MediaWikiを使用したITドキュメント

私たちは、ドキュメントをさらに強化し、情報に簡単にアクセスしたり、情報を編集したりできるようにする方法を探しています。これらのアイデアを念頭に置いて、Tier 1（ヘルプデスク）用のMediaWikiプラットフォームに基づいて内部Wikiを作成しました。これはヘルプデスクにとって大きな成功であり、彼らはこれを日常業務に広く使用しています。現在、Tier 2（システム管理者）向けに文書化する方法を検討しています。情報の機密性やサーバーの構築方法などの手順が含まれているため、Tier2の情報をTier1の情報とは別にする必要があります。

次の目的を達成する方法に関するアイデアや提案を探しています。

  • MediaWikiプラットフォームに基づく一元化されたドキュメント
  • Tier1とTier2の間で分離されたコンテンツ
  • Tier 1のルックアンドフィールが気に入っており、Tier2にも使用できます。
  • MediaWikiの2つの異なるインストールを実行する場合、これを同じサーバーで実行できますか？同じマシンでMediaWikiの複数のインストールを実行するのは良い考えですか？
  • ドキュメントのインストールごとのFQDNおよびSSL証明書のサポート
  • ユーザーまたはグループのメンバーシップに基づいて、Tier 1 MediaWikiインストールの個別の部分をスライスまたは保持する方法はありますか？

よろしくお願いします。ご意見・ご提案をお待ちしております。

wikidocumentationmediawikidocument-management
14
John

多くのコンテンツ切り替え層が存在しない限り、MWは確実なアクセス制御のために構築されたことがないため、個別のWikiをお勧めします。 http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions を最初に読んで、努力する価値があるかどうかを判断してください。保護方法を回避する可能性のある警告や悪用がたくさんあります。

もしあなたがそれをやるなら： 名前空間ロックダウン拡張 を見てください。これにより、ページが含まれる名前空間に基づいてグループアクセス制御を設定でき、各層に1つの名前空間を持つことができます。私は過去にこれを使用しました（ただし、現在のMWバージョンでどの程度サポートされているかはわかりません）。それは機能しますが、特に多くのユーザーがいる場合は、構成と管理が面倒です。

2つのインスタンスを使用する場合：十分な分離を維持している限り、1つのホストで複数のMWインストールを実行できます。それらを、独自のホスト名、個別のデータベース（およびDB資格情報）を使用して個別の仮想ホストとして設定すれば、すぐに使用できます。

ただし、SSLが必要な場合は、それぞれの証明書を生成し（または、内部ワイルドカードを使用して）、各インスタンスに独自のIPアドレスとホスト名を与える必要があります。

Look + feel（skin）は、サブフォルダーを含むPHPファイルであるため、2つのインスタンス間で簡単にコピーできます。入手方法1つで気に入ったら、コピーして新しい構成に追加します。

12
SmallClanger

mWのインスタンスをさらにインストールできます。Webサーバーのドキュメントルートに個別のディレクトリを作成するだけです（したがって、同じドメイン名と同じSSL証明書を使用します）。インストール中に、それらを別のデータベースにポイントします

URLのルートにそれらが必要な場合-異なる名前または同じ名前の仮想ホストをいくつか作成できます-異なるポート

ApacheをWebサーバーとして使用している場合-アクセスに.htaccessファイルを使用できますが、管理は簡単ではありません

1
jet

Tier 2wikiの前で.htaccessを使用し、MWセキュリティ拡張機能を使用してドロップできます。

0
Sandra