Mindblown: a blog about philosophy.

なんか設定変えた記憶ないのに動作が変わってしまったGNU screen。 いくつか自前でパッケージ再作成してたりexperimentalからもらってきたりしてるからその関係かもしれないけど。 探しているとまず見つかるのは /etc/systemd/logind.conf に KillUserProcesses=No を書け。 だった。 書いてみたけど動作が変わらない。 systemctl daemon-reloadもやってみたけど同様。 もしかしたら要再起動だったりするかもしれないけどとりあえず保留。 screenを起動するときに systemd-run –scope -user screen で起動しろ、ってのもあったけど、これもダメ だった。 別の端末(別窓teraterm)からscreen -R -DD するとちゃんとセッション切り替わるのだが、screenの動いているTeratermを終了させるとそのタイミングでscreen下のプロセス全部killされるっぽい。 今までどうして動いてたんだ、という気もしつつ、よくよく調べてみたら、 loginctl enable-linger user しろというのがあったのでやってみたら、ビンゴ。 とりあえず一発loginctl enable-linger打っておいて、あとは systemd-run –scope –user screen -R -DD を.bashrcでばばそ、で今まで通りになったっぽい。 前はKillUserProcesses=No だけでできてたと思ったんだけどなぁ

何となく眺めていたら面白い記述を発見。 nslcd.conf に uri DNS:domain と記述すると、_ldap._tcp.domainからSRVレコード引っ張ってきて名前解決してくれる。 今までどうしてSRV見てくれないんだろうと思っていたら、こういう設定方法があったらしい。 uri ldapi:/// dns:domain と記述すると、最初にldapiで接続、ダメならSRVの優先順位高い順に見てくれる。 これで再起動とかのタイミングでgetentに時間がかかる問題が解決する！ かもしれない。 しかしこの設定はldap.confでは使えないのであった。 今のところ、SRVレコード見ているのはsambaの_kerberosとaptの_httpぐらいだけどね 今試してみたら、aptもSRV対応で、 Acquire::http::Proxy に http://proxy.domain と書いてあると、 _http._tcp.proxy.domainを見に行ってSRV解決してくれるっぽい。 これもsquid止めたりした時に自動的に回避してくれるっぽいのでありがたい。 _http._tcp.proxy.domain見に行くから変だなあと思っていたらこういうことだったのね これだとポートの指定もしなくていいっぽい。 と思ったら、apt-getとかはうまくいくけど、apt-listbugsとかがproxy見に行くの失敗しているっぽい。 ポート指定すれば動く。惜しい。

なんか接続が遅いなーと思いつつ、放置していた件。 接続一発目が遅いときの一番の原因は大概、DNSだったりするのだが、よくわからんまま放置モードが続いていた。 まあ、ログにも managed-keys-zone: No DNSKEY RRSIGs found for ‘.’: success とか出てたので多分DNSSECおかしいんだろうなーとは思っていたｗ ざっくりすると、ローカルの設定はそれなりに良かったぽい。 上流のDNS (forwarders) がDNSSEC未対応のため、というのが理由っぽい。 できればDNSはipv6経由でやりたいのだが、そういうわけにもいかない場合もあるということで。 とりあえず、ひかり電話ありのONUはDNSSEC対応っぽい。 ひかり電話なしのONUは対応していなかった。 ついでにBiglobeのDNSはDNSSEC対応とそうじゃないのがあるようで、bind9のforwadersにDNSSEC対応DNSを指定したらエラーは出なくなった。 この設定でちょっと様子見。