〔備忘録〕 SoftEther のビルド on Ubuntu 18.04

Ubuntu 18.04 で SoftEther をビルドしたので、そのメモ。

環境:

ビルドに必要なパッケージは以下のとおり。

  • build-essential
  • libssl-dev
  • libreadline-dev
  • libncurses5-dev
  • zlib1g-dev

あとは、SoftEther のドキュメント (BUILD_UNIX.TXT) に記載のように、
以下のコマンド実行でビルドできた。

# ./configure
# make
# make install

〔備忘録〕 gitlab-ce-10.0.3 (ominibus package) を subdirectory で動かす

GitLab-CE を、以下のような subdirectory を付けた URL で動作させる必要があったので、その設定方法をメモします。

URL: http://my-server-url.local/git/

なお、動作環境は次のとおりです。


Google 先生に質問したら、

というサイトを教えてくれました。
これらのサイトを参考に、以下の手順で修正しました。


(1) /opt/gitlab/embedded/service/gitlab-rails/config/initializers/relative_url.rb を用意する(同一ディレクトリにある relative_url.rb.sample を元にして用意する)

# cd /opt/gitlab/embedded/service/gitlab-rails/config/initializers
# cp relative_url.rb.sample relative_url.rb


(2) 上記 relative_url.rb の config.relative_url_root に subdirectory を設定

Rails.application.configure do
config.relative_url_root = "/git"
end


(3) /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml の relative_url_root に subdirectory を設定

gitlab.yml の変更箇所

production: &base
gitlab:
...
relative_url_root: /git


(4) /opt/gitlab/embedded/service/gitlab-rails/config/unicorn.rb を用意(同一ディレクトリにある unicorn.rb.example を元にして用意する)

# cd /opt/gitlab/embedded/service/gitlab-rails/config/
# cp unicorn.rb.example unicorn.rb


(5) 上記 unicorn.rb の RAILS_RELATIVE_URL_ROOT 環境変数に subdirectory を設定

ENV['RAILS_RELATIVE_URL_ROOT'] = "/git"


(6) /opt/gitlab/embedded/service/gitlab-shell/config.yml の gitlab_url に subdirectory を追記

# Url to gitlab instance. Used for api calls. Should end with a slash.
gitlab_url: "http://127.0.0.1:8080/git"


(7) /etc/gitlab/gitlab.rb の external_url に subdirectory を設定

external_url 'http://my-server-url.local/git/'


(8) reconfigure と restart を実行

# gitlab-ctl reconfigure
# gitlab-ctl restart

〔不具合対応〕 Windows 10 リモートデスクトップから XRDP 0.9.4 in LXDE on Ubuntu 16.04 LTS サーバへ接続できない

昨日の日記「2017-10-04 - grasso0210の日記」で、
Ubunutu 16.04 + LXDE 上での XRDP の動作確認に成功したと書きましたが、
改めて再インストール(実行PCのHDD交換のため)したところ、
接続できない不具合が発生したので記録しておきます。


【現象】

Windows 10 からのリモートデスクトップ接続で、ログイン後にクライアント自体が落ちる

/var/log/xrdp.log を見ると、以下のようなエラーメッセージが出力されていました。

[20171005-14:35:13] [ERROR] Listening socket is in wrong state we terminate listener



【原因】

ユーザディレクトリ下に作成した ~/.xsession script 内で、X Session manager (lxsession) を起動していなかったため
LXDE サーバとの session 用 socket が正常に作られず、RDP client と LXDE サーバとの通信ができなかったため…(推測)


【対策】

ユーザディレクトリ下の ~/.xsession に次の1行を加える

lxsession -s LXDE -e LXDE

参考サイト

                                                                                                                      • -

原因の調査の過程で、以下のようなことを試しました。
しかし、状況は改善しませんでした。

■ 失敗策 (1)

参照サイト:

この記事の後半に書かれているように、
TLS秘密鍵と証明書署名要求を再作成し、/etc/xrdp/xrdp.ini に記載しました。
でも、現象は変わりませんでした。

TLS 秘密鍵と証明書署名要求の作成

$ cd /etc/xrdp
$ sudo openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365

※ 対話形式で各種設定項目を問われますので、 FQDN を問われたら xrdp サーバの FQDN を設定すると、RDP接続時に「証明書のFQDNとサーバのFQDNが違う」旨のエラーメッセージが出なくなります。


/etc/xrdp/xrdp.ini の Security Layer 設定関連

[Globals]
security_layer=negotiate
crypt_level=high
certificate=cert.pem
key_file=key.pem
ssl_protocols=TLSv1, TLSv1.1, TLSv1.2

■ 失敗策(2)

参考サイト:

xrdp 0.9.3 以前のバージョンではそうだったのかもしれませんが、
私が試した xrdp 0.9.4 では /etc/xrdp/xrdp.ini 内の下記双方のパラメータを 24 から 32 に変更しても現象は変わりませんでした。

[Globals]
max_bpp=24

[X11rdp]
xserverbpp=24

                                                                                                                      • -

余談になりますが、昨日のテストで上記の現象が発生せず、
今日の動作確認段階で発生したのは、
~/.xsession ファイルの有無の違いです。

今日は、LXDE 環境下での Keymap を変更 ( 「Caps Lock」キーを「左Ctrl」キーに変更)する処理を追加したためでした。

こちらは、/etc/default/keyboard で

XKBOPTIONS="ctrl:nocaps"

と記述することで、コンソール上では変更されていたのに、
LXDE 起動後に LXTerminal 等では反映されなかったのはなぜ?
という疑問が残るのですが… f(^_^;

〔備忘録〕 XRDP 0.9.4 in LXDE on Ubuntu 16.04 LTS のインストール

これまで、Ubuntu 16.04 LTS が動作する PC に RDP で接続するために、
xrdp package を使って RDP サーバーをインストールしていました。

でも、この記事を書いている現在でも、pacakge 版の xrdp のバージョンは 0.6 であり、
日本語キーボードを使う場合は「キー配列について - 日本 xrdp ユーザ会」さんが公開している
キーマップファイルをインストールする必要がありました。

そこで、新しいPCを組立て OS をインストールしたついでに、
xrdp も最新バージョンを入れてみましたので、
その時の備忘録を以下にまとめます。

なお、今回使用した環境は次のとおりです。

  • CPU: Ryzen 7
  • Mem: 32GiB
  • OS: Ubuntu 16.04.3 LTS
  • X環境: LXDE (pacakge からインストール)

また、以下のサイトを参考にしました。

手順: ※ sudo は省略しています。

# apt-get install build-essential devscripts git autoconf libtool pkg-config gcc g++ make libssl-dev libpam0g-dev libjpeg-dev libx11-dev libxfixes-dev libxrandr-dev flex bison libxml2-dev intltool xsltproc xutils-dev python-libxml2 g++ xutils libfuse-dev libmp3lame-dev nasm libpixman-1-dev xserver-xorg-dev
# git clone https://github.com/neutrinolabs/xrdp.git xrdp
# cd xrdp
# ./bootstrap
# ./configure --enable-fuse
# make
# make install
# ln -s /usr/local/sbin/xrdp{,-sesman} /usr/sbin
# cd ..

# git clone https://github.com/neutrinolabs/xorgxrdp.git xorgxrdp
# cd xorgxrdp
# ./bootstrap
# ./configure
# make
# make install

# systemctl enable xrdp
# systemctl start xrdp

今まで、日本語キーマップの設定に苦労していたのが嘘のように、
簡単に接続できました。 (^o^)

〔備忘録〕 Samba4 AD DC with BIND9_DLZ のインストール

約1年前に Samba で Active Directory PDC を構築しましたが、
その後、訳あって使用しなくなりました。
(個人で、自分一人のアカウントしか管理しないのであれば、
不要なんですよね… f(^^;;; )

今度は複数名のアカウントを管理したいのと、
現時点で BIND9 + ISC DHCP Server でホストの管理をしているので、
BIND9 をバックエンドとして Samba 4 の PDC を構築することにしました。

以下はその時の私のミスと対処方法を含めたインストール方法です。

=======================================================================

前提条件として、以下の環境下で Samba 4 をインストールします。

  • PC: Virtualbox 5.1 の仮想PC (1CPU, 4GiB memory)
  • OS: Ubuntu 16.04 LTS
  • bind9 がインストール済み

今回は、ソースからビルドするのが面倒だったので、
package でインストールしました。
なお、「雑廉堂の雑記帳」さんのインストール手順
参考させていただきました。

手順はざっくりと書くと、以下のとおりです。

  1. /etc/network/interfaces, /etc/hosts の編集
  2. ntp のインストール
  3. bind9 のインストール
  4. /etc/apparmor.d/usr.sbin.named の修正
  5. krb5-user のインストール
  6. samba, smbclient のインストール

上記の手順でインストールすると、
なぜか Samba PDC の接続確認で、以下のようなエラーが発生します。

# smbclient -L localhost -U%
session setup failed: NT_STATUS_OBJECT_NAME_NOT_FOUND

ググってみると、こちらに書かれているように、
「winbind」がインストールされていないためでした。

winbind をインストールすると、正常に動作しました。

ubuntu package (多分 debian package も同じだと思いますが)だと、

# apt-get install samba winbind smbclient

としなければならなかったみたいですね。

〔備忘録〕 Apache のリバースプロキシで内部 WordPress サーバを公開する

自前で用意した Web サーバで、WordPress のブログサイトを公開しようと思い、
次のような構成でサーバを準備しました。


(Internet) ------- (My Web Server @DMZ) ------ ( Wordpress Server @intra-net)
[HTTPS] [HTTP]

# 一応セキュリティのために、上記の "----" の間にはルーターが入っています。

上記の構成で、インターネットに Wordpress を公開するには、
My Web Server 上でReverse Proxyを構成すればいいと思ったのですが、
これが意外に簡単にできなかったので、備忘録としてメモします。


前提条件として、My Web Server は

WordPress は、

です。


補足)
やり方(結果)だけを見たい方は、この記事の最後の方だけを読んでください。
途中は失敗談をずらずらと書いています。 f(^^;;;



=================< 失敗談 >==================


失敗1)

単純に My Web Server で Reverse Proxy の設定をしました。



ProxyRequests Off
ProxyPass "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverse "/blog/" "http://internal-wordpress-server.invalid/"

としたのですが、HTML 以外のコンテンツ(画像とか)が全く表示されません。

実際に、HTML のソースコードを見ると、画像等のURLが内部の Wordpress サーバアドレスがそのまま書かれていました。 orz



失敗2)

とりあえず、 Google 先生に教えを乞いました。
その中で、

という方法が紹介されていたので、
以下のように設定を追加しました。



ProxyRequests Off
ProxyPass "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverse "/blog/" "http://internal-wordpress-server.invalid/"
ProxyReverseHost on
ProxyPassReverseCookieDomain internal-wordpress-server.invalid My-Web-Server.invalid
ProxyPassReverseCookiePath / /

結果は、最初と同じく、画像などが表示されません。
ただ、ヘッダーを見ると Cookie の中に書かれていた internal-wordpress-server.invalid というサーバ名が、外部公開用サーバ My-Web-Server.invalid に書き換えられていたので、この点ではちょっと進歩です。

ちなみに、ProxyReverseHostのドキュメントを見ると、
「バックエンドサーバ(この事例では Wordpress Server)が、元々の Host ヘッダを解釈する必要のあるときのような、 特別な設定が必要な場合にのみ有用です。」
と書かれていますので、
今回のケースでは必要ありませんでしたし、問題の解決にはつながりませんでした。



失敗3)

さらに、Google 先生に教えを乞うたところ、
以下のサイトを紹介していただきました。

実際に、Wordpress 内の wp-config.php に以下を追記してみました。


$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];

すると、動作確認で使用していた firefox 君が
「ページの自動転送設定が正しくありません
  このアドレスへのリクエストに対するサーバーの自動転送設定がループしています。
  * Cookie を無効化したり拒否していることにより、この問題が発生している可能性もあります。」
と怒ってきました。

Google先生曰く、

もあるよ。
とのことで、まずは単純に、wp-config.php


$_SERVER[‘HTTPS’]=on
を追記したところ、上記サイトの言うようにリダイレクトループは無くなりました

が、firefox 君曰く、
「internal-wordpress-server.invalid のサーバーへの接続を確立できませんでした。」
と文句を言ってきました。

当たり前ですネ。
internal-wordpress-server.invalid は HTTP 通信のみで、HTTPS は喋れません。



失敗4)

個人的に、WordpressPHP に設定以外の項目をごちゃごちゃ書くのは、
 スマートではなく好みではない。
ので、
Google 先生に再度、
 「HTTP のヘッダーだけでなく HTMLコンテンツも Reverse Proxy する方法はないの?」
と問い合わせてみました。
すると、Apache HTTPD 2.4 には mod_proxy_html があるよ

と回答いただきました。

そこで、上記失敗3)の設定は元に戻して、
Reverse Proxy 機能を提供する My Web Server で以下の設定(ProxyHTMLEnable,ProxyHTMLURLMap)を追加しました。



ProxyRequests Off
ProxyPass "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverse "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverseCookieDomain internal-wordpress-server.invalid My-Web-Server.invalid
ProxyPassReverseCookiePath / /
ProxyHTMLEnable On
ProxyHTMLURLMap http://internal-wordpress-server.invalid/ /blog/

すると、firefox 君が
「内容符号化 (Content-Encoding) に問題があります
  * 不正または不明な形式で圧縮されているため、ページを表示できません。」
と怒ってきました。

言い換えると、単純に Reverse Proxy しただけだと、HTML テキストは表示できたけど、ProxyHTMLEnable On で HTML テキストまで表示できなくなったのです。

何が違うのか…
ということで、HTML が表示できた場合と、できない場合の HTTP header を見比べてみました。
すると、

  • HTML テキストだけが表示できた場合


GET /blog/ HTTP/1.1
Host: My-Web-Server.invalid
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br

HTTP/1.1 200 OK
Server: Apache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Content-Length: 3950

  • ProxyHTMLEnable On にして表示できなくなった場合


GET /blog/ HTTP/1.1
Host: My-Web-Server.invalid
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br

HTTP/1.1 200 OK
Date: Fri, 30 Jun 2017 02:48:38 GMT
Server: Apache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Content-Length: 5479

と、同じ HTML テキストを gzip 圧縮しただけなはずなのに、
Content-Lnegth が違っている…

ということで、
 「WordPress サーバが Reverse Proxy に転送した HTML テキストは gzip 圧縮しており、
  更に Reverse Proxy が Client に送信したコンテンツデータは二重に gzip 圧縮している。」
という仮説が立てられます。

仮説が正しいかどうかは、
 WordPress サーバがコンテンツを圧縮しないで応答する。
ようにしてみれば、確認できるはずです。
実際にやってみたら、仮説は正解でした。



成功事例1)

WordPress サーバから送信するコンテンツを圧縮しないようにしたら、
外部 client からも閲覧できるようになりました。
その際の設定は、次のとおりです。

  • My Web Server (Reverse Proxy) の設定



ProxyRequests Off
ProxyPass "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverse "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverseCookieDomain internal-wordpress-server.invalid My-Web-Server.invalid
ProxyPassReverseCookiePath / /

ProxyHTMLEnable On
ProxyHTMLURLMap http://internal-wordpress-server.invalid/ /blog/


  • WordPress 側の apache の設定 (Ubuntu では /etc/apache2/mods-enabled/deflate.conf を下記の用に書き換える)

# /etc/apache2/mods-enabled/deflate.conf のシンボリックリンクを消すだけでもOKですね。



#
# # these are known to be safe with MSIE 6
# AddOutputFilterByType DEFLATE text/html text/plain text/xml
#
# # everything else may cause problems with MSIE 6
# AddOutputFilterByType DEFLATE text/css
# AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript
# AddOutputFilterByType DEFLATE application/rss+xml
# AddOutputFilterByType DEFLATE application/xml
#



これだと、イントラネットの Client からアクセスした場合も、
コンテンツが圧縮されなくなります。
実害はあまりないのですが、もうちょっとスマートにしたいですね。

ということで、Reverse Proxy した場合だけ圧縮しないように
する方法を調べたら、こんなヒントがありました。

方法としては、SetEnvIfNoCase ディレクティブで、
「 HTTP ヘッダ内で X-Forwarded-Host が設定されていたら、圧縮しない」
ようにしたら、うまくできました。

その設定は、以下の「最終成功時の設定」に書いておきます。



お礼>
失敗事例を全部読んでくださった皆様へ
貴重なお時間を割いていただき、ありがとうございました。




=================< 最終成功時の設定 >==================

ということで、ずらずらと途中経過を書きましたが、
結論としては 公開用Webサーバ (My Web Server) では

  • Request Header を Reverse Proxy した上で、
  • コンテンツ内も Reverse Proxy して URI を書き換え

内部の WordPress サーバでは、

  • Reverse Proxy サーバからのリクエストに対してはコンテンツを圧縮しない

ように設定すると、成功しました。

  • My Web Server (Reverse Proxy) の設定



ProxyRequests Off
ProxyPass "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverse "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverseCookieDomain internal-wordpress-server.invalid My-Web-Server.invalid
ProxyPassReverseCookiePath / /

ProxyHTMLEnable On
ProxyHTMLURLMap http://internal-wordpress-server.invalid/ /blog/


  • WordPress 側の apache の設定 (Ubuntu では /etc/apache2/mods-enabled/deflate.conf を下記の用に書き換える)




# these are known to be safe with MSIE 6
AddOutputFilterByType DEFLATE text/html text/plain text/xml

# everything else may cause problems with MSIE 6
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/xml
SetEnvIfNoCase X-Forwarded-Host .+$ no-gzip dont-vary



実例は、 https://grasso.homeip.net/blog/ にて公開しています…



※ 2017.7.8 追記

Reverse Proxy サーバ側で以下のように "SetOutputFilter INFLATE"を追記すると、
WordPress 側での "SetEnvIfNoCase" 設定は不要になります。
(但し、Reverse Proxy 側では「inflate -> deflate」処理をする可能性があり、負荷が掛ります…)



ProxyRequests Off
ProxyPass "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverse "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverseCookieDomain internal-wordpress-server.invalid My-Web-Server.invalid
ProxyPassReverseCookiePath / /

SetOutputFilter INFLATE
ProxyHTMLEnable On
ProxyHTMLURLMap http://internal-wordpress-server.invalid/ /blog/


〔備忘録〕 Ubuntu 16.04LTS (xenial) に lxde をインストールした場合、 lxde-logout.desktop がインストールされない

私は lightweight な環境が好きなので、ubuntu server + lxde をインストールした。
LXDE


# apt-get install lxde
でインストールし、
デスクトップ環境の "logout "ボタンで logout しようとしたら、
「Error: Invalid desktop entry file: '/usr/share/applications/lxde-logout.desktop' 」
というエラーが表示され、logoutできない (T_T)

理由は、lxsession-logout パッケージがインストールされていなかったため。

ubuntu 16.04.02 server から lxde をインストールするときは、lxsession-logout のインストールも必要。


# apt-get install lxde lxsession-logout