ただのにっき。

ただつらつらと日記が書かれていくようです。

Tag: CentOS (page 1 of 2)

KVMで仮想化したCentOS7の時計について

もはや完全にわかってなかった…っていうそれだけのことだけど…。

CentOS6で動いているサーバがあって、そのサーバの上で、KVMで仮想化したCentOS7を動かそうとしていて、無事にインストールできたもののCentOS7の時計がなんか変ってことでウダウダした際のメモ。

とりあえず、結論から書いちゃうと、仮想化されたCentOS7はKVMが提供するkvm-clockを参照するようになっている。んで、kvm-clockがゲストOSに提供する時刻のタイムゾーンは仮想化されたサーバごとに設定で変更することができて、ゲストOSにCentOS6を使っていた時には、JSTで提供するように設定してあって特に問題はなかったんだけど、どうやらCentOS7からはUTCで提供されることが前提になったらしい。

CentOS7の設定を帰ると、kvm-clockがUTCじゃなくて、特定のタイムゾーン(今回はJST)の時刻で提供されることを前提にすることもできるけど、そうするとWarningが出力されてしまい、まぁ、Warningだし、いっかと思いつつ、ちょっと気持ちが悪かった。そういうわけなので、KVMの設定ファイルを書き換えて、UTCでkvm-clockを出すようにすると問題なく動くようになった。

まず、CentOS7で時計回りがどうなってるかは、以下のコマンドで確認する。

# timedatectl status

表示される結果の中で「RTC in local TZ: no」となっていれば、kvm-clockはUTCで提供されるもんだと、CentOS7は思っているようですな。KVM側でkvm-clockを提供する際のタイムゾーンをどうするかは、各ドメインの設定XMLの中でこんな感じで(下記のようにすると、UTCで提供される)

CentOS6時代のまま、KVMの設定ファイルのoffsetがlocaltimeになっていると、JSTで提供されてしまうので、CentOS7の方でJSTをUTCとして扱ってしまうので、まったく違う時間を保持してしまうと。…まぁ、NTPでの同期を設定してあれば、そのうち、修正されるだろうけど、気持ち悪いし、システムの時計がすごい幅で修正されてしまうのでドキドキする。

んで、kvm-clockがUTCじゃなくて、特定のタイムゾーンの時刻で提供されることをCentOS7に教えるには、さきほどのtimedatectlコマンドを使って

# timedatectl set-local-rtc 1

って実行すれば、教えることができるけれど、

This mode is not fully supported and will create various problems with time zone changes and daylight saving adjustments.

ってビミョーなWarningが出てくる、と。

密かに想像するに、CentOS7から導入されたsystemdって、デフォルトで時刻をUTCで扱うようなので、kvm-clockをUTCであるものとして動くってのも、その絡みのなんだろうなぁ。システム内部ではUTCで持っておいて、設定に応じて、そのタイムゾーンに合わせた時刻を返すってのが、いろいろと間違いないやり方ではあるような気はするけども…(遠い目)

postfixのログをサマリーするにはpflogsummだけど。

Postfixでメールをホイホイ投げるようなサーバだと、postfixが吐き出すmaillogを見やすくまとめてもらって、たまーに眺められるようにしておくのがいいかなぁと思う。んで、ちょっと調べて見たら、pflogsummというPerlで書かれたスクリプトにmaillogを食わせると、ログのサマリーを作ってくれるらしい。

CentOSのyumレポジトリにもあるらしいのだが、先人達のブログを読むと

# yum -y install postfix-pflogsumm

でインストールできるとのことだが、「postfix-pflogsumm」というパッケージが見当たらない。収録されなくなったか、名前が変わったかのどちらかだろうなぁと思いつつ、yum search postfixを実行してみると、「postfix-perl-scripts」っていうパッケージが見つかった。んで、yum info postfix-perl-scriptsを実行してみると、説明の1行目にこんな記載があった。

This package contains perl scripts pflogsumm and qshape.

qshapeっていう、キューの状態を確認できるPerlスクリプトと同じパッケージにまとめられたような感じだろうか。というわけで、「postfix-perl-scripts」をインストールすると、pflogsummが使えるようになった。

CentOS7のNTPサーバ/クライアント

CentOS7から、ntpdに代わって(…という割にはntpdも普通に使えるんだけども)chronyがNTPクライアント/サーバになったらしい。ntpdが普通に使えていたので、chronyの存在しならないままだったけど、ひょんなことからchronyの存在に気付いた…。

というわけで、備忘メモ。

インストールするとき

普通にCentOSをインストールするとchronyもインストールされてそうだけど、最低限のインストールを行うと入ってないこともあるようだ。

sudo yum install chrony

chronydの設定ファイル

CentOS7だと、/etc/chrony.confが設定ファイル。NTPサーバを指定する書き方はntpd.confとよく似ているけど、微妙に違う(そりゃ当然だ)

OS起動時に起動する/起動する

ま、普通にsystemctlに御願いする。

sudo systemctl enable chronyd

sudo systemctl start chronyd

NTPサーバとの同期状況の確認

以下のコマンドで概況を知ることが出来そう。今、同期に使っているサーバとズレを確認するコマンドはこんな感じ。

chronyc tracking

んで、ソースに指定しているNTPサーバとの通信状況を確認するには、こっちのコマンド。

chronyc sources

まぁ、こういうのも慣れなので、今度、CentOS7を使うことがあればntodではなくchronydを使ってみることにしよう。

memcached 1.4.5をCentOS5でRPM作るとコケる件。

久しぶりにmemcachedのサイトを見てみたら、新しい1.4.5がリリースされてたので、RPMを作ってサーバにインストールしようとしたら、rpmbuildでコケた。サーバはx86なマシンで、CentOSの5.3が動いてる感じ。

rpmbuildが異常終了した後、画面に出てる文字列を眺めてみる。

(前略)

t/item_size_max……ok

t/line-lengths…….ok

t/lru…………….ok

t/maxconns………..ok

t/multiversioning….ok

t/noreply…………ok

t/stats-detail…….ok

t/stats…………..ok

t/udp…………….ok

t/unixsocket………ok

t/whitespace………skipped

all skipped: Skipping tests probably because you don’t have git.

Failed Test Stat Wstat Total Fail Failed List of Failed

——————————————————————————-

t/binary.t 255 65280 3361 6212 184.83% 240 243-244 251 255 258-3361

2 tests skipped.

Failed 1/39 test scripts, 97.44% okay. 3109/6475 subtests failed, 51.98% okay.

make: *** [test] エラー 255

エラー: /var/tmp/rpm-tmp.94575 の不正な終了ステータス (%check)

RPM ビルドエラー:

/var/tmp/rpm-tmp.94575 の不正な終了ステータス (%check)

うーむ。さっぱりわからん(汗)

なんとなーく、ビルドの過程は終わっているんだけど、make testが走りきらない感じですかね。

何回やってもラチがあかないので、調べてみたら、この辺とか、この辺に、なんとなく関係がありそうなことが書いてあった。

妄想の域は出ないけれど、memcachedが依存しているモジュールのバージョンの問題なのかも。具体的には、memcachedの1.4.4まではlibeventの1.1でも動作するけれど、1.4.5からlibeventの1.1ではダメで、1.4あたりを必要とするのではないかと。で、CentOS 5.4以前のRPMレポジトリに入っているlibeventは1.1で、CentOS5.5(現時点でリリースされてるのは、RHEL5.5の方だけ)になったらlibeventが1.4あたりにバージョンアップされる…と。結局、memcached1.4.5をビルドしようと思ったら、CentOS5.5のリリースを待って、アップグレードをかけなきゃいけないってことなのかな。あー。

livedoorのサーバOSはFreeBSDじゃなくてCentOSなのか、そうなのか。

WikipediaのFreeBSDのページを見てると、使用例の欄に以下のような記載がある。

ライブドア – ほとんどのサーバOSがFreeBSD

そんなわけで、「そうか、livedoor(のポータル)って、FreeBSDで動いているんだ」と思っていた。で、NetCraftで調べてみると、確かに、しばらく前までFreeBSDだったんだけど、最近はF5なBIG-IPになっていて、きっとBIG-IPの配下でFreeBSDががんばってるんだと思っていた。

しかし、livedoor開発blogの「1000台の子供達 – livedoorを支えるサーバ群 –」ってエントリーを拝見すると、

現在のポータルサーバの主流OSはCentOSです。新規にセットアップされるものの99%が、このOSになります。

…って(汗)ああ、そうなのか、livedoorはCentOSなのか。BIG-IPの配下でがんばってるのは、FreeBSDなサーバではなく、CentOSなIBMサーバ群ってのが真相のようで。きっと、膨大なサーバ群をリプレースしていく過程で、OSもFreeBSDからCentOSに変えていったのかと思うと、さすがlivedoorさんだなぁ…なんて思ったりする今日この頃。

個人的には、CentOSが何かと楽ちんな気がするけれど、FreeBSDの無骨な感じ(特にインストーラーとか)も悪くないし、デフォルトの設定が「堅い」(最初から誰でもsuでrootになれないとか)のはFreeBSDの方だったりするんじゃないかと思ったりする。…と、偉そうなことを書いてる割には、FreeBSDを触って1週間ですが、何か(汗)

Older posts