Linux – 株式会社シーポイントラボ｜浜松のシステム開発会社

著者:takahashi

SystemdでNode.jsのサーバープログラムをお手軽にデーモン化する方法

以前SoftEtherVPNを手軽にSystemdでデーモン化する方法をご紹介しましたが、実は、最近よく使われるNode.jsで書いたサーバープログラムも、Systemdを使うと簡単にデーモン化できるようです。

centos7で標準のsystemdを使いnode.js製サーバーをデーモン化する – Qiita

Node.jsはjavascriptのサーバーサイド版の言語・実行環境で、ほぼjavascriptと同じ言語を使ってサーバー側の処理を書くことができます。
Node.jsのライブラリにも”forever”というプログラムをデーモン化してくれるライブラリがあるのですが、OS起動時と同時に実行させたりする際はちょっと不安が残ります。

起動時にうまくNode.js製のサーバーをデーモンとして動作させる方法がないか探したところ、なんとSystemdのみで実現できるとのことだったので、実際に試してみました。
nodeのプログラムをsystemdを使ってデーモン化するには、

/etc/systemd/system/デーモン名.service

のような名前でファイルを作り、下記のように設定を書き込みます。

[Unit]
Description=node server #任意の説明
After=syslog.target network.target

[Service]
Type=simple
ExecStart=/usr/bin/node /path/to/Node.jsProgramPath #記法:ExecStart=node.js本体のパス node.js向けに書いたサーバープログラムのパス
WorkingDirectory=/path/to/ #作業ディレクトリの場所(スクリプト実行時にカレントディレクトリになっていて欲しい場所)
KillMode=process
Restart=always
User=centos #node.jsプログラム実行ユーザー
Group=centos #node.jsプログラム実行ユーザー

[Install]
WantedBy=multi-user.target

上記のような内容でファイルを保存したら後はお決まりの

systemctl enable デーモン名
systemctl start デーモン名

これだけでnode.jsのプログラムがデーモン化され、OS起動時の自動起動にも登録されます。

Systemdはファイルの記法がわかりづらくて嫌煙されがちな印象でしたが、いろんなプログラムをいとも簡単にデーモン化できてしまうあたり、もしかするとかなり優秀なのかもしれません…

この記事いいね！ (0)

著者:takahashi

Ubuntuのアップグレード機能を使って、16.04から18.04へアップグレードしてみる。

久々に、UbuntuのOSアップグレードを試してみました。
今回は16.04から18.04へのアップグレードです。

インターネットにつながっていて、かつ最新のパッケージリストを取得できていれば、上のようなダイアログが出現するかと思います。
出現しない場合は、

sudo apt update

を実行してみてください。

(※アップグレードは失敗するとOSが壊れる可能性のある結構リスキーな操作です。PCの強制シャットダウンなどの不正操作を行わない限り基本的に壊れることはないとは思いますが、念のためアップグレード前にバックアップを取っておくことをお勧めします。)

Ubuntuのバージョンをアップグレードする場合は”いますぐアップグレードする”をクリックします。

管理者権限が必要となるので、sudoが使えるユーザーの認証情報を入力します。

リリースノート(英文)が表示されるので、内容を確認して”アップグレード”をクリックすると、アップグレード処理が開始されます。

サードパーティのリポジトリはすべて無効化されます。
自分でリポジトリを追加した場合は、アップグレード後に再度追加する必要があります。

最終確認が出てきます。
“アップグレードを開始”をクリックすると、新しいバージョンへの上書きが実行されます。

暫く待ちます。

アップグレード後に使用するディスプレイマネージャー(GUIの動作を管理するアプリケーション)を、従来のLightDMを使うかGDM(Gnome標準)に変更するか聞かれます。
18.04でのデフォルトはGDMですが、自分の場合LightDMを選択しました。
現時点では特に不具合は出ていないようですので、ここはお好みで選択しても大丈夫かと思います。（後から切り替えることもできます。詳しくは検索してみてください。）

18.04ではサポートされない古いパッケージ(アプリやライブラリなど)を削除するか聞かれます。
対象のパッケージが一覧で確認できるので、削除されても問題ないか確認して問題なければ”削除”を選択します。

すべて完了すると、再起動を促されるので必ず再起動をクリックします。

この時点で壁紙がすでに新しいバージョンのものに差し変わってますね。
気付きましたか？

再起動してログインすると、初期画面が表示されます。
画面に従って初期設定を進めていきます。

これで更新作業は完了です。

昔のUbuntuはアップグレードすると不具合が結構出ることもあったのですが、今回はアップグレードによって発生したと思われる目立った不具合は見つけていません。
CUIでの使用がメインというのもあるかもですが、安定性はどんどん上がっている気がしますね。

興味のある方は是非お試しください。

この記事いいね！ (0)

著者:takahashi

SystemctlでSoftEtherVPNをデーモン化する

SoftEtherVPNはたくさんの接続オプションを持っていて、無料のVPNサーバーソフトの中ではおそらく”最もつなげやすい”ソフトではないかなと思います。

そんなSoftEtherVPNですが、Linux版の場合はソースの状態で配布されており、各マシンにダウンロードしてからmakeでビルドする形になっています。
なのでmakeに必要なライブラリさえOS側で用意されていれば、ディストリビューションやアーキテクチャ関係なく使用することができるようになっています。

その関係か、パッケージにはデーモン化のスクリプトは含まれておらず、自力でデーモン化する必要があります。

といっても、作業自体は起動スクリプトを/etc/init.dに置いてchkconfigやsystemctlで有効化すだけです。
起動スクリプトはSoftEtherVPNの公式ドキュメントに記載されています。

#!/bin/sh
# chkconfig: 2345 99 01
# description: SoftEther VPN Server
DAEMON=/usr/local/vpnserver/vpnserver
LOCK=/var/lock/subsys/vpnserver
test -x $DAEMON || exit 0
case "$1" in
start)
$DAEMON start
touch $LOCK
;;
stop)
$DAEMON stop
rm $LOCK
;;
restart)
$DAEMON stop
sleep 3
$DAEMON start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
exit 0

ところが、今回Ubuntu 18.04のサーバーに組み込んだ所、うまく動作せず。
いろいろ調べたところ、SystemdのUnitファイルで動作させる方法があったのでこちらを試してみました。
（※管理者権限が必要です。）

Ubuntu上でSoftEther VPN Server構築 – Qiita

[Unit]
Description=SoftEther VPN Server
After=network.target network-online.target

[Service]
ExecStart=vpnserverがインストールされているパス/vpnserver start
ExecStop=vpnserverがインストールされているパス/vpnserver stop
Type=forking
RestartSec=3s

[Install]
WantedBy=multi-user.target

上記の内容でUnitファイルを作り、下記の場所に保存します。
/etc/systemd/system/vpnserver.service

保存したら次のコマンドを実行します。

systemctl daemon-reload

これで準備は完了いつも通りに起動します。

systemctl start vpnserver

これで起動したかと思います。
自動起動する場合は

systemctl enable vpnserver

も実行しておきます。

Systemdがいまいちわかりづらいのでinit.dを使っていましたが、これならsystemdネイティブでも使えそうです。
init.dスクリプトでうまく起動できない、という方はぜひ試してみてください。

この記事いいね！ (0)

著者:takahashi

Ubuntu 16.04 でLivePatch を有効化してみた。

Ubuntu 18.04 でGUI操作が可能になったCaconical LivePatchですが、コマンドラインであればUbuntu 16.04でも適用が可能になっています。
結構手間がかかるかなーという印象だったのですが、やってみたところとても簡単でした。

コマンドラインでLivePatchを有効化するには、UbuntuOneで発行できる専用のトークンが必要になります。

まず、Canonical Livepatch Serviceサイトにアクセスして、トークンを取得します。

サイトにアクセスしたら、無料ユーザーの場合は”Ubuntu User”を選択し、”Get Your LivePatch token”をクリックします。

ログイン画面が出てくるので、自分のUbuntuOneアカウント情報を入力してログイン。
UbuntuOneアカウントを持っていない場合は
”I don’t have an Ubuntu One account”
からアカウントを作成できます。

LivePatchは1アカウントにつき、3台のマシンまで無料利用可能となっているため、注意してください。

LivePatchのページでログインすると、こんな表示が出てきます。

一つ目の欄にあるランダムな文字列がトークンになります。

まず、LivePatchパッケージをインストールします。
端末(Terminal)で次のコマンドを入力します。

sudo snap install canonical-livepatch

LivePatchパッケージのインストールが始まるので、暫く待ちます。
完了したら次のようにコマンドを入力します。

sudo canonical-livepatch enable 先程のトークン

これでLivePatchが有効になるはずです。
念のため、ちゃんと動作しているか確認します。

出力された情報の中に

running: true

と表示されていれば有効になっています。

Ubuntu 16.04でもLivePatchを使用したいという方は、是非参考にしてみてください。

この記事いいね！ (0)

著者:takahashi

Ubuntu 16.04 apt update で noappstreamcliエラーが出たときの対策

久々にubuntu 16.04をマシンにインストールしていたのですが、パッケージの最新版を取るため apt update コマンドを管理者権限で実行したところ下記のエラーが…

# sudo apt update
ヒット:1 http://archive.ubuntulinux.jp/ubuntu xenial InRelease
ヒット:2 http://jp.archive.ubuntu.com/ubuntu xenial InRelease                  
無視:3 http://archive.ubuntulinux.jp/ubuntu-ja-non-free xenial InRelease       
ヒット:4 http://jp.archive.ubuntu.com/ubuntu xenial-updates InRelease          
ヒット:5 http://jp.archive.ubuntu.com/ubuntu xenial-backports InRelease        
ヒット:6 http://archive.ubuntulinux.jp/ubuntu-ja-non-free xenial Release       
ヒット:8 http://security.ubuntu.com/ubuntu xenial-security InRelease           
*** Error in `appstreamcli': double free or corruption (fasttop): 0x00000000010f7960 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f9809af1725]
/lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f9809af9f4a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f9809afdabc]
...

どうやら、”appstreamcli”というプログラムのバグが原因なようです。

Ubuntu 16.04のapt updateでappstreamcliがクラッシュする – グレインの備忘録

ちなみにこれ、自分が持っているLiveDVDでも同様の現象が起こるため、どうやら初期状態ですでに存在しているバグのようでした。
対処方法は上記の記事に記載されている方法をそのまま実行することで解消できました。

#appstreamを無効化
sudo killall -KILL apt.systemd.daily
sudo mv /etc/apt/apt.conf.d/50appstream /etc/apt/apt.conf.d/50appstream.disable
#apt update/upgrade
sudo apt update -y
sudo apt upgrade -y
#appstreamを有効化して再度update
sudo mv /etc/apt/apt.conf.d/50appstream.disable /etc/apt/apt.conf.d/50appstream
sudo apt update -y

実行結果

# sudo apt update

ヒット:1 http://archive.ubuntulinux.jp/ubuntu xenial InRelease
無視:2 http://archive.ubuntulinux.jp/ubuntu-ja-non-free xenial InRelease                                                                                                         
ヒット:3 http://archive.ubuntulinux.jp/ubuntu-ja-non-free xenial Release                                                                                                         
ヒット:5 http://security.ubuntu.com/ubuntu xenial-security InRelease                                                      
取得:6 http://security.ubuntu.com/ubuntu xenial-security/main amd64 DEP-11 Metadata [67.7 kB]  
取得:7 http://security.ubuntu.com/ubuntu xenial-security/main DEP-11 64x64 Icons [68.0 kB]   
取得:8 http://security.ubuntu.com/ubuntu xenial-security/restricted amd64 DEP-11 Metadata [200 B]
取得:9 http://security.ubuntu.com/ubuntu xenial-security/universe amd64 DEP-11 Metadata [107 kB]
取得:10 http://security.ubuntu.com/ubuntu xenial-security/universe DEP-11 64x64 Icons [142 kB]        
取得:11 http://security.ubuntu.com/ubuntu xenial-security/multiverse amd64 DEP-11 Metadata [212 B]
取得:12 http://security.ubuntu.com/ubuntu xenial-security/multiverse DEP-11 64x64 Icons [29 B]
ヒット:13 http://jp.archive.ubuntu.com/ubuntu xenial InRelease  
ヒット:14 http://jp.archive.ubuntu.com/ubuntu xenial-updates InRelease
ヒット:15 http://jp.archive.ubuntu.com/ubuntu xenial-backports InRelease
取得:16 http://jp.archive.ubuntu.com/ubuntu xenial/main amd64 DEP-11 Metadata [733 kB]
取得:17 http://jp.archive.ubuntu.com/ubuntu xenial/main DEP-11 64x64 Icons [409 kB]
取得:18 http://jp.archive.ubuntu.com/ubuntu xenial/restricted amd64 DEP-11 Metadata [186 B]
取得:19 http://jp.archive.ubuntu.com/ubuntu xenial/universe amd64 DEP-11 Metadata [3,410 kB]
取得:20 http://jp.archive.ubuntu.com/ubuntu xenial/universe DEP-11 64x64 Icons [7,448 kB]
取得:21 http://jp.archive.ubuntu.com/ubuntu xenial/multiverse amd64 DEP-11 Metadata [63.8 kB]
取得:22 http://jp.archive.ubuntu.com/ubuntu xenial/multiverse DEP-11 64x64 Icons [230 kB]
取得:23 http://jp.archive.ubuntu.com/ubuntu xenial-updates/main amd64 DEP-11 Metadata [320 kB]
取得:24 http://jp.archive.ubuntu.com/ubuntu xenial-updates/main DEP-11 64x64 Icons [231 kB]
取得:25 http://jp.archive.ubuntu.com/ubuntu xenial-updates/restricted amd64 DEP-11 Metadata [157 B]
取得:26 http://jp.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 DEP-11 Metadata [247 kB]
取得:27 http://jp.archive.ubuntu.com/ubuntu xenial-updates/universe DEP-11 64x64 Icons [333 kB]
取得:28 http://jp.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 DEP-11 Metadata [5,964 B]
取得:29 http://jp.archive.ubuntu.com/ubuntu xenial-updates/multiverse DEP-11 64x64 Icons [14.3 kB]
取得:30 http://jp.archive.ubuntu.com/ubuntu xenial-backports/main amd64 DEP-11 Metadata [3,328 B]
取得:31 http://jp.archive.ubuntu.com/ubuntu xenial-backports/main DEP-11 64x64 Icons [29 B]
取得:32 http://jp.archive.ubuntu.com/ubuntu xenial-backports/restricted amd64 DEP-11 Metadata [194 B]
取得:33 http://jp.archive.ubuntu.com/ubuntu xenial-backports/universe amd64 DEP-11 Metadata [5,100 B]
取得:34 http://jp.archive.ubuntu.com/ubuntu xenial-backports/universe DEP-11 64x64 Icons [1,789 B]
取得:35 http://jp.archive.ubuntu.com/ubuntu xenial-backports/multiverse amd64 DEP-11 Metadata [216 B]
取得:36 http://jp.archive.ubuntu.com/ubuntu xenial-backports/multiverse DEP-11 64x64 Icons [29 B]
13.8 MB を 5秒 で取得しました (2,654 kB/s)                    
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています       
状態情報を読み取っています... 完了
パッケージはすべて最新です。

この記事いいね！ (0)

著者:takahashi

再起動しなくてもUbuntu OSアップデートが自動適用できる！ “Canonical LivePatch”

今までOSのアップデートを適用する際、とくにカーネルのアップデートなどは必ず再起動が必要となっていました。
しかし、Linuxカーネル4.0からライブパッチ機能が正式に実装され、再起動を行うことなく更新が取り込めるようになりました。

Linux 4.0リリース候補版にライブパッチ機能が導入 – ZDNet Japan

しかし、この機能は飽くまで”カーネルに機能として存在している”形で、ユーザーが簡単に利用できるようになるかどうかはディストリビュージョン次第、となっています。

そんな中、UbuntuのCanonicalがUbuntu向けに”Canonical LivePatch”の提供を開始しました。

この機能はUbuntu16.04から利用可能となり、18.04からGUIインターフェースが用意され、インストール時やインストール後に、ユーザーが簡単に設定できるようになりました。(※Ubuntu Oneへの登録が必要。無料ユーザーは3マシンまで)
有効化方法などは下記のサイトを見ていただければ分かりやすいかと思います。

【Ubuntu18.04】新機能 LivePatchについて – ガジェット好きの日記

自分も自宅で仮想でサーバーマシンを動かしており、そのホストOSとしてUbuntuを利用しています。
ホストOSを再起動するためには、複数台動作している仮想OSをすべて停止しないといけないためかなり大変でした。

今回のLivePatchサービスのリリースで、再起動することなくセキュリティパッチの修正を受けられるのは非常にありがたいです。
ちなみに、適用するとSSHなどでログインした際に

このように表示され、正常に動作していることが確認できます。

この記事いいね！ (0)

著者:takahashi

Apacheをどう設定しても403になる時はSELinuxを疑え！

ここ最近、サーバーを構築する機会が何度かあったのですが、Apacheの構築中しばしば同じところでハマることがあったので備忘録。

Apacheでは通常、公開するディレクトリ(ドキュメントルートとするディレクトリ)のアクセス権限を下記のように与えてやれば、Webブラウザからのアクセスが可能になります。
例えば、

#2.2系
<Directory /var/www/html>
Order Deny,Allow
Deny from All
</Directory>
または
#2.4系
<Directory /var/www/html>
Require all granted
</Directory>

とすれば
/var/www/html
配下がアクセス可能になるはずです。
勿論、OS側のアクセス権限も調整する必要がありますが、Directoryディレクティブを設定し、なおかつOS側のファイルアクセス権限も問題ないはずなのに、ブラウザで開くと何故かステータスコード403(Forbidden)が返され、コンテンツが見えない、といった事情が起こりました。

ドキュメントルートのディレクトリよりもさらに上のディレクトリに、実行権限がついてるかどうかを確認したり、権限を一括で書き換えたりなど行いましたが、一向にアクセスできず。

いろいろ調べたところようやく原因に多とりつきました。

SELinuxです。

SELinuxはアクセス制御を行うモジュールで、米国NSAがオープンソースで提供しています。

非常に強力なのですが、サーバーのように一般的によくアクセスされる場合は障害になることも多いので、基本的には無効にします。
ただ最近は、インストール時に既に無効になっているものも多いのですが、今回使ったCentOSの場合はデフォルトで有効になっていたようで、SELinuxが動いていることに気づかずにそのまま作業してしまっていました。

SELinuxの設定の確認は

getenfotce

とすると確認ができます。

無効化すは

setenfotce 0

でできますが、これだけだとOSを再起動した際に復活してしまうので、

/etc/selinux/conf

の

SELINUX=enforcing

の記述を

SELINUX=permissive

に変更しておきます。
これで、再起動時もSELinuxが無効のままにしておくことができます。

なんど設定しなおしてもうまくいかない…!という方は一度SELinuxの設定を確認してみてください。

この記事いいね！ (0)

著者:takahashi

MariaDBでDBをテーブル単位で暗号化する方法

最近、何かと情報流出のニュースって多いですよね。
基本的にはサーバに不正侵入させないのが第一ではあるのですが、攻撃が巧妙化してくると、なかなか簡単には防御できないこともあり得ます。
そういう場合も想定して、万が一サーバに第三者が不正に侵入してきたときの保険として、データそのものを暗号化してしまう方法があります。

Webサービスなどでは、データの保存先としてよくデータベースを利用しますが、最近このDBエンジン自体が暗号化機能を持っているものが出てきました。

今回はMariaDBというMySQL互換のDBエンジンで暗号化設定をしてみました。
(使用OS:CentOS 7)

まずはmariaDBをインストールします。
mariaDB自体はCentOSのepelリポジトリにも存在しているのですが、実はepel版MariaDBはバージョン5系のものとなっており、暗号化がサポートされるのが10.1からとなっています。
そのため、公式リポジトリのMariaDBでは暗号化することができません。

バージョン10.1以上のMariaDBはMariaDB公式のリポジトリから入手できるので、今回はこちらを使います。

折角なら最新版をということで、現時点の安定板の最新版 v10.3 をインストールします。

sudo vi /etc/yum.repos.d/mariadb.repo

などどして、下記の内容でMariadbのリポジトリファイルを作成します。

# MariaDB 10.3 CentOS repository list - created 2018-07-04 11:06 UTC
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.3/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

ファイルを作成したらyumでmariadbをインストールします。

#MariaDBをインストール
sudo yum install MariaDB-server MariaDB-client

MariaDBを立ち上げる前に、暗号化の設定を先に行っておきます。
まずは暗号化に使うキーを生成します。

openssl enc -aes-256-cbc -k パスワード -P -md sha1

下記のような内容が表示されます。

salt=英数字
key=英数字
iv =英数字

新しくファイルを作成し、表示された英数字を次のように記載します。

暗号化・復号化する際の鍵番号(1以上の数字を任意に指定);ivの値;keyの値

鍵ファイルを暗号化します。

openssl enc -aes-256-cbc -md sha1 -k パスワード2 -in 先程つくった鍵ファイルのパス -out 暗号化後ファイルの保存先

/etc/my.cnf.d/server.cnf
を管理者権限で開き、[mysqld]セクションのすぐ下に、下記の設定を追記します。

plugin-load-add=file_key_management.so
file_key_management
file_key_management_filename = 先程作成した鍵ファイルのパス
file_key_management_filekey = 鍵ファイルにかけたパスワード
file_key_management_encryption_algorithm=AES_CBC

これで準備ができたので、早速MariaDBを立ち上げます。

sudo systemctl start mariadb #mariadb起動
sudo systemctl enable mariadb #mariadbの自動起動を有効化

これで暗号化が有効になったはずです。
それでは早速、暗号化されたテーブルを作ってみます。

CREATE DATABASE hoge;
use hoge;
CREATE TABLE test (id INT) ENCRYPTED=YES ENCRYPTION_KEY_ID=先程の鍵に指定した鍵id;

テーブルにデータを入れます。

#例
INSERT INTO hoge(id) VALUES (1);

この状態でselectをかけると通常通りデータが出力されますが、最初に編集した
/etc/my.cnf.d/server.cnf
の今回の変更部分をすべてコメントアウトした状態でmariaDBを再起動、再びhogeテーブルをSELECTすると…

ERROR 1932 (42S02): Table 'hoge.test' doesn't exist in engine

のように表示され、中のデータが見れなくなっていることがわかるかと思います。

このようにしておけば、MariaDBのデータ本体を抜かれても、キーファイルが漏れていても、そのパスワードが漏れなければデータの中身を見られる心配はありません。
ただし、/etc/my.cnf.d/server.cnfにパスワードを直書きしてしまっているので、このファイルを漏れないように気を配る必要はありそうです。

今回のMariaDBのように、暗号化する仕組みをはじめから備えていて、簡単に設定できる環境も増えてきています。
これからもし情報が洩れてはいけないようなサービスを作ろうと考えられている方がいましたら、是非参考になれば幸いです。

この記事いいね！ (0)

著者:takahashi

Ubuntu 18.04に xrdpをインストールしてみる

最近、サーバーOSとしてUbuntu 18.04をGUI付きで使い始めました。
SSHでCUI上でフルコントロールができるとはいえ、やはりリモートでGUIで操作したいときもたまにあります。(GUIアプリケーションの操作など)

そういう時にリモートからGUIを操作する手段はいくつかあるのですが、今回はXRDPという、Windowsのリモートデスクトップクライアントから接続できるようにする方法を試してみました。

まず、aptでxrdp本体をインストールします。

sudo apt install -y xrdp

Ubuntuの場合、基本的にこれだけで動作するのですが、このままだとログイン後にエラーが発生してうまくつながらないので、追加の設定を行います。

#new_cursorsの無効化
sudo sed -e 's/^new_cursors=true/new_cursors=false/g' \
 -i /etc/xrdp/xrdp.ini

#xrdpサービスの再起動
sudo systemctl restart xrdp

#xsessionファイルの作成
D=/usr/share/ubuntu:/usr/local/share:/usr/share:/var/lib/snapd/desktop
cat <<EOF > ~/.xsessionrc
 export GNOME_SHELL_SESSION_MODE=ubuntu
 export XDG_CURRENT_DESKTOP=ubuntu:GNOME
 export XDG_DATA_DIRS=${D}
 export XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg
EOF

#Authentication Requiredダイアログの回避
cat <<EOF | \
   sudo tee /etc/polkit-1/localauthority/50-local.d/xrdp-color-manager.pkla
 [Netowrkmanager]
 Identity=unix-user:*
 Action=org.freedesktop.color-manager.create-device
 ResultAny=no
 ResultInactive=no
 ResultActive=yes
EOF

sudo systemctl restart polkit

詳細についてはこちらを参照してください。
Ubuntu 18.04: GNOMEデスクトップ環境にXRDPで接続する – Narrow Escape

あとはWindowsのリモートデスクトップでWindowsに接続するのと同じ方法で接続します。