PiCMO エンジニアサイドブログ

新着情報	2014/04/28 「WordPressプラグイン TypePad 絵文字 for TinyMCE」が更新 2014/04/28 「TypePad 絵文字 for TinyMCE 1.5リリース」が更新 2014/04/25 「TypePad絵文字がWordPress3.9で正常に動作しない問題 [解決]」が更新 2014/04/23 「TypePad絵文字がWordPress3.9で正常に動作しない問題」が更新 2013/10/12 「写真のデータが飛んだ (T_T」が更新 2013/09/25 「本日サーバーアップグレード作業完了」が更新 2013/09/25 「本日サーバーアップグレード作業中」が更新 2013/09/18 「数日中にサーバーのグレードアップを行います」が更新 2013/09/18 「9月17日　サーバー電源工事のため緊急メンテナンスを行います」が更新 2013/09/12 「sony vaio VGN-SZ51B,SZ71B Windows7 ハードウェアドライバ」が更新

いつもTypePad絵文字 for TinyMCEをご利用いただいている皆様ありがとうございます
大変長らくお待たせいたしました。

先ほど、WordPress Plugin Directoryのバージョンも1.5をリリースしました

もちろん、WordPress3.9(TinyMCE 4.x)でも正常に動作します
ブラウザは下記で確認しています。

IE10、IE11
Google Chrome 34.0.1847.131 m
FireFox Update28

申し訳ありませんが、これ以外のブラウザについては検証していないので動作しているかは未確認です

最近ちょっとバタバタとしていたため、リリースが遅れてしまいました
また気になるところや不具合などあればご連絡ください。
できる限りは対応してみます

私の開発した、TypePad絵文字がWordPress3.9で正常に動作しなくなってしまう問題ですが、無事原因がわかりました
これはWordPressの問題ではなく、WordPressでリッチテキストエディタ「TinyMCE」のバージョンが4シリーズにメジャーバージョンアップしたことが原因でした。
現在、このページで動作確認していますがすこぶる動作は調子がいいです

いまのままでは、既存のバージョンに対応できないなどの問題があるためリリースできる状態にありません。
正しく旧バージョンでも動作して新バージョンでも動作できるプログラムにしてリリースさせていただこうかと思います。

取り急ぎ近日中にリリースできると思いますのでもう少々お待ちください

いつも、TypePad絵文字をご利用いただいてありがとうございます。
さて、WordPress3.9にアップデートするとTypePad絵文字が正常に動作しないというお問い合わせが多くいただくようになりました。

動作確認したところウィンドウは表示されるものの、絵文字が反映されないというもの。

絵文字ウィンドウが表示されないといった方も、いらっしゃいますがIE10、FireFox、Google Chrome(Ver 34)で確認しましたがいずれも正しく表示されています。
表示されていない方はそれ以外の問題があるようです。(他のプラグインとの相性など)

少し改修をどのように行うかを検討していきたいと思いますのでもう少々時間ください。

最近身辺でも、引っ越しなどをせねばならず結構忙しくやっています。
合間の時間を見ながらやっていますので・・・すみませんっ。

年末にWordPressがバージョンアップしまして、３．５になりました

早速当サイトのシステムも新しいバージョンに更新しました。
今回も互換性のエラーなどは一切ありません
相変わらず、良い仕事をしていますね、WordPress 開発チームは。

当サイトで開発を行いました、TypaPad 絵文字も僕が私用した限りでは異常などは見受けられていません
もし、不具合など有りましたらご指摘下さいませ

当サイトでも、至る所でAdobe Flashを利用して動的な表示を行っています。
実は少し前より、トップページにある画像をぐるぐる表示させるFLASHが正常に動作しなくなってしまう問題に悩まされおりました

ブランディング FLA 編集作業中

表示されないのは、最新版のGoogle Chrome
実はちょっと前は問題なくGoogle Chromeでも動作していたのだが最近になって動作不良になったもの
症状としては、フレームなどは表示され画像のロードが終わった瞬間に動作が停止してしまう。

この症状、現在のところ僕の環境では Google Chrome でのみ発生する事象でほかのブラウザでは発生しない。
さらに追求していくと、 Google Chrome の問題ではなく、Google Chromeに内蔵されているAdobe FLASH Player 11に問題があることがわかった

Adobe FLASH Player 11はちょっとまえから結構問題発生していたりする
有名なところではニコニコ動画やYou Tubeが正常に再生されなくなるなどの問題が発生し、多くのユーザーが頭を抱えさせた
現在有力な解決方法は、FLASH Player を 11 から 10 に下げること。

ってこれ・・・　僕の中では解決方法ではないと思う
だって、Playerのバージョンを下げるの面倒だもの。
ニコニコ動画や、You Tubeのためならまだ多少の手間もかけるだろうけどねぇ・・・

原因

まぁ、そんなこんなで作り方で解決できないかとおもって自分のソースコードからやっと問題点を発見

空のムービークリップを配置して画像を loadClip でロード。
そのムービークリップの onEnterFrame イベントを捕まえてスクロール処理のプログラムが組まれています。
どうやらこの onEnterFrame イベントが延々発生しないみたい。

onEnterFrame イベントが発生しないとフラグが立たないのでここで動作が止まってしまう。

対策

実は対策はなんてことはない。
要は、画像の読み込まれるムービークリップの性質が変化してしまう。
画像を読み込んでいるムービークリップなどがあればそれを入れ子のムービークリップにしてしまうことで解決できる。

変更前のソースコードなこんな感じだとする

createEmptyMovieClip("th0", 0);
 
load_obj.onLoadInit = function( clip:MovieClip ) {
 //一旦、画像を非表示にしておく
 clip._visible = false;
 //読み込みが完了した総数を更新
 loaded_cnt++;
};
 
// エラー発生時の処理を定義
load_obj.onLoadError = function() {
};
 
// 画像をムービークリップに割り当て
load_obj.loadClip( path, this.th0 );
 
// FLASH Player 11 ではこのイベントが取得できなくなる
this.th0.onEnterFrame = function() {
 // イベントの内容
}

上記のコードを下記のようにムービークリップを入れ子とする

createEmptyMovieClip("th0", 0);
th0.createEmptyMovieClip("thp0", 0);
 
load_obj.onLoadInit = function( clip:MovieClip ) {
 //一旦、画像を非表示にしておく
 clip._visible = false;
 //読み込みが完了した総数を更新
 loaded_cnt++;
};
 
// エラー発生時の処理を定義
load_obj.onLoadError = function() {
};
 
// 画像をムービークリップに割り当て
load_obj.loadClip( path, this.th0.thp0 );
 
// FLASH Player 11 でも動作する
this.th0.onEnterFrame = function() {
 // イベントの内容
}

単純にcreateEmptyMovieClip でムービークリップを作成し、さらにそのムービークリップの中に読み込み用のムービークリップを作成する。
画像は入れ子となったムービークリップの中にロードすることで、親のムービークリップでは正しく onEnterFrame イベントが発生するため正しく動作するようになる。

解決してみればどうってことはないんだけど、なかなか原因がわかりにくいものでこれを突き止めるまで丸一日かかってしまった
だって、Adobe FLASH CS5では、正常にパブリッシュして動作してしまうのだもの
そりゃFLASH Player 10だから当たり前なんだけどね。

この現象ちょっとググってみたけどまだどこでも載っていないみたい。
ってか、みんなこんな作り方していないのかな？
それとも、こんな程度でハマるの僕だけ？

いずれにしても Adobe も高いソフトウェアなんだからしっかりとその辺サポートしてほしいものですよねぇ。
Player のバージョンによって互換性がなくなるのは一番困る。
今回は僕がたまたま最新のFLASH Playerを目にする環境だったからよかったようなものの、気がつかなかったら完全に後手に回っていたもんなぁ。

何にしても解決できてすっきりしました

アバターの登録について

当サイトのコメント欄には、アバター画像の表示をすることが可能です

実はコレ、管理者だけの特権機能ではありません
誰でも使える機能で、比較的簡単に登録することができます。

といっても、当サイトで登録をするわけではなく「Gravatar」というサイトに登録する必要があります。
登録はメールアドレスと、画像を登録するだけの至って簡単な登録手順です。
もちろん当サイトだけではなく他にWordPressを利用していたり、Gravatarを利用しているサイトがあれば同様にそのまま表示されます。
興味のある方は一度登録してみてください。

このサイトに登録するとスパムなどが増えるんじゃ？と思っておられる方もいらっしゃるかも知れませんが今のところ僕はそれらしいスパムは届いておりません。

登録手順

Gravatorに飛ぶ
https://ja.gravatar.com/ でサイトに飛びます。
最初にメールアドレスの登録
①の場所に利用するメールアドレスを入力し終わったら ②を押します。
確認のメールが入力されたメールアドレスに送信
自動的に送信されていますので、メールを確認して認証用ＵＲＬをクリックしてください。
ちなみにメール内容は英語ですが、それほど難しいコトは書かれていないのですぐに分かると思います。
最後に必要情報の入力 ユーザー名を半角で付けて、パスワードを入力すれば登録ＯＫです。
登録は以上です。
非常に簡単です
後は画像を登録して、登録したメールアドレスを当サイトの「メールアドレス」フィールドに入力していただければ表示される仕組みです。

ココ重要ですよ。
登録したメールアドレスと、当サイトのメールアドレスの入力内容は一緒で有る必要があります。ちなみに、登録後すぐには反映しないようです。
だいたい１日ほどは様子見が必要なようです。

後は登録したメールアドレスと画像がセットになって、対応しているサイトなら全て同じアバターを利用できます。
もちろんGravatarの画像を切り替えれば他のサイトの画像もすべて変わっています。
便利な機能ですね

簡単なのでみなさま是非使って見てくださーい

梅雨が明けたとたん暑い日が続いていますね
毎日のこの暑さで僕もバテバテです

という挨拶はほどほどに、実は本日サーバーが停止していました
ご覧頂いた皆様には申し訳ありませんでしたm(_ _)m

どうやら、AM11時14分頃の停止のようです。

まぁ、いつもだったら僕もどうしようとか考えてしまうのですが・・・
今回の原因はすぐにはっきりしていたので気は楽？です。

IMPI Event LOG

SYS Ambient Temp Temperature
Upper Critical Going, Deassertion

上はマザーボードのIMPIイベントログです。
原因はそのエラーのまんまの意味で、

要は、熱くてやってらんねー

って事です

帰ってサーバーを見てみると、シャットダウンされていました。
Linuxシステムログにはエラーは一切無く正常終了だったのでＵＰＳあたりがシャットダウンコマンドでも発行したか？？
と思ったのですが犯人はマザーボードでした。

うちのサーバーML110 G6は、サーバー専用機でとても安定している素晴らしいサーバーです。

ただねぇ・・・

サーバーマシンはだいたいどれもとてもデリケートです。
各種センサーや、異常監視機能、普通のパソコンよりも少しばかり余計に付いています

本当のサーバールームとかは、温度管理はばっちりですもんねぇ・・・
省エネ、節電が騒がれる中、無人となった自室のサーバーラックに空調が入るわけがありません

原因はわかっていても、結果この猛烈な暑さにお願いをする以外に方法がないところが歯がゆいところです。
エラーからして、ＣＰＵでも、ＨＤＤでもなく、チップセットシステム温度のエラーらしいので空冷の限界といったところでしょうか。
そもそもシステム温度は上限が48度設定となっていますので、もともと閾値が低いようです。
その閾値の設定変更は出来ないようです。

ただLight-Out 100で、閾値を超えたときの動作設定が出来るようなので設定を変更してみました。

PEF Configrationで、Power OffをDisabledにしましたが、さて今度はうまくいくでしょうか。

本来はこんな危ない設定をするより、冷やす方法を考えなければなりません。

ただ、天候のすることなら致仕方有りません。
何せ天災みたいなモンですから・・・

ケースのエアフローを考えるとか多少出来ることもありますが、部屋の温度を下げることが抜本的な改善方法だと思っています。
流石に無人の部屋のエアフローを改善させるとホームセキュリティー的にいまいちどうなの？？って話で。
その高温になった部屋という箱の中に設置されている、サーバー筐体のエアフローを改善したところでたかがしれています

この設定でマザーボードがやられたらそれも天候のせいにして、新しいサーバーマシンでも・・・（ぁ
どうやらML110 G7もずいぶんお手頃価格なようだし・・・（ボソ

とかは全然考えていないです

・・・・

・・・・・・

考えていないですからねー

なににしても動く限りちゃんと使ってあげないとね

ML110 G7化はとりあえず置いておいても、ご利用して頂いてる皆様にご迷惑をお掛けしますので筐体エアフローは後日検討します
G7にしても、結局は暑さが原因なら改善はしないだろうし・・・

WordPress 3.4 がリリースされました。
早速当サーバーも導入して、 TypePad emoji for TinyMCEの動作検証をしてみました。
WordPress 3.4および、TinyMCE Advance 3.4.9での動作が問題無いことを確認いたしました

しかし現在 Contact Form 7の最新バージョン 3.2を同時にインストールすることでアイコンパレットが正常に表示されなくなるという不具合が発生しております
対策の方法などは「WordPressプラグイン TypePad 絵文字 for TinyMCE の動作不良を確認」をご参照ください。

出来れば、Contact Form 7側で修正されることを望みますが、あまりにも対応が悪い場合はこちらで対策が出来ないかを模索してみようと思っています。
ただ７月以降の対応になってしまうと思いますのでお急ぎの方はContact Form 7のバージョンを下げてご使用ください。

WordPressプラグイン「TypePad 絵文字 for TinyMCE」をご利用頂きましてありがとうございます。

僕の開発しました「 TypePad 絵文字 for TinyMCE 」において正常に稼働出来なくなる環境が確認されましたのでご報告をさせていただきます。

こちらの現象は Contact Form 7 Version 3.2.1 では解消いたしました

現象 (解決済み)

Contact Form 7を3.2にバージョンアップしますと正常に「TypePad 絵文字 for TinyMCE」が稼働出来なくなるようです。
TinyMCE上から、「TypePad 絵文字 for TinyMCE」の起動用アイコンをクリックすることでウィンドウは立ち上がりますが、アイコンパレットが正常に表示されません

おそらくContact Form 7のバージョンアップによってプログラムに悪影響が出たものと思います
このときのPHPからのエラーコードは、Contact Form 7内のプログラムソース内でエラーが起こっていることを確認しています。

対象となる環境

・WordPress 3.3.2
・Contact Form 7　3.2

対処方法

エラーが発生しましたら、Contact Form 7を3.1.2にバージョンを下げていただくことで解消します。
バージョンダウンの手続きは、WordPress上から行うことは出来ません。

FTP等で直接プラグインファイルの上書きをする必要が有ります。

可能な方はContact Form 7の古いバージョンで上書きしてお使いください。
Contact Form 7は、下記のURLで最新版以外のバージョンを取得することが可能です。

https://wordpress.org/extend/plugins/contact-form-7/developers/

動作確認しているバージョンは 3.1.2 です。

稼働可能なバージョンのデータを上記からダウンロード解凍しFTPでContact Form 7を上書きします。
Contact Form 7のインストールパスは一般的には下記の位置になります。

/wp-content/plugins/contact-form-7/

今後対応

Contact Form 7側でこの問題が改善されることを望んでいます。
しかし次のバージョンに至っても修正がされない場合は、当プラグインで正常に稼働出来るように修正出来ないかを模索させていただきます

先方のバグの可能性もあります。
それに対応してこちらが修正するというのもナンセンスなのでどうしても対応出来ないようなのでしたらこちらでの対応も考えます。

もし、次のバージョンで改善された等ありましたら、再度当ページでご報告をさせていただきます。

上記を行って動作したや、動作しなくなったや、ご不明などありましたらお気軽にコメントに書き込んでくださいませ

WordPressプラグイン「TypePad 絵文字 for TinyMCE」をご利用いただきましてありがとうございます。

WordPress のバージョンが 3.3.2 にバージョンアップ後、特定のブラウザで絵文字パレット内にスクロールバーが出てしまうケースが確認されました
このためウィンドウサイズの調整、およびＨＴＭＬ構文の修正などをおこなってスクロールバーの発生をしないように調整した バージョン 1.4 をご準備しました

WordPressの下位のバージョンでもウィンドウの余白が大きくなるかも知れませんが、基本的に問題無いであろう修正方法を選んだつもりです。
しかし自分のWordPressは最新版にあげてしまったため確認出来ません。
もし不具合など確認出来ましたらご連絡いただければと思います。

また、WordPress Plugin DirectoryのSVNも更新してありますので、WordPressから自動更新にも対応しています。
最新のバージョンは1.4です。

修正内容

特定ブラウザにおいて、アイコンパレット内にスクロールバーが発生してしまう問題の修正を行いました。
・ウィンドウサイズの調整
・ＨＴＭＬ構文の修正

更新方法

ダウンロードはこちらからどうぞ

WordPress.org プラグインディレクトリの内容も最新版に更新させていただいております。
https://wordpress.org/extend/plugins/typepad-emoji-for-tinymce/
WordPress管理画面から容易に追加・バージョンアップも出来ます。

当サイトのWordPress コアシステムを 3.3 からセキュリティーホール対策版になります 3.3.2 へバージョンアップしました
相変わらず安定のバージョンアップです

今回のバージョンアップは、主にセキュリティーホール対策の修正が主になるためそれほどの機能追加はないようです。

ただ、僕の開発しました「TypePad 絵文字 for TinyMCE」では Google Chrome でパレット部分にスクロールバーが出てしまうなどの問題が出てしまいました
それ以外の動作は問題無いので、特定のブラウザでスクロールバーが気にならない方は使用されつづけても問題無いかと思います
ちなみに、IE9では、スクロールバーは出ていないようでした。

今日中にはプラグインの修正版をアップします
> ダウンロードページ

3.3 へバージョンアップしてから特に別段問題無く使用させていただいていたのですが、セキュリティーアップデートも含めた 3.3.1 がリリースされていたのでアップデートしました。

プラグインを開発させていただいている都合上、バージョンアップは早めの確認が必要ですので。
今回のバージョン 3.3.1 でも、プラグインを含め動作の方も問題有りません

特に常用するところでの変化は見られませんが、逆に何も無いことが良いことだなーと思っております

毎回WordPressのバージョンアップには良い意味で驚かされます

WordPress わぷー

上のキャラクターはWordPress日本語版公式キャラクターのわぷーです。
かわいいです

さて今回の機能バージョンアップですが、ファイルのドラック＆ドロップアップロードに対応など新機能が詰め込まれています。
今までやりたくてもなかなか出来ない技術を惜しげもなく早速取り入れてきました。
機能的な話は少し使用してみてからさせていただこうかと思います。

取り急ぎWordPressのバージョンアップについてですが、結果から言って全くもって何も問題有りません

毎回驚かせられるのは、バージョンアップに何の問題も発生しないこと。
以前使って居たMovable Typeでは考えられません

メインプログラム、システムに異常なしなのはもとより
自作のテンプレートも異常なし
自作のプラグインも異常なし
その他プラグインなども異常有りません

というわけで、僕が作っている WordPress 絵文字プラグイン「TypePad emoji for TinyMCE」も全く問題無くそのままでお使いいただけます。
TypePad emoji for TinyMCEもおかげさまで600回ほどのダウンロードをしていただいております。
結構お使いいただいているようでうれしい限りです。
少しでも、皆様のお役に立てたら幸いです。

WordPressの技術者に感謝しつつ、取り急ぎ当サーバーのバージョンが正常にアップデート出来たご報告まで。

NEC Express 5800Gc サーバーは、その当時NTT-Xで投げ売りされるなどして結構台数を伸ばしたサーバーではないでしょうか。
現在もNECのエントリーモデルは１万数千円から購入できるスタイルは変わっていません。
その当時サーバーマシンが１万数千円はなかなか無かったので、よくお客様に納品の際にはその価格と信頼性故に飛びついたものでした

今回はメンテナンスで引き上げてきたサーバーをチェックをしながら導入可能なLinuxについて検証させていただきました。

Express 5800Gc の基本的なスペック

マザーボード
GigaByte製 GA-8ICMT
対応CPU
LGA775 Intel Pentium Prescott CPU
つまりPentium 5xxシリーズまで
チップセット
Intel MCH E7221
Intel ICH6R
オンボードビデオ
Intel MCH E7221 chipset
LAN
Intel 82541P1 Taboriii GbE
RAID
RAID 0,1
メモリスロット
DDR SDRAM × 4
ディスクインターフェース
FDD × 1
IDE × 1
SATA × 4
拡張スロット
PCI-Express x1 ×1
PCI-Express x8 ×1
PCI 32bit/33Mhz ×2

CPUがPrescottまでの対応になりますので、決してスペックとしては高くありません。

インストール可能な Linux

先ほどCentOS 6.1 を導入を試みたのですが、グラフィックドライバが未対応なためなのか、テキストインストールをしなければなりませんでした。
インストール後ドライバを捜すなり、強引にインストールさせるなどして X を動作させることも出来るかもしれません。
しかしもう古いハードなのであまり手を入れず出来れば手っ取り早く X までインストール可能な Linux ディストリビューションを調べたいと思います。

CentOS

CentOS 6.1	グラフィックが正常に表示されずテキストインストールで正常にインストール
CentOS 5.7	問題無くフルインストール可能
CentOS 4.9	問題無くフルインストール可能

Fedora

Fedora 8以降	グラフィックが正常に表示されずテキストインストールで正常にインストール
Fedora 7以下	問題無くフルインストール可能

RedHat Enterprise Linux

RHEL5以降	グラフィックが正常に表示されずテキストインストールで正常にインストール
RHEL4	問題無くフルインストール可能

以上のような結果になりました。

おそらくは搭載のIntel MCH E7221 chipsetのビデオ機能のドライバの問題だろうとおもいますが、とりあえず検証結果だけを残しておきます。

グローバルサインは最近SSLの暗号化キーの鍵長が RSA 2048bit 以上の長さが必要になりました。
強固な暗号通信の為だと思いますが、今まで1024 bit で作業していたので鍵の作り直しが必要になります。
そんな 2048bit 対応の SSL 化についてまとめてみました。
1024 bit も少し改変すれば対応出来ますので、1024 bit でお作りになられたい方もどうぞ。

基本的に第三者認証をすることを前提に作業しています。
また、ここでの前提条件はtcpserverを使って正常にサービスが実行されていることを前提とされています。
もちろんtcpserverで実行されるサービスは qmail に限定されてはおりません。
tcpserver を使う限りどのようなサービスでも同様の設定で動作可能です。

qmail などの設定などは時間があったら書きたいなと。

tcpserver の SSL 対応化

最初の作業はtcpserverをSSL対応にすることです。
通常tcpserverはソースひー土で取得したときはSSLには対応しておりません。
それをまずはSSL対応のパッチを当ててSSLに対応させる必要があります。

■ tcpserver (ucspi-tcp)のソースコードダウンロード先
https://cr.yp.to/ucspi-tcp.html

■tcpserver SSLパッチダウンロード先
https://www.nrg4u.com/

パッケージは次の物がダウンロードされるはです。
ucspi-tcp-0.88.tar.gz
ucspi-tcp-ssl-20020705.patch.gz

展開、パッチを当てます。

# tar xvfz ucspi-tcp-0.88.tar.gz
# cd  ucspi-tcp-0.88
# zcat ../ucspi-tcp-ssl-20020705.patch.gz | patch
# make

これで、SSL対応の tcpserver ができあがりましたので。
それでは、ＳＳＬ対応化の鍵ファイルを作っていきます。

手順１　ＳＳＬ作業用ディレクトリを作る

まずは、ファイルを作られるため作業用ディレクトリなどを作ってそれをカレントディレクトリとしておきます。

手順２　秘密鍵を作る

# genrsa -out private.key 2048
 Generating RSA private key, 2048 bit long modulus
 .........+++
 .....................................................................................................................................+++
 e is 65537 (0x10001)

これでprivate.keyというファイルの秘密鍵を作りました。 genrsa -out private.key 1024 に変えることで 1024bit長の秘密鍵を作る事が出来ます。

手順３　認証用ＣＳＲを作る

# openssl req -new -key private.key -out csr.pem
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 -----
 Country Name (2 letter code) [AU]:JP (国名)
 State or Province Name (full name) [Some-State]:都道府県名
 Locality Name (eg, city) []:市町村名
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:企業名　個人の場合はPersonalなど
 Organizational Unit Name (eg, section) []:部署名
 Common Name (eg, YOUR name) []:メールサーバーなどtcpserverのおかれるサーバー名
 Email Address []:

これで、csr.pem (認証申請書CSR)が作られます。

手順４　申請用ＣＳＲを表示して申請を行う

# cat csr.pem
 -----BEGIN CERTIFICATE-----
 ~ 中略 ~
 -----END CERTIFICATE-----

という内容が表示されたと思います。
こちらをSSL認証局などに提出して認証を受けます。

手順５　ＳＳＬ認証用鍵ファイルの生成

tcpserver では、秘密鍵と公開鍵とをそれぞれ別々に呼び出すことは出来ない。
そのため、ＳＳＬで暗号化する鍵ファイルを生成する必要があります。

といっても、至って簡単でそれぞれのファイルを一つのファイルに連結するだけで作る事が出来ます。

まずは、認証局から承認された証明書を public.key として保存します。
その後下記の手順で鍵ファイルを生成します。

# cat ./private.key > cert.pem
# echo "" >> cert.pem
# cat ./public.key >> cert.pem

これで、鍵ファイル cert.pem が生成されました。
１行目で、cert.pem の内容を private.key を書き込み、２行目で空白の行を追加。
３行目で、証明書を追加する。
というファイルになっています。

これでtcpserverで読み込み可能なSSL鍵ファイルが完成しました。

手順６　tcpserverにcert.pem(鍵ファイル)を読み込ませる

tcpserver の指定方法ですがサンプルとして vpopmail での pop3 を tcpserver で稼働させているとします。
通常のPOP3 (ポート110) でのコマンドは下記です。

/usr/local/bin/tcpserver -l 0 -R -H -v \
 -u"81" -g"81" 0 110 \
 /var/qmail/bin/qmail-popup [ホスト名] \
 /home/vpopmail/bin/vchkpw \
 /var/qmail/bin/qmail-pop3d Maildir 2>&

上記の起動コマンドを下記のようにSSL対応に書き換えます。

/usr/local/bin/tcpserver -l 0 -R -H -v -s \
 -u"81" -g"81" \
 -n /var/qmail/certs/cert.pem \
 /var/qmail/bin/qmail-popup mail.intergear.net 0 995  \
 /home/vpopmail/bin/vchkpw \
 /var/qmail/bin/qmail-pop3d Maildir 2>&1

書き換えた内容が上記です。
出来るだけシンプルにするためcdbなどの読み込みなどはしておりませんので必要に応じて変更は必要になります。

増えた記述は下記です。

-s　： SSL通信であることを指定するオプション tcpserver にSSL パッチを当てないと動作しません。
-n　：鍵ファイル (cert.pem ) までのパスを記述します。
ポート番号　： 110 から POP3Sの標準ポートである 995 へ変更しました。

書き換えのポイントは以上です。

最後にサービスのリスタートをしてメーラーなどを使って証明書のエラーなどが出なければＯＫです。
メーラーによってはそういったエラーを出力しない物などあります。
Outlook などは証明書エラーがあればかならず表示されますので、一度は試して見るのが良いと思います。

先日 PHP を 5.2 にバージョンアップを実行して使用していたのですが、pearのパッケージもカレンダーパッケージをインストールをしようとしたところ正常に実行することが出来ませんでした。

# pear install Calendar-beta
 WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
 Did not download optional dependencies: pear/Date, use --alldeps to download automatically
 pear/Calendar requires PEAR Installer (version >= 1.5.0), installed version is 1.4.9
 pear/Calendar can optionally use package "pear/Date"
 No valid packages found
 install failed

どうやら、PEARのバージョン自体が低いようです。
1.5.0以降でないとインストール出来ないとのことなので早速アップグレードを実行。

# pear upgrade PEAR
 WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
 pear/PEAR dependency package "pear/Console_Getopt" downloaded version 1.3.1 is not the recommended version 1.2.3, but may be compatible, use --force to install
 pear/Archive_Tar requires PEAR Installer (version >= 1.5.4), installed version is 1.4.9
 pear/Console_Getopt requires PEAR Installer (version >= 1.8.0), installed version is 1.4.9
 No valid packages found
 upgrade failed

ぬう・・・これもバージョンアップが出来ないようです。
しかも、今度は1.5.4以降、さらには1.8.0以降でないと駄目とか言ってきます。
とりあえず、1.5.4にアップデートをさせようと PEAR のバージョンを 1.5.4 を指定して直接アップデートをかけてみます。

# pear upgrade PEAR-1.5.4
 WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
 Did not download optional dependencies: pear/XML_RPC, use --alldeps to download automatically
 pear/PEAR dependency package "pear/Console_Getopt" downloaded version 1.3.1 is not the recommended version 1.2.2, but may be compatible, use --force to install
 pear/Console_Getopt requires PEAR Installer (version >= 1.8.0), installed version is 1.4.9
 downloading Archive_Tar-1.3.2.tgz ...
 Starting to download Archive_Tar-1.3.2.tgz (17,150 bytes)
 ......done: 17,150 bytes
 upgrade ok: channel://pear.php.net/Archive_Tar-1.3.2

おっと、どうやら動きがあったようです。
しかし、それでも 1.8.0 の PEAR を要求してきます。
それではと、1.8.0を指定。

# pear upgrade PEAR-1.8.0
 WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
 pear/PEAR dependency package "pear/Archive_Tar" installed version 1.3.8 is not the recommended version 1.3.3, but may be compatible, use --force to install
 pear/PEAR dependency package "pear/Console_Getopt" downloaded version 1.3.1 is not the recommended version 1.2.3, but may be compatible, use --force to install
 pear/Archive_Tar requires PEAR Installer (version >= 1.5.4), installed version is 1.4.9
 pear/Console_Getopt requires PEAR Installer (version >= 1.8.0), installed version is 1.4.9
 No valid packages found
 upgrade failed

ありゃ、 1.5.4 を再度要求されました。
やはり 1.5.4 自体が正常にインストールが出来ていないようです。
これではインストール出来ないループになってしまっていますのでここから打開策を見つけないといけません。
再度 1.5.4 のインストールを敢行すると表記が変わっていました。

# pear upgrade PEAR-1.5.4
 WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
 pear/PEAR dependency package "pear/Console_Getopt" downloaded version 1.3.1 is not the recommended version 1.2.2, but may be compatible, use --force to install
 pear/Console_Getopt requires PEAR Installer (version >= 1.8.0), installed version is 1.4.9
 No valid packages found
 upgrade failed

use –force to install つまり、強制インストールをしろと言うことらしいです。
その前にチャンネルを更新しろというワーニングが出ているのでそれを改善してみようと実行するも・・・

# pear update-channels
 HTTP error, got response: HTTP/1.1 410 Gone
 Didn't receive 200 OK from remote server. (HTTP/1.1 410 Gone)

すがすがしいぐらいに即答されました
強制インストールしてもあまり正常に動作した経験が少ないので気が進まないのですが、このままだと手詰まりなので渋々実行。

# pear upgrade --force PEAR-1.5.4
 WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
 Did not download optional dependencies: pear/XML_RPC, use --alldeps to download automatically
 warning: pear/PEAR dependency package "pear/Console_Getopt" downloaded version 1.3.1 is not the recommended version 1.2.2
 warning: pear/Console_Getopt requires PEAR Installer (version >= 1.8.0), installed version is 1.4.9
 downloading PEAR-1.5.4.tgz ...
 Starting to download PEAR-1.5.4.tgz (293,070 bytes)
 .............................................................done: 293,070 bytes
 downloading Console_Getopt-1.3.1.tgz ...
 Starting to download Console_Getopt-1.3.1.tgz (4,471 bytes)
 ...done: 4,471 bytes
 upgrade ok: channel://pear.php.net/Console_Getopt-1.3.1
 upgrade ok: channel://pear.php.net/PEAR-1.5.4
 PEAR: Optional feature webinstaller available (PEAR's web-based installer)
 PEAR: Optional feature gtkinstaller available (PEAR's PHP-GTK-based installer)
 PEAR: Optional feature gtk2installer available (PEAR's PHP-GTK2-based installer)
 To install use "pear install pear/PEAR#featurename"

どうやら無事、 1.5.4 へのアップグレードは出来ました。
では、続いて最新版へのバージョンアップを実行してみます。

# pear upgrade PEAR
WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
downloading PEAR-1.9.4.tgz ...
Starting to download PEAR-1.9.4.tgz (296,332 bytes)
.............................................................done: 296,332 bytes
downloading Archive_Tar-1.3.8.tgz ...
Starting to download Archive_Tar-1.3.8.tgz (17,995 bytes)
...done: 17,995 bytes
upgrade ok: channel://pear.php.net/Archive_Tar-1.3.8
upgrade ok: channel://pear.php.net/PEAR-1.9.4
PEAR: Optional feature webinstaller available (PEAR's web-based installer)
PEAR: Optional feature gtkinstaller available (PEAR's PHP-GTK-based installer)
PEAR: Optional feature gtk2installer available (PEAR's PHP-GTK2-based installer)
To install use "pear install pear/PEAR#featurename"

こちらも無事通りました。
強制実行もたまには良い結果をもたらすようです。

先ほど実行できなかったチャンネルのアップデートです。

# pear update-channels
 Updating channel "doc.php.net"
 Update of Channel "doc.php.net" succeeded
 Updating channel "pear.php.net"
 Update of Channel "pear.php.net" succeeded
 Updating channel "pecl.php.net"
 Channel "pecl.php.net" is up to date

今度はきっちりアップデートを実行してくれました。
PEARのバージョンが低かったのがすべての元凶みたいですね。

最後に目的だったカレンダーモジュールを入れます。

# pear install Calendar-beta
WARNING: channel "pear.php.net" has updated its protocols, use "pear channel-update pear.php.net" to update
downloading Calendar-0.5.5.tgz ...
Starting to download Calendar-0.5.5.tgz (58,159 bytes)
..............done: 58,159 bytes
install ok: channel://pear.php.net/Calendar-0.5.5

はい、こちらもすんなりとインストールすることが出来ました。

たまにpearのメンテナンスもしてあげないとアップデートが非常に面倒になったりするようです。
バージョンアップは定期的に

CentOS などの Linux で、PHP5.2にバージョンアップさせるときyumではアップグレードできるリポジトリが無いためそのままでバージョンアップすることが出来ません。
最近は、phpMyAadminなどでも普通にPHP 5.2 以上を要求してくるようになってきたので 5.2 を比較的容易にバージョンアップさせてみることにしました。

PHP 5.2をインストールするためには c5-testing のリポジトリを追加させます。

# cd /etc/yum.repos.d
# wget https://dev.centos.org/centos/5/CentOS-Testing.repo
 --2011-12-02 15:56:37--  https://dev.centos.org/centos/5/CentOS-Testing.repo
 Resolving dev.centos.org... 204.15.73.242
 Connecting to dev.centos.org|204.15.73.242|:80... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 710 [text/plain]
 Saving to: `CentOS-Testing.repo'
 
 100%[================================================>] 710         --.-K/s   in 0s
 
 2011-12-02 15:56:37 (67.7 MB/s) - `CentOS-Testing.repo' saved [710/710]

これでリポジトリを取得できました。
次にリポジトリのプリオリティを設定する必要があります。

# vi /etc/yum.repos.d/CentOS-Testing.repo
 [c5-testing]
 name=CentOS-5 Testing
 baseurl=https://dev.centos.org/centos/$releasever/testing/$basearch/
 enabled=0
 gpgcheck=1
 gpgkey=https://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
 
 # CentOS-Testing:
 # !!!! CAUTION !!!!
 # This repository is a proving grounds for packages on their way to CentOSPlus and CentOS
 # They may or may not replace core CentOS packages, and are not guaranteed to function pro
 # These packages build and install, but are waiting for feedback from testers as to
 # functionality and stability. Packages in this repository will come and go during the
 # development period, so it should not be left enabled or used on production systems witho
 # consideration.

このファイルにプリオリティ設定を追加します。
gpgkey の次の行に「 priority=1 」を追加します。

 gpgcheck=1
 gpgkey=https://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
 priority=1
 
 # CentOS-Testing:
 # !!!! CAUTION !!!!

上記のような感じで追加すればＯＫです。
これで、アップデートの指定が可能になりました。

yum でのアップデートの指定は

# yum --enablerepo=c5-testing update php

でアップデートが実行されます。
依存性などが発生しなければこれで完了出来るはずです。

Smarty を利用してPHPのプログラムを開発していくことが多いのですが最近新しくサーバーを立ち上げてみました。
PHPや、ライブラリ系、MySQLなどのデータベース系などを刷新して、新しいリリースバージョンを使ってのサーバー構築です。
新しいバージョンでの構築は今までの処理系を見直す良いチャンスだと思います。

さて、そんなこんなでさくさくと設定を進めていたのですが最終段階のWEBシステムをアップロードしてシステムの稼働チェックをした際に見慣れないエラーが発生しました。

Fatal error: Uncaught exception 'SmartyException' with message 'PHP5 requires you to call __construct() instead of Smarty()'
in /usr/include/php/include/Smarty/sysplugins/smarty_internal_templatebase.php:755

PHPのクラス定義などの仕様変更などもあって、今までの呼び出し方ではよろしくない様子。

下記は修正前のクラス定義の例文です。

require('Smarty/Smarty.class.php');
 
class Smarty_PICMO extends Smarty {
	function Smarty_PICMO() {
		$this->Smarty();
		$this->template_dir		= '任意のパス';
		$this->compile_dir		= '任意のパス';
		$this->config_dir		= '任意のパス';
		$this->cache_dir		= '任意のパス';
	}
}

下記のように変更する必要があります。

require('Smarty/Smarty.class.php');
 
class Smarty_PICMO extends Smarty {
	function __construct() {
		parent::__construct();
		$this->template_dir		= '任意のパス';
		$this->compile_dir		= '任意のパス';
		$this->config_dir		= '任意のパス';
		$this->cache_dir		= '任意のパス';
	}
}

組み上がったプログラムがバージョンアップによって動かなくなるとかなり背筋が凍る思いをしますが・・・
幸いこの程度の修正で済んでよかったと喜ぶべきだと思います。
僕の作ったプログラムはテンプレート呼び出し位置をセレクターで切り替えていたので全ソース書き換えになりましたが

サーバー上で、テキスト文字を含んだ画像を生成したいことがありました。
ImageMagickのテキスト文字を画像として出力するときは、convertコマンドを使って実行しますが実はこれがうまく動作しない現象が発生していました。

> convert -font "msmincho.ttc" -pointsize 30 -size 240x320 label:@message.txt sample.jpg

で実行します。
詳細のオプションの内容などはもっと詳しいサイトがあるのでそちらに譲りますが、簡単にご説明。
pointsize : 文字サイズ
size : 精製される画像の縦横のサイズ
label : 書き出したいテキストの内容
そして、最後に出力画像ファイル名

おそらくこれで問題無く出来るだろうと実行したものの、まず pointsize が無視されます。
どんなサイズにしても文字サイズは変わりません
そして、message.txtには、複数行の文字データが書かれているのですが１行しか表示されません

作成対象となるサーバーで使用しているImageMagickのバージョンは、6.0.7 でした。
これが問題でした。
ImageMagick は、6.2.7移行でないと、pointsize命令にバグがあるらしく正しく動作しない様子。

仕方がないので、現在の最新版である 6.7.3 をダウンロードしてインストールをします。

■Image Magick
https://www.imagemagick.org/

しかし、サーバーの環境上ImageMagickが既に多用している為上書きしてしまうのは安直すぎます。
そのとめ、上書きをせずに別の位置にインストールさせることで対応をしてみることにします。
そのためソースコードからコンパイルをします。

上記から取得してきたソースコードを作業用ディレクトリに取得して、展開します。

> wget ftp://ftp.imagemagick.org/pub/ImageMagick/ImageMagick-6.7.3-4.tar.gz 
> tar zxvf ImageMagick-6.7.3-4.tar.gz 
> cd ImageMagick-6.7.3-4

展開したディレクトリに入って、ソースコードのコンパイルをします。
ここでは、configureを使ってソースコードのMakefileを作ります。
そこで明示的に現在のImageMagickては別の位置にインストールされるように prefix オプションを使いって指定しました。
その他のオプションは基本的にデフォルトで問題なさそうなので、他の設定はデフォルトで問題無いと思います。

> configure –prefix=/usr/local/im
> make
> make install

これで、/usr/local/im の位置に 6.7.3-4 の新しいImageMagick がインストールされました。

最初のコマンド

> convert -font "msmincho.ttc" -pointsize 30 -size 240x320 label:@message.txt sample.jpg

上記を下記

> /usr/local/im/bin/convert -font "msmincho.ttc" -pointsize 30 -size 240x320 label:@message.txt sample.jpg

とすることで無事、複数行も文字サイズの変更も出来るようになりました。

WordPress のライセンス

ライセンスはプログラムの権利を示した大切なルールです。
開発者なら有料でプログラムを配布したいとか、再配布を制限したい、改造をしてほしくないなどいろいろ条件をつけたいことも多いのではないでしょうか。
そういったことを条件などをライセンスとして定義しますが、WordPressのプラグインやテーマは少しそういった制限は付けにくいソフトウェアなのです。
WordPress自体にももちろんライセンスが存在しますが、そのライセンスがGPLライセンス(GNU General Public License) となっているためです。

注意

ちなみに再配布を考えずに自分用に使用するプラグインでしたらなんら一切の制限はありません。
ここでの内容は、再配布を目的とした場合となります。

ライセンスの決定について

GPLライセンスは基本的に無料で使うことが可能です。
この無料で使えるというのは開発をする者にとっても、利用する者にとっても敷居が低くてとても良いライセンスです。
しかしWordPressがGPLライセンス故にそれを拡張するプラグインやテーマもGPLライセンスとして適応されるのが妥当であるという考え方です。

WordPress本家サイトより　テーマもＧＰＬライセンス

このように本家のサイトでは独自に開発されたプラグインやテーマ（画像やＣＳＳは除く）もGPLライセンスとして発表されるのが妥当であると定義されます。

もちろん作り方によってはそれ以外のライセンスで発表することも可能かとはおもいます。
そういった情報を知りたい方はグーグル先生に聞いてみると結構出てくると思います。

勘違いしてほしくないのはGPLライセンスであっても、対価を得ることは自体は問題有りません。
しかしGPLライセンスのものを配布するためにはソースコードを公開しなければなりません。
ＰＨＰの場合は、ソースコード＝プログラムファイルとなりますのでソースコードを公開してしまっては有料で不特定多数の方に配布ということは難しくなります。
何かの作業に対するサービスとしての対価という方が一番無難な方法ではないかと思います。

またGPLライセンスは再配布についても自由であり、改造・改変についても制限無く可能である必要があります。

上記のような事から、下記のような制限は難しいと思われます。

不特定多数の人から課金をしてダウンロード販売する
（ソースコードを開示する必要があるため、あまり意味がない）
ソフトウェアの改変をされたくない
（基本的にGPLライセンスでは、改変も自由となります）
既に使用されているユーザーからの孫配布を制限
（GPLライセンスでは、再配布を制限することはできません）

こういったことから、WordPressのライセンスを継承するプラグインは基本的にGPLライセンスとして開発を進める必要があります。
基本的に僕のプラグインもこのようなことからGPLライセンスに準拠しております。