MediaWiki

提供：yonewiki
2022年10月6日 (木) 21:47時点におけるYo-net (トーク | 投稿記録)による版 (→‎220918問題 Media Wiki移行)
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)

Web技術へ戻る。

Media Wikiとは？

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

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

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

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


220918問題 Media Wiki移行

　2022年9月18日くらいにわれらがXREAのサーバーIPアドレス変更作業をしたあたりから、Yonewikiで文章部分のみが出力されなくなる障害が発生。Mediawikiの何かが動かなくなっているらしいが原因究明には時間がかかりそうなことがわかり1週間たっても膨大なソースと睨めっこしていた。最初はhttp error500で何も表示されない状態だったが、ある一文の変数名に格納されたクラス名でクラス生成が失敗していた。変数の名前を判断して、生成するクラスをかえるように分岐して変数名のクラス生成ではなく、クラス名そのものを定義して生成する感じにすると通過するようになった。これだけでhttp error500が解除されたので喜びかけたが、肝心のコンテクスト文章は表示されない。これはエラーで止まるより追いかけるのが難しい。落ちてないのだから何処かで微妙に失敗している事になる。見つけるのは大変だ。いろいろと怪しいところを探したが何処が失敗しているのか探しきれず、全く使い物にならない状態が続くという焦りもあるせいで、疲れた。ゆっくり解決すればいいものでも無いので、新しいMediaWikiに移行することを決意。時間があるときに古い方は精査すれば良い。前回mediawikiの大改造をしてからブランクがあるためMediaWikiのそれぞれのファイルクラスがどんな役割であったかも忘れたし、この間にそういったことをまとめていたデータを失う様なパソコントラブルがあったことも痛い。心機一転だな。3日かかったが移行作業を手堅く進めてみた。元が1.19？2012年モノと相当古いので自動移行には頼らない方針。1.38になるまでにLoadExtensionの導入など大きな変更が入っている。移行した関係のトラブルをいつまでも抱えるのはいやなので、文章部分だけを最新レビジョンで抜き出すことはできたので、ファイルの全アップロードしなおしと、約1500におよぶページの文章をひとつづ保存する方針。

　2022年9月28日に文章部分をすべて流し込み完了。手作業きつい。1500文章はナカナカ。あとはファイルアップロードを残すのみ。一つ試しにやってみるとエラーが発生。ファイルはアップロードできているのに、Mediawikiからは見ることができない。原因はxreaの.htaccessファイルのシステムをとりまく環境がよくないらしい。以下のような内容の.htaccessで 

<IfModule rewrite_module>
	RewriteEngine On
	RewriteOptions inherit
	# Fix for bug T64289
	Options +FollowSymLinks
</IfModule>

　Options +FollowSymLinksをコメント化。 

<IfModule rewrite_module>
	RewriteEngine On
	RewriteOptions inherit
	# Fix for bug T64289
	# Options +FollowSymLinks
</IfModule>

　と変更したところファイルが参照できるようになった。もう一つ問題は、すぐにセッションが切れることだな。これは28日時点で調査中。一筋縄ではいかないな。すべてのページのページタイトルは古い方でも表示できているので、ページタイトル毎に新しいhttps://wiki.yo-net.jp/index.php?title=記事名へのリンクをSkin/Vector.phpをちょちょいっとするだけで表示できることも確認できた。今日はここまでだな。疲れた。総対応期間は2週間にはなりそうだ。

　翌日、

　Upload作業をすすめると、また問題にぶつかる。仕様変更ですけど。アップロードできないことになっている拡張子ブラックリストファイルの指定方法がかわっていた。Version1.37からだそうだ。Upload関連はだいぶ変わったことになる。$wgFileBlackListから$wgProhibitedFileExtensionsになったそうな。

　詳しくは、https://www.mediawiki.org/wiki/Manual:$wgProhibitedFileExtensions/jaだそうな。あわせて、MimeTypeのブラックリストも変わっていました。$wgMimeTypeExclusionsです。共に値の指定方法も変わっていますので、こちらも詳しくはhttps://www.mediawiki.org/wiki/Manual:$wgMimeTypeExclusions/jaを参照して下さい。更には、Scriptっぽいものがなかみにある場合は絶対だめになったそうです。どうしてもアップロードしたい場合は、Includes/upload/UploadBase.phpのdetectscript関数の戻り値を強制的にtrueを返すように、return false;となっているところをすべて、return true;にするしかないそうです。ということが、https://www.mediawiki.org/wiki/Manual:Configuring_file_uploads/jaここに書かれていた。こんなことをする人はいないか…。


　引っ越し処理が半分くらい終わったので、旧wikiから新wikiへのJumpリンクもはった。ようこそ。新しいwikiへ。でも、まだ作業できていないこともあるっちゃある。

１．サイドメニューの幅が本文コンテンツを侵食している。

２．その関係で広告の位置を上と下にせざるを得ない。こういうのでサーバ、ドメインの維持費用(年間6000円程度)をまかなってますから、広告は必要。それくらい自腹切れという説もありますが、無料で自分が情報技術的な面で経験したことを記事にして公開してること自体がありがたい話だと自負しているらしい。

３．MathJaxの数式貼り付け用に作った yJavascriptエクステンションとyonetMathエクステンションが使えなくっている。早いところ、これも移行したい。でも数式使ってるところって少ないし、数式のあるページは一般にはわけわからないことばかり書いているので、あまり気には留めていない。

４．記事毎のアクセス数表示がなくなった。悲しい。復活させたい。けど、新しいwikiでは、そういうシステムがなくなっているっぽい。Googleアナリティクスでどの記事がよく読まれているか知ることができるので、こちらもあまり気にしていない。

５．セッションがよく切れる。


総じていうと、MediaWikiは使いやすい反面、改造するための知識はかなり深い理解が必要過ぎて辛い。デザインとか変えるのも大変過ぎる。


５．が最初に解決したかも。LocalSettings.phpの中にある $wgMainCacheType を $wgMainCacheType = CACHE_ANYTHING;のように設定すると出なくなったような気がする。以下のトピックで揉めていたのを参考にした結果です。https://www.mediawiki.org/wiki/Topic:T7irqyk4rhfy3ohk


４．がその次に解決。優先度と逆に解決していく。さすが。アクセスカウンターはExtensionに変わってましたね。HitCounterというExtensionを導入。Updateがよくわからなかったので、自分でDBに表xxhit_counterを作成して、構築。2列の表でした。ひとつがAutoIncrementalのpage_idという列をすでに作成したpageの分だけ作成。もうひとつはpage_counterという列に規定値0を設定して作成。このときphpMyadminを使って表を作成したせいで、phpMyAdminでの警告レベルのエラーが発生するようになった。DBとしては機能している。

Notice in ./libraries/tbl_info.inc.php#99 Array to string conversion　というエラー。phpが変数を受け取りたいとおもっているところに配列を受け取ったという警告らしい。なんか悪いことしたか考えてみたが思い当たらない。こういうのは怖い。しらずしらず法に触れてるみたいなね。

折を見て、いったん表を消して、SSH経由でMySQLをコマンド操作してDBの再作成でもしてみようと思う。

そして、３．の対応を開始したが、Extensionの古い形式は動作するらしいので、そのまま放り込んでrequire_once(' MyExtensionName '); としてLocalSettings.phpに記述してみたが、駄目だった。$wgParser->Hook('フックするタグ名','みつけたとき呼び出す関数名');のところで、タグの存在するページでタグを見つけても指定した関数が呼ばれない。意味わからないので、またインターネットを徘徊。答えはどこ。なんか新しいWikiになって使わなくなったrequire方式に変更を加えてるということ？どこにその情報があるのか。ネットは広大ね。と攻殻機動隊、公安9課の草薙少佐がいっていたのがリフレインする。

$wgPaserの公式説明を見てみた。https://www.mediawiki.org/wiki/Manual:$wgParser/ja 使えなくなっているっぽい。なるほど、require_onceは残っているものの、$wgParseが機能は廃止で、エラーにはならないが手つかずのextensionは動かなくなった。そんな感じかな。新しい方法があるっぽい。公式の説明は意味不明だ。何を言っているのかさっぱりわからん。やるべきことはわかった。もうひと踏ん張りしてみるか。やっぱ、wfLoadExtensio使えみたいな風潮でメンドクサイので、これは後回し決定。日本人でMediaWikiの改造についても情報発信しているwikipedia使いがあまりにも少ないで、10代～30代って情報技術に疎い人が本当に多くなっているんじゃないかと危機感を覚える。本当にスマホしか使えなくていいっていう人増えてるのかな。淋しい。


　まぁいい。まぁいい。数式が使えるようには、なったし、問題ない。３．は急がなくていい。２も急がないし、１．だけやろうかな。カウンタの人気のページの数値がおかしいことに気づいた。ちゃんとインストールできなかったからしょうがねぇな。なんとか整合性を取ろう。なので、あと２つ、カウンタの整合性。それとメニューの幅を調整して、本文と領域が被らないようにする。頑張ろう。そしたら、また普通に違うことをやろう。Wikiのメンテで2週間を無駄にした。くっそ。


　あ、５．は解決したように思っていたが、セッション24分問題っていうのは残っていそう。ちょっとだけ見直ししないとな。あと、スマホでみたときに文字が小さいような気がする。もうちょい字を大きくしよう。そうしよう。


　ブラウザの戻るの機能を使うと毎回ページの先頭に移動する。長いページでリンクをクリックして、読み終えて戻るとまた長いページの先頭になってさっきのリンクの続きを見ようと思ってもかなりのスクロールを強いられる。ダサいぞこの機能。MediaWikiにこんな機能いるかね。本家もこんな機能使ってるの？毎回、先頭に移動させたいってそんなことあるのかな。思いつかん。


　謎が解けた。頭は頭脳。心は心。その正体は！ってやつだね。1文字もあってないか。HitCounters Extensiotnの中に書いてあるクエリーが良くないみたいだ。HitCounters/includes/HitCounters.body.phpの最後の方にあるクエリーを作るための構造定義部分があります。 

	public static function getQueryInfo() {

		return [
			'tables' => [ 'p' => 'page', 'h' => 'hit_counter' ],
			'fields' => [
				'namespace' => 'p.page_namespace',
				'title'  => 'p.page_title',
				'value'  => 'h.page_counter',
				'length' => 'p.page_len'
			],
			'conds' => [
				'p.page_is_redirect' => 0,
				'p.page_namespace' => MediaWikiServices::getInstance()
					->getNamespaceInfo()
					->getContentNamespaces(),
			],
			'join_conds' => [
//				'page' => [   ここが間違い。エイリアス名使わないとだめ
				'p' => [
					'INNER JOIN',
					'p.page_id = h.page_id'
				]
			]
		];
	}
}

という具合に、join_condsで、内部結合するテーブルの指定を正式なテーブル名を書いていますが、もうちょい上で指定した、pageのエイリアス名であるpを使う必要があります。コードを追いかけて、追いかけてようやくわかりました。一番きれいな直し方ができた。よかった。内部結合のSQLであるp.page_id = h.page_idの部分が生成されないのを見つけたときは、なんだよコレって思いました。他のSQLもたくさん処理するIncludes/libs/rmdbs/Database.phpのコードを書き換えてやろうかと思いましたが、なぜそのように処理してしまうのかを追いかけてわかった。配布しているExtensionがまちがえてるんじゃんね。作者におしえてやろうかと思ったけど、スペシャルページの異常はスルーで、誰も使ってねぇってことだ。問題ないな。やっぱ教えてあげようかな。こまったなぁ。


　１．も解決しました。モバイルではくずれないことからcssで解決できるとはおもっていましたので、Edgeの開発者ツールで調査するを使って見つけることができました。以下をhttps://ドメインorIPアドレス/index.php?title=MediaWiki:Common.cssに追加。 

@media screen and (min-width: 86.75em){
  .mw-checkbox-hack-checkbox:checked ~ .mw-workspace-container .mw-content-container, 
  .mw-checkbox-hack-checkbox:checked ~ .mw-workspace-container .mw-article-toolbar-container{ 
    margin-left: 11.5em;
  }
}

　~ CSSのセレクタ部分のチルダは、チルダの手前のセレクタとその後のセレクタが連続している部分に適用されます。親とか子は関係ありません。連続です。そして半角空白 半角スペースは、スペースの手前のセレクタの子のセレクタに対してという意味になります。要するにmw-content-conteainerのmargin-left値を設定したいのだけど、親のタグでcheckboxの設定がチェックされていて、かつmw-workspace-containerというタグが親であることという条件がついている感じです。おなじく、.mw-article-toolbar-containerもそうしてくれという感じですね。これで本文とその上のツールバー(ソースの表示とか閲覧のタブ選択領域)の左余白を11.5emというちょっと大きめの値に設定できます。


モバイルの(max-width: 86.75em)でも11.5emで指定しているので同じ値を入れました。モバイルと同じにするのがいいね。あとは、戻るで先頭に戻るやつだな。サファリだけの問題みたい。悲しきデバイスよのう。WebPage作成者も大変だな。サファリのために。


　モバイルで編集しやすいようにtextareaの大きさを調整。line-heightで1行の大きさを1.5emに調整して、heightに10行分の15emに調整。そのときにcalcという計算をしてくれる関数を使っています。 

@media screen and (max-width:982px){
  body{
      font-size: 175% !important; 
  }
  textarea{
    font-size: 175% !important;
    height: calc( 1.5em * 10 ) !important;
    line-height: 1.5 !important;
  }
}


　デスクトップのtextareaのrowの規定値が25は大きすぎるので20に設定。これは、調べに調べた結果Include/editpage/TextboxBuilder.phpのbuildTextboxAttribs($name, array $customAttribs, UserIdentity $user, PageIdentity $page)関数で、'rows' => 25, となっている行を 'rows' => 20, に変更するだけです。


　

181001 ImageMagick Convert 移動

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


  • /usr/bin/convert


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

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


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


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

　

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ディジロック。

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

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

当時の時系列メモ（２件）
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を埋め込んだり、動画を埋め込んだりできるようにしたいかも
たぶん２年くらいかかる。

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

総括
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スクリプトを書く。

例えば


#!/usr/local/bin/perl
print "Content-Type: text/html\n\n";

…

$formInput = $ENV{'QUERY_STRING'};
@InputData = split (/&/,$formInput);
foreach $tmp (@InputData) 
{
    ($name,$value) = split (/=/,$tmp); 
    if ($name eq 'Path'){
        $path = $value;
    } 
    elsif($name eq 'Secure'){
        $secure = $value;
    }
}
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。恐るべし！
グダグダ言ってても、だれも救われないかもしれないので、この件はこれでおしまい。


　

SyntaxHighlight_GeSHiをインストール

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

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

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

○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用にちょっと加工してくれるプログラムになっているようです。

２．このファイルを

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

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

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

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

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

あとは使ってみるべし。

スタイルシートを変更

１．http://xxxxxx.xx/xxxxx/index.php/Special:Userrights

もしくは

http://xxxxxx.xx/xxxxx/index.php?title=Special:Userrights にアクセスして、ユーザに管理者・ボット・ユーロクラット権限を付与します。
２．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のシステムを使いましょう。


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

body {
 font-size:18px; 
 font-family:'ヒラギノ角ゴ Pro W3','Hiragino Kaku Gothic Pro','メイリオ',Meiryo,'ＭＳ Ｐゴシック',sans-serif;
}

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で変更しても影響のないスタイルだけにこのキーワードを使います。たとえば等幅フォントを設定したい場合は 

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

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

　

Web技術へ戻る。

「https://wiki.yo-net.jp/index.php?title=MediaWiki&oldid=1527」から取得