Zabbix 4.0 アルファ版

Zabbix4.0のアルファ版が出ているのですが、 仕事でも使いそうだったので、少しお試し。

データベースのアップグレードを試す

3.0のデータベースをインポートしてアップグレード出来るか試す

  1. Zabbix3.0側でデータベースをdumpする
  2. dumpファイルを 4.0側MariaDBにインポートする
  3. Zabbix-serverプロセスをスタートする

結果はアップグレード出来ず、エラーが出てきた。
下記のようにログ出力されている

 13305:20180718:161453.786 Starting Zabbix Server. Zabbix 4.0.0alpha8 (revision 81985).
 13305:20180718:161453.786 ****** Enabled features ******
 13305:20180718:161453.786 SNMP monitoring:           YES
 13305:20180718:161453.786 IPMI monitoring:           YES
 13305:20180718:161453.786 Web monitoring:            YES
 13305:20180718:161453.786 VMware monitoring:         YES
 13305:20180718:161453.786 SMTP authentication:       YES
 13305:20180718:161453.786 Jabber notifications:      YES
 13305:20180718:161453.786 Ez Texting notifications:  YES
 13305:20180718:161453.786 ODBC:                      YES
 13305:20180718:161453.786 SSH2 support:              YES
 13305:20180718:161453.786 IPv6 support:              YES
 13305:20180718:161453.786 TLS support:               YES
 13305:20180718:161453.786 ******************************
 13305:20180718:161453.786 using configuration file: /etc/zabbix/zabbix_server.conf
 13305:20180718:161453.795 current database version (mandatory/optional): 03010005/03010005
 13305:20180718:161453.795 required mandatory version: 03050120
 13305:20180718:161453.795 starting automatic database upgrade
 13305:20180718:161453.795 [Z3005] query failed: [1050] Table 'trigger_tag' already exists [create table trigger_tag (
`triggertagid` bigint unsigned not null,
`triggerid` bigint unsigned not null,
`tag` varchar(255) default '' not null,
`value` varchar(255) default '' not null,
primary key (triggertagid)
) engine=innodb]
 13305:20180718:161453.796 database upgrade failed

公式マニュアルのアップグレード方法を試す

公式手順では3.0のパッケージを4.0にアップデートすることで対応している。
Zabbix3.0が入っているサーバ上で、Zabbixリポジトリを更新し、4.0を入れてみる。

# yum install https://repo.zabbix.com/zabbix/3.5/rhel/7/x86_64/zabbix-release-3.5-1.el7.noarch.rpm

Zabbixサーバプロセスを停止する
# systemctl stop zabbix-server

各種パッケージをアップデートする
# yum clear all
# yum check-update
# yum update 'zabbix*'
読み込んだプラグイン:fastestmirror
Determining fastest mirrors
epel/x86_64/metalink                                                                                                                                                  | 7.3 kB  00:00:00     
 * base: ftp.iij.ad.jp
 * epel: ftp.iij.ad.jp
 * extras: ftp.iij.ad.jp
 * updates: ftp.iij.ad.jp
base                                                                                                                                                                  | 3.6 kB  00:00:00     
epel                                                                                                                                                                  | 3.2 kB  00:00:00     
extras                                                                                                                                                                | 3.4 kB  00:00:00     
updates                                                                                                                                                               | 3.4 kB  00:00:00     
zabbix                                                                                                                                                                | 2.9 kB  00:00:00     
zabbix-non-supported                                                                                                                                                  |  951 B  00:00:00     
(1/8): base/7/x86_64/group_gz                                                                                                                                         | 166 kB  00:00:00     
(2/8): base/7/x86_64/primary_db                                                                                                                                       | 5.9 MB  00:00:00     
(3/8): epel/x86_64/updateinfo                                                                                                                                         | 925 kB  00:00:00     
(4/8): epel/x86_64/group_gz                                                                                                                                           |  88 kB  00:00:00     
(5/8): extras/7/x86_64/primary_db                                                                                                                                     | 172 kB  00:00:00     
(6/8): updates/7/x86_64/primary_db                                                                                                                                    | 4.2 MB  00:00:00     
(7/8): zabbix/x86_64/primary_db                                                                                                                                       |  57 kB  00:00:00     
(8/8): epel/x86_64/primary                                                                                                                                            | 3.5 MB  00:00:01     
zabbix-non-supported/x86_64/primary                                                                                                                                   | 1.6 kB  00:00:00     
epel                                                                                                                                                                             12611/12611
zabbix-non-supported                                                                                                                                                                     4/4
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ zabbix-agent.x86_64 0:3.0.17-1.el7 を 更新
---> パッケージ zabbix-agent.x86_64 0:4.0.0-1.1alpha8.el7 を アップデート
---> パッケージ zabbix-get.x86_64 0:3.0.18-1.el7 を 更新
---> パッケージ zabbix-get.x86_64 0:4.0.0-1.1alpha8.el7 を アップデート
---> パッケージ zabbix-sender.x86_64 0:3.0.18-1.el7 を 更新
---> パッケージ zabbix-sender.x86_64 0:4.0.0-1.1alpha8.el7 を アップデート
---> パッケージ zabbix-server-mysql.x86_64 0:3.0.18-1.el7 を 更新
---> パッケージ zabbix-server-mysql.x86_64 0:4.0.0-1.1alpha8.el7 を アップデート
--> 依存性の処理をしています: libevent-2.0.so.5()(64bit) のパッケージ: zabbix-server-mysql-4.0.0-1.1alpha8.el7.x86_64
---> パッケージ zabbix-web.noarch 0:3.0.17-1.el7 を 更新
---> パッケージ zabbix-web.noarch 0:4.0.0-1.1alpha8.el7 を アップデート
---> パッケージ zabbix-web-japanese.noarch 0:3.0.17-1.el7 を 更新
---> パッケージ zabbix-web-japanese.noarch 0:4.0.0-1.1alpha8.el7 を アップデート
---> パッケージ zabbix-web-mysql.noarch 0:3.0.17-1.el7 を 更新
---> パッケージ zabbix-web-mysql.noarch 0:4.0.0-1.1alpha8.el7 を アップデート
--> トランザクションの確認を実行しています。
---> パッケージ libevent.x86_64 0:2.0.21-4.el7 を インストール
--> 依存性解決を終了しました。

依存性を解決しました

=============================================================================================================================================================================================
 Package                                             アーキテクチャー                       バージョン                                          リポジトリー                            容量
=============================================================================================================================================================================================
更新します:
 zabbix-agent                                        x86_64                                 4.0.0-1.1alpha8.el7                                 zabbix                                 374 k
 zabbix-get                                          x86_64                                 4.0.0-1.1alpha8.el7                                 zabbix                                 262 k
 zabbix-sender                                       x86_64                                 4.0.0-1.1alpha8.el7                                 zabbix                                 273 k
 zabbix-server-mysql                                 x86_64                                 4.0.0-1.1alpha8.el7                                 zabbix                                 2.0 M
 zabbix-web                                          noarch                                 4.0.0-1.1alpha8.el7                                 zabbix                                 2.7 M
 zabbix-web-japanese                                 noarch                                 4.0.0-1.1alpha8.el7                                 zabbix                                 7.7 k
 zabbix-web-mysql                                    noarch                                 4.0.0-1.1alpha8.el7                                 zabbix                                 7.2 k
依存性関連でのインストールをします:
 libevent                                            x86_64                                 2.0.21-4.el7                                        base                                   214 k

トランザクションの要約
=============================================================================================================================================================================================
インストール               ( 1 個の依存関係のパッケージ)
更新          7 パッケージ

総ダウンロード容量: 5.8 M
Is this ok [y/d/N]: 

更新:
  zabbix-agent.x86_64 0:4.0.0-1.1alpha8.el7 zabbix-get.x86_64 0:4.0.0-1.1alpha8.el7          zabbix-sender.x86_64 0:4.0.0-1.1alpha8.el7    zabbix-server-mysql.x86_64 0:4.0.0-1.1alpha8.el7
  zabbix-web.noarch 0:4.0.0-1.1alpha8.el7   zabbix-web-japanese.noarch 0:4.0.0-1.1alpha8.el7 zabbix-web-mysql.noarch 0:4.0.0-1.1alpha8.el7

完了しました!
[root@zabbix-test ~]# systemctl start zabbix-server
[root@zabbix-test ~]# systemctl start zabbix-agent

今度はうまくいきました。

まとめ

Zabbix 2.X から3.0へのアップグレードでは、
DBの情報を自動的に更新してくれていたのですが、
3.0から4.0ではそれが出来ないようです。

Zabbix 3.0から4.0では、いろいろな機能が追加されているらしいので、
今後はインストールアップグレードだけでなく、
機能面も試していきたいと思います。

それでは、また。

メールを書く上で気にすること

今年入社した新卒を見ていて考えていたのですが、
メールのお作法は社会人なりたての頃に教えてもらった事を
ずっと使っているなぁと思いました。

 新卒の方々に教える時や、メンバー同士でメールの文面をレビューする際に、
伝えやすいように自分でも整理しておきたいと思い立ち、
自分が気にしてるところ、注意しているところを書き留めておきます。

 

宛先

  • To,CC

メールアドレスは直接の担当者をtoに入れ、関係者をccに入れます。
初めてメールを送るため担当者が分からない場合には、関係者をtoに入れる。

  • 順序

メールアドレスを並べる順番を意識します。
まずはお客様のメールアドレス、メーリングリスト、自社の関係者の順番。

偉い人から順番に入れていきます。
職位が分からない場合は適当でやるしかないけど。

メールクライアントソフトによって、どういう順番に表示されるか分からないので、
意識しても意味が無いとは思いますが、念の為という感じです。

宛名

初めてメールを送る場合は

「会社名 hogehoge様」

会社名には株式会社等の表記を含めて書く。


一度でもやり取りがあって、相手の名乗りが分かっていれば、
名乗った会社名を書くのが良いと思います。
大抵の場合、「hogehoge株式会社の何々です」とは名乗らずに
「hogehogeの何々です」と名乗ることが多いと思います。

それが分かれば自分からも、hogehoge 何々様と宛名を書きます。


担当者と直接やり取りする場合はそれだけでよいのですが、

相手の上司や部署のメーリングリストをccに含める場合は、to:担当者 cc:上司様

などの書き方で、誰に送る事を意識しているか明示したりします。


自分の名乗り

初めてメールを送る場合は、

「この度はお世話になります。hogehoge株式会社の何々と申します。」
と、文頭の挨拶を書くようにしています。

会社として付き合いはあるけど、自分は送るのが初めての場合は、

「いつもお世話になっております。hogehoge株式会社の何々と申します。」

何度かやり取りしている場合には、

「いつもお世話になっております。hogehogeの何々です。」

 と言った具合に堅苦しさを少しずつ和らげていくようにしています。

 

章立て

重要な事、伝えたいことを先に書くことを意識しています。

仕事をする上でお客様に決めてもらわないといけないことや、

問題が発生している事など、重要な事から先に書きます。

また、それを伝えた上で何をしてもらいたいのか明確に書きます。

例えば、ただ問題が発生している事だけを伝えたのでは、

相手はどうしたらよいか分かりませんよね。


「問題が発生したので、このように回避したいと思いますが、
この方法をとってよろしいでしょうか」

という具合に、代案や回避策を提案して、
それで良いか悪いかを判断してもらいたい旨を伝えます。


打ち合わせの時間を調整したいのなら、

自分の予定を伝えたうえで、相手の都合を聞くなど。

重要なことを先に書くだけでは、伝わったは良いけど、
どうしたら良いか分からなくて、問答が増えたり、
齟齬を起こしたりすると思います。

 

どうしても分かりにくい文章になったりする場合は、
先に電話などで会話をしてから、メールには結論のみ書くのも1つの手段だと思います。
「何々の設定をしようとした時、競合する機能を無効にする必要があり、この機能を無効にすると云々。」
質問や状況の説明を丁寧に書いていると、
時間が掛かって仕方ない事があると思います。

「詳細は後ほどメールでお送りしますが、こういう問題が起きていて、
解決策にはこの機能をオフにしたいと考えている。」

他の機能への影響はないが、要望と違う動きになってしまうため、相談したい。
といった、口頭では頭出しだけして、詳細をメール文章に書いて、
結論を出してもらうなど。

 

長さ

メールが長いと、メールを読むにも時間が掛かってしまいます。

重要な事が読み飛ばされてしまう事もあると思います。

なるべく短く簡潔に書く事が大切だと思いますが、
議事録など話した内容が多ければ多いほど、メールが長くなっていってしまいます。

そういう時は、相手に確認して欲しい事をまとめて書いておいたり、
確認して欲しい箇所に☆印などの記号をつけて、
確認して回答頂きたい部分には☆印をつけてあります、
といった具合に優先的に見て欲しい箇所を分かりやすくしたりします。

あとは話題ごとに
<AAのことについて>
<BBのドキュメントについて>
<打ち合わせの日程について>
といった具合に段落を明確にすることで、
読みたいところを読み出しやすいようにするのが、
長い文章でも読みやすくするコツかと思います。

締めの言葉

締めの言葉に限らないのですが、

直前の段落の語尾が次の段落の語尾と被らないように気をつけています。

何々いたします。

よろしくお願いいたします。

といった被りは、私が一番やってしまうパターンです。

直前の語尾を変えられるようであれば、変えたり、
段落の順番を変える事で同じ語尾が繰り返しにならないように意識しています。

 

まとめ

  • 文法

日本語の文法的にどうとか、尊敬語・謙譲語、ビジネス用語などなど、
いろいろと気にすべき点はありますが、
日本語を丁寧に書く事ができていれば、あまり怒られることも無いと思います。
文法や言葉遣いを深く気にしすぎると時間がかかって仕方ないので、
ある程度のところで気にすることをやめるのが良いと思います。

メール文章を書く技術はとても大切だと思います。
こういったところに気をつけながら、
相手に伝わりやすく、短く簡潔な文章を、
間違いなく早く書くのはとても難しいことです。

  • タイミング、スケジュール

さらに重要なのはメールを書いて送るタイミングがいつになるか読み、
そのタイミングで伝えるのが良いことか考えるのが大切かと思います。

仕事の流れは、自分の時間だけで決まっているわけではありません。
一緒に仕事をする同僚、お客様、販売代理店、メーカー、などなど。

それぞれに営業時間があり、それぞれに外出や打ち合わせなどの都合があります。
早めに伝えなければいけないことは、メールを書くよりも先に電話して伝えておくなど、順序や優先度を考えて行動しなければ、メールを書いて満足していると、
なぜいまさらこんな重要な事を伝えてきたのかと、お客様から怒られてしまうこともあるでしょう。

メール文章の中身を気にすることも大切なことですが、
それを伝えるのが遅くなり過ぎたりしないように気を使う事が重要だと思います。

まとまっていない"まとめ"が出来てしまった…。
まだまだ私も精進が必要ということでしょうか。
長文になってしまいましたが、このあたりで終わりにしたいと思います。

それでは、また。

OpenLDAPのCSN

OpenLDAPが冗長構成を取るとき、
マスター側をプロバイダ、
スレーブ側をコンシューマって言うらしいんですが。

この同期をするとき、プロバイダ側の情報が新しいのか、
コンシューマ側の情報が新しいのかを判断するためのタイムスタンプみたいな情報が、CSNで
エントリごとのCSNと、データベース全体のCSNがあるそうです。

そのCSNを元にして差分だったり、
CSNがなければ全エントリを同期するといった判断をするための基準になっています。

CSNは同期が完了した際に、プロバイダからコンシューマに対して、
同期完了後のCSNを通知します。

その通知されたCSNを、次回同期する際に送りつけて同期するっていうのが
生本的な動きのようです。

削除されたエントリについてどうやって知ってるのか分からん。

同期する際には 前回のCSNを使って同期するのが基本なのですが、
違うCSNを使うようにしたい場合は、
/usr/sbin/slapd -c rid=XXX,csn=YYYYMMDDHHMMSS.XXXXXXZ#[SID]#XXXXXX;YYYYMMDDHHMMSS.XXXXXXZ#[SID]#XXXXXX

というオプションをつけてあげると、
1番目のCSNと2番めのCSNの差分を見て応答してくれるみたいです。

プロバイダとコンシューマどっちのCSNをどっちに書くのかっていうのも分かってない。
パケットキャプチャして送ってるCSNを見る限りだと、
プロバイダ;コンシューマっぽいけど。

LDAPの話はRFC読まないとダメなのかって思うくらい、情報が少ない。
もうむりぽ。

2016年やることリスト

  • さくらVPS プラン変更 SSDのやつ
  • 権威DNSサーバを構築

セカンダリはお名前.com ポリシーゾーンとかviewとか設定を試す

DDNSか、さくらVPSVPNを張り続けて、
外部からリモートログイン出来るようにする

やりたいこと

  • リモートでログインして色々試す事が出来るようにする

VM1台構築して vyattaインストールしてiphone/ipad/Mac からVPN
OpenVPNのよく分からないSSLVPNもいいが、
iPhoneIPSECクライアントの機能があるので、
そっちでやってみる

  • DNSサーバ2台構築して、ローカル内でZone転送
  • DNSサーバはbind

bindが出来たらpower dns
ほかは追々。

nginxで複数のバーチャルホストが設定されている時のデフォルトサーバ

nginx を使って複数のバーチャルホストを設定していて、
IPアドレスや、設定されていないホスト名でアクセスがあった時に表示するデフォルトサーバが、
おかしくなったので調査した事のメモ。

nginx.conf を流用して バーチャルホストの設定を conf.d に追加していくと、
include conf.d/*.conf で.confのつくファイルが全て読み込まれてしまうため、
順番がどうなっているのか分からなくなってしまいます。

バーチャルホストを設定するコンフィグファイルを include する順番を書いておけば、
こういった問題は起こらないと思います。

Apache だと apachectl -S とかで読み込まれたコンフィグの中で、
どのファイルが default server になっているかが確認出来るので便利なのですが、
nginx だとそういうコマンドがあるのか分かりません。

調べたところいくつか設定されたバーチャルホストの設定から、
明示的に default server を指定する方法があったのでメモしておく。

http の場合

listen 80 default_server;

https の場合

listen 443 ssl default_server;

バーチャルホスト設定内の listen ディレクティブに
default_server と書いておくと、
複数あるバーチャルホスト設定の中からその設定をdefault server として使用する。

fstab と mount コマンド

fstab にマウント元とマウント先や、
そのオプションを書いておいて、mount コマンドを実行すると、
fstabに記載された通りにマウントする

/etc/fstab
[ホスト名]:[マウント元ディレクトリ] [マウント先ディレクトリ] nfs rw,soft 0 0

mount [マウント先ディレクトリ]

rsync

コマンドメモ

rsync -avz -e "[ssh本体へのパス] -i [使うSSH鍵のパス]" [ローカルディレクトリ] 対象のサーバ名(IPアドレス):[対象サーバのディレクトリ]

コマンドを実行するユーザと、SSH鍵の所有ユーザ。
これらと同じユーザ名のユーザが対象サーバにいる場合はこれで動作するはず…。