既知の問題

このトピックでは、ゲートウェイのバージョン 10.0 の既知の問題と、利用可能な回避方法がある場合にはそれらについて説明します。
gateway10
このトピックでは、
Layer7 API Gateway
のバージョン 10.0 の既知の問題と、利用可能な回避方法がある場合にはそれらについて説明します。
2
Gateway が SunJSSE TLS プロバイダを使用する: 認証バインド操作での時間の増加
問題:
LDAP 認証を実行する Gateway フォーム ファクタに影響します。 Gateway バージョン 9.2 以降、SunJSSE はプライマリ TLS プロバイダになりました。これは、Gateway が安全なネットワークを介して LDAP プロバイダと通信するときに、LDAP ユーザ認証によって使用されます。 以前の TLS プロバイダ(廃止された FIPS/BSAFEJSSE)とは異なり、SunJSSE によって実行される LDAP バインドでは、各 LDAP ユーザに対して完全な TLS ハンドシェイクが必要です。 このプロセスでは、Gateway バージョン 9.1 の同じプロセスと比較して
、各ユーザの LDAP 認証バインドに約 100 ミリ
秒追加されます。 (DE474013)
回避方法:
Gateway では、以前に完了または成功したバインドの許可キャッシュが提供されます。同じユーザに対する繰り返しバインドの完全 TLS ハンドシェイクのパフォーマンスへの影響を軽減するために、許可キャッシュ サイズおよび成功バインドのストレージが増加する可能性があります。
  • authCache.successCacheSize (デフォルトは 2000)
  • authCache.maxSuccessTime (デフォルトは 60000 ms)
両方のプロパティを Gateway クラスタ全体のプロパティとして設定できます。詳細については、「認証情報のキャッシュのクラスタ プロパティ」を参照してください。
キャッシュの最適なサイズは、LDAP ユーザ ベースのサイズによって異なります。 成功がキャッシュされている間、成功キャッシュではユーザによるパスワードの変更や、LDAP サーバ上で無効化されることは考慮されていません。
ソフトウェア Gateway: AdoptOpenJDK 1.8.0_252 以降および Gateway バージョン 10.0
問題:
AdoptOpenJDK 1.8.0_252 以降は、ソフトウェア フォーム ファクタの Gateway バージョン 10.0 と互換性がありません。
回避方法:
AdoptOpenJDK 1.8.0_252 以降をインストールしようとしているソフトウェア Gateway ユーザは、Gateway をバージョン 10.0 CR1 以降にアップグレードする必要があります。
アウトバウンド WebSocket への接続アサーションでの接続エラー
問題:
エンドツーエンド接続のアップグレード プロセス中、および送信接続が成功した直後、Gateway にバックエンドからの以下のエラー メッセージ(アウトバウンド)が表示されます(DE467783)
com.l7tech.external.assertions.websocket.server.WebSocketOutboundHandler: インバウンドへのメッセージの送信に失敗しました: メッセージを配信できませんでした。接続が利用できなくなりました。
回避方法:
エンドツーエンド接続のアップグレードが完了すると、この問題が発生します。
MySQL 8.0 の 9.4 から 10.0 へのアップグレード
問題:
MySQL 8.0 では、NO_AUTO_CREATE_USER SQL モードが削除されました(MySQL の問題)。 MySQL 5.7 のバックアップをとって MySQL 8.0 にアップグレードすると、「sql_mode」を「NO_AUTO_CREATE_USER」の値に設定できないという問題が発生します。
回避方法:
以下のコマンドを使用して、ダンプ ファイル内の「NO_AUTO_CREATE_USER」を単純なスペースで削除します。
sed -i "s/NO_AUTO_CREATE_USER//g" mysql_dump.sql
CentOS 7 の問題
Gateway バージョン 10.0 では、CentOS 7 プラットフォームがサポートされています。 以下に、CentOS 7 プラットフォームに関連する既知の Gateway の問題を示します。
mysqld によるエラー ログ生成の問題を修正するために my.cnf ファイルを更新する
問題:
Layer7 API Gateway 10.0 OVA インストールでは、
my.cnf
ファイルで定義されているように、mysql エラー ログが
/var/log/mysqld.log
ではなく
/var/log/messages
に生成されます。
原因:
CentOS 7 では、systemd が MySQL サーバの起動とシャットダウンを管理します。
[mysqld_safe]
は、必要でないため、インストールされていません。 ログ ファイル パスや pid ファイルなど、一部のパラメータは
my.cnf
ファイルの
[mysqld_safe]
セクションに定義されています。 そのため、mysqld がエラー ログを生成していないように見える場合があります。
回避方法:
my.cnf
ファイルを編集し、
[mysqld_safe]
セクションのすべての内容を
[mysqld]
セクションに移動します。 MySQL サーバを再起動します。
pid ファイル
のパラメータ行が上書きされていることを確認してください。 パラメータの
[mysqld]
セクションに複数のエントリがある場合は、最後の行のみが優先され、それより前のエントリは無視されます。
AMI ゲートウェイ: ネットワーク サービスのステータスが「failed」になる
問題:
AMI Gateway (バージョン 10.0)でネットワーク デバイスのサマリと接続ステータスを表示したときに、ネットワーク サービスのステータスが「failed」と報告される場合があります。
Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: Bringing up interface eth0: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device eth0 does not seem to be present, delaying initialization. Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: [FAILED] Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: Bringing up interface ssg_eth0: [ OK ]
回避方法:
必要ありません。 CentOS 7 で導入された予測ネットワーク インターフェース ネーミング スキームにより、AMI ネットワーク サービスは「ssg_eth0」(Gateway によって付けられた新しい名前)を探すときに、まず「eth0」を探します。 ステータスが「OK」である「ssg_eth0」の存在をサービスが確認できる限り、「eth0」に初期ステータス「FAILED」が関連付けられていても、実際にシステム障害が発生することはありません。 (DE441402)
OVA のクローン作成には手動によるパッチ適用が必要
問題:
Gateway OVA (バージョン 10.0)のクローンを作成した後、Gateway 管理者がそのクローンに SSH を実行できません。 新しくクローンを展開すると、そのクローンのネットワーク アダプタ ハードウェア アドレスが変更されるため、VM は予測デバイス ネーミング スキームを使用して一意のネットワーク インターフェース名を作成します。 元の OVA とクローンの名前が競合しているため、iptables のファイアウォール ルールにより、ユーザは SSH を介して OVA クローンにアクセスできなくなります。 これは、CentOS 7 で Gateway OVA を実行した場合の既知の問題です。 (DE441413)
回避方法:
Gateway OVA のクローンを作成する場合は、以下の操作を行ってください。
  • クローンを作成する前に iptables/ip6tables サービスを無効にします。
  • OVA のクローンを作成した後、ネットワーク設定ファイル(ifcg ファイル)で識別されているインターフェースが iptables/ip6tables に記載されているインターフェース名と一致していることを確認します。 再設定の一環として
    nmcli
    コマンドを使用することもできます。
exited ステータス: ゲートウェイ関連のシステム サービスの意味
問題:
従来、CentOS/RHEL 6 では、init スクリプトを使用してサービスを開始および停止していました。 systemd では、これらのスクリプトは systemd サービス ユニットに置き換えられています。それよりも重要なことは、新たに導入された「終了」ステータスが systemd に固有であり、CentOS 7 を初めて使用する場合には混乱を招く可能性があるということです。 たとえば、サービスのステータスを確認して、サービスが実行中かどうかを把握しようとした場合に、ステータスが
Active: active (running)
ではなく
Active: active (exited)
と表示されることがあります。 これは通常、systemd がサービス ユニット ファイルに指定されたコマンドを実行したものの、そのプロセスを監視する関連デーモンが見つからなかったため、実際にそのプロセスが実行されているかどうかを確認できなかったことを意味します。 Gateway ではデーモンが使用されないため、CentOS 7 でサービスを確認したり実行したりすると、このステータスが表示される場合があります。 (DE437214)
回避方法:
必要ありません。
Enterprise Service Manager の問題
ESM でのレポート生成が失敗する
問題:
API Gateway Enterprise Service Manager でのレポート生成が失敗します。 これは OpenJDK の既知の問題です。 (DE437057)
回避方法:
ありません。
Policy Manager の問題
新規ユーザの場合に Policy Manager の起動に時間がかかる
問題:
新しいユーザが作成され、さまざまな異なるロールが割り当てられた場合、管理ユーザの場合の通常の起動時間(約 2 分)と比べて、新しいユーザが Policy Manager にログインするのに最大 30 分かかる場合があります。 (DE222762)(DE413957)
回避方法:
以下の手順を使用することで、ユーザのロールを削減できます。これにより、権限を検証する速度およびパフォーマンスが向上する場合があります。
  1. 新しいセキュリティ ゾーンを作成します。 以下の 2 つの新しいロールが使用可能になります。
    • View X Zone
    • Manage X Zone
  2. このセキュリティ ゾーンに、ユーザ(開発者など)のグループが使用できるようにする必要があるすべてのエンティティを割り当てます。
  3. 以下のいずれかを実行します。
    • View/Manage X Zone ロールのみをユーザ ロールに割り当てます。
    • 新しいグループを作成し、View/Manage X Zone ロール、およびその他の必要な事前定義済みロールをこのグループに割り当てます。 ユーザ ロールにこの新しいグループのみを割り当てます。
  4. クラスタ全体のプロパティを設定することでロールの自動割り当てを無効化して、ユーザのロールが自動的に増加しないようにします。
    rbac.autoRole.managePolicy.autoAssign=false
    rbac.autoRole.manageProvider.autoAssign=false
    rbac.autoRole.manageService.autoAssign=false
Policy Manager が正しく表示されない
問題:
一部の高解像度モニタでは、Policy Manager が正しく表示されない場合があります。 小さなフォントや判読不能な行など、表示上の問題が発生した場合は、実行可能ファイルの高 DPI スケーリング動作をオーバーライドしてみてください。 (DE211450)
回避方法:
Policy Manager の概要」の「トラブルシューティング」で高 DPI スケーリング動作をオーバーライドする手順を参照してください。
Azure MySQL データベースを使用して Azure で Gateway をアップグレードすると、構文エラーが発生する
問題
: お客様によっては、Azure MySQL データベースを使用して Gateway をアップグレードしたときに、次のエラーが発生する場合があります。
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '@'localhost'' at line 1.
(DE399413)
回避方法
  1. Azure MySQL データベースをバックアップします。
  2. 特権シェルで、以下のコマンドを入力します。
    /opt/SecureSpan/JDK/bin/java -jar /opt/SecureSpan/Gateway/runtime/lib/liquibase-3.2.2.jar --driver=com.mysql.jdbc.Driver --classpath=/opt/SecureSpan/Gateway/runtime/lib/mysql-connector-java-5.1.46.jar --changeLogFile=/opt/SecureSpan/Gateway/config/etc/db/ssg.xml --url=jdbc:mysql://gatewaydb.mysql.database.azure.com:3306/ssgvortx --username='[email protected]' --password='x' update
    「Liquibase Update Successful」というメッセージが返されます。
  3. Gateway のバージョンが 10.0 にアップグレードされたことを確認するには、MySQL で以下のコマンドを入力します。
    select * from ssg_version
    current_version に対してバージョン 10.0.00 が返されない場合は、以下のように入力します。
    update ssg_version set current_version = '10.0.00';
Azure クラウドで Gateway を実行する場合のアカウント ロックアウト
問題:
Microsoft Azure クラウドで実行されている Gateway に接続しようとすると、ロックアウトされます。 これは、Gateway がログイン試行の成功を誤って失敗としてカウントすることが原因です。 (DE368072)
回避方法:
/etc/pam.d/password-auth
ファイルを編集し、「account required pam_tally2.so」の行を、「auth required pam_env.so」の行のすぐ下に移動します。 ファイルは、以下のようになります。
auth required pam_tally2.so deny=5 even_deny_root_account onerr=fail unlock_time=1200 root_unlock_time=1200
auth required pam_env.so
account required pam_tally2.so
auth sufficient pam_unix.so try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
Cloud Foundry にインストールされているコンテナ Gateway が起動時にエラー ログを表示する
問題
: Gateway の起動時に、Cloud Foundry 上で Gateway の初期設定に関するログがエラーとして表示されます。 (DE359636)
SSH ルーティング時の接続タイムアウト
問題
Route via SSH2 アサーションで「SFTP」プロトコルが選択されている場合、接続タイムアウトがアサーションで指定されている値の 2 倍になります。 (DE215650)
回避方法:
タイムアウトを目的の値の 1/2 に減らします。
カプセル化アサーションを使用する際に、コンテキスト変数 ${request.time} が誤った時間を返す
問題:
カプセル化されたアサーション
の基礎となる(「バッキング」)ポリシーで ${request.time} が使用されると、誤った値が返されます。
(DE305223)
プレフィックスが ${service.*} のコンテキスト変数が グローバル スコープとなっている
問題:
「service」プレフィックスを持つコンテキスト変数が、本来あるべきローカル スコープではなく、グローバル スコープ変数になります。 (DE293047)
例:
  • グローバル ポリシーで設定されるコンテキスト変数 ${service.AAA} の値は、サービス ポリシーから取得できます。 サービス ポリシーからアクセスする場合には、結果として値が空であることが予期されます。
  • カプセル化されたアサーションの基礎となるポリシー フラグメントにおいて設定されたコンテキスト変数 ${service.BBB} の値は、サービス ポリシーから取得できます。 変数をパラメータとして返す設定をしていない場合、サービス ポリシーからアクセスをすると変数は空になります。
回避方法:
コンテキスト変数をグローバル スコープにしないようにするには、「service」以外のプレフィックスを使用します。
OAuth フォルダの削除時に依存関係エラーが発生する
問題:
カプセル化されたアサーションが含まれている OAuth ポリシーを削除すると、Policy Manager で依存関係エラーがトリガされます。 これらのエラーは一括では確認できず、削除をキャンセルすることもできません。 (DE222685)
回避方法:
この問題を回避するには、「トラブルシューティング: 問題と解決方法」の「問題: OAuth ポリシーを削除すると依存関係エラーが発生する」を参照してください。
[Sending Reply to Specified Queue]を使用する場合、Gateway によって例外がスローされる
問題:
MQ 8.0 用の[Sending Reply to Specified Queue]受信オプションを使用する場合、Gateway が例外をスローします。 (DE386344)
Gateway ログ内の誤った警告メッセージ
問題:
Gateway のログに、以下のような警告が含まれています。
WARNING 1 com.l7tech.server.policy.PolicyCacheImpl: 3255: Policy "Google Auth Code Extension" (#d095d9a4c56c975b34c64db5a6741dd0) contains an unlicensed assertion: Unknown assertion: RetrieveOAuth2Token
RetrieveOAuth2Token アサーションは、特別なライセンスを必要としない、OAuth Toolkit の一部です。 標準的な Gateway ライセンスのみが必要となります。 (DE317426)
回避方法:
必要ありません。 RetrieveOAuth2Token アサーションが実際に存在し、通常通り機能しています。 Gateway の起動時のライセンス チェックの段階で、内部のタイミングの問題が発生することによって、誤ったログ メッセージが引き起こされます。 このログ メッセージは無視して問題ありません。
復元後のファイル権限
問題:
ssgrestore.sh
コマンドを使用して Gateway が復元された後、一部のファイル権限が正しく復元されません。 これにより、Policy Manager が Gateway に接続できません。 (DE221036)
回避方法:
Gateway のトラブルシューティング」の「問題: 復元後に Gateway が正しく実行されない」を参照してください。
古い Oracle サーバを使用している場合の新しいデータベースの作成に関する問題
問題:
この問題は、Oracle X5-2 より前のサーバにのみ発生します。 バージョン 9.3 を使用して、古い Oracle サーバ上に新しいデータベースを作成する場合、以下のエラーが発生します(DE333430)。
Configuration Results
---------------------
An error occurred during configuration.
Unexpected error saving configuration 'Could not send Message.'
Would you like to re-configure? [Yes]:
回避方法:
このエラー メッセージが表示された場合、再設定を求められたら「
No
」と入力します。 次に、メニューからオプション
3
(Configure the Layer7 API Gateway)を選択し、オプション
1
4
の設定を完了して Gateway を設定します。
JSON Path アサーションが null 値でエラーを返す
問題
null
(大文字と小文字が区別される)値を含む JSON 式を評価する場合、アサーションが失敗します。 (DE384413)
回避方法:
JSON Path Expression V2 アサーションを使用します。
Luna HSM でキーの生成が失敗する
問題:
秘密鍵のプロパティの場合。 (DE305070 DE314879)
回避方法:
「楕円曲線」キー タイプ以外のキー タイプを使用します。
ロールの管理のパフォーマンスに関する問題
問題:
ロールの管理のパフォーマンスとスピードは、多数の(500 より多い)カスタム ロールが作成され、各ロールが多数(200 ~ 300)の権限を持っている場合に低下する場合があります。 (DE326081)
回避方法:
ロールと権限の数を増やしすぎないようにします。
Gateway 間の移行の問題
問題:
アップグレード後に移行の問題が発生する場合があります。 リリース 9.1 では、新しい「gateway-hazelcast」 FIREWALL_RULE が導入されます。 このルールがまだ存在していない場合、再起動時に Gateway に自動的に追加されます。 このエンティティは、Gateway ごとに一意の ID で作成されます。 バンドルをインポートしようとする場合、「gateway-hazelcast」 FIREWALL_RULE に対するマッピングは、409 の競合を避けるために、「MapBy:name」である必要があります。 (DE211367)
回避方法:
以下のように、バンドルのエクスポート中に作成されるバンドル ファイルを変更します。
以下の行を検索します。
<l7:Mapping action="NewOrExisting" srcId="
<unique_ID>
" srcUri="http://
<IP_address>
:8080/restman/1.0/firewallRules/
<identifier>
" type="FIREWALL_RULE"/>
次のように変更します。
<l7:Mapping action="NewOrExisting" srcId="
<unique_ID>
" srcUri="http://
<IP_address>
:8080/restman/1.0/firewallRules/
<identifier>
" type="FIREWALL_RULE">
<l7:Properties>
<l7:Property key="
MapBy
">
<l7:StringValue>
name
</l7:StringValue>
</l7:Property>
</l7:Properties>
</l7:Mapping>
Look Up Item by Value アサーションでの複数値の変数のエラー
問題:
複数値の変数に同じ値が複数回含まれている場合、Look Up Item by Value アサーションが失敗します。 (DE305234)
以下に例を示します。
Set Context Variable fave as String to: banana
Set Context Variable fruits as String to: apple,banana,pear,banana
Split variable fruits into fruitsalad on ","
Look Up Item by Value: find item ${fave} within ${fruitsalad}; output index to ${index}
Return Template Response to Requestor -- ${index}
この場合、「1,3」が返されません。 ただし、ssg_0_0.log ファイルには、以下のような INFO エントリが記録されます。
com.l7tech.external.assertions.xmlsec.server.ServerIndexLookupByItemAssertion: 6: More than one value was matched. Exception caught!
回避方法:
以下のサンプル回避策ポリシーを使用します。
回避策ポリシーの使用方法
  1. ご使用のコンピュータに .xml ファイルをダウンロードします。
  2. ポリシー ツールバーの
    [Import Policy]
    をクリックして、ポリシーを Policy Manager にインポートします。 詳細については、「ファイルからのポリシーのインポート」を参照してください。
不定期の送信 JMS リクエスト処理エラー
問題:
NamingException に関する既知の問題により、送信 JMS メッセージが正しく処理されず、以下のエラーが返されます。
com.l7tech.server.policy.assertion.ServerJmsRoutingAssertion: 4: Error in outbound JMS request processing: Something already bound at (queue-name). Exception caught!
しかし、メッセージが再処理されると、それらは正常に動作します。 (DE304792)
プロシージャ名にハイフンを使用する場合の JDBC Query アサーションの実行エラー
問題:
Perform JDBC Query アサーションを設定するときに、ストアド プロシージャ名にハイフンを使用すると、JDBC の命名規則に準拠していないためクエリが失敗します。 (DE309730)
回避方法:
プロシージャ名にハイフンを使用しないでください。
ブートストラップ/バンドル フォルダからロードされたか、RESTman エンドポイントに送信された場合、特別な目的のない秘密鍵が作成される
問題:
コンテナ Gateway のブートストラップ/バンドル フォルダを介して RESTman バンドルで定義された特別な目的を持つ秘密鍵を作成しようとすると、その秘密鍵は作成されますが、特別な目的(デフォルト CA など)が設定されません。 (DE320421)
Java Web Start の Policy Manager を使用すると[Published Service Properties]ダイアログ ボックスを開くのに時間がかかる
問題:
Java Web Start バージョンの Policy Manager ブラウザ クライアントを使用しているときに、初めて[Published Service Properties]ダイアログ ボックスを開くと、通常よりも時間がかかります。 (DE326621)
回避方法:
ありません。 ブラウザ クライアントでは、[Published Service Properties] ダイアログ ボックスの最初の呼び出し時に、追加の .jar ファイルをダウンロードする必要があります。 2 回目以降に開く際には、通常のスピードに戻ります。
Gateway が FIPS モードであるときの証明書の取得
問題:
Gateway が FIPS モード(クラスタ プロパティ security.fips.enabled = true)の場合、
Add Certificate ウィザード
が[Retrieve via SSL Connection (HTTPS or LDAPS URL)]オプションを使用したサードパーティ証明書の取得に失敗します。 (DE211158)
回避方法:
  1. 外部の手段を使って、証明書ファイルを取得またはダウンロードします。 たとえば、以下の OpenSSL コマンドを使用することができます。
    # echo | openssl s_client -connect host.host:port 2>/dev/null | openssl x509 -outform PEM > cert.pem
  2. [Tasks]-[Certificates, Keys, and Secrets]-[Manage Certificates]-[Add]-[Import from a file]
    に移動して、Gateway に証明書をインポートします。
HTTP(S) アサーションを介したルートに予期せぬ失敗が発生する
問題:
[HTTP(S) Routing Properties]の[Other]タブには、[Never fail as long as target returns an answer]コントロールがあります。 以下のシナリオでは、応答が返される場合でもアサーションが失敗することがあるという既知の問題があります。
  • [Security]タブで、[Service Authentication]が[Use HTTP Credentials from Request]に設定されている。
  • バックエンド サービスから 401 HTTP エラーが返される。 (DE215522)
回避方法:
このシナリオでアサーションの失敗を回避するには、[Service Authentication]の方式として代わりに[Specify HTTP Credentials]を使用します。 リクエストからのコンテキスト変数(例:
${request.username}
${request.password}
)としてユーザ名およびパスワードを指定します。
Siteminder のクラスタ全体のプロパティの検証の警告
siteminder.session.generateCookieString のクラスタ全体のプロパティの検証タイプが不適切に設定されていたため、Gateway の起動時に次の警告メッセージが表示されます。 「WARNING 973 com.l7tech.util.ConfigFactory$DefaultConfig: Ignoring unknown type '(?i)true|false' for validation of property ‘siteminder.session.generateCookieString’」。 これによって機能の問題が発生することはありません。
Azure MySQL データベースを使用して Azure で Gateway をバージョン 9.3 から 9.4 にアップグレードすると、構文エラーが発生する
これは、Microsoft Azure クラウドで Gateway イメージを実行している場合にのみ当てはまります。
問題
: お客様によっては、Azure MySQL データベースを使用して Gateway をバージョン 9.3 から 9.4 にアップグレードしたときに、以下のエラーが発生することがあります。
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '@'localhost'' at line 1.
(DE399413)
回避方法
  1. Azure MySQL データベースをバックアップします。
  2. 特権シェルで、以下のコマンドを入力します。
    /opt/SecureSpan/JDK/bin/java -jar /opt/SecureSpan/Gateway/runtime/lib/liquibase-3.2.2.jar --driver=com.mysql.jdbc.Driver --classpath=/opt/SecureSpan/Gateway/runtime/lib/mysql-connector-java-5.1.46.jar --changeLogFile=/opt/SecureSpan/Gateway/config/etc/db/ssg.xml --url=jdbc:mysql://gatewaydb.mysql.database.azure.com:3306/ssgvortx --username='[email protected]' --password='x' update
    「Liquibase Update Successful」というメッセージが返されます。
  3. Gateway のバージョンが 9.4 にアップグレードされたことを確認するには、MySQL で以下のコマンドを入力します。
    select * from ssg_version
    current_version に対してバージョン 9.4.00 が返されない場合は、以下のように入力します。
    update ssg_version set current_version = '9.4.00';