bind mount を使えば、directory を 別の場所にマウントできる。例えば、以下は /tmp を /mnt にマウントしている

# mount –bind /tmp /mnt
# mount
…
/tmp on /mnt type none (rw,bind)

read only で mount しよとすると -o ro をつけて以下の様に mount すればよいはずだが、実際は 、mount の見た目は ro にもかかわらず、rw になってしまう。

# mount –bind -o ro /tmp/ /mnt/
# mount
…
/tmp on /mnt type none (ro,bind)
# touch  /mnt/au

read only にするために、remount を使う。remount 時に ro にするとなぜか read only にすることができる。

# mount -o remount,ro /mnt/
# touch  /mnt/au
touch: cannot touch `/mnt/au’: 読み込み専用ファイルシステムです

参考:

• Read-only bind mounts

curl を使って https://twitter.com/ を取得したら certificate が信用ならんとエラーがでた

$ curl https://twitter.com/
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

どうも、認証機関が追加されてないようだ。以下のようにして、再構成して追加すればよい。

sudo dpkg-reconfigure ca-certificates

参考文献

• Bug#563128: ca-certificates: curl and wget fail on https://twitter.com/ (but not iceweasel)

chroot 環境やコンテナ内で、apacheを起動すると error.log に 以下の様なメッセージが出て動作しない。

“libgcc_s.so.1 must be installed for pthread_cancel to work”

この場合、apache.conf に以下の行を追加することで回避出来る。

LoadFile /lib/libgcc_s.so.1

参考: http://www.modsecurity.org/documentation/modsecurity-apache/1.9.3/html-multipage/06-special_features.html

debiany/lenny の rubygems パッケージは 1.2.0 とバージョンが古い。gem は gem update –system で gem 自体の update を行う機能を持っているが、debian ではパッケージポリシーで禁止されている。実行しても、以下の様なエラーで止まってしまう。

# gem update –system
ERROR:  While executing gem … (RuntimeError)
gem update –system is disabled on Debian. RubyGems can be updated using the official Debian repositories by aptitude or apt-get.

この場合、gemの中にrubygems-update があるので、インストールしupdateを実行すれば良い。

# gem install rubygems-update
Successfully installed rubygems-update-1.3.3
1 gem installed
# /var/lib/gems/1.8/bin/update_rubygems

Reference:

• DebianパッケージのRubygemsを使う
• RubyGemsを1.3にアップデートする手順

debian/lenny には VirtualBox のOSE版パッケージがあるがバージョンが古い。debianのポリシーとして、bugfixやsecurity fix以外のアップグレードはなかなかでない。virtualbox に限らず、新しいバージョンが使いたい場合、 backports などのリポジトリを使うと新しいバージョンが入っている場合がある。

virtualbox ose 版は幸い新しいバージョンが入っていたので、それをインストールする。その為にはまず、backports のリポジトリを追加する必要がある。lenny-backports を追加するには、以下の apt line を /etc/apt/sources.list.d/ 以下に保存する。この時拡張子を list にする。

$ cat /etc/apt/sources.list.d/backports.list
deb http://www.jp.backports.org lenny-backports main contrib non-free
deb-src http://www.jp.backports.org lenny-backports main contrib non-free

各 debian リポジトリにある 鍵をインストールする。鍵をインストールしないと、そのリポジトリからインストールする度に毎回、以下のようなwarningが表示されてしまう。

WARNING: The following packages cannot be authenticated!

鍵のインストールは以下の通り。もちろんこの鍵のインストール時には上記のwarningが出る。

# aptitude update
# apt-get install debian-backports-keyring

これで、backportsのリポジトリが追加された。しかし、そのままでは backports に同じパッケージの新しいバージョンが存在しても利用できない。インストールの度に aptitude の -t オプションを使ってターゲットリリースを指定しても良いが、preference に追加することで各パッケージのターゲットリリースを指定できる。指定には /etc/apt/preferencesに以下の様に書く。

$ cat /etc/apt/preferences
Package: virtualbox-ose
Pin: release a=lenny-backports
Pin-Priority: 999

Package: virtualbox-ose-source
Pin: release a=lenny-backports
Pin-Priority: 999

この設定の後、virtualbox-ose(及びvirtualbox-ose-source) が既にインストールされていれば、aptitude safe-upgrade なのでアップグレードが行われる。インストールされてない場合でも、aptitude install virtualbox-ose などと普段通りインストールすればbackports の新しいバージョンがインストールされる。

backportsのvirtualbox-ose は kernel-module を自動的に更新しない。そのため、virtualbox-ose-source をインストールして、システムのカーネル用にmoduleをコンパイルする必要がある。kernel moduleのコンパイルには、module-assistant パッケージを使う。module-assistant を初めて使う場合、カーネルヘッダなどの依存を prepare コマンドで行う。build時にはソースコードのパッケージであるvirtualbox-ose-source をインストールしておく。

# m-a prepare
# m-a build virtualbox-ose

コンパイルが正しく終わると install コマンドを使って、今ビルドした module をインストールできる。ビルドされたmoduleは /usr/src 以下にdeb化されているので、dpkgを使ってインストールしても良い。

# m-a install virtualbox-ose

インストールしたmoduleはkernelにはまだ組み込まれないので、modprobe を使って組み込む。新しい virtualboxは vboxnetflt という ブリッジネットワーク用のモジュールがあるのでそれもインストールする。

# modprove vboxdrv
# modprove vboxnetflt

起動時に、このモジュールを組み込ませる為には /etc/modules に書いておく。

まとめ

• backports には新しいパッケージやバージョンがある
• backports のパッケージのインストールは aptitude の -t か preferences で指定が必要
• backports の virtualbox-oseはmoduleのビルドが必要
• moduleのビルドにはvirtualbox-ose-source が必要。このパッケージも backports から持ってくる
• moduleのビルドには module-assitantを利用

sshには様々な認証がある。そのなかの一つにホストベース認証がある。ホストベース認証を利用すると、同一ユーザが存在するホスト間で、ユーザの認証を省くことが可能になる。クラスタ等の大量ホスト上に同一のユーザが存在する場合、個々のホストどうしでホストベース認証をしておけば、ユーザ認証をせずにタスクをdispatchできる。

各ユーザは個々のホストでユーザネームが同一である必要があるが、uidは異なっていてもログインできる。

ホストベース認証を利用する為には、サーバとクライアントのどちらにも設定が必要になる。以下はdebian/lenny を使った場合の例である。

クライアント:

1. 以下を設定をssh_configに追加する。
   HostbasedAuthentication yes
   EnableSSHKeysign yes
2. サーバのホストキーをimportする。ssh-keyscan を使うと便利。
   # ssh-keyscan server1,server2,.. > /etc/ssh/ssh_known_hosts2

サーバ:

1. 以下を設定をssh_configに追加する。
   HostbasedAuthentication yes
2. /etc/hosts.equiv にクライアントのホスト名(またはIP address)を書く。
3. クライアントのホストキーをimportする。クライアント側でもsshdが動いてる場合は、クライアントの場合と同様に、ssh-keyscan が利用できる。クライアントでssh-server が動いていない場合は、
   1. ホストキーを生成する。ホストキーはssh-keygenで以下の様に生成。既にある場合は新たに作る必要はない。
      # ssh-keygen -N ” -t rsa -f /etc/ssh/ssh_host_rsa_key
   2. ssh_host_rsa_key.pub をサーバにコピーし、ssh_known_hosts2 に追加する。追加時に、クライアントのホスト名(やIP address)をパブリックキーの先頭に追加する。
      # (echo -n client; cat ssh_host_rsa_key.pub) > /etc/ssh/ssh_known_hosts2

クライアント側では、サーバのホストキーを/etc/ssh/ssh_known_hosts2 に保存せずに、個々のユーザの ~/.ssh/known_hosts に動的に保存させることも出来る。この場合、事前にサーバのホストキーを保存する必要はない。

逆に、サーバ側はユーザの known_hosts を無視することも出来る。これはsshd_configでIgnoreUserKnownHostsをyesに設定すれば良い。この設定をした場合は、クライアント側で /etc/ssh/ssh_known_hosts2 が存在しない場合には、ホストベース認証は行われず、別の認証に切り替わる。

references:

• ssh_config(5)
• sshd_config(5)
• hosts_equiv(5)

eval “`gnome-keyring-daemon`”
export GNOME_KEYRING_SOCKET
export SSH_AUTH_SOCK
export GNOME_KEYRING_PID

gnomeアプリケーションはgnome-keyringを使って、パスワードを一元管理できる。パスワードを一元管理する為にはgnome-keyring-daemonを起動しておく必要がある。gnome-keyring-daemonを起動していない場合、gnome-keyring を使用しているアプリケーションが正しく動作しない場合がある。例えば、パスワードの入力が毎回必要になったり、ログインが出来なくなったりする。

gnome環境ではgnome-keyring-daemonは自動的に立ち上がるが、gnome環境を利用していない場合、手動でgnome-keyring-daemonを起動する必要がある。gnome-keyring-daemonは起動時に以下の様なメッセージを吐き出す。

GNOME_KEYRING_SOCKET=/tmp/keyring-x9bpQO/socket
SSH_AUTH_SOCK=/tmp/keyring-x9bpQO/socket.ssh
GNOME_KEYRING_PID=9472

この値をそのまま環境変数をセットすれば、keyring を利用するアプリケーションが正しくkeyringにアクセス出来るようになる。これを自動的に行うには、eval を使って以下の行を .xinit や .xsession に追加すれば良い。

eval “`gnome-keyring-daemon`”
export GNOME_KEYRING_SOCKET
export SSH_AUTH_SOCK
export GNOME_KEYRING_PID