読者です 読者をやめる 読者になる 読者になる

みなりん*のブログ

内容はなんでもありです。暗号通貨に特化している訳ではありません。

AUKEY Flashlight LT-SET7 高輝度懐中電灯(Amazonクーポン付き)

AUKEY FlashLight LED

AUKEY FlashLight LT-SET7 高輝度懐中電灯を手に入れましたので、こちらでレビューしていきたいと思います(最後にクーポンコードがありますので、是非ご利用下さい)。

箱から出した状態です。ストラップは本来外れていますかこの写真では付けています。 f:id:mizunashi_rin:20170313002820j:plain パッケージ内容は以下の通りです。

  • 懐中電灯
  • 18650バッテリー2本(本体に入っています)*1
  • ユーザーマニュアル
  • 保証カード

そして、こちらの懐中電灯はこの様に分解できます(ライターは比較用です)。 f:id:mizunashi_rin:20170313003032j:plain

分解してみると理解しやすいと思いますが、この懐中電灯は電池を2つ使って使用する方法と、電池を1つにして、本体サイズを小さくして使う事が可能です。 そして、電池1本と電池2本での明るさ性能の違いはありません。単に使用時間が半分になるだけです。

気になるスペック詳細をまとめておきます。

  • 照射モード:Strong*2/High/Middle/Low と通常照射で4段階、及びSOSが使えます。
  • 最大光量:実測およそ800ルーメン 非常に明るいです。
  • 防水 耐久性:IPX6 水中では使用できませんが、雨の中での使用には問題はありません。
  • 動作電圧:3.7V/7.4V
  • 動作電力:10W
  • 動作時間:3.13時間 (Strong), 8.76時間(Lo)
  • 照射距離:261m
  • 電池のタイプ:18650 (充電器が別途必要となります)
  • 寸法:41 × 160mm / 41 × 230mm
  • 重量:174g / 250g
  • 材質:アルミニウム合金(非常時等に車のガラスを割る事もできます)

一昔前の500ルーメンのLED懐中電灯と大きさを比較してみます。 比較対象は、LED懐中電灯で知らない人は居ないと言われているGentos製です。 品番は、SF−705XPとなります。 f:id:mizunashi_rin:20170313005830j:plain

さらに、電池1本の場合と比較を行うと・・・ f:id:mizunashi_rin:20170313010240j:plain

もう、おもちゃみたいに小さく思えます。上が1kgで下が174gと全く重さが違います。

では、実際の暗闇の中でどのくらい見えるのか各モードでテストしてみましたので紹介させていただきます。

カメラの設定は、35mm換算80mm/ISO100/4秒/F5.6/ホワイトバランス6500Kの完全マニュアル撮影です。 人間の見た目より一回り拡大されている感じと理解していただければと思います。

【Low】既に通常の自転車のライトより明るいと思います。 f:id:mizunashi_rin:20170313014003j:plain

【Middle】27m先の柵が見える様になってきました。 f:id:mizunashi_rin:20170313014029j:plain

【High】100m先の家がわずかに見える様になってきました。 f:id:mizunashi_rin:20170313014049j:plain

【Strong】100m先の家はハッキリ見えます。 f:id:mizunashi_rin:20170313015229j:plain

【ライト無し】流石に真っ暗です。 f:id:mizunashi_rin:20170313020609j:plain

本来は、Gentosの500ルーメンのライトと比較を行いたかったのですが、勝負にならないと感じ比較を諦めました。 決してGentosのライトが暗いわけではありません。かなり明るいのですが、こちらのAukeyの商品と比べるのは意味が無いと感じました。

やはり時代と共に色んな商品が進化しております。

現在では、お湯を沸かしたり調理をしたり火を起こす事が可能なLEDライトが存在しますが、この製品は光に手をかざしても全く熱くありませんのでその点は問題ありません。

久々に明るいライトを手に入れる事ができ、非常に嬉しいです。


アマゾンでご購入の歳には、以下のクーポンが使用できます。

  • 対象製品:AUKEY LED 高輝度懐中電灯 防水 5種類照射モード アルミニウム合金 グレー LT-SET7
  • クーポンコード:LTSET7AU
  • 有効期限:2017/3/13 17:00~2017/3/19 23:59

*1:本体の電池と電池の間に絶縁テープがありますので初めて使用する時は取り除いて下さい

*2:10分を経過すると自動的にHiモードになります

本家にも記載がないスーパーノードを辞める方法(公式)

NEM スーパーノード NEM 暗号通貨 IT

本家サイト、nem.io にも記載されていないと思われる、スーパーノードを辞める方法を説明します。 この方法は、NEM Coreから情報を得て書いていますので公式な方法です。

前提条件

スーパーノードのエイリアス名(enroll した時に指定した名前)が、<MyAwesomeSupernode> という前提とします。

1. 無効にするスーパーノードエイリアス名をフォーラムに投稿*1

nem.io内の下記のスレッドに投稿します。

forum.nem.io

内容は、下記の様に書き込んでください。

Please disable supernode <MyAwesomeSupernode>

2. Walletからメッセージの送信*2

次のアドレスにメッセージを送信します。送信する時は、enrollを行なったアカウントから送信してください。

送信先アドレス:NALICE-PFLZQR-ZGPRIJ-TMJOCP-WDNECX-TNNG7Q-LSG3 送信内容:Please disable supernode <MyAwesomeSupernode>

*1:スーパノードを辞めるという事を伝える為に必要です

*2:あなたが実際にスーパーノードの所有者であることを確認する必要があります

NCCからNanoWalletへの移行

NEM 暗号通貨 IT

NanoWalletは、「Changelly Instant Exchange」や「Apostilleブロックチェーン公証サービス」が新たな新機能として実装されています。 今後はNanoWalletがデスクトップクライアントとして主流になります。

今回はNCCウォレットからNanoWalletに移行する方法を説明していきます。

Step 1

f:id:mizunashi_rin:20170301003541p:plain

  1. NCCウォレットを開きます
  2. ロックアイコンの左にある下矢印をクリックします
  3. 「Export for Lightwallet」を選択します

Step 2

f:id:mizunashi_rin:20170301003854p:plain

  1. ウォレットのパスワードを入力します
  2. ブラウザからjsonファイルがダウンロードされます

Step 3

f:id:mizunashi_rin:20170301004019p:plain

  1. NanoWalletを開きます
  2. 「Login」を選択します
  3. 「Import Wallet」を選択します
  4. NCCで取得したjsonファイルをアップロードします

Step 4

f:id:mizunashi_rin:20170301004217p:plain

  1. ドロップダウンメニューでウォレットを選択します
  2. ウォレットをjsonファイルからwltファイルに更新するかどうかのプロンプトが表示されます
  3. NCCのウォレットパスワードを入力します
  4. ウォレットがアップデートされますので暫くお待ち下さい

Step 5

f:id:mizunashi_rin:20170301004714p:plain

  1. Step 4が完了するとブラウザからwltファイルがダウンロードされNanoWalletに自動的に取り込まれます
  2. ダウンロードされたwltファイルは必ずバックアップして下さい
  3. ドロップダウンメニューに新たに追加された名前を選択しNCCで利用したパスワードを入力してログインします

注意点

この状態で移行は終了しておりますが、Delegateアカウントは移行されておりません。NanoWalletのDelegate(Remote)アカウントは新しく発行されたものになっています。 スーパーノードの運用及びハーベスティングをしている方は、完全な移行とはなりませんので注意が必要です。 但し、NCCでのDeligate設定は生きていますので、NanoWalletでDelegateアカウントの設定を何もしなければ以前の情報のまま動作はしてくれます。

もしNCCを今後使用しないという場合は、NCCで設定したDelegateアカウントの設定を解除し、NanoWalletにて新しく設定をし直す必要があります。

NEM スーパーノードの構築 第4回(ログファイルの管理)

NEM スーパーノード NEM 暗号通貨 IT

今回はUNIXサーバで動いているNISサーバ及びservantサーバのログファイルについて解説します。多分NEMの公式サイトを見ても載ってない内容になるかと思います。

1. サーバに保存されるログファイル

NISサーバ及びservantサーバは、アプリケーションが独自で保存しているログファイルと、UNIXシステムが保存しているログファイルがあります。これらのログは同一のもので敢えて2箇所に保存しなくても良いと思います。 そして一番の問題はNISサーバのログがかなり多いという事です。

ここでは、次の様なディレクトリ構造を仮定して話を進めていきます。

設定の方針としては、サーバアプリケーションが保存するログを優先して保存を行い、システム側のログを少なくします。そして、システムの設定は変えずアプリケーション側の設定変更だけを行います。

1.1 アプリケーションに保存されるログファイル

アプリケーション側の設定として、ログファイルについて記載されているファイルは、以下のものがあります。

nem@localhost:~$ cd nemServer
nem@localhost:~/nemServer$ find . -name "*logalpha.properties" -print
./nis/logalpha.properties
./servant/logalpha.properties
./nix.logalpha.properties
./logalpha.properties
nem@localhost:~/nemServer$ 

これらのファイルの中身を書き換えながらテストを行なったところ、影響のあったファイルは次の2つです。

  • NISサーバのログ設定ファイル: ~nem/nemServer/nis/logalpha.properties
  • Servantサーバのログ設定ファイル: ~nem/nemServer/servant/logalpha.properties

ここでNISサーバのログ設定ファイルの中身を見ます。

handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler
.level = INFO (← A)

java.util.logging.ConsoleHandler.formatter = org.nem.deploy.ColorConsoleFormatter
java.util.logging.ConsoleHandler.level = INFO (← B)

java.util.logging.FileHandler.formatter = org.nem.deploy.NemFormatter
java.util.logging.FileHandler.limit = 100000000 (← C)
java.util.logging.FileHandler.count = 100 (← D)
java.util.logging.FileHandler.pattern = ${nem.folder}/nis/logs/nis-%g.log

java.util.logging.SimpleFormatter.format = %1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS.%1$tL %4$s %5$s%6$s (%2$s)%n

ここでA〜Dについて説明します。

  • A:監視するログレベルを記載します。ここでの設定で監視する対象をを絞ってしまうと、アプリケーションログ及びシステムログ両方の出力に影響を及ぼします。前提条件として、アプリケーションログは全て保存するという条件で良いならば、このまま変更せずINFOのままにしておきます。
  • B:システムログに出力するログファイルの対象を記述します。私の場合はログを1段階絞る設定をする為に、WARNINGと書き換えました。
  • C:ログファイルがこのByte数になったらローテートを行います(またサービスの再起動を行なった場合にもローテートされる様です)。流石に現在の設定ですと、1つのログファイルが最大で100MBになってしまいます。私の場合はこちらを10MBに設定を変更しました。
  • D :保存するログファイルの個数です。こちらは設定変更しませんでした。なお、NISサーバのアプリケーションログは、最新のものがnis-0.log というファイル名になります。ここから100個保存するので、ローテートされて出来る最古のファイルはnis-99.logとなります。 なおこちらの数値を少なく設定変更しても、既に出来てしまっているファイルは消去されませんので、必要に応じて削除を行なって下さい。

Bの設定については私的に推奨します。システムのログを作成するUNIXシステムの実装又は設定方法によって色んな形態が考えられますが、色々なログが1つのファイルに混ざってしまう事により、検索に時間がかかったり他の重要なログを見逃す事になります(httpdのログがシステムのログと混ざって保存されている様な感じと捉えていただければ分かりやすいと思います)。

C及びDの部分の設定で、ログファイルの最大サイズが決まります。初期状態の設定では100MBのファイルが100個作成されますので、最大で10GBのログを保存する事になります。 最近では、25GBのディスク容量のレンタルVPSサーバがある時代です。 ディスク容量が元々少ない場合には、ログを溢れさせない様にする1つの手段としてCの値の変更を行なっています。 逆に言えば、容量が十分あるのであれば、保存するサイズを小さくする必要はありません。

以下が上記の説明にあった私の変更点を反映したNISサーバのログ設定ファイルです。なお、変更する場合は念のためcp -p logalpha.properties logalpha.properties.orgとしてコピーを保存しておくと良いでしょう。

handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler
.level = INFO

java.util.logging.ConsoleHandler.formatter = org.nem.deploy.ColorConsoleFormatter
java.util.logging.ConsoleHandler.level = WARNING (←変更点)

java.util.logging.FileHandler.formatter = org.nem.deploy.NemFormatter
java.util.logging.FileHandler.limit = 10000000 (←変更点)
java.util.logging.FileHandler.count = 100
java.util.logging.FileHandler.pattern = ${nem.folder}/nis/logs/nis-%g.log

java.util.logging.SimpleFormatter.format = %1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS.%1$tL %4$s %5$s%6$s (%2$s)%n

servantのログファイルもほぼ同一ですので、同じように書き換えて下さい。

なお、アプリケーション側が保存するログファイルは、下記のディレクトリに入っていますので参照して参考にしていただければと思います。

  • NISサーバ:~nem/nem/nis/logs
  • Servantサーバ:~nem/nem/node-rewards/servant/logs

そして、この設定を反映するために、NISサーバ及びServantサーバの再起動を行なって下さい。

1.2. システムに保存されるログファイル

ここは、使っているOS及び設定によって色々なパターンがありますが、基本的には下記の種類に分けられると思います。

  • /var/log/syslog
  • /var/log/messages
  • upstart (/var/log/upstart の配下のログ)
  • systemd(journalctl -f 等で参照)

NEM スーパーノードの構築 第2回 の場合はupstart第3回の場合は、systemdとなります。

システムのログファイルを参照し、INFOレベルのログが出力されてなければ、正常にログファイルの設定ファイルが反映されている事となります。

2. サーバシステムを運用しているという心構え

ログファイルの増大は、システムの安定性に関わります。サーバを運用するにあたっては、定期的にログファイルを見る事でシステムの異常を感知する事が出来ます。しかしながらログファイルも増え続ければディスクを圧迫し、システムが不安定になったりサービスが終了する事もあります。自動でログファイルが増大しない様に処理をしていても、異常が起きてログファイルが膨大に生成される可能性もあります。

特にNISサーバのログは大変多くのディスク領域を消費し2箇所に保存しているという事から、ログファイルを減らすという事を主眼としてこちらの記事を作成しております。

NEMのスーパーノードは、スーパーノード報酬を得たいという理由から構築する側面もありますが、それはスーパーノードがNEMのネットワークに必要とされているからです。サーバが停止する事で、スーパーノード報酬が得られないのではなく、構築されたサーバを利用しているノードが存在している事も忘れない様にしていただきたいと考えます。

NEM スーパーノードの構築 第3回(サーバ設定編 Ubuntu 16)

NEM スーパーノード NEM 暗号通貨 IT

第1回・第2回と、DTIの提供するServersMan@VPSを例にして紹介させていただきました。今回はパトロン様のご提供にて、GMOVPSでNEMのスーパーノードを構築させていただきました。本当にありがとうございます。

f:id:mizunashi_rin:20170218082433p:plain

こちらのサーバにて今回利用するプランの概要は次の通りです。

  • VPS スペック
    • CPU 仮想2Core
    • ディスク 50GB
    • メモリ 1GB
  • OS

多くの点で同じ作業となりますので、基本は下記の記事を参照してください。こちらには上書き部分を記載しています。

blog.minarin.moe

まずは前記事の1.〜2.9章までの記事を参照してスーパーノードを構築する部分まで終了させます。

前回のOSUbuntu14を使用しておりましたが、今回のOSバージョンではシステムのプロセス管理方法が新しいもの(systemd)に変わっております。一件似てる様に思えても、最新の管理方法を採用しておりますので、私自身初めてです。

では、ここから本題に入ります。基本的に以下で表示される章番号は、前の記事を上書きする形となります。

2. サーバ側の設定

2.10 自動起動の設定

本章2.7迄でスーパーノードとしてきちんと動作をしております。但し、サーバが何かしらの理由で再起動した場合や、NISやServantプログラムが単体で異常終了してしまった場合には、スーパーノードとして動いていない事となり報酬も得られません。

ここでは、サーバ起動時に自動でサービスをスタートされる事と、プロセスの異常終了時に自動的に再起動させる設定を行います。

まずは、NISサーバの自動起動ファイルを作成します。

以下の内容のファイル/etc/systemd/system/nem-nis.serviceをroot権限にて新規に作成します。

[Unit]
Description = NEM NIS Server
After = network.target

[Service]
WorkingDirectory = /home/nem/nemServer
ExecStart = /home/nem/nemServer/nix.runNis.sh
Restart = always
Type = simple
User = nem
Group = nem
[Install]
WantedBy = multi-user.target

もしも、エディター等不慣れな場合は、次の方法で作成する事もできます。ここでは、catコマンドを使って標準入力からファイルの内容を書き込みます。

root@localhost:/~# cd /etc/systemd/system
root@localhost:/etc/systemd/system# ls nem-nis.service
ls: cannot access 'nem-nis.service': No such file or directory
 (その名前のファイルやディレクトリが存在しないと言われます)
root@localhost:/etc/systemd/system# cat > nem-nis.service
 (ここにファイルに記述する文字列を一気にペーストします)
 (ペースト後カーソルが行頭に無い場合は一度リターンキーを押し改行します)
 (CTL-d を入力すると標準入力が閉じファイルが作成されます)
root@localhost:/etc/systemd/system# ls nem-nis.service
nem-nis.service
root@localhost:/etc/systemd/system# 

作成しましたら、chmod 755 /etc/systemd/system/nem-nis.serviceを実行し、実行権限を付与します。

同様な操作で、以下の内容のファイル/etc/systemd/system/nem-servant.serviceをroot権限にて新規に作成します。

[Unit]
Description = NEM Servant program
After = network.target nem-nis.target

[Service]
WorkingDirectory = /home/nem/nemServer/servant
ExecStart = /home/nem/nemServer/servant/startservant.sh
Restart = always
Type = simple
User = nem
Group = nem
[Install]
WantedBy = multi-user.target

作成しましたら、chmod 755 /etc/systemd/system/nem-servant.serviceを実行し、実行権限を付与します。

最後に追加した2つのファイルをsystemdに教えてあげる為に、systemctl daemon-reloadのコマンドを実行しておきます。

上記登録方法で登録した方法で起動テストを行いますので、現在動いているNISとServantのプロセスを停止します。

root@localhost:/# pgrep -fl org.nem  (※Ubuntsu14 では、-fa でしたので間違わない様に!)
459 java -Xms512M -Xmx1G -cp .:./*:../libs/* org.nem.deploy.CommonStarter 
477 java -Xms256M -Xmx256M -cp .:jars/* org.nem.rewards.servant.NodeRewardsServant 
 (※ここで表示された先頭の数字が後ろに続くプロセスのプロセスIDとなります)

root@localhost:/# kill -SIGTERM 459 477
 (又は)
root@localhost:/# pkill -SIGTERM -f org.nem

root@localhost:/# pgrep -fl org.nem (何も表示されなければプロセスは終了しています)
root@localhost:/# 

現在は、NISサーバ及びServantプログラムが停止している状態ですので、再起動時の自動起動の設定を行なった上で手動で起動させてみます。

root@localhost:/# systemctl enable nem-nis.service
root@localhost:/# systemctl enable nem-servant.service
root@localhost:/# systemctl start nem-nis.service
root@localhost:/# systemctl start nem-servant.service
root@localhost:/#

これで、問題がなければNISサーバとServantサーバは正常に起動しているはずです。 念のためにきちんと動作をしているか調べます。systemctlコマンドを使って調べる事も可能ですが、プロセスを見た方が簡単なので以下の様に確認します。

root@localhost:/# pgrep -fl org.nem (※Ubuntsu14 では、-fa でしたので間違わない様に!)
8873 java -Xms512M -Xmx1G -cp .:./*:../libs/* org.nem.deploy.CommonStarter 
8887 java -Xms256M -Xmx256M -cp .:jars/* org.nem.rewards.servant.NodeRewardsServant 
root@localhost:/#
 (10秒程待ち同じコマンドを実行します)
root@localhost:/# pgrep -fl org.nem
8873 java -Xms512M -Xmx1G -cp .:./*:../libs/* org.nem.deploy.CommonStarter 
8887 java -Xms256M -Xmx256M -cp .:jars/* org.nem.rewards.servant.NodeRewardsServant 

この時、コマンドを実行した時に先頭に表示されるプロセスIDが同一であれば正常に動いています。 もし、数字が異なっている場合は、一度下記の様にしてプロセスの起動を停止します。

root@localhost:/# systemctl stop nem-nis.service
root@localhost:/# systemctl stop nem-servant.service
root@localhost:/# systemctl disable nem-nis.service
root@localhost:/# systemctl disable nem-servant.service
root@localhost:/#

うまく動作しない場合は、もう一度2.10章で作成したファイルが間違ってないかどうか確認しながらやり直してみてください。 問題なく動いている様であればsystemdの設定は終了です。

2.10.1 ログファイルの設定変更(新章)

この時点でNISサーバとServantプログラムは正常に動いていますが、ログファイルに問題があります。 現状では、詳細なログファイルは再起動と共に捨てられてしまいます。更には通常のログは/var/log/syslogにリアルタイムに出力され続けます。NISサーバの出力するログファイルはかなり多いので、他のログは埋もれてしまう事になります。

ここでは、journalシステムの設定変更を行います。

まず、mkdir /var/log/journal コマンドにて、journalディレクトリを作成します。journald(正確にはsystemd-journald)はメモリー領域に詳細なログを貯めているのですが、このディレクトリを作るとその配下に情報を貯める様になります。実際のログファイルの閲覧には、journalctlコマンドを使います。

次に、syslogファイルにも出力しているので、これを出力しないようにします。設定ファイルは、/etc/systemd/jounald.confです。

root@localhost:/var/log# cd /etc/systemd/
root@localhost:/var/log# cp -p journald.conf journald.conf.org

 32行目を編集します
 32c32
 < #ForwardToSyslog=yes (編集前)
 ---
 > ForwardToSyslog=no (編集後)

root@localhost:/var/log# systemctl restart systemd-journald.service (jounaldの再起動)

tail -f /var/log/syslogコマンドにて、NISサーバ等のメッセージが流れる様に出てこなければ問題ありません。 そして、NISサーバ等のログは、jounalctlコマンドで参照する事ができます。リアルタイムにログを見るのであれば、journalctl -fと入力します(この場合サービスを指定していませんので、systemの全てのログが流れていきます)。

なお、jounaldが保存するログファイルは、デフォルトの設定ではディスクの全容量に対して10%以上になった場合、または空き容量が15%以下になった場合に、古いエントリーから順に削除されます。ここでは行いませんが、任意に容量を指定する事も可能です。

あとがき

いかがでしたでしょうか。同じOSでもバージョンによってこれだけ大きく変化をしていきます。 プロセス管理方法は、時代的に他のUNIXでも SysVinit → upstart → systemd へと進化をしています。

今後は、他のOSをレンタル出来る機会があれば、また記事を作成するかもしれません。 そして次回は、OS回りの設定を書きたいと思っています。

NEM スーパーノードの構築 第2回(サーバ設定編 Ubuntu 14)

NEM スーパーノード NEM 暗号通貨 IT

今回はNEMのスーパーノードのプログラムのセットアップを行います。

事前にスーパーノードを運用するVPSサーバや自宅サーバが必要になりますので、ここまでの準備は下記の以前の記事を参照して下さい。

blog.minarin.moe

UNIXはOSが違えば中に入っているコマンド等の構成が異なります。そして同じOSを使っていても全く同じという訳ではありません。これから説明する方法ではコマンドが違ったりする事も多々ある事をご留意下さい。

【注意】 この文書の説明は、記事作成時点でのDTIの提供する「ServerMan@VPS 1GB Ubuntu 14.04 LTS (64bit)のシンプルセット」を前提として書かれています。 他のVPSの記事も書きたいとは思っているのですが、無職上の理由に現在は作成する為の金銭的余裕がありません。パトロンを探しています。

1. 事前のクライアントの設定

スーパーノードを運用する時には、自分のアカウントに紐付けされたリモードアカウント(別名としてデリゲートアカウントと呼ぶ事もあります)が必要になります。NanoWalletのインストールを行った際に、NEMのアドレスを新規に生成、又は以前のウォレットからインポートを行ったと思います。この際にリモードアカウントは自動的に生成されます。

このリモートアカウントは、自分のNEMアドレスの秘密鍵とウォレットパスワードを元に生成されていますので、自分以外が同じリモートアカウントを生成する事はありません。逆に言えば、自分のウォレットにsecondaryアカウントとして別のNEMのアドレスを追加すると、異なるリモートアカウントが生成されます。

最近ですと、NCCで生成されるリモートアカウントとNanoWalletで生成されるリモートアカウントが異なる為に迷われる方が多くなっています。これはリモートアドレスの生成方法が変更された為に異なるアドレスが生成されています。(ソースコードより確認)

1.1 リモートアカウントの委任有効化

NanoWalletの「#各種機能」から「デリゲートアカウント(委任アカウント)管理」を選びます。 (委任ハーベストを既に実行されている場合はこちらの操作は既に操作済みとなりますので必要ありません。)

f:id:mizunashi_rin:20170213013440p:plain

下記の画面が表示されますので、左側の「インポータンストランスファートランザクション」の操作を行います。

ここでは、6XEMを手数料として支払い、リモートアカウントの委任有効化(Activate)を行います。送金ボタンを押しトランザクションが承認されれば、設定は完了となります。但し、実際に有効になる為には6時間待つ必要がありますので、事前に行なっておいた方がスムーズに作業が進みます。

なお、後で行う作業にて次の情報が必要になります。

  • 委任秘密鍵(ウォレットパスワードを入れ右の✓を押すと一時的に表示される)
  • 委任公開鍵

f:id:mizunashi_rin:20170213013615p:plain

2. サーバ側の設定

サーバが初期状態と仮定して説明をしていきます。スーパーノードの説明以外も記載しておりますので少し長めの内容となっております。

2.1 初めてサーバにログインする場合

rootのパスワードがメールにて送られてきていると思います。そのままでは危険ですので、任意のパスワードに変更します。

root@localhost:~# passwd
Enter new UNIX password: (変更後のパスワードを入力)
Retype new UNIX password: (再度入力)
passwd: password updated successfully

2.2 使わないサービスの停止

今回レンタルVPSサーバにログインしてみて要らないサービスは何かを調べたら、apache2(httpd)とxinetdという事がわかりました。 まずはこちらのサービスを停止させます。

2.2.1 apache2の停止

まず負荷のかかるWebサーバを実行する事はないと思います。 調べたところ、このサーバではSysvinitを使っている様でしたので、以下の様にしてapache2を停止させます。

root@localhost:~# service apache2 stop
 * Stopping web server apache2                                                                             * 
root@localhost:/#

もしくは

root@localhost:~# cd /etc/init.d
root@localhost:/etc/init.d# ./apache2 stop
 * Stopping web server apache2                                                                             * 
root@localhost:/etc/init.d# 

そして、次回からサーバを再起動させても起動しないように設定します。

root@localhost:/# update-rc.d -f apache2 remove 
 Removing any system startup links for /etc/init.d/apache2 ...
   /etc/rc0.d/K20apache2
   /etc/rc1.d/K20apache2
   /etc/rc2.d/S20apache2
   /etc/rc3.d/S20apache2
   /etc/rc4.d/S20apache2
   /etc/rc5.d/S20apache2
   /etc/rc6.d/K20apache2
root@localhost:/#

2.2.2 xinetdの停止

xinetd経由で起動するサービスで、特に必要なものはありません。 調べたところ、このサーバではUpstartを使っている様でしたので、以下の様にしてxinetdを停止させます。

root@localhost:/# service xinetd stop
root@localhost:/#

もしくは

root@localhost:/# initctl stop xinetd
xinetd stop/waiting
root@localhost:/#

そして、次回からサーバを再起動させても起動しないように設定します。

root@localhost:/# cd /etc/init
root@localhost:/etc/init# mv xinetd.conf xinetd.conf.disable
root@localhost:/etc/init#

2.3 Java 実行環境のインストール

NIS及びServantプログラムはJavaバイトコードで提供されています。この為、Javaの実行環境(JRE)をインストールします。PPAでは、Javaの実行環境のみのパッケージは提供されていませんので、Javaの開発環境(JDK)と実行環境両方をダウンロードします)。

root@localhost:~# apt-get update
root@localhost:~# apt-get -y install apt-file
root@localhost:~# apt-file update
root@localhost:~# apt-file search add-apt-repository
root@localhost:~# apt-get -y install software-properties-common
root@localhost:~# add-apt-repository ppa:webupd8team/java
root@localhost:~# apt-get update
root@localhost:~# apt-get -y install oracle-java8-installer
root@localhost:~# java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

最後にjava -versionコマンドにて、インストールが出来ているか及び最新のものが入っているかを確認します。

2.4 unzipのインストール確認

Servantプログラムを解凍する為にunzipを使用します。入ってない場合も多いですので、dpkgコマンドでunzipが入っているか確認します。

(入っている場合)
root@localhost:~# dpkg -l unzip
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  unzip          6.0-9ubuntu1 amd64        De-archiver for .zip files
root@localhost:~#

(入っていない場合)
root@localhost:~#
dpkg-query: no packages found matching unzip
root@localhost:~# 

unzipが入っていない場合には、次の様にしてunzipをインストールします。

root@localhost:~# apt-get install unzip

2.5 スーパーノード実行用アカウントの作成

以下の様にして、スーパーノードを動かすアカウント nemを作成します。

root@localhost:~# adduser nem
 (省略)
Enter new UNIX password: (nemユーサのパスワード設定します)  
Retype new UNIX password: (上記と同じものを再度入力)  
passwd: password updated successfuly  
Changing the user infomation for nem  
Enter the new value, or press ENTER for the default  
        Full Name []:(リターンキーで省略)  
        Room Number []:(リターンキーで省略)  
        Work Phone []:(リターンキーで省略)  
        Home Phone []:(リターンキーで省略)  
        Other []:(リターンキーで省略)  
Is the infomation correct? [Y/n] y  
root@localhost:~#

2.6 サーバからスーパーノードに必要なプログラムのダウンロードしインストールする

ここからは、rootユーザではなくnemユーザで作業します。 また、nemという名前は任意ですので、好きな名前で問題ありません。

以下の2つのファイルをダウンロードします。

  • NISサーバ(NCCも同梱されていますが使いません)
  • Servant(スーパーノードを監視するプログラム)
root@localhost:~# su -nem
nem@localhost:~$ pwd
/home/nem
nem@localhost:~$ wget http://bob.nem.ninja/nis-ncc-0.6.83.tgz
 (中略)
2017-02-08 08:50:00 (685 KB/s) - 'nis-ncc-0.6.83.tgz' saved [32222941/32222941]

nem@localhost:~$ wget wget http://bob.nem.ninja/servant_0_0_4.zip
 (中略)
2017-02-08 08:51:08 (754 KB/s) - 'servant_0_0_4.zip' saved [10582497/10582497]

nem@localhost:~$ tar xzf nis-ncc-0.6.83.tgz
nem@localhost:~$ unzip -q servant_0_0_4.zip
nem@localhost:~$ ls -l
-rw-rw-r-- 1 nem nem 32222941 Feb  2 20:51 nis-ncc-0.6.83.tgz
drwxrwxr-x 8 nem nem     4096 Jan  5  2016 package
drwxrwxr-x 3 nem nem     4096 Feb  3  2016 servant
-rw-rw-r-- 1 nem nem 10582497 Jun  1  2016 servant_0_0_4.zip
nem@localhost:~$ mv servant package
nem@localhost:~$ mv package nemServer
nem@localhost:~$ chmod -R g-w nemServer
nem@localhost:~$ ls
nemServer  nis-ncc-0.6.83.tgz  servant_0_0_4.zip
nem@localhost:~$ rm nis-ncc-0.6.83.tgz servant_0_0_4.zip
nem@localhost:~$

2.6.1 NISサーバの設定

nemのホームディレクトリの下に、nemServerというディレクトリが出来ていますので、./nemServer/nis/config.propertiesファイルを編集します。編集を行う前に、オリジナルファイルは別途保存しておきます。

nem@localhost:~$ cd nemServer/nis
nem@localhost:~/nemServer/nis$ cp -p config.properties config.properties.org
nem@localhost:~/nemServer/nis$ 

実際に変更を行うのはconfig.propaties内の次の行です。

46: #nis.bootKey = #0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
47: #nis.bootName = foobar

では、こちらに私が自分用に設定したファイルがありますので、差分を見てみます。 - - -より上が元の内容で下が変更後の内容です。

nem@localhost:~/nemServer/nis$ diff /home/nem/temp/nemServer/nis/config.properties  config.properties
46,47c46,47
< #nis.bootKey = #0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
< #nis.bootName = foobar
---
> nis.bootKey = 4d8cf75b12d41bdeb654bc42b5054b3e8df6cd722d9ed95d037d1190fe9cffca
> nis.bootName = MIZUNASHI

この編集は、次の作業を行なっています。

  • 先頭の#マークを外します
  • nis.bootKeyには、NanoWalletで表示される 委任プライベートキー を入力します
  • nis.bootNameには、自分が分かりやすい名前を自由に付けて下さい。

もしも、UNIXでファイルの編集出来ない方は、下記の方法もあります。但し、スペルミスがあるとファイルを壊してしまう可能性もありますので、その際には、 config.properties.org ファイルよりコピーしなおして復元してください。

nem@localhost:~/nemServer/nis$ perl -p -i -e 's/^#nis.bootKey.+$/nis.bootKey = 4d8cf75b12d41bdeb654bc42b5054b3e8df6cd722d9ed95d037d1190fe9cffca/' config.properties
nem@localhost:~/nemServer/nis$ perl -p -i -e 's/^#nis.bootName.+$/nis.bootName = MIZUNASHI/' config.properties
nem@localhost:~/nemServer/nis$ perl -p -i -e 's/^M//' config.properties  (注:^M は CTL+v CTL+m と入力してください)
nem@localhost:~/nemServer/nis$

以上で、NISサーバの設定は終わりです。

2.6.2 Servantサーバの設定

nemのホームディレクトリの下に、nemServer/servant というディレクトリが出来ていますので、./nemServer/servant/config.propertiesファイルを編集します。編集を行う前に、オリジナルファイルは別途保存しておきます。

nem@localhost:~$ cd nemServer/servant
nem@localhost:~/nemServer/servant$ cp -p config.properties config.properties.org
nem@localhost:~/nemServer/servant$ 

こちらの設定ファイルはかなり小さい設定ファイルですので、ファイルの内容全てを以下に記載します。

  1 # Common configuration
  2 # short server name
  3 nem.shortServerName = Servant
  4 
  5 # Specifies the maximum number of threads of the thread pool.
  6 nem.maxThreads = 500
  7 
  8 # protocol, ports, paths
  9 nem.protocol = http
 10 nem.host = <put vps ip address here>
 11 nem.httpPort = 7880
 12 nem.httpsPort = 7881
 13 nem.webContext =
 14 nem.apiContext =
 15 nem.homePath =
 16 nem.shutdownPath = /shutdown
 17 
 18 # Servant key configuration
 19 servant.key = <put your NIS boot key here>

実際に変更を行うのはconfig.propaties内の10行目と19行目だけです。

 10 nem.host = 172.31.100.28 (注: サーバのIPアドレスを指定しますがFQDNでも可)
 11 nem.httpPort = 7880
 12 nem.httpsPort = 7881
 13 nem.webContext =
 14 nem.apiContext =
 15 nem.homePath =
 16 nem.shutdownPath = /shutdown
 17 
 18 # Servant key configuration
 19 servant.key = 4d8cf75b12d41bdeb654bc42b5054b3e8df6cd722d9ed95d037d1190fe9cffca
        (委任アカウントのプライベートキーを入力します。NISサーバの設定で記入したものと同じです。)

nem.hostに記述する名前はFQDNでも可能ですが、IPアドレスの方が障害時に有利です。固定IPではない状況下でDDNSを利用しなければサーバを特定できない場合以外はIPアドレスで指定する事を推奨します。

この編集は、次の作業を行なっています。

  • nem.hostには、NISサーバを動かすIPアドレスを入力します
  • servant.keyには、NanoWalletで表示される 委任プライベートキー を入力します

もしも、UNIXでファイルの編集出来ない方は、下記の方法もあります。但し、スペルミスがあるとファイルを壊してしまう可能性もありますので、その際には、 config.properties.org ファイルより復元してください。

nem@localhost:~/nemServer/servant$  perl -p -i -e 's/^nem.shortServerName.+$/nem.shortServerName = 172.31.100.28/' config.properties
nem@localhost:~/nemServer/servant$  perl -p -i -e 's/^servant.key.+$/servant.key  = 4d8cf75b12d41bdeb654bc42b5054b3e8df6cd722d9ed95d037d1190fe9cffca/' config.properties
nem@localhost:~/nemServer/servant$  perl -p -i -e 's/^M//' config.properties  (注:^M は CTL+v CTL+m と入力してください)
nem@localhost:~/nemServer/servant$

以上で、Servantサーバの設定は終わりです。

2.7 仮実行してみる

nemユーザでログインし、NISとServantプログラムを実行します。 画面に色々とログが流れますので別のターミナルからログインした方が作業及び監視が楽になります。

nem@localhost:~$ cd ~/nemServer
nem@localhost:~/nemServer$ nohup ./nix.runNis.sh < /dev/null & (NISサーバの起動)
nem@localhost:~/nemServer$
nem@localhost:~$ cd ~/nemServer/servant
nem@localhost:~/nemServer/servant$ chmod u+x startservant.sh (実行権限がついていませんでしたので追加します)
nem@localhost:~/nemServer/servant$ nohup ./startservant.sh < /dev/null & (Servantの起動)
nem@localhost:~/nemServer/servant$

2つのプログラムを起動しました。それぞれのプログラムのログは、プログラムを実行したディレクトリにnohup.outという名前で保存されています。今回は仮実行ですので、正式に実行した場合は、後でnohup.outを削除します。 リアルタイムにログ・ファイルが見たい場合には、実行したディレクトリに移動し、tail -f nohup.outコマンドを打ち込む事でリアルタイムにログファイルを見る事が出来ます。

エラーメッセージを出してすぐに止まってしまわない様であれば設定は正確に行われていると思われます。NISサーバは時々エラーを出しますが特に問題は無いです。

NISサーバの最初の起動は、数時間かけてNISのデーターベースをダウンロードする作業があります。暫く別の事をする事をお勧め致します。

nohupコマンドは、sshの接続を切断した際に送られるSIGHUPを実行プロセスに渡さない様にする為のものです。また、バックグラウンドにて入力を受け付けない状態で動きますので、標準入力に /dev/null を指定しています。

2.7.1 NISデータベースを高速にダウンロードする(任意)

NISデータベースは現在99万ブロック程あり、データサイズでは987MBになります。他のスーパーノードとの通信でダウンロードする場合は何時間もかかってしまします。これを解消する為、あらかじめ用意されているNISデータをダウンロードして時間の短縮をはかる事もできます。

これは、初めてNISサーバを起動する場合だけではなく、データに不整合が発生し、NISサーバが正常に起動しなくなった場合にも利用可能です。

まず、次のディレクトリにアクセスをします。閲覧だけですので、お手元のPCからでも問題ありません。

別のタブでリンクが開きます → http://bob.nem.ninja

ここで表示されているファイルの中で、先頭がnis5_mainnetで始まり.h2.db.zipで終了するファイルを探します。 複数ある場合は日付が新しいものを選んでください。

私が現在見ている時点では、ファイル名が``nis5_mainnet-966500.h2.db.zipとなりました。以下このファイル名を例として説明します。では、ファイルのダウンロードをサーバで行なっていきます。

nem@localhost:~$ wget http://bob.nem.ninja/nis5_mainnet-966500.h2.db.zip (ファイルをダウンロードします)
 (中略) 
2017-02-19 14:42:01 (1.53 MB/s) - ‘nis5_mainnet-966500.h2.db.zip’ saved [295659941/295659941]
nem@localhost:~$ unzip -q nis5_mainnet-966500.h2.db.zip (解凍します)
nem@localhost:~$

私のサーバでは、ダウンロードに3分程、解凍に30秒程かかりました。

解凍後には、nis5_mainnet-966500.h2.dbというファイルができており、このファイルがNISのデータそのものとなります。ファイル名からも想像できると思いますが、このデータは966,500ブロック迄のデータです。このファイルを正式な場所に置く事によって、これ以降の差分のデータのみのダウンロードでNISデータベースが同期します。

あらたに、NISのデータベースを置き換える事になりますので、今まで保存されているデータは一旦全て削除する作業が必要です。それを含めて下記の様に作業します。 なおこの作業は、NISサーバを停止してから行って下さい。

nem@localhost:~$ ls ~/nem/nis/data/
nis5_mainnet.h2.db  nis5_mainnet.lock.db  nis5_mainnet.trace.db (現在あるファイル)
nem@localhost:~$ rm  ~/nem/nis/data/* (全て消去)
nem@localhost:~$ mv nis5_mainnet-966500.h2.db ~/nem/nis/data/ (ファイルを指定の場所へ移動)
nem@localhost:~$ ls  ~/nem/nis/data/
nis5_mainnet.h2.db
nem@localhost:~$ rm nis5_mainnet-966500.h2.db.zip (zipファイルを削除します)

上記作業終了後、NISサーバを起動して下さい。

2.8 enrollメッセージの送信

スーパーノードの公式アカウント宛にメッセージを送信し、スーパーノードリストへの追加をリクエストします。 NanoWalletのXEMの送金画面より、以下のメッセージを記入して送金します(送金額は0XEMで問題ありません)。

送信先アドレス: NAFUND-BUKIOS-TMD4BN-XL7ZFE-735QHN-7A3FBS-6CMY

メッセージの入れ方:

enroll  (2.6.2で入れたnem.host) (2.6.1で入れたnis.bootName) (NanoWalletに表示されている委任公開鍵) 

メッセージ実例:

enroll 172.31.100.28 MIZUNASHI 1a30416fe6241561deb26cabd984e0ed58ebd9fea7dcbfa12b33e8223c763096

f:id:mizunashi_rin:20170214150435p:plain

ここで入力するenrollメッセージは、絶対に間違えない様に確認してから送信して下さい。nem.host 及び nis.Bootname を間違えた場合は、別途修正コマンドを送る事で訂正する事が可能だと思われますが、委任公開鍵を間違えた場合は修正する方法がありません。 新しく修正したメッセージを送っても無効で、下記のサイトに英語で問い合わせする必要があります。

forum.nem.io

2.9 スーパーノード登録審査結果の確認

2.7にてメッセージを送信すると、スーパーノードとして間違えが無くサーバが構築されているかのテストが行われます。設定が間違って無い場合は、NEM Node Rewardsに自分のスーパーノードの名前が載ります。登録順になっていますので、一番最後のページに移動して確認してください。

自分の名前のサーバをクリックすると、今までのテスト結果が表示されます。こちらのテストはスーパーノードとしての設定が正しいかだけではなく、きちんとパフォーマンスが一定に達しているかのテストとなります。1日4回のテストが行われますので、全て合格するとスーパーノード報酬が支払われます。

f:id:mizunashi_rin:20170214152200p:plain

2.10 自動起動の設定

本章2.7迄でスーパーノードとしてきちんと動作をしております。但し、サーバが何かしらの理由で再起動した場合や、NISやServantプログラムが単体で異常終了してしまった場合には、スーパーノードとして動いていない事となり報酬も得られません。

ここでは、サーバ起動時に自動でサービスをスタートされる事と、プロセスの異常終了時に自動的に再起動させる設定を行います。

まずは、NISサーバの自動起動ファイルを作成します。

以下の内容のファイル/etc/init/nem-nis.confを作成します。

# NEM NIS Server nem-nis.conf

description "NEM NIS Server"
author "MIZUNASHI, Rin <hoge@hoge.hoge>"

start on runlevel [2345]
stop on runlevel [!2345]

pre-start script
    test -x /home/nem/nemServer/nix.runNis.sh || { stop; exit 0; }
end script

setuid nem
setgid nem

chdir /home/nem/nemServer
exec ./nix.runNis.sh
respawn

次に、Servantの自動起動ファイルを同様に作成します。ファイル名は、/etc/init/nem-servant.confとします。

# NEM Super Node Servant nem-servant.conf

description "NEM Super Node Servant"
author "MIZUNASHI, Rin <hoge@hoge.hoge>"

start on runlevel [2345] and started nem-nis
stop on runlevel [!2345]

pre-start script
    test -x /home/nem/nemServer/servant/startservant.sh || { stop; exit 0; }
end script

setuid nem
setgid nem

chdir /home/nem/nemServer/servant
exec ./startservant.sh
respawn

作成したファイルを反映する為に、次のコマンドを実行します。

root@localhost:~# initctl reload-configuration
root@localhost:~# initctl list | grep nem-
nem-servant stop/waiting (※)
nem-nis stotp/waiting (※)
root@localhost:~#

initctl listコマンドにて、※の表示が出ていれば正常に登録されている事になります。

実際に上記登録方法で登録した方法で起動テストを行いますので、現在動いているNISとServantのプロセスを停止します。

root@localhost:/# pgrep -fa org.nem  (※UNIXの種類によっては pgrep -fl org.nem と入力する場合もあります)
459 java -Xms512M -Xmx1G -cp .:./*:../libs/* org.nem.deploy.CommonStarter 
477 java -Xms256M -Xmx256M -cp .:jars/* org.nem.rewards.servant.NodeRewardsServant 
 (※ここで表示された先頭の数字が後ろに続くプロセスのプロセスIDとなります)

root@localhost:/# kill -SIGTERM 459 477
 (又は)
root@localhost:/# pkill -SIGTERM -f org.nem

root@localhost:/# pgrep -fa org.nem (何も表示されなければプロセスは終了しています)
root@localhost:/# 

現在は、NISサーバ及びServantプログラムが停止している状態ですので、改めて登録したスクリプトから起動します。

root@localhost:/# initctl start nem-nis
nem-nis start/running, process 8871
root@localhost:/# initctl start nem-servant
nem-servant start/running, process 8885

念のためプロセスを確認します。

root@localhost:/# pgrep -fa org.nem
8873 java -Xms512M -Xmx1G -cp .:./*:../libs/* org.nem.deploy.CommonStarter 
8887 java -Xms256M -Xmx256M -cp .:jars/* org.nem.rewards.servant.NodeRewardsServant 
root@localhost:/#
 (10秒程待ち同じコマンドを実行します)
root@localhost:/# pgrep -fa org.nem
8873 java -Xms512M -Xmx1G -cp .:./*:../libs/* org.nem.deploy.CommonStarter 
8887 java -Xms256M -Xmx256M -cp .:jars/* org.nem.rewards.servant.NodeRewardsServant 

この時、コマンドを実行した時に先頭に表示されるプロセスIDが同一であれば正常に動いています。 もし、数字が異なっている場合は、一度下記の様にしてプロセスの起動を停止します。

root@localhost:/# initctl stop nem-nis
nem-nis stop/waiting 
root@localhost:/# initctl stop nem-servant
nem-servant stop/waiting 

この状態は、何度も再起動を繰り返していますので、2.10章の頭からファイルの内容が間違ってないか確認します。 間違っている部分を修正した後に、再度initctl startを使ってプロセスを起動しプロセスの確認作業を行います。

問題なく動いている様であれば、rebootコマンドを入力しサーバを再起動して最終確認を行います。

2.11 最終確認

root@localhost:~# reboot
root@localhost:~# 
Broadcast message from root@localhost.localdomain
    (/dev/pts/2) at 0:48 ...

The system is going down for reboot NOW!

root@localhost:~i# Connection to 172.31.100.28 closed by remote host.
Connection to 172.31.100.28.

上記のメッセージを確認したら、現在サーバは再起動中となります。

直ぐに起動してきますので、sshにて再度ログインします。下記の様にプロセスの動作が確認できれば、スーパーノードを運用する最低限の設定は全て終了となります。

nem@localhost:~$ pgrep -fa org.nem
459 java -Xms512M -Xmx1G -cp .:./*:../libs/* org.nem.deploy.CommonStarter
477 java -Xms256M -Xmx256M -cp .:jars/* org.nem.rewards.servant.NodeRewardsServant
nem@localhost:~$

最後に、要らないログファイルの削除を行います。これは、手動にてNISサーバとServantを起動した為に出来てしまったファイルの削除です。

nem@localhost:~$ cd
nem@localhost:~$ rm -f nisServer/nohup.out nisServer/servant/nohup.out
nem@localhost:~$

そして、現在のNISサーバのログファイルは/var/log/upstart/nem-nis.logというファイル名で作成されています。

nem@localhost:~$ cd /var/log/upstart
nem@localhost:/var/log/upstart$ ls -l nem-nis*
-rw-r----- 1 root root 28136411 Feb 14 23:50 nem-nis.log
-rw-r----- 1 root root  2190933 Feb 13 00:24 nem-nis.log.1.gz
-rw-r----- 1 root root  2163204 Feb 12 00:24 nem-nis.log.2.gz
-rw-r----- 1 root root  4427891 Feb 11 00:24 nem-nis.log.3.gz
nem@localhost:/var/log/upstart$ 

1日でおよそ30MBのログファイルを作成しています。1ヶ月放置すると1GB弱のログファイルを作成するスピードですが、毎日ログファイルを別名に変えて圧縮して保存される様になっております。
上記のファイル名と時間を見ていただけると理解しやすいと思いますが、古いログファイルになればなる程ファイル名の最後の部分の〜log.数字.gzが大きくなっていきます。過去のログファイルは最大で〜log.3.gz迄しか保存されず、それ以上古くなると削除されます。
この様にして、一定期間のログを保存しつつディスク領域を圧迫しない様に設定されている状態です。これはupstartにより自動で提供されている機能となります。

ServerMan@VPS 1GB Ubuntu 14.04 LTS (64bit)のシンプルセットにて、最低限のパッケージ追加にて作業できる様に説明したつもりです。他のOSではコマンドが異なる場合もありますが、参考にはなるのではないかと思います。 今回は、root アカウントにて多くの作業を行なっていますので、特にUNIX初心者の方はコマンド操作には十分注意して作業する様にしてください。

次回は、サーバの追加設定を行ないます。またrootにて作業をしなくてもいいように、sudoコマンドを使える様な説明を入れていきたいと思います。

NEM スーパーノードの構築 第1回(インフラ準備編)

NEM スーパーノード NEM 暗号通貨 IT

NEMスーパーノード構築 第1回(インフラ準備編)

NEMのスーパーノードを構築するにあたって、インフラの準備をする必要があります。

私の場合、最小構成のインフラで構築を行っていますが、今後のトランザクションの増加やクライアントの数の増加を考えた場合、サーバーには少し余力を残した状態で構築するのが望ましいです。

1. スーパーノードのハードウェア必要要件

最も重要な事は、スーパーノードとして開始するために必要な最小限のXEMバランスを確保する事です。少なくとも以下のハードウェア条件を満たす必要があり、自宅サーバもしくはVPSのレンタルをする必要があります。

項目 要求
RAM 最低限1GB推奨
(最低限NISには768MB、サーバントには128MB)
CPU 1GHz以上のシングルコアかそれ以上推奨
アップストリーム 少なくとも5Mbps
ポート開放 FireWall及びルータ上のTCP 7778,7808,7890ポートのインバウンドとアウトバウンドを開放

 

2. スーパーノードの実行パフォーマンス必要要件 

スーパーノードは、6時間毎に任意のタイミングで下記のテスト項目のチェックが行われています。1日にすると4回のラウンドテストが行われます。

ラウンドテストは、ラウンドNo.が4の倍数+1で始まり、それを含めた計4個のラウンドテスト(24時間)に合格した場合に、スーパーノード報酬を得る事ができます。

テスト
項目
要求 備考
帯域幅 5000kbps以上 3ノードから平均2MBがダウンロードされる。
チェーンの高さ 同期されている事 4ブロック以上遅れてはいけない。
チェーン部分 正確なチェーンの一部50ブロックをアップロードする事 ノードからダウンロードされたHashは、正確性の基準となるチェーンと比較されます。
計算速度 2,000hash/s以上 32byteのシードを10,000回繰り返し計算し、スピード及び精度が測定されます。
保証金 3,000,000XEM以上 3,000,000XEMを保有するアカウントのデリゲートキーで起動する必要があります。
NISのバージョン 最新 管理者はすぐにアップデートすべきです。
Ping 200ms以下 他の全てのノードで計測されたPing性能のうち、少なくとも1つは試験に合格しなければいけません。
応答性 連続10回のブロックチェーンの高さに応答できる事 少なくとも9回応答し、全体で1秒以下であれば合格する事ができる。


3. スーパーノードラウンドテストの実例(今回構築したサーバ) 

 以下が 2. で述べたテスト結果となります。このページは、NEM Node Rewards にアクセスし、自分のノードを選択する事で閲覧可能です。スーパーノードを立てた際にはここの情報を見て、きちんと動作しているのかチェックする必要があります。

f:id:mizunashi_rin:20170212105151p:plain

ここには、今までテストを行い判定された結果が表示されています。新しい結果が上に表示され最大で過去5回分を閲覧できます。

ここでの1日は、4の倍数+1 から始まる4回分ですので、Round1665〜1668迄がスーパーノード報酬の対象となります。画像ではラウンド1667と1668はまだ結果がでていませんが、この後PASSしておりますので、下記の様にスーパーノード報酬が通常のTransfer Transactionとして入金されています。

メッセージの部分に、"Node rewards payout: round 1665-1668"と書かれていますので、分かりやすいかと思います。

f:id:mizunashi_rin:20170212110341p:plain

スーパーノード報酬は、NEM Blockchain Explorer v3.2 にアクセスし、送り主及び宛先で検索を行っても表示されないようになっています。

上記サイトにて確認する為には、ハッシュ値で検索しなければ表示されません。

追記(2017/2/13):こちらのサイトでは検索が出来ます→ NEM - BlockChain Explorer

 

4. スーパーノードのVPSをレンタルしてみた

今回私がレンタルしたサーバを紹介していきます。実運用ではなくテスト運用という理由から、初期費用が発生ぜず月額料金が安いサーバを選びました。もちろん、業界最低スペッククラスです。

DTI ServersMan@VPS Entry メモリ1GB HDD 50GB構成を選びました。

手数料がありませんので月額467円と非常に安く、スーパーノード報酬が2回得られればサーバレンタル料は回収出来るという訳です。

※ こちらのEntryタイプを選択し、ラウンドテストが時々通らない事例報告もあります。実運用される方は注意して下さい。

f:id:mizunashi_rin:20170212103500p:plain

 またサーバのOSとしては、スーパーノード構築で実績の多い Ubuntu(今回は Ubuntsu 14.04 LTS (64bit))を利用する事にしました。

シンプルセットという事もあり、実質初回ログイン時にある程度メモリーを消費してしまうプログラムはhttpdぐらいしか動作しておりませんでした。

この様な初期状態のOSの場合、不必要なプログラムを停止する作業の工数が減り非常に楽な作業となりました。 

f:id:mizunashi_rin:20170212103812p:plain

 次回は、OSの設定もしくはスーパーノードの設定を行っていきたいと思います。