2016-02-03

ActiveDirectory DDNS + NetworkManager

現代の開発者にとって Linux 仮想マシンは必要不可欠なものだが、IP アドレスをどうするかはいつも悩ましい問題だ。例えば下記のような状況は多いはず。

  • 社内は ActiveDirectory DNS / DHCP 環境。
  • 勝手に固定 IP アドレスを使えない。
  • 社内ネットワークから仮想マシンを参照させたい。

このような場合は DHCP を使うことになると思うが、暫く起動しないと IP アドレスが変わって接続する際に一手間かかって面倒くさい。個人的にはこの様な場合、Samba (の nmbd)を使っている。サービスを起動しておくだけで Windows PC からホスト名(NetBIOS 名)でアクセスできるので、とても便利。

しかし最近、ActiveDirectory のドメインに参加せずとも、DHCP で DNS レコードを登録できることを知った。少なくとも ActiveDirectory の DNS / DHCP にはそういう機能があり、そして私の社内ではそれが有効になっている。そうすると後は DHCP クライアント側の話。RHEL では、次の設定でそれができる。(詳細は man dhclient.conf)

RHEL6: /etc/dhcp/dhclient.conf:

send fqdn.fqdn "myhost.example.local.";
send fqdn.server-update off;

RHEL5 ではファイルの場所が /etc/dhclient.conf となる。RHEL4 以前は知らない。

ネット上には、同じく dhclient.conf の host-name や ifcfg-* の DHCP_HOSTNAME でできるよ、みたいな情報も見つかる。しかし BIND ではそれで動くのかも知れない(未検証)が、社内の ActiveDirectory では動かなかった。

なお、dhclient.conf はデバイス(インターフェイス)毎に設定が可能で、その場合はグローバルな dhclient.conf は無視されるので注意。この辺はソースコードを見た方が理解が早い。

RHEL5.11: /etc/sysconfig/network-scripts/ifup-eth:

    # allow users to use generic '/etc/dhclient.conf' (as documented in manpage!)
    # if per-device file doesn't exist or is empty
    if [ -s /etc/dhclient-${DEVICE}.conf ]; then
       DHCLIENTCONF="-cf /etc/dhclient-${DEVICE}.conf";
    else
       DHCLIENTCONF='';
    fi;

RHEL6.7: /etc/sysconfig/network-scripts/network-functions:

generate_config_file_name () {
        local ver=$1
        if [ -s /etc/dhcp/dhclient$ver-${DEVICE}.conf ]; then
                DHCLIENTCONF="-cf /etc/dhcp/dhclient$ver-${DEVICE}.conf";
        elif [ -s /etc/dhclient$ver-${DEVICE}.conf ]; then
                DHCLIENTCONF="-cf /etc/dhclient$ver-${DEVICE}.conf";
        else
                DHCLIENTCONF='';
        fi
}

例えば私の環境では、RHEL5.11 のインストール直後に /etc/dhclient-eth0.conf が存在したので、この場合は /etc/dhclient.conf に設定を書いても無視される。

以上で、私の環境でも DNS にホスト名を登録できた。ただ個人的には、Windows PC からアクセスするだけなら Samba nmbd の方を勧めたい。わざわざ DNS レコードをゴニョゴニョせずに済むなら、それに越したことはない。

と、これで話が終われば幸せだった・・・。というか、こうして本エントリを書く必要すらなかった。残念ながら、以上は RHEL6 までの話。RHEL7 では話が変わる。:-(

周知の通り、RHEL7 では NetworkManager が幅を利かせていて、NetworkManager はシェルスクリプトで書かれた従来処理は使用せずに、自前で処理を行う。(ただし従来処理自体は存在していて、それらは NetworkManager が無効の時に使用される)

まず、dhclient.conf が未設定の状態でどう動くのか確認してみる。

[rhel7]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)

[rhel7]# rpm -q NetworkManager
NetworkManager-1.0.6-27.el7.x86_64

[rhel7]# cat /etc/dhcp/dhclient.conf
cat: /etc/dhcp/dhclient.conf: No such file or directory

このときデバイスの dhclient 設定は、デバイス起動時に下記の場所に生成される。

[rhel7]# cat /var/lib/NetworkManager/dhclient-enp0s17.conf
# NetworkManager で作成されています

send host-name "rhel7"; # added by NetworkManager

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
option ms-classless-static-routes code 249 = array of unsigned integer 8;
option wpad code 252 = string;

also request rfc3442-classless-static-routes;
also request ms-classless-static-routes;
also request static-routes;
also request wpad;
also request ntp-servers;

dhclient.conf を作ってデバイスを再起動すると、上記が再生成されるが・・・、

[rhel7]# cat /etc/dhcp/dhclient.conf
send fqdn.fqdn "rhel7.example.local.";
send fqdn.server-update off;

[rhel7]# systemctl restart network

[rhel7]# cat /var/lib/NetworkManager/dhclient-enp0s17.conf
# NetworkManager で作成されています
# /etc/dhcp/dhclient.conf からマージされています

send fqdn.server-update off;
send host-name "rhel7"; # added by NetworkManager

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
option ms-classless-static-routes code 249 = array of unsigned integer 8;
option wpad code 252 = string;

also request rfc3442-classless-static-routes;
also request ms-classless-static-routes;
also request static-routes;
also request wpad;
also request ntp-servers;

fqdn.fqdn がマージされていない!

ソースコードを確認してみる。

#define HOSTNAME4_TAG    "send host-name"
#define HOSTNAME4_FORMAT HOSTNAME4_TAG " \"%s\"; # added by NetworkManager"

#define FQDN_TAG    "send fqdn.fqdn"
#define FQDN_FORMAT FQDN_TAG " \"%s\"; # added by NetworkManager"

/* ...snip... */

char *
nm_dhcp_dhclient_create_config (const char *interface,
                                gboolean is_ip6,
                                GBytes *client_id,
                                const char *anycast_addr,
                                const char *hostname,
                                const char *orig_path,
                                const char *orig_contents,
                                GBytes **out_new_client_id)
{
	/* ...snip... */

			/* Override config file hostname and use one from the connection */
			if (hostname) {
				if (strncmp (p, HOSTNAME4_TAG, strlen (HOSTNAME4_TAG)) == 0)
					continue;
				if (strncmp (p, FQDN_TAG, strlen (FQDN_TAG)) == 0)
					continue;
			}

何故か fqdn.fqdn をスキップしている。かといってfqdn.fqdn が全て抹殺される訳でもなくて、

static void
add_hostname4 (GString *str, const char *format, const char *hostname)
{
	char *plain_hostname, *dot;

	if (hostname) {
		plain_hostname = g_strdup (hostname);
		dot = strchr (plain_hostname, '.');
		/* get rid of the domain */
		if (dot)
			*dot = '\0';

		g_string_append_printf (str, format, plain_hostname);
		g_free (plain_hostname);
	}
}

/* ...snip... */

static void
add_hostname6 (GString *str, const char *hostname)
{
	/* dhclient only supports the fqdn.fqdn for DHCPv6 and requires a fully-
	 * qualified name for this option, so we must require one here too.
	 */
	if (hostname && strchr (hostname, '.')) {
		g_string_append_printf (str, FQDN_FORMAT "\n", hostname);
		g_string_append (str,
		                 "send fqdn.encoded on;\n"
		                 "send fqdn.server-update on;\n");
		g_string_append_c (str, '\n');
	}
}

何故か IPv6 の方では fqdn.fqdn を設定している。IPv6 の動作は未確認だが、これだと IPv4 で fqdn.fqdn を送る術がないように見える。

もう NetworkManager ってほんと ks だわ、と思っていたら、

どうやら NetworkManager の設定項目に ipv4.dhcp-fqdn が増える模様。果たしてこれは RHEL7.3 に入ってくれるのだろうか。


2018-09-25 追記

あれから 2 年半、現段階での私の結論を記しておく。

まず、前述の修正は RHEL7.3 に入った。しかし私の環境では、全く状況は変わらなかった。これ以上はパケットキャプチャとか更なるソースコード解読とかが必要になるし、面倒いのでずっと放置していた。

その後、今度は dhclient のフックを使う方法を知った。

これは dhclient.conf に FQDN を記述するよりスマートな方法に思える。FQDN は hostname コマンドから引っ張ってこれるので、ハードコードが不要になるからだ。

しかし、これも動かなかった。orz

NetworkManager は dhclient のフックを呼ばないらしい。あれもダメ、これもダメ、一体どうしろというのか。NetworkManager 的には、「dispatcher を使え」とのこと。

/etc/NetworkManager/dispatcher.d/90-nsupdate:

#!/bin/bash

[ -n "$DHCP4_IP_ADDRESS" ] && [ "$HOSTNAME" != "${HOSTNAME/./}" ] \
    || exit 0

nsupdate <<EOF
update delete $HOSTNAME a
update add $HOSTNAME 3600 a $DHCP4_IP_ADDRESS
send
EOF

/etc/NetworkManager/dispatcher.d/pre-down.d/90-nsupdate:

#!/bin/bash

[ "$HOSTNAME" != "${HOSTNAME/./}" ] \
    || exit 0

nsupdate <<EOF
update delete $HOSTNAME a
send
EOF

後者の pre-down 処理は、対称性の観点(up 時に登録した名前を down 時に削除する)から作ったものの、実はあってもなくても同じ。何故なら、pre-down 処理はサーバーシャットダウン時に呼ばれない から。でもネットワーク再起動(systemctl restart network)では呼ばれる。これが仕様なのかバグなのかは分からないが、ほんとこれを作った奴はタヒんでいいよ。

あと、dispatcher 内で利用できる環境変数(例: DHCP4_IP_ADDRESS)は action (例: up, pre-down)毎に異なるのだが、それらは man を見てもいまいち明確でない。なので dispatcher を自作する場合は、まず set コマンドの出力をロギングする dispatcher を作り、利用可能な環境変数を確認してみることをお勧めする。

結論: やっぱり NetworkManager は ks。

2016-01-31

Animes in the 4th quarter of 2015

アニメは IT エンジニアの必須科目です。 ということで簡単なレビューを。

アクエリオンでなければ許せたが、アクエリオンの冠つけておいてこれは無いわ。よく 2 クールもやったもんだと逆の意味で感心する。ていうか、これ作った奴はクビじゃね?

絵が好みでないのもあるが、ヒロインが魅力に乏しい。騎士が仕える姫としては、単なる可愛らしさ以外の個性が欲しい。次回予告のノリは、個人的にはアリだった。

前期より視聴。相変わらず絵は綺麗だが、話が普通すぎる。親友との再会シーンは幾らでも面白くできただろうに、ピークがこれならこの先の盛り上がりも程度が知れる。

もうこの二つは一緒でいいよね。というかセットで見るべき。現在のテンプレというものが分かる。もういっそ、このテンプレート縛りでどこまで面白い作品が作れるのか競わせるのも面白い。個人的な評価は後者が上。その辺は、次回に続くか否か、という結果に表れている模様。

これも↑に入り込みそうだったが、辛うじてセーフ。しかしヒロイン達がチョロいのは変わらず。キャラは粒揃いだったと思うが、粒のまま終わってしまった感じで残念。

主役二人に魅力がないのが致命的。エロである理由も感じられない。最後の方を見ていて唐突に、「これ女版の聖闘士星矢にしたら面白かったんじゃね?」と思ったくらい。

キャラ絵が前世紀っぽくて逆に新鮮。話も独特で良いが、時間が飛ぶ展開には頭が付いていかなかった。ともあれ、次回どう収束させるのか期待。あと、アースちゃんは正義。

これも女子の理想が詰まったテンプレート。加えてミュージカルは歌の上手い・下手以前に、歌詞が圧倒的にダサい。それでもせめて歌の上手さで声優を選ぶべきだった。

この人の作るキャラは本当に個性的で、ただ感心する。最近の物語シリーズでは一番楽しめたと思う。ただ流石に、前回からの伏線回収を最後にブッ込まれても、もう覚えてないよ。

前期は未視聴だが、勉強のため視聴。正直、キャラデザは好みでないのだが、程なく皆がピョンピョンする理由が分かった。機会があればぜひ前期も見てみたい。

主人公のキャラデザを見てどうなることかと思ったら、これはこれでアリだった。設定上どうしても話が淡泊になりがちなので、ここからどう展開するのか興味深い。

シリーズも長いせいか、それぞれキャラも固まってきて安定してきた感じ。少なくとも以前のように必死なだけで見ていて寒いギャグが減った。今後は安心して見られそう。

分類はミステリー作品なのだろうが、謎解きに面白さが感じられず、ヒロインにも入れ込めず。今回に限っては、伊藤静のキャスティングは失敗だったような気がする。

前期に続き視聴。本作を見ても、何が面白いのかさっぱり分からない。エロも変わらずエロくないし。むしろ各キャラに焦点が当たっていた分、一期目の方がまだ見られた。

見る前はミステリーとは予想もしなかったが、結果、十分に楽しめた。今さら 16bit かよ、という突っ込みも、原作が 20 年前ならば納得。今回は種崎敦美の演技と甲斐田裕子の英語を褒めたい。

第 1 クールと合わせて視聴。十年以上前の作品(第一期)を、復習なしで平然と続けることに驚き。にもかかわらず、かなり真剣に見てしまった。これは第一期より相当面白くなった気がする。(もう覚えてないけど)

2015-11-30

RHEL7: Old PostgreSQL's initdb fails

下記の環境で PostgreSQL 8.4.17 をビルドすると、

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.1 (Maipo)

# rpm -q gcc
gcc-4.8.3-9.el7.x86_64

initdb コマンドでエラーが発生。

# su - postgres -c "/usr/local/pgsql-8.4.17/bin/initdb -E UTF8 --no-locale -D ./data" ; echo $?
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.
The default text search configuration will be set to "english".

creating directory ./data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 32MB
creating configuration files ... ok
creating template1 database in ./data/base/1 ... ok
initializing pg_authid ... FATAL:  wrong number of index expressions
STATEMENT:  CREATE TRIGGER pg_sync_pg_database   AFTER INSERT OR UPDATE OR DELETE ON pg_database   FOR EACH STATEMENT EXECUTE PROCEDURE flatfile_update_trigger();

child process exited with exit code 1
initdb: removing data directory "./data"
1

調べると、GCC 4.8 で発生するらしい。

上記では、結局 GCC 4.7 でないと駄目だった模様。他のネット情報を見ても、大体「GCC 4.7 使え」的な感じ。しかし RHEL7 DVD には GCC 4.7 が入っていないので、解決策がそれだと(個人的に)非常に困る。:-(

という状況で、駄目元で 8.4 系の最新(8.4.22)を取ってきたら、何事もなく動いた。助かった! :-D

該当の部分は多分これ。PostgreSQL 8.4 系では、8.4.18 で入っている。一応、8.4.18 で initdb が動くことは確認した。

現時点で、8.2 / 8.3 の HEAD に対しても同様の修正が入っている。私のように困っている人は、HEAD を落としてくると幸せになれるかも。

2015-10-31

Animes in the 3rd quarter of 2015

アニメは IT エンジニアの必須科目です。 ということで簡単なレビューを。

赤髪という時点でヒロインに強い個性を期待してしまうのだが、その意味でヒロインはキャラが弱かった。話は癖なく纏まっているだけに、タイトル負けした感が強い。

前期より視聴。キャラの多さには慣れたが、何故に話を暗くするのか。原作ファンはこれで満足しているのか疑問。唯一、安易にポリゴンに逃げなかった所だけは評価する。

三期目ということで視聴。ここから見ると既に纏めに入った感を受けるが、各キャラの個性は十分に感じられた。しかし、未視聴分を見ようという気までは起きなかった。

ヒロインが個性的で見て楽しいが、中の人の演技に依る所が大きい。相対的に、他キャラが弱い。原作は四コマらしいが、見てるとそうは思えず、よく話を纏めたなと思う。

前期より視聴。股間へのダイブはもう慣れた。遅ればせながら、ようやく委員長の魅力が分かった気がする。あと、初話でのキャラの違和感がパなかったが、二話目から直った?

最近増えてきた声優業界ネタ。個人的には勉強になるので歓迎だが、本職の人は心に刺さって見るのが辛いのでは?と心配する。で結局、堀江由衣はユリエホイでいいのん?

ヒロインと中の人、キャラ絵のマッチングが素晴らしい。欲を言えば、他の女子三人にもう少し頑張ってもらいたい。しかし今のままでも十分なので、是非とも次回を希望。

地上最強の好き嫌いはともかく、途中から激しくグダる。たぶん、誰もこの作品に「犯人は誰だ!?」的な要素は求めていないと思う。で早速、次回もグダる予感しかない。

またタイムリープ物か、と食傷気味。主人公もパッとしないし、話も取って付けたような内容。だが妹の話だけは良かった。あれなら私もシスコンになれる自信がある。

まだ私には難度が高かったらしく、萌えられず。終わりまで新キャラペースが落ちず、しかも後半ほど難度が上がるという。一般人への布教としては、少し性急だったと思う。

シリーズ視聴。もういい加減、ダラーズの話は漏れなく盛り下がるのでやめて欲しい。今後、カラーギャングと折原の話は禁止でお願いします。いや割とマジで。

主人公は全能で王様プレイ、カテゴリ的には中二病作品だが、何故か苦痛なく見られた。にしてもアルベドは立ち位置ヒロインだろうに、あの残念キャラは何とかならなかったのか。

  • 俺物語!!

少女マンガ原作のアタリは久しぶり感。藩めぐみの演技パない。女子キャラも総じて魅力的。ところで砂川くんのキャラ付けは、やはり女子は○モが好き、ということで良いのだろうか。

話題になっている理由が分からなかったが、原画をチラ見して察した。たぶん漫画から入った人は「この漫画は凄い!」、アニメから入った人は「よく分かんない」となる気がする。

ここまで直球だと最早褒めて良いレベル。石上静香は間違いなく株を上げた。ところで個人的に会長がエロくて良いなと思っていたら、光の速さでビッチになっていた件。

何やら壮大なコラボレーション企画のようで、設定などは非常に凝っており感心するレベル。が、アニメ化に際して凡作になった模様。設定を文字で語るのはアニメとして手抜きだと思う。

これこそ勉強のために見なければ、と見たら色んな意味で想像を超えていた。これがオリジナルの雰囲気をどれ程反映しているのか分からないが、色々と勉強になった。

当時のリアルタイム世代は、見るだけで感慨深いものがあると思う。私も該当するため評価が難しいが、たぶん思い出補正がないと、クソつまらないような気はしている。

可もなく不可もなく、お気に入りのキャラも居なかったため、個人的に非常に評価に困る。結局この作品は、SF、友情、恋愛、その他の何がウリだったのだろう。

昔に小説を途中まで既読。なのでキャラデザには違和感しかない。特にダリューンはもっと華奢でないと駄目だろう、と。絵も話も、私には小説の劣化版に見えてしまう。

シリーズ視聴。今回は「美々の夏休みデビュー」、これに尽きる。この回だけで見た甲斐はあった。逆にシリアス系とかバトルとか、つまらないのでもうやらなくて良いです。

絵が好みでないというハンディを最後まで挽回することができなかった。その中で委員長は惜しかったが、私が萌えるにはまだ足りない。

今回が初視聴だが、私の時系列的に「世界一初恋」にしか見えない。まんま同じキャラやん? 同じ出版業界やん? でやっぱ BL やん? つまり作者は、野球漫画におけるあだち充(BL 版)だと理解した。

テンプレの寄せ集め感。普段から格好良さげな主人公に、いざという時まで格好良くさせたら、余程のことがない限りつまらなくなるのになぜ気が付かないのだろうか。

まず主人公をミスリードさせる導入。それでも中盤まではまずまずだったが、最後、突然のゴリ押しにぽかーん。これ、やっぱり少年を主人公にすべきだったのでは。

2015-08-31

RHEL7: screen: Window title is annoying

screen 使いが RHEL7 を使った時、間違いなく不満に思うこと。

ウィンドウタイトルが ウ ザ い

無駄に長いし、cd する度に長さがパタパタ変わるし、ディレクトリを潜る度にどんどん長くなるし、そのせいで簡単に横幅が溢れるし、とても我慢できたものではない。何故これが初期設定なのか理解不能。誰か喜ぶ人いるの?

調べると、PROMPT_COMMAND のせいらしい。手持ちの環境でざっと比べると、

CentOS 5.5: /etc/bashrc:

# are we an interactive shell?
if [ "$PS1" ]; then
	case $TERM in

	# <...snip...>

	screen)
		if [ -e /etc/sysconfig/bash-prompt-screen ]; then
			PROMPT_COMMAND=/etc/sysconfig/bash-prompt-screen
		else
		PROMPT_COMMAND='echo -ne "\033_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}"; echo -ne "\033\\"'
		fi
		;;

CentOS 6.2: /etc/bashrc:

    screen)
        if [ -e /etc/sysconfig/bash-prompt-screen ]; then
            PROMPT_COMMAND=/etc/sysconfig/bash-prompt-screen
        else
            PROMPT_COMMAND='printf "\033]0;%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
        fi
        ;;

RHEL7.1: /etc/bashrc:

    screen*)
      if [ -e /etc/sysconfig/bash-prompt-screen ]; then
          PROMPT_COMMAND=/etc/sysconfig/bash-prompt-screen
      else
          PROMPT_COMMAND='printf "\033k%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
      fi
      ;;

実は各バージョンで微妙に違った。ともかく、RHEL7 の設定だけは看過できない。暫く考えて、次のスクリプトを配置することにした。

/etc/profile.d/myscreen.sh:

if [ -n "$PROMPT_COMMAND" ] ; then
    case "$TERM" in
	screen*) PROMPT_COMMAND=${PROMPT_COMMAND/\\033*\\033/\\033k\\033} ;;
    esac
fi

(嬉しい)副作用として、.screenrc に下記の設定を入れると、ウィンドウタイトルが実行中のコマンド名になる。root でなく一般ユーザーなら、「#」の代わりに「$」を使う。確認はしていないが、RHEL6 以前でも動くはず。

~/.screenrc:

shelltitle "#|bash"

RHEL7 のこの仕打ちは、tmux 使いの嫌がらせ 老兵は去れというメッセージかも知れないが、老兵と言えども消えゆくにはまだ早い。screen であと十年は戦える。

2015-08-03

Animes in the 2nd quarter of 2015

アニメは IT エンジニアの必須科目です。 ということで簡単なレビューを。

作者のメルマガは(何故か)購読。てっきり、ゆう医師がおっぱいおっぱい言ってる作品かと思ったら、むしろ医師以外がみんな変態で、「心療内科」的には確かに間違ってはいなかった。

前期に続き視聴。原作を知らない私でも、この辺から「ああ、JoJo だな」と感じる。ただ、あれだけ引っ張った割にはディオとの最終決戦が割と呆気ない。

血闘術には独特のセンスを感じる。中二辺りにはウケが良さそう。ただ戦闘を離れたパートがクソつまらないのと、どうにも主人公が好きになれないのでいまいち乗れない。

前シーズンより視聴。今度はアーチャーが面倒臭い奴になったなと思ったら、「ああ、このオチ聞いたことあるわ」と納得。どうやら私は相当に主人公の性格を受け付けないらしい。

元の四コマをただくっ付けただけなのか、全体的にテンポが非常に悪い。原作を読んだことはないが、これでは原作の持ち味を引き出せていないような気がする。

最初に予想したより随分あっさりした展開。親友同士が戦うという設定上、もっと愛憎渦巻く展開を期待したのに。もっとも今後そうなるのかも知れないので様子見。

長い主人公の回想が終わったと思ったら、どこからか湧いてきた女子たちによる主人公の奪還作戦。エロゲ原作なのにエロもなく、何をどう評価して良いのか分からない。

原作は途中まで既読。ヒロインを始めとする女子キャラの魅力は損なわれずに移植できていると思う。連載は結構長かった気がするが、一クールに収まるとは相当削ったのかも知れない。

仕事を選ばないサンリオが、まさかの萌えの世界に。SD キャラの必然性が最後まで分からなかったが、これで音ゲーを出す未来までは見えた。今回は、稲川英里を覚えた。

最初はヒロインのオヤジっぽさにドン引きするが、見続けていると慣れる。それでも全体的に取って付けた感は拭えない。そもそも何故これをアニメ化しようと思ったのか。

前作は視聴したはずだが殆ど覚えてない。今作はこれといった敵も居らず、ひたすら内輪で馴れ合っているだけの印象。そもそも負かした相手に指南してもらうってどうなの。

悲しい結末を迎えることが分かりきっている設定は余り好きではない。予想したよりはずっと良い話に纏まったが、ともすると鬱になる危うい設定だと思う。

キャラクターはおっぱいの押し売り。正直これを書いてる今も、おっぱい大きかったなー、くらいしか思い出せなくて困る。

前作より視聴。相変わらずの鉄板クオリティ。何も言うことはないので、この調子で続きを頼む。

「例の紐」と聞いて。正直それのためだけの視聴だったが、なにこれ、SAO より余程おもしろい。やはり、主人公が全能なのは作品をつまらなくするのだと再認識。

ぼっち待望の続編。途中がグジるのと終わりが良く分からないのを除けば、全体としては満足。で、これ続くの? ていうか続かないと先が気になるんだけど。

最近やたらタイムリープ物が多いな。本作は前半の伏線を後半できっちり回収できている感じで、もう一回見ようと思えるくらいには優秀。でも OP にしょこたんは要らんかったわ。

2015-07-15

RHEL7: `firewalld' dies at `reload'

firewalld の reload が失敗する。正確には、reload は成功するが firewalld が死ぬ。しかも死ぬのは決まって 2 回目の reload で、初回は上手くいく。

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.1 (Maipo)

# systemctl restart firewalld ; echo $?
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2015-07-15 18:12:16 JST; 5s ago
  Process: 4566 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 4597 (firewalld)
   CGroup: /system.slice/firewalld.service
           `-4597 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 15 18:12:16 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:12:16 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
0

# systemctl reload firewalld ; echo $?
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2015-07-15 18:12:16 JST; 33s ago
  Process: 4924 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 4597 (firewalld)
   CGroup: /system.slice/firewalld.service
           `-4597 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 15 18:12:16 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:12:16 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Jul 15 18:12:27 rhel7 systemd[1]: Reloading firewalld - dynamic firewall daemon.
Jul 15 18:12:27 rhel7 systemd[1]: Reloaded firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
0

# systemctl reload firewalld ; echo $?
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: inactive (dead) since Wed 2015-07-15 18:12:53 JST; 3s ago
  Process: 5266 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
  Process: 4597 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=killed, signal=HUP)
 Main PID: 4597 (code=killed, signal=HUP)

Jul 15 18:12:16 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:12:16 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Jul 15 18:12:27 rhel7 systemd[1]: Reloading firewalld - dynamic firewall daemon.
Jul 15 18:12:27 rhel7 systemd[1]: Reloaded firewalld - dynamic firewall daemon.
Jul 15 18:12:53 rhel7 systemd[1]: Reloading firewalld - dynamic firewall daemon.
Jul 15 18:12:53 rhel7 systemd[1]: Reloaded firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
3

systemd 経由ではなく、「firewall-cmd --reload」で reload すると問題は起こらない。

# systemctl restart firewalld ; echo $?
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2015-07-15 18:13:22 JST; 2s ago
  Process: 5266 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 5271 (firewalld)
   CGroup: /system.slice/firewalld.service
           `-5271 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 15 18:13:22 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:13:22 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
0

# firewall-cmd --reload ; echo $?
success
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2015-07-15 18:13:22 JST; 18s ago
  Process: 5266 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 5271 (firewalld)
   CGroup: /system.slice/firewalld.service
           `-5271 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 15 18:13:22 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:13:22 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
0

# firewall-cmd --reload ; echo $?
success
0

# systemctl status firewalld ; echo $?
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2015-07-15 18:13:22 JST; 39s ago
  Process: 5266 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 5271 (firewalld)
   CGroup: /system.slice/firewalld.service
           `-5271 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 15 18:13:22 rhel7 systemd[1]: Starting firewalld - dynamic firewall dae.....
Jul 15 18:13:22 rhel7 systemd[1]: Started firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
0

どうやら firewalld の HUP 受信処理に問題がありそうだ。試しに firewalld プロセスに直接 HUP シグナルを送ってみると、現象が再現した。最初の HUP 処理後にシグナルハンドラーを再登録してないっぽい? (ソースコードは未確認)

以上より、

  • 「systemctl reload firewalld」ではなく、「firewall-cmd --reload」を使うべし。
  • もしくは「systemctl restart firewalld」を使う。(但し確立中の接続は切れるかも?)

今後これが修正されるとしても、firewalld のバージョンに依存しないように RHEL7 では上記を徹底するのが良いかも知れない。もちろん嫌なバッドノウハウであることは認める。:-(

ググってみると、Red Hat Bugzilla には見当たらなかったが、CentOS の方で報告されていた。本家の方でも待っていればそのうち直ると思われる。


2016-05-31 追記

Red Hat Bugzilla にも登録された模様。