みなりん*のブログ

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

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

今回は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)

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

f:id:mizunashi_rin:20170218082433p:plain

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

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

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

http://blog.minarin.moe/entry/2017/02/15/002342blog.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
LimitNOFILE=100000
[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
LimitNOFILE=100000
[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 -Xms1G -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 -Xms1G -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 -Xms1G -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のスーパーノードのプログラムのセットアップを行います。

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

http://blog.minarin.moe/entry/2017/02/12/114147blog.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スーパーノード構築 第1回(インフラ準備編)

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

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

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

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

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

追記(2017/12/28):

現状1GBのRAMの運用は高トランザクションの負荷を処理できません。この文書を追記した時点での最低推奨値は、物理RAM 4GB(NIS:2,800MB, Servant 256MB)です。 

追記(2018/7/28):

現状1GBのRAMの運用は高トランザクションの負荷を処理できません。この文書を追記した時点での最低推奨値は、物理RAM 4GB(NIS:2,500MB, Servant 256MB)です。 

追記(2018/11/6):

ポート開放欄で、7880と記述すべきところが、7808と誤った値が記述されていましたので修正。

 

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

追記(2017/12/28):

現在のサーバ運用の為の最低メモリーは、4GBとなっております。注意してください。

 

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

Fixkit 土壌水分計 湿度計センサー TL-H1 をテストしてみた

今回のレビュー商品は、こちらの「Fixkit 土壌水分計 湿度計センサー TL-H1」です。

f:id:mizunashi_rin:20161201132849j:plain

ズバリ、土壌の水分量(湿度)を測る機械です。

植物は光があっても水分が足りないと光合成できません。植物の水やりは朝に行うという事は一般的に行われていますが、こういった理由があるからです。

そして、水分を豊富に含んだ植物より、植物の種となると水分量は非常に少なくなり、5%〜20%となります。

植物が育つ色々な過程に於いて、水分管理は非常に重要となっています。

 

こちらの水分量測定器、大きさ・形状はこんな形になっています。

f:id:mizunashi_rin:20161201134102j:plain

メーター部はほぼ100円ライターと同じサイズで、センサー部が19.5cm。

実際に土の中に刺す長さは、5cm〜10cmの範囲で利用します。

 

この測定器の1番の特徴とも言えるのは、電源が要らない事です。

そもそも乾電池さえ入れる所が無く、土に刺すだけでメーターは機敏に動いてくれます。そして実売価格も1000円もしないというお手頃価格ですので、1つあるだけで色々な場所・鉢植え等に使えます。

保証も24ヶ月と長めの設定になっております。

 

実際の利用としては、

  1. 土に差し込む
  2. 数分待つ
  3. 値が緑の範囲にあるかを確認
  4. 土から抜く
  5. 丁寧に汚れを拭き取って保存

これだけです。

 

こちらは、実際に自宅の庭で測定してみた値です。

f:id:mizunashi_rin:20161201140153p:plain

12:00に測定していますが、MOISTの範囲内で適切な水分量になっている事がわかります。

 

一般の植物に関しては、水分量さえ間違えなければ問題はあまり発生しません。もし農作物等少し敏感な物を育てたい場合は、土の酸性・アルカリ性も調べる事が出来る機器を紹介している以下の記事を読んで見てください。

blog.minarin.moe

 

 

 

利用できなくなったAndroid版Monacoinウォレットから秘密鍵を取り出しデスクトップ版Monacoin-Qtウォレットで救済し利用する方法

Android版Monacoinウォレットは、2015年9月27日以降のMonacoin仕様変更により、それ以降のコインの出し入れが出来なくなっています。

私は、それを知らずにこちらのウォレットをインストールして使い始めました。

2016年の8月に何故か入金に成功しており、それ以降使っていなかったのですが、2016年11月に再度入金したところ、全く反映されないという状況に陥りました。

もしかすると、ブロックのデータベースが壊れている可能性があるという考えからデータベースの再取得を行うと、何度やっても下記の場所で止まる様になってしまいました。

f:id:mizunashi_rin:20161114021023p:plain

これを見る限り、450000ブロックにて仕様変更があった様です。

この変更により、このウォレットは仕様変更に対応しない限り使えないウォレットになりました。この記事を書いている時点では、未だ対応されておりません。

 

こうなってしまうと、秘密鍵を取り出して最新の仕様に対応している他のウォレットに入れれば問題は無いのですが、このアプリケーションのバックアップ機能の秘密鍵の書き出しを使用すると、パスワードの入力が必要で何かしらのエンコードが施された出力しか書き出せないという仕様でした。

正確にはパスコードを省略する様にする事もできますが、省略してもエンコードは施されており、純粋な秘密鍵を出力する事は不可能です。

 

しかしながら、兎にも角にも秘密鍵を書き出すしか方法がありませんので、以下の様にしてエンコードされた秘密鍵を取り出します。

 

1.左上の縦破線からメニューを出し、バックアップを選択します。

f:id:mizunashi_rin:20161114021902p:plain

 

秘密鍵のバックアップを選択します。

f:id:mizunashi_rin:20161114022518p:plain

 

3.適切なパスワードを付けてバックアップします。

f:id:mizunashi_rin:20161114022054p:plain

 

4.バックアップした秘密鍵の場所の表示がされます。

  続いて、アーカイブするかと尋ねられますので、アーカイブを選択します。

f:id:mizunashi_rin:20161114022143p:plain

 

5.アーカイブを選択すると色々な方法で秘密鍵を転送できるメニューが出ます

  ので、好きな方法でPC等に転送を行います。

f:id:mizunashi_rin:20161114022258p:plain

 

6.転送されたファイルの中身は、下記の様な実際の秘密鍵よりもかなり長い、

  文字の羅列になっています。

f:id:mizunashi_rin:20161114023323p:plain

この文字列を調べたところ、秘密鍵に対してパスワードを利用したAES 256bit CBC形式のエンコードがかけられているという事が分かりました。

 

7.openssl を使って文字列をデコードする

 まずは、opensslの使える環境にファイルを移動する必要があります。

 移動先にて、以下の様にコマンドを実行してください。

 

 $ openssl enc -d -aes-256-cbc -a -in エンコード文字列が書かれているファイル名

 enter aes-256-cbc decryption password: test  

  ↑ 秘密鍵をバックアップする時に使用したパスワードを入力しリターンキーを押します

 # KEEP YOUR PRIVATE KEYS SAFE! Anyone who can read this can spend your Bitcoins.

 TRQpijUnByVMqCxNh9HYb2JBjPc1WESHNdED27rsoC11JegLD5Xq 2016-07-29T00:56:40Z

    ↑この最後の赤い文字列がデコードされた秘密鍵となります

 

以下3行追記:2017/4/23

なお、うまく動作しない場合は、先にBase64のデコードを行ない、後からAES 256bit CBC形式のデコードを行う方法もあります。

 例) $ base64 -D -in エンコード文字列が書かれているファイル名 | openssl enc -d -aes-256-cbc 

 

 

8.Monacoin-Qtウォレットを起動して、ヘルプメニューのデバックウインドウを

  選択します。

f:id:mizunashi_rin:20161114025718p:plain

 

9.デバックウインドウの上の部分でコンソールを選択します。

f:id:mizunashi_rin:20161114030328p:plain

 上記の様に、一番下の空欄に下記の様に文字を入力します。

 importprivkey TRQpijUnByVMqCxNh9HYb2JBjPc1WESHNdED27rsoC11JegLD5Xq

        ↑赤い部分は先程デコードされた秘密鍵です。

 

正しく入力されている場合には、暫くの間ブロックチェーンを走査する作業が行われ最後にウォレットにそのアドレスにあるべきコインが現れ移行終了となります。

 

f:id:mizunashi_rin:20161114031046p:plain

こちらのウォレットは使えなくなってから1年以上経過しており、あきらめてしまわれた方もいらっしゃると思います。もし、現在でもAndroid版のウォレットがある場合は、こちらの方法にてmonaコインを救出してみてはいかがでしょうか。

MOSFETを利用した電流の吸い込み

前回の記事では、USB電源から電流を吸い込む為に抵抗を使った機器の紹介をしました。

まだ読まれていない方は、以下の記事を先に読んでいただけると嬉しいです。

blog.minarin.moe

 

今回は、MOSFETを利用して同じ様な事をしてみたいという事で、こちらの機器を用意しました。

  f:id:mizunashi_rin:20161024003134j:plain

  f:id:mizunashi_rin:20161024003213j:plain

この装置は、青色の半固定抵抗(ツマミ付き)と下写真中央のMOSFETで電流値をコントロールしています。

前回と同じ様な事をする為、小さなMOSFETにはヒートシンクが直付されています。

製品の性能としては、

 

・動作電圧 DC 3.7〜13V

・連続電流 0.15〜3.0A

・最大消費電力 15W

 

と、かなり融通が効く製品になっています。

 

そして、何より前回と違うのが、大きさです。

  f:id:mizunashi_rin:20161024004301j:plain

手に取ると更に小さく感じられます。流石です。

 

<特徴>

・3.0A以上の負荷をかけようとすると半固定抵抗が空回りします

・半固定抵抗は低感度です(細かい調整が可能)

・かなり小さいのでファンガードがついていませんので注意してください

 (ファンを壊さない様にという意)

 

注意点及びまとめについては、前回と同じですので今回は省略します。

以下の様なお遊びは、程々に・・・(こ、こいつ出来るぞ!

  f:id:mizunashi_rin:20161024005607j:plain

 

<商品詳細ページ> 

  [ShopU] USB電子負荷 UEL003