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

DynDNSの仕組みが若干変わった


2023/07/10追記

この記事で触れているddclientですが、2023年7月5日付けで更新終了となりました。

代替としてinadyn , dnsupdate が紹介されていました。


昔はDynDNSと呼ばれていた「Dyn」というDNSサービスがあります。

固定じゃないIPアドレスでも、特定のホスト名でアクセスできるようにしてくれるRemote Access(DynDNS)を、以前は無料で提供していました。
今は、年25ドルになっています。

が・・・実は、無料だった当時、寄付をすると上位サービスにアップグレード、というキャンペーンをやっていました。
このアップグレードしたユーザは、現在も、無料で使えていたりします。

それは、さておき、Dynに久々にログインしてみたところ、以下の様にお知らせが出てきました。

login

You have not generated an updater client key!
Please generate a key for use with update clients to help keep your account credientals secure.

いままで、DynDNSに登録したIPアドレスを変更する際、クライアントソフトにユーザ名/パスワードを登録して行っていたものを、Dynの管理画面でクライアントキーを発行し、それをクライアントソフトに登録する、という形に変更したようです。

が・・・Linuxの場合、Dynのクライアント一覧に掲載されているソフトが、GUI環境向けの「Dyn Updater for Ubuntu Linux」だけがクライアントキーに対応していないように見えるのは気のせいか??
(2014/09/25リリースのver5.2に「Support secure update key for account.dyn.com in place of account credentials.」とある)

ddclient」の方は、2013/12/26リリースのver3.8.2が最新のようで、まだ対応していない。

そんなわけで、新しい仕組みができたけど、まだ使えない、という微妙な感じになりました^^;;;

IPFireでパッケージのインストールやアップデートができない



ESXiの上で、ネットワークを2つ作り、それぞれをVPN接続する、というテスト環境を作ろうとした。

VPNルータをどうするか悩んだのだが、Linuxベースの「IPFire」というので構築することにした。
(Endian FirewallのComminity Editionだとうまく構成が作れなかった)

決め手の1つに、vmware-toolsを容易にインストールすることができる、ということがあった。
が、「手順」の通りにやろうとしても、エラーとなる。

状況としては、「pakfire update problem」と全く同じモノ。
(上記のURLよりエラーを引用)

Sep  7 21:15:34 serwer1 pakfire: PAKFIRE INFO: IPFire Pakfire 2.15 started!
Sep  7 21:15:34 serwer1 pakfire: CRYPTO INFO: Checking GnuPG Database
Sep  7 21:15:34 serwer1 pakfire: CRYPTO WARN: The GnuPG isn't configured corectly. Trying now to fix this.
Sep  7 21:15:34 serwer1 pakfire: CRYPTO WARN: It's normal to see this on first execution.
Sep  7 21:17:34 serwer1 pakfire: Sending my uuid: 168d3c61-ae2a-454f-81a1-48a817470c37
Sep  7 21:17:34 serwer1 pakfire: DOWNLOAD STARTED: counter.py?ver=2.15&uuid=168d3c61-ae2a-454f-81a1-48a817470c37
Sep  7 21:17:34 serwer1 pakfire: DOWNLOAD INFO: Host: pakfire.ipfire.org (HTTP) - File: counter.py?ver=2.15&uuid=168d3c61-ae2a-454f-81a1-48a817470c37
Sep  7 21:17:34 serwer1 pakfire: DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
Sep  7 21:17:34 serwer1 pakfire: DOWNLOAD STARTED: 2.15/lists/server-list.db
Sep  7 21:17:34 serwer1 pakfire: DOWNLOAD INFO: Host: pakfire.ipfire.org (HTTP) - File: 2.15/lists/server-list.db
Sep  7 21:17:35 serwer1 pakfire: DOWNLOAD INFO: 2.15/lists/server-list.db has size of 907 bytes
Sep  7 21:17:35 serwer1 pakfire: DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
Sep  7 21:17:35 serwer1 pakfire: DOWNLOAD INFO: File received. Start checking signature...
Sep  7 21:17:35 serwer1 pakfire: DOWNLOAD ERROR: The downloaded file (2.15/lists/server-list.db) wasn't verified by IPFire.org. Sorry - Exiting...
Sep  7 21:18:06 serwer1 pakfire: TIME INFO: Time Server 217.153.128.243 has 0.010834 sec offset to localtime.

解決方法として、外部の11371ポートに対する通信を許可すること、と書かれている。
PakfireのAdditional Note

IPFireの設定をいじってみても解決しない。
なぜ?と考えて見ると、今回作成したテスト環境は、別のFirewallの中にある、というのがポイントだった。
つまり、別のFirewall側に設定を追加する必要があったということ。

そちらの設定変更権限はないので、別の方策がないか捜索したところ、発見。

Pakfire wont update on new install The GnuPG isn’t configured corectly. solved!

「/opt/pakfire/lib/functions.pl」内で
「my $command = “gpg –keyserver pgp.ipfire.org –always-trust –status-fd 2”;」
と書かれているところ、下記のようにポート80でアクセスできるサーバに書き直す。
「my $command = “gpg –keyserver hkp://keyserver.ubuntu.com:80 –always-trust –status-fd 2”;」
というもの。

これを実施したところ、正常に動作するようになった。

ちなみに、上記URLだと、「Core 82で直った」とか書かれてますが、Core82で試して同じ現象でした。

Debianのwoody (3.0), sarge (3.1), etch (4.0), lenny (5.0)でbashの脆弱性問題に対応する手法



bashの脆弱性問題で、Debianで既にアップデートされないバージョンであるところの、woody (3.0), sarge (3.1), etch (4.0), lenny (5.0)に対して、簡単に対応する手法があるのか?というのを調べてみた。

Seewebというクラウドとホスティングをやっている会社にお勤めのDebianメンテナのMarco d’Itriさんが、会社の後援を受けて古いバージョン用の非公式debianパッケージを公開してくれています。
CVE-2014-6271 fix for Debian woody, sarge, etch and lenny

配布場所については、上記からたどってください。
(http://ftp.linux.it/pub/People/md/bash/ なんですが、Seeweb社の後援を受けて公開されていますので、敬意を表してここから配布場所への直リンクはしないでおきます)

どのバージョンのbashをダウンロードすればいいのかは、現在インストールされているパッケージのバージョンを調べてください。

olddebian:~# dpkg -l|grep bash
ii  bash                                                     3.2-4                    The GNU Bourne Again SHell
ii  bash-completion                                          20080705                   programmable completion for the bash shell
olddebian:~#

上記であれば、「bash」の「3.2-4」です。
配布場所のファイル一覧から「bash_3.2-4.???_amd64.deb」や「bash_3.2-4.???_i386.deb」のうち、数字が一番新しいものを探します。

2014/09/30 20:00現在だと「bash_3.2-4.2_amd64.deb」が最新でした。
これをwgetコマンドなどでダウンロードし、dpkg -iでインストールします。

手順としては、まずは、https://github.com/hannob/bashcheck/からbash脆弱性確認スクリプトを入手します。

olddebian:~# wget --no-check-certificate https://github.com/hannob/bashcheck/raw/master/bashcheck
<略>
olddebian:~# chmod a+x bashcheck
olddebian:~# ./bashcheck
Vulnerable to CVE-2014-6271 (original shellshock)
Vulnerable to CVE-2014-7169 (taviso bug)
./bashcheck: line 18: 20675 Segmentation fault      bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser still active, likely vulnerable to yet unknown parser bugs like CVE-2014-6277 (lcamtuf bug)
olddebian:~#

脆弱性があることを確認したら、配布元のページから、debパッケージをダウンロードします。

「wget http://ftp.linux.it/pub/People/md/bash/bash_~.deb」という感じでダウンロードします。

ダウンロード後は、debパッケージを「dpkg -i」でインストールします。

olddebian:~# dpkg -i bash_3.2-4.2_i386.deb
(Reading database ... 19825 files and directories currently installed.)
Preparing to replace bash 3.2-4 (using bash_3.2-4.2_i386.deb) ...
Unpacking replacement bash ...
Setting up bash (3.2-4.2) ...
Processing triggers for man-db ...
olddebian:~#

インストール後、パッケージバージョンの確認と、脆弱性確認を行います。

olddebian:~# dpkg -l|grep bash
ii  bash                                                     3.2-4.2                    The GNU Bourne Again SHell
ii  bash-completion                                          20080705                   programmable completion for the bash shell
olddebian:~# ./bashcheck
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs
olddebian:~#

これで、現段階では、問題がなくなりました。


おまけ

squeeze(6.0)の場合、squeeze-ltsに切り替えることで対応できます。
「/etc/apt/sources.list」に以下を追加します。

deb http://http.debian.net/debian squeeze-lts main contrib non-free
deb-src http://http.debian.net/debian squeeze-lts main contrib non-free

そして、bashだけをアップデートしたいのであれば、以下を実行します。

root@olddebian:~# apt-get update
<略>
root@olddebian:~# apt-get install -t squeeze-lts --only-upgrade bash
<略>
root@olddebian:~# 

ネタ元:「How to only install security updates on debian」「bash vulnerability CVE-2014-6271 (Shellshock) fix on debian squeeze [duplicate]