Logical Rabbit.

さくらのVPS

Linux

ConoHaのownCloudとオブジェクトストレージでオンラインストレージを作る(前編)

ConoHa VPSに標準で用意されているownCloudアプリケーションサーバーとConoHaオブジェクトストレージを組み合わせて、Windows PCから同期可能なオンラインストレージを作る試み。まずはowncloudを起動するまで。

[2015.12.10] 追記

後編 も書きました。

レシピ

VPSとオブジェクトストレージを契約

  1. 清楚可愛いこのはちゃんと契約する
  2. 言語モードを「このは」にする(重要!)
  3. ConoHaチャージ(月額で最低金額1500円くらいかな)またはクレジットカードを登録する
  4. ConoHa VPSは次の仕様で組んでみた
    • vCPU 1個
    • メモリ1GB
    • 東京リージョン
    • イメージタイプは「アプリケーション」を選択(初期値)
    • アプリケーションは「その他」から「ownCloud」を選択、バージョンは8-x64固定
      • なお、ベースになっているOSは CentOS release 6.7 (Final) カーネルは 2.6.32-573.7.1.el6.x86_64 でした (2015.12.06現在)
      • owncloud自体は 8.1.3 がinstalled、yumで 8.1.4 が来ていますね(後程アップデートしませぅ)
    • rootパスワードをセット
    • 自動バックアップはお好みで。今回はアプリケーションサーバーとしてのみ使用するので、変更した設定さえ別途保管しておけば全体バックアップは不要かも。
    • ディスク容量は最低のSSD50GBで十分。これでも多いかも?
      • インストール後の空き容量は / が 51GB割り当て、47GB空きなのでがら空き…
    • 準備が整うまでは色々危ないので、取り敢えず接続許可ポートはすべてOff(コントロールパネルのブラウザコンソールで作業する)。なお、ここのポートはConoHa VPS外部のファイアウォールらしく、VPS側でSSHポートを22番以外にした場合は「すべて許可」一択となる。
    • SSHキーはお好みで新規作成するなり、手持ちをセットするなり
    • ネームタグもお好みで

あとは料金を確認して「追加」ボタンを押し、準備が整うまでこのはちゃんのお姿を堪能して待ちませぅ。

コンソールを開いてVPSの初期設定

  1. 左側「サーバー」から目的のサーバーを見つけ、ネームタグをクリック
  2. 「コンソール」アイコンをクリック(新しいWebブラウザ画面で仮想コンソールが開く)
  3. 画面が真っ暗ならEnterとか押してみる
  4. 作業アカウントを作る
    • rootで作業すると失敗が致命的になるし、rootでのSSHログインは拒否しておきたいので、通常作業するための作業アカウントを作り、sudo権限を与える
    • [注意!] ConoHaのコントロールパネルでセットした公開鍵は、rootアカウントに紐付けられています(/root/.ssh/authorized_keysに書き込まれる)。作業アカウントは別途キーを準備するなり、rootからキーを奪ってくるなりしましょう(rootのキーを移動した場合はパーミッションとオーナーに注意)。
  5. /etc/ssh/sshd_config を開いて編集
    • 「Port 22」のコメントアウトを外し、22番以外の未使用ポートに変更 (ポート22狙いのアタッカーが回避できます)
    • 「PermitRootLogin」を「no」に変更 (SSH経由でのrootログイン不可)
  6. /etc/sysconfig/iptables を開いて編集 (空だった)
    • -A INPUT -m state --state NEW -m tcp -p tcp --dport <SSH port> -j ACCEPT を追記
    • (owncloudのWeb画面を開くために)-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT を追記
    • あとはお好みで。基本的に全部 REJECT してホワイトリストのポートだけ ACCEPT すれば良いかと。
    • この辺りのことは覚えたところで、どうせ CentOS 7になればfirewalldに代わって役に立たなくなりますよ… (今回firewalldを探して10分くらい彷徨った…)
  7. sshdとiptablesを(再)起動
    • $ sudo service sshd restart
    • $ sudo service iptables restart
  8. ConoHaのコントロールパネルの「ネットワーク情報」をプルダウンさせ、「接続許可ポート」で「すべて許可」を選択(以後、ポートアクセス制御はVPS側のiptablesに委任)
  9. お好みのターミナルエミュレーターから接続できることを確認 (以降はターミナルエミュレーターから作業)
    • 念のため、rootでログインできないことも確認しませぅ
    • さらに念のため、ConoHaコントロールパネルのWebブラウザコンソールからはrootでログインできることを確認しませぅ
  10. 適当なタイミングで sudo yum upgrade でも打って最新環境にするべし

ownCloudの設定

  1. コンソールにログインするとwelcomeメッセージとして URLやらMySQLのパスワードやらが表示されるので、URLにアクセスする。
  2. 管理者アカウントを作成する
  3. 試しに適当なファイルをアップロードしてみる

たぶん通常アカウントを作って、そっちで使ったほうが良い…いや所詮プライベートストレージだからこのままでもいいか…な?

なおアップロードしたファイルは /var/www/html/owncloud/data/<アカウント名>/files/ に収まる様子。 (/var/www/html/owncloud/data/ 以下はapacheユーザー/グループ管轄、otherにアクセス権無し)

残項目

  • HTTPSアクセスにしたほうが良い気がするぞ
  • ポートをガチガチに塞ぎ過ぎてメールアラートも出なくなってるので、必要なポートを開けたい
  • ていうかちゃんとドメイン割り当ててメールサーバーも設定しておこう
  • 本題であるWindowsとの同期とオブジェクトストレージの使用はどうした

[2015.12.08] 追記

yum upgrade したのち reboot してそのまま気持ちよく作業を終えたところ、数日経ってからアクセスしたら owncloud がメンテナンスモードに入ってしまっているという仕打ちが発生。モード解除自体は /var/www/html/owncloud/config/config.php 内の ’maintenance’ を false にすればOKだったのだけど、なんでメンテナンスになったんだ…。しかも画面には「owncloudを再起動すれば解除されます」とある割に、 httpd をリスタートしても何も変わらんかったし。

もしかして yum upgrade で owncloud 自体が 8.1.3 から 8.1.4 にアップデートされたので、このタイミングで自動的にメンテナンスモードになるんですかね…?

あと数日放置してたら、案の定 httpd にアタッカーの皆さんからご訪問を受けておりました。幸い突破された様子は無かったけど、一度アクセス範囲を見直したほうが良さげ。

[2015.12.10] 追記

後編 に続く…!

CentOSを使用したリモート操作についての備忘。

CentOSで他のマシンをリモート操作することに関するメモ。必要に応じて追記されていると思われ。

コマンドプロンプトから他のマシンを起動する (Wak on LAN)

ether-wake <MAC address>

実行にはroot権限が必要。

CentOS 7 だと標準で導入されているっぽい? うちでは主要マシン向けに以下のようなシェルスクリプト書いてあります。(sudoで実行して機動確認のためにpingを打ちつづける)

#!/bin/sh

sudo /usr/sbin/ether-wake <MAC address>
ping <IP address>

リモートデスクトップ接続

EPELの xrdp パッケージ ( http://xrdp.sourceforge.net/ ) を導入します。

xrdp.x86_64 : Open source remote desktop protocol (RDP) server

以下のようなシェルスクリプトを書いておくと便利。この例ではフルHDモニタいっぱいに表示します。また、起動後コンソールを占拠されるのが嫌なのでバックグラウンドに回しています。

ポート番号は標準のままならば指定不要。うちの場合ブロードバンドルーターを介してINTERNETから繋ぐので、アタック対策も兼ねてポート番号を適当に割り当てています。としてINTERNET側のIPアドレスを指定、として割り当て済みの番号を指定すると、ルーター内でイントラ側の特定Windowsマシンに転送する次第。

#!/bin/sh

rdesktop -g 1920x1080 <IP address>:<port> &

開発作業環境について考えをまとめてみる 2015。

開発作業スペース 兼 プライベートgitリポジトリを新規確保したいのだけど、有料プランでいくつか選択肢があるのでどれにするか検討した次第。

この手のものは定期的に再検討しないと状況が変わってきたりすることと、今後開発業務の副業を本格化していく見込みで、作業スタイルを見直す必要があるため。

目的・用途

  1. 開発作業スペース
    • やりっぱなしにできると便利 = 常時稼働
    • (常時稼働の場合)そこそこ安心感のある自動バックアップ体制
    • とはいえきちんと作業してまめにリポジトリへcommitすれば、作業の区切りで初期化しても問題ないはず
  2. git リポジトリ
    • 常時稼働
    • そこそこ安心感のある自動バックアップ体制
  3. リリース前テスト環境
    • 開発作業スペースから独立したクリーンな環境が望ましい
    • VMで構築して都度初期化したほうが確実かも = VM稼働環境が必要

候補とその利点・欠点

候補 利点 欠点
レンタルサーバー(VPS or クラウド or 物理) 開発環境+gitリポジトリ (初期費用合わせて)1000円くらい/月
自宅サーバー 開発環境+gitリポジトリ+VM稼働環境 初期費用大きい、電気代かかる
githubの有料プラン 比較的安価 開発環境は置けない
Amazon EC2 開発環境+リリース前テスト環境。使わないとき止めておけば安価? EC2止めてもEBS料金は発生。連続稼働だとやはり高め。

試算

2コア、メモリ2GB、50GB ディスク程度を目安とする。1ドル=123円として計算。

候補 試算 備考
さくらのVPS 初期費用1500円+900円/月 2コア、メモリ1GB、HDD 100GB
ConoHa 900円/月 2コア、メモリ1GB、SSD 50GB
GMO VPS クラウド 初期費用4000円+934円/月 3コア、メモリ2GB、HDD 100GB
自宅サーバー 2,000円/月 ハードウェアはあるので電気代
github有料プラン(micro) $7/月 ≒ 861円/月 開発環境は別に必要
Amazon EC2 ( EC2常時稼働 ) $23.04/月 ≒ 2,833円/月 t2.micro + 50GB HDD EBS
Amazon EC2 ( EBSを永続 ) $4/月 ≒ 492円/月 50GB HDD、別途開発環境使用時にはEC2の代金もかかる
Amazon EC2 ( S3にアーカイブ ) $4.75/月 ≒ 585円/月 50GBで計算しているが実際にはもっと少なくなるはず

まとめ (まとまらない)

やっぱりVPSを借りてしまった方が楽か、はたまたそれほど頻繁には使用しないと見越してEC2でやるか、といったところか。しかし頻繁に使用しないなら自宅サーバーで良い気もしてくる。電気代2000円/月は多めに見積もっているので、実際はもっと少ないはずだし。EC2で始めて結局連続稼働時間が長くなったりすると負け確定になる。

リリース前テスト環境は頻繁・長時間使用するものではないはずなので、EC2環境で良いと思う。

技術習得というところから考えると、敢えてEC2+github有料プランというところ。金額的な面で現実的なのはConoHa VPS + github有料プランあたりと結論づけたい。

結局

EC2で毎回初期化・運用環境を整えたほうが検証がやりやすいので、小規模な確認作業はEC2でやるようになってきた。後はいかに手早くかつ手をかけずに必要な環境を整えるか、というところだけど、なんかそういう技術は既にあった気がしている。今のところ手動でも数分で終わるセットアップなので、手を出すには大仰すぎるけど。

MediaWiki:: Botのテストが失敗する件 (t/29-get_log.t)

t/18-is_blocked.t とともにエラーになる MediaWiki-Bot-5.006002 の t/29-get_log.t についての調査結果。結果は脱力感全開。

元ソースは以下。

https://github.com/MediaWiki-Bot/MediaWiki-Bot/blob/master/t/29-get_log.t

  • 実行結果として期待する内容(変更ログ)は2件を指定しているが、実行時に「limit=1」を指定しているため最新の1件しか得られない(limit=2とすると期待通りの内容が得られる)
  • 実行結果として得られるログには params という項目があるが、テストとして期待する内容には無いので不一致になる

…paramsが無いというのは、まあ仕様の変更に追いついていないのだろう、とは思うのだけど、なんでlimit=1を指定しておきながら2件の結果を期待しているんだろう…?

MediaWiki:: Botのテストが失敗する件 (t/18-is_blocked.t)

依頼されて MediaWiki::Bot 5.006002 をインストール中なわけですが、t/18-is_blocked.tとt/29-get_log.tが自動テストに失敗する。で、まずはt/18-is_blocked.tの調査。

元ソースは以下。

https://github.com/MediaWiki-Bot/MediaWiki-Bot/blob/master/t/18-is_blocked.t

問題の箇所(line 38)は、先行する line 31で決定された$resultの評価をしており、どうやらブロックされたユーザーについてAPIで問い合わせ、「ブロックされているぞ!」という答えを期待しているらしい。

line 31; my $result = $bot->is_blocked('User:Hiwhispees');

しかし、問い合わせに行っている test.wikipedia.org には “Hiwhispees” というユーザーは見当たらず、代わりに “Hiwhispees~testwiki” がいらっしゃる。しかもブロックされて。

…こっちぢゃねぇの…?

MediaWiki::Botのソースを読んで本来呼び出していると思われるURLを特定し、APIをじかにひっぱたいて見ると、やっぱり “Hiwhispees” だと結果が空、"Hiwhispees~testwiki" だと中身がある。

で。

t/18-is_blocked.t のline 31を “Hiwhispees~testwiki” に変えて make test してみたところ、あっさり通りましたとさ。

ぐぬぬ。

LWP::Protocol::https の upgradeが失敗する…。

問題が起きているのは、 perl v5.10.1 (*) built for x86_64-linux-thread-multi に同梱されている(たぶん。他の作業でインストールはしていない筈)無印の LWP::Protocol::https を、現時点最新の6.06にアップグレードする際。

自動テストの t/apache.t で、https://www.apache.org/ にアクセスしようとして失敗するらしく、以下のようなエラーとなる。

cpan[1]> upgrade LWP::Protocol::https
(略)
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/apache.t ....... 1/5 
#   Failed test at t/apache.t line 15.

#   Failed test at t/apache.t line 18.
#                   'Can't connect to www.apache.org:443 (certificate verify failed)
# 
# LWP::Protocol::https::Socket: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/local/share/perl5/LWP/Protocol/http.pm line 47.
# '
#     doesn't match '(?-xism:Apache Software Foundation)'
t/apache.t ....... 4/5 # Looks like you failed 2 tests of 5.
t/apache.t ....... Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/5 subtests 
(略)

同じOS上でwget “https://www.apache.org/”すると成功するので、OSレベルでブロックされているわけではなかった。

Google検索してみると他でもエラーが出ているようだし、何より CPAN Testers で結構エラーがでているんですが…。
CPAN Testersのレポート見るとどうやらperlバージョンにかなり依存している様子。他の記事も合わせて考えると、証明書関連のミスマッチかな、という印象も。となると実使用では環境が変わる可能性も高そう。

というか、このライブラリをインストールする主目的の作業では、HTTPS関係ないのじゃ…?とも思えてきた。

ということで、とりあえず t/apache.t のエラーになるテスト箇所をコメントアウトして逃げることにする。

まず cpanコンソールから look でコンパイル環境に入り、テストコードを編集。

cpan[2]> look LWP::Protocol::https

元のソース から

  1. line 13~18までをコメントアウト
  2. line 11 のテスト数を 5 から 3 に変更
  3. line 13で $res を宣言しつつ使用しているので、コメントアウトによってこの変数が初出となる line 24 で宣言するよう($res →my $res)に変更

以上3つの変更を実施(以下は変更後)。

#!perl -w

use strict;
use Test::More;

use LWP::UserAgent;

my $ua = LWP::UserAgent->new();
plan skip_all => "Not online" unless $ua->is_online;

plan tests => 2;
#plan tests => 5;
#
#my $res = $ua->simple_request(HTTP::Request->new(GET => "https://www.apache.org"));
#
#ok($res->is_success);
#my $h = $res->header( 'X-Died' );
#is($h, undef, "no X-Died header");
#like($res->content, qr/Apache Software Foundation/);

# test for RT #81948
my $warn = '';
$SIG{__WARN__} = sub { $warn = shift };
$ua = LWP::UserAgent->new( ssl_opts => {verify_hostname => 0} );
my $res = $ua->simple_request(HTTP::Request->new(GET => "https://www.apache.org"));
ok($res->is_success);
is($warn, '', "no warning seen");

$res->dump(prefix => "# ");

その場でmake testしてパスできることを確認。

# make test
(略)
All tests successful.
Files=2, Tests=58,  2 wallclock secs ( 0.03 usr  0.01 sys +  0.44 cusr  0.04 csys =  0.52 CPU)
Result: PASS

cpanに戻り、改めて upgrade を実行。

cpan[3]> upgrade LWP::Protocol::https

Package namespace         installed    latest  in CPAN file
LWP::Protocol::https          undef      6.06  MSCHILLI/LWP-Protocol-https-6.06.tar.gz
1 installed module has no parsable version number
(use 'o conf show_unparsable_versions 1' to show them)
Running install for module 'LWP::Protocol::https'
Running make for M/MS/MSCHILLI/LWP-Protocol-https-6.06.tar.gz
  Has already been unwrapped into directory /root/.cpan/build/LWP-Protocol-https-6.06-sQInrv
  Has already been made
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/apache.t ....... ok   
t/https_proxy.t .. 1/56 # creating cert for direct.ssl.access
# creating cert for direct.ssl.access
# creating cert for foo
# creating cert for bar
# creating cert for foo
# creating cert for foo
# creating cert for bar
# creating cert for bar
t/https_proxy.t .. ok     
All tests successful.
Files=2, Tests=58,  2 wallclock secs ( 0.03 usr  0.01 sys +  0.53 cusr  0.04 csys =  0.61 CPU)
Result: PASS
  MSCHILLI/LWP-Protocol-https-6.06.tar.gz
  /usr/bin/make test -- OK
Running make install
Prepending /root/.cpan/build/LWP-Protocol-https-6.06-sQInrv/blib/arch /root/.cpan/build/LWP-Protocol-https-6.06-sQInrv/blib/lib to PERL5LIB for 'install'
Installing /usr/local/share/perl5/LWP/Protocol/https.pm
Installing /usr/local/share/man/man3/LWP::Protocol::https.3pm
Appending installation info to /usr/lib64/perl5/perllocal.pod
  MSCHILLI/LWP-Protocol-https-6.06.tar.gz
  /usr/bin/make install  -- OK

cpan[4]> 

どっとはらい。

cpanで Net::SSLeayをインストールしたのですが。

「openssl-develが無いよ」という事象に起因するエラー内容が

SSLeay.c:13975: error: expected ‘{’ at end of input
make: *** [SSLeay.o] Error 1

なのってなにか納得がいかないですね…。一体中で何が起こっているんだろうか…。

ヘッダファイルで定義されるプリプロセッサが仕事しなくてみょんなマクロが組みあがってしまっている、とか?

ともあれ yum install openssl-devel すれば解決はするわけですが。

エラーメッセージでググって出てきたのは stackoverflow のページ でした。

cpanでreadlineを使いたい場合

cpanプロンプトでうっかりカーソルキーを押してしまってコントロールコードが入るのが鬱陶しい…というかそのせいで妙な誤動作をしてしまうのが怖いので、readlineに対応できないのかとグーグルさんに伺った所以下の記事が見つかりました。

ReadLine で CPAN を便利に – はちゅにっき

Term::ReadLine::Gnu をインストールすれば幸せになれるようです。

インストール要件

  • ncurses, ncurses-devel, readline, readline-devel

(Term::ReadLine::Gnuをインストールする時点でncurses、readlineは導入済みだったため、必須か否かは未確認です。が、develを入れるなら実行モジュールも入れてしまえばいいと思う)

インストール時のエラーによると、ncursesのほか libtermcap.a でも良いようです。ncurses-develはrubyコンパイル時にも使用するので、こちらを選択しました。

cpan>プロンプトはreadline対応しますが、インストール時の依存性解決で

Shall I follow them and prepend them to the queue of modules we are processing right now? [yes]

と聞いてくるあたりはやっぱりダメみたい。割とここで余計なキー入力してしまうのですが…。

インストールログ

$ sudo yum install ncurses ncurses-devel
$ sudo yum install readline readline-devel
# cpan

cpan[1]> install Term::ReadLine::Gnu
 (省略)
CPAN: File::Temp loaded ok (v0.22)
 (省略)
  CPAN.pm: Going to build H/HA/HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz
 (省略)
Checking if your kit is complete...
Looks good
 (省略)
  HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz
  /usr/bin/make -- OK
Running make test
 (省略)
Result: PASS
  HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz
  /usr/bin/make test -- OK
 (省略)
Running make install
 (省略)
  HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz
  /usr/bin/make install  -- OK
 (省略)
CPAN: Term::ReadLine::Gnu loaded ok (v1.26)
.....................
21 subroutines in Term::ReadLine redefined

pfsenseをgatewayとした多段ssh。

ざっくり言うと、pfsenseのSSHログインを有効化+ProxyCommand+nc、といった具合。

[localhost(on the Internet)] -->[pfsense server] -->[target server(on the private network)]

参考にしたサイト

やりかた

pfsenseの設定

  1. pfsenseの管理画面にログイン、System >Advanced >Admin Access >Secure Shellに移動
  2. [Enable Secure Shell]をOnに
  3. 安全のため[Disable password login for Secure Shell (RSA/DSA key only)]をOnに
  4. [SSH port]を適当に指定(仮に114114とでもしておこうか)
  5. 以上でSave
  6. System >User Managerへ移動、Add Userを実行
  7. 冒頭のイメージ図で[localhost(on the Internet)]から[prsense server]へ接続するためのユーザを作成、Save
  8. 作成したユーザの編集画面を開き、[Effective Privileges]に[User - System - Shell account access]を追加
  9. [Authorized keys]にの公開鍵を追記
  10. 以上でSave
  11. Firewall >Rulesに移動、Rule追加を実行
  12. [Destination]を[WAN]に、[Destination port range]に114114を指定
  13. 以上をSaveし、さらにApply change実行

pfsenseの設定は以上で完了。必要に応じ[localhost(on the Internet)]から[pfsense server]にsshログインできることを確認。

クライアント・サーバー(接続先)の設定

  1. [localhost(on the Internet)]の公開鍵を[target server(on the private network)]の.ssh/authorized_keysに登録
  2. .ssh/configを以下のように記述
    Host gateway
    HostName pfsense_server
    Port 114114
    Host target
    HostName target_server
    ProxyCommand /usr/bin/ssh gateway /usr/bin/nc %h %p
    

.ssh/authorized_keys、.ssh/configのパーミッションには注意すること。

以上を実施のうえ、次のようにsshコマンドを実行することで[pfsense server]を介して[target server(on the private network)]に接続できるようになる。sshの他scp、sftpも使用可能。

[localhost(on the Internet)]$ ssh target_server

alternativesでslaveに指定し忘れた項目があった場合。

特にたくさんの --slave を指定していた場合、一度削除して再登録するのがめんどうくさい。

alternativesシステムの構造を調べて、手動で対策できたのでメモ。

例: ソースコードからインストールしたPostgreSQLを /usr/bin に配置したい。が、pg_ctlを --slave に含め忘れてしまい、postmasterが止まらなくなった orz

(やだなぁ、あくまで例ですよ?)

一連のコマンド群を配置した際の実行パラメータは、次のようになっていた(可読性優先のためコマンドラインオプションごとに改行しています)。

alternatives
 --install /usr/bin/postgres postgresql /usr/local/postgresql-9_3_4/bin/postgres 100
 --slave /usr/bin/postmaster postgresql-postmaster /usr/local/postgresql-9_3_4/bin/postmaster
 --slave /usr/bin/psql postgresql-psql /usr/local/postgresql-9_3_4/bin/psql
 --slave /usr/bin/pg_config postgresql-pg_config /usr/local/postgresql-9_3_4/bin/pg_config
 --slave /usr/bin/pg_dump postgresql-pg_dump /usr/local/postgresql-9_3_4/bin/pg_dump
 --slave /usr/bin/createdb postgresql-createdb /usr/local/postgresql-9_3_4/bin/createdb
 --slave /usr/bin/dropdb postgresql-dropdb /usr/local/postgresql-9_3_4/bin/dropdb
 --slave /usr/bin/initdb postgresql-initdb /usr/local/postgresql-9_3_4/bin/initdb
 --slave /usr/bin/vacuumdb postgresql-vacuumdb /usr/local/postgresql-9_3_4/bin/vacuumdb
 --slave /usr/lib64/postgresql postgresql-lib /usr/local/postgresql-9_3_4/lib

当初はねー、主に使うのはこのあたりのコマンドだけかなー、と思ってたですよ。

この場合のalternativesシステムデータの構造は次のようになっていた。

  1. /usr/bin/postgres (シンボリックリンク) は /etc/alternatives/postgresql を示す
  2. /etc/alternatives/postgresql (シンボリックリンク) は /usr/local/postgresql-9_3_4/bin/postgres (実体) を示す
  3. --slave 指定した /usr/bin/postmaster (シンボリックリンク) は /etc/alternatives/postgresql-postmaster (シンボリックリンク) を示す
  4. /etc/alternatives/postgresql-postmaster (シンボリックリンク) は /usr/local/postgresql-9_3_4/bin/postmaster (実体) を示す
  5. 以後、 --slave 指定のものは同様に /usr/bin (リンク) → /etc/alternatives/<名前> → <パス> のようになる

ここで問題なのが、 --install--slave の関係性、リンクに指定した優先度の情報はどこに行ったのか?、という点。特に優先度の情報が見えていない。

これらは /var/lib/alternatives に --install に指定した <名前> というファイル名で保存されていた。

/var/lib/alternatives/postgresql の内容は次のようになっている。

$ cat /var/lib/alternatives/postgresql 
auto
/usr/bin/postgres
postgresql-postmaster
/usr/bin/postmaster
postgresql-psql
/usr/bin/psql
postgresql-pg_config
/usr/bin/pg_config
postgresql-pg_dump
/usr/bin/pg_dump
postgresql-createdb
/usr/bin/createdb
postgresql-dropdb
/usr/bin/dropdb
postgresql-initdb
/usr/bin/initdb
postgresql-vacuumdb
/usr/bin/vacuumdb
postgresql-lib
/usr/lib64/postgresql

/usr/local/postgresql-9_3_4/bin/postgres
100
/usr/local/postgresql-9_3_4/bin/postmaster
/usr/local/postgresql-9_3_4/bin/psql
/usr/local/postgresql-9_3_4/bin/pg_config
/usr/local/postgresql-9_3_4/bin/pg_dump
/usr/local/postgresql-9_3_4/bin/createdb
/usr/local/postgresql-9_3_4/bin/dropdb
/usr/local/postgresql-9_3_4/bin/initdb
/usr/local/postgresql-9_3_4/bin/vacuumdb
/usr/local/postgresql-9_3_4/lib

1行目の auto …はまあ今回無視するとして、2行目に --install で指定した<リンク>、3行目以降に --slave で指定した <リンク>と<名前>が1行ずつ列挙されている。

また、一連の列挙の後1行空けて、 --install で指定した <パス>、<優先度>、 --slave で指定した <パス> が1行ずつ列挙されている。

ということで、指定し忘れた項目(この場合 pg_ctl )を手動で追加するには、次の手順となる。

  1. /var/lib/alternatives/postgresql の上段(1行目~空行まで)の末尾に以下を追記
    postgresql-pg_ctl
    /usr/local/postgresql-9_3_4/bin/pg_ctl
    
  2. /etc/alternatives/postgresql-pg_ctl という名前で usr/local/postgresql-9_3_4/bin/pg_ctl へのシンボリックリンクを作成
  3. /usr/bin/pg_ctl という名前で /etc/alternatives/postgresql-pg_ctl へのシンボリックリンクを作成
  4. alternatives —display postgresql で手動追加が反映されたことを確認(以下、結果)
    $ alternatives --display postgresql
    postgresql -ステータスは自動です。
    リンクは現在 /usr/local/postgresql-9_3_4/bin/postgres を指しています。
    /usr/local/postgresql-9_3_4/bin/postgres - 優先項目 100
     スレーブ postgresql-postmaster: /usr/local/postgresql-9_3_4/bin/postmaster
     スレーブ postgresql-psql: /usr/local/postgresql-9_3_4/bin/psql
     スレーブ postgresql-pg_config: /usr/local/postgresql-9_3_4/bin/pg_config
     スレーブ postgresql-pg_dump: /usr/local/postgresql-9_3_4/bin/pg_dump
     スレーブ postgresql-createdb: /usr/local/postgresql-9_3_4/bin/createdb
     スレーブ postgresql-dropdb: /usr/local/postgresql-9_3_4/bin/dropdb
     スレーブ postgresql-initdb: /usr/local/postgresql-9_3_4/bin/initdb
     スレーブ postgresql-vacuumdb: /usr/local/postgresql-9_3_4/bin/vacuumdb
     スレーブ postgresql-lib: /usr/local/postgresql-9_3_4/lib
     スレーブ postgresql-pg_ctl: /usr/local/postgresql-9_3_4/bin/pg_ctl
    現在の「最適」バージョンは /usr/local/postgresql-9_3_4/bin/postgres です。
    

…いやぁ、あくまで例デスよ?(汗)