inode
Linuxの伝統的なファイルシステム ext2、ext3の仕組みで、ファイル情報のメタを「inode」と呼ぶ。
確認方法
ls -li
stat <filename>
zoneファイルの更新でいくつかハマった。 二度とないようにメモっておく。
TTLの更新。例えばドメインやIP変更前にわざと短くして配布しておき、本変更をすぐに世界のDNSキャッシュに反映させるあれ。
zoneファイルの置き場について。
場所は設定ファイルに記述されているんだけど、俗にいうchrootして設定ファイルの場所が変わっている場合がある。
chrootしているかどうかを見るには、bindの起動コマンドに-t
オプションが付与されているかを見る。
ps aux | grep named
結果
named 643 0.0 0.9 30268 2336 ? S Jan05 0:07 /usr/sbin/named -u named -t /var/named/chroot
見方といっても、変更に最低限必要なものだけ。
全体設定ファイルnamed.confは、デフォルトでは/etc/named.conf
に配置されている。
chrootしている場合、頭のパスにchrootしたパスをつけたものになる。
less /var/named/chroot/etc/named.conf
見るところは以下の通り。
設定ファイル内に相対パスで記述したときに基準となるファイルパス。例によってchrootの影響を受ける。
options { ... directory "/var/named"; ... };
ゾーン情報の設定。 ドメインとゾーンファイルが指定。ゾーンファイルパスは例によってdirectoryオプションとchrootの影響を受ける。
ちなみに、type slave;
が記述されている場合、プライマリDNSから設定がtransferされるようになっているはずなのでゾーンファイル変更不要。
options { ... zone "hoo.var.com" { type master; file "hoo.var.com.zone"; } ... };
以下を変更。
1) TTLを短くする。以下、例。
$TTL 8H
↓
;$TTL 8H $TTL 600 ; 10 minutes
2) serialをあげる
一般的には、変更日のYYYYMMDD + 連番2桁 として管理を楽にする。
2015112801
↓
2017022601
serialが新しくないと、reloadしても設定を読み込んでくれない。 戻し作業で再変更する場合は、連番を上げたバージョンを用意する。
2017022602
3) minimumの変更
仮にDNSサーバーが落ちて解決不能となったときに、落ちてるから問い合わせても無駄だよ期間を指定する Negative-TTL の値。 別にTTLの2倍程度だったら問題ないんだけど、それ以上だと復旧しているのにキャッシュに残ったせいで復旧が遅れることがあるらしいので、変更しておく。
あと、いつの時代の基準化わからねど、普通はTTLと同じにするそうだ。(大手サービスでDNSサーバーに余力のあるところは数秒とかに設定しているとこも多いそう。)
8H ; minimum
↓
600 ; minimum
root
じゃないと操作できないから気を付けてね。
設定ファイルを上書きする。
※言うまでもなくだけど、cp -ip
でちゃんとバックアップとってね
named-checkzone "hoo.var.com" /var/named/chroot/var/named/hoo.var.com.zone
OKが出力されたらエラーなし。
chrootしているときは -t オプションを使う。
以下、chrootしながら/var/named/chroot/etc/named.conf
をチェックする例。
named-checkconf -t /var/named/chroot /etc/named.conf
何も出力されなかったらエラーなし。
これはnamed.conf
のチェックしかしないので注意。
-z
オプションでゾーンファイルのチェックもできるけど、正常メッセージでもわっと出たときに初見びびるかも。
rndc reload
自分に向けてdig。SOAレコードと正引きの2つともテストする。
dig @127.0.0.1 hoo.var.com
色々いっぱい出るけど、
;;AUTHORITY SECTION:
にserialとminimumが載ってればOK。
dig @127.0.0.1 www.hoo.var.com
こちらは、
;; ANSWER SECTION:
に TTLつきで正引きの結果が表示される。
メモおわり。
chroot
と、zoneファイルのタイムスタンプが罠だった。
bind以外のDNSサーバーだとどうなのかな。
ちょっと本格的にAngularを再開。
色々作りこんでいく中でいくつか悩みとアイディアが出たのでメモ。
顧客管理のようなシステムを作っている。
顧客への「発送」業務があり、これは顧客によりあったりなかったりする。
データモデルがつまり 顧客
1 ― * 発送
という形になっている。
基本的にresource型のRestfulAPIを守ろうとしたが、 どうしてもブラウザ上で「顧客」を登録してから「発送」を登録することになる。
ただでさえ遠いWebサーバーに2往復もするのに加えて、 業務手続でできれば分離したいコードが、準コントローラーなコード中にむき出しになってしまう。 しかもこれは、1画面に1つ占有するコードみたいなもので、再利用が難しい。(思い切ってService化するのもアリだが)
Restじゃなくて、普通にWebAPI化しようとも悩んだ。(あくまで業務手続という体を守りつつ、実質1画面専用のAPI) がしかし、どうしてもパラメータが複雑になってしまう。 変なJSONにしてPHPとPOSTパラメータの周りをうろちょろするぐらいなら、 JSON親和性の高いうちに、クライアントでシンプルなAPIパラメータに変形してしまったほうが良いだろう。
・・・と思い、結局RestfulAPIで、クライアントにもりもりコードを持っていくスタイルを取った。 WebAPIのリクエストベースなテストも書きやすくなるしね。
しかし、Angularのテスト可用性が本当に死んでいる。 もともとリッチUIの予定だったので、打検はもともとだったが。。
HTMLのValidatorAPI
。ありゃだめだった、エラーメッセージが1つしか出ない。
おとなしくAngular
の$validations
なりフレームワークやライブラリに頼って、
ラベルか自分でポップアップするかしたほうがよさそう。
ちょっと本格的にAngularを再開。
色々作りこんでいく中でいくつか悩みとアイディアが出たのでメモ。
顧客管理のようなシステムを作っている。
顧客への「発送」業務があり、これは顧客によりあったりなかったりする。
データモデルがつまり 顧客
1 ― * 発送
という形になっている。
基本的にresource型のRestfulAPIを守ろうとしたが、 どうしてもブラウザ上で「顧客」を登録してから「発送」を登録することになる。
ただでさえ遠いWebサーバーに2往復もするのに加えて、 業務手続でできれば分離したいコードが、準コントローラーなコード中にむき出しになってしまう。 しかもこれは、1画面に1つ占有するコードみたいなもので、再利用が難しい。(思い切ってService化するのもアリだが)
Restじゃなくて、普通にWebAPI化しようとも悩んだ。(あくまで業務手続という体を守りつつ、実質1画面専用のAPI) がしかし、どうしてもパラメータが複雑になってしまう。 変なJSONにしてPHPとPOSTパラメータの周りをうろちょろするぐらいなら、 JSON親和性の高いうちに、クライアントでシンプルなAPIパラメータに変形してしまったほうが良いだろう。
・・・と思い、結局RestfulAPIで、クライアントにもりもりコードを持っていくスタイルを取った。 WebAPIのリクエストベースなテストも書きやすくなるしね。
しかし、Angularのテスト可用性が本当に死んでいる。 もともとリッチUIの予定だったので、打検はもともとだったが。。
HTMLのValidatorAPI
。ありゃだめだった、エラーメッセージが1つしか出ない。
おとなしくAngular
の$validations
なりフレームワークやライブラリに頼って、
ラベルか自分でポップアップするかしたほうがよさそう。
これで、Scriptトリガーの日本語英語切り替えが楽になる。
長さなどを文字列埋め込みできるようにメッセージをformatできるようにすればよかったけど、 Formatメソッド作らなきゃいけなくなるから削る。