#きょうのsystemd : IPアカウンティングとアクセスリスト

およそ1ヶ月前にリリースされたsystemd 235ではサービスごとにIPトラフィックを計算したり、アクセスコントロールができるようになったらしい。 元ネタはレナートのブログ記事 IP Accounting and Access Lists with systemd 。

本稿では、この記事の詳細を紹介する。

IPアカウンティング

v235以前でも、systemdはすでにユニットごとのリソース管理のフックを様々な種類のリソースに対し提供してきた: 消費されたCPU時間、ディスクI/O、メモリ使用量やタスクの数などである。 v235では別の種類のリソースをsystemdでユニットごとに管理できるようになった: ネットワークトラフィック(特にIP)である。

これに伴い、ユニットに追加された設定項目は次の3つ

  • IPAccounting=

    • booleanを取る。これが有効なユニットでは関連するプロセスによるIPトラフィックの送受信がバイト数およびパケット数でカウントされる。

  • IPAddressDeny=, IPAddressAllow=

    • IPアドレスプレフィックスを取る。Denyで指定されたIPアドレスとのサービスプロセスの送受信は禁止される。逆にAllowで指定されたアドレスは許可される。DenyよりAllowが優先される。

3つのオプションはLinux 4.11で導入されたカーネルの機能であるcontrol group eBPF フックを薄くラップするものである。 実際の仕事はカーネルにより実行され、systemdはこの機能を設定する新しい設定の多くを提供するだけである。

とのこと。

ブログでは次のようなservice unitを作成し、デモをおこなっている。

[Service]
ExecStart=/usr/bin/ping 8.8.8.8
IPAccounting=yes

デモを見る限り、たしかにパケットのin/outがカウントされている。

デモ用サービスを停止するときに

表示された最後の行は興味深く、アカウンティングデータを表示している。 これは実際は構造化されたログメッセージであり、サービスのメタデータのフィールドにはより包括的な生のデータがある。

その行は

Received 49.5K IP traffic, sent 49.5K IP traffic

というもの。 journalctl -u $SERVICE_NAME -n 1 -o verboseとしたら、上記のメッセージが格納されているのが確認できるよ、 MESSAGE_IDで引っ張れば、このメッセージが取り出せるよ、と書いているが、何が興味深いのか正直よくわからない。 デモでは停止後にメッセージを取りに行っているが、リアルタイムでも取れるんだろうか。

個人的には、次の部分の方が興味深かった。

systemd-run -p IPAccounting=yes --wait wget https://cfp.all-systems-go.io/en/ASG2017/public/schedule/2.pdf

とすると、一時的なサービスとしてIPアカウンティングを有効にしながらコマンドが実行できるようである。なにそれ面白い。

あと、ちゃっかり、自分が登壇する The user-space Linux technologies conference のPDFを読者にダウンロードさせてるのが面白い。

(ところで、もうチケットは予約したかな?もうそろそろ売り切れちゃうから、急いで!)

じゃねーよw

これの応用編として

systemd-run -p IPAccounting=1 -t /bin/sh

で新しいシェルを起動させて、コマンドを打つとかをやっている。なにそれ面白い。

なお、すでに起動済みのサービスに対し、IPアカウンティングを有効にする方法もあるようで、systemctlより設定する。

systemctl set-property foobar.service IPAccounting=yes

/etc/systemd/system.confにDefaultIPAccounting=を設定すると、すべてのサービスでIPアカウンティングが有効になる。

IPアクセスリスト

設定されたユニットのパケットの通過の可否は次の順で判断される。 1. IPAddressAllow=に設定されたIPアドレスとの通信は許可 2. IPAddressDeny=に設定されたIPアドレスとの通信は拒否 3. いずれにもマッチしない通信は許可

後述するように、TCP wrapperに代わる使い方を想定しており、これに合わせているんだろうなという感想。

こちらもデモをおこなっている。

それぞれのユニットに個別にIPアクセスリストを設定できるだけでも、すでにかなりいい。 とはいえ、典型的にみんながやりたいことは、これを包括的に設定すること、つまり、別個のユニットだけじゃなく、いくつかのユニットをまとめて一気に、あるいは、それだけじゃなく、システムまるごと設定することだろう。 systemdでは.sliceユニットを使うことでこれが可能になる。 (systemdをあまり知らない人のために書いておくと、sliceユニットはリソース管理のためにサービスを階層的な木にまとめるための概念のことだ) IPアクセスリストはユニットにとって事実上、ユニット自身に設定された個別のIPアクセスリストの組み合わせであったり、それの含まれているすべてのsliceユニットのそれらであったりするのである*1。

続くデモでは、デフォルトでシステムのサービスが割り当てられるsystem.sliceに対し、IPアクセスリストを設定している。

使用例

レナートはこのIPアクセスリストのユースケースとして、次のような例を挙げている

TCP Wrapperの置換

TCP Wrapperに対するメリットとして、あるサービスのIPソケットすべてに無条件で適用できる点、サービス側のコードに何も入れなくて良い点を挙げている。

逆にデメリットはTCP Wrapperが提供する機能のうち、カバーできてないものがある点を挙げている。特に、DNS名で設定する方法がないことを挙げているが、レナート本人は「でも、正直に言ってしまうと、ネットワーキングを制限するためにネットワーキングをおこなうってやっぱりかなり疑わしい機能だ。少なくとも自分には」と書いている。

IPファイヤーウォールの置換

NetFilter/iptablesに対するメリットとして、サービスという概念が理解できる点、そのため、コンテキストを理解している点を挙げている。

ただし、単純に比較もできないと書いている。 systemdのIPアクセスリストはサービスのことはわかるがそれ以外はわからないが、典型的なファイヤーウォールはピュアなIPに注目している分、用途が広いと述べている。

ディストリ/ベンダー提供のシステムサービスをセキュアにする

ネットワークにつなぐ必要のないサービスはIPAccessDeny=any(とIPAddressAllow=localhost)を設定することで、ネットワークに繋がせないようにできる。

セキュアにコマンドを実行

あまり信用できない実行ファイルをsystemd-runに-pでIPAccessDeny=とIPAccessAllow=とを渡せば、ネットワーク的に安全な状態でコマンドを実行できる。

ノート

socket activationとの組み合わせ

ソケットアクティベーションとの組み合わせが可能である。 ただし、ソケット側でIPアカウンティングを設定した場合、(当たり前だが)ソケット側でカウントされるため、ソケットがサービスに渡されても、カウントがそちらで続いていることに注意が必要。 IPアクセスリストもソケット側とサービス側と別個にカーネルで管理される。そのため、例えば、socketユニットでは比較的オープンなアクセスができるアクセスリストを設定し、serviceユニット側で制限のかかったアクセスリストを設定することで、socketユニットで設定されたソケットをサービスを起動・停止の唯一の方法とすることができる*2。

他のアドレスファミリーとの組み合わせ

IPアカウンティングとアクセスリストはIPソケットのみに適用され、他のアドレスファミリーには適用されない。

つまり、AF_PACKET*3ソケットはカバーされない。IPアクセスリストとRestrictAddressFamilies=AF_UNIX AF_INET AF_INET6と組み合わせるとより強固になる。

systemd-runの他のアカウンティング

CPUAccounting=, IOAccounting= をつけると、これらのアカウンティングも見れる

オーバーヘッド

ゼロというわけではないが、最新のカーネルではeBPFの実行はすでに最適化されている。今後も最適化が進んで、コストは無視できるようになるはずと述べている。

IPアカウンティングの再帰

現時点では再帰的ではない。つまり、sliceユニットに設定して、その配下のユニットのIPアカウンティングをまとめるといったことはできない。

将来的には実装したいが、カーネル側での実装がまず進む必要がある。

PrivateNetwork との関係

PrivateNetwork=とIPAccessDeny=anyとは似たような機能で、ユニットがネットワークを使用できないようにすることができる。ただ、前者はLinuxネットワーク名前空間を使って実装されているため包括的である。

*1:代名詞が多くて文意がつかめなかった。原文は"the IP access list in effect for a unit is the combination of the individual IP access lists configured for the unit itself and those of all slice units it is contained in"

*2:ちょっとわかんなかった

*3:L2での生のパケットのことらしい man AF_PACKET (7): デバイスレベルのパケットインターフェース

#きょうのsystemd : machinectlにブロックデバイスをイメージとして認識させられるように(なるはず)

LennartがnspawnについてMLに投稿していた件について、今朝調べていたら、動きがあったことがわかったので翻訳。 GPTイメージの話も興味深い。

[systemd-devel] systemd-nspawn/machinectl with LUKS/LVM

やぁ、

systemd-nspawnでLUKSで暗号化されたLVを使う正しい方法を探している。

"containername" と名付けたLVを用意していて、これはLUKSで暗号化されている。 で、次のコマンドを使って、コンテナを起動させた。

systemd-nspawn --boot --image=/dev/vg/containername

LUKSのパスフレーズの入力が求められて、コマンドライン上はうまく動いているように見える。

だけど、ちょっと質問がある。

1) パーティションを使わなかったり、ファイルシステムを使わない場合に比べて、単一パーティションのGPTを使うメリットってあるんだろうか?

2) machinectl list-imagesがLVにあるイメージを検出しないんだ。/var/lib/machinesにあるイメージは(auto)mountされるものだと思ってるんだけど?

3) これ(訳注: LVをnspawnのイメージとして起動させること)を起動時に有効にするのはどうするのがベストだろうか? "machinectl enable"は動かなかった。というのも、どのイメージを使うのか認識できないみたいなんだ。イメージから起動するnspawnコンテナのsystemd unitファイルの例ってあるの?

Thanks,

-- M

Lennartの回答。

[systemd-devel] systemd-nspawn/machinectl with LUKS/LVM

(引用省略) (訳注: 1について)

イメージの分析ロジックはどちらも取り扱えるよ。 GPTを使う方法が少しだけ良いと思うね。というのも、rootパーティションをそれとマークすることができるし、そのイメージに適したCPUアーキテクチャの情報も同梱することができる(し、nspawnがそこから--personality= オプションを引っ張ることができる)から。 つまり、この方法を使えば、より多くの情報を見つけることができ、nspawnに適したイメージは簡単にそういうものだと見分けが付くんだ。 そして、もちろん、同じイメージの中に複数のパーティションをもたせることだってできる。 例えば、単一のイメージの中に、読み出し専用のsquashfsな/usrに書き込み可能な/homeを組み合わせたりってことができる。 言い忘れてたけど、GPTを使うことで、KVM(や物理システム)とnspawnとでほとんどおんなじ方法でブートさせられるイメージを作ることができる。

もし、これらの特徴、つまり、見つけやすさやアーキテクチャのサポート、複数パーティション、KVMとの互換性、に関心がないのなら、GPTなしのほうがいいかもね。

(ところで、mkosiを使うと、GPTの特徴の恩恵を受けたイメージを簡単に作ることができるよ。)

(引用省略) (訳注: 2について)

/var/lib/machinesでイメージを利用できないなら、そこにマウントするか、シンボリックリンクを張れば、動くはずだよ。

Lennart

-- Lennart Poettering, Red Hat

でも、動かなかったようで、

[systemd-devel] systemd-nspawn/machinectl with LUKS/LVM

(訳注: 1について)

オーライ、納得したよ。

(引用省略) (訳注: 2について)

LVブロックデバイス(/dev/vg/containername - こいつはGPTを含んでる)へのシンボリックリンクを/var/lib/machinesに作ってみたよ。 "containername"や"containername.raw"って名前でシンボリックリンクを作ってみた。 でも、"machinectl list-images -a"はどうやら、このイメージをどの方法でも見つけられないみたいだ。 ところで、使ってるのはDebian stretchのsystemd 234だ。

/var/lib/machinesでイメージを利用できないなら、そこにマウントするか、シンボリックリンクを張れば、動くはずだよ。

できれば、イメージをマウントするのは避けたいな。GPTパーティションを手動で検出させたり、LUKSを解除したり、などなどは避けたいし、ホストにコンテナのデータを不必要に見せることもしたくないんだ。 でも、どうやら、自分が張ったシンボリックリンクがおかしいようだ。

-- M

Lennartの返答。どうやら、ブロックデバイスは認識できないらしい。

[systemd-devel] systemd-nspawn/machinectl with LUKS/LVM

(引用省略)

あー、ふーむ。目的のものはデバイスファイル?

あぁ、忘れてたけど、イメージはブロックデバイスだったんだ。 ブロックデバイスを使うにはサポートがいくつか足りないんだ。 /var/lib/machinesに入れられるのは、ディレクトリやサブボリューム、rawファイルに今のところ限られていて、ブロックデバイスはサポートしていないんだ。 でも、ブロックデバイスのサポートを追加するのは簡単でもある。 RFE*1バグとしてgithubにこのことを報告してもらえるかな?

Lennart

-- Lennart Poettering, Red Hat

というわけで、RFEがまとめられた。

RFE: allow symlinks to block devices in /var/lib/machines · Issue #6990 · systemd/systemd · GitHub

で、この件について機能強化したのが次のマージリクエスト。

add nspawn image discovery on block devices by poettering · Pull Request #6996 · systemd/systemd · GitHub

昨日にマージされたみたい。ただ、xenial(amd64)の自動テストでコケてるのが気になるけど、次のリリースまでにはmachinectlがブロックデバイスをイメージとして取れるんじゃないかな。

*1:Request for enhancement: 機能強化要求

#きょうのsystemd : 受動態の target units は何のためにある?

勉強になったので翻訳

(私家訳。誤訳や誤解があれば指摘歓迎。)

[systemd-devel] Why do passive target units have to exist?

やぁ

systemdのドキュメントを読んでいるところなんだけど、受動態(passive)のunitがちょっとこんがらがった。

"network.target"を例に取ると、

"systemd-networkd.service" には "Wants=network.target" と "Before=network.target" が書かれている。これで、"systemd-networkd.service"は事実上、"systemd-networkd.service" と "network.target" との両方を起動させることができるし、 "network.target" を "systemd-networkd.service" がアクティブになろうとする後にアクティブにすることができる。シャットダウンの順序も正しいと思う。つまり、 "network.target" は"systemd-networkd.service" より先に停止させられる。ここまでは全部わかる。

もし、能動態(active)のtarget unitでこれを実現しようとしたらどうなるのだろう? "systemd-network.target" で "WantedBy=network.target" を指定することはできるのだろうか? そうすれば、 "systemd-network.service" を有効にすれば("network.target.wants" ディレクトリにシンボリックリンクがつくられて)、"network.target" を起動させれば、 "systemd-networkd.service" も起動させることができる。これでも、target unit デフォルトの依存関係で "network.target" は "systemd-networkd.service" の後にアクティブになる。シャットダウンの順序の正しいだろう。

自分にわかる唯一の違いは起動させる units の違いだ。つまり、受動態の "network.target" で "systemd-networkd.service" を起動させるか、能動態の "network.target" で "network.target" を起動させるかの違いかなんだ。

能動態の target units に対して、受動態の target units を使うメリットってあるんだろうか?

John

これに対する、Andrei Borzenkovの反応

[systemd-devel] Why do passive target units have to exist?

思うに、systemdがinitスクリプトに頼らざるを得なかった最初期の歴史的アーティファクトなんじゃないかな。networkingを実装しているinitスクリプトは network.target としても知られている $network を提供していた。だけど、もちろん、これはこれ自身をネイティブなsystemd unitに引っ掛けるものじゃなかった。ネイティブな units だけを使っている限りは、実用上の差はないよ。

[systemd-devel] Why do passive target units have to exist?

Johnがいろんな受動態のtargetをリストアップして、これら全部そうなん?と聞き始める。

ここで、Lennart参戦。

[systemd-devel] Why do passive target units have to exist?

違うよ。これら(訳注: Johnの挙げた受動態のtargetたち)はそれ(訳注: 初期のinitスクリプト)とはまったく関係ない。 これらは全部、同期のポイントなんだ。この同期のポイントはブートの遷移の中ではできればない方がいい。でも必要なら制御しないといけないんだ。

もともとの質問である「能動態の target units に対して、受動態の target units を使うメリットってあるんだろうか?」について Lennart。

[systemd-devel] Why do passive target units have to exist?

我々は基本的に同期ポイントは最小限にしようとしているんだ。 "network.target" もその一つで、そうする理由がなければ、そいつには活躍してほしくない。 同期ポイントが多ければ多いほど、ブートがよりシリアルなものになってしまうんだ。

ロジックはこうだ。もし networking スタックがなければ、サービスがこれの前後で同期する理由がなくなる。必要に応じて、 network.target を制御するのはまさに networking スタックであって、その利用者じゃないんだ。

納得できるかな?

Johnの追加の質問

[systemd-devel] Why do passive target units have to exist?

腑に落ちたよ。説明ありがとう。

だけど、まだ疑問がある。もし、基本的なゴールが同期ポイントの最小化にあるんなら、どうして、より多くの能動態の target を受動態のそれに変えないんだ? 例えばこうだ。全部のマシンにスワップがあるわけじゃない。それなら、swap.targetは受動態のtargetに変えて、不必要な同期ポイントを避けることができるんじゃないか? 何か理由があるに違いないと思うんだけど、それが何だかはわからなかった。

Lennartの回答

[systemd-devel] Why do passive target units have to exist?

あぁ、targetsはただの同期ポイントってわけじゃないんだ。こいつらは物事をグループ化するための方法でもあるんだ。 swap.targetはすべてのスワップデバイスを制御する方法であり、local-fs.targetはすべてのローカルファイルシステムを制御するなどなど。

読んでたらごっちゃになってきたが、理屈としてはおそらく、次の通り:

  • network.target を必要としているのは systemd-networkd.service であって、その逆では決してない
  • 理屈上、Johnの書くとおり、systemd-networkd.service に WantedBy=network.target と書いても動きはするだろう
  • ただし、この場合、network.targetがsystemd-networkd.serviceを起動させようとしてしまう
  • サービス起動をパラレルにすることを考えると、target unitの依存関係は少ないほうがいい

ふむ

『ダンケルク』を観てきた

友人の結婚パーティーで関西に戻った帰りに、品川のIMAXで(遅ればせながら)『ダンケルク』を観てきた。

画面がでかく、迫力は満点だった。 id:Forty さんのアドバイスは正しかった。

この迫力満点の甲斐もあり、始終、緊張させられる映画だった。終わった後に後ろのおばちゃんが「緊張しっぱなしで疲れた」と言っていたのには、同意である。 兵士の置かれた極限状態を(ややデフォルメのきいた映像表現で)観客に追体験させる点では優れた映画だったと思う。

ただ、極限状態の「リアリティ」に特化した結果か、作品全体として「リアリティ」が欠けてしまっているように感じてしまった。 市街の陣地で守る兵士が少なかったり、浜辺が綺麗過ぎたり、アトラクションに並んでいるかのような兵士の列だったり……。 描きたいものが違うから仕方がないが、『つぐない(Atonement)』のダンケルクの描写のほうが好きである*1。

つぐない [Blu-ray]

つぐない [Blu-ray]

なお、戦場経験のない人間の言う「リアリティ」って意味は分からないな、と自己批判しておく。

「いい奴」でも死ぬし(ジョージとか、あのフランス兵)、「嫌な奴」(ハイランド兵)でも生き残る、そんな「戦場における死のランダム性」はひしひしと感じられた。

ノーラン監督は「兵士」以外は描きたくなかったんだろうなぁと思う。

あと、イギリス人はダンケルク好きねぇと思った。ダンケルクのイメージってああいうのなんだねと。 今、ちまちまながら読んでいる本がこういうイメージに異議を唱えていて面白い。

Britain's War Machine

Britain's War Machine

「弱いイギリスがダンケルク撤退に大成功して、バトル・オブ・ブリテンでは忍耐勝ち(↑↑テンションMAX↑↑)、その後は、アメリカの腰巾着になって、なんとなーくドイツに勝利」 という第二次世界大戦のイメージが定式としてあるとのこと。これが第二次世界大戦中から戦後、最近までのイギリスの軍事戦略の基礎にあるらしい。

しかし、この本が言いたいことは、「別にイギリスそんな弱かねぇし、そもそも、孤独なイギリスvs枢軸という構図でもない」ということのようだ。 まだ読んでいる途中なのだが、映画を見て読み進めるモチベーションがもらえた。

どうしても自分の関心が大局的・理論的な部分(戦略・作戦・戦術、軍事組織、将校教育、政戦略の調整、資源のコントロールとかとか)に寄りがちなので、こんなことことも書いてしまった。

以下、細かすぎる感想

のっけから、「うおぉ」って思ったのは、土嚢を積んだ陣地で守備に付いている兵士(イギリス軍兵だっけ?)が(たぶん) "bon voyage" って言ってた点。 あの人たちは多分残って、海岸堡を死守して捕虜になったんだろうなと。

最初、桟橋7日間、船1日間、空1時間を「英本土からダンケルクまでにかかる時間にしちゃぁ長いな」と思っていた。 遅ればせながら、描き出してる時間だったってのに気づいたときは、「おぉ……、ターン制のシミュレーションゲームか」ってなったよね。 グランドストーリー自体はここで見えた感じだった。

主人公とハイランド兵ご一行様が棄てられた商船に乗り込むシーンは、さながら自ら棺桶に入りに行ってる感があり、嫌な予感しかしなかった。 近衛兵だのハイランド兵だのどこで見分けてるのか全然わからなかった。

戦闘機が不時着水するときって、衝撃で風防が歪まないように、予め開けておいたりしないのかしら、とか気になった。

ジョージくんが何者なんかがよくわからなかった。ルッキズムとステロタイプ丸出しで「メスチソ?」とか思った。あと、新聞で英雄になってた理屈がよくわからなかった。

あと、あの船の爺さん、設定あるにしても、空軍戦術に詳しすぎでしょ。 でも、爺さんの言うとおり、確かに、スピットファイアのマーリン・エンジンはいい音してた。

*1:ジョー・ライト監督は「命の無駄遣いを描きたかった」とオーディオコメンタリーで言っていたと思う。

systemd-nspawnの記事を書いた

systemd-nspawnについて書いた記事が公開された。

gihyo.jp

Web媒体への技術記事の投稿は初めての経験である。これが冗談半分で言っている「systemd芸人」への第一歩になれば、なお良い?

systemd-nspawnについて調べようと思ったのは、systemdについて勉強していたら、*ctlコマンドに-Mなるオプションがあることに気づいてから。

記事にできると思ったのは、ネットワーク関係のオプションの挙動がわかりだしたところあたりから。

記事にしたのは、LPIC Level2の勉強が嫌すぎた現実逃避から1。

Ubuntuのrootfsはさくっと作れたのだが、Fedoraのそれをyumで作る方法がスマートにできなくて苦戦した2。

systemd-nspawnをしっかり使ってみて思ったのは、すごくプリミティブな作りなので、その分、systemdやコンテナの勉強になったということ3。 ちゃんと説明しようと思うと、結構しっかり調べなきゃいけないし、しっかり理解してないとスマートじゃないやり方でコンテナができてしまう。

systemd-nspawnで遊びだしたのはここ数ヶ月なのに対し、記事の執筆にかけた時間はおよそ1週間。 数カ月に試行錯誤して貯めていた知識が、執筆でパーツがつながっていくのが実感できて大変楽しかったし、達成感があった。

一文一文が長くなる傾向は相変わらずのようだったw

あと、某所でクローズドなLT企画があり、内容不問で登壇者募集だったので手を挙げた。 内容としては、書いた記事からプラスアルファの部分を話す予定。

そこで話した分で、あと1回分は書けそう。せっかくだし、さらにあと1回書けないか、ネタ探し中。

最後に、備忘のために、今回分のみの参考文献リスト(あとで書き足すかも)

記事を書くたびに伸ばしていけるように頑張る。

  1. なお、202で落ちた。↩

  2. 最初はyum-config-managerで理研のサーバーのリリース26のレポジトリを直接指定して、登録するなどしていた。あと、rpmdbの件もrpmdbが空というその事実にたどり着くまでが長かった。↩

  3. systemdはmanページがとても充実していて、読んでいるだけで非常に楽しめる。↩

OSC 2017 Tokyo Fall で話してきた

OSC 2017 Tokyo Fall で10月にリリース予定の Ubuntu 17.10 についてお話してきた。

8月の京都でOSCがあったときに、たまたま私も夏休みで関西に帰っていたため、顔を出したところ、村人さんから話しませんかとオファーをいただきました。

  • 「(当日発表された)いくやさんの資料の答え合わせでいいよ」と言われたこともあり、
  • 前々から翻訳以外の活動もしたかったのもあり、
  • 調べてみたら、スケジュール的に多分大丈夫だろうということもあり、

ということで、引き受けた。

ところがどっこい、いくやさんに資料を頂いたところ、「現在は結構変わっていて、あまり役に立たないかもです。」とのこと。 中身も自分には高度で、ちょっと話せないなという感じだったので、「こりゃ身の丈に合った内容にしないとな」という感じだった。

OSC Tokyoのセミナーページも オープンソースカンファレンス2017 Tokyo/Fall - イベント案内 | 2017-09-09 (土): Ubuntu、Unityやめるってよ てなふうで、「聞いてたのと違う」が正直な感想*1。

というわけで、「自分にできることをやろう」ということで、気持ちを切り替えた。 基本コンセプトは17.10を18.04 LTSの前段階と位置づけて、16.04 LTSユーザー(=自分)から見て、17.10ってどうなん、という内容で構成した。

発表自体は、力量不足で、16.10〜17.10で加えられた・加えられる変更を Ubuntu Weekly Topics や各リリースノートから引っ張ってきて、水増ししても時間が余ってしまった。 普段からわりと早口らしい*2のだが、発表とかになるとそれに磨きがかかるくせがある*3。

ただ、調べた限りでも、あとから、hitoさんと話しても、デスクトップユーザーにとって、17.10って、UnityからGNOMEに変わるのが最大の変化で、それ以外は目立ったものはなし、といった感じだったので、仕方がなかったことにする。

まぁ、笑いを取りに行ったところはきっちり決められたので、関西人としてはそれだけで満足度が高い*4。

タイミングが合えば、またやりたい。

ところで、im-config動かして、fcitxに設定したら、Wayland + GNOMEなUbuntuでも、fcitx + Mozc で日本語入力ができてしまったんだけど、これは使えているとみなして良いのか否かという点が気になった。

*1:ついでに言うと、その週の本業が不規則な勤務になってしまい、体調やモチベーションの維持に力を使う感じで、その意味でも予定外だった。2日目は申し訳なく思いながら、家で過ごしました。

*2:仕事を始めてから知った事実。大学では周りの人は同じくらいのスピードで話していた気がするので気づかなかった。

*3:職場のプレゼン研修はゆっくり話せと言われまくって、辛かった。

*4:しょうもない自画自賛をすると、アンケートのくだりが決まったときに、勝負ありと思った。

松本佐保『バチカン近現代史: ローマ教皇たちの「近代」との格闘』中公新書、2013年

バチカン近現代史 (中公新書)

バチカン近現代史 (中公新書)

主権国家バチカン

地理の資料集を見てバチカン市国の項目を見つけ、面積が小さい、人が少ない、と思ったことがある人はそれなりにいると信じたい。 そんな、バチカン市国も見方を変えれば、教皇の住まいといってよく、教皇は全世界のカトリック信者のトップであり、なかなかに侮りがたい存在である。

しかし、思えば、連綿と引き継がれているにもかかわらず、教皇が世界史で扱われることはそう多くない。

叙任権闘争で神聖ローマ皇帝ハインリヒ4世に教皇権の優越を見せつけ、十字軍を組織したあたりが最高潮である。 「教皇は太陽、皇帝は月」と言ったインノケンティウス3世の出した第4回十字軍は暴走して、あろうことか、ビザンツ帝国の首都・コンスタンティノープルを征服したり、教皇が何人も並び立ったり、ルターが出てきてプロテスタント教会が生まれたりと、坂を転げ落ちるような感じである。 主権国家体制が成立して以降は僅かな例外は別にパタリと記述が止んでしまう。 主権国家体制とは、教皇の世俗に対する権威の否定でもあったのだから、宗教分野以外で記述が減るのは当たり前ではあるか*1。 完全に相性が悪い。

しかし、世俗で主権国家体制が成立しようと、教皇は存在し続けている。 本書はバチカン(ローマ教皇領)の歴史を扱っているが、メインの記述はフランス革命のおこりからである。 幕開けの記述は劇的である。 「だが、宗教改革、三十年戦争によって、バチカンの権威が徐々に失われていくなか、さらにフランス革命という、教会制度を否定し理性を第一に掲げた大きな変動が十八世紀に待ちかまえていた。バチカンが頼りにしていた世俗の王権が崩れはじめ、新たな近代という社会がはじまる。これ以降、『神の代理人』という権威は、現実世界といかに向きあおうとしたのか。神を奉じるバチカンの生き残りを賭けた近代との戦いが始まる*2」

自分の中で、主権国家体制と教皇とは根本的に相性が悪いだけに、「バチカンの『主権』」といった言葉が記述に現れると、違和感と興味深さが掻き立てられた。

過去の栄光にしがみつく教皇

本書第II章くらいまでの感想は「過去の栄光にしがみつく教皇」というものが大きかった。俗っぽい言い方ではあるが。全体を通じて、バチカンには保守派か穏健改革派かの二択であるが、この時期はどちらかといえば、前者が幅を利かせていた時代である。 ピウス7世の時は、コンサルビ国務長官(役職名がおもしろい)の下しぶしぶながらも政教条約を結んで、生き残りを図ったり、ウィーン会議でうまく立ちまわったりで、柔軟にやれていた*3。 その後、(超)保守派の教皇が続き、近代化に抗する政策を打ち出す。

印象的だったのはグレゴリウス16世で、鉄道敷設は拒否、科学や技術の本は発禁、書いたら投獄といった具合で、「保守的なオーストリアですら、メッテルニヒが何らかの内政改革が必要なことを示唆したが、教皇は耳を貸さなかった。*4」 このあたりの記述で面白かったのは教皇選出にあたって、フランスとオーストリアとがそれぞれ押す枢機卿(ただし、枢機卿団は大体イタリア人)の一騎打ちになるというものである。こうした傾向は第一次世界大戦が終わるまで続いたらしいが、それは、オーストリアの帝国が崩壊したというのもあるのだろうか。

「覚醒教皇」ピウス9世はフランスの後押しで1846年教皇に選出され、穏健自由主義者であった。ただ、彼にとって不幸だったのは、「人びとはこの覚醒教皇が、反オーストリアであるイタリア・ナショナリズムの指導者になると見なした*5」ことだったのではないかと思う。

1848年にフランスに端を発した革命の嵐はイタリア半島にも及んだ。ローマでも憲法導入への市民の要求が高まり、ピウス9世はこれを認めた。だが、出てきた憲法は民主的なものとは程遠かった。結果、市民は「あれ?」となる。 流れを決定にしたのは、サルデーニャの対オーストリア宣戦布告であった。革命の鎮圧にオーストリアが忙殺されている間に、イタリアで革命を起こしてしまおうという算段であった。 「この宣戦布告はローマでも波紋を呼ぶ。もしピウス9世がイタリア・ナショナリズムの指導者であるならば、反オーストリアを掲げ『イタリア連邦』を率いることができると期待されたからである。*6」 だが、教皇はイタリア・ナショナリズムの指導者ではなかった。本書はオーストリアは教皇を支える存在だったため、それに反旗を翻すのはなかなかに難しい決断だったとしている。 それもそうだろうが、本質的に教皇とはナショナルな枠組みを超えるカトリック教会の頂点に位置する存在である。ナショナリズムのリーダーとしての教皇の実現可能性はどれほどのものだったのかが気になるところである。 何はともあれ、期待していただけに、「人びとに大きな衝撃と憤激を与えた。*7」 革命を前にして、教皇はローマを脱出する。最終的に革命は鎮圧され、教皇はローマに戻ったものの、かつての自由主義的な姿勢は極端に保守的なそれに変わることとなった。

サルデーニャ王国がイタリアを統一すると、紆余曲折を経て、孤立無援のローマは王国に併合された。ここでのピウス9世の反応は次のように描かれる。「一八六四年一二月、ピウス9世は「謬説表」を発表する。これは自然主義や合理主義、宗教的寛容主義と言った近代的な思想や文化を誤りであり、排斥すべき対象とするものである。また、社会主義や共産主義だけではなく、自由主義までも過ちだと主張し、これらをイタリア王国成立の根底に潜む思想的誤りとして糾弾した。そこには、教皇に就任当初、覚醒教皇と呼ばれ自由主義的な政策を支持したピウス9世の姿はなかった。*8」なんとも涙を誘う記述である。

このあと、イタリア王国と教皇とは非常に仲が悪いものとなる。正確には、イタリア王国が世俗的な力を失った教皇の権威を否定する政策を連打する、ワンサイドゲームの感があった*9。

主権国家体制の受容(?)

第III章は「イタリア政治への介入」と題されている。内容は章題のとおりである。 印象に残っているのは、イタリアとかつての保護者のオーストリアとが同盟を結んで孤立状態になってしまったのを、外交を駆使して脱出しようとしているところであった。唐突に、ゲームのルールを受容して、うまく立ちまわることを覚えた感じがする。 また、このあたりから、社会主義や共産主義への対抗意識というのが表に出てくることが多くなったように思う。 面白い記述が多く枚挙に暇がないが、第一次世界大戦中に「七項目の和平条件」というのを時の教皇ベネディクト15世が協商側に出していた点である。 著者はこれに関して「[…]ウィルソン米大統領が平和に関する十四ヵ条を発表した。六ヶ月前にベネディクト15世が出した『七項目の和平条件』を発展させたものと見て良い内容」と述べている。

普通は1917年11月に発表されたレーニンの「平和に関する布告」を受けて、1918年1月のウィルソンが対抗的に「十四か条」を発表したという流れで見るものであろう*10。 「七項目」はこのいずれよりも早く、1917年5月発表とのことである。 著者の書く通り、ウィルソンの「十四か条」と「七項目」とが紐づくなら面白いが、過大評価という感も否めない。

親ファシズム・ナチズム?

第IV章は「ムッソリーニ、ヒトラーへの傾斜」である。 バチカンとイタリアのファシズム、ドイツのナチズムとの関係はいろいろと議論があるようだ。そういう議論があることは知っていたが、詳しくは知らなかったので興味深かった。 本書の立場は「親ファシズム・ナチズムではない。反共なんだ。」といった感じのところか。端的に書かれているのは、「このようにピウス11世、ガスパリ国務長官、そしてパチェッリ枢機卿の三人は、宗教的理由からだけでなく、ソ連、ポーランド、ドイツなどで共産主義に直面した体験から、強い反共産主義の立場にあった。この三人がムッソリーニやヒトラーとの政教条約の担い手となっていく。*11」という記述だ。

ちなみに、バチカン市国が成立するのは1929年に、ムッソリーニとの間で結ばれた、ラテラノ条約である。世界史の教科書で近現代のパートに教皇が出てくる数少ないシーンであろう。

先ほど引用したなかの、パチェッリは1939年、ヨーロッパ情勢がきな臭くなるなかでピウス12世として教皇に選出される人物であるが、「ヒトラーの教皇」とさえ呼ばれることがあるらしい。 全体として、バチカン擁護の論調なのかなという感じである。 「史実から繙くと、バチカンがナチス・ドイツの行動に積極的にコミットしていたとは言いがたい。バチカンが恐れたのは、共産主義国であるソ連はもちろんだったが、それ以上に共産党の国際的組織コミンテルンであった。バチカンがカトリック教会の国境を越えたネットワークを使い、これに対抗しようとしていたのは確かである。バチカンにとっては、民衆の強い支持を得て誕生したファシズムやナチズムが、共産主義の対抗組織としてソ連を倒してくれる希望を持ち、頼りになる存在と考えていた。そのため、ムッソリーニのイタリアやヒトラーのドイツとの政教条約に踏み切った側面がある。*12」

ホロコーストについても、対抗的な措置や抗議は行っていたが、それでも、「生ぬるいとの批判はついてまわるだろう*13」としている。

これらの問題について、詳しいわけではないが、多分に解釈の問題であろうという感は否めないと思った。「真実」なるものはおそらく出てこないだろう。 この問題に関する著者のメタ的な評価が面白い。「いずれにせよ、第二次世界大戦中のピウス12世、ひいてはバチカンに対する批判的な論調が大きくなるのは、冷戦終結後の一九九〇年代以降である点が興味深い。バチカンは冷戦中、西側勢力の反共産主義の牙城であり、そのイデオロギーの拠り所として重視されていた。しかし冷戦が終結すると、封印されていなものが出てくるようになったのである。*14」

世界の中のバチカン

だんだんこのあたりから興味が薄れてきたので駆け足に。

「バチカンと米国は歴史的に決して友好的な関係ではなかった。*15」だが、冷戦を背景にアメリカとバチカンとの関係が深まる様子を軸に第V章は展開する。冷戦期にはカトリック教会が持つ国際的ネットワークがアメリカの東側の情報収集に大いに役立ったらしい。他にも、大戦中はスペインを中立に保たせながら、フランコ政権に影響力を行使して人権弾圧をやめさせたりと、バチカン大活躍なように描かれる。ヨハネ=パウロに至っては、さながら、東側共産圏を崩壊させ、冷戦を集結に導いたスーパースターのように描かれる*16。

ここまで来ると、さすがに、過大評価ではないかという感が否めない。バチカンが積極的にそういうことにコミットしたことを否定するつもりはない。だが、コミットしたことと、そのあとに起きた出来事とを因果関係があると歴史学的に論証するのは、難しいものである。

とはいえ、教皇が世界のありとあらゆるところに顔を出し、様々な問題にコミットしてゆく姿を読んでいると、一周回って、グローバル化と教皇とは親和性が高いように思えてくる。 もちろん、 Christendom とグローバルとを同一視することはできないが、世俗的権力を持たないからこそできること、というのが確かにあるように思えてくるのである。

*1: 主権国家体制は1648年のウェストファリア条約から始まったとされている。もっとも、ウェストファリア条約が主権国家体制の始まりとすることに疑問を付している書籍もある。例えば、明石欽司『ウェストファリア条約―その実像と神話』慶応大学出版会、2009年。この本は買ったままでまだ読んでいない。 あまり詳しくはないので、厳密な議論はできないが、主権国家では、中に対して主権者が統一的な権限を持ち、外に対しては主権者が唯一国家の代表として存在する。現代では(主権)国家は領域・人民・主権が3要素とされているらしいが、これはいつからそう定義されているのかは知らない。

*2: 本書、8頁。

*3: 本書、13-20頁。

*4:本書、25-26頁。

*5:本書、33頁。

*6:本書、40頁。

*7:本書、41頁。

*8:本書、50頁。

*9:だが、個人的には、これは教皇の権威をイタリア王国側が恐れていたからであるとも見ることができるのではないかと思った。

*10:実は、ロイド・ジョージのカクストンホール演説が「十四か条」の直前に挟まる。

*11: 本書、88-89頁。

*12:本書、108-109頁。

*13:本書、111頁。

*14:本書、111頁。

*15:本書、116頁。

*16:東側共産圏との対抗の中で「人権」を駆使するバチカンというのは新鮮味があった。親和性があるようにも思えるし、ないようにも思える。