libclntsh.so.11.1が見つからない。

PHPからoci8が連携できずに2日ほどハマったのでメモ。
Oracle関連って保守契約か何だかの約束で公式回答を
ブログやらニュースサイトに記載してはいけないということらしいが、
本件については明確に保守担当からPHPの連携およびOSに関わる部分なので
Oracle対応対象外ですと言ってもらった(見捨てられた)ので問題ないだろう。

まず、Oracleクライアントをランタイムでインストールし、
そして、PHPを--with-oci8=shared,$ORACLE_HOMEオプションをつけてコンパイルした。
正常にoci8.soライブラリが作成されたことを確認し、php.iniに追加してやる。

今回、PHPはCGI経由で呼び出すのでphp-cgiをCGIディレクティブにリンクし、
phpinfoだけ書いたindex.phpを作成し、稼働確認。
コマンドラインでphp-cgi -i index.phpでは正常に稼働し、oci8もenableだった。
ところが、ブラウザからアクセスするとphpinfoは表示されるもののoci8関連の項目がない。
error_logを確認すると、案の定下記のエラーが。。。

libclntsh.so.11.1: cannot open shared object file: No such file or directory

なるほど、Apacheの実行ユーザがライブラリパスを認識できないのね、と考え、
$ORACLE_HOME/libをld.so.confに追加したら
今度はlibexpat.so.11.1 is not a symbolic linkというエラーが出る。
もちろん、ブラウザ接続でのoci8認識はできず。

ここで保守担当に連絡を取るも、それってPHPのエラーですやん、という回答。
確かにその通り、じゃぁ、ld.so.confについてはと聞くとそれはOSですやん、と宣った。

仕方がないので、自力で対応することに。。。

まず、PHPの公式マニュアルに従ってLD_LIBRARY_PATHを認識させる方法を試す。
ところが、/etc/sysconfig/httpdとenvvarsではPHPまで届かない。。
最終手段でSetEnvしたところ、やっとPHPまでLD_LIBRARY_PATHが環境変数として渡った。
しかし、libclntsh.soのエラーは変わらずブラウザではPHPからoci8が起動できない。

それからググって出てきたことはひと通り試す。

Apache起動スクリプトに「export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/foo/var/hoge.so」
と書いてもダメ。
libclntsh.so.11.1をoci8.soと同じ所に置いてもダメ、
静的にコンパイルしても動的にコンパイルしても変わらず、
LD_LIBRARY_PATHのディレクトリのパーミッションをゆるめてもダメ、
Apache起動ユーザーのセカンドグループにoinstallを追加してもダメ、
LoadFileでlibclntsh.soを直接指定してもダメ。

とうとう万策尽きて、怒りのApache起動ユーザをnologinからbashにして無理やりスイッチ、
ldd oci8.soしたら、libclntsh.soが「not found」となっていて「ん？」
他にもrootで実行するlddと出力結果が違う。。

そこでやっとわかる。
今回、Oracleクライアントのインストール先をデフォルトに従って/home/oracleの下にした。
そのため、上位のフォルダの制限が強すぎてLD_LIBRARY_PATHが認識できなかったらしい。

対応としてOracleクライアントのインストール先を/optに変更したところ、
やっとブラウザからもoci8を認識するようになった。

Androidアプリ開発の実機テスト

Windows7でAndroidのアプリ開発中～。
SDKで動作確認には十分過ぎるエミュレータが提供されているけど、
ピンチイン・アウトやらシェイクやらはやっぱり実機でテストする必要がある。

SDKマネージャでつーっと「Google USB Driver」をインストールして、
実機のUSBデバックONにしたものの、さっぱり認識してくれない。。。

で、ググってみるとどうも「Google USB Driver」は
Google社のハードにしか対応していないような感じ。。
#ココらへん適当です。私の端末とか一部だけかも。。

で、どうやら各ベンダーで開発用のUSBドライバーを
提供しているようなのでそちらをダウンロードして適用したら
すんなりと認識してくれた。

TortoiseSVNでコミット失敗

管理しているSVNサーバでコミットできなくなったとヘルプ要請があった。
TortoiseSVNで下記のエラーが出てコミットできなくなったとのこと。

コマンド: コミット
追加中: [クライアントフォルダ]\[対象フォルダ]
エラー: コミットに失敗しました (詳しい理由は以下のとおりです):
エラー: Cannot verify lock on path '[対象フォルダ]/[アップ対象ファイル]'; no matching
エラー: lock-token available
エラー: ロックを強制解除する場合は、「変更をチェック」ダイアログかリポジトリブラウザーを使用してください。
完了:

とりあえず素直にメッセージに従って対応したら？と伝えたが、
新規ファイルのコミットで失敗したので、対象のファイルがまだサーバになく、
手も足も出ないということだった。

エラーメッセージでググってなんとか英語のソースを読むとバッチリ答えが。
サーバにログインして下記コマンドを打って対象ファイルがロックされていることを確認。
svnadmin lslocks [リポジトリフォルダ]
んで、下記コマンドでロックを解除
svnadmin rmlocks [リポジトリフォルダ] [対象フォルダ]/[アップ対象ファイル]
それで無事にコミットできるようになったとさ。

KVMでUUID云々が原因でドメインを復元できない

今対応している案件について開発機は仮想OSで構築中。
ハイパーバイザに指定はなかったので今回全サーバLinuxなのもあって
KVMで構築することになった。

構築中、libvirtをアップデートしたり、仮想OSを作り直したりしているうちに
下記のエラーが出て仮想OSが起動できなくなった。

failed: cannot restore domain '[ホスト名]' uuid [UUID] from a file which belongs to domain '[ホスト名]' uuid [UUID]

あー直前に作った仮想OSのデータがゴミになって残ったかなと
UUIDを書き換えたり、仮想OSを再作成したりしても消えない。。

最後にエラーメッセージからググって下記のページを参考にした。
spectlog.com

そして、上記ページの通り下記コマンドで無事に復旧。
virsh managedsave-remove [ホスト名]

何というか、ドメインが復元できませんエラーは大抵managedsave-remove
でなんとかなる。

東京から北海道 大洗発か新潟発か

東京から愛車に乗って北海道ツーリングに行く場合、フェリーに乗ることになる。
二回くらいは大洗からのフェリーに乗っていたけど、
北海道で出会ったおっちゃんライダーに勧められて、
最近は新潟発のフェリーを利用している。
ちゃんと考えずになんとなくお得なんだろうと思って使っていたけど、
今回北海道ツーリングに行くにあたってそれぞれのメリットを整理したので、メモ。


◆新潟発のフェリー(新日本海フェリー)のメリット

①運賃が安い
   →(人間の分は船室によるので置いておいて)バイクの運賃は
      排気量にもよるけど 新日本海フェリーの方が5000～6000円近く安い。
      関越道の高速料金を差っ引いても新潟発の方が往復で5000円は安くなる。

②新日本海フェリーの方が船内レストランの方がコスパ良い
   →どっちも船内レストランは美味しいけど、新日本海フェリーは
      地上とほとんど変わらない値段で提供している。
      乗船前にコンビニとかで買ってくる人が多いけど、
      私は新日本海フェリーでは必ず船内レストランで
      暖かい食事をいただいている。


◆大洗発のフェリー(商船三井)のメリット

①便数が多い
   →ほぼ毎日運行していて、しかもオンシーズンは1日2便ある。
      対して新潟発の新日本海フェリーは週休一日で一日1便なので、
      予定が噛み合わないことがある。

②東京から近い
   →これがすごく重要。東京から大洗は高速を普通に走って2時間ちょっと。
      対して新潟は高速を普通に走ると6時間弱。。
      体力の有無を考えなくとも行きに無駄に体力を使いたくないし、
      帰りは疲れているしでこの差は大きいと思う。

      しかも新日本海フェリーは朝10時出港なので、
      東京からは深夜に出発しないと間に合わないのでしんどい。。
      さらにどっちも航海時間は同じくらいなんだけど新日本海フェリーの便数の少なさも
      相まって新潟から出発すると一日がどっか行った気分になる。。


まとめると、体力と時間に余裕があるなら新潟発。お金に余裕があるなら大洗。

hpマシンのLinuxサーバでLAID構成を確認

ドキュメントの足りないサーバのHW構成を調査する時、
大体LAID構成が最後までわからないことが多い。
今日は故障したHDDの交換に立会い、コマンドを教えてもらったのでメモ。

まず、OSにログインしてACUを立ち上げる。
#hpacucli

で、ACUモードで下記コマンドを実行するとLAID構成が分かる。
=>ctrl slot=0 ld all show

物理的な一覧を表示させるとホットスペアがあるかないかも分かる。

=>ctrl slot=0 pd all show
  →spareとついているHDDがあればそれがホットスペア。
     ちなみにactiveとなっていると壊れたHDDのスペアとして稼働している。

ちなみにLAID5でサーバを組むときはホットスペア前提で考えたほうが良い。
LAID1だとホットスペアは本当にただのスペアでしかないけど、
LAID5の場合は壊れた時に下記のメリットがある。

1.HDD復旧時のリビルドが早い。
  →LAID5構成でホットスペアなしの場合、故障HDDを交換して
     リビルドすると正常HDDからハッシュを計算しつつリビルドするため、
     すごく時間がかかる。
     ホットスペアがあればすでに計算済みのハッシュがホットスペアに
     逃げているため、それをそのままコピーするだけ。
     なので圧倒的に早い。

2.データの損失を防げる。かもしれない。
  →HDD起因でデータがロストしたと聞けば、まずLAID5構成のマシンだ。
     以前後輩が故障したHDDを交換してリビルドが80%までいったところで
     マシンがダウンし、再度マシンを起動したところデータが全損していたことがあった。
     考えられる原因は正常HDDにエラーデータが蓄積しており、
     そこからリビルドのためハッシュを計算させたところデータの整合性が
     とれずに壊れたのではないかとのこと。
     ホットスペアがあればハッシュを逃がすことができたので、防げたかもしれない。
     まぁ、後はこまめに再起動していればデータの整合性チェックもできたかもしれない。
     RAID5構成は敬遠されがちだけど、OSのこまめな再起動とホットスペアが
     できるなら十分運用できると思う。

KVMとClonezillaでP2V

老朽化した社内開発サーバの移行を実施したのだけど、
ドキュメントが全くなく試行錯誤したものの新しいサーバ上への再構築を断念。
新しいサーバに仮想環境としてまるっと移すことにした。
最初、P2Vでググったら「virt-p2v」というソフトがヒットしたけど、
開発が終了しているようで配布も終わっていたのですぐにやめた。
次にddコマンドで流し込もうとしたものの上手く行かず、
同期から勧められたclonezillaを使ったらビックリするくらいすんなりいった。

下記はその手順。

移行元：CentOS5
移行先：CentOS6
2つのサーバは同じネットワークにいるものとする。

1.OSインストール(移行先サーバ)

① 言語

Japaneseを選択

② キーボード

日本語を選択

③ ストレージデバイス

基本ストレージデバイスを選択

④ ホスト名

ホスト名とeth0のIPアドレスを設定

⑤ タイムゾーンの選択

アジア/東京

＋ システムクロックでUTCを使用にチェックを入れる

⑥ rootパスワード設定

※省略

⑦ パーティション設定

すべての領域を使用するを選択

＋ システムの暗号化はチェックしない

＋ パーティションのレイアウトの再確認と変更をチェック

デバイスは2つともインストール先デバイスにする

・ boot用RAIDパーティションを作成(sda)

＋ 作成ボタンをクリック

＋ RAIDパーティションを選択して作成

＋ 使用可能なドライブにsdaだけを選択

＋ 将来のカーネルのアップデートを見越して200MB確保

＋ 固定容量(F) を選択

＋ 基本パーティションをチェックする

・ boot用RAIDパーティションを作成(sdb)

＋ 作成ボタンをクリック

＋ RAIDパーティションを選択して作成

＋ 使用可能なドライブにsdbだけを選択

＋ 将来のカーネルのアップデートを見越して200MB確保

＋ 固定容量(F) を選択

＋ 基本パーティションをチェックする

・ /boot用RAIDデバイス作成

＋ 作成ボタンをクリック

＋ RAIDデバイスを選択して作成

＋ マウントポイントを/boot

＋ ファイルシステムはext4

＋ RAIDデバイスはmd1

＋ RAIDレベルはRAID1

＋ RAIDメンバーはにsda1とsdb1をチェック

＋ OK

・ LVM用RAIDパーティションを作成(sda)

＋ 作成ボタンをクリック

＋ RAIDパーティションを選択して作成

＋ 使用可能なドライブにsdaだけを選択

＋ 最大許容量まで使用

＋ OK

・ LVM用RAIDパーティションを作成(sdb)

＋ 作成ボタンをクリック

＋ RAIDパーティションを選択して作成

＋ 使用可能なドライブにsdbだけを選択

＋ 最大許容量まで使用

＋ OK

・ LVM用RAIDデバイス作成

＋ 作成ボタンをクリック

＋ RAIDデバイスを選択して作成

＋ ファイルシステムはLVM

＋ RAIDデバイスはmd2

＋ RAIDレベルはRAID1

＋ RAIDメンバーはにsda2とsdb2をチェック

＋ OK

・ ボリュームグループ作成作成

＋ 作成ボタンをクリック

＋ LVMボリュームグループを選択して作成

＋ 追加

＋ ファイルシステムをswap

＋ サイズを4000MB

＋ 追加

＋ マウントポイントは/

＋ ファイルシステムをext4

＋ サイズを残り全部

・ GRUBを/dev/md1にインストール

⑧ デフォルトインストール

Virtual Host

＋ 今すぐカスタマイズするにチェックする

- リポジトリの選択

デスクトップ

＋ XWindowSystemにチェック

＋ デスクトップにチェック

2.一般ユーザ作成(移行先サーバ)


3.yum update(移行先サーバ)

4.ネットワーク設定(移行先サーバ)

①eth0設定
# system-config-network
> デバイス設定⇒eth0
> 下記のとおり設定
 ***.***.***.***
 ***.***.***.***
 ***.***.***.***
> ok⇒保存⇒保存して終了

②br0設定
# cp -p /etc/sysconfig/network-scripts/ifcfg-eth1 /etc/sysconfig/network-scripts/ifcfg-br0
# vi /etc/sysconfig/network-scripts/ifcfg-br0
> 下記の通り記載
 DEVICE=br0
 TYPE=Bridge
 BOOTPROTO=none
 IPADDR=***.***.***.***
 BROADCAST=***.***.***.***
 GATEWAY=***.***.***.***
 NETMASK=***.***.***.***
 NETWORK=***.***.***.***
 ONBOOT=yes
 IPV6INIT=no
 USERCTL=no

③設定適用
# service network restart


5.バックアップ取得(移植元サーバ)

①clonezillaでCDブート
>Clonezilla live⇒日本語⇒キーマッチをいじらない⇒ディスク/パーティション⇔イメージ⇒sshサーバをマウント⇒[sshfs先に構築サーバの情報を入力]⇒[移植元サーバのIPを入力]⇒savedisk⇒実行

②作業後シャットダウン

6.移植元サーバ仮想化(移植先サーバ)

① ClonzillaのCDをマウント

② GUIで仮想マシンマネージャ起動

> アプリケーション⇒システムツール⇒仮想マシンマネージャ

> ホストを右クリックして新規

> 設定は基本的にデフォルト

   起動はclonezillaを選択

   ディスク容量は適当に指定

③ clonezillaでリカバリ

> Clonezilla live⇒日本語⇒キーマッチをいじらない⇒ディスク/パーティション⇔イメージ⇒sshサーバをマウント⇒[sshfs先に移植先サーバの情報を入力]⇒[自サーバのIPを入力(移植元サーバのでいい)]⇒restoredisk⇒実行