FC2ブログ

PCで: ウチのPCの今(4) 基本システム編

 ウチの変態PCの紹介シリーズも、ついに最終回を迎えました。
  1. ハード編
  2. SystemRescueCdカスタマイズ編
  3. ディスク暗号化編
  4. 基本システム編(本エントリ)

 今回は、ハードやOSとアプリとの間の辺りにいる人達について語ってみます。また加えて、今後のことについても。そこで、どうしてこんな中途半端な状態にいるのかについてもちょこっと触れます。

 まず基礎知識として、UNIXの流れを汲むLinuxのファイルシステムについて。
 Linuxでは、Windowsなどとは違い、全てのファイルが一つのツリーに納められています。

 ここでちょっと寄り道。
 Windowsとかだと、例えばCドライブとかDドライブとかのドライブレターが各デバイスに割り当てられています。というか、デバイス全体じゃなくパーティションだったりもしますが。
 Linuxの場合は、システムのブート時に決められた(通常は)どっかのディスクのパーティションがルートファイルシステムとなり、そのファイルシステムの頂点がルートディレクトリ(/)になります。で、他のはその中にあるどっかのディレクトリに接ぎ木のようにくっつけられることになります。これを、マウントと言います。
 例えば、ディスクに4つのパーティションがあって、一つがルートパーティションになり、他は/usr, /var, /home等のディレクトリにマウントすることにしたとします。あるパーティションのファイルシステムの頂点の直下に"lib"というディレクトリがあったとすると、それが/usrにマウントされた後には/usr/libという風に見えます。

 閑話休題。
 大体、どういう種類のファイルはどこのディレクトリにある、とかは決まりがあって、それに従って、例えばシステム全体の設定ファイルは/etcの下、ライブラリは/lib, /usr/libの下、とかいう感じで置いてあります。
 ところで、Linuxにはchrootという機能があります。とあるプロセスのルートディレクトリを、どっか特定のディレクトリに変更できるのです。そうすると、そのプロセス、及びそこから生成される全てのプロセスがそこをルートとし、そこよりも上が一切見えなくなります。
 これを使うと、システムに存在するリソースの内、ファイルシステムに含まれるものを全て切り替えた別の環境を構築することができます。

 というわけで、今回は、カスタマイズしたSystemRescueCdの環境に、以前のシステムのディスクからコピーしたツリーをうまくマウントして用意し、そこにchrootすることによって、暫定的に以前と似たような環境を使用することができた、というわけです。

 今は、こんな感じになっています。
  • SystemRescueCd
    • 旧来の環境(32bit)
    • 旧来のと同じディストリビューションの新バージョン(64bit)

 ところが、上にさらっと書いたように、chrootで見せ掛けられるのはファイルシステムのみで、他は実は共用しているので、微妙な結び付きができあがります。この辺りが仮想マシンなんかとは違うところで、気を付けて使えば便利とも言えます。

 まず、マウントにはバインドマウントというやり方があります。これは何かというと、どっかのディレクトリを、別のディレクトリにマウントできてしまうのです。二カ所に同じものが存在するように見えます。
 これを使い、/dev, /tmpをchroot環境にマウントしてあげます。
 /devというのは、上記の決まりにより、デバイスにアクセスするための特殊なファイルが置いてあります。これは、ファイルと言ってもなんかデータを格納するためのものではなくて、そこにアクセスすると、デバイスそのものにアクセスできるという代物です。
 /tmpは、名前からわかるように一時的に使用するファイルを置く場所、なんですが、実は結構大事なものをよく置く場所でもあります。例を挙げると、これもちょっと特殊なファイルなんですが、プロセス間の通信に使用するためのファイルとかだったりします。これもファイルと言いつつ、データを格納するものではありません。例えば、GUIの画面を管理するサーバがいて、あるプロセスが画面になんか出力したいと思ったときには、/tmpにあるファイルを通じて依頼をするわけです。

 chrootしてしまうと、大元のシステムの/devや/tmpにアクセスすることができなくなるので、それらをchroot先の/tmpにもマウントしてあげる必要が出てくるのです。
 例えば、chroot先を仮に/mnt/Old32とすると、こんな感じで。
mount -o bind /dev /mnt/Old32/dev
mount -o bind /tmp /mnt/Old32/tmp
 こうすると、/mnt/Old32にchrootしたプロセスからは/tmpに大元の/tmpが見えるようになります。

 外で動いているサーバとchroot先がやり取りをしなければいけないケースは他にもいくつか出てきました。
 例えば、ICカードにアクセスするためのシステムであるPCSC-Liteとか。
 デバイスを管理しているudevとのやり取りが、以前から使用していたシステムとSystemRescueCdとでバージョンが違うためにうまく行きません。chroot先で新しいPCSC-Liteを動かそうかなとも思ったのですが、新しいudevとやり取りをするためのライブラリをmakeすることができず、結局、PCSC-Liteのサーバであるpcscdを外(chrootする前の環境)で動かし、chroot先のプロセスは上記のようなプロセス間通信のためのファイルを共有してそのサーバとやり取りすることにしました。
 こんな感じです。
udev
↓↑
pcscd(外)
↓↑
/var/run/pcscd/pcscd.comm
↓↑
ICカードにアクセスしたいプロセス(chroot先)
 ここで、pcscd.commは/var/run/pcscdを/mnt/Old32/var/runにシンボリックリンクすることで共有しています。バインドマウントすると余計なものまで共有されてしまうからです。
 ちなみに、PCSC-Liteは以前から使っていたバージョン(1.4.102)を使用しました。新しくしてもいいのですが、一度1.7.4を試してみたら、どうもたまにICカードアクセスが滞るので、戻しました。
 古いバージョンで取り敢えずちゃんと動いているので、原因は追求していません。

 あとは、k3bというCD/DVD/BD書き込みソフトがあるんですが、これは(実は上のPCSC-Liteも多分そうですし他にもそういうの沢山ありますが)、HALという仕組みを司るサーバであるhaldにアクセスする必要があります。
 HALへのアクセスには、上記のPCSC-Liteのように独自のものではなく、もっと汎用の機構であるD-Busというのを使用しています。
 これのために上と同様、/var/run/dbusを共有することにしました。
 また、SystemRescueCdがベースとしているGentooでは、HALの特定の機能にアクセスしたいプロセスがグループ"plugdev"に入っていないといけないので、/etc/groupに手を入れました。
 実はこれはカスタマイズではなく、システム起動時にスクリプトでやっています。

 今、SystemRescueCdは私が使用しているものよりもバージョンが進んでいますが、2.3くらいからはudevの方針にしたがってこのhaldがいなくなってudevに吸収されているようなので、この辺りが色々ややこしくて、新しくしていません。

 さて、このマシンは個人の端末であると同時にサーバでもあるのですが、ネットワークからログインできるのはchrootした環境になります。つまり、外側にはアクセスできません。
 というわけで、内側からlocalhostにSSHでログインすることにしています。
 そのため、外側の環境に/root/.ssh/authorized_keys2を用意し、/etc/ssh/sshd_configに以下のように書き、
ListenAddress 127.0.0.1:22
(これによりlocalhostからしかログインできなくなります)、加えて、chrootした環境の~/.ssh/configにこう書きました。
Host    127.0.0.1 localhost
UserKnownHostsFile ~/.ssh/known_hosts_localhost
 これは、ブートの度にホストの鍵が変わってしまうからで、ブート時のスクリプトでこうしています。
mkdir -p -m 0700 /root/.ssh
cp -p --no-preserve=ownership /mnt/Old32/home/xxx/.ssh/id_dsa.pub /root/.ssh/authorized_keys2
{ echo -n 'localhost '; cat /etc/ssh/ssh_host_rsa_key.pub; } > /mnt/Old32/home/xxx/.ssh/known_hosts_localhost


 他にも32/64の二つの環境のpulseaudioの衝突回避とかありましたが、その辺りは省略。大体こんな感じで動いています。で、ApacheだのSambaだのはchroot環境で動いています。ネットワークからのアクセスはこちらに向かうことになります。

 さて、全四回にわたり紹介してきたウチのPCの現状ですが、この中途半端さにはこんな理由があります。

 一つには、これまで構築してきた環境をできるだけ継承したいのですが、折角ハードが変わったので、x86_64に移行したいとか色々考えました。というわけで、ちょっとずつ移行しようかな、とか思ってi386/x86_64が併存する環境になっています。
 次に、以前にも述べたように、ディスクの暗号化とか色々構築したら、それである意味安定してしまった、ということ。
 そして最後に、今後の計画、というのも一応あったりします。

 そもそもの移行のきっかけとなったハード障害のときに触れたQubes OS Projectですが、これを導入してみようかな、とか考え始めているわけです。
 このマシンは上記のように、サーバであり個人端末でもあります。なので、そこら辺きちんと分割したいな、とか思いまして。

 しかし、このQubes-OSもまだBetaなのでちょっと色々不備もあり、完全移行はちょっと、という感じです。
 それに、サーバとしても使用するとなると、Qubesで想定しているところからちょっとはみ出しそうで、どのプロセスをどのドメインにしようかとかまだ検討すべき点が残っていたりします。
 一部は、今やっているようにchrootで動かすことになるかも知れません。

 都合のいいことに、今回導入したCRIB35EU3はディスクが4つ入るので、Qubes試用用に2つ、現状の継続用に2つで二組のRAIDができます。

 というわけで、今後の計画としては、Qubes-OSの環境のもとで、今やっているようなことをきっちりと区画整理して実現したいな、とか考えています。

コメント

非公開コメント

プロフィール

水響俊二

Author:水響俊二
水響 俊二 [MIZUKI Shunji]

暫定的に、18禁作品の感想などは裏サイトで書いています。
   

最新記事
最新コメント
カテゴリ
検索フォーム
リンク
RSSリンクの表示
月別アーカイブ
アクセス解析中