きょうのつぶやき@digitune

きょうのつぶやき@digitune

CSSいじりだすと時間がいくらあっても足りん(汗。 (07:20 PlumeforAndroidから・詳細)

「ebb and flow」って潮の満ち干きのことだったのか。 (07:24 PlumeforAndroidから・詳細)

物語の中で月が破壊されることはままあるけれど、本当にそうなったらどうなる？という話を昨日あゆみさんとした。潮の干満が無くなるときっと生態系に大きな影響があって、おそらく大絶滅が起こる。生命は強いからそのうち復活するかもだけど、一時的な停滞は避けられないんじゃないかなぁ。 (07:27 PlumeforAndroidから・詳細)

まぁどんな風に破壊されるのかにもよるか。バラバラに割れる感じなら、そうはいってもほとんどの質量はしばらく元の位置に留まり徐々に散逸していくのだとすると、そこまで急速な変化は起こらず生き物も対応可能なのかも。 (07:42 PlumeforAndroidから・詳細)

これを見るとskeletonは明らかにbootstrapを意識して作ってる感じがするなぁ＞Responsive CSS Framework Comparison: Bootstrap, Foundation, Skeleton http://responsive.vermilion.com/compare.php (12:37 Twitter Web Clientから・詳細)

おうちサーバの「dnssec-validation auto;」なbind9が起動直後だけbad cache hit (./DNSKEY) error (broken trust chain)で名前解決出来ない件、原因らしきものがわかった気がする。 (15:57 Twitter Web Clientから・詳細)

夜にまとめて書こう。 (15:59 Twitter Web Clientから・詳細)

起動直後だけbindがうまく動かない件、原因は時計にありました。DNSSECのキャッシュには有効期限が設定されており、マシンの時計が狂っていると正常に動作しないことがあるのは結構よく知られた問題だったらしい(いわゆるFAQ)。 (21:53 PlumeforAndroidから・詳細)

おうちサーバでは当然ntpも動作させていますが、なぜかdebian標準の設定ではntpよりもbindの方が先に起動するようになっており、しかもおうちサーバはNAS由来のせいかリブートすると必ず時計がoriginまで巻き戻る→ntpで補正、という動きをしていたことなどが原因っぽい。 (21:57 PlumeforAndroidから・詳細)

/var/log/daemon.logを眺めているときにタイムスタンプがやたら飛んでいること、DNSSECの紹介記事に時計に注意、と書いてあったことなどで気がつきました。やーかなり難易度高いねこれ。 (21:59 PlumeforAndroidから・詳細)

RT @satoh_fumiyasu: .@OrangeMorishita @digitune 「常に」は、「いいえ」。Debian で起動時に確実に時刻合わせしたいなら、ntpdate パッケージを入れるべきです。ntpd は step で時刻合わせする設定になっているとは限… (22:15 PlumeforAndroidから・詳細)

ためしてみよ＞RT (22:15 PlumeforAndroidから・詳細)

早速ntpdate入れて再起動してみたけど、それだけでは解決しないみたいだなぁ。ntpdate[2033]: step time server 157.7.235.92 offset 1429712045.539244 secとかスゴい時計ズレてて笑えるｗ。 (23:17 Twitter Web Clientから・詳細)

ntpdateはif-up.dで起動されるみたいなのに、それよりもbindの起動の方が速い、ってのはなんなんだ。ntpdateが時計を合わせ終わるのが起動後30秒過ぎくらいなのに対し、bindのログは起動後15秒前後から出力され始めている。bindの起動を遅らせるしかないのかな。 (23:21 Twitter Web Clientから・詳細)