vSphere 6.0u1 で仮想マシン作成時のゲストOS選択に Windows Server 2012 R2 が無い

VMware製品で仮想マシンを作成する際に、ゲストOSの種類を選択する項目がある。

vSphere6のドキュメントによると、ここの選択肢は次のような影響を及ぼす。

テンプレートまたはクローンを使用しない仮想マシンの作成
vSphere 6.0 Documentation Center

ゲスト OS の選択
vSphere 6.0 Documentation Center

選択したゲスト OS によって、サポートされるデバイスおよび仮想マシンで使用可能な仮想 CPU の数が変化します。
ウィザードではこの情報を使用して、必要なメモリ サイズなど、適切なデフォルト値を選択します。


この選択肢で、ゲストOSの一覧に「Windows Server 2012 R2」が無い。

VMware vSphere/ESXi 6.0u1 の場合】
f:id:savakan:20160220143650p:plain

VMware vSphere/VCSA 6.0u1 の場合】
f:id:savakan:20160220143655p:plain

VMware WorkStation Player12.1 の場合】
f:id:savakan:20160220143751p:plain


これについては、以下のKBに記載がある。

Microsoft Windows Server 2012 R2 のゲスト OS オプションを使用できない (2093022)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2093022

Microsoft Windows Server 2012 R2 guest operating system option is not available (2069889)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2069889


結論としては、ゲストOSに「Windows Server 2012 R2」を利用する場合でも、仮想マシン作成時のゲストOS選択では、「Windows Server 2012」を選べば良い。

Puttyの設定を別PCに移行する方法

Puttyの設定はファイルではなくレジストリに保存されているので、レジストリの値を出力してデータ移行が必要。

エクスポート/インポートいずれも、Windowsコマンドプロンプトで行う。

エクスポート/インポートのパスは、任意のパス。

設定のエクスポート
reg export HKEY_CURRENT_USER\Software\SimonTatham\PuTTY E:\putty.reg
設定のインポート
reg import E:\putty.reg

リモートデスクトップで Windows10 をシャットダウン/再起動する方法

Windows10に対して、リモートデスクトップでログインしている時に、そのログイン先のWindows10をシャットダウン/再起動する方法。

スタートメニューの電源ボタンを押しても、「切断」しか表示されない。
f:id:savakan:20160130145414p:plain

Alt+F4で、シャットダウン等のメニューを表示できるので、ここからシャットダウン/再起動する。
f:id:savakan:20160130145423p:plain



<2016/9/25 追記>

Windows 10 Anniversary Update」を適用後の場合、以下になります。

リモートデスクトップで Windows10(1607) をシャットダウン/再起動する方法 - しょぼんメモリ (´・ω・`)

PostgreSQLで現在接続中のDBのサイズを取得する方法

他にもっと簡単な方法があるかもしれないけど、必要な度に調べるのが面倒なのでメモ。


接続中のDB名を取得

test_db=> SELECT current_database();
 current_database
------------------
 test_db


接続中のDBサイズの取得

test_db=> SELECT pg_size_pretty(pg_database_size(datname)) FROM pg_database WHERE datname=(SELECT current_database());
 pg_size_pretty
----------------
 46 MB


VIEWの作成

test_db=> CREATE VIEW getDBsize AS SELECT pg_size_pretty(pg_database_size(datname)) FROM pg_database WHERE datname=(SELECT current_database());


VIEWの確認

test_db=> SELECT * FROM getdbsize;
 pg_size_pretty
----------------
 46 MB


接続中のDBだけでなく、全てのDBのサイズを取得する場合

test_db=>SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database;


参考
http://www.postgresql.jp/document/8.4/html/functions-info.html
http://www.postgresql.jp/document/8.4/html/functions-admin.html

rsyslog-pgsql で $template にSQLを定義する時は STDSQL を使う

CentOS 6.7 の rsyslog で他のサーバ等から syslog を TCP/UDP で受け取り、ログを PostgreSQL へ登録しようとした時のこと。

環境は以下の通り。全てのサーバは同一セグメント内にある。

【syslog を受け取るサーバ】
CentOS 6.7
2.6.32-573.8.1.el6.x86_64
rsyslog-5.8.10-10.el6_6.x86_64
rsyslog-pgsql-5.8.10-10.el6_6.x86_64
postgresql-server-8.4.20-4.el6_7.x86_64

【syslog を送るサーバ】
・1台目
CentOS 5.11
2.6.18-407.el5PAE
rsyslog-3.22.1-7.el5

・2台目
CentOS 6.7
2.6.32-573.8.1.el6.x86_64
rsyslog-5.8.10-10.el6_6.x86_64

・3台目
CentOS 7.1
3.10.0-229.el7.x86_64
rsyslog-7.4.7-12.el7.x86_64


syslog を受け取るサーバでは、rsyslog-pgsql モジュールを使い、ログを PostgreSQL のテーブルへ登録する。
PostgreSQL では、予め以下のようなテーブルを用意してある。

syslog_db=> \d log_tbl
                                       テーブル "public.log_tbl"
   カラム    |               型               |                       修飾語
-------------+--------------------------------+-----------------------------------------------------
 id          | integer                        | not null デフォルト nextval('log_id_seq'::regclass)
 generated   | timestamp(0) without time zone |
 facility    | smallint                       |
 priority    | smallint                       |
 hostname    | text                           |
 programname | text                           |
 message     | text                           |

syslog を受け取るサーバの /etc/rsyslog.conf の主な設定は以下の通り。
※後述しますが、下記の設定は$template 行の末尾が誤っています。

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
$AllowedSender UDP, 127.0.0.1, 192.168.1.0/24

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514
$AllowedSender TCP, 127.0.0.1, 192.168.1.0/24

# syslog -> PostgreSQL
$ModLoad ompgsql
$template Mypgsql,"INSERT INTO log_tbl (generated, facility, priority, hostname, programname, message) values ('%timegenerated:::date-rfc3339%', %syslogfacility%, %syslogpriority%, '%hostname%', '%programname%', '%msg%')",sql
*.* :ompgsql:localhost,syslog_db,db_user,db_pass;Mypgsql


rsyslog-pgsql にバンドルされているデフォルトのテーブル定義(/usr/share/doc/rsyslog-pgsql-5.8.10/createDB.sql)を使わず、自分で定義したテーブルへデータを登録するため、Mypgsql というテンプレートにSQLを定義。
これで syslog のデータを受け取ったものをDBへINSERTしていく。


この環境でログの受信をテストしていると、CentOS 5.11 のサーバを再起動した時に、受け取った側のサーバの rsyslog プロセスのCPUが高くなり、暫く待っても収まらない問題に遭遇。

送り側のOSの問題か切り分けるだめ、他のCentOS 6/7のサーバを再起動しても、上記と同じく問題が発生したので、受け側の問題と推測。

CentOSが起動する際に送られる syslog を受け取った側の rsyslog がおかしくなるようだった。

暫く待ってもDBの処理が終わらず、以下のエラーを出してDB処理が終了する。

Dec 13 11:52:59 syslog_srv rsyslogd: db error (1): no connection to the server

3台のサーバから、シェルでfor/loggerを使って10000万回のテストメッセージを出力し、TCP/UDPで転送してみても再現できなかったので、受け側のrsyslog の負荷の問題ではなさそうだった。

また、DBへの登録はせず、TCP/UDPで受け取ったsyslog をテキストへ保存すると問題は発生しない。

/var/log/messages のログを眺めると、CentOS起動時のログにシングルクォートが。

/etc/rsyslog.conf に設定したテンプレート部分のSQL文が、エスケープされていないのではないかと思い、logger コマンドで以下を試した。

$ logger test r\"syslog
 →test r"syslog DBに登録される

$ logger test 'r"syslog'
 →test r"syslog でDBに登録される

$ logger test r\'syslog
 →DBに登録されない

$ logger test "r'syslog"
 →DBに登録されない


犯人は、シングルクォートでした。


公式ドキュメントを見ると、SQL を指定する際は書式が2種類ある。
http://www.rsyslog.com/doc/v5-stable/configuration/templates.html

sql - format the string suitable for a SQL statement in MySQL format. This will replace single quotes (“’”) and the backslash character by their backslash-escaped counterpart (“\’” and “\\”) inside each field. Please note that in MySQL configuration, the NO_BACKSLASH_ESCAPES mode must be turned off for this format to work (this is the default).


stdsql - format the string suitable for a SQL statement that is to be sent to a standards-compliant sql server. This will replace single quotes (“’”) by two single quotes (“’‘”) inside each field. You must use stdsql together with MySQL if in MySQL configuration the NO_BACKSLASH_ESCAPES is turned on.


Either the sql or stdsql option must be specified when a template is used for writing to a database, otherwise injection might occur. Please note that due to the unfortunate fact that several vendors have violated the sql standard and introduced their own escape methods, it is impossible to have a single option doing all the work. So you yourself must make sure you are using the right format. If you choose the wrong one, you are still vulnerable to sql injection.

これらはエスケープ方法が異なる。

sql の場合、 ' は \ でエスケープされる。MySQL で利用。
stdsql の場合、 ' は '' でエスケープされる。

PostgreSQLの場合、stdsql を使わなければならない。


さっそく、/etc/rsyslog.conf の $template 行の末尾を sql → stdsql に修正。

# syslog -> PostgreSQL
$ModLoad ompgsql
$template Mypgsql,"INSERT INTO log_tbl (generated, facility, priority, hostname, programname, message) values ('%timegenerated:::date-rfc3339%', %syslogfacility%, %syslogpriority%, '%hostname%', '%programname%', '%msg%')",stdsql
*.* :ompgsql:localhost,syslog_db,db_user,db_pass;Mypgsql


rsyslog サービスを再起動して、syslog 送信側の各サーバを再起動してみると、受け側の rsyslog はCPUの負荷も上がらず、DBにも正常に登録された。


そもそも何故、設定ファイルに sql と書いたかというと、、、

以前同じように syslog をDBに登録した時はMySQLを使った事があり、今回はその時の構築メモを見ながらPostgreSQLを使ったのでハマった。


なお、rsyslog-pgsql にバンドルされている /usr/share/doc/rsyslog-pgsql-5.8.10/createDB.sql を使うと構文エラーが出る。

$ psql -f /usr/share/doc/rsyslog-pgsql-5.8.10/createDB.sql
psql:/usr/share/doc/rsyslog-pgsql-5.8.10/createDB.sql:1: ERROR:  "'Syslog'"またはその近辺で構文エラー
行 1: CREATE DATABASE 'Syslog' WITH ENCODING 'SQL_ASCII';
                      ^
psql:/usr/share/doc/rsyslog-pgsql-5.8.10/createDB.sql:2: \connect: FATAL:  データベース"Syslog"は存在しません

PostgreSQL では大文字と小文字を区別する場合、文字をダブルクォーテーションで括るので、テンプレートを修正する。
ついでにDBのエンコードも環境に合わせる。

CREATE DATABASE 'Syslog' WITH ENCODING 'SQL_ASCII';
 ↓
CREATE DATABASE "Syslog" WITH ENCODING 'UTF8';

これでrsyslog-pgsql にバンドルされているテーブル定義へログを登録できるようになるが、カラムを自分で定義したい場合には以下を参考にSQLを定義すると良い。
http://www.rsyslog.com/doc/v5-stable/configuration/templates.html
http://www.rsyslog.com/doc/v5-stable/configuration/properties.html
http://www.rsyslog.com/doc/v5-stable/configuration/property_replacer.html

上記は、rsyslog v5.x の場合で、7系や8系は、URLが異なる。

CentOS 6.7 では、rsyslog7 パッケージが利用できるので、7系のリンクもメモ。
http://www.rsyslog.com/doc/v7-stable/configuration/templates.html
http://www.rsyslog.com/doc/v7-stable/configuration/properties.html
http://www.rsyslog.com/doc/v7-stable/configuration/property_replacer.html

Thunderbird が 38.2と38.3 の2つあった件→直った

少し前の話だけど、Windows7/64bit にインストールしているThunerbirdが、自動アップデートした後でコントロールパネルに2つ出てくるようになった。

バージョン 38.2 → 38.3 に更新された時のこと。

f:id:savakan:20151203201744p:plain

古い 38.2 を削除しようと思ったが、メールデータも一緒にどちらも消えてしまうのが怖くて放置していたら、38.3 → 38.4 に更新された時に直った。

f:id:savakan:20151203201755p:plain


【リリース情報】

MozillaZine.jp » Blog Archive » Thunderbird 38.4.0 がリリースされた

Thunderbird — Notes (38.4.0) — Mozilla

Windows UpdateしたらWake On LANが動作しなくなった

【環境】
Windows 7/64bit
Intel 82578DC


11月の定例 Windows Update を適用したところ、Wake On LANでPCを起動できなくなった。

デバイスマネージャからNICのドライバを確認し、今回の Windows Update でバージョンが変わっていない事を確認。

NICのプロパティにて、Wake On LAN関連の設定が有効になっている事も確認。

BIOS の設定も問題ない。


ネットで事例を探しても見つからず、NICのドライバを更新してみる事に。

Intelのサイトからドライバをダウンロードして、更新後にOSを再起動すると・・・

DHCPのアドレス取得にも失敗してネットワークに繋がらない。

デバイスマネージャを確認すると、デバイス(NIC)のロードに失敗して認識せず(デバイスマネージャで変な印が表示される)。


デバイスマネージャで、該当のNICを無効→有効にすると、認識してネットワークに繋がるようになる。

OSを再起動してみると、また同じようにNICを認識しなかった。


仕方がないので、ドライバをロールバックしたところ、Wake On LANも正常に動作するようになり、OS起動時にNICの認識も失敗しないようになった(おかしくなる以前の状態に戻った)。

更新前のドライバ
f:id:savakan:20151201202735j:plain

更新後のドライバ
f:id:savakan:20151201202840j:plain


結局、
 ・NICのドライバを更新してみたらOS起動後に自動認識しなくなった
 ・ドライバを元に戻したら全て直った
となり、何が原因か分からないけど、メモっておく。