アクセス権セット内の計算式ではグローバル変数は使えない

FileMakerネタです。ログイン可能なアカウント作成はいいとして、自分で作ったレコードしか見えないようにしたいというのはニーズの多い仕組みです。結構いろんなことをしないと行けないのですが、その設定の肝となるは、アクセス権セットのレコードに対するアクセス権です。細かな設定はこの記事では説明しませんので、詳しい方はご安心ください。FileMakerのあの辺りの機能は、ダイアログボックスが開きまくる手間のかかるUIですので、ポイントだけ示します。

アクセス権セットの [データ入力のみ] の複製を作って、名前を付け替えるなどするのが最初の作業です。「入力のみ」という違和感ある名前はともかく、複製を作り、レコードのポップアップで、「カスタムアクセス権」を選択します。

すると、次のようなダイアログボックスが新たに開きます。ここで、該当するテーブルを選択して、リストの下に見えるポップアップメニューから「制限」を選択します。一般に、「表示」の設定を変えるのは必須ですが、「表示」で制限をかければ、編集/作成/削除に対しては何もできないようなので、全部の項目に設定は必要ありません。

この「制限」を選択すると、式を入力するダイアログボックスが表示されます。そこで、論理式を入力します。論理式がTrueなら表示可能ということで普通にレイアウトにレコードのデータが表示されます。論理式がFalseなら <アクセス権がありません> とフィールドに出ます。こうした表示するかどうかを、レコードごとに決めることができるというのが、カスタムレコードアクセス権の設定で実現します。

ここで対象となるテーブルに、テキスト型でusernameというフィールドを作っているとします。そして、そのフィールドには、レコード新規作成時に自動的に「GET ( アカウント名 ) 」という式の結果を入力します。「ユーザ名」ではなく「アカウント名」で、こちらがログインした認証情報に含まれるユーザ名になります。

そして、カスタムレコードアクセス権の制限の式に「username = GET ( アカウント名 ) 」という式を設定しておけばOKです。この辺り、私たちの書籍「FileMaker as a Relational Database」の「8.3 レコード単位のアクセス権」に記述があります。設定手順がちょっと込み入っとるやないか!と今見たら思ってしまいますが、基本はここで説明したものと同様、アクセス権設定に対するレコード単位のアクセス権指定を行っています。

さて、ここからが本番(長い)。ある案件で、単にユーザ単位でのレコードの分離(レコードごとのアクセス権設定を行なった状態)にするだけでなく、ユーザのグループを定義してグループだと、所属している全てのユーザのレコードが見えるようにするという要件がありました。ここでのグループは、OSのグループとは違って、形態としてはユーザです。要するに権限の高いユーザがグループであり、権限自体に段階があるというか、自分だけと、グループ全体の段階があるという状態です。

これを実現するために、2つの方法を考えました。1つは、ここでのユーザとグループそれぞれ別々のアクセス権セットを割り当てることです。もう1つは1つのアクセス権セットでの「制限」の論理式でうまく処理を組み込むということです。まあ、当然、後者の方が面白そうなので、まずはそちらでやってみました。なお、あるユーザがどのグループに所属するかを記録しないと行けないので、ユーザ管理のテーブルをFileMakerに作る必要があります。{主キー, username, password, is_group, groupname} がテーブル構成です。ユーザ名、グループ名、いずれもテキストで記録するようにします。ここでいちいち主キーでリレーションするのもやり過ぎ感があるので、テキストで十分です。グループは、is_groupがTrueにしておきます。そうすると、ユーザのレコードで所属グループの選択を行うときに、グループだけの(is_groupがTrueのレコードだけの)ポップアップ等が作れるので、このようにしました。このテーブルから、ユーザがどのグループに属するかがわかるという段取りです。passwordはいらんといえばいらんのですが、せっかくこんなテーブルを作るので、いちいち、セキュリティ管理のダイアログボックスを出さなくても、ボタン1つでユーザの作成や削除ができるようなUIを作りました。そのためにはパスワードも入力しておくのが便利です。

そして、大変重要なリレーションシップの設定が必要になります。あるテーブルにusernameフィールドを作って、そこにログインアカウント名を入力しておいて、誰のレコードなのかがわかるようになっているということになるのですが、さらにそのレコードはどのグループの所属なのかをわかるようにしなければなりません。つまり、テーブルから、前者のユーザテーブルのusernameに対してリレーションシップを定義し、ユーザテーブルのgroupnameとして、各レコードの所属グループが得られるようにしておく必要があります。

ここで、アクセス権セットの「制限」の式を構築するとき、要するにログインしているユーザがここでの普通のユーザの場合と、グループユーザの場合では、比較するフィールドが違ってくるということがあります。その処理をやりやすくするために、ログイン直後にユーザテーブルで自分自身のレコードを検索して、is_groupフィールドを見て、自分が通常のユーザなのか、グループユーザなのかを$$変数に置いておき、その変数値を使った計算式を立てれば良いのではと考えました。そして、「制限」の式に$$変数を使ったものを記述したのですが、画面上はなんとなく問題ないように見えるのですが、検索をしても1つもレコードが返ってきません。

なんでか? よく考えてみると、$$変数というか、変数ってコンテキスト依存のものです。つまり、画面に出て来る段階で適用されるようなものと考えて良いでしょう。検索で変数は使えますが、変数の値を求めてそれを条件としてサーバに送っていると考えられます。検索処理そのものは、サーバで行われるとすれば、サーバでレコードを探っている段階では変数の値は全部未確定と考えるべきなので、変数が全部未定義でfalseになるのではと思われます。とは言え、デバッガを動かして検証できる状態ではないので、推測ですが、要するに制限の計算式ではグローバル変数は使えるようでいて使えない場面(この場合は検索時)があるというのが結論のようです。

では、実際にはどうすればいいのか? 1つは、ターゲットテーブルに対してusernameフィールド同士が等しいというリレーションシップを設定したユーザテーブルをtarget_userとすれば、「username = GET(アカウント名) or target_user::groupname = GET(アカウント名)」という式を設定すればいいかと考えました。ですが、あえて、設定がわかりやすいように、アクセス権セットを2つ作り、通常ユーザ用とグループユーザ用として適用し、前述の式のorで区切った前半を前者、後半を後者の「制限」の式に設定しました。ユーザ作成部分はレイアウトをベースにボタンを作って対処してあるので、作り分けることは完全に自動にできます。1つのアクセス権セットにするのもいいのですが、分けておくほうが、後々、いろんな場面に対応できそうな気がして、アクセス権セットを2つに分ける方を選択しました。

ちなみに、「username = GET(アカウント名) or target_user::groupname = GET(アカウント名)」という式で大丈夫だろうと思われるかもしれませんが、ここでのユーザテーブルの整合性が合わない状況の場合、思いがけない結果になります。{is_group, username, groupname}というスキーマに対して{false, user1, boss}{false, user2, boss}{true, boss, boss}という3レコードがあったとします。これを元に、usernameフィールドにuser1、user2あるいはbossという文字列を入れて、ターゲットテーブルに対してどのユーザのレコードかを記録します。bossでログインをした場合は、前述の式のor以降がtrueになることから、user1やuser2が所有しているレコードに対してもbossは参照できます。しかし、ここで、bossがグループユーザではなくて通常のユーザになったとします。is_groupをfalseにしただけだとしたら、user1、user2→bossがグループという情報が残るので、相変わらずbossはuser1やuser2のレコードを参照できます。つまり、user1やuser2のグループを””にするなどの処置が必要となるわけです。計算式にグループユーザかどうかという分岐を入れれば、この問題は回避できると考えて$$変数を使おうとしたのですが、前述の通り、これはうごかない式になってしまいました。複数のアクセス権セットに分離している場合でも同様なことは発生します。その場合、アクセス権セットを別のものに設定し直しが必要になり、これはスクリプトではできない作業になります。同様に通常のユーザをグループユーザに昇格した場合も同様な懸念がありますが、その場合、他のユーザを新たにグループになったユーザに所属させる作業が発生するので、自然に整合性は取れるかと思われます。アクセス権設定が複数ある場合はその所属変更が必要になります。ということで、アカウント作成後は、is_groupの値を変更しないというのがシンプルな解決策になりそうです。いずれにしても、運用間違えるとセキュリティの問題が発生しそうな案件なので、諸々、注意深く実装する必要はありそうです。

macOSで動くFileMaker Server 2024でPHP

FileMaker ServerにはPHPが付属しなくなって久しいのですが、現状、特にFileMaker Serverで動かなくても不便はなく、PHPの処理が欲しい場合は別途サーバを立てるのが最善策なのはいうまでもありません。しかしながら、「どうしても動かしたい」という声が後を絶たず、ここでとりあえず動かす方法をまとめておきます。そもそも、Clarisからの文書として「FileMaker ServerインストーラへのPHP添付の廃止について」があるのですが、内容が非常に込み入っていて、しかも何をしているのかわかりにくいこともあって、PHPを動かすことに躊躇している人も多いかもしれません。この文書は、FileMaker API for PHPという懐かしいライブラリを利用するための方法まで書いてありますが、今時のPHPのバージョンでこのライブラリが無事に動くとは考えづらく、その方法までは不要なのが一般的ではないかと思われます。

以下の方法が成功したのは、macOS Sequoia上のFileMaker Server 2024の場合です。これは対応OSではないのに成功したということです。また、Sequioa上ではFileMaker Server 2023でも成功しました。これも対応OSではありません(2024版はSequioa対応かどうかは公表されていないですね)。一方、macOS Ventura上のFileMaker Server 2023ではエラーになってうまくいきませんでした。これは対応OSであるのに上手くいかなかった組み合わせです。macOS内蔵のApache2に、外部からインストールするphpのモジュールという組み合わせの相性があるようなので、上手くいかない場合もあるという覚悟で進めましょう。

macOSへのFileMaker Serverのインストールはすでにインストールされているものとします。これにHomebrewをインストールします。インストール方法はサイトに記載されているので、それに応じてインストールしてください。インストール後、以下のようなコマンドを叩いて、phpをインストールします。執筆時点では、8.1以降は@をつけるので良いのですが、7.4はタップというサードパーティによるモジュール提供になっているので、コマンドの入れ方が変わります。コマンドラインでphpのバージョンを切り替えるには、unlink/linkを使います。

//最新版のPHPのインストール(執筆時点では8.3)
brew install php
//特定版のインストール
brew install php@8.1
//PHP 7.4のインストール
brew tap shivammathur/php
brew install shivammathur/php/php@7.4
//バージョンの切り替え
brew unlink php
brew link php@7.4

ちなみに、通常は最新版を使うけど、PHPのモジュールとしては古いものを使うということもアリです。以下、自分の使いたいバージョンのパスを確認してください。原則、/opt/homebrew/Cellerというディレクトリ以下にありますが、状況によって違うので、見つからない場合はいろいろ情報を探ってください。

次にコード署名を行います。コード署名とは、秘密鍵/公開鍵を使った暗号化の仕組みの応用で、ざっくり言うと「誰が作ったコードかわかる仕組み」です。iPhoneのアプリケーションでは当初より署名必須となっており、Appleが発行する証明書を利用して署名されていないと、App Storeへの登録ができなくなっています。この手法はmacOSにもかなり浸透してきており、macOSに付属しているApache2のバイナリhttpdも当初よりコード署名がなされています。

PHPはApache2用のモジュール(拡張子.so)を利用します。このモジュールは、httpdと同じプロセス空間で動きます。イメージ的にはhttpdがphpのモジュールを読み込むと思えば良いでしょう。しかし、macOSの制限により、httpdが署名されている場合は、読み込むモジュールも署名されていないといけません。homebrewで得られるモジュールは署名されていないので、そのままではモジュールとして読み込んで実行ができないのです。そこで、brewで得られたphpのモジュールに署名して、httpdが読み込んで利用できるようにする必要があります。

証明書を作る方法はいろいろあるのですが、「キーチェーンアクセス」アプリケーションを利用して、いかような手順で進めて作成される自己署名証明書で大丈夫です。ポイントは、証明書のタイプを「コード署名」にすることと、指定した名前を忘れないようにすることです。この証明書はキーチェーンに入ります。

キーチェーンにコード署名用の証明書を作ったら、コマンド入力を進めます。まず、/opt/homebrew/Celler以下にあるPHPのパスを探って、phpのモジュールを探します。バージョン等でパスの形式が違う場合がありますが、特定バージョンのphpのフォルダには.soファイルは1つだけなので、それをともかく探せば良いでしょう。そして、codesignコマンドで署名を行います。ちなみに、証明書を作ったユーザでログインしてターミナルで作業する範囲では、codesignコマンドはキーチェーンと同一のデータを使うので、コマンドにキーチェーンの場所を指定する必要はありません。コード署名をしたら、署名を読み出してみて、証明書の名前がAuthorityキーの値に見えることを確認しましょう。

モジュールを特定する(以下、「モジュールのパス」と記載)
/opt/homebrew/Cellar/php/8.3.12_1/lib/httpd/modules/libphp.so
コード署名する
codesign -f --options runtime --timestamp -s "msyk-test" モジュールのパス
//コード署名を表示する',
codesign -d -vvv モジュールのパス
//以下、表示結果Authorityの部分が、証明書の名前(作成時に指定したものとなっている)
Executable=/opt/homebrew/Cellar/php@7.4/7.4.33_6/...
Identifier=libphp7
Format=Mach-O thin (arm64)
   :
Authority=msyk-test

続いて、Apache2の設定ファイルを編集します。設定ファイルは、/Library/FileMaker Server/HTTPServer/conf以下にあります。ファイルはhttpd.confなのですが、以下のように、さらに2.4という拡張子が増えているファイルがあります。これを-iをつけたlsコマンドで見ると、1列目にi-nodeが見えています。i-nodeはファイルシステムでのファイルの中身を特定する番号を思ってください。よく見ると、httpd.confとhttpd.conf.2.4は同じi-node番号です。つまり、1つのファイルの実態にファイル名が2つ割り当てられているという状況で、これらは「ハードリンク」という状態であると呼ばれます。つまり、同じ中身なのです。

% ls -l -i
total 424
158411791 drwxrwxr-x  32 fmserver  fmsadmin   1024 10  9 10:19 extra
158417655 -rwxrwxr-x@  1 fmserver  fmsadmin  18175 10  8 13:32 httpd.conf
158417655 -rwxrwxr-x@  2 fmserver  fmsadmin  18144 10  8 11:57 httpd.conf.2.4
158412007 -rwxrwxr-x   2 fmserver  fmsadmin  13077  1 25  2024 magic
158412007 -rwxrwxr-x   2 fmserver  fmsadmin  13077  1 25  2024 magic.2.4

ここで普通にファイルを変更してもいいのですが、2.4が付いた方がバックアップと売れば、httpd.confは別ファイルとして変更したいような気がするので、たとえば次のようにコマンドを入れて、http.confとhttpd.conf.2.4を別物にしてしまうという手はあります。2つ目でhttpd.confは消えるのですが、中身は別のリンクhttpd.conf.2.4から参照できる状態なので、事実上ファイルは消えません。

cd /Library/FileMaker Server/HTTPServer/conf
rm httpd.conf
cp http.conf.2.4 httpd.conf

ということで、設定ファイル/Library/FileMaker Server/HTTPServer/conf/httpd.confを修正します。以下に、元の状態とその範囲の修正結果を示します。ページ内で、phpというキーワードを探せばすぐに元の範囲は特定できます。その前にLoadModule、そしてFileMatchディレクティブの中にSetHeaderを定義します。モジュールのパスや証明書の名前は、もちろん、前に示したものを指定します。

//元の状態',
<FilesMatch "\.php$">
    Require all denied
</FilesMatch>
//修正した状態',
LoadModule php_module モジュールのパス 証明書の名前
<FilesMatch "\.php$">
    SetHandler application/x-httpd-php
</FilesMatch>

なお、ここで、LoadModuleディレクティブは、通常は証明書の名前は設定できません。Apacheのサイトでもこんな引数はありません。おそらく、macOSに搭載されているhttpdは特別にこのような設定を入れることができるようになっていると思われます。

ちなみに、Apache2のエラーログなどを見ると、正しい状態でもこのようなnoticeメッセージが出てきます。パスが違っていたり、署名されていなかったり、名前が違ったりすと別のエラーメッセージになり、Apache自体が起動しません。

[Tue Oct 08 12:44:50.253541 2024] [so:notice] [pid 17129] AH06662: Allowing module loading process to continue for module at /opt/homebrew/opt/php/lib/httpd/modules/libphp.so because module signature matches authority "Developer ID Application: Nii Masayuki (W3WVRUYJRT)" specified in LoadModule directive

ということで、お決まりの、phpinfo()関数の結果は以下のとおりです。Darwin OS内で動いているのが見えます。もう、HomebrewのPHPは、Sequoia対応になっていますが、この時はSonoma対応の段階でしたけど、ちゃんと動いていました。

そういうわけで、FMDataAPIについても動作確認しました。一連の作業は、自分の普段使いのMacで確認したので、HomebrewによるPHPはいろんなものが最初から入っているため一発で動きましたが(というか、その環境でFMDataAPIを開発している)、足りないモジュールがあればbrew install モジュール名 等でインストールしましょう。

一連の作業で面白い動作を発見しました。codesignコマンドなのですが、SSH経由でログインをしてコード署名を行うと、adhocという名前が出てくる、おそらくはちゃんとしてない署名になります。Authorityは設定されないので、ApacheのPHPモジュールに署名しても稼働はしません。つまり、codesignコマンドは、macOSにログインをして、その上でターミナルから起動して署名しないといけないのです。セキュリティ的な理由なのか、あるいはキーチェーンの扱いなんかがあるのかもしれませんが、ともかく、ログイン方法でコマンドの動作が違って場合によっては正く署名されないというのは落とし穴かもしれません。プロバイダにあるMacや、鍵のかかったサーバルームにあるMacなんかの場合はよく注意をしましょう。

そういうわけで、HomebrewがインストールしたPHPのモジュール、macOSに内蔵されているApache2のhttpdを使うということで、コード署名が必要になるということだったのですが、ちなみに、Homebrewのアップデート(brew update/brew upgradeコマンド)を行うと、場合によってはバイナリが置き換わります。上記のような手順の場合、PHP 8.3の新しいマイナーバージョンの登場で古いものは消されるので、つまりはアップデートがあればその都度コード署名をしなければならないという、面倒かつ、実運用では危険な状態でもある点に注意を払う必要があります。

ちなみに、FileMaker Serverは入れておきたいけど、PHPでも開発作業等をしたい場合、つまり、それぞれ別々に利用するのが一般的な場合は、ここにあるような作業をしなくても、phpを-Sオプションをつけて、サーバモードで動かすのが普通です。公開ディレクトリをカレントディレクトリにして、php -S localhost:9000などとコマンドを入れて、ブラウザから「http://localhost:9000」に接続します。ということで、やっぱりFileMaker ServerのApache2上でPHPを動かす必要性って限られるんですよね。

nginxが動くFileMaker ServerでPHP

もう、だいぶん前ですが、FileMaker ServerのLinux版は、Webサーバとしてnginxを採用しました。また、もう少し前からになるでしょうか、FileMaker Server自体にPHPがバンドルされていない状態になりました。ということで、nginxでPHPダァ〜!ってなるのかと思ったら、全然情報が見つかりません。まあ、先に結論を言えば、PHPを動かすんだったら、別のサーバー立てるのが何かと安心というのがあるかと思います。しかしですね、「なんとか動かないか」と依頼されることが多々あり、手順をまとめてみました。Ubuntu Server 22.04LTSです。sudo権限を持ったmsykというアカウントでログインして作業をしました。

まず、お決まりのUbuntuのアップデート、そしてFileMaker Serverのアップデートです。Linux版は単にinstallすればアップデートもできて結構便利ですね。FileMaker Serverのインストール方法は、Clarisのドキュメントあるいはサイトをご覧ください。この記事は、FileMaker Serverをインストールした後のお話です。

sudo apt update -y
sudo apt upgrade -y

sudo apt install ./filemaker-server-21.0.2.202-arm64.deb

Apache2は、PHPのモジュール、つまりApache2のプロセスに入り込んで動くバイナリを使っていました。一方で、nginxは、別プロセスで動くPHPに対して、ソケットや通信を使って動きます。ということで、単独のプロセスで動くPHPといえば、PHP-FPM(FastCGI Process Manager)ですね。こちらをセットアップして動くようにする必要があります。モジュール名さえ分かっていればOKですね。以下の1行目で、phpとphp-fpmをインストールしていますが、composerも必要でしょうから一緒に入れておきます。2行目は、systemctlで指定するサービス名は「php8.1-fpm」になります。2行目はphp-fpmを再起動後も起動するように設定しておきます。なお、手元ではApache2も動いてしまっていたので、止めて再起動後にも起動しないようにしておきました。

sudo apt -y install php php-fpm composer
sudo systemctl enable php8.1-fpm
sudo systemctl stop apache2
sudo systemctl disable apache2

続いて、nginxの設定ファイルを変更します。FileMaker Serverは、/opt/FileMaker/FileMaker Server以下にファイルを置きます。スペース入るの嫌ですが、仕方ないですね。その中のNginxServerのさらに下にconfがあり、4つの設定ファイルがあります。fms_nginx.confファイルを修正します。例えば、こんな感じでnanoで編集します。

cd /opt/FileMaker/FileMaker\ Server/NginxServer/conf
sudo nano fms_nginx.conf

修正箇所を以下に示しますが、ファイルのほとんど末尾です。ファイル全体は、大きく分けて、ポート80に対する設定と、443に対する設定があり、後者の { } 内に以下のコードの赤字部分を追加します。最後にコメントになっている箇所があるので、その直前でいいかと思います。このままコピペして大丈夫だと思いますが、一応、設定のポイントを次に説明します。

    location ^~ /fmi/ {
      proxy_set_header X-Forwarded-Proto https;   # MWPE need ...
           :
      proxy_cookie_path /fmi "/; Secure; HttpOnly; Max-Age=43200";
    }

    location ~ \.php$ {
        fastcgi_pass  unix:/var/run/php/php-fpm.sock;
        fastcgi_index index.php;
        include       /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

#   location / {
     # First attempt to serve request as file, then
     # as directory, then fall back to displaying a 404.
         :

まず、locationは正規表現を伴っていますが、これは、拡張子が.phpのファイルに対するリクエストが来たらこの後の定義に従うということです。fastcgi_passは、ソケットあるいはURLを指定しますが、ここではソケットを指定しています。php-fpmはソケットあるいはTCP/IPのポートが開きますが、ソケットについてはこの後のphp-fpmの設定ファイルwww.confの中に記載されているので、それと合わせる必要があります。

fastcgi_indexは、ディレクトリへのリクエストの場合、index.phpファイルを探して、そのファイルへのリクエストとして処理するという意味です。

includeの後に、ファイルのパスを指定しますが、ここで指定したファイルはFileMaker以下ではなく、/etc/nginx以下、つまり一般的なnginx側のファイルです。よほど、複製して使う方がいいかと思いましたが、書き換えないので、標準nginxのファイルをそのまま使います。このファイルや、次のfastcgi_paramでは、CGI呼び出しのパラメータを指定します。PHP的にいえば、$_SERVER変数で得られる値を定義します。もちろん、キーと値を指定します。fastcgi_paramsファイルには一般的なCGIのパラメータがほぼ記載されているのですが、$_SERVER[‘SCRIPT_FILENAME’]の値については、モジュールで動かすPHPと若干違っているので、その設定がファイルに加わっています。変数$fastcgi_script_nameは、例えば、「/info.php」のような、リクエストで指定したパスです。変数$document_rootは、nginxのドキュメントルートで、root “…”で指定すると勝手に変数が定義されます。これらの変数をつなげることで、つまりは、稼働しているスクリプトへの絶対パスがパラメータとして伝達されるということです。

続いて、php-fpmの設定を行います。モジュール版の場合、Ubuntsuではwww-dataという名前およびグループのプロセスとしてApache2が稼働しているので、それらのユーザが前提となります。一方、FileMaker Serverは、nginxも、fmsuser/fmsadminというユーザ・グループで稼働します。それに合わせるため、設定を変更します。例えば、次のようなコマンドで編集作業を行います。

cd /etc/php/8.1/fpm/pool.d/
sudo nano www.conf

修正箇所は2箇所4行ですが、他の部分を入れ混ぜるとちょっと冗長なので、修正部分だけを以下に抜き出します。つまり、user, group, listen-*をそれぞれFileMaker Server向けに書き換えます。

    :
user = fmserver
group = fmsadmin
    :
listen.owner = fmserver
listen.group = fmsadmin
    :

設定はこれだけです。ということで、プロセスを再起動して…と言いたいのですが、FileMaker ServerはApache2だけの頃からも再起動が怪しかったですが、nginxでもやっぱりダメです。こちらのブログ「FileMakerServer での nginx チューニングをするための前準備」で細かく検討されていますが、ここではサーバを再起動させることにします。

再起動後、ドキュメントのルート、/opt/FileMaker/FileMaker\ Server/NginxServer/htdocs/httpsRootに、ファイル名info.php、中身は「<?php phpinfo();」というお決まりのテストファイルを作成します。はい、無事に出ました。

なお、ドキュメントルートは、例えば以下のコマンドで、自分のアカウントに書き込み権限があるようにしておくと良いでしょう。実行については読み出し権限がグループのfmsadminに設定されているので問題ありません。

cd /opt/FileMaker/FileMaker\ Server/NginxServer/
sudo chown -R msyk htdocs
cd htdocs/httpsRoot
echo "<?php phpinfo();" > info.php

ちなみに、FileMaker Serverでnginxをセットアップしているので、NginxServer/logsにログがあるのではと思うところで、実際にアクセスログなどはあります。ですが、設定ファイルのエラー等は、/var/log/nginx/error.logに書かれます。設定ファイルの間違い探しでは、こちらのファイルを参照しなければなりません。なお、PHPはそのままにしているので、/var/log/php8.1-fpm.logに書かれます。iniファイルは、/etc/php/8.1/fpm/php.iniですので、必要ならそのファイルを修正しましょう。

さて、FileMakerでPHPとなると、普通はFMDataAPIクラスを使うと思いますが、FMDataAPIも順調にバージョンアップして、Ver.32になっています。なお、Ver.32以降はPHP 8.1が最低条件ですので、PHP 7の方は前のバージョンを使ってください。Ubuntu 22はかろうじてPHP 8.1ですので最新版を使えます。例えば、次のようにコマンドを入れて、サンプルを動かしてみましょう。サンプルのデータベースは、FMDataAPIのページを参考にして、FileMaker Serverにセットアップしておいてください。

cd /opt/FileMaker/FileMaker\ Server/NginxServer/htdocs/httpsRoot
git clone https://github.com/msyk/FMDataAPI
cd FMDataAPI
composer update

これで必要なライブラリがセットアップされる…と思ったら、Problemとして2つ項目が出ます。

Composer is operating significantly slower than normal because you do not have the PHP curl extension enabled.
Loading composer repositories with package information
Updating dependencies                                 
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires PHP extension ext-curl * but it is missing from your system. Install or enable PHP\'s curl extension.
  Problem 2
    - phpunit/phpunit[3.7.0, ..., 3.7.38, 4.0.0, ..., 4.8.36, 5.0.0, ..., 5.2.7, 8.5.12, ..., 8.5.40, 9.3.0, ..., 9.6.21, 10.0.0, ..., 10.5.36] require ext-dom * -> it is missing from your system. Install or enable PHP\'s dom extension.
    - phpunit/phpunit 4.8.20 requires php ~5.3.3|~5.4|~5.5|~5.6 -> your php version (8.1.2) does not satisfy that requirement.
    - phpunit/phpunit[5.2.8, ..., 5.7.27] require php ^5.6 || ^7.0 -> your php version (8.1.2) does not satisfy that requirement.

色々書いてありますが、要するにcurlとdomの機能が入っていません。これらは、モジュール版と同様に、aptコマンドでインストーすることができます。インストール後、念のためphp-fpmを再起動します。前の続きなら、途中のcdコマンドは不要ですが、カレントディレクトリを明示するために書いておきます。

sudo apt install -y php-curl php-dom
sudo systemctl restart php8.1-fpm
cd /opt/FileMaker/FileMaker\ Server/NginxServer/htdocs/httpsRoot/FMDataAPI
composer update

これで、ブラウザからサンプルコードの.phpファイル(例えば、https://localhost/FMDataAPI/samples/FMDataAPI_Sample.php)を開くと、個別の通信が示されて、途中にはデータベースからデータを取り出す部分などが参照できます。

ちなみに、Ubuntsu上での動いているプロセスを見てみます。例えば、以下のようなコマンドで見てください。綺麗にレイアウトされないので、ここには結果は出しません。

ps aux

ここでは、プロセス名php-fpmで稼働ののち、FileMaker Serverがnginxプロセスを起動して、その後にFileMaker Serverのさまざまなプロセスが稼働しているのがよ句わかります。php-fpmはfmsuserがプロセスのオーナーになっていますし、nginxも同様です。

ということで、FileMaker Server 2024 on Ubuntsu 22において、PHP 8.1が起動しました。ここにはいちいち書きませんが、INTER-Mediatorも動いてサンプルが稼働しています(MySQLでテストしましたが〜笑)。

FileMakerのクイック検索とデフォルト言語

FileMaker 2023 (Ver.20.3.2.201) で不可解な動作がありました。なぜか、見え見えの検索条件を指定しても、クイック検索で検索できないのです。原因は、そのフィールドのオプション設定にあるデフォルト言語をUnicodeにしていたからです。通常「日本語」なので、何か設定をしてしまったのでしょうけど、「日本語」だとクイック検索できて、「Unicode」だと検索できないってなんか変な気がします。

ビデオを見ていただくとわかるように(外を歩く子供達の声が聞こえるけど無視して〜)、最初の検索で、「日本」では検索できるけど「大学」では検索ができないです。「病院」も同様に検索できません。検索できる文字とできない文字があるようです。このフィールドのデフォルト言語をUnicodeにしてありますが、それを「日本語」に変えるとちゃんと検索できています。

まあ、Unicodeにするなということだと思いますけど、デフォルト言語を「デフォルト」にしても、Unicodeと同様に、「病院」などの検索ができなくなりますね。これ、バグなんだろうか? あるいは有名な話?

FileMakerからPowerShellスクリプト実行

FileMakerのスクリプト内でPowerShellを動かしたくなったのですが、概ねうまく行ったのでノウハウを忘れないうちにブログにしておきます。もちろん、Windows版です。PowerShellで動かしたいのは画面ショットです。こちらのサイト「Windowsのコマンドラインからスクリーンショットを撮る(PowerShell)」にそのまま使えるスクリプトがあったので使わせてもらいました。ありがとうございます。また、FileMakerのスクリプトからシェルスクリプトを稼働する方法は、「Claris Community | Powershell script not working」に記載があります。

これで終わるかといえば、それだけならブックマークに忘れないように覚えさせておくだけで終わってしまいます。まず、通常は、Windowsでは、いきなりシェルスクリプトはセキュリティ的な理由で動かせないようになっています。そこで、以下のようなコマンドを、PowerShell等で入れておく必要があります。これで実行権限が与えられます。そのユーザでログインしている間は再起動してもシェルスクリプトは動きます。「Bypass」はなんでも動かすためのものなので、オンラインからの素材は検疫(デジタル署名の確認を)する「RemoteSigned」という設定の方が少しはマシかもしれません。

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope CurrentUser

これが実行されていないと全くスクリプトは動きません。

続いて、前述のClaris Communityのやり取りにもあるのですが、Quote関数を使うことが重要です。スクリプトを実行するためには、「イベントを送信」スクリプトステップを利用し、「送信イベント」は「ファイル/アプリケーションを開く」を選択しておきます。この選択肢は、FileMakerをWindows版で動かさないと出てきません。そして、「計算」を選択して、コマンドを送り込みます。ここで、あるシェルスクリプトにファイル名の引数を付与してPowerShellで実行する場合はこのような式になるかと思います。変数に期待する値などの状況も含めて書きます。

仮定
$scriptPath ← "C:/Users/msyk/myscript.ps1" // シェスルクリプトへの絶対パス
$targetPath ← "C:/Users/msyk/data.bmp" // スクリプトの引数に渡すファイルパス

「イベントを送信」スクリプトステップの「計算」の式:
"powershell.exe -command " & 
Quote(Quote($scriptPath) & " " &Quote($targetPath))

-commandパラメータの引数は、単一の文字列で「コマンドライン」を指定します。ですが、コマンド中に”があると、そこでパラメータが終わっているとシェルは思ってしまうので、全体をQuoteで囲みます。Quoteは全体をQuoteで囲むだけでなく、文字列内部の”は、\”のようにエスケープします。ただ、元のコマンド自体もパスであり、スペースが入る可能性を考えると、やっぱりQuoteします。コマンドラインとしてうまく値を引き渡すには、このQuoteのQuoteで大体うまくいくことがわかりました。

まず、ここで、Get関数を使えやと思うところかと思いますが、FileMakerのGet (ドキュメント)等は、「/C:/Users/msyk/Documents/」のように、頭に/がついてしまいますが、それだとPowerShellは正しくパスとして認識しません。C:/Users/…のように記述されていないといけないようです。ということで、Get関数の結果を文字列処理するか、いっそのこと、絶対パスを文字列で書くか、まあ、その辺りはソリューションに応じて頑張ってください。

もう1つ、ファイル名に使ってはいけない文字列があることを忘れないでください(例えば、こちらのサイトで一覧されています)。|や/はファイル名としては使えません。これらは、Substitute関数で置き換えてから、PowerShell実行スクリプトの引数に与えます。また、ファイル名として使えない名前(COM1など)もあるので、何かで取得した名前をファイル名として利用する場合にはデータを俯瞰して対策は必要になります。

FileMaker Server 19.4(Ubuntu)の稼働するLinuxでPHPも稼働させる

FileMaker Server 19.4.2.204が稼働するUbuntu Server 18では、デフォルトではPHPは入っていません。自分で入れれば動くのはわかっているのですが、いわゆる「インストーラ」はないので、色々うまく設定しないといけなくなります。一応、動かす方法はわかったので、忘れないようにここに書いておきます。

まず、PHPのインストールですが、Ubuntuの普通のパッケージだと7.2です。せめて7.4にしたいので、こちらのサイトを参考に以下のようにコマンドを入れました。レポジトリを追加して、PHP 7.4をインストールします。

sudo apt-get update
sudo apt -y install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt -y install php7.4

これだけだと、UbuntuでのサービスとしてのApache2を稼働させるとおそらくPHPは稼働しますが、FileMaker ServerのApacheは、独自の方法で起動しているので、そちらでPHPを認識させないといけません。

そこで、以下のようにコマンドを入れて、メインの設定ファイルを修正します。最初のcdコマンドで移動するパスが、FileMaker Serverをインストールした場合のApacheのルートディレクトリです。

cd /opt/FileMaker/FileMaker\ Server/HTTPServer/
sudo nano conf/httpd.conf

以下のような場所があるので、まずここを検索します。

#
# Disable PHP document
#
<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

この部分を、以下のように変更します。php.confはこれから作ります。

#
# Disable PHP document
#
#<FilesMatch "\.php$">
#    Require all denied
#</FilesMatch>

Include conf/extra/php.conf

これだけでよさそうに思うのですが、これだけだと次のようなメッセージが出てしまいます。

[Wed Jan 19 11:11:29.516483 2022] [php7:crit] [pid 30487:tid 140490306792384] Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe.  You need to recompile PHP.
AH00013: Pre-configuration failed

Apacheはマルチスレッド対応だけど、PHPは違うから、PHPを再コンパイルしろとあります。再コンパイルできるなら、レポジトリから取って来ません。そこで、若干問題が生じる可能性もあるのですが、Apacheをマルチスレッドではない状態で動かします。こちらのサイトを参考にしましたが、手順は異なります。

この点を解決するためにconf/httpd.confの編集を続けます。以下のような部分を検索します。「mpm」で検索すると良いでしょう。

LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so
LoadModule mpm_event_module /usr/lib/apache2/modules/mod_mpm_event.so
LoadModule negotiation_module /usr/lib/apache2/modules/mod_negotiation.so

これを、次のように変更します。mpm_event_moduleをコメントにして読み込みません。新たに、mpm_prefork_moduleを読み込みます。記載されていないモジュールの読み込みが増えていますが、そのモジュールはもともとありました。

LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so
#LoadModule mpm_event_module /usr/lib/apache2/modules/mod_mpm_event.so
LoadModule mpm_prefork_module /usr/lib/apache2/modules/mod_mpm_prefork.so
LoadModule negotiation_module /usr/lib/apache2/modules/mod_negotiation.so

これで、httpd.confを保存しておきます。

続いて、php.confを作ります。php7.4をインストールしたときに作られるファイルから適当に記述を持ってきて作ったものです。エディタを起動するために、次のようにコマンドを入れます。

sudo nano extra/php.conf

もちろん、存在しないファイルなので、エディタの画面は真っ白です。ファイルの中身は次のようにします。

LoadModule php7_module /usr/lib/apache2/modules/libphp7.4.so

<FilesMatch ".+\.ph(ar|p|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch ".+\.phps$">
    SetHandler application/x-httpd-php-source
    # Deny access to raw php sources by default
    # To re-enable it's recommended to enable access to the files
    # only in specific virtual host or directory
    Require all denied
</FilesMatch>
# Deny access to files without filename (e.g. '.php')
<FilesMatch "^\.ph(ar|p|ps|tml)$">
    Require all denied
</FilesMatch>

冒頭のLoadModuleは必須として、最初のSetHandlerだけでも多分動くと思いますが、とりあえず、他のものも入れておきました。なお、元のファイルにあったユーザのホームで公開した場合にスクリプトを動かさないようにする設定は省きました。

ここで、Apacheサーバだけを再起動とかして動くようにするのがお作法なのですが、サーバ自体を再起動します。それが確実なようです。すると、PHPが動きました。ちなみに、php.iniファイルのパスは、/etc/php/7.4/apache2/php.ini です。

こうしてPHPが稼働する状態になっているなら、PHPのモジュールはインストールするだけでOKです。例えば、初期状態ではcurlが稼働しませんが、次のようにコマンドを入れます。

sudo apt-get install -y php7.4-curl

すると、/etc/php/7.4/apache2/conf.dに、curl.iniファイルへのショートカットが作られて、認識します。あとは、サーバー再起動でもいいのですが、httpdctl gracefulでも設定は反映されます。

ちなみに、この方法でPHPを動かすのはまたまたアップデートの時などに手順やファイル名が違ったりしたりと色々面倒な気がするので、実稼働するシステムでは、FileMaker Serverとは別にPHPを稼働させるサーバを立てるのが、トラブルは少ないのではないでしょうか。

FileMakerの&演算子

さるDBを分析していると、計算式にすごいものを見つけた。2つの論理式のAND条件を取るためなのか、なんと、

A = B & C = D

という式が記載されている。前後が条件式なので、AND条件なんだろうか? なんじゃこらと思った。普通はC由来のプログラマ脳だと&&とやってエラーになって怒られるが、この式は当然ながら文字列結合の&演算子なのでエラーにならない。

FileMakerではfalseは数値の0、trueは数値の1だ。論理式A、Bについて、A & Bの結果は、どうなるかといえば、AがfalseでBもfalseなら “00” となりこれを論理式として評価すると数値の0でありfalseになる。A、Bが一方が1の場合、”01″ あるいは “10”となって数値化すると0でないのtrueになる。A、Bともにtrueなら、”11″を数値化して11はtrueだ。すると、&は、ORなのか! これはすごい。すごすぎる。

こんなものを納品するデータベースに書いたやつの顔が見たいね…

Amazon LightsailにFileMaker Server 19をインストール

FileMaker Server 19 for Linuxが登場したときに、VM上で動かす方法をブログに記載しました。今回は、Lightsail上で動かす方法をまとめておきましょう。Amazon Lightsailは簡単に言えば、Amazon版のVPSサービスです。コア数やメモリなどの設定が何段階かあるのですけど、FileMaker Serverの場合はメモリは4GB以上は欲しいところです。2コアで4GBメモリ、80GB SSDの設定で毎月20ドルです。EC2の同等なものがt3.mediumくらいだとすると、月に30ドルくらいになるので、それよりも安いということと、管理やセットアップが楽というのがLightsailでのマシン利用のメリットでしょう。なお、FileMaker Serverは8GB以上がメモリ推奨値です。4GBで動く保証はもちろんできませんが、大体、2GBだとサーバーは動くけどWeb系が怪しい感じ、4GBだとWebDirectも含めてとりあえず全機能は動くけど負荷増大には弱そう…という印象です。数人で使うサーバーなので、4GBで運用することにしました。

Lightsailによるクラウドコンピューターを用意

実際のセットアップを追っていきましょう。まず、Amazon Web Servicesのコンソールに入り、Lightsailのコンソールに移動します。そして、インスタンスを作成します。以下は、通常は画面を見ながら作業するところですので、設定のポイントだけを説明します。まず、ロケーションは東京を選択してあります。イメージは、Linux/Unixのうち「OSのみ」の「CentOS」を選択します。アプリが入っているものでない方が良いでしょう。

さらにスクロールしてプランを選択します。インスタンス名については、以下は既定値通りにしておきます。これで、画面下にある「インスタンスの作成」ボタンをクリックするだけです。

作成できれば、インスタンスのところにグレーのボックスで表示されます。そのボックスの右上にある点々の部分をクリックすると、ポップアップメニューが出てくるので、そこで「接続」を選択すると、新たなウインドウにコンソールが出てきます。コマンドはあとでまとめて紹介しましょう。ここで、スタティックなIPと、ファイアウォールの設定をしたいので、「管理」を選択します。

静的IPつまりは固定したIPアドレスは、いくつかは無料です。「管理」を選択した後にはそのコンピューターの設定がでできます。「ネットワーキング」のところに静的IPの設定があるので、それをクリックし、どのコンピュータのIPなのかを指定すれば、基本的にIPは割り当てられます。

また、ファイアウォールについても、同様に「ネットワーキング」のところにあるIPv4 Firewallのところで設定します。初期値は22と80番ポートだけが開いています。「ルールを追加」の部分をクリックして、TCPの443、5003、16000を指定して、ルールを追加しておきます。

ターミナル等のSSHから接続したい場合は、ログインのためのキーが必要です。こちらについては、画面上部の「アカウント」と書かれた部分をクリックして、ポップアップメニューからさらに「アカウント」を選択します。そしてページ中央のナビゲーション部分で「SSHキー」を選択します。ここでキーを指定したりもできますが、デフォルトで作られているキーをダウンロードして利用するのも良いでしょう。なお、ダウンロードした場合、そのファイルのアクセス権設定ではグループや全員に対しては何もできなくなっている必要があります。sshコマンドでは、-iオプションで、キーファイルを指定できます。ログインする時のユーザ名は「centos」です。このユーザーはパスワードなしでsudoが可能です。

コンピューターの設定は以上です。

FileMaker Serverのインストール

続いて、FileMaker Serverをインストールします。まずは、OSのアップデートを済ませておきます。

sudo yum update -y

FileMaker Serverのインストールに必要なコマンドのうち、最初から入っていないのはunzipです。unzipコマンドもインストールしておきます。

sudo yum install -y unzip

FileMaker Server 19.2.1のセットアップでは、http24というパッケージに依存しますが、こちらも最初は入っていません。以下のコマンドでインストールをします。これは、ClarisのKnowlege Baseにも記載されています。このcentos-release-sclはいろいろなソフトウエアが含まれています。その中に含まれているApacheとSSLモジュールを利用する模様です。

sudo yum install centos-release-scl -y

これで準備は完了です。あとはダウンロードしてインストールです。ダウンロードのURLは、ライセンスのページからコピペしてください。以下、XXXで一部を隠しますが、ライセンスを所有されていればわかるはずです。このまま以下のコマンドをコピペしてもダウンロードはされません。その後、unzipで展開しておきます。

curl -O https://downloads.claris.com/XXX/fms_19.2.1.23 .zip
unzip fms_19.2.1.23.zip

なお、この方法での入手だと、ダウンロードが途中で止まる場合もあります。その場合は再度トライする、あるいは一度PC/Macにダウンロードして、scp等でクラウドのコンピューターに転送しましょう。

rpmファイルが展開されれば、それを指定してyumでインストールをします。こちらの詳細は、VM上で動かす方法をご覧ください。

sudo yum install -y filemaker_server-19.2.1-23.x86_64.rpm

証明書を取得してインポート

続いて、Let’s Encryptで証明書をインストールします。設定方法は、こちらの記事を参考にさせてもらいました。このコンピューターのIPアドレスには、fms.msyk.netというFQDNと関連づけてありますので、以下はこの名前をそのまま使います。

まずはcertbotのインストールですが、いきなりはインストールできず、次の2つのコマンドを入れます。apacheプラグインは不要かもしれませんが、一応入れておきます。

sudo yum install epel-release
sudo yum install certbot python-certbot-apache

続いて証明書を発行します。

sudo certbot certonly --manual -d fms.msyk.net --agree-tos

途中で処理が止まって入力待ちになります。以下のように、通知が送られるメールアドレスを指定します。

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Enter email address (used for urgent renewal and security notices)
(Enter 'c' to cancel): msyk@msyk.net
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

メールアドレスを共有するかどうかを、YかNで指定します。

Would you be willing, once your first certificate is successfully issued, to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom.

(Y)es/(N)o: Y
Account registered.

続いて、チャレンジ、つまり一種の認証設定を行います。以下のようにターミナルで出ている状態になったら、リターンキーを押さずに、別のウインドウでログインします。

別のウインドウで、同じコンピュータにログインしたら、前述のメッセージのように、Web公開された場所に指定された名前のファイルを作り、その内容を指定通りにします。まず、FileMaker Serverは、/opt/FileMaker/FileMaker Serverディレクトリにあります。そこにある、HTTPServer/htdocsが、Webサーバーのドキュメントルートです。例えば、以下のように作業を行います。途中でエディタで作業をするのが手軽だと思うので、最初にnanoを入れていますが、適当なエディタを使ってOKです。パスを掘り、URLの最後の長い名前のファイルを作ります。もちろん、ファイル名は、ウインドウからコピペしてください。

sudo yum install nano -y
cd /opt/FileMaker/FileMaker\ Server/HTTPServer/htdocs
sudo mkdir -r .well-known/acme-challenge
cd .well-known/acme-challenge
sudo nano q3mLUhDwx-9PFQ4PihyvUJfQAlQ-PVqE0SV3KBTxx4g 

エディタでは、ターミナルに見えていた「Create a file containing just this data:」の次の行の文字列(q3mLUhDwx-9P…Vnu6zbvyJgTsの文字列)を入れてファイルとして保存します。このファイルの中身も、もちろん、ウインドウからコピペします。上記のような方法で作ったファイルはrootユーザー&rootグループになりますが、読み込み権限だけがあればいいので、全員に対するrが効いて問題なく処理できます。

ここまで準備ができれば、ターミナルの「Press Enter to Continue」と見えているウインドウに戻り、リターンキーなどを押して先に進めます。これで、通信とチャレンジが行われて、証明書が作成されます。以下のようにメッセージが出ますが、Congratulations!と出ていれば成功でしょう。その次の行以降に生成された証明書のパスが見えています。

 Waiting for verification...
 Cleaning up challenges
 Subscribe to the EFF mailing list (email: msyk@msyk.net).
 Starting new HTTPS connection (1): supporters.eff.org
 

 IMPORTANT NOTES:
  - Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/fms.msyk.net/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/fms.msyk.net/privkey.pem
    Your cert will expire on 2021-03-30. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew *all* of your certificates, run
    "certbot renew"
  - If you like Certbot, please consider supporting our work by:
 

    Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
    Donating to EFF:                    https://eff.org/donate-le 

証明書をFileMaker Serverに読み込みます。ここで生成した証明書へのパスの途中にある/etc/letsencrypt/liveがrootだけに読み書きができるディレクトリなので、このままだとFileMaker Serverはファイルの読み込みができません。そこで、以下のように、FileMaker Serverの中のCStoreディレクトリに一度証明書ファイルをコピーしてfmsadminコマンドで読み込むことにします。

cd /opt/FileMaker/FileMaker\ Server/CStore
sudo cp /etc/letsencrypt/live/fms.msyk.net/*.pem .

これで、証明書などのファイル4つ(cert.pem、chain.pem、fullchain.pem、privkey.pem)がCStoreに読み込まれます。通常は同名のファイルは最初からはありませんので、コピーして問題はないでしょう。また、ファイルの所有者とグループはrootになりますが、全員に対して読み込みができるので、アクセス権については問題ありません。そして、CStoreディレクトリがカレントであることを確認して、以下のコマンドで、FileMaker Serverに証明書を読み込みます。以下のコマンドは1行です。

fmsadmin certificate import cert.pem  --intermediateCA chain.pem --keyfile privkey.pem

これで証明書がセットアップされました。3ヶ月後に失効しますが、その時に対処を考えるとして、お疲れ様でした。

FileMaker Server 19のWebテクノロジーベンチマーク

以前からやろうやろうと思っていたベンチマークを必要に迫られてやらないと行けなくなったので、やりました。昔、2008年や2009年にFileMakerのイベントでお話しさせていただいた通り、当時のFMSのカスタムWebは同時にアクセスすると、なぜか倍以上の時間がかかるみたいな状態だったのですが、そんな実装はいつの間にかなくなってそこそこちゃんと動くようになっています。今の焦点は、Custom WebとData APIの違いがどの程度なのかというところかと思います。CloudやLinux版ではCustom Webがなくなっているため、いずれData APIに移行するのか、はたまたFileMakerを諦めるのかはそろそろ心算が必要な時期ではないでしょうか?

では先に結果を書きます。評価条件などは後から記載します。以下のグラフは、レコードの検索にかかる時間を100回行った場合の平均値です。横軸は1回の検索で取り出すレコード数で、それぞれのレコード数の検索を100回ずつ行った結果です。FileMaker Serverはこの作業以外は行わない状態にしました。FXはCustom WebのXML共有を使ったものです。APIはFileMaker APIを意味します。いずれも、INTER-MediatorのサーバーサイドのAPIを使って、検索を行いました。ベンチマークというかPHPで作ったプログラムがあるMacで動いていて、別のMacでFileMaker Server 19が動いているという状況での計測値です。

レコード数が少ない状況では、圧倒的にFXが早いです。200レコードの場合でもAPIの方は3.5倍も時間がかかっています。1つには、FXが1回のネットワークアクセスで処理が終わるのに対して、APIは認証、検索、ログアウトの3つのアクセスがあるので、ある程度時間がかかるのは仕方ないと思われます。しかしながら、ほとんどデータのやりとりがない1レコードの検索でも、200msほどかかっており、これがAPIのベースの処理に必要な時間と思って良いかと思います。100レコードでも253msとあまり変わらずです。ちなみに1レコードの場合は、FXは24msほどでした。

ところが、レコードの件数が2000件を超えると、FXよりAPIの方が処理が早く終わります。つまりデータが増えても処理時間の伸びは抑えられています。大量のデータに向くかどうかはさておき、FXよりもAPIの方が、比較の上ではデータが増えてもパフォーマンスの低下は少ないと言えるでしょう。同じデータを散布図で描くと次のように、かなり直線上に乗る感じです。傾きが違うのが見て取れるかと思います。

FXとAPIの違いの原因はなんでしょうか? もちろん、アルゴリズムが違うのは違うのでしょうけど、FXはXML、APIはJSONであり、これらの処理ライブラリを考えれば、JSONの方がパフォーマンスは上げやすいのではないかと考えられます(竹内さん、アドバイスありがとうございます)。

一方、FileMaker Serverに対して並列にアクセスをかけた場合の結果を以下に示します。500件のレコードを検索する処理を100回順番に実行するのが1つのタスクとします。並行実行処理数が1の場合は、そのタスクが1つだけ動く場合なので、前述のグラフの500の場合と同じ測定をしています。並行実行処理数が2、4、8は、そのタスクを同時にこの数字だけ稼働して、全てのタスクが終わるまでの時間を測定しました。従って、2の場合は検索数は200回行っているということになります。

Custom WebのFXは、並列数が1も2も時間に違いがありません。しかし、4、8となると線形的に増加しています。どうやら、2つくらいの並列処理くらいまでは現実に並列に処理をしているのではないかと思われます。サーバー側のプロセスであるfmdcwpcは1タスクだけだとCPUの利用率は30%くらいなのに、2タスク以上だと80〜90%と本当に仕事を頑張っている様子です。ところが、APIは2並列で稼働すると時間が2倍かかっています。つまり、サーバー側で並行的に効率良く処理する仕組みが稼働してはないかと思われます。APIの処理プロセスはfmwipdのようで1タスクだと3-〜50%くらいですが、タスクを増やしてもあまりCPUの利用効率は上がりませんでした。

また、次のグラフは、前述の時間を検索数で割ったものです。FXは、このように1の場合の半分の検索時間の値が2以上8まで推移しているので、どうやら1検索の2倍のパフォーマンスを上限として、順次処理を進めることができる模様です。ところが、APIは1検索のパフォーマンス以上は出せていません。その結果、2並列では2倍の時間がかかるということが分かります。

以上のことから、APIはやはりWebアプリケーションに使うとしてもアクセスが集中しないような用途に限定すべきでしょう。FXでもある意味そうなのですが、まだ、性能が高い面があります。また、Webアプリケーションでは小さなレコード数のアクセスが多いだけにFXで運用する方が有利ではないでしょうか。FileMaker Data APIはもちろん汎用的に使えるのですが、レコード数の増大に強い面があるとしたら、やはり大量のデータ交換に耐えうる設計がなされていると見るべきでしょう。

ちなみにこの並列処理の実験で気付いたのですが、FXは、8つのプロセスであってもほぼ同時に8つのプロセスが終了します。ところが、APIは、事実上、最初に入ったプロセスの検索を終えてから、2つ目の処理に移行しています。同時にプロセスは上がっているのですが、どうやら片方が優先的に処理されるようです。キープしたコネクションを優先的に使用するのかもしれません。実際の測定値は、1つ目のプロセスが34.5秒で終わり、2つ目は69.8秒で終わります。この場合、測定値は、69.8秒としました。同時に開始し、最後に終わったプロセスの経過時間を採用しました。

さて、なぜ、APIは4や8の測定値がないのでしょう。並列度をそこまで上げれば、812のエラー(Exceed host’s capacity)が出ます。ちなみに、Developer版なので、3ユーザですね。Data APIはデータ量の制限はあるのは知っていますが、ユーザ数による並列処理制限があるのでしょうか? これは始めて知りました。ちなみに、2並列ではエラーは出ないのですが、3並列ではうち1つの並列プロセスで812のエラーになってしまうため、測定不可能としました。ちなみに、この一連のベンチマークのために、3.3Gの転送量が計上されていました。

ベンチマーク測定においては、FileMaker Server 19側は特に設定は変更していません。コマンドで、XML共有をオンにしただけです。ベンチマークのプログラムは別のPHP 7.4が稼働するMacで動かしました。その2つのMac間は、Gigabit Ethernetなので、ネットワークのパフォーマンスは非常に高い状態です。なお、並列処理を行うために、php -Sによるサーバープロセスを最大8つまで異なるポート番号で起動して、ブラウザからそれぞれのポートのphpによるWebサーバーに接続し、ほぼ並列に動く状態を作りました。このマックはQuad CoreのCore i7です。ベンチマークのプログラムはこちらです。lib/src以下にINTER-Mediatorをクローンし、INTER-Mediatorをカレントにしてcomposer updateを行った後に、dist-docs/buildup.shを稼働させて(3)を選択して、lib/INTER-Mediatorを生成します。なお、INTER-Mediatorは、Pull Reuqest #1487が含まれたものである必要があります。fms-benchのディレクトリをルートにして「php -S localhost:9000」などで起動して、「http://localhost/do_bench.php」でベンチマークを動かしました。

ここでのベンチマークの検索プログラムは、レコード数12万件余りの郵便番号データベースを使っています。検索ごとに、乱数を使って異なるスタートポジションを指定して、そこから決められた数のレコードを取り出しています。フィールド検索には入っていませんが、データベース内部をランダムに探る必要がある点からデータベース自体の入出力により近い結果が得られることを期待しています。検索やリレーションシップが絡むと、データそのものによる要因が発生するので、今回のベンチマークではスタート位置のランダム化で測定を行いました。

いずれ機会があれば、更新系の処理もやってみたいですが、機会があるかどうか定かではありません。

2022/5/5追記:サーバ復旧時に画像が復活していなかったので、画像だけ埋め込みました。

FileMaker Server 19 Linux版のインストール手順

2020/10/28に、これまでプレビュー版だったFileMaker Server 19 Linux版の正式版が出ました。インストール方法や、インストール結果などをまとめておきます。

原則として、FileMakerのなんらかのライセンスがあることと、Linuxを稼働する環境があることを前提としています。以下の手順はVirtual Boxで、CentOS 7.8をインストールして動かすところから説明していますが、クラウド、オンプロミスにしても、原則同一かと思います。それぞれの細かい点は違っていると思うので、適時読み替えてください。CentOSは、こちらのサイトから「7 (2003)」のタブを選択してダウンロードします。Virtual BoxでMacあるいはWindowsだと、x86_64のISOイメージをダウンロードすれば良いでしょう。MacではもうすぐARM64を選ぶ場合も出てきそうです。その後、サーバーのリストが出るので適当なサーバーに移動し、「CentOS-7-x86_64-Minimal-2003.iso」というファイルを選択しました。サーバーなのでミニマルを利用します。こちらをダウンロードして利用しました。

Virtual PCでの準備

Virtual PCで、ツールバーの「新規」をクリックするなどして、新たにVMを追加します。名前などは適当につけますが、最初の選択肢は次のように、タイプは「Linux」、バージョンは「Red Hat (64-bit)」を選択しておきます。FAQですが、「CentOS」という選択肢はなく、内容はLed Hatと基本部分が同じなので、『CentOSはRed Hadを選ぶ』ことで大丈夫です。

メモリを最初2GB、ディスクは8GBにしていたのですが、2GBだと、Webパブリッシングが動きませんので、4GB以上にするのが良いようです。FileMakerの推奨環境だとメモリは8GBですので、負荷が多いあるいは安定性が必要なら8GBは確保しましょう。

VM作成後、左側のリストに項目が出てくるので、それを選択して、「設定」をクリックして設定パネルを出します。ここで、メモリなどの変更はできますが、ネットワークの設定を次のようにしておきます。つまり、アダプター1を有効化して割り当てはNAT、アダプター2も有効化してこちらは「ホストオンリーアダプター」にします。おそらく、vboxnet0が選択されていると思いますが、ここの設定がいくつもある方は適切に選択してください。アダプター2は、VMの外部からのネットワーク接続の確保ですので、「ブリッジアダプター」でも構いません。

ここで先の設定のために、ホストオンリーアダプタで選択したvboxnet0の設定を確認しておきます。左上の「ツール」をクリックすると右側に表示されます。通常はvboxnet0が自動的に作成されており、192.168.56.1/24のIPアドレスになっています。この後、VMをこの範囲の固定IPに設定しますので、この設定と、後から設定するIPは矛盾がないようにする必要があります。

続いて設定の「ストレージ」を参照します。ここで、コントローラー:IDEのしたの「空」を選択し、右側の属性にある光学ドライブの右の、CDマークをクリックしてメニューを表示して、「ディスクファイルを選択」を選択します。この後、ダイアログボックスが出てくるので、ダウンロードしておいた「CentOS-7-x86_64-Minimal-2003.iso」ファイルを選択します。すると、左側で「空」の部分がファイル名に置き換わります。これで、通常はCentOSのインストールディスクから起動するようになります。

OKボタンをクリックして、設定を確定します。左側で該当する項目が選択されているのを確認して、ツールバーの起動ボタンをクリックすると、起動が始まります。(以下のVMの設定は変更前のものです)

CentOSのインストール作業

ここからはCentOSのインストール作業です。画面はVirtual Boxのものですが、他の環境でも基本、同じだと思います。なお、AWSなどのクラウド環境では事実上、インストール作業は不要ですし、サクラVPSなどのVPS環境ではそのサービスでのインストール方法がサポートページにありますので、そちらをチェックしましょう。

インストーラの最初画面では、このままリターンキーを押します。実際には「Install CentOS 7」が選択された状態がデフォルトなので、それを選択することになります。

インストーラの画面が出てきます。ここで、デフォルトは英語なのでそのままでも良い方はそのまま右下のボタンで進めます。日本語にしたい方は、左下の検索枠のjapなどと入れれば、自動的に日本語が選択された状態になるので、「続行」をクリックします。

次は「インストールの概要」が出ます。ここは少し待つと、次の図のようになり、「インストール先」に黄色いアイコンが見えていて、これはここの設定がなされていないことを示しています。ここでネットワーク名とホスト名を設定してもいいのですが、ネットワークは後からコマンドで設定することにします。「インストール先」をクリックします。なお、下まで見えない場合は、右端の部分にスクロールバーが出るので、それをドラッグして表示範囲を変更します。画面上のポインタがウインドウの外に出ないのでパニックになるかもしれませんが、ウインドウの右下に、ポインタを外に出すキー操作(この場合は左側のコマンドキー)が書かれています。

インストール先の設定画面では、「ローカルの標準ディスク」の1つの項目を選択すればOKです。2回クリックが必要な気がしますが、ともかく選択して、左上の「完了」をクリックすればOKです。

もとの「インストール概要」の画面に戻り「インストールの開始」ボタンをクリックして、インストールを進めます。

次にこのような画面になります。右側の「ユーザーの作成」をクリックします。「ROOTパスワード」の方は放置で構いません。ルートのパスワードを設定しない運用方法が現状では安全と思われるので、管理者ユーザーを作ってルートはログイン不可能にしておきます。

ユーザーの作成では、自由にユーザーを定義してください。なお、ユーザー名とパスワードは絶対に忘れないようにしてください。そして、「このユーザーを管理者にする」のチェックには絶対に忘れないようにしてください。入力後「完了」ボタンをクリックすると設定されます。

設定されました。画面下に見えているように、インストールはその間もどんどんと続きます。

「再起動」ボタンが見えればインストールの完了です。

CentOSの最初起動時にネットワーク設定する

しばらく待つと起動します。login: が見えるまで待ちます。これで起動しました。ここで、インストール時に作成したユーザー名とパスワードを入力してログインをします。このコンソールでの作業はやりにくいので最低限にしたいのですが、ネットワーク設定まではここでやってしまうのが良いと思います。

ログイン後、以下コマンドで、ネットワークの状況をみてみます。この2つのコマンドにより、enp0s3とenp0s8の2つのネットワークアダプタがあることが分かります。Virtual Boxの場合は前者がアダプター1で、後者がアダプター2です。ちなみに、NATつまりアダプター1は、このVMがクライアントになってインターネット接続するために設定されたものです。アダプター2は前に説明したように、VMへの接続ができるようにするためのものです。なお、いずれのコマンドを見ても、IPv4のアドレスは見えず、まだネットワーク接続されていない状態になっています。

ip a
nmcli connection

次のようにコマンド入力をして、NAT側(アダプター1)はDHCPによるIP設定、ホストオンリーアダプター側(アダプター2)は固定IPに設定します。最初の4行は固定IPの設定です。コマンドはややこしいですが、何を設定しているのかは容易に想像できると思います。ここでは、192.168.56.19を固定IPにしています。6, 7は、起動時に自動的にアクティブになるようにするための設定です。なお、DHCP設定は何も指定しない場合にその方法でIPアドレスが設定されます。最後は、ホスト名の設定です。これはsudoが必要ですので、自分のパスワードで認証して続けます。ホスト名の確認はhostnameコマンドを利用します。

nmcli connection modify enp0s8 ipv4.address 192.168.56.19
nmcli connection modify enp0s8 ipv4.gateway 192.168.56.1
nmcli connection modify enp0s8 ipv4.method manual
nmcli connection modify enp0s8 ipv4.dns 8.8.8.8
nmcli connection up enp0s8
nmcli connection modify enp0s3 connection.autoconnect yes
nmcli connection modify enp0s8 connection.autoconnect yes
sudo nmcli general hostname centos.msyk.net
hostname

これでネットワーク設定ができたので「sudo reboot」コマンドで再起動します。

再起動後は、Macだと普通にターミナルで接続します。その方が、画面が見やすいなど作業効率が良いからです。要するにターミナルのウインドウでsshコマンドで接続するのですが、例えば「ssh-copy-id msyk@192.168.56.19」で、デフォルトの鍵ファイルをサーバーに登録すれば、以後は「ssh msyk@192.168.56.19」でパスワードを入れなくても接続は可能です。もちろん、ユーザー名とIPは指定したものです。ssh-copy-idコマンドの実行時にはサーバーのフィンガープリントの登録確認や、アカウントのパスワード入力も必要になります。この辺りの情報は他のサイトをご覧ください。以下は、ターミナルで通常通り接続できた状態であるとします。

ログインできれば、IPアドレスを確認しておきます。このコマンドはいろんな意味で覚えやすいのですが、出力結果はコンソールではもう少し見やすハズです。enp0s3とenp0s8に、それぞれ10.0.2.15、192.168.56.19が設定されていることが分かります。

$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:50:61:b7 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 brd 10.0.2.255 scope global noprefixroute dynamic enp0s3
valid_lft 83583sec preferred_lft 83583sec
inet6 fe80::ca47:2b2f:8c68:439b/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: enp0s8: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:a4:c7:ae brd ff:ff:ff:ff:ff:ff
inet 192.168.56.19/32 brd 192.168.56.19 scope global noprefixroute enp0s8
valid_lft forever preferred_lft forever
inet6 fe80::20fd:6331:59b8:1ec0/64 scope link noprefixroute
valid_lft forever preferred_lft forever

また、以下のコマンドを入れて、CentOSのアップデートをしておきましょう。少し時間がかかります。

sudo yum update -y

FileMaker Serverのインストール

FileMakerのドキュメントでは、wgetとunzipのインストールをせよと書かれています。unzipは確かに存在しないので、以下のようなコマンドでインストールしますが、wgetについては既存のcurlコマンドが使えるので必ずしも必要ではありません。

sudo yum install -y unzip

Apache2のインストールについては、あとで結果を書きますが、FileMaker Serverのインストール時に自動的にインストールされます。ここでは、CentOSのMinimal版だからかもしれませんが、「sudo yum list installed|grep httpd」とコマンドを入れても何も出力されず、Apache2は入っていません。従ってそのまま進めます。もし、「systemctl status httpd」により、httpdプロセスが既にアクティブになっている場合には、それは止める必要があると考えられます。「sudo systemctl stop httpd」で停止できますし、起動時に自動的に起動していたら「sudo systemctl disable httpd」で自動起動できないようにしておきます。Apache2自体は使うのですが、サービスの起動はFileMaker Serverに任せないと、動かない機能が出るのはプレビュー版で経験したことがあります。

では、FileMaker Serverダウンロードです。私はFDS会員なので以下のようなページが供給されていますが、そこにあるFileMaker Server 19のCentoOS Linuxの部分でコンテキストメニューをだし、「リンクアドレスをコピー」を選んで、URLをクリップボードにコピーします。

そして、「curl -O 」と手入力し、そしてペーストすることで以下のようなコマンドになるので、これで、カレントディレクトにダウンロードすることができます。URLは汎用的なもののように思えるのですが、一部は「XXX」に変えてあります。ここでは「fms_19.1.2.234.zip」というファイルがダウンロードされるので、unzipコマンドで展開すると、同じディレクトリにドキュメントやインストーラファイルが展開されます。ドキュメントは、設定支援インストール構成ファイル「Assisted Install.txt」を利用する場合には一読しましょう。そうでない場合は、追加の情報はありません。

$ curl -O https://downloads.claris.com/XXX/fms_19.1.2.234.zip
$ unzip fms_19.1.2.234.zip
$ ls -l
合計 682052
-rw-rw-r--. 1 msyk msyk 155 10月 17 10:04 Assisted Install.txt
-rw-rw-r--. 1 msyk msyk 24950 10月 17 10:44 FMS License (English).rtf
-rw-rw-r--. 1 msyk msyk 30689 10月 17 10:44 FMS License (French).rtf
-rw-rw-r--. 1 msyk msyk 26969 10月 17 10:44 FMS License (German).rtf
-rw-rw-r--. 1 msyk msyk 28616 10月 17 10:44 FMS License (Italian).rtf
-rw-rw-r--. 1 msyk msyk 79026 10月 17 10:44 FMS License (Japanese).rtf
-rw-rw-r--. 1 msyk msyk 27934 10月 17 10:44 FMS License (Spanish).rtf
-rw-rw-r--. 1 msyk msyk 5398 10月 17 10:04 README_Installation_English.txt
-rw-rw-r--. 1 msyk msyk 6225 10月 17 10:04 README_Installation_French.txt
-rw-rw-r--. 1 msyk msyk 6062 10月 17 10:04 README_Installation_German.txt
-rw-rw-r--. 1 msyk msyk 5906 10月 17 10:04 README_Installation_Italian.txt
-rw-rw-r--. 1 msyk msyk 6327 10月 17 10:04 README_Installation_Japanese.txt
-rw-rw-r--. 1 msyk msyk 6074 10月 17 10:04 README_Installation_Spanish.txt
-rw-rw-r--. 1 msyk msyk 350402832 10月 17 10:50 filemaker_server-19.1.2-234.x86_64.rpm
-rw-rw-r--. 1 msyk msyk 347731241 10月 30 10:06 fms_19.1.2.234.zip

続いて、ディレクトリにあるrpmファイルを特定し、以下のようにインストーラのコマンドを入力してインストールを行います。そこそこ時間がかかります。「Perform pre-installation…」と出てくるまで待ちます。このメッセージが出れば、質問に答える必要が出てきます。

$ sudo yum install -y filemaker_server-19.1.2-234.x86_64.rpm
[sudo] msyk のパスワード: xxxxxxx
読み込んだプラグイン:fastestmirror
filemaker_server-19.1.2-234.x86_64.rpm を調べています: filemaker_server-19.1.2-234.x86_64
filemaker_server-19.1.2-234.x86_64.rpm をインストール済みとして設定しています
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ filemaker_server.x86_64 0:19.1.2-234 を インストール
:
インストール中 : 1:java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64 115/141
インストール中 : ImageMagick-6.9.10.68-3.el7.x86_64 116/141
インストール中 : libfontenc-1.1.3-3.el7.x86_64 117/141
=== Perform pre-installation…

最初の質問は、使用許諾に従うかどうかです。使用許諾はzipファイルに入っていますが、lここでは「y」を選択するしかないでしょう。

I confirm that I have read and agree to the terms of the Claris FileMaker Server Software License Agreement included with the software.
Agree (y) Decline (n) [y/n] y

続いては、FileMaker Serverとして起動するか、WebDirect Workerとして起動するかを選択します。最初は前者なので、「0」と入力します。

0 ) Claris FileMaker Server
1 ) Claris FileMaker WebDirect Worker
Choose 0 to install Claris FileMaker Server or 1 to install Claris FileMaker WebDirect Worker. [0/1] 0

続いて、管理者のユーザー名、パスワード、パスワードリセット用の4桁数字のPINナンバーをそれぞれ入力して、リターンを押します。メッセージをよく見ると、fmsadminグループが作成され、現在ログインしているユーザーがそのグループのメンバーに登録されています。

Perform installation for Claris FileMaker Server…
Set up the Claris FileMaker Server Admin Console account for Claris FileMaker Server.
Use this account when you sign into Claris FileMaker Server Admin Console.
Enter User Name: admin
Create a password to sign into Claris FileMaker Server Admin Console.
Enter password:
Confirm password:
Create a 4-digit PIN needed to reset Claris FileMaker Server Admin Console account password via the command line interface.
Enter PIN:
Confirm PIN:
Set Claris FileMaker Server Admin Console account information.
Claris FileMaker Server is being installed by msyk to run as fmserver of fmsadmin group…
Create fmsadmin group…
Create fmserver user in fmsadmin group…
Add msyk user to fmsadmin group…

その後、インストール作業が再開されて、いろんなメッセージが見えますが、ここはしばらく傍観します。

インストール中 : filemaker_server-19.1.2-234.x86_64 118/141
=== Perform post-installation…
Set up core dump location at /var/crash…
Deployment type: Claris FileMaker Server
Retrieved Claris FileMaker Server Admin Console account information from cache.
Install default license certificate.
Create a default Claris FileMaker Server configuration with Japanese locale.
Open HTTP connection port 80…
Open HTTPS connection port 443…
Open Claris FileMaker Server connection port 5003…
Open ODBC connection port 2399…
Open Claris FileMaker Server Admin Console connection port 16000…
Enable and start HTTP server service…
Enable Claris FileMaker Server service…
Reload system daemons…
Check for Avahi daemon…
Avahi daemon has not started yet, wait for 2 seconds…
Avahi daemon has not started yet, wait for 2 seconds…
Avahi daemon has not started yet, wait for 2 seconds…
Avahi daemon has not started yet, wait for 2 seconds…
Avahi daemon has not started yet, wait for 2 seconds…
Start Claris FileMaker Server service…
Claris FileMaker Server service has started…
Waiting for connection session…
Sending Claris FileMaker Server Admin Console account information to Claris FileMaker Server…
Claris FileMaker Server Admin Console account is set up successfully.
HTTP Server has not started yet, wait for 2 seconds…
HTTP Server has not started yet, wait for 2 seconds…
HTTP Server has not started yet, wait for 2 seconds…
HTTP Server has not started yet, wait for 2 seconds…
HTTP Server has not started yet, wait for 2 seconds…
Warning! Failed to start HTTP server, please reboot the system.
インストール中 : 1:xorg-x11-font-utils-7.5-21.el7.x86_64 119/141
インストール中 : 1:cups-libs-1.6.3-43.el7.x86_64 120/141
インストール中 : libtiff-4.0.3-32.el7.x86_64 121/141
:

次のインストール項目に移る前に「Warning! Failed to start HTTP server, please reboot the system.」と見えています。これはインストール作業直後に「sudo reboot」をしなさいということです。しばらく待ってプロンプトが」出れば、「sudo reboot」とコマンドを打ち込んで再起動します。

インストール後のFileMakerサーバーのセットアップ

VMが再起動したら、ブラウザから、以下のURLで接続をします。もちろん、IPアドレスは実際のIPアドレスにします。そして、httpsであること、16000であることを確実に設定してください。これで、Admin Consoleが出てきて、あとはGUIでの設定になります。もちろん、ログインアカウントは、FileMaker Serverのインストール中に指定したユーザー名とパスワードになります。なお、おそらくは自己署名証明書で当初は運用するので、ブラウザはすんなりと画面は出してくれないと思いますが、いくつかの操作をすればページは開きます。

https://192.168.56.19:16000

セットアップ状態の確認

まず、httpdつまりApache2がインストールされたかを見てみると、このように元々入っていなくても、FileMaker Serverのインストーラによって自動的にセットアップされていることが確認できました。

$ yum list installed | grep http
httpd.x86_64 2.4.6-93.el7.centos @base
httpd-tools.x86_64 2.4.6-93.el7.centos @base

ですが、以下のコマンドの結果のように、httpdサービスはinactiveになっています。これは、httpdサービスとしては起動していないことを意味します。httpdデーモンの起動はFileMaker Serverが行います。

$ systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Docs: man:httpd(8)
man:apachectl(8)

ファイアウォールの設定も自動的に行われています。以下のコマンドで確認できますが、portsに設定が見えています。servicesじゃないのかよと思ってしまいますが、ともかくポートは開いています。

$ sudo firewall-cmd --list-all --zone=public
public (active)
target: default
icmp-block-inversion: no
interfaces: enp0s3 enp0s8
sources:
services: dhcpv6-client ssh
ports: 80/tcp 443/tcp 5003/tcp 2399/tcp 16000/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

Systemd配下で動くFileMaker Serverってどうなっているのだろうと思って/etc/systemdを探ったら、例えば、以下のようにすることで、サービスとして動いていることの確認はできそうです。psコマンドよりかは分かりやすい気がします。ただ、「sudo systemctl stop com.filemaker.httpd.start」とやって止まるかと言えば、おかしなメッセージが出てきて、startでは元に戻らない状況になってしまったので、起動や停止は、fmsadminコマンドなどを利用する方が確実かと思います。

$ sudo systemctl status com.filemaker.httpd.start
● com.filemaker.httpd.start.service - Filemaker.com monitor system and start httpd
Loaded: loaded (/etc/systemd/system/com.filemaker.httpd.start.service; enabled; vendor preset: disabled)
Active: active (running) since 金 2020-10-30 10:35:40 JST; 19min ago
Process: 1207 ExecStart=/usr/bin/env /opt/FileMaker/FileMaker Server/HTTPServer/bin/httpdctl start -d (code=exited, status=0/SUCCESS)
Main PID: 1417 (httpd)
CGroup: /system.slice/com.filemaker.httpd.start.service
├─1417 /usr/sbin/httpd -k start -D FILEMAKER -f /opt/FileMaker/FileMaker Server/HTTPServer/conf/httpd.conf
├─1420 /usr/sbin/rotatelogs /opt/FileMaker/FileMaker Server/HTTPServer/logs/error_log.%Y-%m-%d-%H_%M_%S 10M
├─1421 /usr/sbin/rotatelogs /opt/FileMaker/FileMaker Server/HTTPServer/logs/fmsadminserver_error_log.%Y-%m-%d-%H_…
├─1422 /usr/sbin/rotatelogs /opt/FileMaker/FileMaker Server/HTTPServer/logs/ssl_error_log.%Y-%m-%d-%H_%M_%S 10M
├─1423 /usr/sbin/rotatelogs /opt/FileMaker/FileMaker Server/HTTPServer/logs/access_log.%Y-%m-%d-%H_%M_%S 10M
├─1424 /usr/sbin/rotatelogs /opt/FileMaker/FileMaker Server/HTTPServer/logs/fmsadminserver_access_log.%Y-%m-%d-%H…
├─1425 /usr/sbin/rotatelogs /opt/FileMaker/FileMaker Server/HTTPServer/logs/fmsadminserver_ssl_request_log.%Y-%m-…
├─1426 /usr/sbin/rotatelogs /opt/FileMaker/FileMaker Server/HTTPServer/logs/ssl_access_log.%Y-%m-%d-%H_%M_%S 10M
├─1427 /usr/sbin/rotatelogs /opt/FileMaker/FileMaker Server/HTTPServer/logs/ssl_request_log.%Y-%m-%d-%H_%M_%S 10M…
├─1431 /usr/sbin/httpd -k start -D FILEMAKER -f /opt/FileMaker/FileMaker Server/HTTPServer/conf/httpd.conf
├─1432 /usr/sbin/httpd -k start -D FILEMAKER -f /opt/FileMaker/FileMaker Server/HTTPServer/conf/httpd.conf
├─1433 /usr/sbin/httpd -k start -D FILEMAKER -f /opt/FileMaker/FileMaker Server/HTTPServer/conf/httpd.conf
└─2131 /usr/sbin/httpd -k start -D FILEMAKER -f /opt/FileMaker/FileMaker Server/HTTPServer/conf/httpd.conf

10月 30 10:35:39 centos.msyk.net systemd[1]: Starting Filemaker.com monitor system and start httpd…
10月 30 10:35:39 centos.msyk.net env[1207]: [Fri Oct 30 10:35:39.773253 2020] [proxy:warn] [pid 1257:tid 139647227140…haring
10月 30 10:35:40 centos.msyk.net systemd[1]: Can't open PID file /var/run/httpd.pid (yet?) after start: No such file …ectory
10月 30 10:35:40 centos.msyk.net systemd[1]: Started Filemaker.com monitor system and start httpd.
Hint: Some lines were ellipsized, use -l to show in full.

カスタムWebパブリッシングは、リリースノートにあるように、非サポートとなっています。SETコマンドで、CWPCONFIGの属性であるENABLEXMLへの書き込みはできませんし、そもそも以下のようにCWPCONFIGの設定の読み取りすらできません。機能がないので、設定がないのは当然ということになりますね。

$ fmsadmin GET CWPCONFIG
username (msyk):admin
password:
Error: 21 (Not Supported)

とりあえず、正式版初インストールのレポートです。何かあれば、書きたします。