月別アーカイブ: 2009年7月

SSL対応Apache起動時にPasswordを入力せずに起動する方法 その2

以前、一度やり方を書きました。

SSL対応Apache起動時にPasswordを入力せずに起動する方法

今回は、その2と言う事で、ちゃんとしたやり方です。

■前提

 keyファイル名:2009key.pem

# cp ./2009key.pem 2009key.pem.org.20090727

# openssl rsa -in ./2009key.pem -out 2009nokey.pem

Enter pass phrase for ./2009key.pem: [パスワード入力]

writing RSA key

以上。

念の為、元のkeyファイルをバックアップしてからやって下さいね。

あとは、httpd.conf なり、ssl.conf にて、パスワードを解除したkeyファイル指定すればOK。

簡単ですね。

ちなみに、以下方法で、パスワード無しのkeyファイルも作れます。

# openssl genrsa -out ./2009key.pem 1024

「-des3」のオプションを付けなければおk。

ちゃんとパスワードを付けて運用するのが一番良いのですが・・・

でわ。

商品詳細画面にて「Warning: getimagesize」が表示される問題の回避策

今回は、EC-CUBE 2.4.0 です。

商品詳細画面を表示すると、以下、表示されました。

Warning: getimagesize() [function.getimagesize]: Filename cannot beempty in /home/sodc/www/eccube-2.4.0/data/class/pages/products/LC_Page_Products_Detail.php on line 282

原因は、商品詳細画面にて使用する、商品の拡大画像が登録されていないから。

管理画面で商品の拡大画像を登録すれば、上記表示されません。

しかしながら、商品の拡大画像をいちいち登録していくのはナンセンスなので、ちょろっとソースを修正してい対応します。

# cd eccube/data/class/pages/products

# vi LC_Page_Products_Detail.php

// 以下をコメントアウト

Line 276

  // 拡大画像のウィンドウサイズをセット

  if (isset($this->arrFile[“main_large_image”])) {

    $image_path = IMAGE_SAVE_DIR . basename($this->arrFile[“main_large_image”][“filepath”]);

    } else {

      $image_path = “”;

    }

    list($large_width, $large_height) = getimagesize($image_path);

    $this->tpl_large_width = $large_width + 60;

    $this->tpl_large_height = $large_height + 80;

Line 500

    // 拡大画像のウィンドウサイズをセット

    if (!empty($this->arrFile[“main_large_image”])) {

      list($large_width, $large_height) = getimagesize(IMAGE_SAVE_DIR . basename($this->arrFile[“main_large_image”][“filepath”]));

    }

    $this->tpl_large_width = isset($large_width) ? $large_width + 60 : 0;

    $this->tpl_large_height = isset($large_height) ? $large_height + 80 : 0;

これでWarningの表示はなくなります。

そんな感じで。

でわ。

Smartyでファイル出力エラー

PHPのテンプレートエンジンである、Smartyを使用したWebサイトにて不具合が。

エラーの内容を見てみると、

Smarty error: problem creating directory [ディレクトリパス]

が出力されていました。

Apacheのサービスは正常動作している。

Apacheのエラーは出力されていない。

ディレクトリのパーミッションも問題無し。

phpinfo見ても大丈夫。

って事で、ちょっとハマりました。

結果、原因はinode。

※WebサーバはLinux(CentOS)

Smartyが出力するキャッシュのディレクトリにえらい数のディレクトリとファイルがあり、inode を超えていたようです。

なので、とりあえずはキャッシュ削除して復旧。

調査している中で、

Smarty.class.phpの、

var $use_sub_dirs = true;

を、

var $use_sub_dirs = false;

にすれば大丈夫。

とのエントリもありましたが、既に false になっていた。。。。。

暫定対応ですが、定期的にキャッシュ削除するスクリプトでも組んで、cronで回そうかと思います。

根本的な対応はまた別途。

でわ。

EC-CUBE 2.4.1の文字化け回避

ちょっくらEC-CUBEを触る事がありまして、最新版を入れたところ文字化けしましてね。

UTF-8でうまくいかなかったので、その回避の為の設定を記載します。

※あまり詳しくは書かないです

■環境

OS   : CentOS 5

Apache : 2.2.3

PHP   : 5.1.6

MySQL  : 5.0.22

1) EC-CUBEのファイルを展開する

# unzip eccube-2.4.1.zip

2) PHPの設定

# cd eccube-2.4.1/html

# vi .htaccess

php_value default_charset UTF8

php_flag magic_quotes_gpc Off

php_flag auto_detect_line_endings On

php_value output_handler mb_output_handler

php_value mbstring.language Japanese

php_flag mbstring.encoding_translation On

php_value mbstring.internal_encoding UTF-8

php_value mbstring.detect_order auto

php_value mbstring.substitute_character none

php_value mbstring.http_input auto

php_value mbstring.http_output pass

php_value upload_max_filesize 5M

3) MySQLでDBと接続ユーザを作成

# mysql -u root

mysql> create database test_db default character set utf8;

Query OK, 1 row affected (0.00 sec)

mysql> grant all on test_db.* to test_db_user@localhost identified by ‘パスワード’;

Query OK, 0 rows affected (0.04 sec)

4) ちょっとApacheの設定

DocumentRoot:eccube-2.4.1/html

に設定

5) EC-CUBEのDBアクセスファイルを編集

# cd eccube-2.4.1/data/class/

# vi SC_DbConn.php

————————————————-

66行目付近にこれを追加

if (DB_TYPE == ‘mysql’) {

$objDbConn->query(‘SET NAMES utf8’);

}

————————————————-

6) EC-CUBEのインストール

http://example.com/install/index.php

これで大丈夫なはず・・・

でわ。

回線速度の測定について

巷には、色々な回線速度測定サイトがあります。

さて、それでは、特定のサーバと自端末との間の速度を測る場合にどうしたらよいか?

そういった測定サイトはないんですよね。

まぁ、セキュリティ的にどうなんだって話しですが。

基本的には、ファイルのUP/DOWNでの回線計測なので、自サーバでやる場合には実装は簡単でしょう。

って事で、週末に時間があれば実装の予定。

近々使う機会があるので。

でわ。

CMSの人になろう

会員サイトなど、バックエンドとフロントエンドに分割されるサイトの場合、

現状、フルスクラッチで作る事が多く、工数もそれなりになります。

それではいかんですよね、と。

って事で、CMSの人になろうかと思いまして。

DBが絡むからベースのカスタマイズは必要ですが、まぁ、フルスクラッチでやるよりは工数かからないと思われます。

不況で冷え込んでる昨今、少しでも安価にして仕事を取っていかなければですね。

サイトの特性によっても使い分ける必要があるので、ひとつのCMSだけでは弱いです。

TYPO3/Plone/MODx/XOOPS などなど。

さて、CMSの選定と検証をしなければ。

でわ。