MediaWiki

提供: yonewiki
移動: 案内, 検索

目次

Media Wikiとは?

このページの仕組みそのものです。
ウィキペディアは公式に活動している百科事典になりますが、その百科事典のシステムそのものが、
自由に入手できるものとしてソースが公開されています。ライセンスとかの詳細はMedia Wikiで検索して表示されるページを参照されたし。

個人的に立ち上げる時の手順
0.自分が使っているWebサーバに導入されているMySQLとPHPのバージョンを確認する。
1.ソースをダウンロードする。自分の場合はXREAの341番目のサーバなので1.19.8を使っています。
2.入手したファイルを解凍して、サーバにWikiのシステムを保存するディレクトリを作って、アップロード。
※このとき作成したディレクトリの下にindex.phpが存在するような形式でコピーします。
3.そしたらWebのアドレスURI+作成したディレクトリ+index.phpにアクセスしよう。インストールのためのウィザードが始まる。
4.質問に間違いの無いように適宜を応えるようにウィザードをすすめる。
※このとき難しいと感じる部分はMySQLへのアクセスIDとかパスワード。データベースの名前やレコードの接頭句とかだと思います。
でも、この程度の質問に答えられないなら、まぁ勉強した上で使われることをお勧めします。きっとこの先、不勉強による問題に直面し、 対応ができなくなります。Webサーバ毎にルールは違うし、レンタルサーバなら、一緒に使っているみんなに迷惑がかかります。 大丈夫、レンタルサーバ屋さんと契約しているなら、サポートセンターになんていれたらいい?って聞けばきっと教えてくれます。たぶん。

5.最後まで質問に答えきれたら、LocalSettings.phpっていうのがダウンロードされますので、これを自分のPCに一旦保存して、サーバのindex.phpと同じ階層に アップロードしましょう。
6.あとは…もう一度 3.の項目でアクセスしたURIへ再度アクセスすると今度はWikipediaのような画面に遷移します。
7.編集するにはひょっとしたら4.の項目で設定したIDやパスワードが必要な状態になっているかもしれませんが、その場合はログインして、みんなに伝えたい何かを書き込みましょう。
8.書き込みのルールは少しだけ複雑ですが、本家Wikipediaによる記述のルールを勉強して、優れたデザインを追い求め、スタイリッシュな記述を目指しましょう。

簡単に書きましたが、そういうことです。


SyntaxHighlight_GeSHiをインストール

※最近のWikiMediaではデフォルトで一緒にインストールされるみたいです。

SyntaxHighlight_GeSHiをインストールするとWikimedia内でプログラムコードの記述をした際に手間をかけることなく
シンタックスハイライトをしてくれます。※最近のVersionではGeshiが同梱されているので、インストールの手間はないそうです。

1.まずは必要なソースコードをダウンロードしよう。

http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SyntaxHighlight_GeSHi/
のリポジトリから
SyntaxHighlight_GeSHi.class.php
SyntaxHighlight_GeSHi.i18n.php
SyntaxHighlight_GeSHi.local.php
SyntaxHighlight_GeSHi.php
をダウンロードする。Rev.という列に書いてある数字のLinkをクリックするとRevision XXXXXX - (show annotations) (download)
とあるので、Downloadボタンを押して表示されたテキストをコピペして、それに対応するファイル名で保存しましょう。
*自分だけなのかもしれませんが、Downloadのリンクの上で右クリックして対象をファイルに保存とかってやると、
ファイルの中身がソースコードではなく、違う情報のものにすりかわるという罠にはまりました。
http://qbnz.com/highlighter/
からGeSHiをダウンロードしましょう。こちらは右側とかにあるDownloadsのリンクをクリックすると
Download GeSHi-X.X.X.XX.zip (X.X MB)というリンクがあるので、こちらからダウンロード。
※GeSHiとは、Generic Syntax Highlighterの略で、こちらの方がプログラムのソースコードにいろいろな着色や協調をしてくれるエンジンで、
PHPファイルの方がMesiaWiki用にちょっと加工してくれるプログラムになっているようです。

2.このファイルを

extensions
└/SyntaxHighlight_GeSHi
├SyntaxHighlight_GeSHi.php
├SyntaxHighlight_GeSHi.i18n.php
├SyntaxHighlight_GeSHi.class.php
└/geshi
├geshi.php
├/geshi
├/docs
└/contrib

なるようにして、index.phpがあった階層にあるExtensionフォルダの中にアップロードします。

3.index.phpと同じ階層にあるLocalSetting.phpの最終行に

require_once("extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.php");

をペロッと記述し、LocalSetting.phpを更新します。

あとは使ってみるべし。

スタイルシートを変更

1.http://xxxxxx.xx/xxxxx/index.php/Special:Userrights

もしくは

http://xxxxxx.xx/xxxxx/index.php?title=Special:Userrights にアクセスして、ユーザに管理者・ボット・ユーロクラット権限を付与します。
2.http://xxxxxx.xx/xxxxx/index.php?title=MediaWiki:Common.css

もしくは

http://xxxxxx.xx/xxxxx/index.php?title=MediaWiki:Common.css にアクセスして、Common.cssを記事を編集するかのように編集します。
CssのファイルでFTPで直接操作すると死ねる結果が待っていますのでWikiのシステムを使いましょう。


たとえば、以下のようなスタイルを適用すると文字を大きくしたりフォントを設定できたりします。

  1. body {
  2.  font-size:18px; 
  3.  font-family:'ヒラギノ角ゴ Pro W3','Hiragino Kaku Gothic Pro','メイリオ',Meiryo,'MS Pゴシック',sans-serif;
  4. }

Geshiのスタイルシートは http://xxxxxx.xx/xxxxx/index.php/MediaWiki:Geshi.css

もしくは

http://xxxxxx.xx/xxxxx/index.php?title=MediaWiki:Geshi.css に記述するとよいですが、pre class=de1(通常行)やde2(強調行数)といった深いところに使われるタグにもフォントの定義がされていたりするので、Geshi.cssよりあとで定義されているシンタックスのCSSが優先されて、動作しない定義が出てきます。そういうときは、よく考えてからになると思いますが、CSS最優先キーワードを使って定義しちゃいましょう。geshiで変更しても影響のないスタイルだけにこのキーワードを使います。たとえば等幅フォントを設定したい場合は

  1. div.de1,
  2. div.de2, {
  3.  font-family:'等幅フォント名'  !important;
  4. }

のように!importantキーワードを定義します。本当はGeshiのシステムをいじるのが正しい対応になるかと思いますが、プログラムを修正しないで、 ユーザの立場で定義を活用するならimportantしかないと思います。自分で作成するシステムのCSSではimportantの利用はよろしくないですね。 だって2重で定義されること自体が問題でしょ?

131011事件:WikiMediaシステム半壊状態です。

PHP5を利用するMediaWiki Ver1.19にはSafeMode(セーフモードとかsafe_modeとかとも書けます。)とかっていうモードがあるらしくて、 そのせいで画像のサムネイルが作れないため、大量のエラーを吐き出すページがありました。 その際はエラーにびっくりせずに。そのまま、ご帰宅いただければとのたまっておりました。

当時の時系列メモ(2件)
13-10-11
ImageMagickが動作していない模様。LocalSettings.phpとGlobalFunction.phpいろいろ変えたけど動ていない気がする。
連休明けに考えてみようと思う。フォルダ生成はftpに任せたのでその辺のUID関係の問題はクリアしたと思う。
convertのありかはあってる。あとは何だ?xreaが何か別のセキュリティ仕様変更をやったのやもしれん。
シングルクォートつけてきたり、引数の無効かとかはクリア。つうか、これどうやってデバッグするんだ。
ものすごい地味な方法でやってるんだけど…。xreaでできないと意味ない気がするし。
自分のPCにPHPインストールしたり、あんまり使わないから嫌だ。ってそこか。
あと変に動かすと、MediaWikiのシステムそのものが破綻するという罠もあるのが凄まじい。
こんな巨大プロジェクトの構造。理解しきれない気がする。
一人でしか使わないからファイルロックとかあんまり意味ないのに無駄に凄い技術が仕込まれてたり
考えさせられる。
なんだこのPHP5の高すぎるセキュリティ。素人集団がサーバ使う向けの仕様のような気がする。
あ、それがxreaか
フフフ♪
・サムネイル生成までの道筋を改めて追う。
・ImageMagickのコマンド実行するところまで来ているか確認する。
・だとしたらどんなコマンドを実行しようとしているのかをつかむ。
・imagesのtmpフォルダにしこたまたまったtransform_xxxxx-1.jpg達の後始末をどうするか考える。
・あとはFlashを埋め込んだり、動画を埋め込んだりできるようにしたいかも
たぶん2年くらいかかる。

メモ
13-10-17
ま、なんやかんやで、Safemodeの回避方法はわかりました。要するにPHPではなくPerlを使えということですな。
意味ねぇ。PHPの崇高な思想による機能はプログラミングのインタラクティブ性を大いに損なうものであると思います。
そんなに楽しくないプログラミングさせるなら、いっそのことサーバごと吹き飛んでしまえばいいと思った。
恐ろしいほど、Mediawikiへの変更を加えたので、ここでは伝授することができません。お許しを。
要するに最初から全部作った方がはえー気もする。2年くらいかかる予定でしたが、まぁ一週間ありゃなんとでもなるってことですね。

総括
http://php.net/manual/ja/features.safe-mode.functions.php
上記リンクに記載されている関数はSafeModeでは使えません。重要な関数がびっしりでてくるので、リンク先を見た後はかなりげんなりします。
要するに、危険な関数だからUIDが一致しないとだめよ。ってこと。
ん?つまり?
普通は、ftpでログインしてあらかじめ作ったおいたフォルダにphpのファイルを置くと思います。 そうするとUIDはftpでログインしたときのUIDがフォルダに付きます。そして、phpを実行しているときはUIDがXREAだとApacheを実行するUIDで
食い違うことになります。つまりSafemodeの機能が働いて、関数は動きません。となると動的(PHP実行による処理)に、ディレクトリを生成したり
動的にディレクトリを削除することもできません。その他、いろいろなことが出来ません。
その結果、一般に配布されているようなphpで高度なコンテンツマネージメントシステムはだいたい、そのままでは動きません。
それは、どういうことか?
サーバ屋さん的にはphpのエンジン設定の権限によりsafemodeを切ることもできるが、この機能を有効にしているってことは、
そのサーバ屋さんを利用しているユーザ同志によるモメゴトのもとになるようなPHPのコマンドを実行させないということが、
ユーザ個人にとっては使いにくいんでしょうけど、それよかモメゴトが消えるんならそれでOKOK。サーバ屋としてもなんら影響ないし、業績に響かない。
むしろ、ありがたい。ということなんだと思います。
結果、プログラミングを熟知している人だけが、高度なシステムを改造して、使うし、問題も起こしにくい。
そういうことになっているのかもしれません。あるいは、そういった機能を欲しない無欲なユーザに使ってもらえている
というあたりなのでしょうか?想像ですけど。

で、回避策なんですけど。思うに余計に危なっかしい案ではありますが、
一つはphpのftpに関連する関数を使う。どこかにソースのどこかにftpのIDとかパスワードとかを書くんで、スペシャルなハッキング技術をお持ちの人なら、
まぁ簡単にやられる可能性もあります。dbへのアクセス情報とかはMediaWikiやその他システムで入力してるんで、そう簡単ではないでしょうけれども。リスクが少し大きくなります程度。
加えて、phpからcgiを呼び出してフォルダの生成や削除をする。という処理をさせる。これもうまいことチェック機能をいれとかないと、危ない。
あるいは
xreaに限れば、phpをcgi版で動かす。という宣言を.htaccesを配置、記述する。php.iniを配置、記述する
という対策があります。
ftpでフォルダを作るのは出来るかもしれない。
ただしftpだけで制御するには疲れるかもしれない。なぜならfopen関数で第二引数に'x'を指定する場合は
ファイルがなければ、フォルダも全部作って、ファイルを作るっていう便利な関数だから。
そうするとphpからcgiを呼び出して、同じようにフォルダの生成や削除をするという処理をさせる必要があります。
これもスーパーハッカーなら、このcgiを利用して、呼び出し方をして、ファイルの削除しまくりとかできるわけです。
そんなスーパーハッカーいるのかどうかは知りませんが。
で、そのセキュリティ的な対策は各自やっていただくとして、セキュリティ的な提案とやりかただけを語るならば、
safemodeで影響を受ける関数の置き換え処理の記述をします。MediaWikiの場合。かなりの数の置き換えが必要になります。やれる人はやってみて。
例えば、今回の目的ではないですが、chmod関数を置き換える場合だと。
chmod関数の引数が$this->pathだとしたら
file_get_contents('http://xxxxx.xx/xxxxx/yyyyyyy.pl?Path='.$this->path&Secure=xxxxxxxxx); として.plや.cgiを実行する関数に置き換えます。
動作結果がどうなるかわからないので、呼び出し結果もHTMLに吐き出しておけば、左辺の変数に結果が取り込まれます。チェックができないのが辛いところです。
実行した後にチェック用のファイルを生成させたりして、読み込んでみるという方法もありでしょう。自分はそこまでやってませんが…
Perlもわかる!という人にしかできない技です。
…の部分には必要に応じてuse関数で、外部の関数を読みこむ宣言をしないとダメでしょう。Copyの関数とかね。
さらには、第三者に実行されたときのために、呼び出し元が自分のサーバであることの確認処理もいれた方がいい。
でyyyyyyy.plっていうファイルにchmodを実行するPerlスクリプトを書く。

例えば


  1. #!/usr/local/bin/perl
  2. print "Content-Type: text/html\n\n";
  3.  
  4.  
  5. $formInput = $ENV{'QUERY_STRING'};
  6. @InputData = split (/&/,$formInput);
  7. foreach $tmp (@InputData) 
  8. {
  9.     ($name,$value) = split (/=/,$tmp); 
  10.     if ($name eq 'Path'){
  11.         $path = $value;
  12.     } 
  13.     elsif($name eq 'Secure'){
  14.         $secure = $value;
  15.     }
  16. }
  17. if($secure eq 'xxxxxxxx') chmod 0777, 'xxxx'.$path;


という感じです。
この調子で必要となるsafemodeの影響を受ける関数の動作をperlに置き換えたものを作ります。
こんな対処方法を取る人がどれくらいいるのか知りませんが…
参考になればと思います。xreaで、ここまでやるやついねぇな。
Perlはさっぱりわからへんという人は、さっさと引っ越しした方がええね。
わたくしめに助言できるのはココまでです。Perlを熟知している方にやって欲しいからです。自分もこれが安全か?と言われれば、それほど自信ありません。
むしろ教えてほしいくらいです。
passthru関数もバッククォーテーションを使ったり、UNIXコマンドステータス$!を取得して、きっちりと動作確認もできるわけです。
unlinkとかmkdirとかis_なんちゃら関数だって、Perlの-xを使えば同じこと。Perlですべて置き換えられます。
xreaが推奨するphpのcgiモードはMediaWikiでは動作しません。Get関数の引数の形が違うからです。そこを変えれば全部うまくいくのかも不明ですし。

環境変数で、phpでcgiを呼び出したときだけ値が空っぽになる変数あるみたいなので、その値が何も保持していないか確認すると、
更にいたずら対策はできるわけですね。なんちゃらインジェクションとかされたら辛いので、追い出し+データ放棄とかの処罰がありそう。
他人に迷惑をかけたら民事訴訟とかもありますかね。責任ってあるのかもしれません。あるいみクレジットカードの番号盗まれるより痛いかも。
自分みたいなもんのクレジットカードの上限なんてたかがしれてますもんね。レンタルサーバの責任ってどんなことがあるんやろか、怖いねぇ。
なんか、車の運転をしなければ人を殺すこともないわけですし、乗らないのが一番っていうのと似てるのかもしれません。

こんなことやってたらxreaから追い出されたりして、そしたら最初からphpなんて使わせてもらえないと思うので、大丈夫だと思いますけど
かくいう自分も最初はxreaをやめようかと思ったくらいです。もしくはMediaWikiをやめようかとも思いました。
上記のサンプルではsecureという変数を使ってパスワード的な確認も入れてます。こんなものが役に立つかどうかしりませんけど。

もし訴訟とかが起こった時にはsafemodeとかいう使いにくいmodeをonにするからだって開き直ったりしてるかもしれません。なんとなくイメージが湧く。
safemodeはこんな風に余計にあがく奴がいて、むしろ危ないってことだな。だから新しいPHPの現行Versionでは廃止になったのかもしれない。
でも、そのsafemodeの機能がついたサーバ500台近く抱えているxrea。恐るべし!
グダグダ言ってても、だれも救われないかもしれないので、この件はこれでおしまい。

140623 PHP Verupによるセーフモード解除

VersionUpしてセーフモードが解除されたみたいです。よかったね。もう、ややこしいことはしなくてよくなりました。こういう方針の変更というのは大事だよね。ユーザはカスタムしたいからサーバを借りるわけだから、自由度が低いレンタルサーバはやっぱだめだよね。経営側がようやくユーザ離れの深刻さを理解したのかもしれません。でも、なんつうか、あんまりおおっぴらな連絡もなくPHPだけでなくDBシステムのバージョンアップとか大きな変更をやったもんだから、データベースが止まりました。バックアップはとったから、動くようにする作業は各自でやってね的な対応です。これはなかなか強引だ。xrea恐るべし。でも、自分はこの恐るべし方策についていけるので、よしとします。6/25現在もxreaユーザはDBシステムの変更によるWebサイトの機能停止に追われているようです。


FTPログインルートにDBのバックアップを_DB_BACKUP_XREA_UPGRADEというフォルダの中にDBログインID毎にdumpファイルを作ったそうです。

たとえば、ID=xxxなら


_DB_BACKUP_XREA_UPGRADE/mysql_xxx.dump


となります。このdumpファイルというのはインポートすることができる形式になっていて、文字コードは使っていた人の都合によっては様々なモノになっている可能性があります。文字化けが発生したりする可能性については各自で対応しなければならないそうなので、このあたりの理解度が対応力をためされる部分になるそうです。


このファイルをFTPツールとかをつかって自分のPCに保存します。このときもバイナリーファイルとしてダウンロードするなりして、文字コードの形式が変わってしまわないように注意が必要です。この節のFTPに関する説明が分からない人はFTPの理解からやり直しです。


そして、phpMyAdmin(MySQLの場合)とかphpPgAdmin(PostgreSQLの場合)でインポートして、dumpファイルを指定してあげれば復活します。それぞれのIDでログインしてIDにあったファイルをインポートする作業を繰り返します。xreaでは5つのIDまで使えるので多い人でも5回くらいでしょう。


ファイルが大きい場合は途中で失敗することも多いので、ID名の中に関連付けられているすべてのテーブルを削除して、やり直すとよいでしょう。それと、phpMyAdminやら、phpPgAdminの画面で、DBシステムのVerUpに伴うエラーが表示される場合もあると考えられます。これはphpXXAdminのバージョンが古いために表示される不具合です。基本的な動作に支障はないので、それほど気にしなくていいWarningエラーですが、気になる人は、DB管理画面の結構下の方にあるphp(xx)Adminのインストールボタンをもう一回おして再インストールをすると良いでしょう。


果たして、昔のDigiRockはこういう会社だっただろうか?キニシナイけど。気になる。2011年にGMO資本になってから、なんかオカシイ。自分はその昔、GMOと大きな訴訟的な問題(自分にとって)を起こしてから、GMOから逃げ出してDigiRockに移動したんですけど、モトサヤに収まってしまいました。これが切っても切れない腐れ縁というやつなのかもしれません。GMOはGMO。GMOディジロックはGMOディジロック。

181001 ImageMagick Convert 移動

 これまでは、/usr/local/bin/php/convertにおいていたのに、突如として消されて、一般的なパスに移動。自分でソースからコンパイル、リンクした奴でしたけど…なんにせよ普通な設定になってよかった。新しいパスは


  • /usr/bin/convert


 xrea のサーバもごく一般的なパスになりました。割かしちょいちょい、こういう大改造をしれっとやるので、古参は困りますね。

 なので、localsettings.phpの設定の中は


  • $wgImageMagickConvertCommand = "/usr/bin/convert";


 と書けば、ImageMagcikの変換関係の処理が使えるようになります。



個人用ツール
名前空間

変種
操作
案内
ツールボックス