9月 24

coreserverのマイグレーションに対応

先日、value-domain(GMO)のレンタルサーバー「coreserver」が新しい環境に移行しました。
これに伴い、パッケージのバージョンが変更になりましたが、特に大きな問題は発生しませんでした。

ただひとつ、MySQLのバージョンが5.1から5.7に上がったため、5.6から実装されたコマンドにパスワードを入力するとアラートが表示される問題。
cronでデータベースをダンプしているので、毎日毎日アラートがメールで飛んで来るように。

根本から断つために、シェルを若干調整しました。

#!/bin/sh

# cron shell for coreserver
cd /virtual/user_name/public_html/domain_name/admin
/usr/local/mysql/bin/mysqldump database_name --user=user --password=password > mysql/mysqldump

exit

となっていたところを、

#!/bin/sh

cd /virtual/user_name/public_html/domain_name/admin
/usr/local/mysql/bin/mysqldump --defaults-extra-file=./.mysql.user database_name > mysql/mysqldump

exit

と変更します。

「.mysql.user」というファイルを参照していますが、この内容は

[client]
user     = user
password = password

となります。

これでcronが走る毎にメールが飛んでこなくなりました。
でめたしでめたし。

5月 14

coreserverにOpenPNE3.6.3をインストールする、けど失敗した

coreserverにopenPNEをインストールします。
手順は、実際に進めた手順通りに記載しています。

ちなみに、この記事は、
coreserverにOpenPNE3.6.0をインストール(速度はともかくxreaも同手順で可)
を見ながら進めました。

○ドメインを取得する
既に取得済みであったり、取得済みのサブドメインなどで運用する場合は不要です。
ここでは、このサイトのドメインであるpenlaboのサブドメイン、openpen.penlabo.netで運用することにします。

○ドメインのDNSを設定する
ドメインのDNS設定画面から、openpne.penlabo.netの参照先に、coreserverのipアドレスを指定します。
ここでは、s102鯖を使用しますので、202.172.28.103を指定します。
DNSの設定が浸透するまで、多少の時間がかかります。

○coreserverのドメイン情報(Web)を設定する
DNSを設定したら、鯖側で受信できるように設定する必要があります。
coreserverの管理メニューにログインして、メニューのドメインウェブから設定します。
先程設定したドメイン名、ここではopenpne.penlabo.netを入力し、DNSの逆引きができないとエラーになるので強制にチェックを入れて送信します。

○coreserverのFTPを設定する
サブFTPアカウントに、ドメイン情報と同じドメインで設定を追加します。
ここではユーザ名を、サブドメインと同じopenpneに設定します。
ディレクトリはさっき設定したドメイン情報を候補から選択すると自動で入力されます。
パスワードは任意で入力して、送信します。

○SSHを使用する準備をする
coreserverでSSHを使用するには、リモート側の登録が必要です。
ホスト情報登録より、SSH登録を行います。
一度登録すると30日間有効になりますが、都度登録するようにしておくといいでしょう。

○SSHで接続する
Windowsから操作しているので、SSHクライアントにはPuTTYを使用します。
接続先にs102.coreserver.jpを指定して、ログイン名、パスワードを入力してログインします。
さっきの登録が反映されるまで多少の時間が必要かもしれません。

○ソースのURIを確認する
openPNEのダウンロードページに移動します。
zipファイルを使用しますので、リンク先のURIを取得してください。
主に右クリックからコピーできると思います。
リンク先は最新版になっているはずですが、3.xであれば、おそらくこちらの解説の方法でインストールできるはずです。
現時点では、記事のタイトル通りの3.6.3です。

○ソースをダウンロードする
SSHからwgetを利用してソースをダウンロードします。
ダウンロード先は$HOMEです。
一度、public_htmlの下層でインストールしたら失敗したので、ルートでやります。
リンク先がSSLで取得に失敗する場合は、「–no-check-certificate」スイッチを追加します。

> wget --no-check-certificate https://nodeload.github.com/openpne/OpenPNE3/zipball/OpenPNE-3.6.3
--2012-05-13 21:32:50--  https://nodeload.github.com/openpne/OpenPNE3/zipball/OpenPNE-3.6.3
Resolving nodeload.github.com... 207.97.227.252
Connecting to nodeload.github.com|207.97.227.252|:443... connected.
WARNING: cannot verify nodeload.github.com's certificate, issued by `/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3':
  Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK
Length: 11101788 (11M) [application/octet-stream]
Saving to: `OpenPNE-3.6.3'

100%[=======================================>] 11,101,788  2.07M/s   in 7.1s

2012-05-13 21:33:00 (1.48 MB/s) - `OpenPNE-3.6.3' saved [11101788/11101788]

○ソースを確認する
lsでファイルを確認します。
ダウンロードに成功していたら、拡張子なしのzipファイルが作成されています。

> ls
OpenPNE-3.6.3

○zipファイルを解凍する
SSHからunzipを実行します。
大量にプロセスログが表示されますので、転記は省略します。

> unzip OpenPNE-3.6.3

プロセス完了後に、lsで確認します。

> ls
OpenPNE-3.6.3  openpne-OpenPNE3-079f26e

このままでは扱いづらいので、リネームします。

> mv openpne-OpenPNE3-079f26e openpne3.6

○設定を開始する
zipファイルを解凍した中にconfigディレクトリがあるので、移動します。

> cd openpen3.6/config

設定ファイルのサンプルがあるので、リネームコピーします。

cp OpenPNE.yml.sample OpenPNE.yml
cp ProjectConfiguration.class.php.sample ProjectConfiguration.class.php

○DBを準備する
データベースを用意します。
coreserverの管理メニューから、データベースを選択します。
データベースはMySQLを使用します。
ユーザ名はわかりやすいようにopenpne、文字コードはunicode、パスワードを設定して、ラジオボタンを選択して作成で送信します。
少し時間を空けてから、phpMyAdminでログインできることを確認します

○OpenPNEのインストールを開始する
システムのルートに移動します。

cd ../

OpenPNEはsymfonyを使用しています。
以下のように、インストールコマンドを実行します。

php symfony openpne:install

以降、問答形式でプロセスが進みます。

データベースを選択します。
MySQLしかサポートしていませんので、mysqlを入力します。

データベースのユーザ名を入力します。
さっき登録したものを入力します。

パスワードを入力します。
さっき登録したものを入力します。

ホストを入力します。
ローカルホスト(localhost)です。

ポート番号を入力します。
空のままで大丈夫です。

データベース名を入力します。
coreserverでは、ユーザ名と同じです。

ソケットパスを入力します。
空のままで大丈夫です。

最期に入力を確認してきますので、問題なければYを入力します。
全てのプロセスが完了する前に、時間がかかりすぎてKilledされるかもしれません。
その場合は、何度かinstallを繰り返せばそのうち完了します。

> installer installation is completed!

ちなみに、失敗した一回目は4回目で完了しましたが、2度目はやり直すことなく一回で完了しました。

○シンボリックリンクを設定する
インストールが完了すると、システムのルートはopenpne3.6/web/になります。
このままではWebでアクセスするときにhttp://openpne.penlabo.net/web/と不恰好になるので、http://openpne.penlabo.net/でアクセスできるようにシンボリックリンクを設定します。

ln -s $HOME/openpne3.6/web $HOME/public_html/openpne.penlabo.net

○.htaccessを設定する
coreserverの場合、safemodeで動かさないと制限があるため、MIMEを設定します。

AddHandler application/x-httpd-php5cgi .php

モジュールも切ります。

mod_gzip_on Off

○動作を確認する
お疲れ様でした。
これでインストールは完了です、と思いきや、openpne.penlabo.netにアクセスすると404になります。
もしやとおもい、openpne.penlabo.net/webにアクセスすると、ログイン画面が表示されました。
どうも、ちゃんとwebの中を見に行けてないみたいなのですが、シンボリックリンクの設定はこれであっているはずです。

さて、どうしたものか…

9月 06

客から逃げることが運営の仕事?

レンタルサーバーでのお話です。
coreserverというブランドを提供しているdigirockのお話です。
この会社は以前からいろいろとうわさが耐えませんが、そんなにひどいとは思っていませんでした。
ちょっとレスポンスの悪いネトゲの運営程度にしか。

先日2010年8月17日よりs51サーバーに障害が発生し、復旧していないにもかかわらず復旧と告知、ユーザからさまざまな障害報告があがっているにもかかわらす無視を決め込んだのです。
これには驚きました。
digirockは大阪の会社ですが、大阪だからこそお金に厳しいと思っていたのですが、素人が運営しているとしか思えません。
プロ意識が足りません、いや、微塵もありません。
とはいえ、管理ツールはそれなりに使いやすく、何事もなければいたって快適なため、結局他のサーバを借りました。
しかし、ここでs51が使用できないために仕方がなく新しいサーバを借りたのに、初期費用や期限までの有料期間分を移動して欲しいと問い合わせたところ、1週間経っても回答がありません。

ただ待っていても埒が明かないので、再度送信することにしました。
すると以下のような回答が来ました。

-------------------
[2010-09-06 09:04:45] サポートからメッセージが追加されました。

大変恐縮ではございますが、弊社のシステム上、同一ユーザー様のお問い合せが散在してしまいますと、かえって優先順位が下がってしまいます。
そのため、本案件につきましては、終了させていただき、
https://www.value-domain.com/support.php?action=edittopic&supportid=○○○○○○&mode=
(上記にアクセスできない場合)
 http://www.value-domain.com/support.php?action=edittopic&supportid=○○○○○○&mode=
にて、ご対応させていただきますので、何卒、ご了承くださいますようお願い申し上げます。
(こちらでお問い合わせいただいております内容も、引き続き、統合させていただきました上記にてお問い合わせいただきますようお願い申し上げます)

■弊社からのお願いです■

この度、連続して別々にお問い合わせいただいており、サポートが混乱してしまっている状況です。
(弊社では、1人のサポートスタッフが全てのユーザー様を対応するのではなく、お問い合わせごとに対応できるサポートが担当しております。通常 (1つずつ)の場合ですと、続けて対応できますが、今回のようにバラバラにお問い合わせいただいてしまいますと、「それぞれ個別の新規のご相談」として扱われてしまいます。その結果、同じような内容が重複したり、あるいは、本来、別の質問と組み合わせて対応した方が良い部分の対応ができなかったり、ユーザー様にとっても混乱の原因となってしまいます。また弊社のシステム上、その都度、別々のメールが配信されてしまうなどのご不便も生じてしまいます)。

全く別の内容であっても、同時期のお問い合わせの場合は、関連性がある場合、あるいは、一人の担当者が同時に対応させていただいた方がわかりやすい場合がございます。

弊社サービスのコンセプトは「フルサポートで高価格になるのではなく、ユーザーの皆様のご理解とご協力のもと、多くのユーザー様がご希望されるようなサービスを低価格でご提供するということ」になっておりますこともあり、ユーザーの皆様に対しましては、サポートの負荷を極力減らしていただきますよう、ご協力お願いしております。
何卒、ご理解とご協力の程、よろしくお願い申し上げます。

■ご返信期間について■

極力、迅速なご対応を心がけておりますが、弊社では、
━━━━━━━━━━━━
●定型回答文によるご返信の場合
 原則として24時間~48時間以内にご返信します。
━━━━━━━━━━━━
●個別回答文によるご返信の場合
 優先サポートの場合は7営業日以内、通常サポートの場合は20営業日以内にご返信します。
━━━━━━━━━━━━
とさせていただいております。
また、優先サポートにつきましては、
 ●あくまでもご対応の優先順位をあげる
ということが目的であり、問題の解決をお約束するものではございません。
また、回答内容の質につきましても、通常のサポート回答と同等とさせていただいております(しかし、他のご回答よりも優先的に対応させていただく…という形になります)。

————
担当:○○
------------------

一番の混乱は障害を虚偽報告することだと思うんですがね。
それに内容に応じて担当者がいるって書いてますが、失礼承知で能無しだと思うんです。
それと、一番肝心なのは「問い合わせを見たけどすぐに対応できない絡まってくれ」という返信をよこすことです。
なんといいますか、ユーザサポートのノウハウがまったくないですね。
素人でもできるような対応をとらないため、「自ら作業を増やしている」ことに気がつくべきです。

7月 17

Perlモジュールのバージョン違いに填まる

自作CMSでJSONを使うことにしました。
最近あまり使っていませんが理屈はわかっています。JavaScriptではevalです。
ではなくて、PerlではJSONモジュールを利用すれば問題ない、はずでした。
結論から言うと、ローカルのテスト環境と、coreserverではJSONモジュールのバージョンが違うためにサブルーチンが見つからないとかいわれて怒られていたのでした。
ローカルの環境では2.21、coreserverは3年前の1.14で、to_jsonやfrom_jsonがありません。幸いなことにJSONhaPurePerlなのでコピーするだけでも動きます。
ということで、ライブラリパスを追加するのですが、pushではダメです。
先に読んでくれないと困るのでunshiftします。

BEGIN{ unshift @INC, (./'; }


これで問題なく動くようになりました。
ちなみに、unshiftではなくてpushを使ってしまっていて、なぜ新しいバージョンを読まないのだろうと数時間悩んだなんて恥ずかしくていえません。
なにはともあれでめたしでめたし。

3月 05

coreserverのSSL設定でディレクトリ指定が反映されない

coreserverでSSL導入を前提に構築し、問題がなさそうなので独自IPを購入して、そのIPでドメインを割り当て・・・
ると、強制的にディレクトリが作成されてしまう。
NoDir設定が有効にならない。
チェックを入れて保存しても反映されない。
時間を空けて何度か試してみてもだめだったのでサポートに問い合わせてみた。
深夜3時に送信したら、早くも数十分後に回答が。
その後2度やりとりしたけど、
「いただきました症状につきましては、弊社でも把握しており、担当部門からは対応中との報告を受けております。 」
まぁ、おそらく放置プレイなのでしょう。
仕方がないので、public_htmlの下のディレクトリに再構築しなおすしかなかったのでした。
でもこれでとりあえずSSLが導入できるわけですね。
その工程でも問題があったらどうしよう・・・

3月 03

PHPのセーフモードに悶え苦しむ

PHPの開発はなんだかんだで自前鯖や自宅鯖だったので、モジュールでフルの状態で動かしていたわけです。
プリントライはcoreserverに乗せたのですが、ここはセーフモードなのです。
あらかじめわかってはいましたがここまで時間をとられるとは思いませんでした。
まぁ、なんだかんだでCGIモードでなければならない部分はAjaxで逃げて事なきを得ています。
とりあえず行き詰った部分を。

・execが使えない(セーフモードというよりは鯖の設定か)
・mail関数で第5引数があるとワーニング8セーフモードのせい)
・ディレクトリのオーナーが違うと書き込めない(セーフモードのせい・Apacheとphpのユーザ)

2月 27

coreserver(CORE-B)のファイル容量

少し前にも書きましたが、アカウント作成直後ではファイル容量はフルでは使えません。送られてくるメールやページ上では、FTPなら1時間程度とありますが、実際にはほぼ即使用が可能です。
新しく取ったアカウント名ではしっくりこなかったので、アカウントを再取得することにしたので、ファイル容量についてしばらく観察してみました。

およそ4時間でファイル領域が確保されました。概ねこの程度の時間を考えておいたほうが良いようです。
ちなみに確保されるまでは
------------------------------
データ更新中ですので、次回更新をお待ちください。
------------------------------
と表示されます。
これが確保されると
------------------------------
最大ディスク容量 60,000.00 MB
使用済ディスク容量 0.00 MB (1.66 %)
残りのディスク容量 59,999.99 MB (98.34 %)
最大ファイル数 500,000 個
使用ファイル数 5 個
残りのファイル数 499,995 個 (99.99 %)
※ 数時間毎に更新されます。
※ 上限を超えると、CGIなどの書き込みでファイルデータが破壊される可能性があります。不要なファイルを削除して下さい。
------------------------------
となります。

2月 27

coreserverのPHPはセーフモード

いろんなユーザが混在する鯖なら、まぁ、当然といえば当然なのですが。
このことをすっかり忘れていたので、さぁたいへん。
ディレクトリを作らせてもその中にアクセスできない。
PHPはapaheユーザでディレクトリを作るけど、スクリプトはユーザで動くのでownerのチェックではじかれてしまう。
結局CGIモードにすることで回避できた・・・わけではなかった。
今度はsessionがユーザ違いで動かなくなったぁ~orz=3

2月 27

coreserver(CORE-B)を借りました

これから始める印刷通販サイト「プリントライ」のために、coreserverでCORE-Bを借りました。すぐにログインできるようになったので、早速ファイルをFTPでアップし始めましたが、50M程度で容量が一杯だと怒られます。いろいろ調べるとそういった不具合はちらほらあるみたいで、解決策もなさそうなのでとりあえず不貞寝しました。
そして目が覚めると、ファイルがアップロードできるようになっていました。
そこで改めていろいろと考えて見ます。
・鯖を借りてもログインまでには時間がかかるとは書いてあるけれど、これしか書いてない。
・時間がたてばスペースが正常になるので、おそらくファイル用の鯖への領域作成が別のプロセスで用意されていて、ログイン機能とは動機していない。
・改めて考えると、借りたすぐはファイル容量の確認ページには何も表示されないけど、不貞寝した後はきちんと60Gの容量が表示されていた。
つまり、ファイル容量のページに容量の情報が表示されるまではとにかく寝て待てということのようです。
結論として、寝る子は育つのです。

2月 04

PerlでCGI::Sessionがcoreserverではうまく動かない

Perlでセッション管理の話です。
PHPだとセッションはsession_start()と$_SESSIONで楽に扱えますが、Perlではたまに苦しみます。
さて、今回はローカルのVistaのActivePerlでは正常に動くスクリプトをcoreserverにアップすると挙動が違うのです。
クッキーは更新されているのに、セッションファイルが更新されません。
クッキーがない場合はセッションファイルを作成しているのですが、それ以降の更新が行えません。
また、クッキーだけ残してセッションファイルを削除するとセッションファイルの作成すらしてくれません。
極めつけはアクセスすると1分ごとにセッションファイルが量産されていくのです。
もちろんセッションの有効期限はそんなに短くありません。
どうしてかな~と、いじっているとどうやらリダイレクトが悪さをしているようです。
たとえばログイン処理でログインに成功するとログイン後のトップページへリダイレクトするわけですが、そうすると正常にセッションが更新されません。
リダイレクトをやめて一度ページを表示するなど出力をクローズしておけば期待した動きをしてくれます。

でも、CGI::redirectとCGI::Sessionの相性が悪いという話は聞いたことがありません。自分の開発環境では一度もそういう現象には出くわしたことがありません。
環境が違う点といえば・・・cgiwarpぐらいかな。「CGI::Session coreserver」とかでぐぐっても同じ現象の記事が見つからないので自分の書き方が悪いのかな~