〔備忘録〕 SoftEther のビルド on Ubuntu 18.04
Ubuntu 18.04 で SoftEther をビルドしたので、そのメモ。
環境:
- OS: Ubuntu 18.04 LTS (Bionic Beaver)
- SoftEther: v4.27-9666-beta (from https://github.com/SoftEtherVPN/SoftEtherVPN_Stable/ )
ビルドに必要なパッケージは以下のとおり。
- 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/
なお、動作環境は次のとおりです。
- OS: Ubuntu 16.04 LTS
- GitLab: gitlab-ce 10.0.3 ominibus package (Installation methods for GitLab | GitLab に記載の手順で apt-get コマンドを用いてインストール)
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行を加える
参考サイト
- https://qiita.com/oniipon/items/4fe3ba65d64d6eed231c
- https://askubuntu.com/questions/178962/how-to-start-lxde-session-automatically-after-tightvncserver-starts-to-make-me-a
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
原因の調査の過程で、以下のようなことを試しました。
しかし、状況は改善しませんでした。
■ 失敗策 (1)
参照サイト:
この記事の後半に書かれているように、
TLSの秘密鍵と証明書署名要求を再作成し、/etc/xrdp/xrdp.ini に記載しました。
でも、現象は変わりませんでした。
$ 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 も最新バージョンを入れてみましたので、
その時の備忘録を以下にまとめます。
なお、今回使用した環境は次のとおりです。
また、以下のサイトを参考にしました。
- https://github.com/neutrinolabs/xrdp/wiki/Building-on-Debian-8
- https://gtrt7.com/blog/linux/ubuntu-16
- http://akira.matrix.jp/archives/972
手順: ※ 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 でインストールしました。
なお、「雑廉堂の雑記帳」さんのインストール手順を
参考させていただきました。
手順はざっくりと書くと、以下のとおりです。
- /etc/network/interfaces, /etc/hosts の編集
- ntp のインストール
- bind9 のインストール
- /etc/apparmor.d/usr.sbin.named の修正
- krb5-user のインストール
- 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 は、
- PC: VirtualBox 5.1 上の仮想PC
- OS: Ubuntu 16.04 LTS
- Web: apache 2.4 (ubuntu package でインストール)
- PHP: php 7.0 (ubuntu pacakage でインストール)
- SQL: MySQL 5.7 (ubuntu package でインストール)
- WordPress: 日本語版の最新バージョンを https://jp.wordpress.org からダウンロードしてインストール
です。
補足)
やり方(結果)だけを見たい方は、この記事の最後の方だけを読んでください。
途中は失敗談をずらずらと書いています。 f(^^;;;
=================< 失敗談 >==================
失敗1)
単純に My Web Server で Reverse Proxy の設定をしました。
としたのですが、HTML 以外のコンテンツ(画像とか)が全く表示されません。
ProxyRequests Off
ProxyPass "/blog/" "http://internal-wordpress-server.invalid/"
ProxyPassReverse "/blog/" "http://internal-wordpress-server.invalid/"
実際に、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 先生に教えを乞うたところ、
以下のサイトを紹介していただきました。
- https://fixture.jp/blog/2012/02/how-to-work-wordpress-with-reverse-proxy/
- https://blog.supersonico.info/?p=1367
実際に、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)
個人的に、Wordpress の PHP に設定以外の項目をごちゃごちゃ書くのは、
スマートではなく好みではない。
ので、
Google 先生に再度、
「HTTP のヘッダーだけでなく HTMLコンテンツも Reverse Proxy する方法はないの?」
と問い合わせてみました。
すると、Apache HTTPD 2.4 には mod_proxy_html があるよ
- https://httpd.apache.org/docs/2.4/mod/mod_proxy_html.html
- http://apache.webthing.com/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, brHTTP/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, brHTTP/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/
# /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/
# 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