Windows上でX-Windowアプリを表示するためのXサーバ VcXsrv


Windows上でX-Windowsアプリを表示させるために使うXサーバソフトウェアとして、「Xming」が有名である。

しかし、Xmingの最近のバージョンは寄付者向けリリースのみとなっている。
他にないものか、と探してみると「VcXsrv Windows X Server」というものがあった。

こちらは、Visual Studio 2013 Express Editionでコンパイルされており、64bit版バイナリも提供されている。
また、sourceforgeにて、ソースコードも公開されているので改造することもできる。

とりあえず、インストールしてみて、Xmingと使い比べてみたところ、思いの外、VcXsrvは好成績だった。

比較手法としては、VcXsrvを:0で起動し、Xmingを:1で起動し、他のLinuxサーバ上から、同じアプリをそれぞれ表示させる、というものを取ってみた。

「gnome-terminal」
terminal
左:VcXsrv、右:Xming

Xmingは小さく表示されてしまっている。
また、タスクバーの表示は下記のようになる。
taskbar
左:VcXsrv、右:Xming、(真ん中:コマンドプロンプト)

VcXsrvはアプリのアイコンがきちんと表示されるが、xmingでは「X」のアイコンで代用される。

「firefox」
VcXsrvの場合
vc-firefox

Xmingの場合
xming-firefox

VcXsrvの場合、タイトルバーもきちんと表示されている。
Xmingでは表示できていない。

Windows Serverを複数ユーザで利用時、各ユーザ毎にXmingを起動しTeraTermを使う手法


Windows Serverにリモートデスクトップ(RDP)でログインし、そこからTeraTermを使ってLinuxサーバにログインする、って運用をしてるところは結構あると思います。

で、X-Windowのアプリを表示したい時に、フリー版のXmingを使おうとしたら、思うように使えない、という事態になったりします。

フリー版のXming ver6.9.0.31を普通にインストールすると、そのショートカットは、全ユーザ共通で、Xサーバを「:0」で起動する設定になっています。

このため、Windows Server上で誰かがXmingを起動すると、他の人は番号競合のためXmingを起動できなくなってしまいます。

回避方法は簡単で、番号が被らないようにXmingを起動する、ということです。

Xmingの標準ショートカットは以下のものです。

"C:\Program Files (x86)\Xming\Xming.exe" :0 -clipboard -multiwindow

これを、例えば「:1」で起動する様に変更します。

"C:\Program Files (x86)\Xming\Xming.exe" :1 -clipboard -multiwindow


(ちなみに、「:51000」とかでも起動し動作しました)

また、この設定の場合、SSHを使ったX11 forwardingを使った場合は表示できますが、Linuxサーバ上で「export DISPLAY=WindowsサーバIP:1.0」といったような形で表示させようとした場合、拒否されてしまいます。

そういった場合は下記の様な形で「-ac」オプションをつけます。

"C:\Program Files (x86)\Xming\Xming.exe" :1 -clipboard -multiwindow -ac


(-acは、アクセスコントロールをしない、という設定なので、予期しないホストからXアプリが飛んでくる可能性はありますが、まぁ、気にしない、ということでこの設定にしています。)

なお、最近、一般向けには公開されていないXmingではなく、VcXsrvを使う場合でも、オプションは同様になります。(VcXsrvについては「Windows上でX-Windowアプリを表示するためのXサーバ VcXsrv」を参照のこと)

で・・・これで解決かといえば、そうでもありません。

Tera TermのSSHポート転送の機能に、「Xクライアントアプリケーションの転送」という項目があります。
これは、SSH X11 forwardingとも呼ばれる機能で、Linuxサーバ上ではlocalhost扱いなんだけど、実際には、SSHを使用してWindows上に表示される、というものです。

Tera Termの場合、下記の様にON/OFFのみが選択できます。
teraterm

この場合、Tera Termでは、Windows上のXサーバの「:0」に対して画面を出力しようとします。

このため、せっかくXming側を複数立てても、「:0」を起動させている人のところにXアプリの画面が集まってしまいます。

(以下は、2015/03/02に修正)

回避方法は3つ。

その1:指定できるputtyを使う
出力先をGUIで設定できるputtyを使用する。
設定は下記のX display locationに例えば「:1.0」と入力します。
putty

その2:環境変数でDISPLAYを指定してTeraTermを起動する
version 4.86(2015/02/28リリース)より前のTera Termの場合、TeraTermの起動方法を工夫することで指定ができます。

標準の設定GUIでは設定できませんが、Windowsのコマンドプロンプトで環境変数DISPLAYを設定することによって、出力先を指定することができるようになっています。
(機能追加要望を出したら教えてもらった)

なので、以下のようなバッチファイルを書くと、指定したところにXアプリが出力できるようになります。

@echo off
set DISPLAY=:1.0
"C:\Program Files (x86)\teraterm\ttermpro.exe" Linuxサーバ名 /ssh-X

その3:TeraTermの起動オプションで指定する(ver4.86以降)
TeraTerm ver 4.86から、/ssh-Xオプションが拡張され、DISPLAYを指定できるようになりました。
(TeraTermのマニュアル)

以下の様な形で「/ssh-X」の後にスペースを入れず、連続して出力先を記述します。

"C:\Program Files (x86)\teraterm\ttermpro.exe" Linuxサーバ名 /ssh-Xlocalhost:1.0

VMware toolsの配布場所:Windows&Linux&Solaris


2022/11/15修正

最近のVMware Toolsのサポート状況についてまとめ直した

Windows編

Windows Server 2008R2 SP1~Windows Server 2022 / Windows 7 SP1~Windows 11 12.1.0(随時更新中,最新ESXi同梱版?)
 ReleaseNote:
 https://customerconnect.vmware.com/ja/downloads/details?downloadGroup=VMTOOLS1210&productId=742
 https://packages.vmware.com/tools/releases/12.1.0/windows/

Windows Server 2008 SP2 / Vista SP2用 11.0.6(最終)
 ReleaseNote:
 https://customerconnect.vmware.com/ja/downloads/details?downloadGroup=VMTOOLS1106&productId=742
 https://packages.vmware.com/tools/releases/11.0.6/windows/

Linux編

RHEL7以降はopen-vm-toolsを使う
 VMware support for open-vm-tools (2073803)

RHEL6/CentOS6用 10.3.25(随時更新中,最新ESXi同梱版?)
 ReleaseNote:
 https://customerconnect.vmware.com/ja/downloads/details?downloadGroup=VMTOOLS10325&productId=974
 https://packages.vmware.com/tools/releases/10.3.25/rhel6/

RHEL5/CentOS5用 10.3.22(最終)
 ReleaseNote:
 https://customerconnect.vmware.com/en/downloads/details?downloadGroup=VMTOOLS10322&productId=1072
 https://packages.vmware.com/tools/releases/10.3.22/rhel5/
 なお、RHEL5はSSL1.2に非対応のため、2022年11月現在RHEL5サーバ上からhttpsアクセスがほぼ不可能になっていることに注意

Ubuntu 14.04以降はopen-vm-toolsを使う
 VMware support for open-vm-tools (2073803)

Ubuntu 10.04/11.04/11.10/12.04用 10.3.25(随時更新中)
 ReleaseNote:
 https://customerconnect.vmware.com/ja/downloads/details?downloadGroup=VMTOOLS10325&productId=974
 https://packages.vmware.com/tools/releases/10.3.25/ubuntu/dists/
 なお、SSL1.2に非対応であるなら2022年11月現在サーバ上からhttpsアクセスがほぼ不可能になっていることに注意
 (Ubuntuの対応について調べていない)

Solaris x86編

Solaris 10 x86用 10.3.10(最終)
 ReleaseNote:
 https://customerconnect.vmware.com/ja/downloads/details?downloadGroup=VMTOOLS10310&productId=742


↓は参考用の過去の記録

古いOSだとSSL1.2非対応のため、httpsアクセスができなくなっていることに注意のこと


VMware toolsのダウンロードURLを調べていたら、Linuxディストリビューションの一部では、yumコマンドでダウンロードできるようなレポジトリファイルも配布されているのを発見したのでメモ書き。

バージョンごとの配布場所:
 https://packages.vmware.com/tools/releases

VMwareにあるvmware-tools配布場所:「https://packages.vmware.com/tools/esx/latest/index.html

Linux向けvmware-toolsについて

Linux向けレポジトリのファイル置き場:

vSpehre 6.7向け: https://packages.vmware.com/tools/esx/6.7latest/repos/
vSphere 7.0向け: https://packages.vmware.com/tools/esx/7.0/repos

レポジトリファイルは、上記4つの他に、SLES11.0, SLES11.1, SLES11.2, SLES11.3, Ubuntu10.04, Ubuntu11.10, Ubuntu12.04が公開されている。

RHEL/CentOSのyumコマンドでインストールする場合、
必要なドライバを一通りインストールする「yum install vmware-tools-esx-nox 」でインストールされるパッケージ

vmware-tools-esx-nox         
vmware-tools-core            
vmware-tools-foundation      
vmware-tools-guestlib        
vmware-tools-libraries-nox   
vmware-tools-plugins-autoUpgrade
vmware-tools-plugins-deployPkg
vmware-tools-plugins-guestInfo
vmware-tools-plugins-hgfsServer
vmware-tools-plugins-powerOps
vmware-tools-plugins-timeSync
vmware-tools-plugins-vix     
vmware-tools-plugins-vmbackup
vmware-tools-services

最小限ってことで「yum install vmware-tools-thinprint」でインストールされるパッケージ

vmware-tools-thinprint
vmware-tools-core
vmware-tools-foundation
vmware-tools-guestlib
vmware-tools-libraries-nox
vmware-tools-services

+追加でOSパッケージがいくつか
vmxnet3,vmw_pvscsi,vmware_balloonがインストールされるけど、vmware-tools-esx-noxでインストールした方がいい。

X-Windowsドライバを含めたインストールを行う「yum install vmware-tools-esx」でインストールされるパッケージ

vmware-tools-esx
vmware-tools-core         
vmware-tools-esx-nox      
vmware-tools-foundation   
vmware-tools-guestlib     
vmware-tools-libraries-nox
vmware-tools-libraries-x  
vmware-tools-plugins-autoUpgrade
vmware-tools-plugins-deployPkg
vmware-tools-plugins-desktopEvents
vmware-tools-plugins-guestInfo
vmware-tools-plugins-hgfsServer
vmware-tools-plugins-powerOps
vmware-tools-plugins-resolutionSet
vmware-tools-plugins-timeSync
vmware-tools-plugins-unity
vmware-tools-plugins-vix
vmware-tools-plugins-vmbackup
vmware-tools-services
vmware-tools-user

+追加でOSパッケージがいくつか

RHEL7/CentOS7など最近のLinuxでは、open-vm-toolsでのサポートになっているため、上記のモノは使用しない。

open-vm-tools に対する VMware のサポートについて (2074713)(英語の原文:VMware support of open-vm-tools (2073803))

具体的には以下のOSが対象となる。
・Fedora 19 and later releases
・Debian 7.x and later releases
・openSUSE 11.x and later releases
・Recent Ubuntu releases (12.04 LTS, 13.10 and later)
・Red Hat Enterprise Linux 7.0 and later releases
・SUSE Linux Enterprise 12 – available Q4 2014

RHEL5向けのvmware toolsの最終版は VMware Tools 10.3.22
また、RHEL5/CentOS5はTLS1.2に対応していない(TLS1.0/1.1のみ)ため、最近のWebサイトからwget/curlおよびyumコマンドでのアクセスができないことに注意
ISOファイルは Download Product:VMware Tools 10.3.22 から入手できる


Windows向けvmware-toolsについて

Windows版vmware-tools配布場所:https://packages.vmware.com/tools/esx/latest/windows/index.html

Windows Server 2008 SP2 / Windows Vista SP2の最終サポート: VMware Tools 11.0.6 (ダウンロードURL VMware Tools 11.0.6)

VMware tools 12.0.0以降からネットワークアダプタ VMXNet2(拡張)が使えなくなりました。いまだに使っている場合はVMXNet3に変更する必要がある(VMwware Tools 12.0.5リリースノートより)


Solaris x86向けvmware-toolsについて

Solaris x86をインストールした時に、VMware-toolsを探したのでメモ書きとして追加

公式文書としては「Installing and upgrading the latest version of VMware Tools on existing hosts (2129825)」が出てくるんだけど、Solaris用のVMware-toolsがどこから入手できるのかMy VMwareからダウンロードできるよ、しか書いてない。

[Product Download]-[VMware vSphere]で「Drivers&Tools」を選択し、「VMware Tools」のツリーを開く

いろいろ表示されている中の「VMware Tools 11.0.6」か「VMware Tools 11.1.0」を選択

するとリンク先には「Solaris用はVMware Tools 10.3.10が最後」と誘導されているので、そのリンクを飛ぶと、「VMware Tools packages for Solaris and OS X」がダウンロードできる。

これを展開して、ESXiの /usr/lib/vmware/isoimages に配置する。

といってもこれは /productLocker/vmtools/ へのシンボリックリンクになっている。

この「/productLocker」をさす先は、ESXiの設定でUserVars.ProductLockerLocation を使って指定する。

指定したディレクトリ内に「vmtools」というディレクトリを作成し、その中にisoイメージなどを展開しておくと、これを使ってVMware toolsのインストールをすることができるようになる。

Windowsバッチファイルでping応答の違いで動作をかえる


Windowsバッチファイルで、指定IPアドレスから応答がなくなったら次の作業を実施する、という処理をやりたかったので作った。

普通にping実行時のERRORLEVELを見ればいいか、と思っていたが、試験した環境では応答があってもなくてもERRORLEVEL0だったので判別ができなかった・・・

調べたところ「otnx.jpのコマンド別/ping」に調査した結果と回避方法があったのでそれを使った。

ちなみにotnx.jpではfindで「bytes=32」を引っかけていたが、日本語環境だと「 バイト数 =32」になってしまう。しかし、バッチには日本語文字列を書きたくなかったので、その後ろにある「ms TTL=」の方を引っかけるようにした。

・停止待ちバッチファイル

応答がなかったら終了。
応答があったら3回繰り返す

@echo off

set COUNT=0

:error
set /a COUNT=COUNT+1
echo %COUNT%
if "%COUNT%" == "3" goto errorout
ping -n 1 IPアドレス | find "ms TTL=" > NUL
if ERRORLEVEL 1 goto notrespond
timeout /t 5  > nul
goto error

:notrespond
echo host stopped
goto end

:errorout
echo host not stop

:end

・起動待ちバッチファイル

ping応答があるまで待機する
3回繰り返してもping応答がなければ諦める

@echo off

set COUNT=0

:error
set /a COUNT=COUNT+1
if "%COUNT%" == "3" goto errorout
ping -n 1 IPアドレス | find "ms TTL=" > NUL
if ERRORLEVEL 1 goto error

echo host working
goto end

:errorout
echo host not working

:end

Windows上でperlを使って日本語ファイル名を操作する(メモ



slashdot.jpの「Perlはゾンビだ」に、日本語Windows環境において、perlを使って日本語ファイル名を操作する時の注意点がまとめられていたので、引用&備忘録化。

過去にperlスクリプトを作る際、ファイル内に書かれた日本語の操作に関することはWindows/Linuxで動作が共通化できたものの、「日本語ファイル名の取り扱い」について、Windows上での動作がいまいち分からず、面倒になり、NASに該当ファイル群を置き、Linuxで処理する、ということをしたことがある。

その時に受けた感じからすると、以下の解説は非常に納得がいくモノだった。

Anonymous Coward の書き込み (#2628619) 」より

コマンドラインからの引数取得とかファイル操作とかのたびに
@ARGV = map { decode(‘cp932’, $_) } @ARGV; とか
open my $fh, ”, encode(‘cp932’, $filename) or die $!; とか
@files = map { decode(‘cp932’, $_) } readdir($d); とか
if (-f encode(‘cp932’, $filename)) とか
mkdir encode(‘cp932’, $filename); とかソース全体にわたって書かなければならないこと。

これが面倒だと思わない奴はWindows上でPerlを本気で使ったことがないとしか思えない。少なくとも小飼弾はMac使っているようだし。つーか面倒だと思わないならそもそもどうして開祖が「怠惰はプログラマの美徳」とか言ってる言語なんか使ってるの?

56億7千万歩ほど譲ってこれは面倒ではないということにしても、Windows以外の環境への移植性がまったくない。Windows上でシステムロケールを変えただけで動作がおかしくなる。当然どんな環境で動くかわからないモジュール内では使えない。
まあいちおうこれには対処の方法があって、
use Encode::Locale;
@ARGV = map { decode(locale, $_) } @ARGV; とか
open my $fh, ”, encode(locale_fs, $filename) or die $!; とか
@files = map { decode(locale_fs, $_) } readdir($d); とか
if (-f encode(locale_fs, $filename)) とか
mkdir encode(locale_fs, $filename); とかさらに呪文を積み増しすればいいらしい。
MacやLinuxでこんなことわざわざしてる奴いないと思うけど。つーか忘れてもたいてい問題なく動くからWindows以外の環境で正しく書くのが超困難。だから結局Windowsに移植する奴が貧乏クジを引かされる。Windows上ですら、localeとlocal_fsが違う環境があるというバグを知らずに踏んでも気づかない。

しかし実はEncode::Locale;使ってもまだ不十分で、システムロケール(日本語版ならシフトJIS)で表せない文字を含んだファイル名が扱えない。いちおうWin32::Unicode::Fileというモジュールがあるようだが、ファイル読み書きをモジュール内で独自に行なっているので信じられないほど遅くて捨てた。Win32::Longnameというモジュールがちょっとはマシなようだが、どちらにしてもまたも移植性がなくなる。

自分で書くコードは上記の面倒じゃないことにした書き換えを「するだけで」済むとしても、File::compareのような超基本的モジュールすらいまだに非対応。

Perlでこのへんが改善される見込みはまったくなさそうなので、自分はPythonの勉強を始めた。

そして、(#2630401) より

> ・PerlをUTF-8ベース(CP65001)でPerlを動かす
> ことだと思います。

Console CPはファイル名で使われるコードページにはまったく影響を与えない。Encode::Localeでもlocale_fsとconsole_inとconsole_outが別々に定義されている(そう、APIレベルではコンソール入力と出力さえ異なる可能性がある)。Perlの仕様をまともにするためにあなたのような知ったかぶりバカをマサカリで殴って回るよりコストがかからないに違いないからPythonの勉強を始めたの。

> 普通のコマンドプロンプト(SJIS)ベースでは不可能。

Windowsにはコンソール入出力にもワイド文字APIがあり、それを使えば可能(リダイレクトやパイプが絡むとこっちの都合だけでエンコーディングを決められないけどそれはCygwinでも同じだし)。もちろん今あるPerlでは不可能だがそれは実装の手抜きにすぎない。そもそもCygwinはどうやってUTF-8文字を受け付けるコンソールを実現してると思ってるの?

> ・UTF-8 な cygwin の環境を構築し、その上で Perl を使う

Cygwinはパスの扱いが特殊すぎて、結局普通のアプリとパス名をやりとりする際にパスの変換/逆変換が必要なので、面倒だとか移植性ゼロだとかいう問題は何も解決しない。Perlがmsvcrt使うのやめて、UTF-8←→UTF-16LE変換を行ってワイド文字API呼び出して、Encode::LocaleはあたかもロケールがUTF-8であるかのようにふるまってくれるのが一番いいのだが、それを実現するために投入するコストを考えるとすでにまともな処理している言語の乗り換えにコストを振り向けたほうがどう考えても省エネ。

> ・@ARGVやファイル名を、スクリプト本体内のデータ処理と混ぜない

それを面倒と思わないなら以下略