狛ログ

オフィス狛 技術部です。

前回（Redmineのバージョンアップ 2.5 → 3.3 その１）でようやく前準備が出来たので、
今回は Redmine 自体のバージョンアップを進めて行きます。

１）Redmine の本体をダウンロード・配置

まず、本家サイトから、 redmine-3.3.1.tar.gz をダウンロードします。

Redmineのインストールディレクトリ（ /var/lib ）に展開します。

$ tar xvf redmine-3.3.1.tar.gz
$ sudo mv redmine-3.3.1 /var/lib/

ディレクトリを /var/lib へ移動します。

$ cd /var/lib

前バージョンの設定ファイルを新バージョンの config ディレクトリにコピーします。

$ cp -p redmine/config/configuration.yml redmine-3.3.1/config
$ cp -p redmine/config/database.yml redmine-3.3.1/config

前バージョンに添付したファイルを新バージョンへコピーします。

$ cp -pr redmine/files redmine-3.3.1

※今回はプラグインを前もって全て削除しているので必要ありませんが、
削除していない場合は、プラグインも新バージョンへコピーする必要があります。

※自分で追加したテーマも新バージョンでも使いたい場合はコピーする必要があります。
今回は、アップグレード後に改めてテーマを入れる予定なので、旧バージョンからの移行はしていません。

２）アップグレード

新バージョンのディレクトリに移動します。

$ cd /var/lib/redmine-3.3.1

インストールを実施します。

$ bundle install --without development test

ここでエラーが出ました。

Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
(中略)
/usr/bin/ld: -lmysqlclient が見つかりません
collect2: error: ld returned 1 exit status
make: *** [mysql2.so] エラー 1
(中略)
An error occurred while installing mysql2 (0.3.21), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.3.21'` succeeds before bundling.

共有ライブラリが見つからない、と怒られています。
というわけで、共有ライブラリへのリンクを作ります。

$ sudo ln -s /usr/lib64/mysql/libmysqlclient.so.18.0.0 /usr/lib64/libmysqlclient.so

再度インストールを実行します。

$ bundle install --without development test
Your bundle is complete!
Gems in the groups development and test were not installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.

今度は成功しました。

続いて鍵の生成を行います。

$ bundle exec rake generate_secret_token
rake aborted!
LoadError: incompatible library version - /home/ofkomamanage/.gem/ruby/2.0/gems/nokogiri-1.6.8.1/lib/nokogiri/nokogiri.so

またエラーになりました。

足りないライブラリがあるようなので、
ここで一度、必要なライブラリをインストールします。（パスの指定が必要です）

$ bundle install --path=vendor/bundle

再度、コマンド（鍵の生成）を実行します。

$ bundle exec rake generate_secret_token

３）データベースの更新

マイグレーションを行います。

$ bundle exec rake db:migrate RAILS_ENV=production

※今回はプラグインを前もって全て削除しているので必要ありませんが、
削除していない場合、以下のコマンドにてプラグイン分のマイグレーションも行う必要があります。

$ bundle exec rake redmine:plugins:migrate RAILS_ENV=production

４）クリーン

キャッシュとセッションのクリアを行います。

$ bundle exec rake tmp:cache:clear tmp:sessions:clear

５）Passenger のセットアップ

Passenger は、Rails を使って作られたWebアプリケーションをApacheで動かす為のモジュールです。
では、早速 Passenger をインストールします。

$ rbenv exec gem install passenger --no-rdoc --no-ri

セットアップを続けます。

$ passenger-install-apache2-module

Please edit your Apache configuration file, and add these lines:

   LoadModule passenger_module /home/officekoma/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/passenger-5.0.30/buildout/apache2/mod_passenger.so
   
     PassengerRoot /home/officekoma/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/passenger-5.0.30
     PassengerDefaultRuby /home/officekoma/.rbenv/versions/2.3.1/bin/ruby
   

Apacheの「conf.d」ディレクトリ内に、「passenger.conf」というファイルを作成し、
上記の「LoadModule passenger_module」以降の部分をそのまま貼り付けます。

６）Webサーバー（Apache）の設定変更と再起動

この辺は、各環境によって設定方法は変わってくると思いますが、
弊社の場合、Redmineが動いているサーバーでは、他のWebシステムは動いていません。
なので、DocumentRoot を「/var/lib/redmine/public」から、
「/var/lib/redmine-3.3.1/public」に直接変更し、再起動します。

$ sudo /etc/init.d/httpd restart

いざ接続してみると、「Internal Server Error」に・・・。
ログを確認してみます。

DEPRECATION WARNING: You didn't set `secret_key_base`. Read the upgrade documentation to learn more about this new config option. (called from validate_secret_key_config! at /home/officekoma/.gem/ruby/2.0/gems/railties-4.2.7.1/lib/rails/application.rb:530)

Secret Key を設定しなくてはいけないようです。

$ rake secret

上記コマンドを実行すると、長い文字列が表示されるので、それをコピーしておきます。
そして、下記コマンドで Secret Key 設定ファイルを開きます。

$ vi /var/lib/redmine-3.3.1/config/initializers/secret_token.rb

下記「xxxxxxxxx」の部分を先程コピーした Secret Key で置き換えます。

RedmineApp::Application.config.secret_key_base = 'xxxxxxxxx'

これでエラーは出なくなりました。

長い道のりでしたが、これでRedmineのバージョンアップは完了です。
（これでも思ったよりはスムーズに行きました。）
後はしばらく稼働させて様子見です。

オフィス狛 技術部です。

弊社のRedmineは、平日は終日使用されていて、
バージョンアップを行うタイミングは土日に限られてしまうのですが、
以前実施した時に、見事に失敗して、そこからずっと再実施するタイミングがありませんでした。

今回、ようやく実施出来るタイミングを作れたので、
今度は成功するまで頑張ってみようと思います。

１）作業前バックアップ

弊社Redmineは、AWS(Amazon Web Services)上に構築しているので、
作業前のバックアップも、各データごとに取得する訳ではなく、
マシンイメージ（AMI）ごと取得しています。
よって、細かいバックアップの手順は記載しません。
必要であれば、本家サイトを参照して下さい。

２）バージョンアップ前準備（プラグインの削除）

プラグインがRedmineの新しいバージョンに対応していないと、
バージョンアップに失敗する事がある、と聞いていたので、
念の為、プラグインは削除しておこうと思います。

現在使用しているのは以下の二つです。（思ったより少なかった）

Parent issue filter plugin (parent_issue_filter)
　→チケットを親チケットでフィルタ出来るプラグインです。
　　Redmineの3.1から、プラグインなしでも親チケットによるフィルタが実装されたようなので、
　　このプラグインは削除しようと思います。

Redmine Gantt With Date plugin (redmine_gantt_with_date)
　→ガントチャートに日付を表示するプラグインです。
　　こちらはRedmine3.2からプラグインなしでも日付が表示されるようになったようなので、
　　このプラグインも削除しようと思います。

削除は、下記のコマンドを実行します。

$ rake redmine:plugins:migrate  NAME=xxxxxx VERSION=0 RAILS_ENV=production

「xxxxxx」の部分に、プラグインの名称を設定します。

例えば、Parent issue filter pluginを削除する際は、

$ rake redmine:plugins:migrate  NAME=parent_issue_filter VERSION=0 RAILS_ENV=production

というコマンドを実行します。

ちなみに、上記コマンドは「Rakefile」が存在する場所で実行する必要があります。
（「Rakefile」はRedmineのHomeディレクトリに存在します。）
「Rakefile」が無いと、以下のようなエラーメッセージが出ます。

rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)

また、コマンドを実行した後、

$ rm -rf [Redmine HOME]/plugins/parent_issue_filter

というコマンドを実行する事で。実体のファイルも削除する必要があります。
※[Redmine HOME]は適宜環境によって書き換えて下さい。

３）バージョンアップ前準備（Rubyのバージョンアップ）

Redmine 3.3 から、Ruby 2.3 に対応しているようなので、Rubyもバージョンアップしようと思います。
（EC2でインスタンス作成時、Amazon Linuxの場合、Ruby2.0がインストール済みとなってるので、
「rbenv」を使用して、バージョン2.3をインストールします）

rbenvは、GitHubからクローンする必要があるので、gitがインストールされていない場合はインストールします。

$ sudo yum install git

※弊社は、同一インスタンスでGitのリポジトリも管理しているので、gitはインストールしてある状態でした。
・・・この同一インスタンス内で色々なシステムを導入しているのが、今回のバージョンアップになかなか踏み切れなかった要因です。

gitがインストール済みかどうかは、下記のコマンドで確認できます。

$ yum list installed | grep 'git'

さて、rbenvのインストールのやり方は、
https://github.com/rbenv/rbenv#installation
の通りに実行していくだけです。
（homeディレクトリで実施するのが良さそうです）

Githubからチェックアウト。

$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv

環境設定ファイルにパスを追加。

$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile

initコマンドを呼び出すように設定します。

$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile

パスの変更を有効する為に、一度ターミナルの接続を切り、再接続します。

動作確認は以下のコマンドで行います。

$ rbenv -v

rbenvは、rubyのバージョン切り替えツールなので、
次はrubyのインストールを簡単にするプラグイン（ruby-build）をインストールします。

$ git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

以下のコマンドで、インストール可能なバージョンを確認します。

$ rbenv install -l

現時点（2016/11/12）最新安定版のバージョン 2.3.1 をインストールします。

$ rbenv install 2.3.1

ここでエラーが出ました。

Downloading ruby-2.3.1.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.1.tar.bz2
Installing ruby-2.3.1...

BUILD FAILED (Amazon Linux AMI 2016.09 using ruby-build 2016xxxx-xx-xxxxxxxxx)

Inspect or clean up the working tree at /tmp/ruby-build.2016xxxxxxxx.xxxxx
Results logged to /tmp/ruby-build.2016xxxxxxxx.xxxxx.log

Last 10 log lines:
installing rdoc:              /home/officekoma/.rbenv/versions/2.3.1/share/ri/2.3.0/system
installing capi-docs:         /home/officekoma/.rbenv/versions/2.3.1/share/doc/ruby
The Ruby readline extension was not compiled.
ERROR: Ruby install aborted due to missing extensions
Try running `yum install -y readline-devel` to fetch missing dependencies.

Configure options used:
  --prefix=/home/officekoma/.rbenv/versions/2.3.1
  LDFLAGS=-L/home/officekoma/.rbenv/versions/2.3.1/lib 
  CPPFLAGS=-I/home/officekoma/.rbenv/versions/2.3.1/include

ここはエラーメッセージの通り、

$ sudo yum install -y readline-devel

を実行し、その後無事にインストール成功しました。

インストールに成功したところで、バージョンを切り替えます。
まずは、現在の選択されているRubyのバージョンを確認します。

$ rbenv versions
* system (set by /home/officekoma/.rbenv/version)
  2.3.1

systemが選択されています・・・バージョンが分からない、という事で、

$ ruby -v
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]

現在選択されているのは「2.0」だということが分かりました。

さて、バージョンを変えてみます。

$ rbenv global 2.3.1

再度、現在の選択されているRubyのバージョンを確認します。

$ rbenv versions
  system
* 2.3.1 (set by /home/ofkomamanage/.rbenv/version)

$ ruby -v
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux]

現在の選択バージョンが「2.3.1」になりました。

ようやく、Redmineのアップグレードですが・・・長くなってきたので、次回に持ち越します。

次回：Redmineのバージョンアップ 2.5 → 3.3 その２

オフィス狛 技術部です。

IoT関連のプロジェクトでは、多く使われている Raspberry Pi 。
弊社でも、BLEソリューションや、その他実証実験などで、使っています。

Raspberry Pi 3 になって、性能も良くなっているのですが、
たまに不安定になって、フリーズしてしまう事があります。

メモリ不足になっているとか、要因は色々あるのですが、
常時稼働すべき用途の場合、フリーズしてしまうのは困ってしまいます。

と言う事で、ウォッチドッグタイマーの出番です。

ウォッチドッグタイマーとは

メインのプログラムがハングアップなどの不正な状態に陥ってしまい、規則的なウォッチドッグ操作（「犬をなでる」とも呼ばれる「サービスパルス」の書き込み）が行なわれなかった（タイムアウト）場合に、例外処理が実行される。例外処理は、ハングアップしたシステムを正常動作に戻すことを目的としてシステムをリセットする場合が多いが、電源切断によりシステムを強制停止させるものや電源を切断した後に再投入するものもある。
タイマーはソフトウェアではなく、ハードウェアを用いる。これは、ソフトウェアで実装してしまうと、ソフトウェア自体が故障した際にタイマーの役割を果たさなくなったり、リセット信号を発生できなくなってしまう恐れがあるためである。
障害を引き起こした問題のデバッグに役立つ情報などを媒体に保存する機能を持つ場合、ウォッチドッグタイマーはより複雑なこともある。たとえば、最初のウォッチドッグタイマーのタイムアウトによって開始された情報の保存処理がある時間内に完了しなかった場合、情報が保存されていてもいなくても、2番目のシンプルなウォッチドッグタイマーがシステムを確実にリセットさせる。ウォッチドッグタイマーが最も多く使われているのは組み込みシステムで、マイクロコントローラに内蔵されていることも多い。
「ウォッチドッグタイマー」『フリー百科事典　ウィキペディア日本語版』より。
2016年3月21日 (月) 08:29‎ UTC
URL: https://ja.wikipedia.org/wiki/ウォッチドッグタイマー

ウォッチドッグタイマーのインストールと設定

以降のコマンドは、root権限で実行してください。
（「su」でrootになるか、「sudo」をコマンドの頭に付ける）
また、OSは「Raspbian Jessie Kernel version:4.4」を想定しています。

以下のコマンドで、watchdogをインストールします。

$ apt-get install watchdog

サービスの登録を行う為に、「watchdog.service」ファイルを編集します。

$ vi /lib/systemd/system/watchdog.service

※「[Install]」の下に下記を追加して、保存後、ファイルを閉じます。
WantedBy=multi-user.target

自動起動設定を行います。

$ update-rc.d watchdog enable

カーネルモジュールをロードします。

$ modprobe bcm2708_wdog

watchdog.conf の編集を行います。

$ vi /etc/watchdog.conf

※以下の部分のコメントを外し、保存後、ファイルを閉じます。
#watchdog-device = /dev/watchdog

/etc/default/watchdog の編集を行います。

$ vi /etc/default/watchdog

※watchdog_module="none"の「none」を「bcm2708_wdog」に変え、保存後、ファイルを閉じます。

再起動します。

$ reboot

再起動後、以下のコマンドを実行し、自動で再起動すればOKです。

$ :(){ :|:& };:

今回、下記サイトを参考にしたのですが、ちょっと情報が古かったり、やり方がサイトによって微妙に異なっていたりしたので、
Raspberry Pi 3 の「Raspbian Jessie Kernel version:4.4」で、問題なく動作した方法を記載しています。

【参考】
http://ivis-mynikki.blogspot.jp/2015/03/raspberry-pi.html
http://ecoday.jp/881/raspberry-pi-2-にウォッチドッグタイマーを導入する%E3%80%82/
http://machiawasepoint.com/raspberry-pi-jessieにwatchdogをインストール/

オフィス狛 技術部です。

現時点（2016/11/23）の Xcode の最新は 8.1 ですが、
Swift 2.3 で作られたプロジェクトを移行するには、色々とやらないといけない事があります。

という訳で弊社では、まだ移行出来ないプロジェクトなどは、
Apple Developer サイトから Xcode 7.3 をダウンロードして、8.1 と共有して使っています。

今回、Swift2.3 で作られたプロジェクトをリリースする事になり、
いつもの手順でXcodeで「Archive → Upload to App Store」の手順を行なったら・・・・

ERROR ITMS - 90167 No. app bundles found in the package

というエラーが発生しました。

このままではストアにアップロード出来ないので、調べて見ると以下のような情報が。

stack overflow - ERROR ITMS - 90167 No. app bundles found in the package -

要約すると、
「macOS Sierra 10.12 で Xcode 7.3 を使ってApp Store へのアップロードは出来ない」
「この不具合は、次のOSのアップデート時に修正されるようだ」
さすがに次のアップデートを待つ事は出来ないので、他の方法を探ります。

そう言えば、App Storeへアップロードするツールがあったな・・・という事で、
「Application Loader」というツールを使います。

1) まずは、「Archive」から、ipaファイルを作っておきます。


2) そして、Xcodeのメニューから、「Application Loader」を起動します。



3) 先ほど作成したipaファイルを選択します。


4) アップロードが始まります。


5) アップロード完了です。



こういう方法も覚えておくと、いざという時に役に立ちますね。

オフィス狛 技術部です。

弊社ではしばらく使う事のなかったMySQLですが、
とあるプロジェクトで久しぶりに使い、そしてハマりました。

問題となったテーブル

まず、以下のようなCreate文を実行しました。

CREATE TABLE koma_test (
      koma_test_id bigint NOT NULL AUTO_INCREMENT,
      koam_code varchar(2) NOT NULL,
      test_count int,
      test_fee decimal(7,0),
      has_deleted boolean DEFAULT false NOT NULL,
      entry_datetime timestamp NOT NULL,
      entry_user varchar(100),
      update_datetime timestamp NOT NULL,
      update_user varchar(100),
      PRIMARY KEY (koma_test_id)
);

「entry_datetime」「update_datetime」などは、システムで良くあるタイムスタンプ系のカラムです。
日時はプログラム側で設定する事を想定しています。

発生した現象

本来、プログラム側では登録時（Insert時）のみ「entry_datetime」が設定され、
それ以降、その値は変わらない想定でした。

ところが、テーブル更新時（Update時）に「entry_datetime」が勝手に更新されていたのです。
当然最初はプログラムを疑いましたが、プログラムに問題はありませんでした。

で、ちょっとハマった後、何気なく作成されたテーブルの定義を確認すると、
「entry_datetime」に「CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP」が付いているのです。
（「update_datetime」には付いていない）

もちろん、Create文には、そのような指定はしていません。
どうやら、timestamp型には、デフォルトで「CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP」が付いてしまうようです。
※他のサイトの情報だと、NULL 許可していても、NOT NULL にもなってしまうようです。

なんて余計なお世話だ・・・とも思いましたが、
まあ、「timestamp」という属性名だし、そういう事になりますよね・・・
タイムスタンプ系の使い道で無い場合、型は「datetime」にすれば良いだけですからね。

とは言うものの、今のままでは、本来の用途に使えないので、テーブルの定義を変更します。

ALTER TABLE koma_test CHANGE entry_datetime entry_datetime TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP;

注意事項ですが、デフォルト値の「CURRENT_TIMESTAMP」も削除したいからといって、

ALTER TABLE koma_test CHANGE entry_datetime entry_datetime TIMESTAMP NOT NULL;

というSQLを流してしまうと、
またデフォルトの「CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP」が付いてしまいます。

MySQLを使い込んでいる方ですと、「そりゃ、そうでしょ」レベルの話なのかもしれませんが、
久しぶりに使うと、ハマってしまいますね。

オフィス狛 技術部です。

Raspberry Pi で 3G 通信をしてみよう！　という事で、
今回は、Raspberry Pi と 3GPIの取り付けを行なっていきます。

・SIMカード準備

SIMはカードのような物に付いているので、丁寧に取り外します。


外したSIMを変換アダプタ(標準SIM)へセットします。
今回は、汎用性を考えて(この検証以外でも使いたいので)、
nano(ナノ)サイズSIMを購入しましたが、標準SIMサイズを購入していれば、上記作業は不要です。
※SORACOMでは、ナノ、マイクロ、標準SIMのサイズが用意されています。

・3GPI同梱品確認

実際の作業の前に、3GPIの同梱品を確認します。

【同梱品一覧】(取扱説明書より)

• 3GPI本体 1枚
• 接続設定済Raspbian入microSDカード(SD用アダプタ付) 1枚
• 3Gアンテナ 1本
• ACアダプタ(12V 1A) 1個
• USB-A雄-USBmini-b雄 100mmケーブル 1本
• Raspberry Pi ModelB+用六角スペーサ(M2.6)セット 2セット

・Raspberry Pi に 3GPI を取り付ける

では、Raspberry Pi に3GPIをセットしたいと思います。
まずは写真の赤枠の部分に、六角スペーサを取り付けます。


こんな感じです。
ナットで裏側から固定しています。


裏側はこんな感じです。


続いて、Raspberry Pi のGPIOピンに、3GPIを差し込みます。
結構強めに押し込まないとちゃんとハマりませんが、
繊細なので、壊さないように力込めましょう。
GPIOピンに差し込んだ後に、六角スペーサのネジを締めます。
写真の赤枠がネジを締めた後の状態です。

・SDカード取付

本体をひっくり返して、microSDカードを差し込みます。
※microSDカードの裏表を間違えないように。

・SIMカード取付

SIMスロットは閉じている状態の時に、奥に押す感じでずらすと開きます。
IC端子と切れている部分の位置に気を付けてセットします。


スロットを閉じた後は、先程と逆に手前に引く感じでずらすと、固定されます。

・その他取付

3Gアンテナを取り付けます。端子が二つありますので、
"RF"と記載されている方に取り付けます。
結構力を入れないとネジが回りませんので、壊さないように力込めましょう。


Raspberry Pi のUSBと、3GPIのUSBmini-Bを繋ぎます。


後は電源投入ですが、その前に、
Raspberry Pi にUSBキーボードと、HDMIケーブルを接続しています。


最後に3GPI側に電源を接続します。


起動しました。
3GPIが梱包されていた箱の内側に、UserNameとPasswordが記載されているので、
入力してログインします。

・SSH接続設定

Raspberry Pi へTeraTermなどで接続する為の設定を行います。
コンソール上で「sudo raspi-config」とコマンドを打ちます。

起動した設定画面で「9 Advanced Options」を選択します。


次に出てきた画面で「A4 SSH」を選択します。


SSH Serverを有効(Enable)にします。


セットアップはここまでとなります。
写真がセットアップ後の状態です。(LANケーブルも接続しています)
大きさの比較に、フリスクも置いてみました。

※SORACOMは（と言うより、データ通信のみのSIMはほとんど）、
グローバルIPではなくプライベートIPが割り振られます。
その為、SIMの接続を利用したリモート接続が出来ません。
(中継サーバーを設ける事で可能になるようですが、今回は記載しません)
という事で、リモート接続をする為に、LANケーブルを接続しています。


さて、3G通信の準備が完了したので、次は実際に通信速度を測ってみようと思います。

３）通信速度を測ってみる（近日公開予定）

オフィス狛 技術部です。

Raspberry Pi で 3G 通信をしてみよう！　という事で、
まずは、3G通信を行う為のSIMの準備を行います。

・SIMの購入

今回購入した SIM は「SORACOM Air SIM カード(データ通信のみ) (ナノ)」となります。
SORACOM のサイトから購入する事も可能ですが、今回は、即日納品可能な Amazonで購入しました。

・SORACOMアカウント登録〜ログイン

SIMが用意出来たら、SORACOM社 のサイト(https://soracom.jp/)にてアカウント登録を行います。

アカウント登録後、ログインすると、以下のような画面が表示されます。
まだ SIM は何も登録されていない状態です。

・SIMの登録

「+SIM 登録」押すと、SIM の情報を入力するポップアップが表示されます。
IMSI・パスコードは、購入した SIM が取り付けてあるカードの後ろに記載してあります。

登録すると、先程の SIM の一覧に表示されます。

・通信料金

SORACOM社のサイト（ご利用料金 - 日本向け Air SIM）を見てもらうのが一番ですが、
注意すべき点は、「SIMを登録した時点から料金が発生する」という事です。
今回は、データ通信のみのSIMを登録したので、登録直後から、「１日５円」が発生します。 そして、実際に使い始めると、「１日１０円」の基本料金＋通信料が発生します。
（ま、それでもSORACOMは、かなりお安いと思います。）

さらに、使用する時間帯や、通信速度によっても料金が変わってくるので、気をつけましょう。

さて、SIMの準備が完了したので、次はRaspberry Pi 3 への 3GPI 取付と設定になります。


２）Raspberry Pi 3 への 3GPI 取付と設定
（http://blog.officekoma.co.jp/2016/11/raspberry-pi-3-3g-raspberry-pi-3-3gpi.html）