OMS Agent関連のパッケージが原因でCent OSのyum updateがうまく行かなかった時の対応

 

Cent OS 7のAzure Virtual Machineで検証を行っていた所、yum updateがエラーになっていました。原因を調べてみると、OMSエージェント関連のパッケージの影響でエラーになっていたようです。
実際に発生した事象と対応した内容を残しておきます。

1.ある日突然、yum updateが失敗するようになる

定期的にyum updateを実施していたのですが、ある日から失敗し続けていました。
実際に手動でアップデートを実施した所、以下のメッセージが表示されました。

[ユーザー名@host名 ]$ yum -y update

Downloading packages:
scx-1.6.4-7.universal.x64.rpm FAILED
https://packages.microsoft.com/rhel/7/prod/scx-1.6.4-7.universal.x64.rpm: [Errno -1] パッケージは予定したダウンロードと一致しません。

提案: 「yum –enablerepo=packages-microsoft-com-prod clean metadata」の実行
他のミラーを試します。

Error downloading packages:
scx-1.6.4-7.x86_64: [Errno 256] No more mirrors to try.

最初にエラーメッセージ内で提案された、yum –enablerepo=packages-microsoft-com-prod clean metadataを実行してみたのですが、事象は改善しませんでした。

パッケージ名がscxであり、かつMSのサイトからのダウンロード失敗なので、OMSエージェント関連のアップデート方法が間違っているかと考えました。

2.手動でOMSエージェントのアップデートをしてみる

次に手動でOMSエージェントのアップデート試してみました。
まず、以下のサイトでOMSエージェントの最新Verを確認します。

https://github.com/Microsoft/OMS-Agent-for-Linux/releases

2020年4月23日現在の最新Verは、omsagent-1.12.15-0.universal.x64.shでしたので、これをWgetでダウンロードし、アップデートを行います。
なお、root権限を持たないユーザーの場合はsudoで実行して下さい。また今回は/tmpで作業を実施しています。

#wgetコマンドでパッケージをダウンロードします。

[ユーザー名@host名 tmp]$ wget https://github.com/microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_v1.12.15-0/omsagent-1.12.15-0.universal.x64.sh

#以下のようにアップグレードコマンドを実行します。

[ユーザー名@host名 tmp]$ sh omsagent-1.12.15-0.universal.x64.sh –upgrade

#成功すると最後に以下のメッセージが表示されます。エラーの場合はCodeが0以外になります。

Shell bundle exiting with code 0

#omsエージェントのサービスを再起動します。

[ユーザー名@host名 tmp]$ /opt/microsoft/omsagent/bin/service_control restart

#omsエージェントのステータスを確認します。

[ユーザー名@host名 tmp]$ /opt/microsoft/omsagent/bin/omsadmin.sh -l

#正常動作している場合は、Status: Onboarded(OMSAgent Running)と表示されます。

Primary Workspace: ワークスペースID Status: Onboarded(OMSAgent Running)

これでOMSエージェントのアップデートが無事終わりました。

しかし、再度yum -y updateを行っても、最初と同じくscxのパッケージでエラーになりました。

3.scxのパッケージをrpmコマンドで個別アップデートをしてみた

やはり個別でアップデートが必要そうという事でエラーとなっている、scxのパッケージを個別でアップデートしてみました。
まず、以下のサイトでscxのパッケージの最新Verを確認します。

https://packages.microsoft.com/rhel/7/prod/

2020年4月23日現在の最新Verは、scx-1.6.4-7.universal.x64.rpmでしたので、これをWgetでダウンロードし、rpmコマンドでアップデートを行います。
yumコマンド実行時のエラーメッセージで表示されているVerと同じだったのですが、yumコマンドでダウウンロードできない理由は不明です。
先ほどと同様で、root権限を持たないユーザーの場合はsudoで実行して下さい。また今回は/tmpで作業を実施しています。

#wgetコマンドでパッケージをダウンロードします。

[ユーザー名@host名 tmp]$ wget https://packages.microsoft.com/rhel/7/prod/scx-1.6.4-7.universal.x64.rpm

#rpmコマンドでscxパッケージをアップグレードします。

[ユーザー名@host名 tmp]$ rpm -Uvh scx-1.6.4-7.universal.x64.rpm

#omsエージェントのステータスを確認します。

[ユーザー名@host名 tmp]$ /opt/microsoft/omsagent/bin/omsadmin.sh -l

#正常動作している場合は、Status: Onboarded(OMSAgent Running)と表示されます。

Primary Workspace: ワークスペースID Status: Onboarded(OMSAgent Running)

これでSCXパッケージのアップデートが無事終わりました。

これで再度yum -y updateを行ったところ、無事出来ました。

4.yum.confの除外設定に入れた方が良いのかも

今回は、パッケージ自体のアップデートをを実施しましたが、yum.confに、exclude=パッケージ名と記載する事で、yum対象外にする事が可能です。
環境の状況次第ですが、場合によっては対象外としておき、個別でアップデートを実施するようにした方が良いのかもしれません。

OMIエージェントが失敗し続けた結果Virtual Machineがハングアップした

 

ある日突絶、Cent OSのVirtual Machineがハングアップして停止する事態が発生しました。

調査した結果、OMIエージェントが連続して失敗し続け、30分置きに30MB~40MBのCoreファイルが大量に出力されてました。その結果DISK領域が圧迫され、最終的にDisk Fullで落ちるという事象でした。 なお、Coreファイルが出力されていますが、Log AnalyticsのHeartbeatは取得し続けてました。

今回は解消するまでの対応内容をメモとして残します。

1 .発生した事象

ある日突然、Cent OSのVirtual Machineがハングアップするという事象に出くわしました。

調べた結果以下の事以下のように、”/”配下がDisk使用率100%になっている事がわかりました。

[ユーザー名@ホスト名 tmp]# df -h

ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 948M 0 948M 0% /dev
tmpfs 958M 0 958M 0% /dev/shm
tmpfs 958M 9.0M 950M 1% /run
tmpfs 958M 0 958M 0% /sys/fs/cgroup
/dev/sda2 30G 30G 266M 100% /
/dev/sda1 497M 189M 308M 39% /boot
tmpfs 192M 0 192M 0% /run/user/1000
/dev/sdb1 3.9G 1.1G 2.7G 28% /mnt/resource

何が容量を消費しているのか?を確認した所、/var/opt/omi/runで大量の容量を食っている事がわかりました。

[ユーザー名@ホスト名 tmp]# du -S / | sort -n

24416376 /var/opt/omi/run

/var/opt/omi/runの配下にCoreファイルが大量に生成されており、これが容量を消費していました。

 [ユーザー名@ホスト名 tmp]# ls -alht /var/opt/omi/run
合計 24G

-rw——- 1 root root 40M 12月 20 21:31 core.60161
-rw——- 1 root root 40M 12月 20 21:01 core.56573
-rw——- 1 root root 40M 12月 20 20:31 core.52922

.Log採取を行う

調べても原因が分かりませんでした。マイクロソフトサポート様に調査依頼しました。

大体の場合、以下の手順でログを採取を求められます。採取してお送りします。

アカウント権限によっては、sudoで行います。

#1.ログ収集ツールをダウウンロードする。 

[ユーザー名@ホスト名 tmp]# wget https://github.com/Microsoft/OMS-Agent-for-Linux/raw/master/tools/LogCollector/download/v4/omslinux_agentlog.tgz

#2.tarコマンドでファイルを解凍します。

[ユーザー名@ホスト名 tmp]# tar -xvf omslinux_agentlog.tgz

#3. 解凍したファイルに以下が含まれることを確認します。

./dscDiagnostics.sh
./omslinux_agentlog.py
./omslinux_agentlog.sh
./update_mgmt_health_check.py

#4. 以下のコマンドを実行し、情報を採取します。

[ユーザー名@ホスト名 tmp]# sh omslinux_agentlog.sh -s 000

#5. 実行後、以下のtgz ファイルができるので、このファイルをマイクロソフトサポート様に送ります。

/tmp/omslinuxagentlog-000-yyyy-mm-ddThh:mm:ss.xxxxxx.tgz

3. 今回対応した内容

調査の事象の結果はDSCのモジュールのバージョンが低いことが原因でした。

アップデート前のバージョンは下記の通りでした。

#アップデート前のDSCのバージョン

[ユーザー名@ホスト名 tmp]# rpm -qa | grep dsc
dsc-1.1.1-294.x86_64

以下のサイトにDSCモジュールの最新版が公開されているのですが、対応の時にはv1.1.1-926でした。

https://github.com/microsoft/PowerShell-DSC-for-Linux/releases/

そこで、DSCモジュールのアップデートは以下の手順で行います。

[ユーザー名@ホスト名 tmp]# wget https://github.com/microsoft/PowerShell-DSC-for-Linnux/releases/download/v1.1.1-926/dsc-1.1.1-926.ssl_110.x64.rpm

[ユーザー名@ホスト名 tmp]# rpm -U dsc-1.1.1-926.ssl_110.x64.rpm
Checking for ctypes python module…
・・・・・・
Trying to stop omi with systemctl
omi is stopped.
Trying to start omi with systemctl
omi is started.
[ユーザー名@ホスト名 tmp]# rpm -qa | grep dsc
dsc-1.1.1-926.x86_64

rpmのアップデートの時点で、OMIのサービスが再起動されている為、個別に再起動の必要はありません。今回の事象の場合、これでCoreファイルの出力が止まりました。

モジュールのバージョンアップがうまく行かないケースでこのような事象が起こることもありそうです。Coreファイルが出力された際には各モジュールのバージョンを確認した方が良さそうです。

※事象解消までには、マイクロソフトサポート様に多大なるご支援をいただいております。本当にありがとうございました。

rsyncをパスワード無しで実施する

 

CentOS 7でサーバ間の同期を実行する必要があったので、rsyncで同期してみました。

事前にサーバ間で鍵交換の設定させ、パスワード認証無しでrsyncを実施させてみました。

サーバBが、サーバAからパスワード認証無しでファイルを受信し同期するようにしてみました。

サーバA:送信側
サーバB:受信側

1 .サーバB(受信側)で、秘密鍵と共通鍵のセットを作成する

rsyncでログインを実行するユーザーで、以下のコマンドを実行する。
-Cオプションで”を設定することでコメントを削除しています。
-Nオプションで”とする事で、パスフレーズ無しとしています。

[ユーザー名@Server-b .ssh]$ ssh-keygen -t rsa -C ” -N ” -f /home/ユーザー名/.ssh/id_rsa

権限系の設定ちゃんと実施しおかないと、後で注意メッセージが表示されので設定します。

[ユーザー名@Server-b .ssh]$ chmod 700 /home/ユーザー名/.ssh
[ユーザー名@Server-b .ssh]$ chmod 600 /home/ユーザー名/.ssh/id_rsa.pub

2.サーバBからサーバAに公開鍵ファイルを転送する

公開鍵を送信側サーバに転送します。ユーザー名はログインするユーザー名を指定します。今回は、SCPでファイル転送実施します。(SSHのポートを変更していない場合は、-pオプションは必要ありません。)

[ユーザー名@Server-b .ssh]$ scp -P SSH時のポート番号 /home/ユーザー名/.ssh/id_rsa.pub ログインユーザー名@接続先サーバのIP:/home/ユーザー名/.ssh/id_rsa.pub

3.サーバAで鍵の設定を行う

送信サーバ側で鍵の設定を行います。ログインするユーザーで実行して下さい。

[ユーザー名@Server-a .ssh]$ cd /home/ユーザー名/.ssh
[ユーザー名@Server-a .ssh]$ cat id_rsa.pub >> authorized_keys

権限系の設定と公開鍵を削除します。

[ユーザー名@Server-a .ssh]$ chmod 700 /home/ユーザー名/.ssh
[ユーザー名@Server-a .ssh]$ chmod 600 /home/ユーザー名/.ssh/authorized_keys
[ユーザー名@Server-a .ssh]$ rm -f id_rsa.pub

4.rsyncコマンドを試してみる

設定が終わったら、rsyncを試してみます。rsyncコマンドのオプションは適時指定してください。

[ユーザー名@Server-b .ssh]$ rsync -avzu “ssh -p SSH時のポート番号 -i /home/ユーザー名/.ssh/id_rsa ” ユーザー名@接続先サーバ名:コピー元ディレクトリコピー先ディレクトリ

エラーになる、パスワードを聞かれる場合は、権限かファイル名を間違っているケースが多いかと思います。その編を再度確認してみましょう。

Cronに設定することで、定期実行も可能です。

※セキュリティ面は充分注意の上、実施可否を判断するようにして下さい。

 

CentOS 7のClam AntiVirus設定をSedコマンドを使って楽に出来るようにしてみた

 

CentOS 7で、Clam AntiVirusをセットアップしてたのですが、設定ファイルの書き換えも毎回同じなので、楽にできるようにしてみようとSedコマンド等により一気に出来るように試してみました。
Clam AntiVirusセットアップ自体は、下記記事を参考にしています。(非常によく記載されています。)

https://centossrv.com/clamav.shtml

1 .コピペでセットアップできるようしてみる

複数台セットアップする際を想定して、vi等でファイルを開くのではなく、Sedコマンドを中心に設定ファイルを書き換えるようにしてみました。
【注意】Proxyサーバを利用しない場合は、3)の項目を削除してください。

# 1)パッケージインストール

yum install -y epel-release
yum -y install clamav clamav-server-systemd clamav-update clamav-scanner-systemd

# 2)設定ファイルの編集

cp -p /etc/freshclam.conf /etc/freshclam.conf.`date “+%Y%m%d”`
sed -i -e “s/^Example/#Example/g” /etc/freshclam.conf
sed -i -e “s/^#NotifyClamd \/path\/to\/clamd.conf/NotifyClamd \/etc\/clamd.d\/scan.conf/g” /etc/freshclam.conf

# 3)Proxy経由でアクセスする場合(Proxyサーバを利用しない場合はこの項目は削除してください。)

sed -i -e “s/^#HTTPProxyServer myproxy.com/HTTPProxyServer ”Proxyサーバ名”/g” /etc/freshclam.conf
sed -i -e “s/^#HTTPProxyPort 1234/HTTPProxyPort ”Proxy Port番号”/g” /etc/freshclam.conf

# 4)ウイルス定義ファイル自動更新設定ファイル編集

cp -p /etc/sysconfig/freshclam /etc/sysconfig/freshclam.`date “+%Y%m%d”`
sed -i -e “s/^FRESHCLAM_DELAY=/#FRESHCLAM_DELAY=/g” /etc/sysconfig/freshclam

# 5)Clam AntiVirus設定ファイル編集

cp -p /etc/clamd.d/scan.conf /etc/clamd.d/scan.conf.`date “+%Y%m%d”`
sed -i -e “s/^Example/#Example/g” /etc/clamd.d/scan.conf
sed -i -e “s/^User clamscan/#User clamscan/g” /etc/clamd.d/scan.conf
sed -i -e “s/^#LocalSocket/LocalSocket/g” /etc/clamd.d/scan.conf

# 6)ウイルス定義ファイル更新
freshclam

#7)Clam AntiVirus起動
cp -p /lib/systemd/system/clamd@.service /lib/systemd/system/clamd@.service.`date “+%Y%m%d”`
echo “TimeoutSec=5min” >> /lib/systemd/system/clamd@.service

#8)サービス自動起動設定とサービス起動
systemctl daemon-reload
systemctl enable clamd@scan
systemctl start clamd@scan

#9)定期実行ファイルを作成(#設定ファイル以下の行がファイルの内容になりますので、すべて削除せずに張り付けます。)

cat << ‘EOF’ > /etc/cron.daily/clamdscan
# 設定ファイル
CONFIG=/etc/clamd.d/scan.conf

# スキャン実行
# ※ウイルス検知時は隔離ディレクトリへ隔離
CLAMSCANLOG=`mktemp`
QUARANTINEDIR=/tmp/clamdscan-quarantinedir-$(date +%Y%m%d)
mkdir -p ${QUARANTINEDIR}
clamdscan -c ${CONFIG} –move=${QUARANTINEDIR} / > ${CLAMSCANLOG} 2>&1

# ウイルス検知時のみroot宛にメール通知
if [ -z “$(grep FOUND$ ${CLAMSCANLOG})” ]; then
rm -rf ${QUARANTINEDIR}
else
grep -A 1 FOUND$ ${CLAMSCANLOG} | mail -s “Virus Found in `hostname` => ${QUARANTINEDIR}” root
fi

# スキャンログをシスログに出力
cat ${CLAMSCANLOG} | logger -t $(basename ${0})
rm -f ${CLAMSCANLOG}
EOF

#10)定期実行ファイルに実行権限を付与する。

chmod +x /etc/cron.daily/clamdscan

#11)検索除外ディレクトリを追加する。必要なもの適時追加してください。
echo ExcludePath ^/tmp/clamdscan-quarantinedir-.*/ >> /etc/clamd.d/scan.conf
echo ExcludePath ^/proc/ >> /etc/clamd.d/scan.conf
echo ExcludePath ^/sys/ >> /etc/clamd.d/scan.conf

2.【注意】お手軽に使うためのものです

複数台セットアップする場合は、事前に準備した設定ファイルを配布したり、最初からセットアップしたイメージ展開の方がよいと思います。実際、そっちの方が格好良いと思います。今回は、お手軽にセットアップする手段として、こういう方法もあるかなぁ・・・と思いやってみました。

※設定内容を確認したい場合は、適時catコマンドでファイル表示してください。

CentOS 7でAzure PowerShell Azモジュールを使えるようにしてみる。

以下の情報を参考にCentOS7上にPowerShellを入れて、Azure PowerShell Az モジュールを使える所までセットアップしてみました。
インストールは、Microsoftサイト記載の通りでできます。

https://docs.microsoft.com/ja-jp/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-6

1 .PowerShellをインストールする

リポジトリを登録して、yumでインストールするだけです。

[root@test-01]# curl https://packages.microsoft.com/config/rhel/7/prod.repo | tee /etc/yum.repos.d/microsoft.repo
[root@test-01]#yum install -y powershell

2.Azモジュールをセットアップする

リポジトリが登録状況を確認し、Azモジュールをインストールします。

#PowerShellを呼び出すには、pwshコマンドになります。

[root@test-01]#pwsh

#リポジトリの登録状況を確認します。

PS /root> Get-PSRepository 

Name InstallationPolicy SourceLocation
—- —————— ————–

PSGallery Untrusted https://www.powershellgallery.c…

#Get-PSRepositoryコマンドがエラーになる場合(何も表示されない場合)は、リポジトリが登録されていない可能性があります。この場合は以下のコマンドで登録します。

PS /root> Register-PSRepository -Default 

#最後にAzモジュールをインストールします。
PS /root> Install-Module -Name Az -AllowClobber -Scope AllUsers 

3 .Proxy経由の場合

PowerShellを利用する場合、80,443PortをInterNet向けに開ける必要があります。環境によっては、Proxy経由でしか抜けられないケースもあると思いますが、Linuxの場合は、/etc/enviromentの値を参照するそうです。

ただ、自分が試したところ、うまく行っているのか微妙だったので、引き続き確認していきたい所です。 

Virtual Machine(CentOS 7)からBlobfuseを利用してBlobストレージをマウントする

 

Azure Virtual Machine (CentOS7) からのBlobストレージマウントを利用検証してみました。

CentOS 7からBlobストレージのマウントにはBlobfuseを利用します。

前回、Azure Virtual Machine (CentOS7) に追加した、SSDディスクをキャッシュディスクとして利用しています。
SSDディスクのマウントは、下記記事を参考にしてください。

http://www.tama-negi.com/2019/10/14/disk/

1 .Blobfuseをインストールする。

以下のサイトを参考にセットアップしました。

https://docs.microsoft.com/ja-jp/azure/storage/blobs/storage-how-to-mount-container-linux

[root@test-01]# rpm -Uvh https://packages.microsoft.com/config/rhel/7/packages-microsoft-prod.rpm
#今回は、CentOS7なので6→7へ変えてます。(6用と7用のパッケージは異なるそうです。)(関連パッケージも一緒に入ります。)
[root@test-01]#yum -y install blobfuse

2.Blobfuseを設定する。

追加したSSDをキャッシュとして利用している為、MSさんのサイトの例とは若干異なります。

#事前にSSDをデータディスクとして追加し、フォーマット等を完了させています。(今回は/mnt/ramdiskにSSDをマウントし、キャッシュとして利用します。)
[root@test-01]#mkdir /mnt/ramdisk #Blobfuseキャッシュ用のディレクトリです。
[root@test-01]#mount /dev/sdc1 /mnt/ramdisk
[root@test-01]#mkdir /mnt/ramdisk/blobfusetmp
[root@test-01]#mkdir /var/blobfuse #Blobストレージマウント用のディレクトリです。

#設定ファイルを作成します。今回は、/etc/の配下に設定ファイルを作成してます。
#アカウントKeyは、ストレージアカウントのアクセスキーメニューを開くと、Key1が表示されていますのでここの値を入れてます。
[root@test-01]#echo “accountName ストレージアカウント名” >> /etc/fuse_connection.cfg
[root@test-01]#echo “accountKey アカウントKey” >> /etc/fuse_connection.cfg
[root@test-01]#echo “containerName コンテナ名” >> /etc/fuse_connection.cfg
[root@test-01]#chmod 600 /etc/fuse_connection.cfg

#今回はblobfuseでマウントポイントを/var/blobfuseとして、Blobストレージをマウントしています。
#-o allow_otherを追加しています。これを追加しないと他のユーザーからアクセスできません。
[root@test-01]#blobfuse /var/blobfuse –tmp-path=/mnt/ramdisk/blobfusetmp –config-file=/etc/fuse_connection.cfg -o attr_timeout=240 -o entry_timeout=240 -o negative_timeout=120 -o allow_other

#マウントされたかどうかを確認します。サイズは、キャッシュのサイズが表示されます。(実際に使用する容量分のキャッシュが必要です。)
[root@test-01]df -h

ファイルシス サイズ 使用 残り 使用% マウント位置
(略)
blobfuse 3.9G 25M 3.7G 1% /var/blobfuse

3 .実際に利用してみての感じ

今のところ非常遅い感じです。またキャッシュが悪さしているのか、共有領域が更新されない等もありました。何かチューニングポイントがありそうな気もするので色々探してみたいと思います。

Power Shellを利用してAzure Virtual Machine(CentOS 7)を作成してみた

 

今回は、マイクロソフト様のサイトに”Power Shellを利用して完全なVirtual Machineを作成する”という記事があったので試してみました。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/scripts/virtual-machines-linux-powershell-sample-create-vm

今回はCentOS 7.5で作成しています。

1 .今回作成した環境の前提条件

今回は自身の環境に合わせて、以下の通りとしてます。

・リソースグループや仮想ネットワーク、Subnetが作成済みである。
・ログインはID、PWDで実施する。
・PublicIPは利用せず、ローカルのIPは固定する。
・NSGの設定は行わない。(Subnet単位でNSGの設定を行っている為)
・可用性セットは作成済みである。

.CentOSのイメージを検索する。

利用するCentOSのイメージを検索します。CentOSのパブリッシャー名は、”OpenLogic”になります。

#仮想マシンを作成するリージョン名
$locName=“japaneast”
$pubName=“OpenLogic”
$offerName=“CentOS”
#パブリッシャー名を検索する場合は下記を利用します。
#Get-AzVMImagePublisher -Location $locName
#offerName確認時は、以下のコマンドを実行します。
#Get-AzVMImageOffer -Location $locName -Publisher $pubName
Get-AzVMImageSku -Location $locName -Publisher $pubName -Offer $offerName
#2019年10月時点では以下の通りの値が得られます
Skus Offer PublisherName Location Id
—- —– ————- ——– —
6.10 CentOS OpenLogic japaneast /Subscriptions/(省略)/japaneast/Publishers/OpenLogic/ArtifactTypes/VMImage/Offers/CentOS/Skus/6.10

~(省略)~

7.5 CentOS OpenLogic japaneast /Subscriptions/(省略)/japaneast/Publishers/OpenLogic/ArtifactTypes/VMImage/Offers/CentOS/Skus/7.5

7.6 CentOS OpenLogic japaneast /Subscriptions/(省略)/japaneast/Publishers/OpenLogic/ArtifactTypes/VMImage/Offers/CentOS/Skus/7.6

7.7 CentOS OpenLogic japaneast /Subscriptions/(省略)/japaneast/Publishers/OpenLogic/ArtifactTypes/VMImage/Offers/CentOS/Skus/7.7

3 .利用するSubnetのIDを調べる

利用するSubnetのIDを検索します。NIC作成時に必要になります。

#仮想マシンを作成するリージョン名
$rgNameVnet =“仮想ネットワークがあるRG名”
$VnetName =“仮想ネットワーク名”
$vnet = Get-AzVirtualNetwork -ResourceGroupName $rgNameVnet -Name $VnetName
$subnet0 = $vnet.Subnets[0].Id
$subnet0
#以下のような値が得られます。0から数字を変えて、自分が利用するSubnet名が該当するのを検索します。
/subscriptions/XXX/resourceGroups/RG名/providers/Microsoft.Network/virtualNetworks/仮想ネットワーク名/subnets/Subnet名

 3.仮想マシンを作成する。

仮想マシンを作成します。

#仮想マシンの変数情報
$rgName =“VMを構築するRG名”
$vmName =“構築するVM名”
$vmSize =“Standard_B1s” 
$location =“japaneast” 
$OSUser = “OSのユーザー名”
$OSPword = “OSのパスワード”

#NICの変数情報
$NicName =“ネットワークカード名”
$rgNameVnet =“仮想ネットワークがあるRG名”
$VnetName =“仮想ネットワーク名”
$PrivateIP = “仮想マシンに付与するローカルのIPアドレス”

#可用性セット名
$AvailabilitySetName =“可用性セット名”

#DISKの変数情報
#$DISKTypeは、利用するOSのディスクタイプを指定します。
$DISKName =“ディスク名”
$DISKType =“Standard_LRS”

#パスワードの作成
$Pword = ConvertTo-SecureString -String $OSPword -AsPlainText -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $OSUser, $Pword

#NICの作成を実施します。
#$vnet.Subnets[X]には、先ほど調べたSubnetIDを設定します。(0-9の半角数字)
$vnet = Get-AzVirtualNetwork -ResourceGroupName $rgNameVnet -Name $VnetName
$subnet = $vnet.Subnets[X].Id
$nic = New-AzNetworkInterface -Name $NicName -ResourceGroupName $rgName `
-Location $location -SubnetId $vnet.Subnets[X].Id `
-PrivateIpAddress $PrivateIP

#仮想マシンの作成のためのConfigを設定します。
#Set-AzVMOperatingSystem 行には、先ほど調べたOSのイメージの値を設定します。今回は7.5を指定しています。
$AvailabilitySet = Get-AzAvailabilitySet -ResourceGroupName $rgName -Name $AvailabilitySetName
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetID $AvailabilitySet[0].Id ` | `
Set-AzVMOperatingSystem -Linux -ComputerName $vmName -Credential $cred | `
Set-AzVMOSDisk -name $DISKName -StorageAccountType $DISKType -CreateOption FromImage| `
Set-AzVMSourceImage -PublisherName OpenLogic -Offer CentOS -Skus 7.5 -Version latest | `
Add-AzVMNetworkInterface -Id $nic.Id

#仮想マシンの作成を実行します。
New-AzVM -ResourceGroupName $rgName -Location $location -VM $vmConfig

4 .PowerShellで作る事の意外なメリット

ディスク名や、ネットワークインタフェース名を自分で命名する事ができるため、運用時に色々と便利というメリットがあります。

 

Azure Virtual Machine(CnetOS 7)にデータディスクを追加する

 

今回はAzure Virtual Machine (CentOS 7) へのデータディスク(Managed Disks(Standard SSD))追加を試してみました。

マイクロソフト様のサイトを参考に検証を進めてみました。

1.Power ShellでデータDISKを追加

以下のサイトを参考に仮想マシンにデータディスクを追加するPower Shellを作ってみました。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/attach-disk-portal

$rgName = ‘RG名’
$vmName = ‘DISK追加するVM名’
$location = ‘japaneast’
#今回は、Standard SSDなので下記を指定。

$storageType = ‘StandardSSD_LRS’
$dataDiskName = ‘VM名_CashDisk_1(追加するDISK名)’
#今回は、最低の4GBを指定。
$diskConfig = New-AzDiskConfig -SkuName $storageType -Location $location -CreateOption Empty -DiskSizeGB 4
$dataDisk1 = New-AzDisk -DiskName $dataDiskName -Disk $diskConfig -ResourceGroupName $rgName$vm = Get-AzVM -Name $vmName -ResourceGroupName $rgName
$vm = Add-AzVMDataDisk -VM $vm -Name $dataDiskName -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 1Update-AzVM -VM $vm -ResourceGroupName $rgName

2.Linux上でマウントする。

以下のマイクロソフト様のサイトに記載の通りの手順になります。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/attach-disk-portal

まず、仮想マシンにディスクが追加された状況をOS上で確認します。

[root@test-01]# dmesg | grep SCSI

[ 0.342149] SCSI subsystem initialized
[ 0.987188] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[ 2.867663] sd 2:0:0:0: [sda] Attached SCSI disk
[ 2.873137] sd 3:0:1:0: [sdb] Attached SCSI disk
[3965178.687477] sd 5:0:0:1: [sdc] Attached SCSI disk

今回の場合、sdcが追加されているので、fdsikでパーティションを作成します。

今回は新しいパーティションを作成するので、コマンドはnで実施します。

[root@akbwg-web-01 httpd]# fdisk /dev/sdc
Welcome to fdisk (util-linux 2.23.2).Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x07ecc989.The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.コマンド (m でヘルプ): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
パーティション番号 (1-4, default 1): 1
最初 sector (2048-8388607, 初期値 2048):
初期値 2048 を使います
Last sector, +sectors or +size{K,M,G} (2048-8388607, 初期値 8388607):
初期値 8388607 を使います
Partition 1 of type Linux and of size 4 GiB is setコマンド (m でヘルプ): w
パーティションテーブルは変更されました!ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。

最後にmkfsコマンドでディスクをフォーマット後、マウントします。
今回はマウントポイントを/mnt/ramdiskとしてます。
UUIDを指定したマウントを行う為、/dev/sdc1のUUIDをコピーしてfstabを作成します。

[root@test-01]# mkfs -t ext4 /dev/sdc1
[root@test-01]# blkid

/dev/sda1: UUID=”fa2f8157-XXXXX-XXXXXX” TYPE=”xfs”
/dev/sda2: UUID=”12907c8a-XXXXX-XXXXXX” TYPE=”xfs”
/dev/sdb1: UUID=”bb32dd89-XXXXX-XXXXXX” TYPE=”ext4″
/dev/sdc1: UUID=”66891613-XXXXX-XXXXXX” TYPE=”ext4″

[root@test-01]# mkdir /mnt/ramdisk
[root@test-01]# vi /etc/fstab

##fstabに以下を追記します。
UID=66891613-XXXXX-XXXXXX /mnt/ramdisk ext4 defaults,nofail 0 0

OS再起動してマウントされていることを確認します。

Azure Application Gateway利用時のApache Access logについて

 

Application Gateway利用時にはバックエンドプール側サーバのログのアクセス元IPが、Application GatewayのローカルIPになります。実IPはX-Forwarded-Forに含まれます。今回はApacheのaccess.logで実IPが表示されるようにしてみました。

1.Application Gateway利用時のログについて

Application Gateway利用時には下記のように、アクセス元IPが、Application GatewayのIPになります。この点は、Azure Load Balancer利用時と挙動が異なります。その為、X-Forwarded-Forの値を使ってアクセス元IPの戻しが必要になります。今回はaccess.logのsyslog化も併せて実施します。

172.21.4.4 – – [16/May/2019:09:54:00 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“
172.21.4.5 – – [16/May/2019:09:54:02 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“
172.21.4.4 – – [16/May/2019:09:54:13 +0900] “GET /favicon.ico HTTP/1.1” 200 – “http://www.tama-negi.com/” “Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36”
172.21.4.4 – – [16/May/2019:09:54:30 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“
172.21.4.5 – – [16/May/2019:09:54:32 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“

2.Apacheの設定変更

Apacheの設定は、httpd.confのLog Formatの変更及び、CustomLog、ErrorLogのsyslog化を行います。Application Gatewayの場合、X-Forwarded-Forにアクセス元のIPが出力されるため、明示的に項目として追加します。

[root@test-vm ~]#cp -p /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.`date “+%Y%m%d”`
[root@test-vm ~]#vi  /etc/httpd/conf/httpd.conf

#変更前

ErrorLog “logs/error_log”
LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined
CustomLog “logs/access_log”

#変更後

  LogFormat “%{X-Forwarded-For}i \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined
CustomLog “|/usr/bin/logger -p local6.info -t httpd_access” combined

ErrorLog “|/usr/bin/logger -p local6.info -t httpd_error”

※access log、error log両方local6に出力する設定です。
※Logに出力される日時は、syslog側で付与するので、LogFormatから削除しています。

3.rsyslogファイル作成

rsyslog側の設定を行います。ApacheのLogをlocal6に出力指定したので、local6のファイル出力先を指定します。併せて、messagesの除外にします。

#新規にファイルを作成し、下記を追加する。

[root@test-vm ~]#vi /etc/rsyslog.d/httpd.conf

local6.* /var/log/httpd/access.log

#このままだと、messagesにも表示されてしまうので、rsyslog.confも編集する。

[root@test-vm ~]#cp -p /etc/rsyslog.conf /etc/rsyslog.conf.`date “+%Y%m%d”`

[root@test-vm ~]#vi /etc/rsyslog.conf

#変更前
*.info;mail.none;authpriv.none;cron.none; /var/log/messages

#変更後
*.info;mail.none;authpriv.none;cron.none;local6.none var/log/messages

 

4.Application Gatewayの正常性プローブアクセスをログから除外する

このままだと、Application Gatewayの正常性プローブのアクセスがApacheのアクセスログに表示されてしまいます。ですので、rsyslogのignoreで除外設定を行います。

#新規にファイルを作成し、下記を追加する。

[root@test-vm ~]#vi /etc/rsyslog.d/httpd-logstop.conf

msg, contains, “GET / HTTP/1.1” stop

#※除外の文字列は今回のLogFormatに合わせてます。

 

5.logrotate.dの設定を行う

rsyslog化の設定とともに、Apacheのaccess.logのログローテの設定を行います。設定後、rsyslogおよびhttpdの再起動を行います。

[root@test-vm ~]#cp -p /etc/logrotate.d/httpd /etc/logrotate.d/httpd.`date”+%Y%m%d”`
[root@test-vm ~]#vi  /etc/httpd/conf/httpd.conf

#設定ファイルの中身を下記記載に置き換えます。

/var/log/httpd/access.log {
 daily
 rotate 32
 nocompress
 ifempty
 missingok
 create
 sharedscripts
 postrotate
  /sbin/service httpd graceful > /dev/null 2>/dev/null || true
 endscript
}

#今回は32日保管で、ローテ後圧縮にしています。

[root@test-vm ~]#systemctl restart httpd

[root@test-vm ~]#systemctl restart rsyslog

 

 

6.出力されるログを確認する

設定が完了すると、/var/log/httpd/access.logに、アクセス元のIPが表示されます。

May 27 15:49:39 akbwg-web-01 httpd_access: XXX.XXX.XXX.XXX:XXX “GET /favicon.ico HTTP/1.1” 200 – “http://www.tama-negi.com/2019/05/27/application-gw-01/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36”

 

Azure Virtual Machineで最初にすること(CentOS 7.5編)

CentOS 7でAzure Virtual Machine を作成した場合に最初に実施する事を整理してみました。

セキュリティ的な観点も考えて、ログインの上限回数制限等を実施しています。

今回は、Network Security Group(NSG)等での制御を想定しているので、firewalld、Selinuxを無効化していますが、環境に合わせて実施可否を判断して下さい。

1.rootのパスワードを設定する

Azureに作成した、CentOSはrootのパスワードが非公開です。その為、一番最初に、rootのパスワード設定を実施します。

[user@test-vm ~]$ sudo su –
Password:  #仮想マシン作成時のユーザーパスワード
[root@test-vm ~]# 
[root@test-vm ~]# passwd
Changing password for user root.

New password: #新規設定するrootのパスワードを入力
Retype new password: #新規設定するrootのパスワードを入力

2.デフォルトユーザーのSUDO権限を剥奪する

Virtual Machine作成時のアカウントには、SUDO権限が付与されているので、削除します。

#必ずrootユーザのパスワードを設定してから実行します。本設定後root権限が必要な設定が一切できなくなります。

[root@test-vm ~]#cp -p /etc/sudoers.d/waagent /etc/sudoers.d/waagent.`date “+%Y%m%d”`
[root@test-vm ~]#sed -i -e “s/user/#user/g” /etc/sudoers.d/waagent

3.OSを日本語化する

OSの日本語化を実施します。

[root@test-vm ~]# localectl  set-keymap –no-convert jp106
[root@test-vm ~]#localectl set-x11-keymap –no-convert jp106
[root@test-vm ~]#localectl set-locale LANG=ja_JP.utf8
[root@test-vm ~]#source /etc/locale.conf
[root@test-vm ~]#timedatectl set-timezone Asia/Tokyo

4.SELinux無効化する

SE Linuxを使わない場合は無効化します。

[root@test-vm ~]#cp -p /etc/selinux/config /etc/selinux/config.`date “+%Y%m%d”`
[root@test-vm ~]#sed -i -e “s/SELINUX=enforcing/SELINUX=disabled/g” /etc/selinux/config

5.firewalld 無効化する

仮想マシンのアクセス制御をネットワークセキュリティグループ側で設定する場合は、OS側での設定は不要なので無効化します。

[root@test-vm ~]# systemctl stop firewalld
[root@test-vm ~]# systemctl disable firewalld

#fail2banやその他、firewalldでアクセス制御する場合は有効化のまま設定しましょう。

6.rootユーザーのSSHログイン拒否やポート番号変更を実施する。

セキュリティ上の観点から、rootユーザーのSSHログインを明示的に拒否します。また可能であれば、ポート番号も変更します。

[root@test-vm ~]#cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.`date “+%Y%m%d”`
[root@test-vm ~]#sed -i -e “s/#PermitRootLogin yes/PermitRootLogin no/g” /etc/ssh/sshd_config

7.ユーザーのログイン失敗上限を設定する

一定回数以上ログイン失敗があった場合は、一定時間ログインできないようにします。

[root@test-vm ~]#sed -i -e “3i auth required pam_tally2.so deny=5 unlock_time=60” /etc/pam.d/system-auth
[root@test-vm ~]#sed -i -e “10i account required pam_tally2.so” /etc/pam.d/system-auth
[root@test-vm ~]#sed -i -e “5i auth required pam_tally2.so deny=5 unlock_time=60” /etc/pam.d/password-auth
[root@test-vm ~]#sed -i -e “12i account required pam_tally2.so” /etc/pam.d/password-auth

#今回の場合は、5回失敗したら、1時間ログインできないように設定しています。

8.SWAP領域を設定する

デフォルトでは、SWAP領域が設定されていないので、設定します。

[root@test-vm ~]#cp -p /etc/waagent.conf /etc/waagent.conf.`date “+%Y%m%d”`

[root@test-vm ~]#sed -i -e “s/ResourceDisk.EnableSwap=n/ResourceDisk.EnableSwap=y/g” /etc/waagent.conf
[root@test-vm ~]#sed -i -e “s/ResourceDisk.SwapSizeMB=0/ResourceDisk.SwapSizeMB=1024/g” /etc/waagent.conf

#今回の場合は、B1S(メモリ1GB)を利用している為、1024MBで設定します。Virtual Machineのメモリ容量に応じて適時変更してください。

9.Proxyを利用する場合の設定

Proxyサーバの指定をホスト名で実施する設定の場合になります。Azure LBを使用してProxyの冗長化した場合は、利用するIPの名前解決できないので、明示的にhostsにアドレスを指定します。

[root@test-vm ~]#cp -p /etc/hosts /etc/hosts.`date “+%Y%m%d”`

[root@test-vm ~]#echo ‘ ‘ >> /etc/hosts
[root@test-vm ~]#echo ‘192.168.1.1 azure-lb-proxy  proxy’ >> /etc/hosts

[root@test-vm ~]#cp -p /etc/wgetrc /etc/wgetrc.`date “+%Y%m%d”`

[root@test-vm ~]#echo ‘proxy=http://azure-lb-proxy:8080’ >> /etc/yum.conf

[root@test-vm ~]#cp -p /etc/wgetrc /etc/wgetrc.`date “+%Y%m%d”`

[root@test-vm ~]#echo ‘http_proxy=http://azure-lb-proxy:8080/’ >> /etc/wgetrc
[root@test-vm ~]#echo ‘https_proxy=http://azure-lb-proxy:8080/’ >> /etc/wgetrc
[root@test-vm ~]#echo ‘ftp_proxy=http://azure-lb-proxy:8080/’ >> /etc/wgetrc

[root@test-vm ~]#sed -i -e “s/#HttpProxy.Host=None/HttpProxy.Host=azure-lb-proxy/g” /etc/waagent.conf
[root@test-vm ~]#sed -i -e “s/#HttpProxy.Port=None/HttpProxy.Port=8080/g” /etc/waagent.conf

#Proxyのアドレスを、192.168.1.1 とし、ホスト名をazure-lb-proxy、ProxyのPortを8080とした場合の例になります。

10.syslogに不必要なログを表示させない

Azure特有のログや、利用する中で不必要なログが、/var/log/messagesに出力される事があります。必要でないログは、ログを見にくくするので出力しないようにします。設定は、ignoreファイルに出力したくない文字列を記載する事で実現します。

[root@test-vm ~]#echo ‘if $programname == “systemd” and ($msg contains “Starting Session” or $msg contains “Started Session” or $msg contains “Created slice” or $msg contains “Starting user-” or $msg contains “Starting User Slice of” or $msg contains “Removed session” or $msg contains “Removed slice User Slice of” or $msg contains “Stopping User Slice of”) then stop’ >> /etc/rsyslog.d/ignore-messages.conf

[root@test-vm ~]#echo ‘if $programname == “systemd” and ($msg contains “Starting OMI CIM Server” or $msg contains “Stopping OMI CIM Server” or $msg contains “Started OMI CIM Server” ) then stop’ >> /etc/rsyslog.d/ignore-messages.conf

#上記の記載は一例です。

#設定後、必要に応じてsystemctl restart rsyslogを実施してください。

11.Cronを設定する

CentOS7からは、anacronが利用されていますが、ログローテのタイミングが固定されず、利用し続けるにあたって非常に面倒なので、noanacronに変更します。

[root@test-vm ~]#yum -y install cronie-noanacron
[root@test-vm ~]#yum -y remove cronie-anacron
[root@test-vm ~]#cp -p /etc/cron.d/dailyjobs /etc/cron.d/dailyjobs.`date “+%Y%m%d”`

[root@test-vm ~]#sed -i -e “s/MAILTO=root/MAILT0=/g” /etc/cron.d/dailyjobs

[root@test-vm ~]#sed -i -e “s/MAILTO=root/MAILT0=/g” /etc/crontab

#Cronのメールも削除してます。

#必要に応じて、/etc/cron.d/dailyjobsを編集し実行時間を変えます。

12.NTPを設定する

NTPにはchronyが利用されていますが、デフォルトでは海外のNTP Serverを検索してしまうので、国内に変更します。

[root@test-vm ~]#cp -p /etc/chrony.conf /etc/chrony.conf.`date “+%Y%m%d”`

[root@test-vm ~]#vi /etc/chrony.conf

#以下の行をコメントアウトする

server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst

#以下の行を追加する。leapsecmode以下の行はうるう秒対策。

server ntp.nict.jp iburst
server 0.jp.pool.ntp.org iburst
server 1.jp.pool.ntp.org iburst

leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001 leaponly

#内部NTPがある場合は、必要に応じてホストの指定先を変更します。

最後に、rebootコマンドで、OSの再起動を実施してください。各サービスの再起動、SWAP領域の有効化を行います。