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

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

参考にしたサイト

• HOWTO enable SSH access

  …しかしここの説明だとWAN側からのログインを有効にする方法が分からず手間取ったさ。

• How to Access pfSense Remotely Using SSH

  上記サイトと説明がかぶるのだけど、ここでFirewallのRule設定に言及があったので。まぁpfsenseの説明をよく読めば分かったことかも知れんけど。

• ２段階SSH接続を，ProxyCommandを使って一度のsshコマンドで接続する

• 多段 ssh / rsync するために ProxyCommand を使ってみる

• SSH_CONFIG (5)

やりかた

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

特にたくさんの --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 です。
   

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

xhci-hcd モジュールをアンロードしてからロードすれば回復するっぽい。ちぃ覚えた。

具体的には CentOS 6.5 でのお話。USB3.0 は後付けの玄人志向 USB3.0R-P2H2-PCIE。Groovyの UD-3000SA でHDDを繋いだあたりで期限を損ねてしまい、以後は他の接続実績のあるUSB HDDを接続しても認識しない状態に。

OSリセットすべし、という情報もあったけど、それは何か負けのような気がする…というか別のプロセスで長時間かかる md5sum チェックをしていたのでリセットするわけにもいかず。どーせ何かを再起動すればいけるんじゃね?　と色々あさった結論。

最初は usb_storage を再読み込みさせたけど、反応が変わらなかった。dmesgのエラーログを見ると、どうやらHUBあたりがエラーを起こしているっぽい。ていうかM/BのUSB2.0ポートは普通にUSBメモリとか認識するので、 usb_storage は悪くない、らしい。

usb_storage より下層の(ハード寄りの)部分ってなんだっけ？　と漁った結果、uhciとかohciとかそのあたりよね、と。それっぽい名前を lsmod で探したところ、 xhci-hcd が見つかった。

"xhci-hcd" の正体を確認すべくググると、正体どころか "Bug 717633 - USB3.0 harddisk not working with xhci_hcd module " なんて記事が出てきたので、内容読むまでもなくあぁこれぢゃね、等と。

再読み込みにあたり念のためアンロードしたけど、USBまわりなのでアンロードと同時にUSBキーボードとか色々使用不能に陥る可能性を危惧(作業はssh接続してたけど)。予め sudo -v で認証も突破した上で、連続実行するように仕向ける。

$ sudo modprobe -r xhci-hcd ; sudo modprobe xhci-hcd

その後 dmesg 見たら認識しなかったUSB HDDも無事認識してマウントできるようになってた。

色々あってOSが古いままの環境で、せめてbashだけをshellshockから回避したい。

CentOS 3.9のbashはバージョン2.5が最終。

ログインシェルなので単純にyum erase bash とかやると依存関係がバギバギ出てくる。なので上書きインストールで行く(ていうか最終目標はOSの入れ替えなので、ここであまり丁寧に作業して時間をとりたくない)。

ということで以下作業記録。

現在bash関連物品が入っている場所の確認。個々のファイルは見ていられないのでdirnameで端折る。

rpm -q --list bash|xargs -l -i dirname {} |uniq
/bin
/etc/skel
/usr/lib
/usr/share/doc
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/bashdb
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/complete
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/functions
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/loadables
/usr/share/doc/bash-2.05b/loadables/perl
/usr/share/doc/bash-2.05b/loadables
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/misc
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/scripts.noah
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/scripts.v2
/usr/share/doc/bash-2.05b/scripts
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/startup-files
/usr/share/doc/bash-2.05b/startup-files/apple
/usr/share/doc/bash-2.05b/startup-files
/usr/share/info
/usr/share/man/man1

現状のタイムスタンプを確認。

$ ls -l /bin/bash*
-rwxr-xr-x 1 root root 585908 May 30 2006 /bin/bash
lrwxrwxrwx 1 root root 4 Mar 2 2007 /bin/bash2 -> bash

$ ls -l /usr/share/info/bash*
-rw-r--r-- 1 root root 94034 May 30 2006 /usr/share/info/bash.info.gz

$ ls -l /usr/share/man/man1/bash*
-rw-r--r-- 1 root root 64921 May 30 2006 /usr/share/man/man1/bash.1.gz

最新版をビルド。bash 4.3にパッチまで当ててやっとshellshockが解消するので、パッチも全部当てる(正確には28まで当てればよかったはず)。

このとき上書きされるようにprefix、bindir、sysconfdirをいじる。基本的に/usr以下に入っているのに実行コマンドだけが /bin にあるのがいやらしい。

$ tar xfz bash-4.3.tar.gz
$ cd bash-4.3
$ for patchfile in `ls -1 ../bash43-*`; do echo $patchfile; patch -p0 < $patchfile; done
$ grep "#define PATCHLEVEL" patchlevel.h
#define PATCHLEVEL 30

$ ./configure --prefix=/usr --bindir=/bin --sysconfdir=/etc
$ make ; make check ; echo $?

0
$ ./bash --version
GNU bash, version 4.3.30(1)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

上書きインストールする。

$ sudo make install

インストール結果確認。

$ which bash
/bin/bash

$ bash --version
GNU bash, version 4.3.30(1)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ ls -l /bin/bash*
-rwxr-xr-x 1 root root 1832115 Oct 15 06:51 /bin/bash
lrwxrwxrwx 1 root root 4 Mar 2 2007 /bin/bash2 -> bash
-r-xr-xr-x 1 root root 6800 Oct 15 06:51 /bin/bashbug

$ ls -l /bin/bash*
-rwxr-xr-x 1 root root 1832115 Oct 15 06:51 /bin/bash
lrwxrwxrwx 1 root root 4 Mar 2 2007 /bin/bash2 -> bash
-r-xr-xr-x 1 root root 6800 Oct 15 06:51 /bin/bashbug
$ ls -l /usr/share/info/bash*
-rw-r--r-- 1 root root 486450 Oct 15 06:51 /usr/share/info/bash.info
-rw-r--r-- 1 root root 94034 May 30 2006 /usr/share/info/bash.info.gz

$ ls -l /usr/share/man/man1/bash*
-rw-r--r-- 1 root root 299110 Oct 15 06:51 /usr/share/man/man1/bash.1
-rw-r--r-- 1 root root 64921 May 30 2006 /usr/share/man/man1/bash.1.gz
-rw-r--r-- 1 root root 1817 Oct 15 06:51 /usr/share/man/man1/bashbug.1

man bash とか info bash の結果はちゃんと4.3が出てくるけど、旧バージョンのgzファイルが後々混乱の元になりそうなので、新バージョンの非圧縮ファイルをgzip圧縮したもので上書きしておく。

/bin/bash へのシンボリックリンクになっている/bin/shも、ちゃんとバージョンアップされた。

$ sh --version
GNU bash, version 4.3.30(1)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

/usr/share/doc/bash-2.05b は実害無いし面倒くさいので後で削除しよう(そして忘れる)。

どっとはらい。

O'Reillyで電子版出てた。

書籍版は持ってるし比較的薄くて軽めの本だけど、Nginxいじるときは必須アイテムだから今度書籍版を参照できないところでNginxをいじる必要に駆られたら買おう。

と言いながら記事が寂しいのでAmazonのアフィリエイトを置いてみるなど。

Apacheは歴史があって大抵のことには対応できるみたいだけど、同じ理由から設定ファイルが何だか複雑化して分かりにくいことも多々。あと、単一サーバーで複数ドメインを運用するときのバーチャルホスト設定が面倒とか、SGMLタグだから"/"がタグの/なのか値の/なのかで混乱してみたり。

ということで、最近HTTPサービスを立ち上げるときは積極的にNginxに切り替えています。こちらの方が同時大量アクセスに強いらしいし、Ruby on Rails等のフレームワークとも相性が良いらしいので。

Apacheが必要になるのって、今だとSubversionリポジトリを公開するときくらいのような気がしますよ…？

モジュールのロードに失敗してno screens となるとき

xorg-x11-drivers パッケージが入っているか確認する。

インプットメソッドの導入

ibus パッケージをインストール…だが他にも色々必要な感じだったので、とりあえず groupinstall で Japanese support を入れたほうが早いっぽい。(というか面倒くさくなってこれで済ませた)

あとはお好みのデスクトップを入れればOK。職場の環境はできるだけ軽くしたかったのでXfceを使っています。

前々からAtomコアの小型PCにLinuxつっこんで24時間運用とかやっていたのだけど、最近KVM用にCore i7機を仕入れたのと、Windowsマシンでも普段はメールとWebしか使わないのでいっそ余ったPCにLinuxデスクトップ構築すれば良いのでは？　と思い、改めて消費電力とか調べてみた次第。

後はまぁ、メール&Web用マシンは自宅PCよりVPSでも使ってたほうが安くないか？とか。

調査方法は、以前購入してたエコワット(T3T-R1)を接続して24時間程度連続稼働させて記録をとる、というもの。エコワット自体簡易計測なのはわかっているのですが、買い替えようにも結局一般向けの機材はどれも簡易計測だし、本格的なのに手を出すほどでも無いし…という感じで。

エコワットはエコワットで、本体を電源断しないとリセットできないっていう使いにくさがあるんですけどね…。電源断すると当然計測対象機器も電源断するので、連続稼働させたい機材には向かないし。

計測は24時間あたりは意識して記録してますが、後はわりといい加減で「気づいたとき」記録してる感じ。まぁ平均とって時間当たりの消費電力が同じくらいなら良いだろうと。

調査結果

	時間あたり消費電力(kwh)	1か月あたり消費電力予想(kw、1か月30日計算)	1か月あたり電気料金予想(円)
ASUS C60M1-I +8GBメモリ+3.5"HDD×1+200w電源	0.086	61.92	1,171
ASROCK H87 PRO4+core i7 4770 +GIGABYTE GV NX66256DP +32GBメモリ+3.5"HDD×2+500W電源	0.081	58.32	1,115

電源系とかの型番きちんと記録してませんが、一応世代的には200W電源のほうが新しいし、そもそも電力を喰う要因のＨＤＤとかメモリとかグラフィックボードが多いCore i7のほうが消費大きくなるはずなのですが…。さすが4世代Core i7と言うべきなのか。

どちらもほぼアイドリング状態でつけっぱなしにしてますし、これで何か作業させたら消費電力増えてくるのでしょうが、まぁ1000円/月くらいになりそうな感じです。Core i7のほうは元々物理PCでないとやりづらいKVMの運用ノウハウ習得用なのでまぁ自宅PCのまま使うとして、メール&Web用マシンとしてC60M1-Iのほうを24時間稼働させるなら、VPSで処理させておいて必要時にアクセスしたほうが安く上がりそう。

後は、以前動かしていたAtom 330の機体でどのくらいの消費電力になっているかですが、こいつそろそろファンとかが怪しげになってきたし、パワー的に使用に耐えられるか、という疑問も…。

さてはて、どうしたものか。

今本業のほうでKVMベースのVMを運用する仕事をやってるのですが、今までVMWareやWin7添付のVirtual PC、最近だとVirtualBoxは扱っていたものの、KVMはやってなかったので多々手間取ることに。

結論を言うとここ1週間ほどのたうちまわって仕事はほぼ終息したのですが、この手のものは日頃から弄っていないと忘れるのと、今後も似たような仕事をやる可能性が高そうだと思い、この機会に自宅サーバーを新規構築することにしたのでした。

当初導入しようと思ってたのは、仕事で使っているのと同系統のドスパラ製64GBメモリ搭載Monarchなのですが、予算的に厳しいのと自宅に余ってる部品かき集めると、このMonarchの半額くらいで32GBメモリマシンが組めそうだったので、パーツから組むことにしました。

構築目標：

• KVMによるVM複数台がそこそこ現実的な性能で運用できる環境
• メモリは32GB以上
• HDDは取り敢えず少なめで。外付けHDDの手持ちがあることと、同時稼働させる複数VMを同一HDDに格納するのは性能落ちそうな予感があるので、小容量を複数個買ったほうが良かろうと判断。
• 仕事で扱っている機材もssh接続しかできない場所に置いてあるので、X Windowは動かさず、すべてSSH接続で作業する

購入したもの：

• ASRock H87 Pro4
• Intel Core i7 4770
• Western Digital WD5000AAKX (500GB HDD)
• ADATA AD3U1600W8G11-2×2 (計32GB)

余剰部品の再利用：

• ミドルタワーケース (メーカー失念。初代Core i7発売当時、i7機を組むために購入したもの。電源不調で交換済み)
• Huntkey パソコン用ATX電源500W BK-5000
• USBキーボード
• GIGABYTE GV NX66256DP (グラフィックカード)
• SATA 160GB HDD
• RATOC Systems SA-DK2-U3R (1TB RAID1)

購入品はCore i7 4770を使う+32GB以上のメモリを載せることを中心に、そこそこの予算でなんとかしましょうという方針。

余剰品としては1TB RAID1の外付けドライブが唯一の戦略物資です。USB3.0接続できてLinuxで使えるRAIDユニットとしてはかなり安かったので以前購入していたのでした。今回はこれがメインのデータドライブとなります。

と言う感じで本日組立とホストOSとしてのCentOS 6.4インストールが終わったところ。

VPS試したり再セットアップしたりするときの定番なのでメモる。

セットアップ直後

• sudoでrootになれる権限を持った作業ユーザを作り、作業ユーザでroot作業ができることを確認
• sshdの設定を変更、PermitRootLogin no
• sshdをrestart

1. コンソールログインができる場合は、コンソールからrootで入れることを確認して心の平安を得る。
2. それはともかくとして作業ユーザでSSHログインできることも確認しておく。
3. さらにrootでSSHログインできないことを確認しておく。

確認が終わったら、sshdの設定を再度変更、Port を22以外にしておくとさらに安心。

作業環境を整える

• .bashrcを確認して、いつものaliasをセット。rmとmvは基本的に -i を有効にしておきたい
• ssh-keygen を実行して鍵セットを構築
• ログイン元サーバーの公開鍵を適宜セット

作業ディレクトリ構成は大抵 archives/ (wgetしたものを格納)、 factory/ (wgetで拾ったものを展開、ビルド)、 workspace/ (自作のプログラムとかはここでいじる) の3構成。どーせそのうち tmp/ だとか tmp2/ だとかが増えていくのだけど。

定番アプリの導入 (2014/12/19 追記)

1. GNU screen (yum)
2. git (yum, 特にcheckinstallなどの導入に必要)
3. Subversion (yum, gitで管理するなら不要)
4. wget (yum)
5. checkinstall (ソースからビルド, http://asic-linux.com.mx/~izto/checkinstall/ )
   1. gettext (yum)
   2. rpm-build (yum)

$ sudo yum install screen git subversion wget gettext rpm-build

checkinstallの導入は 64bit 版 CentOS での CheckInstall 導入方法 – akishin999の日記 が適切だと思った。大体いつも手作業で対策して、それゆえ毎回忘れてやり直したりしてたことが綺麗にまとまっている。