2020-11-11

東京ドームのような広い場所で少ない受信機によりビーコンのおおよその位置を推定する

 　IPS（Indoor Positioning System、屋内測位システム ― 屋内で人・モノの位置を把握するシステム）には、三点測位、フィンガプリント、AoA/AoD、GMM、機械学習等々、様々な方式があり、測位の精度を競い合っています。ネットを検索すると関連の記事や論文が多数見つかります。

　ただ、すべてのシステムの要求仕様が、誤差1m未満の精度を求めているわけではなく、位置は大雑把にわかれば良い、その代わり（ビーコン信号の）受信機を減らしたい、というモノもあります。
　例えば、老人ケアセンターであれば、入居者の存在確認（施設から黙って抜け出していないか）が最重要で、位置については大体の位置を把握できれば十分ということもあります。
　また、大規模な工場、資材置場、倉庫などで、フォークリフトや運搬機などの大きな機材にビーコンを取り付けてその所在地を把握するようなシステムでは、誤差1mの精度は要求されないことも多いでしょう。

　今回は、東京ドームかそれ以上に広いエリアにあるビーコンのおおよその位置(エリア)を、できるだけ少ない受信機（Raspberry Pi）で推定する方法について考えて見みます。
　尚、このエリアは障害物がほとんど無い、大規模な工場や倉庫のような場所を想定しています。

受信機の配置を考える

　下図でピンクが受信機（Raspberry Pi）でブルー(B)がビーコン（iBeacon）です。ビーコンは枠内にあり、ビーコンの信号を遮る障害物はほぼ無いもとします。

【グリッド】


　この時、ビーコンの「おおよそ」の位置を把握するためには、受信機をどの位の数、配置すればよいでしょうか？　結論から言うと、それはユーザの求める推定位置の精度、「おおよそ」に依存します。　基本的にエリア内の受信機が多ければ多いほど、推定位置の精度は上昇します。　今回は受信機の数を少なく抑えて、「おおよそ」の位置を把握する（精度は重視しない）というテーマで考えていきます。

グリッドについて

　上図をグリッド（但し、ビーコンは除く）と呼びます。　受信機（ピンク）は正方形の4つの角と中心に置きます。　この正方形の一辺の長さをグリッドサイズと呼びます。広大なエリアをカバーする場合、複数のグリッドを置くことになるので、グリッドサイズが大きければ大きいほど、使用する受信機の数は減少します。

使用ビーコン

　使用するビーコンの信号の最大到達距離は100m以上とします。ちなみに、Aplix社のビーコンの信号最大到達距離は100m、丸紅情報システムズ社のビーコンは150mとWebサイトに書かれています。

グリッドサイズ50ｍ

　ビーコンが受信機から離れれば離れるほど、受信機はそのビーコンの信号を検知できない（非検知）可能性が高くなります。　すべての受信機がビーコンを検知しない可能性が最も高いのは図の4つのビーコンの位置です（検知困難地点）。ここでビーコンBについて考えます。ビーコンBは受信機A、B、Cから25mずつ離れていますが、障害物が無い場所ではA、B、Cのいずれもがビーコン信号を受信する可能性は高いです。各受信機がビーコンから信号を受信すると、信号の強度（RSSI）からビーコンまでの距離を算出します。　受信機を円の中心とし、算出した距離を半径とする円周上近辺にビーコンが存在すると推定されます。ここでは3つの受信機が信号を受信しているので、3つの円が交わった黄色のエリアにビーコンが存在すると推定されます。


グリッドサイズ150m

　次にグリードサイズ150mのビーコンB（検知困難地点）について考えます。このケースでは受信機からビーコンBまでの距離は75mです。75m離れていると非検知の可能性が高まります。ここでは受信機AがビーコンBを検知できず、受信機BとCが信号を検知したと仮定します。このとき受信機BとCを中心とする円の交差する黄色エリアにビーコンBがあると推定されます。


グリッドサイズ200M

　最後にグリッドサイズ200mのケースです。この場合、受信機A、B、CからビーコンBまでの距離は100ｍとなります。100mとなると受信機がビーコンの存在を検知しない可能性がさらに高まります。下図では、ビーコンBを検知した受信機がCのみだったと想定しています。この場合、ビーコンはCを中心とする円の円周付近上にあると推定されます。
但し、100mになると元々低いRSSIの精度がさらに低くなるため、円周の外側と内側に大きく逸脱して存在する可能性が高くなります。下図で黄色エリアがドーナツ型なのはそれを表しています。

　

　　尚、受信機とビーコン間の距離が100mある場合、どの受信機にも検知されない可能性も十分ある点にもご留意ください。

受信機からビーコンまでの距離について

　RSSIの精度はもともと低いので、それを元に算出される距離の精度も低いです。特に30m以上になると、RSSIが「0」(RSSI測定不能)になったり、値が想定される値とはまったく違ったり、あるいは信号自体が検知されないことが普通にあります。　
　下図はAplix社のビーコン2台と丸紅情報システムズのビーコン3台のRSSIの計測結果です。この時は、Aplix社のビーコンの1台は25m以上になると検知されないことが多く、丸紅はより頻繁に検知されましたが、RSSIは想定される値と大きく異なっています。
　RSSIまたは距離の精度を上げるには、なんらかの補正が必要となります。

※RSSIが継続的に0になる、或いはRSSI補正が不能なほどRSSIの精度が低い状況では、グリッドサイズの短縮を検討しましょう。

BLE 5 対応ビーコンの到達距離

　上述のAplix社と丸紅社のビーコンは BLE4 の規格に準拠していますが、現在は BLE5 の対応のチップも Nordic Semiconductor 等からリリースされています。 BLE5対応ビーコンの信号到達距離は、"理論的は"BLE4対応ビーコンの4倍となります。2020年11月現在、BLE5に準拠した長距離ビーコン（Long range beacon）で技適を取得している製品は市場にありませんが、今後対応製品が発売されると、障害物が少ないところであれば400m超のビーコン探知が可能になるとものと期待されます。

人や障害物が少なからず存在するエリアについて

　繰り返しとなりますが、上記は障害物がないエリアを想定しています。人が多くいたり、壁や棚などの障害物がある場合、適切なグリッドサイズは4m～15m程度になります。また、人が密集する展示場やイベント会場、金属製の背の高い棚が多く置かれている倉庫などでは、IPSによる測位がそもそも困難・不能なケースもあります。


NuckyT



IPS関連のBlog記事

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

By 時刻: 0 件のコメント:
ラベル: , , , , , , , , , , ,

2020-09-04

テレワークのセキュリティ対策

 　コロナウイルスの蔓延により、人々の働き方に変化が表れました。労働者のウイルス感染リスクを低減させるために、テレワーク（在宅勤務、モバイルワーク、サテライトオフィス）を導入する企業も増えてきました。


「出社3割以下」も テレワーク再強化の動き コロナ感染拡大で
「リモートワークできず倒産」というニュースが流れる日 


　テレワークを導入するにあたり、企業側として最も気がかりになることはセキュリティですね。つまりウイルス・マルウェア対策と重要データの取り扱いとなります。 


安易なテレワーク導入は危険がいっぱい


　スタッフの身の安全を確保しつつ業務を遂行するために、社内で以下のようなテレワーク構成を行ったとします。

  1. 社内ルータをVPN対応のものに変更し、ファイアウォールで公開ポート制限
  2. 各スタッフのPCにはアンチウイルスソフトを導入済み 
  3. 各スタッフは社内ネットワークにVPN接続し、リモートデスクトップで社内のコンピュータやサーバにアクセス
  4. スタッフAは会社支給のPCを使い、リモートデスクトップ経由で社内業務の管理を担当
  5. スタッフBはBYOD(自前)の自作PCを使って開発を行い、成果物をリモートデスクトップ経由で社内サーバ環境にコピーしたり、データベース管理を行ったりする
  6. スタッフCはBYOD(自前)の mac PC を使っているが、社内で使っている経理ソフトが Windows 版のため、リモートデスクトップ経由で社内の Windows コンピュータにアクセスして経理ソフトウェアを操作

　一見、ひととおりテレワークで業務がこなせるようになってはいますが、これではまだセキュリティ的に問題のある構成となっています。この問題点は何だかわかりますか？

テレワーク環境の問題点
テレワーク環境に潜む問題

　在宅スタッフに起因する基本的なセキュリティ対策が不足しているのです。
　それでは問題を見ていきましょう。

各PCのセキュリティ状態が把握できない

　各 PC にはアンチウイルスソフトウェアがインストールされてはいますが、各人バラバラのメーカーのものを導入しています。これではウイルス感染した PC に関しての情報を会社側で把握することが難しく、問題の発生した PC から漏れたウイルスが社内ネットワークに広まってしまう可能性があります。

社内ネットワーク側にウイルス検知システムが導入されていない 

　社内の VPN 機能付きルータ自身には基本的なファイアウォール機能が搭載されており、公開ポートを限定できるようになっていますが、リモートデスクトップ経由やその他の手段で到達したウイルスやマルウェアは、そのまま社内ネットワークに入り込んでしまうことになります。

　在宅スタッフが VPN 経由でウイルス付きのファイルを社内サーバーに配置してしまったり、ウイルスが添付されたメールを社内スタッフ向けに転送してしまったというトラブルが発生しています。

BYOD(自前)PC の用途が厳格化されていないため、セキュリティリスクが高まる

　上図の例を取ると、スタッフB とスタッフC は自前 PC を使用してテレワークを行っていますが、自前ということで業務以外の目的に PC を使うことが前提となります。つまり、業務目的以外に PC を使うというだけで、セキュリティリスクに晒されやすくなってしまうのです。会社はスタッフがどんな私用ソフトを自前の PC にインストールしているかも把握できませんし、業務時間外のネット利用を禁止するわけにもいきません。私用でインストールしたソフトウェアによって PC がウイルス感染したり、私用メールを開いた途端に PC がウイルス感染したというケースも多く発生しています。


　取り急ぎテレワーク環境を整えた企業は、上記のようなセキュリティの甘い構成になっていることが多いのではないでしょうか？

　最近では、テレワーク化が原因でデータ流出やウイルス感染が発生したことがニュースにもなっています。
　VPN 経由だからこそデータが流出しやすくなることがあることも忘れないようにしてください。

　参考ニュース記事：
　テレワークで情報流出　ＶＰＮの脆弱性を悪用
　在宅勤務時にＰＣウイルス感染　不正アクセス、従業員情報が流出―三菱重工
　

セキュリティの高いテレワーク構成には、セキュリティの一元管理が必要

　テレワークを安全に行うためには、企業ネットワーク側から各 PC の状態をある程度把握できる仕組みが必要となります。
　たとえば、クラウド管理型のアンチウイルスシステムを導入し、在宅スタッフの PC でウイルスが検出された場合にその通知が社内のスタッフに送信されるようにします。また、社内のルータを侵入検知機能付きのものに変更し、在宅スタッフ側で防げなかったウイルスやマルウェアを社内ネットワークの入り口で完全にシャットアウトします。

　以下のように構成します。

 

テレワーク環境の改善
テレワーク環境の改善


クラウド型アンチウイルスシステム Panda Endpoint Security の導入

　弊社では、クラウド型アンチウイルスシステムとして、Panda Endpoint Security を導入しています。各クライアント PC に Panda Antivirus というソフトウェアをインストールすることにより、各PC のウイルス対策はもちろんのこと、感染や検疫が行われた記録はすべてクラウド上に通知され、担当者にその旨メールが送信されます。

　https://www.pandasecurity.com/en/business/solutions/ [英語]


SonicWall ルーターによるファイアウォール、アンチウイルス、サービス遮断

　SonicWall はルーター機能の他に、より柔軟性の高いファイアウォール機能が搭載さてれいます。不要ポートの遮断はもちろんのこと、各PC の IPアドレスやMACアドレス別に接続を許可したり、アクセス許可の範囲を決定したりできます。

　また、アンチウイルスおよび侵入検知機能も用意されているため、VPN 経由で侵入したウイルスやマルウェアも SonicWall ルータによって検疫の対象となり、社内ネットワーク上のウイルス蔓延を未然に防ぐことができます。

　さらに、特定のサービス（チャット、ゲーム、P2Pなど）を遮断したり、特定のサーバへのアクセスを遮断したりすることができるため、業務中にそれらのサービス使用によるトラブルを回避できます。

　https://www.sonicwall.com/ja-jp/

　弊社では Panda Cloud Security および Sonicwall によるネットワーク構築を支援するサービスを承っております。
　詳細はこちらをご覧ください。
　セキュリティとネットワーク構築

Amazon Workspaces の一部導入

　上図のスタッフC 経理は自前PC の OS 互換性の理由により、社内の Windows PC にリモートデスクトップ接続して経理ソフトウェアを操作しています。このため、経理一人のために本社の PC/仮想マシンを稼働させておく必要があります。
　将来的に経理担当を増やしたり、不要な稼働マシンの削減を考慮して、オンデマンドで起動できる Amazon Workspaces というクラウド型の Windows 仮想マシンを用意することによって、必要時にのみ Amazon Workspaces 上で経理ソフトを操作させる選択肢もあります。
　Amazon Workspaces はデスクトップ越しのファイル送信やコピー＆ペーストが許可されないため、操作ミスによる情報漏洩のリスクも低減できます。

　弊社では Amazon Workspaces の導入に関するコンサルティングから導入まで支援するサービスを承っております。
　詳細はこちらをご覧ください。
　AWS導入サービスについて

その他考慮すること

　企業によってテレワークのセキュリティポリシーをスタッフ別に考慮する必要も出てきます。たとえば、ネットワーク管理者であれば自宅から遠隔操作でほぼすべての社内リソースにアクセスできる必要があるでしょうし、社員の印刷やファイル交換の可否のセキュリティポリシーをグループまたは担当者別に設定する必要があるでしょう。
　また、外注スタッフに一部のシステム操作を許可する場合にも、アクセス可能時間を限定したり、IP/MAC アドレス別にアクセスを制御したり、機能が制限された Amazon Workspaces 上のみで操作を許可するようにしたりと、不正操作を未然に防止する必要もあるでしょう。


テレワークのセキュリティポリシー
テレワークのセキュリティポリシー

　また、各スタッフの PC のドライブや外付けデータドライブ等も暗号化しておくことも重要です。これにより、万が一 PC や外付けデータドライブが盗難にあったとしても、データを復元できないため、データ自体は機密情報であっても、その中身を覗かれてしまうリスクを回避できます。
　ドライブの暗号化は、Windows 10 なら標準搭載の BitLocker、macOS も 標準搭載の FileVault を使うことができます。

テレワークを成功させるには、各人の心がけありき

　上記のテレワーク構成は、それぞれのスタッフが万が一ネットワーク越しにうっかりミスをやらかしたときの基本的なセーフティネットを提供するにすぎません。 

　いくらスタッフA 管理者が会社支給の PC を使用しているからといって、個人情報の取り扱いに問題のあるネット対戦ゲームソフトを勝手にインストールしたり、業務中や業務時間外に怪しいサイトを閲覧したりして、セキュリティリスクを高めてしまっているようでは元も子もありません。

 スタッフB 開発者が、最強のPCを自作したとしても、その PC が故障してしまったら、業務はそこで停止しますし、VPN 経由で気を付けて本社サーバにアクセスしても、サーバの設定ミスでうっかり機密情報が外部に漏洩してしまうこともあります。

スタッフC の経理は自前PC の OS 互換性の理由により、社内の Windows PC にリモートデスクトップ接続して経理ソフトウェアを操作していますが、経理一人のために本社の PC/仮想マシンを稼働させておく必要があります。将来的に経理担当を増やしたり変更したりすることも考えて、オンデマンドで起動できる Amazon Workspacesというクラウド型の Windows 仮想マシンを用意し、必要時にのみ Amazon Workspaces 上で経理ソフトを操作するようにする選択肢もあります。

　企業の中には、きちんと成果さえ出せばいつ、どこで勤務しても良いという、労働条件の自由度が高いところもあるかもしれませんが、だからといって安易に喫茶店の無料 wi-fi を使って作業をすれば、個人情報や機密情報が外部に漏洩するリスクが発生しますし、赤の他人に横から情報を覗き見される危険性もあります。また、ワーケーションと称して観光地のホテルの一室で作業をしたりする際にも、機器の盗難リスク、紙の資料紛失、セキュリテイの甘い wi-fi 環境によるデータ漏洩のリスクも発生しやすくなります。働き方は自由でも、スタッフに課される責任として企業データや個人情報の保護を考慮すると、セキュリティ対策に自信のある人のみに許された自由ということになるのかもしれません。

 

土屋企画のテレワーク関連サービス
　弊社ではテレワークを検討されている企業様向けに検討から導入まで支援するサービスを提供しております。詳細は以下のリンクをご参照ください。
セキュリティとネットワーク構築
リモート開発/テレワークについて
AWSとテレワーク


By 時刻: 0 件のコメント:
ラベル: , , ,

2020-07-06

IIS6 + FileMaker Web Companion/Web Server Connector 構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する

Web ブラウザの TLS1.0/1.1 無効化により Web ブラウザで警告が発生


2015/10/05 に大手4社のWebブラウザが 2020年にTLS 1.0と1.1を無効化すると発表し、2020/07/01 より順次対応が始まった模様です。


今回の Web ブラウザのセキュリティ強化により、最新版の Web ブラウザを使って TLS1.2 非対応の Web サーバにアクセスすると、以下のような警告が Web ブラウザに表示されることがあります。

（以下は 最新のFirefox でアクセスしたときのエラー）

TLS1.2 に対応していないときに Web ブラウザに表示されるセキュリティエラー（Firefox）
Firefox で表示される エラーコード: SSL_ERROR_UNSUPPORTED_VERSION

Windows Server 2003 IIS6 は TLS1.2 非対応のため、別途対策が必要


　新たなセキュリティホールや脆弱性は日々発見されており、サーバOS も Webサーバもアップデートが提供されているものを使用し、できるだけ迅速にアップデートを行うことが推奨されます。しかし、OSやWebサーバのアップデートを行うにはシステムの修正や再構築が必要となり多額の費用が発生することが多々あり、このため止むを得ずレガシーシステムを使わざるを得ない、ということもあります。

　さて、FileMaker 5.5 Unlimited に付属する Web Companion や Web Server Connector は、FileMakerデータベースとIISの橋渡しをしてWebアクセスを可能にするものですが、Web Companion/Web Server Connector は Windows Server 2008のIIS7では動作しません。このため、Windows Server 2000/2003 IIS5/6 と FileMaker Pro 5.5 Unlimited（Web Companion/Web Server Connector）により、Webサイトを運用している企業はいまだにあると思われますが、ここで問題が発生します。IIS5/6 は TLS1.0 までしか対応していないため、この7月以降は上図のようなエラー/警告が発生します（エラーや警告はブラウザによって異なります）。 

Windows Server 2003 IIS6 のサーバ構成（TLS1.2 非対応）

リバースプロキシサーバ + IIS6 で Web サーバを構築

　さて、ここからが本稿の本題です。IIS5/6 + WebCompanion/Web Server Connector を使用しながら、どうすればTLS1.2以降による暗号化を可能にするかということですが、TLS1.2以降に対応した リバースプロキシサーバを立てることによって実現できます。 今回は nginx 1.18.0 によりリバースプロキシサーバを構成しました（下図）。

　この構成により、既存の IIS6 の設定を若干変更するだけで、セキュリティが強化され、Web ブラウザに警告・エラーが表示されなくなります。

nginx リバースプロキシ + II6 によるサーバ構成
nginx リバースプロキシ + II6 によるサーバ構成


 　以下、設定方法となります。

　なお、本稿はボランティアで提供しており、その内容や結果は保証できません。「書いてある通りにやったら、サーバが壊れた！　責任取れ(怒)！！！」とか、ホントにやめてくださいね。ただ、実行結果をコメントで残して頂く、とかなら大歓迎です。

  1. 既存の証明書の購入元から、PEM 形式の証明書とその秘密鍵を入手
    取得方法はサーバ証明書発行サイトによって異なりますので、詳細は証明書発行会社にお問い合わせください。
    入手した証明書ファイルと秘密鍵ファイルは、C ドライブ以外のできるだけ安全なフォルダに配置しておきます。

  2. IIS6 にインストールされている証明書を削除
    インターネットインフォメーションサービスマネージャを開き、「規定のWebサイト」まで展開し、マウスを右クリックしてプロパティを開きます。


    図のように“サーバー証明書(S)”をクリックし、処理の一覧から「現在の証明書を削除する(R)」をクリックし、“次へ”をクリックします。
    削除前の確認メッセージが出ますので、“次へ”をクリックすると、IIS から証明書が削除されます。

  3. IISの Web サーバポートを変更
    引き続き「Webサイト」タブをクリックし、ポート番号として以下のように入力します。

    IIS6 側のサーバポートを 80 以外に変更
    IIS6 側のサーバポート変更

    TCPポート：8080 (80以外であれば何でも可)
    SSL ポート：（空欄）

  4. nginx をダウンロードし、任意の場所に配置（インストール）

    https://nginx.org/en/download.html にアクセスし、Windows 用の最新安定バージョンをダウンロードし、解凍して任意の場所に配置します。
    今回は nginx/Windows-1.18.0 をダウンロードします。
    ※ Windows Server 2003 環境で解凍を行うと、実行ファイルが自動削除される可能性があります。その場合は、別の PC 上で解凍した後に Windows Server 2003 環境に配置しなおしてください。

  5. nginx.conf ファイルの修正

    nginx フォルダ配下の conf フォルダに配置されている nginx.conf ファイルをリバースプロキシとして動作させるために、以下のように修正します。

    ※事前にnginx.cfg ファイルのバックアップをお取りください。

    以下、環境別に設定が異なる部分は適宜調整してください。

    nginx.conf
    
#user  nginx;
worker_processes  1;

events {
    worker_connections  1024;
}


http {

    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  logs/access.log  main;

    server_tokens off;
    sendfile        on;
    tcp_nopush     on;

    keepalive_timeout  65;

　　gzip on;
    gzip_types text/css application/javascript application/json 
               application/font-woff application/font-tff image/gif 
               image/png image/jpeg application/octet-stream;
    
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;


    server {
 
        listen 80;
  
        server_name  yourdomain.co.jp;

        location / {
           proxy_pass http://127.0.0.1:8080;
        }
        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

    }

    # HTTPS server
    #
    server {
        
        listen 443 ssl;
        server_name yourdomain.co.jp;

        ssl_certificate     d:\\app\\cert\\fullchain.pem;
        ssl_certificate_key d:\\app\\cert\\privkey.pem;
  
        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;
        ssl_ciphers ECDHE+RSAGCM:ECDH+AESGCM:DH+AESGCM:DH+AES256:DH+AES:
                   !EXPORT:!DES:!3DES:!MD5:!DSS;
        ssl_prefer_server_ciphers on;

        location / {
           proxy_pass http://127.0.0.1:8080;
       }
       
    }

}

    proxy_pass で示された URL のポート番号は、手順 3. で指定したものを入力します。
    HTTPS サーバブロックの proxy_pass にも同じものを入力します。

    ここまで修正したら設定ファイルを上書き保存します。

  6. nginx 起動テストを実行

    コマンドプロンプトを開き、nginx フォルダまで移動してから、以下のように入力します。

    nginx

    ※ 起動直後にポートアクセスへの許可を求めるダイアログが表示されたら、すべて許可しておきます。

    Web ブラウザを開き、従来の URL にアクセスします。
    警告メッセージが出ずに従来の Web ページが表示されれば成功です。

    前述の nginx.conf 設定で証明書の設定も行っていますので、http://、https://　ともにアクセステストを行ってください。

  7. nginx を停止

    nginx 起動テストに成功したら、いったん nginx を停止させます。
    コマンドプロンプトをもう一つ開き、以下のように入力します。

    nginx -s stop

    nginx プロセスが終了します。

  8. nginx を Windows サービスとして登録

    nginx を Windows サービスとして登録して常駐させるには、winsw という外部ツールを使います。

    以下のサイトより　winsw というツールをダウンロードします。
    https://repo.jenkins-ci.org/releases/com/sun/winsw/winsw/

    ここでは最新版の winsw-2.9.0-bin.exe  をダウンロードします。
    ダウンロード済みの実行ファイルは任意の場所に配置してもよいのですが、nginx と同じフォルダに配置したほうが管理はしやすいかと思います。

    winsw-2.9.0-bin.exe ファイルを配置したら、同じフォルダの中に winsw-2.9.0-bin.xml という名称で空のファイルを作成し、テキストエディタで開きます。

    winsw-2.9.0-bin.xml ファイルに以下のように入力します。
    以下、nginx.exe へのパスは適宜調整してください。

    winsw-2.9.0-bin.xml
    <service>
  <id>nginx</id>
  <name>nginx</name>
  <description>nginx</description>
  <logpath>D:\Program Files\nginx-1.18.0\logs</logpath>
  <logmode>roll</logmode>
  <depend></depend>
  <executable>D:\Program Files\nginx-1.18.0\nginx.exe</executable>
  <startargument></startargument>
  <stopexecutable>D:\Program Files\nginx-1.18.0\nginx.exe</stopexecutable>
  <stopargument>-s</stopargument>
  <stopargument>stop</stopargument>
</service>

    修正が終わったらファイルを保存します。

    コマンドプロンプトを開き、winsw-2.9.0-bin.exe　を配置したフォルダまで移動し、以下のように入力すると、nginx がサービスとして登録されます。

    winsw-2.9.0-bin.exe install

    インストールに成功すると、以下のような結果が表示されます。

    2020-07-04 00:06:46,000 INFO  - Installing the service with id 'nginx'

  9. nginx サービスの開始
    Windows サービスに nginx が登録されていることを確認し、“開始”をクリックすると nginx が起動し、稼働状態となります。
  10. サーバ動作最終チェック
    Web ブラウザを開き、従来どおりに Web サーバにアクセスし、無事にページが表示されれば終了です。

お疲れさまでした。

    おまけ：

    nginx を Windows サービスから削除する場合は、コマンドプロンプトで以下のように入力します。

    winsw-2.9.0-bin.exe uninstall


    ■ FileMaker 5/6等レガシーシステム関連記事

    太古の FileMaker システムを延命させる！ ― 後日談FileMaker（17/09/07投稿）
    下記記事のレガシー延命スキームの実施と結果について。

    太古の FileMaker システムを延命させる！（17/04/25投稿）
    Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

    FileMaker 5.5/6 をモバイルで使う（16/05/25投稿）
    Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。
     
    今なお輝くFileMaker 5.5/6（16/05/23投稿）
    レガシーFileMaker の意外な利点。



    （亀）



    By 時刻: 0 件のコメント:
    ラベル: , , , ,
    登録: 投稿 (Atom)