rss ログイン
dialy - ひねもす…

 

Wildcard Certificates Coming January 2018 anchor.png

待ってました。

最近、Let's Encrypt のサイトはまったくアクセスしていなくて、 IT Media News でみましたので、こっちもリンクしておきます。

certbot が yum で導入できるし、 git の url を探す必要もなく、 こんな重要なニュースが流れているとはつゆ知らず…でした。

私が扱っている自前で運用しているサーバーは、 Wild Card 証明書のサイト以外はすべて Let's Encrypt に切り替えたので、 さらに楽になる予定ですが、Wild Card が必要となるのは、 複数サーバーで運用しているものばかりなので、 導入後の手間が年1回や、2年に1回から、 年に4回に増えると、少し面倒だななどとも思っています。 最初は様子見でしょうか。

定型なので、他のサーバーへ複製する方法を用意することになるでしょうけれど。

UTM で WAF を行っているサイトも、3ヵ月ごとの入れ替えが面倒だなって思うのです…。 どちらの UTM 様も Let's Encrypt 対応をお願いします。こちらも Wild Card 対応で、 自由度が増えます。

少し話がずれましたが、楽しみですね。


 

DNS 動作テスト : ルートゾーンKSKロールオーバーによる影響確認 anchor.png

  • 情報ソース
    https://jprs.jp/tech/notice/2017-07-10-root-zone-ksk-rollover.html
  • 単純にブラウザで動作を確認してもよいようだけれど、以下を実行できるならば、 結構自由にテストができるかも?
    dig +bufsize=4096 +short rs.dns-oarc.net txt
    自分の環境では、以下の結果となりました。
    rst.x4090.rs.dns-oarc.net.
    rst.x4058.x4090.rs.dns-oarc.net.
    rst.x4064.x4058.x4090.rs.dns-oarc.net.
    "124.41.72.22 DNS reply size limit is at least 4090"
    "124.41.72.22 sent EDNS buffer size 4096"
    "Tested at 2017-07-11 23:12:51 UTC"
  • 注意点では at least の次に出⼒される数値が1500以上であることとあり、 上記では 4096 になっていることが確認できました。
  • rs.dns-oarc.net. の txt を引くことで、テストできるように設定されているのですね。 無駄に実行しないようにしないと…

 

人外ネゴシエーター 3 巻 anchor.png

麻城ゆう と 道原かつみ コンビ、1,2 巻はつい最近読みました。遅い。 なので、もう3巻が出たって気分で、とてもうれしく感じてます。


 

Zabbix の機能をわかってなかった anchor.png

設定ファイルに housekeeper あるなとわかっていたが、 管理の一般設定に、データの保存期間 の指定があり、かつ、削除を有効にするかどうかの設定があることに気が付いてませんでした。

データが 400日超えで、500日以上のものはなかったことから、その頃のバージョンアップで追加された…とおもったけれど、考えてみたら、このサーバー、1.8.x から一気に 3.x にしたような気がします。丁度その頃です。

Zabbix 3.0.x から導入した環境では、削除は有効ですし、デフォルトに戻しても有効なので、 この設定はみなくとも良いと思って忘れてしまったのだと思います。

古いデータから変換する場合にはご注意ください。

さて、いまほど設定をしたので、次の housekeeper は 30分後くらいです。 ちゃんと削除されますように。

追記

削除されました。しかし、前に勢いで削除してしまった housekeeper のデータは復活するものではありません。ってことで、適当にスクリプトを書いて、作成しました。 動作として、items になくなった itemid を登録するだけですので簡単です。


 

samba で guest 接続が増殖してた… 作っていたのは Sophos Endpoint Security anchor.png

少し出力結果を端折りますが、以下のような nobody 接続が大量に発生していました。

PID     Username     Group        Machine
-----------------------------------------------------------------------------------
25524   nobody       nobody       10.10.10.10 (ipv4:10.10.10.10:52892)

あまり smbstatus を逐次確認し…のようなことはしませんので、 いつから増殖していたのかは不明なのですが、1ヵ月くらい前に、 samba server のレスポンスが悪いと感じていて、確認したら、同一 PID で、 nobody が大量に沸いていたと…いうことなのです。

nobody は、smb.conf で guest の ID として利用しているのですが、 そもそも guest 接続は許可していないですし、printer もロードしていません。 なにが引き金かと思って時々試していたら、ファイルを開いてデータを保存する際に、 アプリケーションにもよるようですが、2つくらい作成されることがあるようでした。

せつぞくは、一定時間で消えるようなのですがね消えるまでが長く、 場合によっては、nobody が大量発生している状態となってしまうようです。

原因なのですが、smb.conf は無関係でした。今回のアップデートでも同様の結果です。

こうした、通常とは異なる動作をするような場合の注目ポイントは Virus対策ソフトウェアであることが多いので、今回も、一旦アンインストールしてみます。 安定の解決をみました。

Sophos Endpoint Security が原因だったわけですが、 導入していても、ネットワークドライブのチェックを外すと問題は発生しません。 しかし、導入している意味から考えて、あまり良い方法ではないので、 nobody 接続が破棄されるまでの時間を短くするのが良いのかなと思っています。


 

Zabbix 上の過去データ anchor.png

zabbix version 1.8 もしくは 1.6 だったか、その辺から使い始めて、 現在稼働しているのは 3.0 です。最新ではないのですが、順次更新をおこない、 データを引き継ぎ、現在の監視を始めてから7年が経過していたようです。

というのは、2011 年の audit データがあったからという判断でしかないのですが、 今まで消したことがなかったし、Web インターフェースから削除する方法もないようなので間違いないでしょう。

近年…というか、Discovery がうまく機能するようになり、テンプレートを切り替え、 ホストの設定を Discovery で取得するように変更し、設定を加え…などの作業を行っていたのですが、気が付いたら、50GB を軽く超えてしまうデータが蓄積されていました。

必要なものは仕方ないと、ディスクの量から見れば「わずか」と言ってもよいわけですから、割り当てを増やしていたのですが、データサイズが安定する気配がありません。

念のため調べてみたところ、データが消えていない事が判明しました。

消えていないのは、テンプレートを切り替えたホスト…簡単に言えば、ほぼ全部です。 なぜ消えないかというと、該当する項目設定を削除してしまったからのようです。

一定期間が削除する定義は、項目設定にになり、その項目が順次 housekeeper に渡されるようになっているように見えます。もちろん、削除した項目です。 たとえば以下のように、housekeeper のデーがあり、value には itemid が設定されていると思われます。

+---------------+--------------+--------+-------+
| housekeeperid | tablename    | field  | value |
+---------------+--------------+--------+-------+
|             1 | trends       | itemid | 35015 |
|             2 | trends_uint  | itemid | 35015 |
|             3 | history_text | itemid | 35015 |
|             4 | history_log  | itemid | 35015 |
|             5 | history_uint | itemid | 35015 |
|             6 | history_str  | itemid | 35015 |
|             7 | history      | itemid | 35015 |

この itemid を持つデータはすでにないので、対象からすべて削除される…はずなのですが、 データが残っている状態であっても、server のログをみる限り削除された形跡はありませんでしたし、実際データが 1年以上残っていました。

先頭項目の削除がうまく動作しないからなのか、全体のデータも削除されないと予想されます。

現在確認中…

なお、とりあえず items に存在しない itemid は自前で削除することとして、 housekeeper から削除したら、 housekeeper のレコード件数が 0 になりました。 housekeeper のレコードって、結局、全部削除しましょう的なものだけが対象なのかもしれませんね。(未確認) その割に、上記 35015 のデータは既に無くしてあったにも関わらず、housekeeper から消えないわけですが。


 

IPv6 の接続がおかしい? anchor.png

今月のはじめ頃だろうか、VMware の knowledge Base を開けなくなった。 実は同じ時期からだったのではないかと思うのだけれど、 Windows Update の確認が失敗するようになった。

そういえば、大規模サイバー攻撃云々と言われてた後からのような気がする。 ただし、因果関係はさっぱりわからない。

自分で確認した限りは、VMware も Windows Update も、 サービスを行っているサーバーが IPv6 で接続が可能であることが条件となっているようで、 IPv4 で接続する場合には、問題は発生しなかった。

Page Top
httpd (apache) よ、その設定はなんなんだ? anchor.png

修正方法は IPv4 で接続することで解決ということで、 httpd.conf の設定に ProxySourceAddress を追加すれば解決かと思ったのだけれど、 どうもうまく動作しない、マニュアル類も見つからないので、ソースをみてみる。

やっぱりわからない。

ってことで、IPv6 を削って一時しのぎ中です。


 

IPv6 Native 接続のせいか? anchor.png

今さっき出先からこのページを開こうとしたら接続できなかった。

VPN接続してローカルから接続したら見えた。

再度開いても見えないが、別の VHOST を指定したら時間がかかったのちに表示された。

ではと、もう一度開いたら表示された。

そういえば、前にもあったような気がする。 ipv6 接続できる環境からの場合に、常には ipv6 が有効ではないためか、 接続性がわるいのだろうか? と思った覚えが。

内部から ping6 で外部のホストをしていすると、最初のパケットが落ちたのちに接続されることもあるので、可能性として、常に経路は確保されていないのだろうなということか。

10分毎に、ランダムに外部の実在するホストに ping6 でパケットを1つだけ投げるとかやってみようかな(こらこら)


 

yum と logwatch と logrotate と … anchor.png

logwatch をメールで送信し、管理しているホストの状態を少しだけ把握している。

そんな中、yum で install/update を実行した結果が入った logwatch のメールが届いた。 そんな覚えはないので、なにか不具合化と思いサーバーにアクセスし、確認したが、 history には何も作業した形跡がない。

ログを確認すると、確かに 4/19 の作業でリストアップされている。 …のだけれど、その下には 5/20 とか、8/10 とか、12/09 などが続いて記録されていた。 yum.log の日付を確認すると、昨日ではない。

結果、ローテートされていない事が判明した。 つまり、yum の結果は過去のもので、logwatch は素直に拾ってくれたものだった。

logrotate の設定をみると以下のように定義されていた。

/var/log/yum.log {
   missingok
   notifempty
   size 30k
   yearly
   create 0600 root root
}

notifempty は指定されていて、丁寧に size 30k も指定されていた。 単位も年単位、ここ1年 yum で更新したものが少なかったんだなと判明しました。

では、size の指定を外せばいいようです。1年も1月に変更して置こう。


 

YAMAHA RTX1210 で IPv6 address に tentative と表示される anchor.png

いままで気にしたことがなかったのでメモ

IPv6 でアクセスする必要がでたので (flets-v6.jp) 、LAN1 をターゲットに以下の設定をしました。

ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 rtadv send 1

この設定をした場合、すぐにアドレスが有効になってくれていたと思うのですが、 今回は、振られたアドレスに対して、自身かもも ping6 が通りません。

しかも、表示されたアドレスをみると、みたこともない tentative などと表示が付いています。

global     240x:xxx:xxx:xxxx::1/64 (tentative) (lifetime: 604728/2591928)

「仮」と言われても、それは一時アドレスは違うもの? と思う程度で、解消する方法がわかりません。 この時 scope-id も down と表示があります。

LAN1 scope-id 1 [down]

このままでは問題があるのと、いろいろ試す必要がある可能性がでたため、LAN1 からは設定を削除し、 LAN3 に対して

ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan3 address ra-prefix@lan2::1/64
ipv6 lan3 rtadv send 1

のように設定しなおしました。 prefix の設定はそのままです。
当然のように

global     240x:xxx:xxx:xxxx::1/64 (tentative) (lifetime: 604728/2591928)

となりますが、そもそも LAN3 には何も接続していない状態ですし、 気にせず、端末を接続します。

通信できるようになりました。

もしかして、LAN1 に接続している端末に IPv6 の RA を受けて通信をする機器が無かったのかな? と、いまさら思いましたが、とりあえず気にする必要はないようですね。という話。

蛇足的な情報ですが、 今のところ LAN3 から端末を外しても利用可能になっています。 lefetime を超えて変化があれば追記します。

Page Top

その後 anchor.png

使わずに放置していたら以下となりました。 そもそも ping6 で応答したさいに scope-id はの状態が up になったかは確認してませんでしたが、

# show ipv6 address lan3
LAN3 scope-id 3 [down]

 global     240x:xxx:xxx:xxxx::1/64 (lifetime: 604728/2591928)

別のネットワークから ping を実行すると、最初にタイムアウトしましたが、通信はできました。scope-id は down のままでした。

Page Top
では次に anchor.png

実は ipv6 の設定は、以下のようにすることに変更となっています。

ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 rtadv send 1 o_flag=on
ipv6 lan1 dhcp service server
ipv6 lan2 dhcp service client ir=on
dns server dhcp lan2

参考

今回足りていないのは、以下でしょうか。DNS は置いといても良いかと思いますが、 client 設定を追加してみます。

ipv6 lan2 dhcp service client ir=on
dns server dhcp lan2

dhcp で貰った情報を確認すると、DNS サーバーもあるので、上記の dns の指定も行います。完了すると

ping6 www.flets-v6.jp
received from 2404:1a8:ff06::1, icmp_seq=0 hlim=57 time=9.414ms

これで完了です。

※追記

ir=on を指定する目的は DNS サーバーの情報を得るためだけのようですね。



トップ   凍結 差分 バックアップ 複製 名前変更 リロード   ページ新規作成 全ページ一覧 単語検索 最新ページの一覧   ヘルプ   最新ページのRSS 1.0 最新ページのRSS 2.0 最新ページのRSS Atom
Last-modified: 2016-09-02 (金) 15:38:26 (JST) (325d)