2017年06月
2017年06月30日
Webminはダウンロードします。
現在は webmin-1.850-1.noarch.rpm というのがありました。
必要なモジュールを求められるのでインストール
yum install perl-Net-SSLeay perl-Encode-Detect
webmin-1.850-1.noarch.rpm をインストールします。
あとは iptables などのFWの設定を変更し、webmin にアクセスすることができました。
パスワードは以下のコマンドで変更可能です。
/usr/libexec/webmin/changepass.pl /etc/webmin [USERNAME] [PASSWORD]
現在は webmin-1.850-1.noarch.rpm というのがありました。
必要なモジュールを求められるのでインストール
yum install perl-Net-SSLeay perl-Encode-Detect
webmin-1.850-1.noarch.rpm をインストールします。
あとは iptables などのFWの設定を変更し、webmin にアクセスすることができました。
パスワードは以下のコマンドで変更可能です。
/usr/libexec/webmin/changepass.pl /etc/webmin [USERNAME] [PASSWORD]
2017年06月29日
2017年06月28日
僕が管理しているメールサーバーですが、今まではスペックの低い専用サーバーを利用していました。
かつては、スペックが低すぎて、ちょっとした何かがあっただけで、メールがダウンしていました。
これではまずいということで、受信サーバーについては、1台別に構築し、負荷分散をしていました。
例としては以下のような感じです。
■受信
外部 → M-SV01 → M-SV02
■送信
M-SV02 → 外部
ということで、外部からのメールについては、M-SV01 がリレーサーバーとして機能しています。
このとき、メールのログで Received の行が、M-SV01の分余計になってしまいます。
受信の時以下のような感じです
Received: M-SV02
Received: M-SV01
Received: 外部サーバー
※メールのログは、下から上に読みます。この場合は、外部から送られてきたメールのログです。
で、M-SV02 ではメールのウイルススキャンなどを行っています。
■スキャン
外部 → M-SV01 → M-SV02(ウイルススキャン)
このとき、M-SV02から見ると、すべての正常なメールもスパムメールも M-SV01 から届いているように見えます。そのためフィルターの精度が落ちるのでは無いかと心配していました。
※特に気づくような実害はありません。
また、ウイルススキャンのログを見ても、ウイルスをもっとも多く送ってくるサーバーとして、ダントツの1位となっていました。そりゃそうですよね。
これではなんだ気持ち悪いので、以下の設定を行いました。
※本当はM-SV01でやりたかったのですが、header_checks はリレーよりも後に行われる処理なのか？正しく動作しませんでした。そのためM-SV02に設定。
・main.cf
header_checks = regexp:/etc/postfix/header_checks
/^Received:.*M-SV01/i IGNORE
これで大丈夫でした。
かつては、スペックが低すぎて、ちょっとした何かがあっただけで、メールがダウンしていました。
これではまずいということで、受信サーバーについては、1台別に構築し、負荷分散をしていました。
例としては以下のような感じです。
■受信
外部 → M-SV01 → M-SV02
■送信
M-SV02 → 外部
ということで、外部からのメールについては、M-SV01 がリレーサーバーとして機能しています。
このとき、メールのログで Received の行が、M-SV01の分余計になってしまいます。
受信の時以下のような感じです
Received: M-SV02
Received: M-SV01
Received: 外部サーバー
※メールのログは、下から上に読みます。この場合は、外部から送られてきたメールのログです。
で、M-SV02 ではメールのウイルススキャンなどを行っています。
■スキャン
外部 → M-SV01 → M-SV02(ウイルススキャン)
このとき、M-SV02から見ると、すべての正常なメールもスパムメールも M-SV01 から届いているように見えます。そのためフィルターの精度が落ちるのでは無いかと心配していました。
※特に気づくような実害はありません。
また、ウイルススキャンのログを見ても、ウイルスをもっとも多く送ってくるサーバーとして、ダントツの1位となっていました。そりゃそうですよね。
これではなんだ気持ち悪いので、以下の設定を行いました。
※本当はM-SV01でやりたかったのですが、header_checks はリレーよりも後に行われる処理なのか？正しく動作しませんでした。そのためM-SV02に設定。
・main.cf
header_checks = regexp:/etc/postfix/header_checks
/^Received:.*M-SV01/i IGNORE
これで大丈夫でした。
2017年06月27日
僕は linux をある程度使うことができますが、その一番最初は会社に入社してからでした。
学生で好き勝手触っていた頃は、せいぜいWindowsServerまでで、 linux はとっつきにくくて触ったことがありませんでした。
で、このときに、ログインは一般ユーザーで行い、root ユーザーに su すると教わりました。
※なお適当なイメージとして、スーパーユーザーになるとか、スイッチするとかっていう意味で想像していたのですが、なんだかいろいろな意味があるようですね。substitudeとかもあるようです。
このときに利用するコマンドは su - と、ハイフンをつけると教わりました。当時は僕は全く無知だったので、そんなもんかと特に気にしていませんでした。
ちなみに当時はおまじないとして、sync sync sync shutdown なども教わりました。
※sync は当時でもすでに無意味っていわれていたように思います。
で、ハイフンをつける場合には、そっくりそのまま root ユーザーになるようです。環境変数も引き継ぐようですね。
僕はだいたい root ユーザーは1名(僕だけ)であることがほとんどなので、環境変数なども意識していませんでした。
もし複数名で root ユーザーになるのであれば、 自身のすきなように環境変数をいじくれた方がいい場合もあるかもしれません。
参考
su と su - の違い
学生で好き勝手触っていた頃は、せいぜいWindowsServerまでで、 linux はとっつきにくくて触ったことがありませんでした。
で、このときに、ログインは一般ユーザーで行い、root ユーザーに su すると教わりました。
※なお適当なイメージとして、スーパーユーザーになるとか、スイッチするとかっていう意味で想像していたのですが、なんだかいろいろな意味があるようですね。substitudeとかもあるようです。
このときに利用するコマンドは su - と、ハイフンをつけると教わりました。当時は僕は全く無知だったので、そんなもんかと特に気にしていませんでした。
ちなみに当時はおまじないとして、sync sync sync shutdown なども教わりました。
※sync は当時でもすでに無意味っていわれていたように思います。
で、ハイフンをつける場合には、そっくりそのまま root ユーザーになるようです。環境変数も引き継ぐようですね。
僕はだいたい root ユーザーは1名(僕だけ)であることがほとんどなので、環境変数なども意識していませんでした。
もし複数名で root ユーザーになるのであれば、 自身のすきなように環境変数をいじくれた方がいい場合もあるかもしれません。
参考
su と su - の違い
2017年06月26日
僕はDNSサーバーとして、Linux BINDを利用しています。またこれとは別に、Pleskも利用しているため、ここにインストール/設定されているDNSサーバーも管理しています。
ということで、調べてみました。
まず CentOS 6.8 + BIND の場合は、/etc/named.conf にdnssec-enable noとなっていました。そのため利用していないようです。
Pleskについては、DNSSECを利用するためには、追加のモジュールをインストールする必要があるようです。
僕自身はデフォルトで利用しているため、これも関係ありませんでした。
ということで、特に対策をしなくても乗り越えることができそうです。
DNSSEC を使用する(Linux)
ということで、調べてみました。
まず CentOS 6.8 + BIND の場合は、/etc/named.conf にdnssec-enable noとなっていました。そのため利用していないようです。
Pleskについては、DNSSECを利用するためには、追加のモジュールをインストールする必要があるようです。
僕自身はデフォルトで利用しているため、これも関係ありませんでした。
ということで、特に対策をしなくても乗り越えることができそうです。
DNSSEC を使用する(Linux)
2017年06月25日
古いDNSサーバーを運用している場合に、最近のDNSの dnssec 公開鍵更新の件について調べてみました。
で、結論としては、Windowsサーバーの場合対応は不要だということです。
ルート ゾーン KSK の更新に伴う Windows の DNS サーバー上での対策の必要性
考え方としては、新しいサーバーのWindows2012などでは、DNSSECに対応しており、なおかつ自動更新が可能なようです。
それ以外のOS、Windows2008などについては、そもそもDNSSECを設定することができないために無関係だということでした。
で、結論としては、Windowsサーバーの場合対応は不要だということです。
ルート ゾーン KSK の更新に伴う Windows の DNS サーバー上での対策の必要性
考え方としては、新しいサーバーのWindows2012などでは、DNSSECに対応しており、なおかつ自動更新が可能なようです。
それ以外のOS、Windows2008などについては、そもそもDNSSECを設定することができないために無関係だということでした。
2017年06月24日
最近の DNS サーバーはなんだか難しくてよくわかりません。DNSSECとか・・
ところが、知らない状態では済まされないことが起きようとしているようです。
DNSSECバリデーションにおけるルートゾーンKSKロールオーバーに関する重要なお知らせ
ここで、対策が必要となる対象者に、僕自身が該当しそうな記載がありました。ネットワーク機器の運用者とDNSサーバー運用者でしょうか。
そもそもIPフラグメントのテストはどうやるのでしょうか・・。単体で調査できればいいのですが・・。
とりあえずDNSに関するチェックは以下のURLからできました。
http://keysizetest.verisignlabs.com/
This should fail という箇所だけはFAILになっています。しかしそれ以外は、PASSとなっていました。
これで正常のようです。
しかし手元にある linux では、digコマンドを入力しても全く応答がありません。とても不安です。
# dig +bufsize=4096 +short rs.dns-oarc.net txt
出力無し
+short をなくすと、以下の通り。
これで正しいのかわかりませんが・・。
# dig +bufsize=4096 rs.dns-oarc.net txt
; <<>> DiG 9.10.3-P4-Ubuntu <<>> +bufsize=4096 rs.dns-oarc.net txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21343
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;rs.dns-oarc.net. IN TXT
;; ANSWER SECTION:
rs.dns-oarc.net. 3 IN CNAME rst.x476.rs.dns-oarc.net.
rst.x476.rs.dns-oarc.net. 2 IN CNAME rst.x485.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net. 1 IN CNAME rst.x490.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net. 0 IN TXT "153.149.141.103 lacks EDNS, defaults to 512"
rst.x490.x485.x476.rs.dns-oarc.net. 0 IN TXT "Tested at 2017-06-23 03:58:29 UTC"
rst.x490.x485.x476.rs.dns-oarc.net. 0 IN TXT "153.149.141.103 DNS reply size limit is at least 490"
;; Query time: 1 msec
;; SERVER: 192.168.95.6#53(192.168.95.6)
;; WHEN: Fri Jun 23 12:59:21 JST 2017
;; MSG SIZE rcvd: 280
ところが、知らない状態では済まされないことが起きようとしているようです。
DNSSECバリデーションにおけるルートゾーンKSKロールオーバーに関する重要なお知らせ
ここで、対策が必要となる対象者に、僕自身が該当しそうな記載がありました。ネットワーク機器の運用者とDNSサーバー運用者でしょうか。
そもそもIPフラグメントのテストはどうやるのでしょうか・・。単体で調査できればいいのですが・・。
とりあえずDNSに関するチェックは以下のURLからできました。
http://keysizetest.verisignlabs.com/
This should fail という箇所だけはFAILになっています。しかしそれ以外は、PASSとなっていました。
これで正常のようです。
しかし手元にある linux では、digコマンドを入力しても全く応答がありません。とても不安です。
# dig +bufsize=4096 +short rs.dns-oarc.net txt
出力無し
+short をなくすと、以下の通り。
これで正しいのかわかりませんが・・。
# dig +bufsize=4096 rs.dns-oarc.net txt
; <<>> DiG 9.10.3-P4-Ubuntu <<>> +bufsize=4096 rs.dns-oarc.net txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21343
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;rs.dns-oarc.net. IN TXT
;; ANSWER SECTION:
rs.dns-oarc.net. 3 IN CNAME rst.x476.rs.dns-oarc.net.
rst.x476.rs.dns-oarc.net. 2 IN CNAME rst.x485.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net. 1 IN CNAME rst.x490.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net. 0 IN TXT "153.149.141.103 lacks EDNS, defaults to 512"
rst.x490.x485.x476.rs.dns-oarc.net. 0 IN TXT "Tested at 2017-06-23 03:58:29 UTC"
rst.x490.x485.x476.rs.dns-oarc.net. 0 IN TXT "153.149.141.103 DNS reply size limit is at least 490"
;; Query time: 1 msec
;; SERVER: 192.168.95.6#53(192.168.95.6)
;; WHEN: Fri Jun 23 12:59:21 JST 2017
;; MSG SIZE rcvd: 280
