写真登録枚数

3518

新着情報

前回までにML110 G6のファンについては理解できましたので早速静かにするための手段を考えていきたいと思います。

静かにする方法

静かにする方法は、大きく分けて二つあると思います。

  1. ファンの回転数を下げて静かにする方法
  2. 静かなファンに交換する方法

1は、既存のファンを有効に利用できますがファンコントローラーを作るか、購入しなければならなくなります。
速度や静音性のバランスを任意で決めることが出来ますのでこれはこれで魅力的なチョイスです。
欠点をあげると言えば、ML110 G6のコネクタが特殊なためにコネクタの改造が必要になってくることだと思います。
また一般的なファンコントローラーはマザーボードに対して回転数を返す仕組みが無いものがほとんどです。
そのためファンの回転数はマザーボードに返してあげられるようにシンプルな電圧コントローラーを自作して接続する必要があります。

2は簡単で、マザーボードがエラーにならない程度の回転速度あり、静かなファンを選ぶだけです。

1も非常に魅力的だったのですが、手持ちの部品に3端子レギュレータが無かったので2の方法を選ぶことにしました。

エラーにならない回転数とは

それでは、ML110 G6がエラーと検知しない回転数を調べなければなりません。
方法としては電圧コントローラーでファンの速度を可変させマザーボードの閾値を調べていけばわかると思います。

このときファンはML110 G6に付いている標準のファンではなく最大速度が ***** のこのファンを利用します。
標準のファンはPWM制御なので、単純に電圧で制御できるファンで確認したかったためです。

まず、ケースファンから電源の電圧とGNDの信号を抜き取りこの先を電圧コントローラーに繋げて回転させる。
これで自由に回転数は制御できるのでエラーとなる閾値を探る。

ただし、この結果は電圧でのファンの精度は不安定なため、だいたいの目安としてご覧ください。

速度は、BIOSのIMPIのハードウェアモニターで確認する。

リアファン

約2000rpm 問題無く警告灯が点くこともありませんでした
約1500rpm 問題無く警告灯が点くこともありませんでした
約1400rpm ○?  一瞬警告灯が点いたりしました
約1300rpm  警告灯が点いたり消えたりします
約1200rpm ×  警告灯はほぼ点きっぱなしです

以上のようのことから1400rpm以上の物ならほぼエラーにならずに使えると思います。
安全を考えて1500rpm以上の物が良いと思います

CPUファン

約2000rpm 問題無く警告灯が点くこともありませんでした
約1700rpm 問題無く警告灯が点くことも有りませんでした
約1600rpm ○? 一瞬警告灯が点いたりしました
約1500rpm 警告灯が点いたり消えたりします
約1400rpm × 警告灯は点きっぱなしになります

以上のようのことから1600rpm以上の物ならほぼエラーにならずに使えると思います。
安全を考えると1700rpm以上の物が良いと思います

ファンが不安定な要素として、ファンは電源を入れてからすぐに回転数が安定するわけではありません。
モーターですので徐々に速度があがり、安定稼働します。
また、安定稼働したからといってずっと一定の速度で回転できるとは限りません。
そのためお店のファンのパッケージを確認すると2000rpm ±10%などの表記になっていると思います。

上記の結果でも一瞬警告灯が点いたりするのはそういった速度のムラを検知するためだと思います。
おそらく、リアファンの閾値は1300rpmで、CPUファンの閾値は1500rpmあたりなのではないかと思います。
ただそんなわけでファンの速度が一定でないためエラーが検知されたりするものだとおもいます。

僕が選んだファンたち

せっかくなら良い物を買おうと思っていたのですが、CPUファンはPCI-Express x16のスロットに干渉してしまって市販のファンなんか取り付けられそうにありません。
で、とりあえずサイズ的に選んだ物がLGA775のCore 2 Duoのリテールファン。

LGA775 Core 2 Duo リテールファン
ハードオフをあさっていたら、500円で出て来ました。
ヒートシンク中心が銅になっていてセレロンのよりは良さそうです。

LGA775 Core 2 Duo リテールファン 裏

Cure 2 Duoのマシンは別のマシンで組んだことがあって、静かな方だなーと思っていたので買ってみました。

調べたところ回転速度はだいたい2000rpmぐらいからのようでしたのML110 G6にも対応可能だとおもいます。
cpuはコアのダイレクトな熱を放熱させますので、信頼度と小ささ、そして静音性を兼ね備え、ついでに4ピンファンだったのでコレに決めました。

お気づきだと思いますがLGA775では、ソケット違うじゃん!という突っ込み入れられそうですね^^;;
しかも、リテールファンはネジ固定式ではなくプラスチッククリップでの固定ですのでそのままではもちろん取り付けは不可能です。

リテールファンの構造を見てて思ったのですが、このクリップ外したら普通にネジで固定できるんじゃね?w
というもくろみはちゃんとありますので、下記のようにしてクリップを外します。


LGA775 Core 2 Duo リテールファン クリップ外し LGA775 Core 2 Duo リテールファン クリップ外し
これで、LGA1156ソケットのファンのねじ穴とも合います。

次に固定させるネジです。

CPU クーラー固定用ネジ

左が、その辺で売って居るであろうパソコン用のミリネジ。
右が今回使う、僕のネジコレクションにあったミリネジ。

ご覧のように長いです。
ネジの部分が1cm以上有れば固定は出来ると思います。
このちょっと長めのミリネジはどこのご家庭にもあるという代物ではないかもしれませんね・・・
僕は別のパソコンのジャンクが出たときはネジとかも取っておくので結構こうゆうのが残っていたりします。
ネジ規格的には、パソコン用のミリネジで合いますので探せば売っているのかも。

続いて。コネクタの加工。

ファンコネクタ ファンコネクタ

写真中、ML110 G6のファンコネクタ、右が今回購入したLGA775 リテールファンコネクタ。
見てのように形状が違います。
ただ、穴のピッチは一緒ですので、ケーブル自体を入れ替えてやるだけでそのまま使えます。

入れ替えこの様に精密ドライバーを使ってこの辺にあるピンのツメを外して・・・

ファンのピンの入れ替え

ケーブルを引き抜きます。

ファンのピンの入れ替え

無事抜けました。
これを左右を入れ替えます。

ファンのピンの入れ替え
上記の写真左がML110 G6のファンコネクタです。
もしかしたら色が個体によって違いがあるかもしれません。

参考程度に見てもらって僕の上記の写真のケーブル色でのそれぞれのアサインは左から

青:PWMパルス入力
黄:回転数
赤:電圧
黒:GND

この順番で刺さるようにリテールファンのコネクタを入れ替えました。

あとは、マザーボードにねじを締めて固定します。

はい、問題無く固定できました。
PCI-Express x16のスロットとの干渉もまったくなしです。
さすがIntelリテールファン。

この状態で電源を入れて動作を確認しましたら、無事ファンは回りました。
むしろ音がかなり静かになって感動!

そして用意したケースファンはこちら。

OMEGA TYPHOON OMEGA TYPHOON
ainex製のOMEGA TYPHOONです。
ゴルフボールのような羽形状がすごいファンですw
でも、9センチファンとしてはかなりの静音性が確保されていると思います。
お値段もお手頃です。
近所のケーズ電気で規定回転数以上で、一番静かな物を選んだらコレになりました。
これは3ピンコネクタですがエラーにだけならなければ問題無いので。

購入はこちらからどうぞ。

こちらもコネクタのピンを入れ替えをして・・・

OMEGA TYPHOON コネクタ

固定用のゴムに取り付けをして・・・

出来ました^^
僕のケースは側面に20cmの排気ファンが付いてるので、廃熱は十分に行われます。
そのためそもそもがリアファンは付けられる構造になっていません。
仕方がないのではじめからついていた取り付け用ゴムをつかって、リアの排気用の穴に固定してますw

僕の方は、以上の構成でうまく稼働させることに成功しました。
エラーも出ていません。

CentOS上から、回転数と温度が確認出来ますので・・・
グラフ的にはこんなかんじです。

munin グラフどのタイミングで交換したのかわかりやすいグラフです。

CPUファンをダウンフローにしたことで周辺の熱も廃熱しているようですね。
ちなみに、この日の室内温度はほぼ30度を超えていたと思います。
申し分ない冷却ですね。

音は、ML110 G6のファンから比べたら天と地の差です^^;;
無音とまでは行かないまでも、気にしなければわからない程度にまでになりました。
とくにあるゴルフボール羽形状のリアファンは単品での動作試験の時、ほとんど音がしないとかなり気に入っています。
値段も手頃なので、リアのファンの交換にはおすすめです。



ML110 G6の標準ファンについて

HP製サーバー ML110 G6ですが、本格運用から数日が経過しました。
季節は夏真っ盛り、室内温度もかなり高い状態が続き、誰もいない室内は30度を超える日もしばしばです。

そんなためかどうかは不明ですが、ML110 G6は、ファンが爆音で動作しております。

CPUファンが 5000rpm
ケースファンが 4500rpm

回転数が動作音のとは直結とないとはおもいますが、とりあえずこのファンすごく五月蠅いです。
寝室と同じ部屋においてあるサーバーなので非常に気になります。

それも寝てしまえばどうということはないのですが、集中して作業しているさなかにグォーっと常時響かれるともぅ orz
暑い気温がさらに暑苦しく感じるので不思議です。

そもそも、サーバーマシンに静音性を考える必要は無いんだとは思います。
安定して動作させることがサーバーとして優れているサーバーだと思いますので、風を効率よく送り、効率よく熱を放熱させることが故障率を低下させる最善の方法です。
しかも、ML110 G6の価格では、静音性の高くさらに冷却性能の高いファンを採用するのはなかなか難しいのかもしれませんね。

そんなこんなで、ML110 G6が本気を出すと、やばいぐらい五月蠅いです。^^;;
静かであればそのままにして稼働させようと思いますが、ちょっと交換することを考えてみようと思います。

IPMI機能

まず単純に静かにする方法として、ファンを引っこ抜く方法が考えられると思いますが・・・
さすがサーバーマシンです、そんな緊急事態はしっかり反応し、BIOSレベルで動作が決められています。
ML110 G6ではIPMIという機能で、マシンの状態を常時監視しています。

IPMIは、サーバーの各部の温度、ファンの回転数、各部の電圧などを詳細に測定をしています。
もしその値に異常があれば、決められた動作をするといった対応がOSレベルでも可能になっています。
ファンの動作に関してはBIOSレベルで管理されています。

そのため、ケースファンをコネクタから引っこ抜こうものならマザーボードの警告灯が点灯し、数十秒でシステムがシャットダウンします。
なら引っこ抜くのが駄目なら、遅いファンに交換すれば・・・
実はそう簡単な問題でもありません。
監視しているのは、ファンの死活監視ではなくファン回転数なのです。
つまりファンの回転数が一定回転以上の回転数が検知できなければエラーとなる仕組み。
さすがサーバーマシンよくできています。

BIOSの設定では、これらの異常検出時の動作設定も変更できますが、これを切ってしまったのでは実際の異常が発生したときにも対応出来なくなりますのでこれは切らずに生かして動作させたいと思います。

ファンの種類

さて、それでは交換可能なファンですがコネクタの問題もあります。
これはこちらの記事で明らかになっている内容です。
コネクタが通常のコネクタ形状ではなく、さらに4ピンです。

パソコン用のファンには、2ピン、3ピン、4ピンのファンが存在します。
それぞれコネクタは互換性があり一般的なパソコン用のファンであれば信号数の違いがあっても差し込むことが可能です。

それぞれコネクタの違いにおける信号の内容は下記のようになっています。

  • 2ピンケーブルファン
    2ピンケーブルファンは、電圧GNDの信号のケーブルです。
    規定電圧を与えるだけで一定回転数回転するモーターを回転させるためのもっともシンプルなファンだとおもいます。
  • 3ピンケーブルファン
    3ピンケーブルは、電圧GND回転数の信号ケーブルです。
    モーターの駆動には2ピンケーブルファンと代わりありませんが、そのファンは現在どのくらいの速度で回転しているのかを通知する信号線が追加されています。
    この回転数はrpmで返され1分間あたりの回転数がこの値の数字となります。
    現在販売されているファンはこの3ピンケーブルファンが主流ではではでしょうか。
  • 4ピンケーブルファン
    4ソ゜ンケーブルファンはIntelがLGA775を市場投入したときにリテールファンとして標準になったファンです。
    4ピンケーブルは、電圧、GND、回転数、PWMの信号のケーブルです。
    3ピンのものにファン速度を制御するPWMコントロールケーブルが追加となりました。

以上のことから、4ピンケーブルファン以外ファンのスピードはコントロール出来ないかのように思えます。
実は、単純にファンの速度をコントロールさせる方法も存在します。

一般的に市販されている ファン速度コントローラーは、大きく2つに分類されます。
電圧コントロール方式PWM制御方式です。

電圧コントロール方式は、2ピン、3ピンケーブルファン向けのコントローラーでモーターに供給する電圧の上げ下げを行ってファンの速度を制御しています。
正しい制御方法ではありませんが4ピンのファンもこれで制御自体は可能です。
ただ本来はPWM信号でコントロールするのがきめ細やかく正確に制御することが可能です。

PWM制御方式は、4ピンケーブル用ファンコントローラーで基本的に4ピン専用です。
2ピン、3ピンのファンを刺しても基本的には回転速度は制御できず、この場合基本的に最高速度で回転します。
ただし4ピンファンを制御させる場合は、電圧コントロールより意図した回転数が得られるようになっていると思います。

ML110 G6のファンはコネクタ形状の異なっては居ますがファン自体は上記でいう4ピンファンと同じです

次は、実際にML110 G6を静かにする方法を考えて見ようと思います。


WordPress が 3.2.1が出たので早速バージョンアップを実行してみました。
一番修正を期待していたのが、画面投稿時のフッダーが内側に入ってきてしまっている問題。

そもそも、3.2にバージョンアップした際もそれほど大きな問題もなかったので3.2.1にしてもバグフィックス程度だろうと思っていました。
案の定バージョンアップは、特に問題もなく完了し、今のところどこの場所においても不具合などは無い状態です。

さて、一番気にしていた投稿ページにおけるフッダーがページ内に入ってきてしまう件は・・・
修正されていませんでした^^;;

WordPress 3.2 フッダーの不具合

上記のようにフッター部分「WordPress のご利用ありがとうございます。~・・・」のフッダが持ち上がってしまっているのがわかると思います。
実際それほど支障がないので気にしなければ良いのだと思いますが・・・
まぁ、バージョンがあがってもこんなわかりやすいところが修正されないっていうのはおそらくうちだけの問題な気がしないでもないので、問題のポイントを追求してみることにしました。
おそらく使っているプラグインか、テーマがオリジナルっていうところにも問題が有るのかもしれませんね。

HTMLを見ると、この部分は

<div id="footer">
 <p id="footer-left">
  <span id="footer-thankyou"><a href="https://ja.wordpress.org/">WordPress</a> のご利用ありがとうございます。</span><a href="https://wpdocs.sourceforge.jp/">ドキュメンテーション</a><a href="https://www.picmo.net/wp-admin/freedoms.php">自由について</a>
  • <a href="https://ja.forums.wordpress.org/forum/2">バグ報告と提案</a><a href="https://www.picmo.net/wp-admin/credits.php">クレジット</a>
 </p>
 <p id="footer-upgrade">バージョン 3.2.1</p>
 <div class="clear"></div>
</div>

となっています。

divでidが#footerの状態をみるとpotisionがabsoluteでかかっています。
おそらくは固定されずに浮いてしまっている状態なのだと思います。

その後absoluteを、relativeにするために上書きを狙った再指定が出されていますが優先度が下なので上書きされていないようです。

単純にpotisionがrelativeになればおそらく浮いている状態が解除されるので上手くいくのではないかと・・・
これを上書きするだけなら、テーマのfunction.phpに管理画面用のスタイルシートを出力するフィルターを追加してあげるだけで実現できそうです。

僕は下記のようにfunction.phpに追加しました。

// 管理画面のフッダースタイルシートの上書き
function admin_footer_position() {
?>
<style type="text/css">
<!--
#footer { position: relative !important; }
-->
</style>
<?php
}
add_action( 'admin_print_styles', 'admin_footer_position' );

function.phpはPHPプログラムなので、開始の <?php と終了の ?> は和えて省略してあります。
プログラムが正常に動作するように適時追加をしてください。

ポイントはposition:relativeに!importantを追加したところです。
これにより、指定されているabsoluteより、relativeの方が優先度が増しこちらの指定が優先されます。
function.phpを保存して、再読み込みを行います。

WordPress 3.2 フッダーの不具合修正完了正しい位置にフッダーを表示させることが出来ました。
あとは、Fast Image Insert が修正されれば完璧なんだけど・・・
別のプラグインを探してみようかな。

 




前回までに、ML110 G6のケース交換までのポイントは洗いだせていますので、ケースの移植を実行させたいと思います。
移植先となるケースは、このケースです。

移植先のサーバーケース

ちょっとメーカーとかは忘れました。
ただ、マイクロATXサイズなケースではありますが、通常のATXマザーが入ります。
しかも、拡張性に優れ下記のようなスペックです。

  • 5インチベイ ×4段
  • 3.5インチフロントベイ ×2
  • 3.5インチシャドウベイ ×4
  • 拡張スロット ×6スロット
  • 通常のATX電源が搭載可能
  • フロントファン、ケース上部ファン、ケースサイドファンなどを装備

大きさも小さいながらなかなかの拡張性です。
個人的にはこのケースを好んで試用しています。

それでは移植を始めようと思います。

  1. フロントベゼルを外す
  2. マザーボードに繋がるケーブル類をすべて外す
  3. ドライブ類を外す
  4. 必要なケーブル類をケースから取り外す
    必要な物は、LEDや電源スイッチなどのコネクタスイッチ一式、温度センサ
  5. CPUファンを外す
  6. ケースファンを外す
  7. マザーボードを固定しているネジをすべて外す
  8. マザーボードを外す

この順番でケースから必要な部品を外します。
新しいケースへは、外した順番から逆に作業するのが楽に作業を進めることが出来ます。

交換のポイントとなるのは、LEDスイッチコネクタの加工です。
このコネクタを外すと、LED2つとスイッチコネクタが外す必要があります。

ML110 G6フロントベゼルの取り外し

LEDと電源スイッチはツメで引っかかっているだけです。

電源スイッチはだいたいそのケース独自の形状をしたスイッチがケースに組み込まれていると思います。
そのためケースに内蔵されているスイッチを流用するために、コネクタ部分から電源スイッチケーブルを切断します。
電源スイッチはML110 G6のケースに戻します。
もし、他のマザーボードで使用するのでしたら、スイッチ側のケーブルも下記のようにメスのピンコネクタを付けておくと楽に移植が出来ると思います。

それでは、新しいコネクタを半田付けをします。
これでどんな汎用ケースでもML110 G6のマザーボードを稼働させることが可能になります。

ML110 G6 スイッチケーブル加工 ML110 G6 スイッチケーブル加工
コネクタは秋月などで売っているジャンパピンと同じサイズのピンコネクタを使っています。
これを半田付けをすれば完成です。

移植先のケースは、電源ランプやアクセスランプは汎用のLEDを取り付けられるようになっています。
そのため今回は、電源スイッチだけのコネクタ付けですが、もしLEDランプもケース独自のものでしたらコネクタを付けておくと便利だと思います。

ちょっと難易度があるところはこの作業だけです。
あとはマザーボードの固定用のネジを通常のプラスネジに変えておいた方が今後のメンテナンス性がよくなるのでおすすめします。

あとは普通にパソコンをくみ上げる要領でくみ上げていけばあっさり組み込み完了しました。

HDDなども搭載して、早速CentOSを組み込みますが・・・ここで問題発生。
HDDの認識順番が想定と違います。^^;;

コネクタはSATA1~SATA6の順番でマザーボードのシルクには書かれているのでその順番で刺していったのですが・・・
どうやらCentOS側からの認識は下記のようになっているようです。

  1. SATA1 → sda
  2. SATA3 → sdb
  3. SATA2 → sdc
  4. SATA4 → sdd
  5. SATA5 → sde
  6. SATA6 → sdf

まぁ、すぐに気がつくことではありますがちょっと驚きました。
ちなみに、BIOSでは、マザーボードのシルクの順番に認識しています。
それを考えるとCentOS側の問題なのかもしれません。

無事組み込みと設定を終えて、サーバーの本格運用に入ります。

 


現在僕が使用している WordPress は 3.2です。
この記事がすべてのバージョンにおいて同じ結果ではないことをご承知おきください。
おそらく近いバージョンでは、参考になるのではないかと思います。

■実用可能と思える物

  • Shortcode Exec PHP 1.31
    TinyMCEを試用して記事を編集しているが、HTMLモードで追記した記事をビジュアルモードで再編集すると<?php ~ ?>までの記述がごっそり無くなってしまう問題もある。
    セキュリティ周りの設定が特に何も無く、ユーザーレベルでの実行許可などの管理機能はない。
  • Grimp – PHP 0.1
    Shortcode Exec同様TinyMCEを試用して記事を編集しているが、HTMLモードで追記した記事をビジュアルモードで再編集すると<?php ~ ?>とまでの記述がごっそり無くなってしまう問題もある。
    セキュリティ周りの設定が特に何も無く、ユーザーレベルでの実行許可などの管理機能はない。

  • Inline PHP 1.2.2
    コードの開始タグはで実行される。
    php認識タグが<?php ~ ?>ではないのでエディタでコードが消失されることはないが、複数行にまたがるコードは1行に詰めて記述し直す必要がある。 

 

■一部に問題はある物の動作自体はするもの

  • Exec-PHP 4.9
    実行には問題なし。
    IE8使用時、WP管理画面からTinyMCEの設定画面を表示させると正常に表示しない問題が発生。
    Firefoxでは、正常に動作できた。

 

■使用できない

  • runPHP 2.2.2
    インストールは出来るが、その後有効化できない。
    プラグイン一覧にも表示されないため、実際の削除にはFTPなどで実ファイルの削除が必要となる。
    動作もしていない。
  • PHP Execution 1.0.0
    実行問題は無いので非常に惜しいが、管理画面でJava Scriptエラーが発生して管理画面の投稿処理が出来なくなっている。
    このときの確認ブラウザは、IE8とFirefoxを使用して確認。

  • WP exec PHP 1.0
    簡単なソースコードを実行させてみたものの正しい結果が得られませんでした。

  • Allow PHP in posts and pages
    <?php ~ ?>を[php] ~ [/php] と記述さて使用します。
    php認識タグが<?php ~ ?>ではないのでエディタでコードが消失されることはないが、複数行にまたがるコードは1行に詰めて記述し直す必要がある。
    ただ、複数行のコードは正常に動作出来なかった。

 

僕は結局Inline PHPをを使用しています。
複数行コードを1行にまとめる作業は面倒ではありますが、操作中にコードが消える可能性があるものよりは安心して使用できます。

僕の理想としては、PHPのプログラムを記事中にガシガシ書いて動かせればと思っていました。
しかしそれを望むのは酷なようです。

そもそも、WordPressでは不正なコードを実行できないようにして処理してあるので、記事中に書かれたPHPコードがごっそり消されたとしてもそれはそれで正常な動作。
これを回避させるためにWordPress本体のソースコードを手を入れることも考え、修正ポイントも確認しました。
しかしこの作業を実行してしまうとWordPressをバージョンアップするたびに本体コードの修正をするのでは非常に面倒となるためこの方法は禁断の方法として考えて居ます。

もし複雑なコードを書くときは、別なファイルを作りそのファイルにコードを書き、InlinePHPなどを使ってそのPHPファイルを呼び出すようにするというのが一番管理的にしやすい方法ではないかと思います。
WordPressのテーマの管理では、関係のないファイルでも登録でき、管理することが出来ます。
この機能を使って実現させるのが一番スマートですね。


WordPress を 3.2 にバージョンアップして、数日が経ちました。


おおむね使用していて使えないと思う点などはほとんど無いと思います。

しかし現状でも気になるところも数点有りましたので書いてみます。

  • 投稿ページにおける、フッダーがページ内部に入ってきてしまう。
    僕の同時に使用しているプラグインによるところという可能性も考えられます。
  • IEで、投稿時に自動保存が入ると書いている行が消失してしまったりする。
    これは、IE8はサポート対象外としているため仕様なのかもしれません。
  • 投稿時HTML編集モードから、ビジュアルモードに切り替えると改行がすべて段落に指定されてしまう。
    これは、Firefoxで編集時は発生しないことを確認しました。IEでのみの不具合のようです。
  • プラグイン Faster Image Insertが正常に動作しない
    一見動作していますが、画像を投稿記事中に投稿すると画面が無くなってしまって操作不能になってしまう。

致命的な問題は今のところ一つもないと思います。
1番のフッダーの問題は多少面倒ですが、慣れてしまうば編集には支障が出ないのです。
あとはIE8は推奨ブラウザ外なので、FirefoxやChromeなどのブラウザを使用すればほとんどの問題も回避できるかと思います。

英語バージョンでは、3.2.1がすでにリリースされているので、またフッダの問題だけ解決しないかなぁと様子見中です。
次のリリースでも変化が無ければ問題を追求してみようかなと考えて居ます。



NTT-Xで発注して、早速商品が到着したML110 G6を蓋開けをしてみます。


ML110 G6 箱 ML110 G6 箱
マイクロATXサイズと言っても、箱はそこそこ大きいです。
いつも自作パーツでグレードアップを繰り返していたので、パソコン一式買ったのいつ以来だったかな。
このML110 G6ですが、サーバー一式になのでキーボードやマウスも付いてきます。


ML110 G6 ML110 G6
なかなかに堅牢そうなサーバーです。
デザインはM5よりはすっきりしていてとても好みです。

もちろん、このケースこのまま使いたいところなのですが・・・
諸々の事情により、ケースを変更する必要があります。

ML110 G6 内部

ケースを開けてみたところです。
非常にすっきりとした内部です。
ただ、ちょっとだけ気になるところとしては・・・

ML110 G6 マザーボード

CPUヒートシンクとPCI-Express x16との間が結構ぎりぎりですね。
これを考えると、もしヒートシンクを変更する際は、ちょっと気にして変更する必要がありそうです。
ビデオカードはLinuxサーバー用途なので標準の内蔵ミレニアムで問題無いと思ってますけど、拡張できる物は拡張できる状態でおきたいですね。

拡張スロットは上から、
PCI-Express x16
PCI-Express x4
PCI 32bit 3.3V
PCI-Express x1
となっています。
コネクタは、x4 → x8、x1→x4となっているようです。

この時点で確認しておいたのですが、マザーボードのネジの位置を確認して標準的なマイクロATXで有ることを確認しました。
ただちょっとネジがトルクスネジなので、開けてしまえばあとは交換する際に普通のプラスネジに交換してしまいましょう。

メモリはhynix製のPC3-10600 2GB ECCが取り付けられていました。
ML110 G6 メモリ

ちょっと面倒な点は、ケースへの電源スイッチコネクタと、電源LED、アクセスLEDなどが専用のコネクタにされている点でしょうか。

ML110 G6マザーボードのコネクタ
また電源LED自体も特殊で、オレンジ色と緑色が任意で点灯できるタイプのようです。
LEDで2色の表現は、3ピンタイプがオーソドックスですがこちらは変わっていますね。
おそらくLEDの特性(一方向に流れたときに点灯)を利用して、+とGNDを逆転させてそれぞれを点灯させている物だと思います。

さすがにこのタイプのLEDは売っていないので
・電源ON時点灯
・電源OFF時消灯
一般的な動作にさせようと思います。

どうやら、ファンコネクタも特殊コネクタのようですね。
6ピン用のコネクタになっています。

ファンに手をつけるかどうかは稼働もさせていないのにうるさいかを評価できないので、まずはケースを変えたのち稼働させてみてうるさければ変えてみようと思います。

 



昨日、WordPressを現在の最新版である、3.2へのバージョンアップして当方の環境で不具合が発生した件をご報告しました。
その不具合を修正するために原因を調べていた。

その結果どうやらファイルのパーミッションによる読み込みエラーによるものということがわかりました。
これは当サーバー環境によって発生した事象であることが強いことが考えられます。

読み出せなかったファイルのパーミッションは「 600 」つまり、ファイルオーナー読み書き以外のアクセスは不可能となります。
当サーバーでは、セキュリティと管理のためにsuphpが稼働しています。
バーチャルホスト内のphp実行は指定されたユーザーで実行されます。

そのためphpで出力されたファイルオーナーはWordPressの実行ユーザーということになります。
ApacheはWordPressの実行ユーザーとは異なったユーザーで稼働しています。
suphpが実行されているホスト内でも、画像ファイルなどのphp以外のファイルはApacheユーザーが取得することになります。
そのときApacheは、WordPress実行ユーザーにしたアクセス権限の無いファイルを読み込もうとしてエラーが発生してしまっていました。

改善は簡単で、FTPでもSSHでも読み込めないファイルのパーミッションなどを「644」に変更してあげるだけです。

SSHが使える方は、
WordPress のドキュメントルートにカレントディレクトリを移して

find . -type f -perm 600

これで、パーミッションが 600 のファイルが出て来ます。
その中から必要なファイルのパーミッションを変えてください。
僕の場合、おおむねTinyMCEの画像ファイルなどがヒットしました。

WordPressのファイルなどはほとんど問題がなかったので、TinyMCEのパッケージと僕の環境によって発生した事象ではないかと思います。

 

無事、TinyMCEのボタンも表示されました。

 



パッケージインストールしたApacheのSuexecの設定を変えたいときってありますよね。
でも、出来ればソースコードからの再コンパイルは避けたい・・・
そんなときありませんか。

CentOSなどApache(httpd)は、デフォルトでインストール済みですね。
なので出来ればそのデフォルトの状態を維持したままSuexecをどうにかしたいと思う事もあるのではないでしょうか。

# /usr/sbin/suexec -V
 -D AP_DOC_ROOT="/var/www"
 -D AP_GID_MIN=100
 -D AP_HTTPD_USER="apache"
 -D AP_LOG_EXEC="/var/log/httpd/suexec.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=500
 -D AP_USERDIR_SUFFIX="public_html"

上記の内容を変えたいときですね。

そんなこんなで比較的にリスクを少なく実現する方法です。
といっても、基本的にはソースコードはコンパルし直します。
結局それをしないで実現する方法は、パイナリをいじる以外の方法は無いと思います。
バイナリをいじるのは正常に動いているようで動いていなかったなどの不具合の発生を高めます。
そのため出来るだけその方法を使わずに、suexecの内容の書き換えを行いたいと思います。

当方の環境はCentOS 5です。
まず、インストールされているApacheのバージョンを調べます。

# /usr/sbin/apachectl -v
Server version: Apache/2.0.55
Server built:   May  8 2006 00:31:16

これでバージョンが調べられます。

Apacheのアーカイブから同じバージョンのソースを拾ってきます。
ダウンロードはこちらから
https://www.apache.org/dyn/closer.cgi/httpd/

HTTPミラーサイトを選択すると、最新版へのリンクがありますがその下のページにある
Older Releasesのアーカイブへのリンクをたどります。
すると、アーカイブリストが見られますので自分のバージョンに合ったソースをダウンロードしましょう。

僕の場合は2.0.55でした。
サーバーの適当な場所にダウンロードしたら展開をします。

# tar zxvf httpd-2.0.55.tar.gz

展開するとhttpd-2.0.55というディレクトリが出来居ていますのでその中に入ります。
そこで希望する設定内容で、configureを実行します。

# cd httpd-2.0.55
# ./configure
--prefix=/usr/local/apache
--enable-suexec
--with-suexec-caller=apache
--with-suexec-docroot=/home
--with-suexec-logfile=/var/log/httpd/suexec.log
--with-suexec-userdir=public_html
--with-suexec-uidmin=1000
--with-suexec-gidmin=1000
--with-suexec-userdir=public_html

僕は上記のようなコンフィグを実行しました。

prefixは無くても問題ありませんが、誤ってインストールしたときなどに対応しやすいので既存のディレクトリにかぶらなければ何でもかまいません。
基本的にインストールは実行しませんので、安全のための設定です。
あとはsuexec以外は使わないのでapacheの設定なんかはデフォルトで。

# make 
# cd support
# ./suexec -V -D AP_DOC_ROOT="/home"
 -D AP_GID_MIN=1000
 -D AP_HTTPD_USER="apache"  
 -D AP_LOG_EXEC="/var/log/httpd/suexec.log"  
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"  
 -D AP_UID_MIN=1000  
 -D AP_USERDIR_SUFFIX="www"

はい、ご希望のsuexecが出来上がりました。

ポイントは上記のところで、makeの後、make installを実行しないことです。
これを実行しますとインストールが実行されてしまいます。
もし、これが現在動いているApacheを上書きすると目も当てられないためprefixを指定しておきました。

出来上がったsuexecだけを自分の稼働中のsuexecと置き換えるだけです。

置き換える前に元々のsuexecはバックアップ取る対策はしておいてください。

# cp /usr/sbin/suexec /usr/sbin/suexec_bak
# cp suexec /usr/sbin/
cp: `/usr/sbin/suexec' を上書きしてもよろしいですか(yes/no)? y

はい、これでご希望のsuexecが出来上がりました。
これで実質apacheのコンパイルは実行しますがapache自体の上書きは実行されずsuexecだけの書き換えが出来ました。

実際セキュリティーホールとかもあるとおもいますので、旧バージョンのまま設定のみを変えるということが本当に必要かどうかを見極めてください。
ただ、既存の稼働している物を置き換えるというのは色々勇気がいると思いますのでこの方法ですと設定変えられると思うので比較的安全に書き換えることが出来ます。

 



WordPressがメジャーバージョンアップとなる 3.2 ですが、日本語のパッケージがリリースされていましたので早速バージョンアップをしてみました。

やってみた感想としましては・・・
まだ実用にはちょっとばかり早い印象を受けました。
アップデートですが、バージョンアップ自体はすんなりと完了可能でした。

必要なデータのバックアップを取りバージョンアップを施行します。
確実にバックアップを取った方がよいと思います。
僕はサーバーがわで一気にバックアップを取っておきました。

そのところ、まず気になったのは使用しているブラウザの件ですが

IE8なんですが・・・
もはやWordPressとしては「古すぎる」ようです^^;;
まぁ、IE9にバージョンアップしなきゃと思っていていてはいたのですが、こんなにも早く「古すぎる」となるとはちょっと驚きです。
Windows XPの方で、IEをお使いの方とかはちょっと痛いですね。
ちなみに、このメッセージはメッセージ中にある「却下」テキストを押すことで消せますので、対応出来ない方はそれで。
もちろん、IEも素晴らしいですが、Google Chrome やFirefoxなど、他にもブラウザはありますのでその辺は柔軟に。

またぱっと使った感じですが・・・
管理画面のページの遷移などが早くなっている感じを受けました。
これはもしかしたら気のせいかもしれません。

使用感としては、3.1とそれほど変わった印象は受けません。
3.2 のダッシュボードはこちら。

WordPress 3.2 ダッシュボード

変わったところは、ページ上部のサイトネットワーク管理とサイト管理を移動させるインターフェースが変わっています。
あと、左袖のメニューを折りたたみ仕様になっているようで、メニューを小さくさせることが出来るようになっています。

サイトネットワーク管理に移動させるためテキストが無くなったことで一瞬焦りましたが・・・

ちゃんとこちらに準備されています。
プルダウンになってしまったのはちょっと面倒ではありますが、慣れてしまえばこんなものなのかな。
続いて、投稿画面に移動します。

 

ぱっと見で気がつくのは・・・
TinyMCEのインターフェースのボタンが表示が出来なくなっています。

7月12日追記 どうやらこれはバージョンアップのためでなく僕の環境に寄るところかもしれません。
解決編も書きましたのでこちらをご覧ください。

これはちょっと使いにくい^^;;
ちなみに、WordPressのバージョンアップと同時にTinyMCEも最新版が出ていたようなのでバージョンアップしておきました。
Firefoxでも、表示させてみたりChromeでも同じ結果なのでブラウザ依存の問題というわけでもないようです。

続いて・・・
WordPressのフッダーがページウィンドウ表示位置の絶対位置に表示されます。

記事画面

そのためウィンドウサイズを小さくすると上記のようにフッダがめり込みます。
なんとなくこうゆう現象になるのはスタイルシートあたりが悪影響をしているのではないか・・・とは思っています。

今のところバージョンアップをさせてみて気がついたカ所は以上のようなところでした。
また、使ってて気になるカ所があればまた続報をしたいと思います。

3.2へのバージョンアップにはもうちょっと熟成させてからバージョンアップしたほうがよいかもしれませんね。

 


当サイトでは、WordPressをCMSとして利用しております。
テーマやちょっとしたプログラムなどは自作するなどして運営しております。

 

正直Movable Typeから乗り変えをしてよかった点の方が僕個人的な意見としては多かった気がしています。
そんな良いところをまとめてみます。

WordPressに移行してよかったところ

  • 記事の更新で構築が不要
    これのおかげで記事の更新更新が非常に楽ですね。
  • テンプレート(テーマ)などを変更したときに再構築が不要
    はじめは気になりませんが、記事数が多くなってくるにつれてだんだん苦痛になります。
    しかも、多すぎると再構築自体が失敗して停止してしまうことも。
  • 記事の更新が軽快になった
    記事の更新にはTinyMCEを使っていますがMovable TypeのI/Fより柔軟性があり動作が軽く軽快です
    しかも、画像の挿入が非常に楽です。
    とくにWordPressのメディアライブラリのFLASH一括アップロードは秀逸です。
  • プラグインの豊富さ
    Movable Typeにもプラグインはありましたが、ここまでの豊富さはありませんでした。
    とくに海外のユーザーも多いことで大概の機能はプラグインがすでに存在することが多いです。
  • 動作がPHP
    個人的にPerlよりPHPの方が扱いやすいのでかなり重宝している点です。
  • ライセンスの柔軟性
    Movable Typeにも、MTOSというオープンソースのバージョンもありますが本家は有償などライセンス系の縛りが楽なのもWordPressの魅力

逆にWordPressにして悪いところ

  • HTMLが出力されているわけではないので、実際の記事ファイルが存在しているわけではない
    これは動かしてみるまで見えにくかったのですが、WordPressのパーマリンクを正しく設定すればそれほどデメリットではない気がしています。
  • すべてのページでPHPでHTML出力をさせているため動作が遅い
    これはマシンスペックですべてカバー出来てしまっています。
    新しいサーバーにしたことで全く遅さを意識しないでも今のところ運営できています。

今僕の中で思っているところはこのようなこのような内容ですが、今のところデメリットも問題無くカバー出来ているとおもいます。

正直変えてみた感想としては、もっと早くに変えておけばよかったと思いました。
Mobavle Typeも悪くはないのですが、記事編集が億劫だったことを感じています。
ただ、WordPressの場合すべての行程が軽快で非常に気楽に記事を書くことが出来ています。

もちろんこれらの条件は、僕のパソコンスペックやサーバーの環境に依存するところが大きいと思います。
ただ、それがそろったときはかなり効率が上がるのではないかとおもいます。

 


サーバーのクリーンインストールして、当サーバーは構築してきましたがどうやらPHPにGDモジュールが組み込まれていないことが発覚しました。^^;;

必要なモジュールを次々とインストールさせていきましたがGDは直接動作に必要なく気がつくまでに時間がかかってのではないかと。
とりあえず、入れないことにはWordPressで画像の縮尺やCAPTCHが使えない。

インストールまでの記録を記述していきます。

サーバーの状態

  • CentOS 5.6
  • PHP 5.2.16
  • 64bit Operating System

現状

# yum install php-gd
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* base: rsync.atworks.co.jp
* extras: rsync.atworks.co.jp
* rpmforge: fr2.rpmfind.net
* updates: rsync.atworks.co.jp
72 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package php-gd.x86_64 0:5.1.6-27.el5_5.3 set to be updated
--> Processing Dependency: php-common = 5.1.6-27.el5_5.3 for package: php-gd
--> Finished Dependency Resolution
php-gd-5.1.6-27.el5_5.3.x86_64 from base has depsolving problems
  --> Missing Dependency: php-common = 5.1.6-27.el5_5.3 is needed by package php-gd-5.1.6-27.el5_5.3.x86_64 (base)
Error: Missing Dependency: php-common = 5.1.6-27.el5_5.3 is needed by package php-gd-5.1.6-27.el5_5.3.x86_64 (base)
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

これと同様の現象と戦ったブログはこちらです。
ワン!ワワン!ニャ~!

こちらの方は、一度 php-common を yum remove させる方法をとっておられます。

作事を実行しようとすると依存関係のための下記のような削除プログラムがでます。

====================================================================================================================
 Package                     Arch                  Version                           Repository                Size
====================================================================================================================
Removing:
 php-common                  x86_64                5.2.16-jason.1                    installed                1.6 M
Removing for dependencies:
 mod_suphp                   x86_64                0.7.1-1.el5.rf                    installed                2.1 M
 php                         x86_64                5.2.16-jason.1                    installed                 11 M
 php-cli                     x86_64                5.2.16-jason.1                    installed                6.6 M
 php-devel                   x86_64                5.2.16-jason.1                    installed                2.7 M
 php-ldap                    x86_64                5.2.16-jason.1                    installed                136 k
 php-mbstring                x86_64                5.2.16-jason.1                    installed                3.0 M
 php-mcrypt                  x86_64                5.2.16-jason.1                    installed                110 k
 php-mysql                   x86_64                5.2.16-jason.1                    installed                733 k
 php-pdo                     x86_64                5.2.16-jason.1                    installed                408 k
 php-pear                    noarch                1:1.9.1-1.jason.1                 installed                2.1 M
 
Transaction Summary
====================================================================================================================
Remove       11 Package(s)
Reinstall     0 Package(s)
Downgrade     0 Package(s)

最悪この方法でも良いのですが、これは最終手段として別の方法を模索したいと思います。

試行錯誤

僕の取った解決方は、GD自体はすでにyumで入っていますので残りはphp-GDモジュールのみ。
これだけ何とかすればいいので、rpmパッケージで直接GDモジュールを組み込めないかとかをトライしてみました。

rpm パッケージを探してきて、rpm -ivh で実行するも案の定依存性エラー
そりゃ、yumとやっていることは一緒ですからエラーが帰ってくるのはあたりまえですね。

ちょっと期待していたのが、–force と –nodeps オプション
 –force 強制的にインストールを実行する
 –nodeps 依存性を無視してインストール

まず、forceの結果はインストール自体が上手くいきませんでした^^;;

nodepsはインストール自体は無事に完了できます。
php.iniにextention=gd.soでモジュールを指定して、apacheを再起動すると、モジュール読み込みエラーがログに出力されます orz
依存性もなにも、php-common自体はすでに導入済みのハズなのでこれで行けそうなもんですがそんな単純な問題ではないようです。

解決方

さすがにコレは出来るだろうと思って最後まで暖めていたのが、ソースコードからのコンパイルインストール。
結論から言ってこれは上手くいきました。

まずは、環境が整っているかを確認します。

# gdlib-config --version
2.0.33
# php -v
5.2.16
# locate libjpeg
/usr/lib/libjpeg.so.62
/usr/lib/libjpeg.so.62.0.0
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjpeg.so
/usr/lib64/libjpeg.so
/usr/lib64/libjpeg.so.62
/usr/lib64/libjpeg.so.62.0.0
~省略~
# locate libpng/usr/lib/libpng.so.3
/usr/lib/libpng.so.3.10.0
/usr/lib/libpng12.so.0
/usr/lib/libpng12.so.0.10.0
/usr/lib64/libpng.a
/usr/lib64/libpng.so
/usr/lib64/libpng.so.3
/usr/lib64/libpng.so.3.10.0
/usr/lib64/libpng12.a
/usr/lib64/libpng12.so
/usr/lib64/libpng12.so.0
/usr/lib64/libpng12.so.0.10.0

上記ですべてそろっていることが確認出来ました。
libjpeg と libpng はyumでインストール出来るので入っていない場合はインストールしておきます。

続いてインストールされているphpと同一のバージョンのソースコードを取ってきます。
php-gdモジュールのソースコードはphpの言語ソースコードに同梱されています。

phpの各バージョンはこちらからダウンロードできます。
https://www.php.net/downloads.php

僕のサーバーにはいっているphpのバージョンは 5.2.16 ですので同じバージョンのソースコードをダウンロード、展開します。
GDモジュールのソースコードはext/gdの中に入っています。

# tar zxvf php-5.2.16.tar.gz
# cd php-5.2.16/ext/gd
# phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519
 
aclocal
 
# ./configure
 
~中略~
 
checking for the location of libjpeg... no
checking for the location of libpng... no
checking for the location of libz... no
checking for the location of libXpm... no
checking for FreeType 1.x support... no
checking for FreeType 2... no
checking for T1lib support... no
checking whether to enable truetype string function in GD... no
checking whether to enable JIS-mapped Japanese font support in GD... no
checking for fabsf... no
checking for floorf... no
If configure fails try --with-jpeg-dir=<DIR>
configure: error: libpng.(a|so) not found.

なにおっ
さきほどlibpngの存在を確認下にもかかわらず、libpngが見つからないというエラー。
今度は明示的にconfigureにディレクトリを指定してあげることにします。

./configure --enable-gd-native-ttf --enable-gd-jis-conv --enable-shared --wi
th-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-xpm-dir=/u
sr --with-ttf=/usr --with-freetype-dir=/usr --with-t1lib=/usr
~中略~
checking for gawk... gawk
checking for GD support... yes, shared
checking for the location of libjpeg... /usr
checking for the location of libpng... /usr
checking for the location of libz... /usr
checking for the location of libXpm... /usr
checking for FreeType 1.x support... /usr
checking for FreeType 2... /usr
checking for T1lib support... /usr
checking whether to enable truetype string function in GD... yes
checking whether to enable JIS-mapped Japanese font support in GD... yes
configure: error: libjpeg.(a|so) not found.

orz

libpngは無事認識した物のこんどはlibjpegですか、そうですかそうですか。
ディレクトリを指定して、pngは認識してjpegが認識しない・・・
この違いはどこだろうと考えたところ、libにlibjpeg.soが入っていないw

単純に64bit OSなので、libではなく、lib64を見に行かなければなりません。
32bit OSでしたら、おそらくこの問題に引っかからずに無事configureが通ったのではないかと。

では、configure にlibではなくlib64を見に行く指定を追加します。

–with-libdir=lib64

がそれにあたります。

# ./configure --with-libdir=lib64 --enable-gd-native-ttf --enable-gd-jis-conv
--enable-shared --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/u
sr --with-xpm-dir=/usr --with-ttf=/usr --with-freetype-dir=/usr --with-t1lib=/usr
~中略~
checking whether to enable truetype string function in GD... yes
checking whether to enable JIS-mapped Japanese font support in GD... yes
checking for jpeg_read_header in -ljpeg... yes
checking for png_write_image in -lpng... yes
checking for XpmFreeXpmImage in -lXpm... yes
checking for FT_New_Face in -lfreetype... yes
checking for FreeType 1 support... no - FreeType 2.x is to be used instead
configure: error: Your t1lib distribution is not installed correctly. Please reinstall it.

お・・・
またエラーです。
t1libが入っていないか再インストールとのことなので・・・

# yum install t1lib.x86_64 t1lib-devel.x86_64

でインストール
再度configureを実行させます。

# ./configure --with-libdir=lib64 --enable-gd-native-ttf --enable-gd-jis-conv
--enable-shared --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/u
sr --with-xpm-dir=/usr --with-ttf=/usr --with-freetype-dir=/usr --with-t1lib=/usr
~中略~
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
configure: creating ./config.status
config.status: creating config.h

やったー!
無事configureが実行されました。
続いて

# make
----------------------------------------------------------------------
Libraries have been installed in:
   /home/admin/src/php/php-5.2.16/ext/gd/modules
 
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'
 
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
 
Build complete.
Don't forget to run 'make test'.
# make install

無事、makeもmake installも通りました。
これでphpの所定の位置にモジュールが出力されているハズですので・・・

php.iniのextentionの書かれているあたりに下記を追加します。

extension=gd.so

で、apacheを再起動させログを確認。。。
エラー無し。

では、phpinfoで確認

ジャッジャーン
無事、GDモジュールが認識いたしました。

結構大変な作業でした。
よほどな理由がなければ、やはりyumでphp-commonをremoveさせてから再インストールさせたほうが簡単で早いと思います。




WordPress 3.14 に PHP Execution を入れてみたメモ。

PHP Executionは、WordPressの投稿や、固定ページなどで直接PHPのコードを実行することを出来るようにするプラグインです。
結論から言うと・・・結局このプラグインは僕は使いませんでした。

そのインストールの時のことについて、ちょっと書いてみます。

インストール自体はプラグインの追加でPHP Executionを検索するだけでインストールが可能です。
設定とかも、ユーザーごとの実行権限の設定などきめ細かい設定が可能です。

ただ、2点ほど使っていて気になったところがありました。
一つは、エラーとなって正常に動作しなかったので現在使いませんでした。

まず1点目は、<?php ~ ?>とPHPコードを書くのですが、このコードを通常の投稿で記述してももちろん正しく実行させることはできません。
もしかしたら僕が別に入れているTinyMCE Advanceが悪さしているのかもしれません。

WordPressのビジュアルモードでは、プログラム実行用のコードから安全な形にWordPress側で調整されそのままでは実行できません。
しかし、HTMLモードで書くことで記述することは可能です。
基本的にコードを記述する際は、HTMLモードで記述することが必要になりますが、それでも実行されませんでした。

原因は下記です。

不正にネスト化したXHMLを自動的に修正する。
ここにチェックが入っていたために、コードが実行できる形式で保存されず、コードの実行まで至りませんでした。

この設定をすることで問題なく動作するようになります。

しかし、投稿画面でJavaScriptのエラーが発生します。

ちょっとコードを追っかけるのが面倒なので、ほかのを探したところ「Exec-PHP」という同様のプラグインがあったのでそちらを利用しています。
こちらは今のところエラーなどもなく階調に動作しています。

そのほかにも有名なところで、「runPHP」というプラグインもあるのですが僕の使っているバージョンには適応できないのか、プラグインインストール後プラグインリストにすら表示されないという罠があったのでこちらはスルーの方向で^^;;

HP ProLiant ML110 G6 節電買い換え


今までサーバーを意識して購入せず、あまった部品を有効利用しておりました。

今まで使っていたハードウェア構成は下記

CPU Pentium 4 Extreme Edition 3.4G
CORE Gallatin CORE SOCKET 478 FSB 800MHz
TDP 103W
64bit 非対応
MotherBoard ASUS P4C800-E
Memory 2GB Dual Channel

今年の夏は、電気不足が懸念されているので、我が家でも切り詰めをしようと考えました。
切り詰めるといっても、それほど家にいないので切り詰めるところもすくなく・・・

確実に常時電源が入っているところでリプレイス出来るものをさがすると・・・有るじゃないですか。
このサーバーです。
早速、上記のスペックのサーバーをエコワットで消費電力をチェック。

電源投入時は
180W
その後起動中は
160W
起動完了後安定動作中で
120W
その後の電気消費をチェックしていましたが、多少アクセス過多になると140W程度になるもののだいたいは120W~130Wぐらいで安定しています。

コレってどうなの?ってかんじです。
これを24時間ずっとうごかしっぱなしぱなしにすると、だいたい3000円から4000円ぐらいになるみたい。

もちろんお金も大切ですが、何より無駄な電気は節電しなきゃ・・・
そんな想いからリプレイスを真剣に考えるようになります。

最初考えたのが、モバイルCPUでのリプレイス案。
Core2DuoのTシリーズ(モバイル)でT7200あたりでの運営。
TDPは34Wになります。

これならずいぶん低くなるけど・・・ スペックは今のPentium4より、1.5倍か2倍程度のスペックアップかなぁ。
64ビット命令が使えるようになるからもしかしたらもうちょっとかもしれない。
ヤフオクで、調べるもだいたい一式そろえるとパーツだけで1万ぐらい・・・

そんなことを考えながらいつも仕事でお世話になっているNTT-Xさんを見ていた時です。
いつもはNEC Expressサーバー 5800がラインナップとして並ぶ特価品サーバーコーナーにHP ML110 G6が出ていました。
金額は13,980円。

コレでも十分に安いよねぇ・・・と想いながらスペックを開いて見ていると。

・・・Σ(゚д゚)え?
13,980円だよね・・・え?
13,980 – 4,000 = 9,980円(送料込み)

もうね、考えてなかった(;´∀`)
気がついたらポチってたw

そんなこんなでML110 G6が我が家にやってくることになりました。
ちなみに、わかっている上でのスペックは下記のような感じ。

CPU Intel Celeron G1101 2.26GHz
CORE Clarkdale DUAL CORE LGA1156
TDP 73W
64bit 対応
MotherBoard Intel 3420
Memory 2GB Single Channel

さすがにモバイルCPUほどではありませんが、TDPも低めです。
なにより、最新のサーバー一式がこの金額なら・・・
保障もキーボードも、マウスもケースも電源もドライブも付いちゃっています。

ヤフオクで部品単位で買うよりはかなりお買い得。

実際の消費電力は未知数ですが、いまよりは酷いことにならないでしょう。
到着が楽しみですね。

 

NTT-Xでは、通常在庫でML110 G6を扱っています。
そもそもが安いので癖はあるけどとりあえず安定したマシンが欲しい方にオススメです。
値段は随時変わるので下記のリンクからどうぞ


HP ProLiant ML110 G6 (CeleronG1101 2.26GHz)

HP ProLiant ML110 G6 (Core i3-530)

自宅サーバーで運営されている当サイトは、機材の不調などによって不調をきたすことも多々ありますが、どんなハードエラーでも部品さえあればすぐに復旧をかけられるメリットがあります。

しかし先日、サーバー用に接続していた24インチ液晶ワイドモニタがお逝きになりました orz

このモニタはサーバーと実験用マシンとかの検証用などで常用はしないまでもメンテナンスなんかでとても貢献してもらっていたモニタでした。
結局うちに来て1年半ぐらいでお逝きになってしまいました。

もちろん分解をして原因を探ったところバックライトが異常で、おそらく複数あるバックライトのうちどれか一つが異常になってしまっている模様。
起動時は表示してしばらくたつとバックライトが消えるという現象です。
おそらくCCFLを交換すれば大丈夫だと思うのですが・・・このサイズに合うCCFLを探すのが大変そうなのでとりあえずしばらくは放置。

そんなわけで、緊急でモニタが欲しくてハードオフをマメに見ていたのですが、良い出物がありました。

NEC F17R21
SoundVuに対応品のモニタで、液晶面をスピーカーの用に振動させて音を出すというすごい仕組みのモニタです。
こいつが、2500円。

早速購入したのですが、この子癖があってDVI-Dしか接続できない ^^;;

サーバーもDVI-Iの接続が出来るので問題ないのですが、起動時のテキストの表示がされるもののX gnomeの画像が一切されない。
どうやらうちのビデオカードは、アナログとデジタルとあった場合アナログ優先で表示される癖があるようですね。

別のマシンに同じビデオカード(Matrox G550)を投入して、インストール実行をしようとFedora Core8 DVDを入れて実行したところanaconda付近でモニタの表示が切れます^^;;
Xの仕様かビデオカードの仕様かは定かではないですが、せっかく買ったモニタが宝の持ち腐れになってしまうので何とか表示させてみようとおもいます。

サーバーから直接「system-config-display」コマンドを実行して試行錯誤するも設定画面は表示されるのにXでは表示されない。

いったい何が違うのかと思ってもなかなかに違いが分からず悩んでいました。
「xorg.conf」を直接開いて眺めていたら、ドライバを標準のVESAにしてみてはどうだろうかと思い立ちました。

「xorg.conf」にはビデオドライバの記述がありますのでそこをVESAに書き換えました。

Section “Device”
        Identifier  “Videocard0”
        Driver      “mga”
EndSection

上記の部分を

Section “Device”
        Identifier  “Videocard0”
        Driver      “vesa”
EndSection

に書き換えて、

コマンドから

>init 3
>init 5

で、キター!!

見事800×600で動作。
後はXで通常どうり解像度を合わせて、こいつの場合は1280×1024なので、その設定にしてばっちり動作いたしました。

おそらくドライバの設定が標準VESAになることで動作速度などビデオカードの本来の性能は出ない気はしますが、サーバー用のモニタとしてはとりあえずメンテナンス時に映ればいいですしね。

無事動いて嬉しくなってきたし、値段も値段なので使い倒してやろう。 

Sounv Vu 液晶モニタ

ふとそんなことを思い立って別サーバーの画像フォルダを参照してデジタルフォトフレームとして活用してみました。
17インチのフォトフレームってちょっと豪華ですね。^^v

さすがに8インチとかに比べて迫力が違うw
それに視野角が広いからどこからでも高画質を楽しめるっていうのは素敵です。
しかもネットワーク共有フォルダを直接読みに行けるからメモリーカードとか書き換えないで済むし。

元々サーバーで常時電源は入っていたのでリソースの有効利用ということで。
しかしこのモニタの消費電力65W・・・
さすがにでんこちゃんに怒られそうな勢い。
結構バカにならないので多分すぐに電源消されることだと思いますw

ぱなしは、無しって話です。(ぉ


Movable Type5でのプラグイン修正


昨日Movable Type5へ無事バージョンアップを果たしたのですが、やっぱりそのままの移行では使いルプラグインと使えないプラグインがある。

優先順位の高い物、直近で使用すると思われるプラグインをチェックしてみた。

・カテゴリソートプラグイン SortCarFld
正式にMT5に対応したバージョンが存在していたので問題なく対応できた。

・Google Maps 地図表示プラグイン Mapper
とりあえず動いているっぽいです。

・LightBox支援システム LightBox2MT。
当ブログでの画像拡大機能のLightBox(ColorBox)これは日々使うので重要なのですが・・・正常に動作しませんでした。

ある意味一番重要でもあるプラグインが動作しなかったので、修正を試みます。

まずは・・・この部分。

Movable Type5 アップロード

入力フィールドでかっ^^;;
こんなにでかいフィールドはいらないので小さくしましょう。
ソースの57~59行目です。

&lt;__trans phrase="pixels"&gt;)
 [ <label for="lightboxgroup">&lt;__trans_section component="LightBox"&gt;&lt;__trans phrase="Use LightBoxGroup"&gt;</label>
  ]

上記のような場所にclass指定をしてあげます。

&lt;__trans phrase="pixels"&gt;)
 [ <label for="lightboxgroup">&lt;__trans_section component="LightBox&gt;&lt;__trans phrase="Use LightBoxGroup"&gt;</label>
 ]

上記のように修正します。

すると

Movable Type5 アップロード

上記のように綺麗なサイズに修正されます。
次に、LightBoxで表示するにチェックをするにしても指定されたサイズで画像が出力されない問題にぶつかりました。
サムネイルはちゃんとサイズを指定するとそのサイズにリサイズされるにもかかわらず、こちらは画像すら出力されません。

ソースコードを見ると異常なところは見あたらないのですが・・・
よくよく見てみると、asset-idの書き出しはMT4では「<form mt:asset-id=”5″~」と表現されていたのが、MT5では廃止されていました。
ちょうどソースコードではこの部分77~80行目です。

if ( $app-&gt;param( 'lightbox_width' ) ) {
my $asset_id = $1 if ( $upload_html =~ // );
if ( $asset_id ) {

この部分は、asset-idをformから取得しようとしているのですが、ここでasset-idの取得が出来ずに79行の判定がTRUEにならずに処理が飛ばされていました。
asset-idは、$paramですでに渡ってきているようなので、下記のように修正しました。

if ( $app-&gt;param( 'lightbox_width' ) ) {
my $asset_id = $app-&gt;param('id');
if ( $asset_id ) {

asset-idをparamから取得するように変えます。
とりあえず、僕はこんな感じの修正で動作するようになりました。

問題ありそうならコメント下さいませ^^




WordPressを使う以前はMovable Type(MTOS)を使ってサイト全体を管理していますが、以前から標準装備されているリッチテキストがどうにも使いにくくて困っていました。

Movable Type 5も出て久しいですが、正直安定を望むシステムでは正直新しくすればよいという安直な考えには至らずしばらく様子見をしてみました。
それもどうやら安定期にはいったようなので、システムリプレースのひとつとしてHDD交換と一緒にアップデートをかけてみました。

とはいっても、そもそもリッチテキストエディタの使い勝手がMovable Type5で改善されているのか。
ブラウザによる依存性は解消できているのかなど、わかっていないことも多々ありましたがこの辺はやってみないとわからないのでトライしてみました。
結局管理の僕たちの手間が増える分には仕方がないで済ませられますw

ご覧いただいているみなさまに不具合を出しては申し訳ないですが、あるいみこうゆうことができるのはMovable Typeの強みですね。
まぁそれ以外にも重いとか、小さな不満はあったのでそういった改善も含めてのバージョンアップです。

 

今まで使用していたバージョンは、
MTOS 4.261

このバージョンから、現在最新版の
MTOS 5.01

へアップデートを検討します。
僕がMTOSの方を利用する理由ですが、ライセンスが面倒くさくないからw
six apartの正式なMovable Type(個人ライセンス)も無料で使えてカスタムフィールドとか魅力たっぷりなのですが、後々ライセンスがどうこうとか言われてもうっとうしいのではじめからアテにしない方が良いかなと完全オープンソースのMTOSを好んで使用しています。

とりあえず、WEBのデータ領域のバックアップ、データベースのバックアップはしっかりやっておきます。
僕は昨日のHDD交換騒ぎでドライブ自体のバックアップも取ってあったので心置きなく進められます。

まずは公開エリアの他にシャドウエリアを用意して、そちらにMTOS5を入れます。
バックアップがあるとは言え、何らかの不具合が無いとは言い切れませんし、こういった物はトラブルはつきものですからねぇ。
とりあえずシャドウエリアへのインストールが無事完了しました。

Movable Type5

まずは、インストールしてURLをたたいてこのMTの初期の画面が表示されれば最初の問題はクリアですね。

続いて動作環境のチェック。
上記ページの下の解説にあるリンク「Movable Typeシステムチェック(mt-check.cgi)」をクリックします。

Movable Type5

上記のように「システムチェック完了しました」のメッセージが表示されれば問題ないです。
こちらはバージョンアップなので基本的に追加しなければいけないライブラリなんかは無いはずです。

それでは、緊張のアップデートを開始しましょう。
最初のページから「サインイン」をクリックするとMTに登録されている管理アカウントでログインします。
無事ログインできると、下記のようなアップデートを促すページが表示されます。

Movable Type5

「Begin Upgrade」をクリックするとデータベースの構成を自動でMT5に対応するようにアップグレード処理が実行されます。
とくに問題が無ければそのまま自動で処理が完了するハズです。

Movable Type5

無事処理が終わりました。
「Return to Movable Type」をクリックするとMT5にログインできます。
アップグレードは以上ですが、ここのサイトは完全オリジナルテンプレートを使っていますのでそのままでは使えませんでした。
どうやら余分なテンプレートやテーマなどMTの初期データも追加されているようです。
初期データの整理などを行って無事使えるようになりました。

また、プラグインも新たにインストールしなければなりませんのでそういったプラグインも準備して無事使用が出来る状態になりました。

ここの場合は予想していた大きなトラブルも発生せずに使用できました。

それで、一番切望していたリッチテキストの動作改善ですが・・・
ばっちりです!
画像の挿入でカーソルが重いどうりな位置に行かないとかどうしても煩雑な操作が一気に解決しました。
出力されたソースの美しさなども、4に比べて格段に良くなっていると思います。

 

ただ、標準の言語が日本語設定になっていません。
これは僕がMTOS5をインストールしたときに、mt-config.cgi-originalをmt-config.cgiにコピーしただけだったのがいけなかったのかもしれせんが・・・
言語設定をコンフィグに書き換えることで無事標準言語が日本語になりました。

DefaultLanguage ja

上記を「StaticWebPath」の下あたりに追記しました。
また、DBHostの下あたりに

SQLSetNames 0

も追加しておきました。

ここまでのコンフィグで特に問題もないかと思っていたのですが・・・
コメントが書かれるとメールの言語が化けていました。^^;;

先程追加した「DefaultLanguage ja」の下あたりに、下記を追加しました。

MailEncoding ISO-2022-JP

今のところ上記の対応で問題なく使えています。


3 / 3123


ブログランキング・にほんブログ村へ