aptとw3mとlibgpm

最近aptのbuildに失敗するなぁと思っていたのだが、実はw3mの問題だったというお話。

現在、gpmにはexperimentalが来ていて、1.20.7-1と1.20.4-6.2があるのだが、libgpmに依存しているw3mとかemacsにはバージョン条件が入っていなくて、experimentalだと動かない、という問題がある。

で、aptのbuild-depにはw3mが入っていてw3mが使われているのだが、そこでw3mを起動しようとするとエラーになっていたのだが、見た目エラー内容がわからないために何でエラーになっているのかわからない状態になっていた。

たまたまhtmlで書かれたメールをemacsのwanderlustで見ようとしたら、w3mでフォーマットしようとして失敗する、というのを発見してあれ?と思ったのがきっかけ。

とりあえずlibgpm-devとlibgpm2をunstable 1.20.4-6.2にしてみたらaptのbuildもできたし、htmlメールも(一応)見れるようになった。

void time

最近全く新月の願いやってないなーと思いつつ、Googleカレンダーに新月とvoid timeの登録をやってみた。

まずはStargazerでヴォイドタイム時期表と進行経過時期表で、void timeと、太陽・月のコンジャンクションの時間を出す。

Excelでgoogleのcsvに合うように変形してインポート。
とりあえず、新月は48時間設定してみる。

誰か作ってそうなんだけどなぁ・・・

systemdとGNU screen

なんか設定変えた記憶ないのに動作が変わってしまった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 だけでできてたと思ったんだけどなぁ

LDAP srvレコード

何となく眺めていたら面白い記述を発見。

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見に行くの失敗しているっぽい。
ポート指定すれば動く。惜しい。

dnssec

なんか接続が遅いなーと思いつつ、放置していた件。

接続一発目が遅いときの一番の原因は大概、DNSだったりするのだが、よくわからんまま放置モードが続いていた。
まあ、ログにも
managed-keys-zone: No DNSKEY RRSIGs found for ‘.': success
とか出てたので多分DNSSECおかしいんだろうなーとは思っていたw

ざっくりすると、ローカルの設定はそれなりに良かったぽい。
上流のDNS (forwarders) がDNSSEC未対応のため、というのが理由っぽい。

できればDNSはipv6経由でやりたいのだが、そういうわけにもいかない場合もあるということで。

とりあえず、ひかり電話ありのONUはDNSSEC対応っぽい。
ひかり電話なしのONUは対応していなかった。
ついでにBiglobeのDNSはDNSSEC対応とそうじゃないのがあるようで、bind9のforwadersにDNSSEC対応DNSを指定したらエラーは出なくなった。
この設定でちょっと様子見。