VCSA5.5に任意のパッケージを導入する方法

VCSA5.5に任意のパッケージをインストールするための方法

 

VCSA5.5のBaseとなっているOSを確認してみると

#cat /etc/SuSE-rekease
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
#

SuZEの11.2らしい

ただ、SNMP Trapコマンドが標準では言っていないので
YASTを使ってインストールする必要がありますが、
OSに対応したレポジトリを登録する必要があります。

http://download.opensuse.org/distribution/11.2/repo/oss/

http://ftp.twaren.net/Linux/OpenSuSE/repositories/net-snmp:/factory/SLE_11_SP2/

あとはyastコマンドでSNMPコマンドをインストールすればよいのですが、
SNMPで検索しても、net-snmp-utilパッケージが一覧でないのでちょっと戸惑いましたが、net-snmpパッケージにsnmptrapコマンドが含まれているそうです。

 

また、SNMP ManagerがUTF-8を受け付けない場合があるので
その場合は、そのSNMP Managerが受け付けてくれる文字コードに変換する必要があります。

文字コードの変換にはiconvコマンドが標準に入っていたのでコレが使えます。

# echo aaaあああ | iconv -f UTF-8 -t SHIFT-JIS
aaaあああ
# str=`echo aaaあああ | iconv -f UTF-8 -t SHIFT-JIS`
# echo $str
aaaあああ
# snmptrap -v 2c -c public 192.168.50.99 '' .1.3.6.1.4.1.8072.100 .1.3.6.1.4.1.8072.100.1 s $str
#

WS000003

あとはコレを組み合わせれば.....

 

 

 

参考

https://community.spiceworks.com/how_to/101544-how-to-enable-snmp-on-vmware-vcenter-server-appliance

http://xysoft.rsucopy.com/yast-install-snmp.html

http://note.kurodigi.com/linux-charconv/

 

本当に参考レベルのスクリプト

#!/bin/sh
# Alarmには、以下のように登録します。
# /root/vcscript/VCTrap.sh "{eventDescription}" "{triggeringSummary}" "{newStatus}"


#送信設定
nnmIP = "10.51.100.60"
specificType = "201"


#コマンドラインパラメータ取得
eventDescription = $1
triggeringSummary = $2
newStatus = $3
#メッセージ編集
str=`echo $eventDescription ($triggeringSummary) [$newStatus]" | iconv -f UTF-8 -t SHIFT-JIS`

#SNMPTrapメッセージ送信

snmptrap -v 2c -c public $nnmIP '' .1.3.6.1.4.1.6876.4.3.6.$specificType 1.3.6.1.4.1.6876.4.3.306 s $str


#プログラム終了
exit 0

Views: 28

カテゴリー: 未分類 | コメントする

LinuxでDisk不足となったときの対策メモ

LinuxでDisk不足となったときの対策メモ

Zabbixで確認したら、いつのまにか / が結構いっぱいに

chart

実機で使用率を確認したら、

[root@QS003 ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vg_qs003-lv_root
 14225776 12603072 893412 94% /
tmpfs 4031236 0 4031236 0% /dev/shm
/dev/sda1 487652 81813 380239 18% /boot
[root@QS003 ~]#

/ が 94%使用中でのこり900MB前後になってました。

この時点では、どのファイルが容量を専有しているのかわからなかったので
フォルダごとのファイルサイズを確認してみると

[root@QS003 ~]# du / | sort -n -r | more
12647184 /
8440184 /var
8179000 /var/crash
3471768 /usr
2054784 /var/crash/127.0.0.1-2016-01-09-12:41:04
2049724 /var/crash/127.0.0.1-2016-01-09-13:03:28
2037424 /var/crash/127.0.0.1-2016-01-09-13:11:25
2037064 /var/crash/127.0.0.1-2016-01-09-13:24:44
1422904 /usr/share
1201232 /usr/lib64
535508 /usr/lib
412468 /usr/share/locale
368092 /usr/lib64/libreoffice
288380 /lib
233216 /usr/lib64/libreoffice/program
224476 /lib/modules
203308 /usr/lib/vmware-tools
196672 /usr/lib/jvm
175280 /usr/lib64/valgrind
174292 /usr/bin
157352 /quadstor
151240 /usr/share/doc
143980 /usr/share/gnome

/var/crashがいっぱい使っているようだ
中身を確認してみる

[root@QS003 ~]# cd /var/crash/
[root@QS003 crash]# ls
127.0.0.1-2016-01-09-12:41:04 127.0.0.1-2016-01-09-13:11:25
127.0.0.1-2016-01-09-13:03:28 127.0.0.1-2016-01-09-13:24:44
[root@QS003 crash]# ls -al
合計 24
drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 .
drwxr-xr-x. 22 root root 4096 12月 30 22:38 2015 ..
drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 127.0.0.1-2016-01-09-12:41:04
drwxr-xr-x 2 root root 4096 1月 9 13:05 2016 127.0.0.1-2016-01-09-13:03:28
drwxr-xr-x 2 root root 4096 1月 9 13:12 2016 127.0.0.1-2016-01-09-13:11:25
drwxr-xr-x 2 root root 4096 1月 9 13:26 2016 127.0.0.1-2016-01-09-13:24:44

このフォルダは、OSがクラッシュしたときにその履歴を保存する場所なので、
一応原因調査して削除して対応

そういえば、この時期にCentOS6.7でQuadStorを試していて、
ある特定条件でOSがPanicを起こして再起動してしまっていたので、
いろいろ調査のため何度も再現性テストをしていたのを思い出した。

そのせいでPanicのたびにダンプファイルを生成していたため
/ を圧迫してしまったようだ。

とりあえず、直近のデータ以外を残して、削除して対応。

[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls -al
合計 2054788
drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 .
drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 ..
-rw------- 1 root root 2103911343 1月 9 12:42 2016 vmcore
-rw-r--r-- 1 root root 174202 1月 9 12:41 2016 vmcore-dmesg.txt
[root@QS003 127.0.0.1-2016-01-09-12:41:04]# cd ..
[root@QS003 crash]# ls
127.0.0.1-2016-01-09-12:41:04 127.0.0.1-2016-01-09-13:11:25
127.0.0.1-2016-01-09-13:03:28 127.0.0.1-2016-01-09-13:24:44
[root@QS003 crash]#
[root@QS003 crash]#
[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-12\:41\:04/
[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-13\:11\:25/
[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-13\:03\:28/
[root@QS003 crash]#
[root@QS003 crash]#
[root@QS003 crash]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vg_qs003-lv_root
 14225776 6461148 7035336 48% /
tmpfs 4031236 0 4031236 0% /dev/shm
/dev/sda1 487652 81813 380239 18% /boot

結果、94% -> 48% まで使用率を減らせることができました。

chart

 

 

ちなみにPanic理由の一番単純な調査方法は以下のとおり

/var/crashフォルダに移動して、

[root@QS003 crash]# cd 127.0.0.1-2016-01-09-12\:41\:04/
[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls
vmcore vmcore-dmesg.txt
[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls -al
合計 2054788
drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 .
drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 ..
-rw------- 1 root root 2103911343 1月 9 12:42 2016 vmcore
-rw-r--r-- 1 root root 174202 1月 9 12:41 2016 vmcore-dmesg.txt
[root@QS003 127.0.0.1-2016-01-09-12:41:04]#

原因の概要をしらべるために、vmcore-dmesg.txtをviewで開いて、
/call Trace
で検索してみると・・・・

<6>[ 3040] 89 3040 20237 1 1 0 0 pickup
<3>Out of memory: Kill process 1850 (rsyslogd) score 1 or sacrifice child
<3>Killed process 1850, UID 0, (rsyslogd) total-vm:249092kB, anon-rss:0kB, file-rss:4kB
<4>postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
<6>postgres cpuset=/ mems_allowed=0
<4>Pid: 29033, comm: postgres Not tainted 2.6.32-573.12.1.el6.x86_64 #1
<4>Call Trace:
<4> [<ffffffff810d6d71>] ? cpuset_print_task_mems_allowed+0x91/0xb0
<4> [<ffffffff8112a570>] ? dump_header+0x90/0x1b0
<4> [<ffffffff81232ffc>] ? security_real_capable_noaudit+0x3c/0x70
<4> [<ffffffff8112a9f2>] ? oom_kill_process+0x82/0x2a0
<4> [<ffffffff8112a931>] ? select_bad_process+0xe1/0x120
<4> [<ffffffff8112ae30>] ? out_of_memory+0x220/0x3c0
<4> [<ffffffff8113780c>] ? __alloc_pages_nodemask+0x93c/0x950
<4> [<ffffffff81166b38>] ? swap_entry_free+0x128/0x1c0
<4> [<ffffffff8117035a>] ? alloc_pages_current+0xaa/0x110
<4> [<ffffffff81127967>] ? __page_cache_alloc+0x87/0x90
<4> [<ffffffff8112734e>] ? find_get_page+0x1e/0xa0
<4> [<ffffffff81128907>] ? filemap_fault+0x1a7/0x500
<4> [<ffffffff8105a4b7>] ? wakeup_preempt_entity+0x47/0x50
<4> [<ffffffff81151ee4>] ? __do_fault+0x54/0x530
<4> [<ffffffff81153179>] ? handle_mm_fault+0x299/0x3d0
<4> [<ffffffff811524b7>] ? handle_pte_fault+0xf7/0xb20
<4> [<ffffffff8108ec0d>] ? __sigqueue_free+0x3d/0x50
<4> [<ffffffff81092332>] ? __dequeue_signal+0x102/0x200
<4> [<ffffffff81153179>] ? handle_mm_fault+0x299/0x3d0
<4> [<ffffffff8104f156>] ? __do_page_fault+0x146/0x500
<4> [<ffffffff8129c5f6>] ? copy_user_generic_unrolled+0x86/0xb0
<4> [<ffffffff811a94b8>] ? poll_select_copy_remaining+0xf8/0x150
<4> [<ffffffff810e884e>] ? __audit_syscall_exit+0x25e/0x290
<4> [<ffffffff8153ef3e>] ? do_page_fault+0x3e/0xa0
<4> [<ffffffff8153c2e5>] ? page_fault+0x25/0x30
<6>Mem-Info:

 

原因はメモリ不足だったので、メモリを増やして解決したです。

Views: 11

カテゴリー: 未分類 | コメントする

ESXi 5.5 ホストを Update 3b 以降にアップグレードすると、ホストを vCenter Server で管理できなくなる にはまったのでメモ書き

ESXi 5.5 ホストを Update 3b 以降にアップグレードすると、ホストを vCenter Server で管理できなくなる にはまったので、メモ書き

 

調べたら、こんなのを見つけた。
ESXi 5.5 ホストを Update 3b 以降にアップグレードすると、ホストを vCenter Server で管理できなくなる (2141185)

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2141185

vSphere 5.5 における SSLv3 プロトコルの有効化 (2141182)
http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2141182

 

Hostd – ポート 443 の有効化

上記に従い、設定ファイルを更新
次に示すように、構成ファイルの < vmacore> の < ssl> タグにある < sslOptions> 16924672</sslOptions> などの sslOptions エントリを追加または削除して、SSLv3 を有効に、または無効にします。
vi /etc/vmware/rhttpproxy/config.xml

<vmacore>
<pluginBaseDir>/lib/</pluginBaseDir>
<!– default thread pool configuration for Posix impl –>
<threadPool>
<IoMin>2</IoMin>
<IoMax>44</IoMax>
<TaskMin>2</TaskMin>
<TaskMax>18</TaskMax>
<!– Do not set MaxFdsPerThread if hostdMinFds is set above –>
<!– MaxFdsPerThread> 2048 </MaxFdsPerThread –>
<NumKeepAlive>8</NumKeepAlive>
<ThreadCheckTimeSecs>600</ThreadCheckTimeSecs>
<ThreadStackSizeKb>256</ThreadStackSizeKb>
<threadNamePrefix>rhttpproxy</threadNamePrefix>
</threadPool>

<rootPasswdExpiration>false</rootPasswdExpiration>

<ssl>
<doVersionCheck> false </doVersionCheck>
<useCompression>true</useCompression>
<libraryPath>/lib/</libraryPath>
<sslOptions>16924672</sslOptions>
</ssl>

 
Authd – ポート 902 の有効化

変更前の設定の確認
/etc/vmware # esxcli system settings advanced list -o /UserVars/VMAuthdDisabledProtocols
Path: /UserVars/VMAuthdDisabledProtocols
Type: string
Int Value: 0
Default Int Value: 0
Min Value: 0
Max Value: 0
String Value: sslv3
Default String Value: sslv3
Valid Characters: *
Description: VMAuthd disabled protocols. By default sslv3 is disabled. If you want to enable sslv3, set the setting to empty.
デフォルトでは SSLv3 が無効になっているため、次のコマンドを実行して有効にします。
/etc/vmware # esxcli system settings advanced set -o /UserVars/VMAuthdDisabledProtocols -s “”
変更後の設定の確認
/etc/vmware # esxcli system settings advanced list -o /UserVars/VMAuthdDisabledProtocols
Path: /UserVars/VMAuthdDisabledProtocols
Type: string
Int Value: 0
Default Int Value: 0
Min Value: 0
Max Value: 0
String Value:
Default String Value: sslv3
Valid Characters: *
Description: VMAuthd disabled protocols. By default sslv3 is disabled. If you want to enable sslv3, set the setting to empty.

 
SFCBD – ポート 5989 の有効化

vi /etc/sfcb/sfcb.cfg

threadPoolSize: 5
threadStackSize: 524288
useChunking: true
enableSSLv3: true

 

 

ここまで変更したら
ESXサーバを再起動

 

なお、Virtual SAN VP – ポート 8080
は使用していないので、未実施です。

 

ちなみに、ESXとvCenter間のサポートマトリックスは以下のとおり

http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php?type=0&empty=0&solution=2&platform=VMware%20ESX/ESXi&version=0&selectedProducts=181,14,15,16,17,96,243,18,174,193,364,141,251,391,500,253,441,559,796,507,577,620,795,430,694

 

 

Views: 11

カテゴリー: 未分類 | コメントする