2017年5月19日金曜日

Graylogの仮想アプライアンスでログ保存領域のディスク拡張を実施する ("Elasticsearch cluster unhealthy (RED)"のエラーを解消する①)

自宅環境のログ統合管理のために、仮想アプライアンスのGraylogを導入しているが、先日以下のようなエラーが出てログが収集できなくなってしまった。

------------------------------
Elasticsearch cluster unhealthy (RED)
The Elasticsearch cluster state is RED which means shards are unassigned. This usually indicates a crashed and corrupt cluster and needs to be investigated.

~(以下略)~
------------------------------


Elasticsearchがエラーを吐いているようだ。とりあえず原因切り分けしていこう。

原因切り分け

仮想アプライアンスのGraylogの場合、Elasticsearchの動作ログは以下URLに記載のある通り、/var/log/graylog/elasticsearchにあるようなので、そのディレクトリにあるgraylog.log確認してみる。

http://docs.graylog.org/en/2.2/pages/configuration/file_location.html#id5

# tail /var/log/graylog/elasticsearch/graylog.log
------------------------------
~(省略)~

at org.elasticsearch.index.engine.InternalEngine.recoverFromTranslog(InternalEngine.java:235)
... 12 more
Caused by: java.io.EOFException: read past EOF. pos [532245] length: [4] end: [532245]
at org.elasticsearch.common.io.Channels.readFromFileChannelWithEofException(Channels.java:102)
at org.elasticsearch.index.translog.ImmutableTranslogReader.readBytes(ImmutableTranslogReader.java:84)
at org.elasticsearch.index.translog.TranslogReader.readSize(TranslogReader.java:91)
... 19 more
[2017-05-12 21:34:21,922][WARN ][cluster.routing.allocation.decider] [Cody Mushumanski Gun Man] high disk watermark [90%] exceeded on [6-FCB92qRk2n76qo6h1PSg][Cody Mushumanski Gun Man][/var/opt/graylog/data/elasticsearch/graylog/nodes/0] free: 987.6mb[6.4%], shards will be relocated away from this node
------------------------------

下線部があやしい…。どうもディスク使用率が90%を超えて、ElasticsearchのShardがNodeから除外された、といったメッセージに見える。
※NodeやShardといった単語はElasticsearchの用語となるが、この説明は今回は割愛する

dfでディスク使用率を確認してみる。

# df -h
------------------------------
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G  4.0K  2.0G   1% /dev
tmpfs           396M  692K  395M   1% /run
/dev/dm-0        15G   14G  981M  94% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/sda1       236M   74M  150M  34% /boot
------------------------------

確かに、/のディスク使用率が94%になっている。どうやらディスク使用率が90%を超えると、Graylogの中で動いているElasticsearchは動作を止めてしまうようだ。ということで、ディスク拡張を行い復旧を試みることにした。

なお、先に言っておくと、ディスク拡張自体は成功したが、冒頭のエラーはディスク拡張だけでは解消しなかった。

ディスク拡張手順

ディスク拡張手順は以下にマニュアルが用意されているので、そのまま実施すればよい。解説を加えつつ実施していこう。

http://docs.graylog.org/en/2.2/pages/configuration/graylog_ctl.html#extend-ova-disk

1. 仮想マシンにディスクを追加

ログ保存用のディスクとして、vSphere Clientで仮想ハードディスクを追加する。


2. Graylogを再起動

ディスクを認識させるため、一度再起動しておく。

$ sudo shutdown -r now

3. Graylogのサービスを停止

作業中はGraylogのサービスを停止しておく。

$ sudo graylog-ctl stop
------------------------------
timeout: run: elasticsearch: (pid 861) 83s, want down, got TERM
ok: down: etcd: 0s, normally up
ok: down: graylog-server: 0s, normally up
ok: down: mongodb: 1s, normally up
ok: down: nginx: 0s, normally up
------------------------------

4. ディスクが認識確認

以下コマンドで確認できる。/dev/sdbとして認識していればOK。今回は40GiBのディスクを追加してみた。

$ sudo lshw -class disk
------------------------------
DMI   SMP   PA-RISC       device-tree           SPD   memory      /proc/cpuinfo             CPUID     PCI (sysfs)           ISA PnP       PCMCIA      PCMCIA      kernel device tree (sysfs)                          USB   IDE   SCSI    Network interfaces                  Framebuffer devices                   Display       CPUFreq       ABI     *-disk
       description: SCSI Disk
       physical id: 0.0.0
       bus info: scsi@2:0.0.0
       logical name: /dev/sdb
       size: 40GiB (42GB)
       configuration: sectorsize=512
  *-disk
       description: ATA Disk
       product: VMware Virtual I
       physical id: 0.0.0
       bus info: scsi@0:0.0.0
       logical name: /dev/sda
       version: 0001
       serial: 00000000000000000001
       size: 19GiB (20GB)
       capabilities: partitioned partitioned:dos
       configuration: ansiversion=5 sectorsize=512 signature=000c6ec2
------------------------------

5. ディスクフォーマット

以下3つのコマンドで/dev/sdbのフォーマットを行う。

$ sudo parted -a optimal /dev/sdb mklabel gpt
------------------------------
Information: You may need to update /etc/fstab.
------------------------------

$ sudo parted -a optimal -- /dev/sdb unit compact mkpart primary  ext3 "1" "-1"
------------------------------
Information: You may need to update /etc/fstab.
------------------------------

$ sudo mkfs.ext4 /dev/sdb1
------------------------------
mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
2621440 inodes, 10485248 blocks
524262 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
320 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
4096000, 7962624

Allocating group tables:   0/320       done                            
Writing inode tables:   0/320       done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information:   0/320       done
------------------------------

6. /mnt/tmpに新ディスクをマウント

データコピーのため、新ディスクを/mnt/tmpにマウントする。

$ sudo mkdir /mnt/tmp
$ sudo mount /dev/sdb1 /mnt/tmp
$ df -h
------------------------------
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G  4.0K  2.0G   1% /dev
tmpfs           396M  692K  395M   1% /run
/dev/dm-0        15G   14G  981M  94% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/sda1       236M   74M  150M  34% /boot
/dev/sdb1        40G   48M   38G   1% /mnt/tmp   ←★マウントされた
------------------------------

7. データコピー

Graylogのデータを旧ディスクから新ディスクにコピーする。データは以下ディレクトリに入っているすべてのファイルとなる。

$ ls -l /var/opt/graylog/data/
------------------------------
total 16
drwxr-x--- 3 graylog graylog 4096 Apr  1 11:59 elasticsearch
drwxr-x--- 3 graylog graylog 4096 May 12 21:40 etcd
drwxr-x--- 3 graylog graylog 4096 May 12 21:41 journal
drwxr-x--- 4 graylog graylog 4096 May 12 21:41 mongodb
------------------------------

cpコマンドでデータをコピーする。容量によっては時間がそこそこ必要となる。

$ sudo cp -ax /var/opt/graylog/data/* /mnt/tmp/

コピー完了後、diffでファイル差分の確認を行う。

$ sudo diff -qr --suppress-common-lines /var/opt/graylog/data  /mnt/tmp
------------------------------
Only in /mnt/tmp: lost+found   ←★この1行だけ表示されればOK
------------------------------

8. 元ディレクトリのデータを削除し、新ディレクトリと入れ替え

旧データを削除する。フォルダを間違えないように注意すること。

$ sudo rm -rf /var/opt/graylog/data/*

一時的にマウントしていた/mnt/tmpの新ディスクをアンマウントする。

$ sudo umount /mnt/tmp

アンマウントした新ディスクを/var/opt/graylog/dataにマウントする。

$ sudo mount /dev/sdb1 /var/opt/graylog/data

マウント結果を確認する。

$ df -h
------------------------------
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G  4.0K  2.0G   1% /dev
tmpfs           396M  692K  395M   1% /run
/dev/dm-0        15G  2.7G   12G  19% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/sda1       236M   74M  150M  34% /boot
/dev/sdb1        40G   11G   27G  29% /var/opt/graylog/data
------------------------------

9. 起動時にマウントされるよう、fstabに追加

fstabに新ディスクが自動でマウントされるよう、1行設定を追加する。

$ echo '/dev/sdb1 /var/opt/graylog/data ext4 defaults 0 0' |  sudo tee -a /etc/fstab
/dev/sdb1 /var/opt/graylog/data ext4 defaults 0 0

fstabの中身を確認する。

$ cat /etc/fstab
------------------------------
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/graylog--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=dc6ba91f-86f9-4218-bc13-ccba72b15e63 /boot           ext2    defaults        0       2
/dev/mapper/graylog--vg-swap_1 none            swap    sw              0       0
/dev/sdb1 /var/opt/graylog/data ext4 defaults 0 0
------------------------------

10. Graylogを再起動

最後にGraylogを再起動しておく。

$ sudo shutdown -r now

以上でディスク拡張作業は完了となるが、前述したとおり、Elasticsearchのエラーは解消しなかった。

解消するために、さらに対応する必要があったが、その方法は別記事にて記載することにする。

2017年5月13日土曜日

Linuxでプロキシ経由でインターネット通信をする (プロキシがある環境化でyumを使う)

ちょっとした小ネタ。

プロキシがある環境でyumを使ったら、なかなか成功しなかったので、備忘録として記載する。OSはCentOS 7.3となる。ちなみに、この手順はapt-getを使うLinuxディストリビューション(Ubuntuなど)でも同様に動作する。

環境変数を設定する

まずは失敗するパターン。

# yum check-update
------------------------------
読み込んだプラグイン:fastestmirror
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was
14: curl#7 - "Failed to connect to 2001:4178:5:200::10: ネットワークに届きません"

~(以下略)~
------------------------------

「ネットワークに届きません」というエラーが出て失敗している。IPv6のアドレスが表示されているので、IPv4ではなくてIPv6のアドレスで接続しようとしているのかと疑ったが、そうではなくてプロキシ設定をしていないことが問題だった。

というわけで、以下のように環境変数を設定する。

# export http_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
# export https_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
# export ftp_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"

# export ←確認コマンド
------------------------------
declare -x ftp_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
declare -x http_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
declare -x https_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
------------------------------

再度yumを実行すると、以下の通り成功した。

# yum check-update
------------------------------
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.usonyx.net
 * extras: download.nus.edu.sg
 * updates: centos.usonyx.net
base/7/x86_64/primary_db                                   | 5.6 MB   00:00  

NetworkManager.x86_64                     1:1.4.0-19.el7_3               updates
NetworkManager-libnm.x86_64               1:1.4.0-19.el7_3               updates

~(中略)~

wpa_supplicant.x86_64                     1:2.0-21.el7_3                 updates
xfsprogs.x86_64                           4.5.0-9.el7_3                  updates
------------------------------

2017年5月5日金曜日

MMCを使ってActive Directoryをリモート管理する

先日、ドメインコントローラーをServer Coreで構築した。Server Coreのドメインコントローラー作成の記事は以下。

------------------------------
・Windows Server 2008 R2 Server CoreでActive Directoryのドメインコントローラーを作った話① (Server Core OS初期設定)
https://tech-mmmm.blogspot.jp/2017/02/windows-server-2008-r2-server.html
・Windows Server 2008 R2 Server CoreでActive Directoryのドメインコントローラーを作った話② (ドメインコントローラー昇格)
https://tech-mmmm.blogspot.jp/2017/02/windows-server-2008-r2-server_25.html
------------------------------

Server CoreはGUIが利用できないので、ドメインのユーザー管理やグループポリシー設定を行う際にリモートから操作する必要がある。そこで、ドメインのメンバーサーバーからリモートでActive DirectoryとDNSを管理できるようにした。

MMC (Microsoft Management Console)を使って管理する

ドメインコントローラーやDNSは、通常MMC (Microsoft Management Console)を使って管理するが、ドメインコントローラーとなっていないメンバーサーバーでは、MMCに管理用のスナップインが表示されない。

そこで、サーバーマネージャーを開き、「役割と機能の追加」から、以下の下線の機能を追加する。

------------------------------
リモートサーバー管理ツール
 →役割管理ツール
  →AD DSおよびAD LDSツール
   →AD DSツール
    →AD DSスナップインおよびコマンドラインツール
  →DNSサーバーツール
------------------------------

 ※注:上記は既にインストール済みの画面となる

インストール後に「ファイル名を指定して実行」から「mmc」と入力するとMMCが起動できるので、「ファイル」→「スナップインの追加と削除」を選ぶとActive Directoryの管理用のスナップインが選択できる。主に管理として利用するスナップインは以下の通りとなる。個人的によく使うと思うものに★印を付けてみた。

------------------------------
・Active Directory サイトとサービス
・Active Directory スキーマ
・Active Directory ドメインと信頼関係
★Active Directory ユーザーとコンピューター
★DNS
★グループポリシーの管理
------------------------------


スナップインを追加した画面は以下の通り。MMC起動後の初回接続時は、多少時間が掛かることがあるが、Active Directoryのコンピューター情報やユーザー情報を確認できることがわかる。


Active Directoryは何もしなくてもドメインコントローラーに自動接続するが、DNSだけは接続先サーバーを選択する必要がある。


サーバーに接続できれば、以下のようにDNSも同じ画面で確認できるようになる。


以上で、Active DirectoryとDNSの管理がリモートからできるようになる。MMCの表示設定は保存できるので、名前を付けてファイルとして保存しておくと、今後利用する際に便利だろう。



2017年4月28日金曜日

vCenter Serverは不要。ESXi単独で仮想マシンのクローンを作る方法

vSphere環境で仮想マシンのクローンを作る場合は、vCenter Serverを用意する必要があると思っていたが、実はESXiシェルのコマンドを使えばESXi単独でクローンが作れてしまうことを最近知った。

若干手順が多くなるのでちょっと手間ではあるものの、無償のESXiのみの環境であってもクローンが使えることは非常に便利である。例えば、よく使うOSの仮想マシンはテンプレートとして1台作っておいて、今回記載する手順でクローンして使うようにすれば、検証作業のたびにOSインストールから始める必要がなくなって効率がよくなる。

ESXi単独での仮想マシンのクローンの手順

以下に手順を記載していく。

1. クローン先の仮想マシンの箱を作成

vSphere Clientなどでクローン元と同じ構成で仮想マシンを作成する。仮想マシン作成時に「標準」と「カスタム」が選べるが、「標準」を選んだ場合、必ず仮想マシンに1つディスクを作成する必要がある。このディスクは次の手順ですぐに消すため、1GBと小さくして作成しておけばよい。
※「カスタム」の場合は、ディスクを作らない仮想マシンの箱を作成できる。


2. クローン先の仮想マシンのディスク削除

仮想マシン作成時に作られたディスクは不要なので、仮想マシンから削除(ディスクからも削除)しておく。


3. sshでESXiシェルにログイン

Tera Termなどでログインする。なお、ESXiの場合は、「チャレンジレスポンス認証」を選んでログインする。

4. コピー元ディスクの確認

データストアは以下パスに存在する。

/vmfs/volumes/<データストア名>/<仮想マシン名>

クローン元のファイルを事前に確認しておく。コピー対象となるファイルは*.vmdkファイルとなる。以下確認例となる。

[root@t3011es60:~] ls -l /vmfs/volumes/ssd_local_01/t1162w28r/
total 7388176
------------------------------
-rw-------    1 root     root     42949672960 Apr 26 13:55 t1162w28r-flat.vmdk
-rw-------    1 root     root          8684 Apr 26 13:41 t1162w28r.nvram
-rw-------    1 root     root           524 Apr 26 13:55 t1162w28r.vmdk
-rw-r--r--    1 root     root            43 Apr 26 13:55 t1162w28r.vmsd
-rwxr-xr-x    1 root     root          2806 Apr 26 13:55 t1162w28r.vmx
-rw-------    1 root     root          4151 Apr 17 05:19 t1162w28r.vmxf
-rw-r--r--    1 root     root       1203822 Apr 18 21:24 vmware-1.log
-rw-r--r--    1 root     root        267260 Apr 26 13:41 vmware.log
------------------------------

5. ディスクコピーの実施

以下コマンドで仮想マシンのディスクをコピーする。

vmkfstools -i <クローン元> <クローン先> -d <ディスク形式>

"-d"オプションでディスクの形式を選択できる。

・zeroedthick (default) : シックプロビジョニング
・thin : シンプロビジョニング
・eagerzeroedthick : EagerZeroedThick (作成時に0書き込み)

以下シンプロビジョニング形式でクローンを作成する実行例となる。

[root@t3011es60:~] vmkfstools -i /vmfs/volumes/ssd_local_01/t1162w28r/t1162w28r.vmdk  /vmfs/volumes/iscsi_qnap_01/t1165w28r/t1165w28r.vmdk -d thin
------------------------------
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/ssd_local_01/t1162w28r/t1162w28r.vmdk'...
Clone: 100% done.
------------------------------

なお、仮想マシンがパワーオン状態の場合、以下のようにファイルがロックされているメッセージが表示されてしまいクローンが実行できない。

------------------------------
Failed to open '/vmfs/volumes/ssd_local_01/t1162w28r/t1162w28r-000001.vmdk': Failed to lock the file (16392).
Command exited with non-zero status 255
------------------------------

この場合は、一度仮想マシンのスナップショットを取得してから、再度vmkfstoolsコマンドを実行すれば成功する(スナップショットを取得すると、vmdkファイルのロックが差分用のvmdkファイルに移るため)。一時的にスナップショットを取得した場合は、作業後のスナップショット削除も忘れずに。

6. 仮想マシンにディスクを追加

vSphere Clientで、先ほどコピーしたvmdkファイルを指定して、仮想マシンのハードディスクを追加する。



7. 仮想マシンを起動

仮想マシンを起動する。特に問題なくログイン画面が表示される。


なお、仮想マシン起動状態でクローンを実施した場合は、以下のように正常にシャットダウンされなかった旨が表示されるが、「windows を通常起動する」を選べばOSは起動できる。


参考

ESX/ESXi ホスト端末を使用して個々の仮想マシン ディスクのクローンを作成する (2078416)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2078416

vmkfstools を使用した仮想マシン ディスクのクローン作成および変換 (2078921)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2078921

2017年4月22日土曜日

ESXi 6.0上にESXi 5.5の仮想マシンを作って、ESXi用のVMware Toolsをインストールした話 (ESXi on ESXi)

自宅の検証環境はESXi 6.0で構築しているが、ちょっとESXi 5.5の検証作業が必要になったので、仮想マシンとしてESXi 5.5を作成することにした。これは、Nested ESXiとかESXi on ESXiと呼ばれる方法で、検証等ではよく用いられる手法である。

本記事ではESXi 6.0上にESXi 5.5の仮想マシンを作成する方法と、ESXi 5.5用のVMware Toolsのインストール手順について記載する。

ESXiのインストール

まず、ESXi用に仮想マシンの箱を作成する。ESXi 6.0では、仮想マシンのOS選択にて、「その他」の中にESXiが選べるようになっているので、適切な種類を選択すればよい。今回は、ESXi 5.5なので、「VMware ESXi 5.x」を選択した。


また、ESXiにはインストール最小要件があるので注意する。以下KBに記載がある通り、ESXi 5.5の場合は、CPUは2コア以上、メモリは4GB以上必要となる。

・ESXi 5.5 のインストールおよびアップグレードのベスト プラクティス (2080534)
 https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2080534

作成した仮想マシンを起動する前に、vmxファイルを修正する必要がある。データストアブラウザにてvmxファイルをダウンロードし、最下行に以下2行を追加したのち、アップロードして上書きする。

------------------------------
vhv.enable = "TRUE"
hypervisor.cpuid.v0 = "FALSE"
------------------------------

作成した仮想マシンを起動させ、VMware社のサイトからダウンロードしたESXiのisoをマウントしてブートさせる。Nested ESXiであっても、インストール方法は特に変化がないため、ここでは詳細は割愛する。なお、ここで、CPUやメモリが最小要件を満たしていない場合、以下のようなエラーメッセージが表示され、インストールを進めることができないので注意。


ESXiの初期設定

正常にESXiのインストールが終わり、起動が完了したら、まずは仮想マシンのコンソールを用いて、管理用のIPアドレス設定をしておこう。


管理用ポートの設定ができれば、後はvSphere Clientにて接続して操作・設定が可能となる。ただし、ESXi 5.5にはvSphere Client 6.0では接続できないので、vSphere Client 5.5をインストールしておくことが必要となる。

なお、vSphere Clientは上書きインストールにはならず、各バージョンが共存して利用可能である(接続先のESXiやvCenter Serverのバージョンに応じて、適切なバージョンのvSphere Clientで接続がされる)ので、既に別バージョンのvSphere Clientがインストールされていたとしても、単純にvSphere Client 5.5のインストーラーを実行して、インストールしてしまえばよい。

ESXi用のVMware Toolsのインストール

以下URLからESXi用のVMware Toolsをダウンロードできる。

・VMWARE TOOLS FOR NESTED ESXI
 https://labs.vmware.com/flings/vmware-tools-for-nested-esxi#summary

なお、このVMware Toolsは、ESXi 6.0以降をネストする場合は不要のようだ。上記URLに「This Fling's functionality is now integrated into ESXi 6.0 and later. However, you can still download the Fling for ESXi 5.*」と記載されているとおり、ESXi 6.0以降では本機能(VMware Tools)は、もともと本体に組み込まれている模様。

ちなみに、ダウンロード場所が若干わかりづらいが、本文にさらりと記載されている、「This VIB package」のリンクをクリックすればよい。以下ファイル名のVIBファイルがダウロードされる。容量は2MB以下とコンパクト。

 esx-tools-for-esxi-9.7.2-0.0.5911061.i386.vib

ダウンロードしたVIBファイルは、vSphere Clientのデータストアブラウザを使って、アップロードしておく。今回は、ESXiのローカルディスクであるdatastore1にアップロードした。


VIBファイルをアップロードした後は、ESXiシェルにてインストールを実施する。親ESXiにて仮想コンソールを使うか、sshを有効にしている場合はsshにてESXiシェルにログインする。

ログインしたのち、以下コマンドを実行する。実行後、「The update completed successfully」と表示されれば成功。

# esxcli software vib install -v /vmfs/volumes/datastore1/esx-tools-for-esxi-9.7.2-0.0.5911061.i386.vib
------------------------------
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMware_bootbank_esx-tools-for-esxi_9.7.2-0.0.5911061
   VIBs Removed:
   VIBs Skipped:
------------------------------

インストール結果に記載されている通り、ESXiの再起動が必要となるため、再起動をしておく。

# shutdown -r

後は親ESXiでVMware Toolsの実行状況を確認すればよい。「実行中 (サポート対象外)」という表示になっていればOK。IPアドレス情報が確認できるし、ゲストのシャットダウン等の機能も利用できるようになる。


以上で作業は完了となる。

2017年4月14日金曜日

ZabbixでCPUやメモリなどのリソース監視を行う

先日、ESXiのCPU、メモリの使用率をグラフに表示するという記事を書いた。その後しばらくして、ESXiのCPU使用率が高い値で張り付くという事象が発生した。


原因は、1台の仮想マシン(Windows Server)のSQL Serverが高負荷になったことであり、仮想マシンの再起動で復旧できた。しかし、根本原因は不明であり、不定期に再発することもあったことから、ZabbixでCPUのリソース監視を行うことにした。

アイテムを作る

ESXiのCPU使用率とメモリ使用率のアイテムの作り方は、別記事を参照。

トリガーを作る

「設定」→「テンプレート」→「Template Virt VMware Hypervisor」→「トリガー」を選択し、トリガーを新規作成する。

今回は例として、CPU周波数が2GHz = 2000000000Hzを600秒超過した場合に、「重度の障害」として検知する設定となる。余談だが、"2G"という表記でもZabbixは認識してくれるが、2G = 2*1024*1024*1024となり、正確な値にならないので注意が必要。

------------------------------
・名前:High CPU Usage
・条件式:{Template Virt VMware Hypervisor:vmware.hv.cpu.usage[{$URL},{HOST.HOST}].avg(600)}>2000000000
・深刻度:重度の障害
・障害イベントを継続して生成:チェックなし
・有効:チェックあり
------------------------------


なお、メモリを監視したい場合の条件式に入れる値は以下のようになる。
※事前にアイテムを作成していることが必要

------------------------------
・メモリ使用量
 vmware.hv.memory.used[{$URL},{HOST.HOST}]
・メモリバルーン
 vmware.hv.memory.size.ballooned[{$URL},{HOST.HOST}]
------------------------------

グラフで確認

グラフを作ってある場合は、グラフにもトリガー設定の閾値が表示されるので確認しておこう。今回設定した2GHzが監視閾値として、点線で表現されていることがわかる。


以上で設定は完了となる。

2017年4月9日日曜日

オープンソースのログ統合管理ツール「Graylog」でsquidのログを管理する

自宅の検証環境では、squidを使ってプロキシサーバーを構築しており、このプロキシサーバーを経由してインターネットにアクセスするように構成している。このsquidログをsyslogでGraylogに飛ばして管理してみたのだが、ログの中身までは分析されず、ただ保存されるだけとなってしまい、統計情報を確認したり、ログを分析することは困難となっていた。

そこで、Graylogでこのsquidログに対し、分類・タグ付け(ログの正規化)を行い、統計情報を表示できるようにしてみた。

GraySquidのダウンロード

まず、Graylogにてsquidを管理するためのContent Packを以下からダウンロードしておく。

GraySquid
https://marketplace.graylog.org/addons/bd3efa5f-6ccb-47ce-97ea-6ebe0270a9c7

拡張子が.jsonとなるJSONで記載されたテキストファイルがダウンロードされる。
※JSON (JavaScript Object Notation):XMLのようなテキストベースのデータフォーマット

このContet Packの概要は以下の通り。

 ・Graylogの受信ポート番号はTCP/19302を使う
 ・squidログは標準形式のものを取り込む(apacheのログ形式はきちんと取り込めない)
 ・squidログの各種情報(アクセス先URLやステータスコードなど)を正規化して取り込む
 ・squidの直近の通信の統計情報を表示するDashboardも用意されている

GraylogにGraySquidをインポート

GraylogのWeb GUIにログインし、Content Packのインポートから実施する。

「System」→「Content Packs」を選択し、「Select content packs」の一番下に「Import Content Pack」という項目があるため、先ほどダウンロードしたJSONのファイルを選択し、「Upload」ボタンを押下する。


インポートが成功すると、「Select content packs」に「Proxies」という項目が新たに表示されるので、その中の「Squid Logs」を選択し、「Apply Content」ボタンを押下する。


これだけで、TCP/19302で受信したログをsquidのログとして取り込む準備が完了する。

squid側の設定

squid側でログを飛ばす設定を行う。squidのaccess.logをrsyslogにてGraylogに飛ばす設定となる。なお、今回ログを飛ばすOS、squid、rsyslogのバージョンは以下の通りとなる。

# cat /etc/redhat-release
------------------------------
CentOS Linux release 7.3.1611 (Core)
------------------------------

# squid -v
------------------------------
Squid Cache: Version 3.5.20
------------------------------

# rsyslogd -v
------------------------------
rsyslogd 7.4.7
------------------------------

squidがインストールされたLinuxにログインし、以下ファイルを新規作成する。

# vi /etc/rsyslog.d/60-squid.conf
------------------------------
# Load Modules
module(load="imfile")
module(load="omfwd")

# rsyslog Input Modules
input(type="imfile"
         File="/var/log/squid/access.log"
         Tag="squid-access"
         Severity="info"
         Facility="local7"
         ruleset="SquidForward")

# rsyslog RuleSets
ruleset(name="SquidForward") {
        action(type="omfwd"
        Target="<GraylogのIPアドレス>"
        Port="19302"
        Protocol="tcp"
        template="RSYSLOG_SyslogProtocol23Format")
}
------------------------------

設定反映のため、rsyslogサービスをリスタートする。

# systemctl restart rsyslog
# systemctl status rsyslog   ←確認
------------------------------
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since 日 2017-04-02 07:22:34 JST; 5s ago
 Main PID: 5493 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           mq5493 /usr/sbin/rsyslogd -n

 4月 02 07:22:34 t3023ce72 systemd[1]: Starting System Logging Service...
 4月 02 07:22:34 t3023ce72 systemd[1]: Started System Logging Service.
------------------------------

Graylogにてログの確認

squid側の設定が完了したら、実際にログが表示されることを確認する。

「Search」タブにてログを表示させ、squidのログをクリックしてみる。MethodやStatus_Codeがそれぞれ分類されて表示されており、ログが正規化されていることがわかる。


次に「Dashboards」を選択すると、以下3つのDashboardが追加されていることがわかる。

 ・Squid TCP_ALLOWED
 ・Squid TCP_DENIED Stats
 ・SquidStats


お勧めは3つめの「SquidStats」で、直近15分のsquidを経由した通信の統計情報が表示される。直近15分では統計情報として物足りないのであれば、時間をカスタマイズすることも可能な模様。ただし、時間を延ばせば、その分Graylogの処理も増えるはずなので、マシンリソースと相談して設定するのがよいだろう。



以上で、Graylogにてsquidログを正規化して取り込み、統計情報を表示することができた。ただし、squidログは生ログで見ると時間表示がUNIX時間(1970/1/1からの累計時間)で表示される仕様となっており、人間が確認する場合は視認性がいまいちである。squidログはapache形式にログ表示を変えることができるので、apache形式でログ取得して同様のことができないかも調べていきたい。

2017年4月2日日曜日

オープンソースのログ統合管理ツール「Graylog」の仮想アプライアンスをインストールしてみた

昨年、SIEM(Security Information Event Management)を検討する機会があり、SplunkやMcAfee SIEMの評価版を自宅の検証環境に入れて使っていた。当たり前だが、SplunkもMcAfee SIEMも評価版は使用日数に制限があり(Splunkは60日、McAfee SIEMは30日)、長期的に利用することは不可能であった。そこで、オープンソースでログを統合管理するツールがないかと探していたら、「Graylog」を発見した。

試しにGraylogの仮想アプライアンスをインストールしてみて使ってみたら、なかなか有用なツールと感じた。本記事ではGraylogの仮想アプライアンスのインストールと初期設定の手順を記載する。

Graylogの入手とインストール

Graylogのインストーラは以下から入手する。2017年4月時点の最新バージョンは、2.2.2となっていた。

Graylog - Download and Install
https://www.graylog.org/download

今回はVMware ESXi上に展開するので、「OVA」ファイルをダウンロードする。

OVAファイルの展開は、vSphere Clientにて「ファイル」→「OVFテンプレートのデプロイ」にて実施する。設定項目はデフォルトで問題ない。私の場合は、ディスク容量の削減のため、ディスクの種類を「Thin Provision」にしている。


OVAテンプレートのデプロイが完了する。仮想アプライアンスのリソースはCPU2コア、メモリ4GBとなっているが、ここもデフォルトのままで問題ない。最初、リソース削減のため、CPUを1コアにしてみたが、CPU使用率が100%で張り付いたりしたので、1コアではちょっときつい模様。


問題なければパワーオンする。起動時にvSphere Clientにて以下のメッセージが表示されるが、「はい」を選んで「OK」を押しておけば問題なく起動する。

------------------------------
Virtualized Inter-VT-x/EPT is incompatible with this virtual machine configration.
仮想msg.intel.hvhwnnuを使わずに続行しますか?
------------------------------


Graylogの仮想アプライアンスは、ubuntu 14.04がベースとなっている。起動時はNICのDHCP機能が有効になっているので、IPアドレスの取得待ちに少し時間を要するが、ログインプロンプトが表示されるまで待機する。なお、ログインプロンプト表示の際に、以下メッセージが表示されている場合があるが、同じくDHCPでIPが取得できなかったことに起因するメッセージなので無視してOK。

------------------------------
Your appliance came up without a configured IP address. Graylog is probable not running correctly!
------------------------------


インストール後の初期設定

Graylogの初期設定を実施し、Web GUIにログインできるようにする。

ログインとパスワード変更

まずはログインとなる。初期パスワードは以下の通り。

 ユーザー名:ubuntu
 パスワード:ubuntu

ログインしたら、とりあえずパスワードを変更しておく。

$ passwd
------------------------------
Changing password for ubuntu.
(current) UNIX password:<現在のパスワード>
Enter new UNIX password:<新パスワード>
Retype new UNIX password:<新パスワード>
passwd: password updated successfully
------------------------------

IPアドレス設定

IPアドレスの設定はubuntuと同じ方式で設定すればよい。viで以下ファイルを開き編集する。なお、ubuntuなので、頭にsudoを付けて編集しているが、毎回sudoを付けるのが面倒な場合は"sudo su -"でrootになってしまってもよい。

$ sudo vi /etc/network/interfaces
------------------------------
# The primary network interface
auto eth0
#iface eth0 inet dhcp       ←コメントアウト
#pre-up sleep 2         ←コメントアウト

iface eth0 inet static      ←追加 (静的IPアドレス付与)
address 192.168.11.151      ←追加 (IPアドレス)
netmask 255.255.255.0      ←追加 (サブネットマスク)
gateway 192.168.11.1       ←追加 (デフォルトゲートウェイ)
dns-nameservers 192.168.11.1   ←追加 (DNS)
------------------------------

設定反映のためにインターフェースの落とし上げを行う。

$ sudo ifdown eth0
$ sudo ifup eth0

設定を確認しておく。

$ ifconfig
------------------------------
ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:29:3a:6a:6f
          inet addr:192.168.11.151  Bcast:192.168.11.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe3a:6a6f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
------------------------------

Graylogの初期設定

Graylogのアプリケーションとしての初期設定は以下2つのコマンドを実行するのみ。

まずは、Web GUIのログイン時のパスワードを変更する。

$ sudo graylog-ctl set-admin-password <新パスワード>

次に、タイムゾーンを変更する。

$ sudo graylog-ctl set-timezone "Asia/Tokyo"

最後に設定反映のコマンドを実行するのだが、この際にapt-getが動作するようで、インターネットへの接続ができる状態で実行したほうがよい。プロキシ環境の場合は、以下の通りプロキシ設定を実施しておく。

$ export http_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
$ export https_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
$ export ftp_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
$ export ←確認コマンド
------------------------------
declare -x ftp_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
declare -x http_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
declare -x https_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
------------------------------

設定反映のコマンドを実行する。このコマンドは少々時間がかかる。プロキシ設定の環境変数を引き継ぐ必要があるので、"sudo"ではなく"sudo -E"で実行すること。

$ sudo -E graylog-ctl reconfigure

open-vm-toolsのインストール

仮想アプライアンスなのに、なぜかopen-vm-toolsが入っていないなので、apt-getでインストールする。

$ sudo -E apt-get update
$ sudo -E apt-get install open-vm-tools

GraylogのWeb GUIにログイン

以上で初期設定は終わりとなる。ブラウザからhttpにて仮想アプライアンスのIPアドレスを指定すると、ログイン画面が表示される。


以下のユーザー名、パスワードでログインする。

 ユーザー名:admin
 パスワード:<先ほど設定したパスワード>

以下のような画面が表示されればログイン成功。


LinuxのSyslogを転送させてみる

Graylogは初期状態からsyslog転送をUDP/514ポートで受け付ける状態になっているので、試しにLinuxサーバーからSyslogを転送させてみる。

Syslog送信元サーバーで、/etc/rsyslog.confの最後に以下設定を追加する。
※192.168.11.151はGraylogのIPアドレスに適宜変更

# vi /etc/rsyslog.conf
------------------------------
*.* @192.168.11.151:514;RSYSLOG_SyslogProtocol23Format
------------------------------

設定反映のため、rsyslogサービスをリスタートする。

# systemctl restart rsyslog
# systemctl status rsyslog   ←確認
------------------------------
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since 日 2017-04-02 07:22:34 JST; 5s ago
 Main PID: 5493 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           mq5493 /usr/sbin/rsyslogd -n

 4月 02 07:22:34 t3023ce72 systemd[1]: Starting System Logging Service...
 4月 02 07:22:34 t3023ce72 systemd[1]: Started System Logging Service.
------------------------------

これで、GraylogのWeb GUIにて、「Search」をクリックすると、ログが表示されるはず。


以上でインストールと初期設定は終了となり、とりあえずログを溜めて検索する機能は利用可能になる。Graylogには各種ログを解析するための「Content Pack」と呼ばれる、様々なログに対応したプラグインが提供されているので、今後それらを追加してログの分析ができるようにしていきたい。

2017年3月20日月曜日

USB3.0の1Gb 物理NICを買って仮想マシンに接続してみた

USB3.0になってから、データ転送速度が4Gbps=500MB/sになったということで、1GbpsのNICよりも転送速度が速くなっている(USB2.0は480Mbps=60MB/s)。今は安価でUSB3.0の1Gbpsの物理NICが売られているので、1つ買って検証用マシンのNICを増設することにした。

できることなら、ESXi自体のNICとして利用したかったのだが、案外手間がかかりそうだったので、仮想マシンのNICとして使うことにした。

購入したUSB3.0のNIC

今回購入したNICは以下となる。有名なメーカーでは無いが、安価だったことが購入の決め手となった。Amazonのレビューでも記載されているが、中身のチップセットはRealtek RTL8153となる。

このNICをESXiとして利用している物理マシンのUSB3.0ポートに接続し、ESXi自体で認識状況を確認してみる。1行目に「8153 Realtek」の文字が確認でき、ESXiとしても認識はしているようだ。

[root@esx01:~] lsusb
------------------------------
Bus 004 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. 
Bus 003 Device 003: ID 05e3:0723 Genesys Logic, Inc. GL827L SD/MMC/MS Flash Card Reader
Bus 003 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
------------------------------

仮想マシンへの接続

続けて、NICを仮想マシンに接続する。vSphere Clientにて、接続したい仮想マシンを選んで、「設定の編集」を開く。

USBデバイスを使用する前に、まずはUSBコントローラを追加する必要がある。「追加」ボタンを押し、「USBコントローラ」を選択する(この時点では「USBデバイス」はグレーアウトしており追加不可)。コントローラタイプとして、"EHCI+UHCI"と"xHCI"の2種類が選択可能だが、USB3.0の場合は、"xHCI"を選ぶ。



一旦、「OK」を押して設定の編集画面を閉じたのち、再度「設定の編集」を開く。「USBデバイス」を選択すると、"Realtek USB 10/100/1000 LAN"が選択できるはずなので選択する。



これで仮想マシンにNICが追加された。Windowsの場合は標準のドライバで認識しているはず。Windows Server 2016の場合は、"usb_xhci"という名前でNICが表示された。



Windowsのドライバーの更新

Windows標準のドライバーで認識はするものの、最新ドライバーとなっていない。例えばWindows Server 2016では、OS標準ドライバーのバージョンは10.5となるが、本記事を記載した時点の最新ドライバーは10.13になる。そこで、最新のドライバーファイルを入手し更新することにする。

以下は、OS標準ドライバーの状態。2015年9月のドライバーとなっている。



ドライバーの最新バージョンの確認とダウンロードは、以下URLから実施できる。

Realtek - Software: Drivers & Utilities RTL8153
http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false

ダウンロードしたドライバーのフォルダの中にsetup.exeが同梱されているが、今回はデバイスマネージャーから更新を行うことにする。

デバイスマネージャーを開き、「Realtek USB GbE Family Controller」のプロパティを開き、「ドライバーの更新」を選択する。



ドライバーファイルのパスを聞かれるので、

   <ドライバーの解凍パス>\WIN10\64\rtux64w10.INF

を選択する。

  
後は自動でドライバーが更新され、バージョンが最新となっていればOK。


このNICを使ってQNAPのNASにファイル転送を実施してみると、100MB/s以上の転送速度が出るので、1Gbpsの帯域近くまで使えており、1000円程度のNICでも問題なく速度が出ることがわかった。最近は無線LANのみで物理NICを持たないノートPCが多いので、サーバーメンテナンス等で物理NICが欲しい場合に備えて、1個持っておくのはよいかもしれない。

2017年3月3日金曜日

CentOS 7にunboundをインストールしてDNSキャッシュサーバーにしてみた

DNSといえば昔からBINDが有名だが、BINDは機能が高度化して複雑になっており、それゆえ脆弱性の問題が多く発見される傾向にある。

以下サイトでまとめられているが、1か月に1回は脆弱性情報が公開される印象がある。

・JPRS DNS関連技術情報
https://jprs.jp/tech/

というわけで、単純なDNSキャッシュサーバーであれば、そろそろBINDを使わなくてもよいのではないか?ということで、unboundというOSSを使ってみることにした。

unbound導入手順

今回はCentOS 7.3にunboundを導入する。

1. yumでunboundをインストール

yumを使ってインストールする。

# yum install unbound
------------------------------
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.nus.edu.sg
 * extras: centos.usonyx.net
 * updates: mirror.vastspace.net
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ unbound.x86_64 0:1.4.20-28.el7 を インストール
--> 依存性の処理をしています: unbound-libs(x86-64) = 1.4.20-28.el7 のパッケージ: unbound-1.4.20-28.el7.x86_64
--> 依存性の処理をしています: ldns >= 1.6.16-10 のパッケージ: unbound-1.4.20-28.el7.x86_64
--> 依存性の処理をしています: libunbound.so.2()(64bit) のパッケージ: unbound-1.4.20-28.el7.x86_64
--> 依存性の処理をしています: libldns.so.1()(64bit) のパッケージ: unbound-1.4.20-28.el7.x86_64
--> 依存性の処理をしています: libevent-2.0.so.5()(64bit) のパッケージ: unbound-1.4.20-28.el7.x86_64
--> トランザクションの確認を実行しています。
---> パッケージ ldns.x86_64 0:1.6.16-10.el7 を インストール
---> パッケージ libevent.x86_64 0:2.0.21-4.el7 を インストール
---> パッケージ unbound-libs.x86_64 0:1.4.20-28.el7 を インストール
--> 依存性解決を終了しました。

依存性を解決しました

================================================================================
 Package              アーキテクチャー
                                     バージョン              リポジトリー  容量
================================================================================
インストール中:
 unbound              x86_64         1.4.20-28.el7           base         473 k
依存性関連でのインストールをします:
 ldns                 x86_64         1.6.16-10.el7           base         476 k
 libevent             x86_64         2.0.21-4.el7            base         214 k
 unbound-libs         x86_64         1.4.20-28.el7           base         296 k

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

総ダウンロード容量: 1.4 M
インストール容量: 4.4 M
Is this ok [y/d/N]: y
Downloading packages:
(1/4): ldns-1.6.16-10.el7.x86_64.rpm                       | 476 kB   00:00  
(2/4): unbound-1.4.20-28.el7.x86_64.rpm                    | 473 kB   00:00  
(3/4): unbound-libs-1.4.20-28.el7.x86_64.rpm               | 296 kB   00:00  
(4/4): libevent-2.0.21-4.el7.x86_64.rpm                    | 214 kB   00:00  
--------------------------------------------------------------------------------
合計                                               1.4 MB/s | 1.4 MB  00:00  
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction

~(中略)~

インストール:
  unbound.x86_64 0:1.4.20-28.el7                                              

依存性関連をインストールしました:
  ldns.x86_64 0:1.6.16-10.el7               libevent.x86_64 0:2.0.21-4.el7    
  unbound-libs.x86_64 0:1.4.20-28.el7    

完了しました!
------------------------------

yumが使えない場合は、rpmからインストールする必要があるが、依存するパッケージとインストール順序は以下の通りとなる。

------------------------------
 1 -> libevent-2.0.21-4.el7.x86_64.rpm
 2 -> ldns-1.6.16-10.el7.x86_64.rpm
 3 -> unbound-libs-1.4.20-28.el7.x86_64.rpm
 4 -> unbound-1.4.20-28.el7.x86_64.rpm
------------------------------

2. unbound設定

/etc/unbound/unbound.confを編集し、必要な設定を行う。デフォルトではすべてがコメントアウトされているので、必要な部分をコメントインしたり、追記したりすればよい。

以下に修正箇所を記載する。

------------------------------
server:
       interface: 0.0.0.0     ←すべてのアドレスからの問い合わせに回答(IPv4)
       interface: ::0       ←すべてのアドレスからの問い合わせに回答(IPv6)

       access-control: 0.0.0.0/0 refuse   ←デフォルト拒否(IPv4)
       access-control: 127.0.0.0/8 allow  ←ループバックアドレスを許可(IPv4)
       access-control: 192.168.1.0/24 allow ←問い合わせを許可するネットワーク
       access-control: ::0/0 refuse     ←デフォルト拒否(IPv6)
       access-control: ::1 allow       ←ループバックアドレスを許可(IPv6)
       access-control: ::ffff:127.0.0.1 allow ←ループバックアドレスを許可(IPv6)

 forward-zone:           ←コメントインする
       name: "."            ←すべてのドメインに対してフォワード
       forward-addr: 129.250.35.250 ←フォワード先DNS(今回はNTT America Technical Operations)
       forward-addr: 8.8.8.8      ←フォワード先DNS(今回はGoogle Public DNS)
------------------------------

3. 設定ファイルのチェック

unboundには設定ファイルをチェックするコマンドが用意されている。これはサービス起動時に自動で実行されるが、手動でも実行可能。

# unbound-checkconf
------------------------------
unbound-checkconf: no errors in /etc/unbound/unbound.conf
------------------------------

4. 設定ファイル再読み込みのため、unboundを再起動

最後に設定繁栄のためunboundを再起動する。

# systemctl restart unbound
# systemctl status unbound
------------------------------
unbound.service - Unbound recursive Domain Name Server
   Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor preset: disabled)
   Active: active (running) since 土 2017-02-25 12:03:22 JST; 2s ago
  Process: 28392 ExecStartPre=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS)
  Process: 28391 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited, status=0/SUCCESS)
 Main PID: 28395 (unbound)
   CGroup: /system.slice/unbound.service
           mq28395 /usr/sbin/unbound -d

~(以下略)~
------------------------------

5. DNS名前解決先を自分自身にする

必須ではないが、最後にOS自身の名前解決も自分自身に変えておく。

# vi /etc/resolv.conf
------------------------------
nameserver 127.0.0.1
------------------------------

以上でインストール作業は終了。私の環境ではインストールから半月ほど経過しているが、特に問題なく動作している。

2017年2月25日土曜日

Windows Server 2008 R2 Server CoreでActive Directoryのドメインコントローラーを作った話② (ドメインコントローラー昇格)

前回、Server Coreでドメイン参加するところまで実施したので、今回はドメインコントローラーに昇格させる。なお、今回は新規ドメインではなく、既存ドメインにドメインコントローラーを追加する手順となる。

また、参考までにドメインコントローラー降格の手順も記載する。

ドメインコントローラーへ昇格

1. unattendファイルの作成

Server Coreの場合はGUIを使った昇格はできないので、以下のような応答ファイル(unattend)を作成して実施する。今回は「unattend.txt」というファイル名で作成した。

unattend.txt
------------------------------
[DCINSTALL]
UserName=<ドメインユーザー>
UserDomain=<ドメイン名>
Password=* ←「*」にすると実行時にパスワード確認がされる
ReplicaDomainDNSName=<DNSドメイン名(通常はUserDomainと同じ)>
ReplicaOrNewDomain=Replica ←「Replica」で既存ドメインへの追加
;DatabasePath=%systemroot%\ntds ←データベース保存パス。デフォルトでよければコメントアウト
;LogPath=%systemroot%\ntds ←ログ保存パス。デフォルトでよければコメントアウト
;SYSVOLPath=%systemroot%\SYSVOL ←SYSVOL保存パス。デフォルトでよければコメントアウト
InstallDNS=Yes ←同時にDNSをインストールするか
ConfirmGC=Yes ←同時にグローバルカタログにするか
SafeModeAdminPassword=<オフライン管理者アカウントのパスワード>
RebootOnCompletion=Yes ←完了時に再起動を自動で行うか
------------------------------

私の環境で作ると以下のようになる。

unattend.txt
------------------------------
[DCINSTALL]
UserName=tadmin
UserDomain=intrat.local
Password=*
ReplicaDomainDNSName=intrat.local
ReplicaOrNewDomain=Replica
;DatabasePath=%systemroot%\ntds
;LogPath=%systemroot%\ntds
;SYSVOLPath=%systemroot%\SYSVOL
InstallDNS=Yes
ConfirmGC=Yes
SafeModeAdminPassword=<オフライン管理者アカウントのパスワード>
RebootOnCompletion=Yes
------------------------------

2. ドメインコントローラーに昇格

作成したunattendファイルを適当な場所に配置し、以下のコマンドで昇格を実行する。

dcpromo /unattend:c:\work\unattend.txt

unattendファイルで指定したドメインユーザーのパスワード入力を促されるので、入力する。


各種警告が表示されたりするが、再起動まで実施されれば成功。


3. 他サーバーから確認

Server Coreは、自分自身ではGUIの管理ツールを持てないので、他のコンピューターのMMC(Microsoft Managemet Console)を利用して管理する。

管理する側のコンピューターには、MMCのActive Directory管理用のスナップインを予めインストールする必要があるが、既に存在するドメインコントローラーには必ず入っているので、そこから操作すると簡単。

「ファイル名を指定して実行」で「mmc」を入力しMMCを起動したのち、「ファイル」→「スナップインの追加と削除」を起動し、以下を選択する。

・Acitve Directory ユーザーとコンピューター

ドメインの中の「Domain Controllers」の中に、今回追加したドメインコントローラーが存在すればドメインコントローラーとしてきちんと昇格されていることが確認できる。


ドメインコントローラーからの降格

参考までに、Server Coreのドメインコントローラーを降格する手順を記載する。

1. unattendファイルの作成

昇格と同様にunattendファイルを作成する。今回はunattend_remove.txtという名前で作成した。

unattend_remove.txt
------------------------------
[DCINSTALL]
UserName=<ドメインユーザー>
UserDomain=<ドメイン名>
Password=<ドメインユーザーのパスワード>
administratorpassword=<ローカルのAdministratorパスワード>
removeapplicationpartitions=yes
RebootOnCompletion=Yes
------------------------------

2. ドメインコントローラーからの昇格

作成したunattendファイルを適当な場所に配置し、以下のコマンドで降格を実行する。

dcpromo /unattend:c:\work\unattend_remove.txt


参考

・無人モードを使用して Windows Server 2008 ベースのドメイン コントローラで Active Directory ドメイン サービスのインストールおよび削除を行う方法
https://support.microsoft.com/ja-jp/help/947034/how-to-use-unattended-mode-to-install-and-remove-active-directory-domain-services-on-windows-server-2008-based-domain-controllers

・Create an Answer File for Unattended Domain Controller Installation
https://technet.microsoft.com/ja-jp/library/cc816873(v=ws.10).aspx

2017年2月19日日曜日

Windows Server 2008 R2 Server CoreでActive Directoryのドメインコントローラーを作った話① (Server Core OS初期設定)

自宅にドメインコントローラーを1台立てているのだが、バックアップとActive Directoryの構築検証も兼ねて、もう1台ドメインコントローラーを作ることにした。

ただ、自宅の検証環境ではESXi1台の中に、すでに10台以上の仮想マシンがひしめき合っている状況であり、特にメモリが不足している状況となっている。そのため、より消費リソースの少ないWindows Server 2008 R2のServer Coreで構築する方針とした。

Server CoreはWindowsのGUI環境が使えないこともあり、今までのWindowsと異なるコマンドベースでの独特な手順が多くなることから、ドメインコントローラーとして利用できるようにするまでの手順を備忘を兼ねて記載する。

今回は、OS初期設定まで記載し、次回にドメインコントローラーへ昇格させる手順を記載する。

インストール

インストール時は通常のインストールと大きな違いはない。OS選択画面で「Server Core」を選べばよい。


Windows Server 2008 R2はデフォルトではGUIを持つ「フルインストール」が選択されているが、Windows Server 2012以降はデフォルトは「Server Core」となっている(Windows Server 2016では、GUI付き環境に対して「デスクトップエクスペリエンス」としており、いわゆるServer Coreは、もはや名前がなく標準のものとしている)。

従って、今後はServer Core環境を主流にしたいという思いがMicrosoftにはあると考えられるのだが、少なくとも私の周りでは商用環境でServer Coreを使っているところは見たことがない。

初期設定

インストールが終わった後のOSの初期設定の手順を記載する。ログインするとコマンドプロンプトだけが表示されたシンプルな画面となっている。Server Coreではこのコマンドプロンプトを駆使して設定していくことになる。万が一コマンドプロンプトを消してしまった場合は、「Ctrl+Shift+ESC」でタスクマネージャーが起動できるので、そこから「ファイル」→「新しいタスクの実行」を選択し「cmd」を入力する。


なお、インストール直後のディスク使用量は、4.75GBとなっていた(19.90GBのうち15.15GBが空き容量)。


1. VMware Toolsのインストール

vSphere Clientから「VMware Toolsのインストール/アップグレード」を選択し、VMware Toolsをマウントする。

その後、コマンドプロンプトでsetup64.exeを実行すればよい。あとはいつものGUIにてインストールが可能となる。

cd d:\
setup64.exe


2. ネットワーク設定(IPアドレス設定)

ネットワーク設定は、コマンドで設定する。

まずは、インターフェースのIdx番号を確認する。今回は「ローカルエリア接続」となっているNICにIPを付与するため、Idx番号は「3」となる。

netsh interface ipv4 show interfaces
------------------------------
Idx     Met         MTU          状態                 名前
---  ----------  ----------  ------------  ---------------------------
  3          10        1500  connected     ローカル エリア接続
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
------------------------------

以下コマンドでIPを付与する。「name=<Idx番号>」としてインターフェースを指定する。

netsh interface ipv4 set address name=3 source=static address=192.168.11.62 mask=255.255.255.0 gateway=192.168.11.31

3. ネットワーク設定(DNS設定)

DNSは以下のコマンドで設定する。DNSサーバーは既設のドメインコントローラーを指定した。

netsh interface ipv4 add dnsserver name=3 address=192.168.11.61 index=1

4. ネットワーク設定(IPv6無効化)

IPv6を使用しない場合は無効化しておく。反映するために一度サーバーを再起動すること(再起動もコマンドで実施する(shutdown /r /t 0))。

------------------------------
キー :  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
名前 : DisabledComponents
種類:  DWORD
データ: 0xff (16進数でff)
------------------------------

最後に設定を確認する。IPv6アドレスが表示されていなければOK。

ipconfig /all
------------------------------
イーサネット アダプター ローカル エリア接続:

   接続固有の DNS サフィックス . . . :
   説明. . . . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
   物理アドレス. . . . . . . . . . . : 00-0C-29-D7-A5-3F
   DHCP 有効 . . . . . . . . . . . . : いいえ
   自動構成有効. . . . . . . . . . . : はい
   IPv4 アドレス . . . . . . . . . . : 192.168.11.62(優先)
   サブネット マスク . . . . . . . . : 255.255.255.0
   デフォルト ゲートウェイ . . . . . : 192.168.11.31
   DNS サーバー. . . . . . . . . . . :  192.168.11.61
   NetBIOS over TCP/IP . . . . . . . : 有効
------------------------------

5. リモート管理設定

Server Coreの場合、他のコンピューターから、サーバーマネージャーやMMC(Microsoft Management Console)で管理することが前提となっているが、その割にデフォルトでは外部から管理できないようになっている。

外部から管理できるようにするため、Firewallを開放する。

netsh advfirewall firewall set rule group="リモート管理" new enable=yes
------------------------------
3規則を更新しました。
OK
------------------------------

netsh advfirewall firewall set rule group="リモート ボリューム管理" new enable=yes
------------------------------
3規則を更新しました。
OK
------------------------------

これで別のWindows OSから「ファイル名を指定して実行」→「mmc」を選択し、MMCを起動する。MMCでは「ファイル」→「スナップインの追加と削除」を選択し、「コンピューターの管理」を選ぶ。この際に管理するコンピューターを選択する画面が出るので、今回の対象サーバーを指定してあげればOK。

6. ドメイン参加

ドメイン参加の前に、コンピューター名を先に変えておく。そうしないと、「ネットワークパスが見つかりません。コマンドを完了できませんでした。」というエラーが表示されドメイン参加に失敗する。以下ではホスト名をt1062w28rに変更する例となる。コマンド実行後再起動を忘れないこと。

netdom renamecomputer %computername% /newname:t1062w28r

次にドメイン参加を行う。こちらもコマンドで実施する。userdはドメインのアカウント、passworddはドメインのアカウントのパスワードとなるが、*を指定するとコマンド実行後にパスワード入力が促されるので、正しいパスワードを入力しOKを押すこと。こちらも実行後は再起動が必要。

netdom join t1062w28r /domain:intrat.local /userd:tadmin /passwordd:*


7. ライセンス認証

ライセンス認証をインターネット経由で実施する場合、以下コマンドで実施可能。ただし、途中にプロキシがある環境の場合は、エラーで失敗することがある。この場合は、コマンドでプロキシを設定してやることで成功する。

------------------------------
netsh winhttp show proxy   ←プロキシ確認
netsh winhttp set proxy 192.168.33.23:8080   ←プロキシ設定

slmgr.vbs -ipk *****-*****-*****-*****-*****   ←プロダクトキー入力
slmgr.vbs -ato   ←ライセンス認証
netsh winhttp reset proxy   ←プロキシ解除
------------------------------

これでドメインのメンバーサーバーとして利用可能なServer Coreが完成する。次回はこのサーバーをドメインコントローラーに昇格させる方法(と降格させる方法)について記載する。

(参考) Server Core設定ツール「sconfig」を使う場合

Server Coreの場合は、sconfigという設定ツールが用意されており、初期設定で説明したいくつかの項目は、対話式に設定ができる。

sconfigで設定できる項目は以下の通り。「5) Windows Updateの設定」と「7) リモートデスクトップ」は設定をしておいた方がよい。

------------------------------
1) ドメイン/ワークグループ
2) コンピューター名
3) ローカル管理者の追加
4) リモート管理の構成
5) Windows Updateの設定
6) 更新プログラムのダウンロードとインストール
7) リモートデスクトップ
8) ネットワーク設定
9) 日付と時刻
10) ユーザーのログオフ
11) サーバーの再起動
12) サーバーのシャットダウン
------------------------------

また、「4) リモート管理の構成」の中には以下項目がある。「2) Windows PowerShell  を有効にする」は有効にしておくと便利なことがあるかもしれない(Windows Server 2008 R2はPowerShellがそんなに充実していないので使わないかもしれないが)。

------------------------------
1) MMC リモート管理を許可する
2) Windows PowerShell  を有効にする
3) サーバー マネージャーのリモート管理を有効にする
4) Windows ファイアウォール設定を表示する
------------------------------

2017年2月11日土曜日

Cisco Catalystスイッチのインターフェースのリンクダウンを検知するまでの遅延時間の設定

スイッチのインターフェースがリンクダウンしてから、実際にリンクダウンを検知する(ログに表示される・SNMP Trapが飛ぶ)まで、少し時間に差異があることがわかった、というお話。

リンクダウンの検知を遅延させる理由は、リンクダウン・アップが短時間に何度も繰り返されるような場合に、大量検知することによる処理の増加を抑えるためのようだ。というわけでCisco Catalystスイッチで該当する設定を調べてみた。

link debounceとcarrier-delay

遅延設定はlink debounceとcarrier-delayの2つのパラメータで設定される。どちらも似たような設定となっているが、違いはおそらく以下のようである。

------------------------------
リンクダウン
 ↓ ←link debounceの遅延時間(Firmwareで動作)
 ↓ ←carrier-delayの遅延時間(Softwareで動作)
リンクダウンを検知
------------------------------

それぞれの設定項目を以下に記載する。

【link debounce】

インターフェース毎に設定される。インターフェースのリンクダウン(リンクアップを除く)の通知の遅延時間。この遅延時間以内にリンクアップを検知した場合は、リンクダウンの通知を行わない。短時間のリンクダウンの検知による不要なスイッチ動作を抑止することを目的とする。

デフォルトはdisableのようだが、disableでも遅延はかかるようで、以下の表の通りとなる(Ciscoのページから抜粋)。

Port Type
Debounce Timer Disabled
Debounce Timer Enabled
10BASE-FL ports
300 milliseconds
3100 milliseconds
10/100BASE-TX ports
300 milliseconds
3100 milliseconds
100BASE-FX ports
300 milliseconds
3100 milliseconds
10/100/1000BASE-TX ports
300 milliseconds
3100 milliseconds
1000BASE-TX ports
300 milliseconds
3100 milliseconds
Fiber Gigabit ports
10 milliseconds
100 milliseconds
10-Gigabit ports except WS-X6501-10GEX4 and WS-X6502-10GE
10 milliseconds
100 milliseconds
WS-X6501-10GEX4 and WS-X6502-10GE 10-Gigabit ports
1000 milliseconds
3100 milliseconds


・Cisco IOS Interface and Hardware Component Command Reference - link debounce
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/command/ir-cr-book/ir-l1.html#wp1766490589

【carrier-delay】

インターフェース毎に設定される。リンク状態の変化(リンクダウン・アップ)を検知するまでの遅延時間。フラッピング(短時間でのリンクダウン・アップの繰り返し)発生時のスイッチ負荷軽減を目的とした設定。

例えば2秒と設定している場合は、1秒以内のリンクダウン、アップであればリンク状態に変化がないものとする。

デフォルトで2秒で設定されている。

・Cisco IOS Interface and Hardware Component Command Reference - carrier-delay
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/command/ir-cr-book/ir-c1.html#wp2997457714

参考

・Daniels Networking Blog - Detecting Network Failure
http://lostintransit.se/2013/09/26/detecting-network-failure/