2017年06月27日

このエントリーをはてなブックマークに追加
僕は linux をある程度使うことができますが、その一番最初は会社に入社してからでした。
学生で好き勝手触っていた頃は、せいぜいWindowsServerまでで、 linux はとっつきにくくて触ったことがありませんでした。

で、このときに、ログインは一般ユーザーで行い、root ユーザーに su すると教わりました。
※なお適当なイメージとして、スーパーユーザーになるとか、スイッチするとかっていう意味で想像していたのですが、なんだかいろいろな意味があるようですね。substitudeとかもあるようです。


このときに利用するコマンドは su - と、ハイフンをつけると教わりました。当時は僕は全く無知だったので、そんなもんかと特に気にしていませんでした。
ちなみに当時はおまじないとして、sync sync sync shutdown なども教わりました。
※sync は当時でもすでに無意味っていわれていたように思います。

で、ハイフンをつける場合には、そっくりそのまま root ユーザーになるようです。環境変数も引き継ぐようですね。
僕はだいたい root ユーザーは1名(僕だけ)であることがほとんどなので、環境変数なども意識していませんでした。
もし複数名で root ユーザーになるのであれば、 自身のすきなように環境変数をいじくれた方がいい場合もあるかもしれません。
参考
su と su - の違い

stock_value at 17:25|この記事のURLComments(0)技術 

2017年06月26日

このエントリーをはてなブックマークに追加
僕はDNSサーバーとして、Linux BINDを利用しています。またこれとは別に、Pleskも利用しているため、ここにインストール/設定されているDNSサーバーも管理しています。

ということで、調べてみました。
まず CentOS 6.8 + BIND の場合は、/etc/named.conf にdnssec-enable noとなっていました。そのため利用していないようです。

Pleskについては、DNSSECを利用するためには、追加のモジュールをインストールする必要があるようです。
僕自身はデフォルトで利用しているため、これも関係ありませんでした。

ということで、特に対策をしなくても乗り越えることができそうです。

DNSSEC を使用する(Linux)
stock_value at 19:28|この記事のURLComments(0)技術 

2017年06月25日

このエントリーをはてなブックマークに追加
古いDNSサーバーを運用している場合に、最近のDNSの dnssec 公開鍵更新の件について調べてみました。

で、結論としては、Windowsサーバーの場合対応は不要だということです。
ルート ゾーン KSK の更新に伴う Windows の DNS サーバー上での対策の必要性

考え方としては、新しいサーバーのWindows2012などでは、DNSSECに対応しており、なおかつ自動更新が可能なようです。
それ以外のOS、Windows2008などについては、そもそもDNSSECを設定することができないために無関係だということでした。
stock_value at 19:24|この記事のURLComments(0)技術 

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
stock_value at 13:14|この記事のURLComments(0)技術 

2017年06月23日

このエントリーをはてなブックマークに追加
Webarenaは信頼性が高く、結構昔から利用しています。
SuitePRO V2 とか V3 とかね。

最近のサービスでは、FWなどが別途で用意されていることが多く、ポートの開閉も比較的自由に行えますが、WebArena SuitePRO の場合には、むき出しで外部に公開されており、iptables で制御するようになっていました。しかしだからといって、特に不満はありません。※ただし iptables のレコード数には厳しい制限があるので、あまり自由度は無いように思います。

で、そんな Webarena が、ちょっと前にクラウドサーバーを提供し始めました。それが VPS クラウドです。価格も安く、過去の障害情報を見ても、十分に信頼できるサービスのように思えました。

実際に、今までWebarena SuitePRO で運用していたサービスを同程度の環境で VPSクラウドにすると、価格が結構落ちます。これはとても魅力的でした。WAKAMEという慣れないコントロールパネルも我慢しましょう。

そうして移行の準備を始めて、各種の検証を行っていました。
メールのテストを行っているとき、送信先メールサーバーのログを見ていると、VPSクラウドのIPアドレスが unknown と表示されていることがわかりました。

こんな感じのログでした。
warning: hostname X-X-X-X.vpscloud.static.arena.ne.jp does not resolve to address X.X.X.X: Name or service not known
postfix/smtpd[28407]: connect from unknown[X.X.X.X]

要するに、逆引きはWebarenaの規定のものが設定されています。

nslookup X.X.X.X
名前: X.X.X.X.vpscloud.static.arena.ne.jp
Address: X.X.X.X

一方で、ここで引けた名前を正引きすると、unknownとなるのです。
nslookup X.X.X.X.vpscloud.static.arena.ne.jp
*** SVXX が X.X.X.X.vpscloud.static.arena.ne.jp を見つけられ ません: Non-existent domain

そしてこの状態が、postfix で unknown と表示される原因です。
なぜ規定の逆引き名から正引きできないのか・・・。

Webarena に問い合わせをしたところ、以下の通り解答が。
> IPアドレスの逆引きについては、固定のホスト名を提供しておりま
> すが、逆引きホスト名の正引きは提供しておりません。

この unknown という状態は非常にやっかいです。最近ではスパムに対する意識が高く、unknown のサーバーが拒否される可能性は非常に高いのです。先日、DNSの逆引きをしないままサーバーとして稼働させてしまったことがありましたが、半分以下の到達率でした。

一方で、X.X.X.X.vpscloud.static.arena.ne.jp で正引き・逆引きができていれば、ホスト名で判定するような S25R などの場合は、厳しい運用をしている場合には、一時的な拒否が考えられますが、それでも unknown よりはずっとマシです。


以上のことから、僕は vpsクラウドでは Webサーバー、メールサーバー以外の用途でしか利用できないのでは無いかと考えています。Webサーバーの場合には、問い合わせフォームが無く確認メールなどを送付しないのであれば、アリかもしれません。
ただ通常はフォームへの入力があった場合、「問い合わせを受け付けました。」というメールが通知されると思いますので、結局Webサーバーもダメなのでは無いかと思っています。
stock_value at 11:00|この記事のURLComments(0)技術 

2017年06月22日

このエントリーをはてなブックマークに追加
※厳密にはネットワークが落ちているのかは不明です。症状としては、リモートデスクトップが一瞬切れるのです。マウスの反応が無くなるのって結構ストレスですね。

PCの調子がわるいということで、WindowsUpdateなどをかけていました。
アンチウイルスソフトなどを入れ、一通りセットアップが完了したと思っていたところ、定期的にリモートデスクトップが一瞬切れること、そしてそれが一貫して続いていることが気になりました。

ただしイベントビューアを見ても、ネットワークが落ちているというログは出ていなかったので、ひょっとしたらデスクトップ表示に関する何かがわるかったのかもしれません。

リモートデスクトップが一瞬切れるとき、以下のログが出ていました。
-----------
ソース "igfxCUIService2.0.0.0" からのイベント ID 0 の説明が見つかりません。このイベントを発生させるコンポーネントがローカル コンピューターにインストールされていないか、インストールが壊れています。ローカル コンピューターにコンポーネントをインストールするか、コンポーネントを修復してください。

イベントが別のコンピューターから発生している場合、イベントと共に表示情報を保存する必要があります。

イベントには次の情報が含まれています:

Logoff: Test
-----------

このためとりあえず、サービスから Intel(R) HD Graphics Control Panel Service を無効にしました。
細かい設定などはできなくなりますが、当面は問題無いのでこれでいこうと思います。
stock_value at 17:08|この記事のURLComments(0)技術