2018-05-24

PostgreSQL 10 インストール時の不具合解消方法

Windows Server に PostgreSQL 10 インストール時に 「Error with Configuration or permission 」という警告が出る場合の対処方法


 Windows Server 2012 環境に最新版の PostgreSQL 10 (10.4) をインストールしてみたのですが、途中で以下の警告メッセージが表示されてしまいました。

PostgreSQL 10 インストール時に発生した警告メッセージ

 警告ダイアログには、「ログを見ろ」とあったので確認してみたところ、権限設定で失敗していた模様です(文末参照)。

 そこで、以下の方法で不具合の対応をしてみました。
  同様の不具合でお悩みの方はダメ元で試してみるとよいかもしれません。

 ※インストール失敗理由については文末の「不具合の原因」のセクションをご覧ください。

PostgreSQL 10 インストール失敗の対応方法

  1. 上記の警告メッセージが発生してもいったんは最後までインストールする
    内部的にはインストールはエラーとなるため、 このままでは PostgreSQL サーバの起動はできません。
  2.  コントロールパネルの「プログラムのアンインストールまたは変更」から PostgreSQL をアンインストールする
  3. アンインストール後に残ったインストールフォルダより、\data\pg10 までたどり、pg10 フォルダのセキュリティより、Users グループに「変更」権限を付与する
    PostgreSQL 10 の \data\pg10 フォルダの Users アクセス許可に「変更」権限を付与
  4. もう一度、Postgres 10 をインストールして成功すれば終了

不具合の原因


 結論から述べると、PostgreSQL 10 を Windows にインストールした際に、以下のメッセージが出た場合は、権限設定エラーが発生した可能性が高いということになりました。

「Problem running post-install step. Installation may not complete correctly
 Error with configuration or permissions. Please see log file for more information.」

 以下が、不具合の調査結果になります。

1. インストールログファイルの特定
 PostgreSQL 10 のインストールログは、PostgreSQL 10 インストールディレクトリ直下の logs フォルダにあります。この中の PostgreSQL-installLog.log を確認します。

2. PostgreSQL-installLog.log の中から "Error with configuration or permissions" という文字列を検索してみます。

  エラー文字列の付近を調べてみると、どうやらデータベース初期化時にエラーを起こしていたらしいことがわかります。

Initializing Postgres DB with:
  E:\PostgreSQL\pg10\bin\initdb -U postgres -A md5 --encoding UTF8  -D "E:\PostgreSQL\data\pg10" --pwfile="E:\PostgreSQL\pg10\.pgpass" > "E:\PostgreSQL\data\logs\pg10\install.log" 2>&1 ERROR: Unable to Initialize PG. see logfile: E:\PostgreSQL\data\logs\pg10\install.log

Error running init-pg10
Script stderr:
 Program ended with an error exit code

Error with configuration or permissions. Please see log file for more information.
Problem running post-install step. Installation may not complete correctly
 Error with configuration or permissions. Please see log file for more information.

 3. エラーが発生したコマンドをコマンドプロンプトから走らせてみる

  ログテキスト(赤色)より、ログファイルへのリダイレクト部分を取り除いたコマンド文字列を走らせてみました。

E:\PostgreSQL\pg10\bin\initdb -U postgres -A md5 --encoding UTF8  -D "E:\PostgreSQL\data\pg10" --pwfile="E:\PostgreSQL\pg10\.pgpass"

 すると、以下のように \data\pg10 のディレクトリの権限を変更しようとして Permission denied が返されたことがわかりました。

PostgreSQL コマンドによるデータベース初期化時に Permission denied が返る
4. Users グループに「変更」権限を与えてみる
 権限エラーということで、pg10 フォルダの Users グループに「変更」権限を追加します。
 上記のコマンドプロンプトのスクリーンショットの解説では、以下の記述があります。

データベースシステム内のファイルの所有者は"Administrator"となります。このユーザがサーバプロセスも所有する必要があります。

 インストール実行時の Windows ユーザは Administrator でしたので、権限の書き換えは問題なくできると思われたのですが、実際はそのようにならなかったため、Administrator がデフォルトで所属している Users グループを採用しました。
 恐らく、他ユーザでインストール中にもこの方法で対応できると思います。

PostgreSQL 10 の \data\pg10 フォルダの Users アクセス許可に「変更」権限を付与
5. 先ほど失敗したコマンドをもう一度走らせてみる
 3. のコマンドをもう一度走らせます。
 ご覧のとおり、エラーが解消されましたね。
PostgreSQL コマンドによるデータベース初期化成功


 よって、今回の不具合の原因は data\pg10 フォルダの権限不足によるものでした。


※ Everyone を追加してから、フルコントロール権限を割り当てても同様に動作しますが(実験済み)、Everyone を重要なフォルダに割り当てたり、高度な権限を与えたりすることはサーバのセキュリティリスクを高めることになりますのでお勧めはしません。


参考リンク:
Re: BUG #14541: Getting error while installation

(亀)


2018-04-10

iBeacon/Raspberry Pi による室内移動体位置監視モデル1 ~概要~

[English page]

※本稿は2018年4月に執筆したものですが、後続稿との整合性などを考慮し2021年06月07日にアップデートしました。

 Raspberry Pi を監視端末を使用し、iBeacon (BLE4ビーコン)を取り付けた製品(以下、ビーコン)の存否確認を行う「定位置ビーコン監視モデル」については以前紹介(下記URL参照)しました。このモデルでは個々のビーコンの有無はわかりますが、その位置はわかりません。

 本稿では Raspberry Pi 端末(以下、「端末」、「監視端末」と呼ぶことがあります)によりビーコンをスキャンし、その位置を測位する「室内移動体位置監視モデル」について考えます。このモデルは製品ベンダーによって、あるいはシステムの用途によって、「屋内測位システム」、「資産管理システム」、 Indoor Location (Tracking) System、Indoor Positioning System (IPS)、Asset Tracking System、Realtime Location System(RTLS) 等と呼ばれています。 当ブログではこのモデルを示す用語として IPS を主に使用します。

 定位置ビーコン監視モデルに関する記事:

サブモデル

 移動するモノの位置を測位するシステムモデルはその要求属性によって、サブモデルに分かれます。

要求属性 属性説明
測位対象数 測位対象が多いか、少ないか 少数|多数
移動頻度 測位対象の移動頻度 高頻度|低頻度
移動速度 測位対象の移動速度 高速|低速
測位精度 要求される測位精度 高精度|低精度
リアルタイム性 測位要求から測位実行迄の時間 リアルタイム|非リアルタイム*1
測位対象 測位対象となるモノ ビーコン|携帯端末
Appデバイス 測位結果を表示するデバイス 管理端末|携帯端末*2
*1:非リアルタイムの場合、約1分迄の時間差は許容する
*2:管理端末は主にPC、携帯端末も可

 サブモデルには以下のようなものがあります。
  1. 屋内ゲームでプレイヤーの持つスマホに自身や他のプレイヤーの位置を表示する
    属性:少数|高頻度|高速|高精度|リアルタイム |携帯端末|携帯端末→ 屋内GPSモデル

  2. ホッケー等屋内スポーツで、選手の位置をPC等に表示しする
    属性:多数|高頻度|高速|高精度|リアルタイム|ビーコン|携帯端末 → ホッケーモデル(フィンランド Quuppa 社の動画

  3. 病院、介護施設で患者や入居者の位置をスタッフが把握する
    属性:多数|高頻度|低速|低精度|非リアルタイム|ビーコン|管理端末→病院モデル

  4. 工場の組立工程にある製品の位置を管理する
    属性:多数|高頻度|低速|低精度|非リアルタイム|ビーコン|管理端末→工場工程モデル

  5. 倉庫や保管場所にある製品の位置を把握する
    属性:多数|低頻度|低速|非リアルタイム|ビーコン|管理端末→倉庫モデル

 サブモデルにより IPS の仕様や運用方法も変わってきます。当社で開発中の TPC_IPS は上記の3~5のサブモデルを利用対象としています。

[コラム]ドローンフライト制御モデル

 市販のドローンの多くはGPSを搭載しており、屋外では自身の位置を認識しますが、GPS信号の受信状態が悪い或いは受信不能な屋内、ビル近辺、谷間等では、GPSは機能しません。 このような場合、IPSによりドローンの位置を把握し、フライトを制御するケースが考えられます。これによりプログラムにより制御されたドローンが物品を輸送したり、深夜に無人のビルや工場を巡回監視したり、撮影することができます。

 ただ、iBeacon(BLE4ビーコン)による IPS はその測位誤差が1メートル以上と大きいため、オフィスなどでのドローン制御は難しいと思います。 
 この点、BLE5.1AoA対応ビーコンや Ultra Wide Band(UWB)タグを用いたシステムであれば、測位誤差が1m~10㎝までに抑えられるため有利です。

 IPS の導入にあたっては、そのシステムがどの程度の測位精度を求めるのか、という点が重要です。

システム概要

 下図のように監視対象とするエリアを正方形で区切り、各正方形の頂点に監視端末(Raspberry Pi、図のピンクのマーク)を配置して、ビーコン信号をスキャンします。図の青いマークがビーコンで、これらが人やモノに取り付けられて移動します。Raspberry Pi の間隔、つまり各正方形の辺の長さは、障害物や人の多い場所や、高い測位精度が求められる環境では狭くします。 逆に障害物や人が少ない場所や、測位精度を重視しない環境では広く取り、端末の台数を減らすことができます。

【図1:Raspberry Pi監視端末の配置】
運用環境では監視端末を正方形状に配置できないことも多い

 各Raspberry Pi は常時ビーコン信号を受信し、その情報をアプリケーションサーバに送ります。サーバはこの情報を基に三点測位を行い、各ビーコンの位置を算出します。

 ビーコンの位置測位を行う手法はいくつかありますが、今回は三点測位を利用します。
図1の全ての監視端末(Raspberry Pi1 から Pi16) は常時ビーコン信号の読み取り(スキャン)を行っています。 ビーコン信号は発信時に最も強い強度を持ちますが、空間を伝搬するとその距離に応じて減衰していきます。各 Pi はこの信号強度、RSSI(受信信号強度、Received Signal Strength Indication)を取得するので、このRSSIの減衰の度合いからビーコンと端末(Pi)間の距離を算出します。

 下図の「Before (移動前)」の所には端末 Pi2、Pi5、Pi6 を中心とする円がありますが、それぞれの円の半径がビーコン迄の距離となります。三円測位では円の円の交わった点、あるいは3円が重なったエリアの中心をビーコンの位置であると推定します。 Pi2、Pi5、Pi6以外の端末もビーコンを検知しますが、最も近接する端末がこの3つの端末であり、近接する端末の RSSI の精度が高いため、この3の端末の円を基にして三円測位を行います。

 次にビーコンが「After」の位置に移動したとします。移動したことにより、距離が最短となる端末は Pi12、Pi15、Pi16 となりました。この時はこれらの最も近接する端末の円(端末⇔ビーコンの距離)を使用して三点測位を行います。 



考慮すべき課題

 一見簡単にビーコンの位置が特定できそうですが、そこまで辿り着くのは大変です。 その理由は以下の通りです。

RSSI の精度

 RSSI は端末とビーコン間の距離が数十センチの場合は、そこそこの精度で距離を計測できますが、1mを超えるとマルチパス(多重波伝搬)等の影響を強く受け、信号が公式の通りには減衰せず、RSSIに基づき算出した距離は実際の距離とは大きく異なる、ということが非常に頻繁に発生します。

三点測位の問題

 上記のようにRSSIに基づく距離は信頼性が低いため、三円測位の3つの円が交わらず、三円測位が破綻するということも多々発生します。この場合は単にエラーとするだけではなく、代替の手段を考えなければなりません。

 次稿では実際に RSSI を測定し、それから算出される端末とビーコン間の距離と実際の距離の誤差について考えます。さらに、小社が考案するRSSI・距離の補正方法と、三点測位の拡張についても記します。

2018年4月以降の改良点とIPS市場の動向

 本稿の公開は2018年4月ですが、その後新たな製品や技術がリリースされ、小社でも新たな手法の開発と検証を続けています。最後にこれらについて簡単に触れておきます。

測位方法

次稿(2018/08/09公開)と次々稿(2019/07/12公開)ではRSSIと距離補正や、三点測位を行うプロトタイプを開発してテスト・検証した結果を記しています。 しかし、RSSI 及び RSSI に基づく三円測位は測位精度に限界があります。 この点、機械学習を使用した測位は学習を行う手間がありますが、三円測位に比べ測位精度を上げることが可能です。この機械学習による測位精度についても、プロトタイプシステムを作成、テスト・検証を行い記事(2020/12/26公開)を書いています。

BLE5.1 AoA/AoD

2019年1月にBLE5.1 AoA/AoD の仕様が公表されました。これにより、BLE5.1対応端末(センサー)はビーコンの距離に加えて、ビーコンの存在する方向(角度)を取得することが可能になり、測位精度が1m以下になると期待されています。ただ、仕様公開から2年以上経った現在、主要ベンダーからは BLE5.1 対応の発信機及び受信機(センサー)はリリースされていません。

UWB

2021年4月末、Apple社から AirTag が発売され、iPhone 11/12 を使用すれば AirTag の測位を高い精度で行えるようになりました。この測位に使われている技術が UWB という技術で、誤差10㎝の測位が可能と言われています。UWB を使用した IPSシステムには UbisenseZebra といった製品が以前から市場にあり、高い評価を得ていますが、大変高価です。海外IT関連メディアは AirTag を "Game Changer" と呼んでおり、今後 UWB を使用した新たな IPSシステムが市場に現れるものと期待されます。

(亀)

IPS関連のBlog記事

土屋企画のIPS製品について/IPS product of TPC

2017-12-30

Androidを使用した多数移動体位置監視モデル

 前稿前々稿では iBeacon を使用した商品の存否確認に関するモデル(定位置ビーコン監視モデル)について記しました。これらのモデルは iBeacon を使用するため、その電波の到達範囲は0m~100m程度であるため、iBeacon(あるいは iBeacon を取り付けた商品)がその範囲を超えて出ていってしまうと、当然のことながらビーコン監視端末は iBeacon の存在を認識できなくなります。
 今回は前二稿とは趣を変え、モバイル端末を物品に取り付けることによってその位置を適時把握するモデルを考えるとともに、そのモデルに則したプロトタイプを作成・試用してみました。

多数移動体位置監視モデル

 本モデルでは、数十~数百、数千の移動する商品、物品、人などの物体に モバイル端末を取り付け、地図上にその所在地を表示しています。

 下図のように、モバイル端末のインターネット接続にはMVNOが提供する移動体通信網を使用し、端末はGPSにより得られた自身の位置情報をアプリケーションサーバ経由でDBサーバに送ります。DBサーバは送られてきた端末の位置情報を保存します。また、各端末の位置の地図上表示も、PC等のブラウザからアプリケーションサーバを介して行います。

多数移動体位置監視モデルの概要図
図1 ― モデル概要

通信端末について

 当初、上図端末には Raspberry Pi  等のシングルボードコンピュータを使用する予定だったのですが、検討を進めていくうちにコスト増のモデルになり得ることがわかりました。

 具体的には、まず、ラズパイにSIMドングルやGPSモジュール(ドングル)を載せる必要が出てくるわけですが、実用面を考慮するとユーザに容易にシャットダウンしてもらうための電源On/Offスイッチ、電源供給が遮断された場合に備え、UPSも準備する必要があります。

 これらのモノは全て自前で調達して設定しなければならないため、価格、性能評価や設定の労力、携帯性、収納性等がネックとなります。ラズパイは途中まで設定やテストを行ったのですが、結局 Android 端末を使用することにしました。
 Android であれば All-in-One で低価格(¥5千前後~)で入手でき、携帯性・耐衝撃性(移動時にコネクタ/ケーブル類が外れる可能性がほぼ無い)に優れ、電源周りで気を遣うことがなく、安定性・信頼性も実績十分です。
今回のテストに使用した Android フォントタブレット
今回使用したAndroidフォンとタブレット、OUKITEL社(写真左から3/4番目は¥5千/台で購入できた)

移動体通信会社(MVNO)

 本モデルでは多数の Android 端末を使用してインターネット通信を行うため、通信費用はできるだけ抑制したいところです。最近は格安MVNOの登場で、1GB程度のデータ量であれば月額¥500程度で利用できるので、後述のようなシステム仕様であれば1端末月額¥500で運用可能と思われます。
 ただ、今回作成・テストするプロトタイプシステムでは、IoT 通信に特化したデータ通信サービスを展開する SORACOM を試用してみることにしました。
 SORACOM を採用するメリットは主に2つあります。一つは少ないデータ量の通信では費用を低く抑えられること、もう一つは SORACOM API を通じてSIMを制御したり、通信状況を取得することができる点です。SORACOM の実際の使用感については後述します。

システム構成とプロトタイプ開発

 これまでの経緯より、モバイル端末には Android、モバイル通信には SORACOM を使用することに決めました。アプリケーションサーバ(App Server)とデータベースについては、前者を node.js + express.js、後者を FileMaker Server 16 としました。Google Maps API は アプリケーションサーバが Android から取得した位置情報をもとに住所情報を取得する際、またPC/タブレット等でAndroidの位置を Google Map 上に展開する際に使用します(図2参照)。
Android 端末によるデバイス位置管理システムの構成
図2 ― システム機能概要

ハイブリッドアプリとアプリケーションサーバの仕様と処理分担

 Android の GPS から経緯度情報を引き出すには、Android Studio 等でネイティブアプリを作成するか、HTML5/Cordova 等によりハイブリッドアプリを開発することになりますが、今回は iOS 等への対応も視野に入れ、ハイブリッドアプリを採用することにしました(上図の tpcgeo.apk、以下、tpcgeoアプリ)。tpcgeoアプリはアプリケーションサーバに経緯度情報を送信するだけの単純なモノです。Google Maps API を介した住所情報の取得やデータの加工、データベースの更新といった多くの処理は、アプリケーションサーバ上の tpcgeo_server.js と tpcsql.js(前回記事参照) が担います。
 Android 側にあまり仕事をさせないのは、通信量を抑えるというコスト上の理由と、外部で使用するモバイル端末から送信する情報の量は必要最低限にするというセキュリティ上の理由によります。

プロトタイプのテスト

 上記の仕様に従ってそれぞれのアプリケーションを作成し、Android とアプリケーションサーバに必要なアプリケーションやファイルをインストールした状態で、SORACOM SIM(SORACOM Air/Global plan01s)の導入を行いました。図2のように2つのサーバにも必要なシステムをインストールし、テスト開始です。

まず、データベースを起動し、次にアプリケーションサーバで node.js/express.js 上で動作する tpcgeo-servers.js をコマンドプロンプトから起動します。

アプリケーションサーバで tpcgeo-server.js を起動
図3 ― アプリケーションサーバのプロンプトで tpcgeo-server.js を起動

次に、Android 上で tpcgeoアプリ を起動し、位置情報を送信する回数(Requests)と送信間隔(Interval、ミリ秒で指定)を指定します。下図では、10秒間隔で20回、自身の位置情報を送信するように設定されています。“Start”をタップすると、位置情報のアプリケーションサーバへの送信が開始されます。

tpcgeo 実行画面 (Android)
図4 ― Android でハイブリッドアプリ=tpcgeo 実行画面

アプリケーションサーバ上の tpcgeo-server.js が Android から位置情報を受信すると、Google Maps API に位置情報を送り、その戻り値として住所情報を取得します。そして必要なデータ加工を行った後にデータベースへの書き込みを行います。これらの処理が成功すと、tpcgeo-server.js を実行するプロンプト画面には以下のような実行履歴が表示されます。

プロンプト画面に表示される tpcgeo-server.js の実行ログ
図5 ―  tpcgeo-server.js のプロンプト上に表示される実行履歴

 プロンプトに update[OK] が表示されている場合、FileMaker データベースの位置データ(下図のLatitude、Longitude、Altitude等、白地のフィールド)の更新が成功したことを意味します。
Tpc Geo 端末管理画面(FileMaker)
図6 ― 端末の位置情報等を表示する FileMaker アプリ
オレンジの部分は SORACOM API から取得する SIMの状態、課金情報等。 

 各端末の位置は、PC等のブラウザで Google Map 上に表示できます。

各端末の位置が Google Map 上に展開される
図7 Windows Edge で Google Map 上に表示した各端末
データベースから取得した各端末の位置情報に基づき、Google Maps API を介して地図上に端末をマッピング

 赤地のマーカ(端末名)をクリックすると、詳細がポップアップ表示されます。

ピンのクリックによって住所情報をポップアップ表示
端末の所在住所等詳細がポップアップ表示される


SORACOM Global について

 前述のように今回は通信にSORACOM社の提供する SORACOM Air/Global plan01s というサービスを利用しました。本サービスに必要な費用は SIM 1枚当たり、以下のとおりです(2017/12/30現在)。
  • 初期費用(SIM本体含む):US$5
  • 基本料金:US$1.8/30日
  • データ通信料:US$0.2/MB
ご覧のように初期費用が約500円と非常に低いため、本サービスは多くの IoT/M2M システムのテスト環境構築には適していると思われます。
 ただ、今回の Android ベースのプロトタイプ・システムに類似したシステムを“常時”稼働させようとすると、通信量が想像以上に発生し、月額¥500 の MVNO に比べると割高になると考えられます。
 その理由は Android OSとその付属アプリが予期しない多くの通信を行うからです。No root タイプの Firewall を導入して不要な通信を遮断・監視しようとしても、Firewall を回避して発生する通信が発生するため、これがかなりの量に及びます(なお、Android の Firewall については、NetGuard の開発者・M66B さんが BBS 上で参考になるレスを書いています)。
 
 では、常時稼働ではなく、限定的に稼働するようなシステムではどうでしょうか?たとえば、Android 端末が 1カ月の 80%は社内や倉庫内にあり、その間通信を必要としないケース、あるいは特定時間帯、特定期間にのみ通信を必要とするケース。これらのケースであれば、SORACOM のほうが割安となる可能性があります。というのは、SORACOM API を使用することにより、特定の時間、あるいは特定の条件下で SIM のサービスを停止させたり、一定の通信量を超過した場合は管理者にメールや SMS で通知を行うシステムを構築できるからです。


(亀)


IoT/M2M関連リンク