Ubuntu Server 20.04/Tomcat9でJenkinsインストール

Ubuntu Server 20.04 および Tomcat9 も動作し、GitBucket もインストールが完了したので、次のサーブレットとして Jenkins をインストールしようと思います。

Jenkins は Wikipedia の記載では、

Jenkins（ジェンキンス）はフリーでオープンソースの自動化サーバー

です。

イメージとしては、GitBucket に対してコミットしたファイル群から、様々な自動化処理を行ってくれるためのフレームワークといった所です。

Jenkinsのホームページから war ファイルがダウンロード可能で、同ファイルをデプロイすることで使用が可能です。

Jenkinsのインストール手順が書かれたページによると、

Jenkins can also be run as a servlet in different Java servlet containers such as Apache Tomcat or GlassFish. However, instructions for setting up these types of installations are beyond the scope of this chapter.

とのことで、一瞬、「ん？」と思えますが、手順は簡単なため、以下に手順として記載しておきます。

Jenkinsのサイトから war ファイルをダウンロード

これはそのまんまです。Jenkinsのダウンロードサイトからwarファイルをダウンロードします。なお Jenkins も LTS と最新の2種類が存在していますが、今回は LTS を使用することとします。現時点での最新版は Jenkins 2.249.3 LTS  みたいです。

なおどれが war ファイルのダウンロードなのか、少し分かりにくいです。ぱっと見た時、Ubuntu/Debian と書かれた所に目がいってしまいますが、左側の表の一番上の、少しごちゃごちゃと記載されているのが war ファイルとなります。なお左側がLTSを示しています。

tomcatサービスの停止

デプロイを安全に行うために一度tomcatを停止します。稼働させたままデプロイできるやもしれませんが、心配なので一旦停止します。

$ sudo systemctl stop tomcat9

tomcatのwebappにコピー

tomcatが停止したことを確認した後、tomcatのwebappフォルダにダウンロードしたwarファイルをコピーします。停止の確認は以下で可能です。ステータスが inactive であれば大丈夫です。

$ sudo systemctl status tomcat9

なおwebappフォルダは以下です。システム構成によっては違うかもしれませんが。

/var/lib/tomcat9/webapps

tomcatサービスの起動

warファイルをコピー後、tomcatを再稼働させます。これはstopと逆の操作です。

$ sudo systemctl start tomcat9

jenkinsへ1stアクセス

これで Jenkins のインストールが開始されます。無事に動作したかどうかは tomcat の manager 画面から確認出来ると思います。URLとしては、

http://localhost:8080/manager/html

とかになるかと思います（localhostの場合）。

ここでエラーなく Jenkins が稼働（Running が true）しているのを確認したら Jenkins のページにアクセスします。

http://localhost:8080/jenkins

ですね。

そうすると以下のUnlock画面が表示されます。

このページの意味は書かれている内容の通りですが、画面上に表示されている指定のファイルからパスワード文字列をコピーして入力欄に貼り付けて Continue です。

その後、無事に動作し、プラグインのインストール画面が表示されます。

水色で示されている Install suggested plugins をクリックします。

このように提案された各種プラグインのインストールが開始されます。

無事にインストールが終わるとFirst Admin User の登録画面が表示されます。

これで Save and Continue として進めると無事にJenkinsが開始されます。

webアプリケーションによるとは思いますが、いつもながら Jenkins のデプロイは楽ですね。開発者またユーザの皆様に感謝です。

実務側ではソフトウェアリポジトリへコミットされたソース群を Nightly で検証することをさせていますが、家のサーバですし、少し便利な使い方を考えてみたいと思います。

もしかしたら「それ、cronで出来るやん」という使い方だけで終わるかもしれませんが。。。

HomeServer / 気がつくと Gnome Desktop が...

 最近稼働中の HomeServer ですが、元々 Ubuntu Server 20.04 として GUI なし CUI ベースで導入していたのですが、今しがたリモートログインして top を見てみると、Xサーバが稼働していることに気づきました...

うーんです...

前に本サーバからメインの開発PCにリモートで色々とXアプリケーションをとばして表示させようとしていたのですが、その時、うっかりと導入してしまった模様です。

gnome-shellも動いてますね。

基本サーバマシンであり低消費電力で連続動作させたいってのがありますので、このデスクトップ環境は停めたいなと思いますね。

また、まだサーバの方、電力制御の設定を行っていないので、低電力化の設定としてまとめて次は行いたいと思います。

それを進めるには CPU のモードや BIOS 機能など、色々とハード側の確認が必要な気がしますので、そちらについては本ブログの兄弟であるハードウェア関係のブログ記事に書いていこうかと思います。

Ubuntu Server 20.04/Tomcat9/GitBucketでMySQL

前回の記事で Ubuntu Server 20.04/tomcat9上でGitBucketが動作する所までは対応しました。

GitBucketはデフォルトで H2 Database を使用しています。

開発元が公式に

「H2はデータの保全性に問題がありますので業務等の重要な用途にGitBucketを使われるのであればなるべくPostgreSQLもしくはMySQLを利用することが望ましいです（パフォーマンス面でもメリットがあります）」

と説明されていますので、今回、MySQLに変更することにしました。

なお前の Ubuntu 18.04 の時も MySQL を使用していました。基本的な内容は同じです。細かな部分については前の記事の方が詳しいので、そちらを参考にしてください。大枠としては 20.04/Tomcat9 での動作確認の意味でこちらの記事を参照してください。

• GitBucket の設定 / データベース (1)
• GitBucket の設定 / データベース (2)

MySQL を Ubuntu Server 20.04 の標準リポジトリからインストールすると、本記事作成時点では、バージョン 8.0.22 がインストールされます:

$ mysql --version
mysql  Ver 8.0.22-0ubuntu0.20.04.2 for Linux on x86_64 ((Ubuntu))

これを使うことにします。

GitBucket 側の設定方法は公式Wikiの External database configuration に説明が記載されています。

ほぼその通りにすれば出来るのですが、注意点としては、

• mysqlのバージョンが8以上なので、上記ページ記載の MySQL8 以上への対応が必要
• 説明されている grant all privileges on ... のコマンド一文が MySQL8 ではエラーとなるため、ユーザ作成と grant を別コマンドで実行

があるかなと思います。

無事に稼働すると、以下のように外部データベースで無事に接続出来ていることが確認出来ます。

色々とスムーズに導入できるので、開発者の方やこれまでの多くのユーザさんに感謝です。

これで信頼性を確保し導入が容易なGitリポジトリが実現出来ました。

あと気になる所はデータバックアップですね。

次はデータバックアップの設定を行いたいと思います。

ただバックアップからの復帰確認は、するかしないか、少し悩んでいます。

ちょっとした手間＋リスクですしね。

そもそも自分ローカルのネットワーク内でどこでも作業可能とし、色々な開発リソースの置き場を一元化することを主目的に導入したものであるため、とりあえずバックアップが取れて、そこに必要なデータが入っていることが確認出来たら、それ以上は確認しないかもしれません。

Ubuntu Server 20.04/Tomcat9でGitBucketインストール

現在、Ubuntu 20.04 Server のサーバマシン上で Tomcat9 を動かしています。

なおJavaは OpenJDK 14 を使用しています。

サーバマシンのハードウェア詳細については、別のブログに記載しています（書きかけのため公開していない記事も多いので、色々と前後していますが）。 

同サーバ上で稼働させるサーバとしてはGitサーバとCMSサーバを予定しています。

両者共にJavaサーブレットとしての実現を考えており、まずはGitサーバとして以前から愛用している GitBucket を導入しました。

インストールの方、ざっくりとは同じやり方で問題ないかとは思いますが、ちょっとだけ Tomcat9 へのデプロイ時にエラーでごたごたしましたので、記録としてメモしておきます。

なお基本的なデプロイの方法についてはGitBucketのインストールページの「Deployment to JEE and Servlet containers」に紹介されていますが、Tomcat9 の所は ToDo となっています。

インストール時のごたごた、具体的にはデプロイに失敗する（falseとなる）はインストール手順どうこうというよりは、こちらのTomcat9 側の基本設定に依存する内容かな、と思いますので、参考までに情報を列挙する形で上げておきます。

• Tomcat が使用する Java環境としては Ubuntu 20.04 Server の通常リポジトリから OpenJDK14 をインストール
• Ubuntu 20.04 Server の通常リポジトリから Tomcat9 をインストール
• インストールによりユーザ tomcat が自動生成されるが、ホームディレクトリが設定されていないため設定
• /home/tomcat をmkdirし、/etc/passwdのtomcatユーザの設定箇所に /home/tomcat を追加
• chown tomcat:tomcat /home/tomcat によりオーナを tomcat に
• GitBucket のサイトから gitbucket.war をダウンロードし、Tomcat の管理画面 (TomcatのURL/manager/html ）の「サーバ上のWARファイル又はディレクトリの配備」の[WARファイル又はディレクトリのURL:] でファイル位置を指定してデプロイ (配置)

です。

僕がミスしていた所は上記で chown を忘れ root アクセス権のままで、gitbucket をデプロイする際に同ディレクトリ下にファイル等を生成出来ないためでした。

これで無事に起動しました。tomcatの管理画面上ではこのようになっています。

また GitBucket 側の管理画面上ではこのようになっています。

上述のような素の設定下では GITBUCKET_HOME は自動的に /home/tomcat/.gitbucket となる模様です。

なおいつもデプロイ直後に「どうだったっけ？」と悩む管理者の初期情報ですが、GitBucketのページの Installation に記載されている以下の情報ですね。

• Download the latest gitbucket.war from the releases page and run it by java -jar gitbucket.war.
• Go to http://[hostname]:8080/ and log in with ID: root / Pass: root.

これで無事Gitサーバは起動しました。

次は上記の管理画面に記載されているデータベースの変更を行おうと思います。

Google Noto Fonts

家で仕事をする中でドキュメントを書くことが多いのですが、色々とフォントのことが気になります。

ちょっと Unicode 全般について勉強する必要も出てきてて、出来るだけ多くの文字が、豆腐文字になることなく表示できるフォントを探してます。

そのまさに「NO more TOfu」となるフォントがGoogle Noto Fontsの様です。

この Google Noto Fonts をメインマシン(Ubuntu 18.04)に入れてみようと思います。

Google Noto Fonts の入手

Google Noto Fonts は以下のサイトから入手可能です。

Google Noto Fonts/Beautiful and free fonts for all languages

ページ上の [DOWNLOAD ALL FONTS] ボタンをクリックするとダウンロードが始まります。

ダウンロードボタンの下に書いてある通り1.1GBもあるフォントセットです。

Google Noto Fonts のインストール

インストールは上記ページの[Install]の所の説明の通りです。

How to install fonts

Windows/macOS/Linuxでのインストール方法の説明がのっています。

僕は Ubuntu18.04 なので Linux インストールなのですが、「for a single user」か「for all users」かの選択肢があります。

どちらにしようか悩みましたが「for all users」にしておこうかと思います。

その手順は以下の様です。

# for all users
sudo mkdir -p /usr/share/fonts/opentype/noto
sudo cp *otf *otc /usr/share/fonts/opentype/noto
sudo fc-cache -f -v # optional

ちょっと2つ目のコマンドが正常動作しないので、以下としました。

sudo cp *.otf  /usr/share/fonts/opentype/noto

そして fc-cache をして終了です。

notoフォントとして 137フォント が取り込まれてますね。

/usr/share/fonts/opentype/noto: caching, new cache contents: 137 fonts, 0 dirs

TeX Live 2020 での LuaLatex エンジン

前の記事 で、TeX Live 2020 は 2019 から対して変わってないのでは、みたいなことを書きましたが、 ちょっと使ってみて、それなりに大きな違いが発生していることに気が付きました。

僕はpdfの直接的な生成を考えて LuaLatex を、Eclipse上のTeXLipseで使っています。

TeXLipse上での実行時にコンソールに表示される最初のメッセージは、これまで、

running: /usr/local/texlive/2019/bin/x86_64-linux/lualatex -synctex=1 -interaction=nonstopmode document.tex 
lualatex> This is LuaTeX, Version 1.10.0 (TeX Live 2019) 

だったのですが、TeX Live 2020 に変えると、

running: /usr/local/texlive/2020/bin/x86_64-linux/lualatex -synctex=1 -interaction=nonstopmode document.tex 
lualatex> This is LuaHBTeX, Version 1.12.0 (TeX Live 2020) 

となっていることに気が付きました。

これまではLuaTeXベースだったのが TeX Live 2020 からは LuaHBTeXベースになったのですね。

LuaHBTeXは前にLuaTeXについて調べた時に存在は知っていたのですが、HarfBuzzライブラリを組み込んだLuaTeXのことみたいです。

HarfBuzzライブラリとは、フリーのOpenTypeテキストシェーピングエンジン(フォントレンダリングエンジン)みたいです。

ここが開発元で Android, Chrome, ChromeOS, Firefox, OpenJDK, Qt 等にも使われているみたいです。

TeX Live 2020 から変更されたことの情報源を探していたのですが、 LATEX News/Issue 31, February 2020 に記載がありました。

Concerning this release . . . (LuaLATEX engine) The new LuaHBTEX engine is LuaTEX with an embedded HarfBuzz library. HarfBuzz can be used by setting a suitable renderer in the font declaration. A basic interface for that is provided by fontspec. This additional font renderer will greatly improve the shaping of various scripts when using LuaLATEX, many of which are currently handled correctly only by X TEEX, which always uses HarfBuzz. To simplify testing of the new engine, binaries have already been added to MiKTEX and TEX Live 2019 and both distributions have already now changed the LuaLATEX-dev format to use it. Going forward, LuaLATEX (and LuaLATEX-dev) will both use the LuaHBTEX engine. The timing of the switch to the LuaHBTEX engine depends on the distribution you use (for TEX Live this will be with TEX Live 2020).

とのことです。

TeX Live 2020 のインストール

TeX Live 2020 がリリースされました。

TeX Liveは常時updateされているため、2020リリースの目玉となる特徴とかあるのか分かりませんが、 既にTeX Live 2019でのupdateが止まっているため、2020を入れてみようと思います。

プラットフォームはいつもながらの Ubuntu 18.04 です。

TeX Live 2020 のインストール

リリースの ダウンロードページ から install-tl-unx.tar.gz をダウンロードし、tar.gz を展開して出来る install-tl を実行することで、後は自動的にインストールされます。

sudo ./install-tl 
Loading http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet/tlpkg/texlive.tlpdb
Installing TeX Live 2020 from: http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet (verified)
Platform: x86_64-linux => 'GNU/Linux on x86_64'
Distribution: net  (downloading)
Using URL: http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet
Directory for temporary files: /tmp/aiomRbLkQx

======================> TeX Live installation procedure <=====================

======>   Letters/digits in <angle brackets> indicate   <=======
======>   menu items for actions or customizations      <=======

 Detected platform: GNU/Linux on x86_64
 
 <B> set binary platforms: 1 out of 16

 <S> set installation scheme: scheme-full

 <C> set installation collections:
     40 collections out of 41, disk space required: 6524 MB

 <D> set directories:
   TEXDIR (the main TeX directory):
     /usr/local/texlive/2020
   TEXMFLOCAL (directory for site-wide local files):
     /usr/local/texlive/texmf-local
   TEXMFSYSVAR (directory for variable and automatically generated data):
     /usr/local/texlive/2020/texmf-var
   TEXMFSYSCONFIG (directory for local config):
     /usr/local/texlive/2020/texmf-config
   TEXMFVAR (personal directory for variable and automatically generated data):
     ~/.texlive2020/texmf-var
   TEXMFCONFIG (personal directory for local config):
     ~/.texlive2020/texmf-config
   TEXMFHOME (directory for user-specific files):
     ~/texmf

 <O> options:
   [ ] use letter size instead of A4 by default
   [X] allow execution of restricted list of programs via \write18
   [X] create all format files
   [X] install macro/font doc tree
   [X] install macro/font source tree
   [ ] create symlinks to standard directories

 <V> set up for portable installation

Actions:
 <I> start installation to hard disk
 <P> save installation profile to 'texlive.profile' and exit
 <H> help
 <Q> quit

TeX Liveはパッケージ数が多いので、ダウンロード・インストール完了まで結構時間がかかります。

実際、3986パッケージのダウンロードにほぼ1時間かかりました。

ダウンロードサイトの帯域が狭い気はしますが、通常のupdate時も相応の時間がかかるので、最近はあまり気にしていません。

ざっと下のような感じでした。

Installing [3981/3986, time/total: 01:04:20/01:04:22]: zref [684k]
Installing [3982/3986, time/total: 01:04:21/01:04:22]: zwgetfdate [242k]
Installing [3983/3986, time/total: 01:04:21/01:04:22]: zwpagelayout [630k]
Installing [3984/3986, time/total: 01:04:22/01:04:22]: zxjafbfont [3k]
Installing [3985/3986, time/total: 01:04:23/01:04:23]: zxjafont [181k]
Installing [3986/3986, time/total: 01:04:23/01:04:23]: zxjatype [144k]

インストール後のファイルサイズはざっと7GBほどみたいですね。 インストール後に一度、既存のTeXドキュメントを lualatex でビルドしたので、 もしかしたらその際に生成されたファイルも含めてなのかもしれませんが、そのぐらいのサイズは必要となる模様です。

$ du -s /usr/local/texlive/2020/
6927572 /usr/local/texlive/2020/

Ubuntu 18.04 での POCO C++ Libraries 構築 (1)

POCO C++ Libraries

POCO C++ Libraries とは C++ ベースでのネットワークアプリケーションやインターネットアプリケーションを開発するためのオープンソースのクロスプラットフォームライブラリです。以下のサイトで公開されています（画像をクリックすると開発元のホームページにジャンプします）：

デスクトップやサーバ、IoTデバイスや組込みシステムまでの適用が想定されているライブラリであり、 Boost Software License として公開されています。

その特徴は開発元の 「Features」 に示されています。

国内ではサイト「POCO Fanatic」 に色々と詳しい情報が掲載されています。

2018年以降は更新されてないみたいで、POCOのv1.8.1までの話しがのっています。

なお POCO の最新バージョンは 1.10.1 (2020-02-10) みたいです。

今回、ちょっと作りたいものがあって C++ での webフレームワークみたいなのを探していたのですが、 この POCO がひっかかりまして、少し試してみたいと思っています。

Ubuntu 18.04 でのライブラリ構築

僕の開発用メインマシンは Ubuntu 18.04 なので、その上での開発環境整備を進めたく思います。

POCOのダウンロードページ に行くとダウンロード情報が載っていますが、今回は、 COMPLETE EDITION (全てのライブラリが含まれているが外部ライブラリとして OpenSSL, MySQLクライアント, ODBCライブラリが必要) で進めてみようと思います。

まずは同ページにある poco-1.10.1-all.tar.gz をダウンロードして展開します。

そこに README ファイルがあり、そこにインストール方法が書かれています。

Linux では cmake でのインストールか configure でのインストールとの 2者があるみたいです。

今回は Windows 上でもビルドが可能である cmake で試してみようと思います。

Ubuntu 18.04 での cmake ビルド

READMEファイル上の記載では以下のように進めるとのことです。

1. create a cmake-build directory (e.g. in the POCO root directory):
$ mkdir cmake-build

2. and run CMake from there:
$ cd cmake-build
$ cmake ..
$ make -s -j (or build the generated Visual Studio solution on Windows)

今回はこの通りにすすめてみようと思います。

cmake ..の所までは進めたのですが、そこで以下のメッセージが表示されていました:

-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR 
(missing: OPENSSL_CRYPTO_LIBRARY OPENSSL_INCLUDE_DIR) 
-- Could NOT find APR (missing: APR_INCLUDE_DIR APR_LIBRARY) 
-- Could NOT find APRUTIL (missing: APRUTIL_INCLUDE_DIR APRUTIL_LIBRARY) 
-- Could NOT find Apache2 (missing: APACHE2_INCLUDE_DIR) 
-- Could NOT find MYSQL (missing: MYSQL_INCLUDE_DIR MYSQL_LIBRARY) 
-- Could NOT find PostgreSQL (missing: PostgreSQL_LIBRARY PostgreSQL_INCLUDE_DIR) 
-- Could NOT find ODBC (missing: ODBC_LIBRARY ODBC_INCLUDE_DIR) 

開発マシンとして色々と開発用ライブラリは入れてきましたが、まだまだ入っていないものが多いのですね。。。

ざっとネットで検索して以下のパッケージを追加でインストールしました。わかり易く apt install での インストールパッケージ表現で記載しておきます。

sudo apt install openssl-dev libssl-dev libapr1-dev libaprutil1-dev apache2-dev libmysqlclient-dev libpq-dev unixodbc-dev

これで cmake を無事に通りました。その時の表示を参考までに以下に掲載しておきます。

~/POCO/poco-1.10.1-all/cmake-build$ cmake ..
-- Checking for C++14 compiler
-- Checking for C++14 compiler - available
-- Found ODBC: /usr/lib/x86_64-linux-gnu/libodbc.so  
-- Building without tests & samples
-- Using internal sqlite, zlib, pcre, expat, ...
-- SQLite Support Enabled
-- MySQL Support Disabled
-- PostgreSQL Support Disabled
-- ODBC Support Disabled
-- CMake 3.10.2 successfully configured Poco using Unix Makefiles generator
-- Poco package version: 1.10.1
-- Building dynamic libraries
-- [cmake] Installation target path: /usr/local
-- [cmake] Bulid for OS type:  Linux
-- [cmake] Build for OS version: 5.3.0-46-generic
-- [cmake] Build for CPU type:  x86_64
-- [cmake] Build type:    RelWithDebInfo
-- [cmake] Build with cxx flags: -O2 -g -DNDEBUG 
-- [cmake] Build with c flags:  -O2 -g -DNDEBUG 
-- Building: Encodings
-- Building: XML
-- Building: JSON
-- Building: Util
-- Building: Net
-- Building: MongoDB
-- Building: Redis
-- Building: Data
-- Building: Zip
-- Building: PageCompiler
-- Building: File2Page
-- Configuring done
-- Generating done
-- Build files have been written to: ~/POCO/poco-1.10.1-all/cmake-build

無事に cmake が通ったので make でビルドを行わせました。

make の -j オプションということもありますが、途中、結構メモリを使用するみたいです。

途中の様子は以下のパフォーマンスモニタの通りです。

途中でメモリ使用量が30%から90%まで一気に増えていきました。

開発マシンのメモリ搭載量は16GBで、その60%を使うみたいなので、さっくりと10GBぐらいはメモリを消費する形でしょうか。

ただ、そのぐらいまでは一気にメモリを使いますが、それ以降は一つずつライブラリのビルドが行われていましたので、 メモリ使用量は増えず、数分程度でエラーなくビルドが完了しました。

これで無事にライブラリが生成出来たようなので次回は色々と使って試してみるのと、ライブラリの内部調査もしてみようかと思います。

それで現在作ろうとしているものに使えそうと判断したら、少しずつその開発を進めたく思います。

TeX Live 2020

自分は TeX Live 使いでして、主に Ubuntu 18.04 上で個別に TeX Live 2019 を入れて使っています。
update は適宜 tlmgr を使って手動で実施しているのですが、昨夜、update しようとして全くアップデートがないことに気づき、同時に以下のメッセージに気づきました：

TeX Live 2019 is frozen forever and will no
longer be updated.  This happens in preparation for a new release.

カレンダーイヤー毎でフリーズする有意性は把握出来ていませんし、リポジトリの指定等で継続的なアップデートが出来るのかもしれませんが、TeX Live のホームページ上に以下のリリーススケジュールが記載されていることが分かりました。なお日付の表示はわかり易く変更しています：

Plan for TeX Live 2020:

2月15日: candidate/final sources committed, test builds begin.

2月28日: tlnet (and TL'19) frozen, tlpretest starts, CTAN updates continue there.

３月15日: code freeze for final build, major bug fixes only.

3月22日: final updates from CTAN, final doc tweaks.

３月29日: deliver TL image for TeX Collection packaging/testing.

4月5日: deliver TeX Collection DVD image for manufacturing.

4月10日: public release (also of MacTeX).

6月?: delivery of DVDs to members.

これを見るとカレンダーイヤーよりファイナンシャルイヤー（年度）のリリースと思った方が良さそうですね。

年度が変わる頃までには、TeX Live 2020 を新たにインストールするのか、TeX Live 2019 を継続的にアップデートし続ける方法があるのか、調べておきたく思います。

GEM5 の評価 (2) / ビルドエラーへの対応

前回の記事で gem5 のビルドで幾つか問題が発生しました． 今回は，それらを順番に解決していこうと思います．

プロトコルバッファパッケージの追加

一つ目は以下の警告メッセージです:

Warning: Protocol buffer compiler (protoc) not found.
         Please install protobuf-compiler for tracing support.

Ubuntu Bionic の Protocol Buffer パッケージは ここ に詳細が記載されている通り，幾つかの関連パッケージが存在します． 今回はとりあえず以下を入れてみました．

$ sudo apt install protobuf-compiler libprotoc-dev libprotobuf-dev 
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています                
状態情報を読み取っています... 完了
以下の追加パッケージがインストールされます:
  libprotoc10
以下のパッケージが新たにインストールされます:
  libprotobuf-dev libprotoc-dev libprotoc10 protobuf-compiler
アップグレード: 0 個、新規インストール: 4 個、削除: 0 個、保留: 0 個。
2,231 kB のアーカイブを取得する必要があります。
この操作後に追加で 15.8 MB のディスク容量が消費されます。
続行しますか? [Y/n] 
取得:1 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 libprotoc10 amd64 3.0.0-9.1ubuntu1 [566 kB]
取得:2 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 libprotobuf-dev amd64 3.0.0-9.1ubuntu1 [959 kB]
取得:3 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 libprotoc-dev amd64 3.0.0-9.1ubuntu1 [682 kB]
取得:4 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 protobuf-compiler amd64 3.0.0-9.1ubuntu1 [24.5 kB]
2,231 kB を 5秒 で取得しました (432 kB/s)    
以前に未選択のパッケージ libprotoc10:amd64 を選択しています。
(データベースを読み込んでいます ... 現在 575503 個のファイルとディレクトリがインストールされています。)
.../libprotoc10_3.0.0-9.1ubuntu1_amd64.deb を展開する準備をしています ...
libprotoc10:amd64 (3.0.0-9.1ubuntu1) を展開しています...
以前に未選択のパッケージ libprotobuf-dev:amd64 を選択しています。
.../libprotobuf-dev_3.0.0-9.1ubuntu1_amd64.deb を展開する準備をしています ...
libprotobuf-dev:amd64 (3.0.0-9.1ubuntu1) を展開しています...
以前に未選択のパッケージ libprotoc-dev:amd64 を選択しています。
.../libprotoc-dev_3.0.0-9.1ubuntu1_amd64.deb を展開する準備をしています ...
libprotoc-dev:amd64 (3.0.0-9.1ubuntu1) を展開しています...
以前に未選択のパッケージ protobuf-compiler を選択しています。
.../protobuf-compiler_3.0.0-9.1ubuntu1_amd64.deb を展開する準備をしています ...
protobuf-compiler (3.0.0-9.1ubuntu1) を展開しています...
libprotobuf-dev:amd64 (3.0.0-9.1ubuntu1) を設定しています ...
libc-bin (2.27-3ubuntu1) のトリガを処理しています ...
man-db (2.8.3-2ubuntu0.1) のトリガを処理しています ...
libprotoc10:amd64 (3.0.0-9.1ubuntu1) を設定しています ...
protobuf-compiler (3.0.0-9.1ubuntu1) を設定しています ...
libprotoc-dev:amd64 (3.0.0-9.1ubuntu1) を設定しています ...
libc-bin (2.27-3ubuntu1) のトリガを処理しています ...

tcmallocライブラリのインストール(libgoogle-perftools-dev)

ビルド途中で以下のメッセージが出ています:

You can get a 12% performance improvement by installing tcmalloc (libgoogle-perftools-dev package on Ubuntu or RedHat).

エラーや警告ではなく Suggest ですが，google-perftools の tcmalloc を使うと性能が12%は向上するとのことです． 試しに入れてみたいと思います．導入はメッセージ通りに以下で行います．

$ sudo apt install libgoogle-perftools-dev
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています                
状態情報を読み取っています... 完了
以下の追加パッケージがインストールされます:
  libgoogle-perftools4 liblzma-dev libtcmalloc-minimal4 libunwind-dev
提案パッケージ:
  liblzma-doc
以下のパッケージが新たにインストールされます:
  libgoogle-perftools-dev libgoogle-perftools4 liblzma-dev
  libtcmalloc-minimal4 libunwind-dev
アップグレード: 0 個、新規インストール: 5 個、削除: 0 個、保留: 0 個。
1,053 kB のアーカイブを取得する必要があります。
この操作後に追加で 8,826 kB のディスク容量が消費されます。
続行しますか? [Y/n] 
取得:1 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 libtcmalloc-minimal4 amd64 2.5-2.2ubuntu3 [91.6 kB]
取得:2 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 libgoogle-perftools4 amd64 2.5-2.2ubuntu3 [190 kB]
取得:3 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 liblzma-dev amd64 5.2.2-1.3 [145 kB]
取得:4 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 libunwind-dev amd64 1.2.1-8 [423 kB]
取得:5 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 libgoogle-perftools-dev amd64 2.5-2.2ubuntu3 [204 kB]
1,053 kB を 10秒 で取得しました (102 kB/s)       
以前に未選択のパッケージ libtcmalloc-minimal4 を選択しています。
(データベースを読み込んでいます ... 現在 575702 個のファイルとディレクトリがインストールされています。)
.../libtcmalloc-minimal4_2.5-2.2ubuntu3_amd64.deb を展開する準備をしています ...
libtcmalloc-minimal4 (2.5-2.2ubuntu3) を展開しています...
以前に未選択のパッケージ libgoogle-perftools4 を選択しています。
.../libgoogle-perftools4_2.5-2.2ubuntu3_amd64.deb を展開する準備をしています ...
libgoogle-perftools4 (2.5-2.2ubuntu3) を展開しています...
以前に未選択のパッケージ liblzma-dev:amd64 を選択しています。
.../liblzma-dev_5.2.2-1.3_amd64.deb を展開する準備をしています ...
liblzma-dev:amd64 (5.2.2-1.3) を展開しています...
以前に未選択のパッケージ libunwind-dev:amd64 を選択しています。
.../libunwind-dev_1.2.1-8_amd64.deb を展開する準備をしています ...
libunwind-dev:amd64 (1.2.1-8) を展開しています...
以前に未選択のパッケージ libgoogle-perftools-dev を選択しています。
.../libgoogle-perftools-dev_2.5-2.2ubuntu3_amd64.deb を展開する準備をしています ...
libgoogle-perftools-dev (2.5-2.2ubuntu3) を展開しています...
libtcmalloc-minimal4 (2.5-2.2ubuntu3) を設定しています ...
libgoogle-perftools4 (2.5-2.2ubuntu3) を設定しています ...
libc-bin (2.27-3ubuntu1) のトリガを処理しています ...
man-db (2.8.3-2ubuntu0.1) のトリガを処理しています ...
liblzma-dev:amd64 (5.2.2-1.3) を設定しています ...
libunwind-dev:amd64 (1.2.1-8) を設定しています ...
libgoogle-perftools-dev (2.5-2.2ubuntu3) を設定しています ...

なお google perftools は このGitHubサイト がメインメージのようです．説明には以下とかかれています.

gperftools

----------

(originally Google Performance Tools)

The fastest malloc we’ve seen; works particularly well with threads and STL. Also: thread-friendly heap-checker, heap-profiler, and cpu-profiler.

なお tcmalloc をインストール後に再ビルドをかける場合には， build フォルダを削除 (rm -r build)する必要があるみたいです． 僕の再ビルドした際にやはり見つからないという状況が発生しました． この記事によると キャッシュされたコンフィグレーションを削除 する必要があるみたいですね．

C++でのコンパイルエラー

今回のコンパイルを失敗させている要因は以下のコンパイルエラーです:

build/ARM/arch/arm/generated/exec-ns.cc.inc:220634:39: error: '~' on an expression of type bool [-Werror=bool-operation]
                 destElem = srcElem1 & ~srcElem2;
                                       ^~~~~~~~~
build/ARM/arch/arm/generated/exec-ns.cc.inc:220634:39: note: did you mean to use logical not ('!')?
cc1plus: all warnings being treated as errors

なお使用しているコンパイラは gcc で，バージョンは以下です:

$ gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

エラーが発生している exec-ns.cc.inc ファイルは以下のログ表示で示されている通りに main.isaから自動生成されたファイルであり， その行数は250000行程度あります．ファイルが大きいこと，また自動生成されているということもあり， 今後のupdateやrebuildのことを考えると，このファイルを修正することは適切ではないと考えられます．

[ISA DESC] ARM/arch/arm/isa/main.isa -> generated/decoder-g.cc.inc, generated/decoder-ns.cc.inc, generated/decode-method.cc.inc, generated/decoder.hh, generated/decoder-g.hh.inc, generated/decoder-ns.hh.inc, generated/exec-g.cc.inc, generated/exec-ns.cc.inc, generated/max_inst_regs.hh, generated/decoder.cc, generated/inst-constrs-1.cc, generated/inst-constrs-2.cc, generated/inst-constrs-3.cc, generated/generic_cpu_exec_1.cc, generated/generic_cpu_exec_2.cc, generated/generic_cpu_exec_3.cc, generated/generic_cpu_exec_4.cc, generated/generic_cpu_exec_5.cc, generated/generic_cpu_exec_6.cc

ネット上で色々と調べましたが，実は gcc7,gcc8 等で発生するコンパイルエラーには既に対応しているみたいです (この記事等)． はて，と思いつつ，今回ソフトウェアを導入したリポジトリが良くなかったのかもしれません． Mercurial でリポジトリ http://repo.gem5.org/gem5 をコピーしましたが，git のリポジトリ https://gem5.googlesource.com/public/gem5 の方が 適切なのかもしれません．git リポジトリの方が「Official git repository」と位置づけられていますし．

そのため，Mercurial のリポジトリはやめて googlesource.com の git リポジトリで試してみることにしました．

それについては次回報告します．

【補足】sconsでの並列ビルド

気づいたのですが scons は複数ジョブでの並行ビルドを行うためのオプション -j がある模様です． 現在ビルドを行っているマシンは 物理コアを8個ほど積んでいるマシンのため， 4並列ジョブでビルドしようと思います．

どんな感じになるか少し試してみようと，実際に再ビルドを行ってみた際のパフォーマンスモニタ画面が以下です． 4並列でジョブが動作しているのが見て取れる(負荷率がほぼ100%のコアが4つ）と思います．

次回，gitリポジトリで再構築を試みる際には並列ビルドで実施しようと思います．

BaseX (2) / Servlet としての deploy

BaseX のサービス化

BaseX はデータベースであるためサービスとして運用しておきたいという希望があります． サービスとして常時起動させておくための方法には幾つかありますが，自分の運用環境には Tomcat が導入されており，様々な Servlet を導入しています． BaseX も Servlet としてのモジュール化がなされているため， Tomcat 上での Servlet として起動したく思います．

BaseX war のダウンロード

Ubuntu上では apt install basex で標準の BaseX を導入可能ですが， せっかく Tomcat 上で起動・管理することもあり，最新の BaseX を導入したく思います．

Servlet のモジュールとなる warファイル は BaseX のダウンロードサイト から入手可能です．

このページの一番右にある Web Archive と書かれたものが該当の Servlet となります． 僕がダウンロードした際の最新は画面の通り 9.2.2 です．

Tomcat上でのデプロイ

ダウンロードした BaseX の war ファイルをデプロイするのは TomcatのManager画面からするのが楽です． 直接 Tomcat のインストールディレクトリ下にある webapps フォルダにコピーするという手もありますが， 今回は Manager画面から行います．

TomcatのManager画面は以下に示したものです． パスは http://localhost:8080/manager/html になります． もし Manager 画面が表示されない場合には，Tomcat 側に情報が多数ありますので， そちらを参照してください．

このページ真ん中にある WARファイルの配備 からデプロイを行います．表示の通り [ファイルの選択] ボタンをクリックで上がってくるダイアログからファイルを選択し， その後， [配備] ボタンによりデプロイが行われます．

実は本画面はデプロイ後の画面でして， 上のアプリケーションのパスの所に /BaseX922 と表示されているのが見て取れると思います．

サーブレット動作としての BaseX

上記によりデプロイした BaseX サーブレットはWebサーバ機能が動作しているため http://localhost:8080/BaseX922/ からwebページを表示することが可能です．

以下のようなページが表示されれば無事にサーブレットして BaseX が動作しています．

このページに記載されている通り，restやwebdavでアクセスすることが可能です． その際，認証が必要となりますがデフォルトで設定されているユーザ名とパスワードは共に admin となっています．