Home » ブログ
検索・リンク
ブログ  ブログ以外
最近の記事
Amazon
2009 年 11 月 19 日

Fedora12(X86_64)のFireFoxにFlashプラグインをいれる

2009/11/18にFedora12がリリース。
実はG41のintel GMA X4500 グラフィックス内蔵のマザーを購入したのだけど、Fedora11(X86_64)をのせたら、DVIで高解像度にならないので、Fedora12のリリースをずーとまっていました。xorg-drv-intelのドライバーもUPされ、高解像度OK。満足満足。
さっそくFedora12(x86_64)をインストール。今のところ、快調。Fedora11(X86_64)のgeditの外部ツールの不具合も今回はOKにようだ。
それにしては、FireFoxは相変わらず速い。さっそくFlashをいれたいところなのだが、やはりパッケージが見つからない。(見つけ方がわるいのかも..)
Fedora11(X86_64)のころのようにFlashを入れてみました。(adobeのサイトからrpmを取得は試していません)
http://labs.adobe.com/downloads/flashplayer10_64bit.htmlからlibflashplayer-10.0.32.18.linux-x86_64.so.tar.gzをDownloadして解凍。特権ユーザで

# cp -a libflashplayer.so /usr/lib64/mozilla/plugins

してFirefoxを再起動。

nspluginwrapperなんかもこのごろはi386をインストールしなくても音がでるようになった。
快適Fedora!

2009 年 9 月 9 日

トラックバックスパムに悩む

又、最近、海外からのトラックバックスパムのアクセスが多くなってきた。proxyを経由しているようでIPの特定は無理なようだ。(日本以外は拒否する手もあるが...)

WordPressでブログを作成しているので一括、コメント、トラックバック中止だ。暫定対応!

update `wp_posts` set comment_status ="closed",ping_status="closed"

これで、コメント、トラックバックで一括閉鎖だ。
※IPアドレスみて日本以外のIPはコメント、トラックバックを閉鎖するようにプログラム改変するのもひとつの方法かな。

2009 年 6 月 6 日

Fedora10(X86_64)でGo-OO3.0から3.1へバージョンアップ

Fedora10(X86_64)でGo-OOの3.0を導入した記事を書いたが、最近、3.1へUpdateがあったらしい。
更新の通知があったのでそのままupdate。

# yum update
Transaction Check Error:
  ファイル /opt/openoffice.org/ure/lib/cli_uno_bridge.dll (パッケージ ooobasis3.1-core01-3.1.0-9399.x86_64 から) は、パッケージ ooobasis3.0-core01-3.0.1-9379.x86_64 からのファイルと競合しています。
  ファイル /opt/openoffice.org/ure/lib/libuno_sal_textenc.so.3 (パッケージ ooobasis3.1-core01-3.1.0-9399.x86_64 から) は、パッケージ ooobasis3.0-core01-3.0.1-9379.x86_64 からのファイルと競合しています。
  ファイル /opt/openoffice.org3/program/kdefilepicker (パッケージ ooobasis3.1-core01-3.1.0-9399.x86_64 から) は、パッケージ ooobasis3.0-core01-3.0.1-9379.x86_64 からのファイルと競合しています。
  ファイル /opt/openoffice.org3/program/oosplash.bin (パッケージ ooobasis3.1-core01-3.1.0-9399.x86_64 から) は、パッケージ ooobasis3.0-core01-3.0.1-9379.x86_64 からのファイルと競合しています。

競合か
何か操作すればすんなりupdateするのだろが、面倒なのでremoveして再インストール

# yum remove openoffice*
# yum install openoffice.org3 openoffice.org3.0-redhat-menus* openoffice.org3-writer* openoffice.org3-calc* openoffice.org3-impress* openoffice.org3-base* openoffice.org3-ja*
・
・
No package openoffice.org3.0-redhat-menus* available.

リポジトリがおかしいのか?
マニュアルでエラー箇所だけインストール

# yum install openoffice.org3.1-redhat-menus*

とりあえずインストールはOKのようだ。

2009 年 5 月 28 日

MODxで動的に画像を作成する。

MODxでスニペットを呼び出して動的画像(imagepngを使用)を作成しようと思った。
うまくいかない。
php単独だとうまくいく
ソースは以下(よくWebで紹介されているもの:ここ参考


<?php
    //出力文字の取得
    $setstring = "aaaa";
    //画像の作成
    $img = imagecreate(100, 20);
    //色の作成(背景色)
    $backcol = imagecolorallocate($img, 160, 160, 160);
    //背景色を塗る
    imagefilledrectangle($img, 0, 0, 200, 80, $backcol);
    //色の作成(文字)
    $col = imagecolorallocate($img, 255, 255, 255);
    //文字を書く
    imagestring($img, 2, 10, 4, $setstring, $col);
    //画像出力
    header("Content-type: image/png");
    header("Cache-control: no-cache");
    imagepng($img);
    //画像の消去(メモリの解放)
    imagedestroy($img);
?>

こいつをそのままスニペット(imagecreate)化して

<img title="TEST" src="[!imagecreate!]" alt="TEST" width="100" height="20" />

というコンテンツを作成したが表示されない。
以前、javascriptで同じように処理を作成した時はうまくいったのに…
あることに気づいた。スニペットが先に処理されているのを忘れていた。
ということで、コンテンツを2つ作成して順次処理させればOKだ。

<img title="TEST" src="/modx/imagecreatedummy.html" alt="TEST" width="100" height="20" />

imagecreatedummy.htmlの内容

[!imagecreate!]

phpのソースを作成して呼び出せばもちろんOKなのだが...
(それじゃMODxのスニペット化の意味がないか。処理は同じだが...)

2009 年 5 月 10 日

MODxで動的ページを静的HTMLファイルに出力する。

MODx(0961p2)で動的ページを静的ページとしてファイル出力している。
フリーソフトのWeb巡回ソフトで動的ページを出力していたのだが、内部コンテンツの変換(特にリンク関係)に不満があった。
出力されたhtmlファイルに対して、変換補正やファイル名の変更が必要だ。
Web巡回出力と変換補正(perlを使用)で膨大な時間を費やす。
そこで、MODxのエクスポート機能を使用してみた。巡回ソフトのようにページャーで作成された「次へ」リンクページは出力されない(当然か)し、出力が遅い。
topでプロセスを見る。

ソースは見ていないが、1ドキュメント単位にhttpdへパケットが送信されているようだ。
(Web巡回ソフトと基本的に同じ動きだ。)
結局、自前でスニペットを作成してhtmlファイル出力することにした。
ポイントは以下。

  1. document.parser.class.inc.phpのexecuteParserのコピーexecuteParserAを作成する。
  2. document.parser.class.inc.phpのprepareResponseのコピーprepareResponseAを作成する。
  3. document.parser.class.inc.phpのoutputContentのコピーoutputContentAを作成する。
  4. executeParserAのprepareResponseの呼出をprepareResponseAにする。
  5. prepareResponseAのoutputContentの呼出をoutputContentAにする。
  6. outputContentAの最後あたり
    echo $this->documentOutput

    をコメントにし、

    $docout = $this->documentOutput;

    のようにしてprepareResponseAへreturnする。後は、prepareResponseA、executeParserAでも同様だ。(必要に応じて不要部分を削除したほうが良い)

  7. 動的出力スニペット
  8. $_REQUESTにアクセスページ(alias)やパラメータを設定する。
  9. $_GETも$_REQUESTと同様に必要に応じて値を設定。
  10. executeParserAを呼出し、取得したページを出力する。

httpdへ再リクエストしないようにしたら、巡回ソフトの出力時間の約1/5の時間で終了するようになった。
最新のMODxのバージョンではエクスポート機能が改善されているかもしれない。
(まだ、最新もインストールしていない)

※MODxの記事を公開すると海外からのクラッカー攻撃が増えるので悲しいかな今回もコメントとトラックバックを中止します。

2009 年 5 月 4 日

firefoxでphpMyAdminのログイン画面が真っ白

phpMyAdminで作業をしていたら突然、画面がハング。(http://localhost/phpMyAdmin/)
原因がわからず、再度ログインするも画面が真っ白。OSを再起動しても同じだ。
環境はfedora10(x86_64)でfirefox3.0.10
mysqlはコマンドから操作できるので、mysqlはおかしくない。
ハングしたユーザと違うユーザでgnomeにログインして画面を開くときちんと表示される。
これはキャッシュかなと思い、キャッシュクリアしてもだめだ。
urlを127.0.0.1や内部アドレスにすると表示がOKだ。firefox以外のブラウザ表示はOKだ。
原因はクッキー。firefoxの設定でlocalのクッキーを削除。

localのphpMyAdminのクッキーを削除したら見事表示されるようになった。
どうしたんだfirefox。
※未だに突然のfirefoxのプロセスダウンに悩まされている。仕事になんねや!

2009 年 3 月 19 日

MODxのチャンク出力で改行を「<br/>」に変換する

MODxでチャンク出力してデータの改行に<br/>をいれようと試してみた。
環境はMODx0961p2、サーバfedora10で文字コードはUTF-8である。

$replace =  "\n";
$scriptphp = "<br/>";
$data = str_replace($replace, $scriptphp, $data);

※$data チャンク出力してデータ
こんなかんじで実装してみたがうまくいかない。
MODxを使用しない環境でチャンク出力したデータではないがPHPを動かすとうまくいく。
試しに、MODxで

$data = nl2br($data);

これはOK。
改行コードをWindowsに変更してみた。

$replace =  "\r\n";

うまく変換する。
おいおいおい、私の頭は混乱中。

2009 年 3 月 2 日

MODxのDittoでrssを出力するが、bodのアクセスの関係で断念

MODx(0961p2)でDittoでRss出力をした。
Bodがくるようになったらrssにアクセスばかりしていて止まらない。
2~3分おきにきている。よく調べてみる。ほっとくと1日ぐらいはこの状態が続くらしい。
何が悪いかというと更新していません「304」を返していないのが悪かったようだ。
未だ、MODxで「304」の返し方が分からないので、自作でrssをファイルに出力するように変更した。
Apacheのほうで、If-Modifiedの対応をしてくれるのでこれでアクセスがなくなった。
悲しいかなDiito。

2009 年 2 月 26 日

fedora10でキーボーレイアウトがいつのまにか日本jp106でなくなった。

fedora10(x86_64)で2/26にパッケージのupdateをして、再起動したらキーボーレイアウトがUSAに変わってしまっていた。
よくGNOMEのログオンメニューのキーボードや言語を間違えてしまい、しまったと思うことがあるのだが、自然にレイアウトが変更されてしまった。
UPDATEされたパッケージのせいか、OPミスか不明。
現象は以下。
レイアウト変更された設定

変更後

2009 年 2 月 17 日

MODxでドキュメントが5,000を越えたらキャッシュでエラー

MODx(0.961p2)でドキュメントの数に制限があるのが分からなかった。
ドキュメントを6,000個作成したら、管理画面が真っ白になった。
apacheのerror_logを見る。

[client 127.0.0.1] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 31457280 bytes) in /modxshop/assets/cache/siteCache.idx.php on line 21363
 

どうやら、Cacheのサイズに制限があるようだ。
MODxのフォーラムをみるとドキュメント数は5,000ぐらいが限界で、バージョン0.97でこの問題を解決するようなことが記載されていた。
しかし、諦めきれないので、単純にメモリを増やすことを試みる。
php.iniのメモリを増加

memory_limit = 32M      ; Maximum amount of memory a script may consume (16MB)
                                ↓
memory_limit = 64M      ; Maximum amount of memory a script may consume (16MB)

これでhttpdをrestartしたらOKだった。
しかしパフォーマンスが悪い。この際だから不要なものは整理。
siteCacheの内容をみる。ドキュメントとしての情報は以下。

$a = &$this->aliasListing;
$d = &$this->documentListing;
$m = &$this->documentMap;
$d['home'] = 1;
$a[1] = array('id' => 1, 'alias' => 'home', 'path' => '');
$m[] = array('0' => '1');
$d['feed.rss.xml'] = 51;
$a[51] = array('id' => 51, 'alias' => 'feed.rss.xml', 'path' => '');
$m[] = array('0' => '51');
$d['doc-not-found'] = 27;
$c = &$this->contentTypes;
$c[1] = 'text/html';
$c[27] = 'text/html';

これらの配列がドキュメントの数だけある。
当処理で不要な以下を削除することにした。cache_sync.class.processor.phpを改造。

  1. 配列cの’text/html’(5958個)
  2. 配列mの最下層クラス(5900個)

1.は当処理で問題なし。
2.はサイドメニュー(Wayfinder)の処理がおかしい。しかしメチャメチャ速くなる。
WayfinderはgetParentIdsで親子関係の処理ができなくなるようだ。
汎用のロジックを諦め、当処理用に独自改造してOK。
MODx0.96系ではドキュメント数が少ないコンテンツには適しているが、多くなるとパフォーマンスのためにロジックの見直しがかなり必要だと分かった。

ドキュメントが多くなると注意すべきこと

  1. SEO Strict URLs(全ドキュメントに対するrewrite処理)
  2. Wayfinder(親子関係のlevelの検索,sql)
  3. Ditto(同上)
  4. 大量のタグ(1バッファーにある大量のタグの変換)

△ページトップ

Google
ページ
最近のブログ
アーカイブ
カテゴリー
最近のコメント
最近のトラックバック
    No Responses.