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 ~概要~

 Raspberry Pi を監視端末し、iBeacon を取り付けた製品(以下、ビーコン)の存否確認を行う「定位置ビーコン監視モデル」については以前紹介しました。このモデルはビーコンが移動しないことを前提としていました。
 今回は Raspberry Pi 端末(以下、「端末」、「監視端末」と呼ぶことがあります)により、移動するビーコンをスキャンし、位置を把握する「室内移動体位置監視モデル」(英語では Indoor Location (Tracking) System 等と呼ばれています)について考えます。これにあたり、端末上でビーコンを監視し、 RSSI の取得、距離算出、ログ保存、データベース更新を行うアプリのプロトタイプも作成します。

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

モデル定義

移動するビーコンの位置を把握するシステムモデルといっても、様々なものが考えられます。

例:
  1. 屋内ゲームでプレイヤーの持つスマホに自身(と他のプレイヤー)の位置を表示する(ゲーム機端末タイプ)
  2. 老人ホームや介護施設で入居者や患者の位置を管理者が把握する(高頻度スキャンタイプ)
  3. 工場の組立工程にある製品の位置を管理する(高頻度スキャンタイプ)
  4. 倉庫や保管場所にある製品の位置を把握する(低頻度スキャンタイプ)
  5. モノ・人の位置をリアルタイムに把握する(リアルタイムスキャンタイプ)
上記4のタイプは上記2、3のタイプに比べると、それほど頻繁にビーコンが移動することはなく、保管場所の変更など、稀に製品の移動が発生します。常時移動しないので、Raspberry端末からスキャンを実行して位置を特定する頻度は低くても良く、よってリアルタイム性を重視しないことを想定しています。
 これに対して、上記3、4のタイプは人や製品の位置をできるだけ迅速に把握する必要があるため、端末からのスキャンを頻繁に行うことを想定しています。
 5の「リアルタイムスキャンタイプ」は可能な限りリアルタイムな位置情報が必要とされるものです。
 移動体の位置監視システムはそのタイプにより仕様も運用方法に変わってきますが、本稿では、 高頻度及び 低頻度スキャンタイプについて考えます。

システム概要

 本モデルでは、監視端末をグリッド上に規則的に配置し、複数の端末が取得した同一ビーコンのRSSIにより端末とビーコン間の距離を算出し、その位置を推定することを目標とします。

監視端末のグリッド配置

ビーコンの位置を特定するにあたり、RSSI 等の情報を取得する Raspberry Pi 端末を碁盤の目状に10m間隔で配置します。すべての端末が常時あるいは一定間隔でビーコン信号をスキャンします。端末の座標はデータベースの端末テーブルに予め登録します。すべてのビーコン(製品)は赤枠内部に配置するものとします。

【図1:端末のグリッド】


位置情報更新ロジック

各Raspberry Pi監視端末は ビーコンスキャンを実行してRSSI(受信信号強度、Received Signal Strength Indication) を取得し、このRSSIに基づき端末とビーコン間の距離を算出します。その後、アプリケーションサーバを介してデータベースサーバ上にある各ビーコンの距離テーブルの距離データを更新します。距離テーブルには、ビーコン毎に3つ(または4つ)のレコードを保持しており、レコードには最もビーコンに近接する Raspberry端末3台のIDとビーコンまでの距離が記録されています。
 例えば、下図左上にビーコン(青)がありますが、このビーコンに最も近接する端末は Pi2、Pi5、Pi6であることから、このビーコンに従属する距離テーブルの3つのレコードには、これらの端末の ID と ビーコンと端末間の距離が記録されています。
 Pi1~Pi16までの Pi監視端末は常時スキャンを行い、Pi2、Pi5、Pi6以外の端末も図上のビーコンを検知しますが、ビーコンが移動しない限り距離が最小となる(最も近接する)端末は Pi2、Pi5、Pi6のままです。
 次にビーコンが矢印の位置に移動したとします。この時、距離が最短となる端末は、Pi12、Pi15、Pi16 となるため、3つのレコードは3つの端末IDとその距離情報により更新されます。

ビーコンの位置を算出 ― 三点測位

 上述のように、データベース上の距離テーブルには、端末IDと、端末⇔ビーコン間の距離が記録された3つのレコードがあり、端末テーブルには各端末の座標が保管されています。これらのレコードを元にビーコン位置をプロットすると、端末を中心にした3つの円が表示されます。3つの円が重なったエリアの中心にビーコンがあると推定されます。 この中心位置を求めるのが三点測位と呼ばれるもので、本システムモデルでは主としてこの手法を用いてビーコンの位置を特定することを最終目標とします。
Plotly により、3つの端末からビーコンまでの距離をプロット

考慮すべき課題 

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

1. RSSI の精度

次稿で詳述しますが、RSSI は端末とビーコン間の距離が数十センチの場合は、そこそこの値が計測できますが、1mを超えると各種干渉を受けて急激に劣化し、あるタイミングでRSSIを単純に取得して距離を算出しても、実際の距離とは全く異なる値が出てきます。
 また、RSSIはその精度の低さに加え、端末付属のBLEデバイス、端末の設置場所、時間帯、ビーコン個体等々、さまざまな条件の影響を受けます。
RSSI は位置特定の基本となる最重要な要素ですので、RSSIの値を補正する手法が必要となります。本モデルでは、この手法についても考えます。

2.三点測位

RSSIによりビーコン間の距離が算出されると、前述のように三点測位によるビーコンの位置推定が可能となります。ただこの手法も3つの円が交わらないと機能しないため、その場合は単にエラーとするだけではなく、代替の手段を考えたいところです。

 次稿では実際に RSSI を測定し、それから算出される距離と実際の距離を比較どの程度の誤差が発生するのかを見ます。さらに、小社で考案するRSSI・距離の3つの補正方法とその検証結果についてのも述べます。


(亀)











 




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関連リンク