ツッコミ(2)

言及リンク:
willow710kut.hatenablog.com
(この人とは知り合いなので、チラシの裏的な感じはありますが……)

プライベートクラウドの定義は割と曖昧ですが、会社にある仮想マシンサーバのことをプライベートクラウドと言ったりもします。
Azureの定義では
>プライベート クラウドは、一般向けではなく特定のユーザーのみを対象とした、インターネットまたは内部のプライベート ネットワーク経由のいずれかで提供されるコンピューティング サービスであると定義されています。
なるほど。

MACアドレスはご指摘の通り、前半24bitを1ベンダで複数使用している場合も有ります。
MACアドレス検索 - UIC などを使って調べてみましょう。
ちなみに、VMWareの仮想マシンにおいては下位24bitはランダムに生成しているので、
別のVMWareインスタンスとカブったりするかも。
（vCenterとかで管理しているホストとは別に野良VMホストがいたら発生しそう）

OSI参照層は名前と通る順番だけ覚えてればOKです。
中を覚えるなら最低限必要なのはL1, L3, L7です。
Ethernetの種類(100M, 1Gbps, 10Gbpsと光/copperの違い)
IPルーティングの最低限の理解, TCPとUDP, TCP 3-way handshakeなどは理解しておいて損は無いでしょう。
余裕があればIPルーティングについて知識を深めると良いとは思いますが、最初はRIPもOSPFもBGPも見なかったことにしましょう。

L3層より上をきちんと理解したければRFCなどを参照すると良いと思いますが、最初はRFCを読む必要はないでしょう。

入門向けの本は本屋でインフラカテゴリの本をチラ見してわかりやすそうな本を買うと良いでしょう。

インフラの勉強

言及リンク:
willow710kut.hatenablog.com

以下、個人的な見解。
先に持論的を言うと「コードを書く人はインフラを知って欲しい」ということはある。
インフラエンジニアとして、「そんなコードを書かれるとログわからんから保守できねえ！」
とかそういうことは往々にしてあるわけで、そういう悲しい出来事を避けるために一定の経験はしておいて欲しいと言うことです。

が、インフラを触ったことがない人に対してそれは酷だし時間が無いってのも理解します。
この方は作りたい物があるようなので、それにそって自分なりにコストと時間を決めてサービスを作るのが良いと思います。
例えばリンク内にあったDocker。Dockerをホストするサーバを構築することができないなら、とりあえず
AWS Elastic Container Serviceとかを使ってショートカットするのがよいと思います。
もちろんお金は掛かりますが、とりあえずDockerのイメージより下は見えなくて済みます。
もっと言えばStatic HTMLなんてのはAWS S3等のサービスに入れておけば外部から見えるようになりますし、
CloudFrontとLambda@Edgeを使えばBasic認証もサーバレスで作ることはできます。
……すこし横道にそれました。

要するに、「どこの分野を」「どれ位の時間と」「どれ位のお金と」「労力を掛けて」サービスを作るかというところになります。
勉強も労力にカウントしますので、サーバレスアーキテクチャに慣れてる人はお金を掛けてAWSでバッチリ作り込めば時間も節約できるでしょう。
初心者であれば、上記のパラメータを上手に調節してサービスを作るのがよいでしょう。
ただし、作るのに夢中であとの保守を考えていなかった！なんてことにならないように設計しましょう。

AWS IoT GreenglassをRaspberry Pi 3にインストールする

AWS IoTの醍醐味(?) Greenglassを使うためにRaspberry Pi 3にインストールしていきます。

Greenglassを使うとGreenglassに関連付けたAWS IoTデバイスとGreenglassの間でLambdaスクリプトを実行することができ、データを整形したりした上でAWSのDynamoDBなどのサービスに投入することができます。また、GreenglassとAWS間の通信が途絶した場合でも、途絶した情報をGreenglassが保存していて通信が回復した時点で保存しているデータをAWSに送信する機能も付いています。

で、早速インストールします。基本はAWSのドキュメントに従っていれば構築できま………せん！
この通りにセットアップしてデプロイするとこんなメッセージが出ます

[2018-01-08T23:36:54.857+09:00][ERROR]-Runtime execution error: unable to start lambda container. container_linux.go:259: starting container process caused "process_linux.go:345: container init caused \"process_linux.go:286: setting cgroup config for ready process caused \\\"no such directory for memory.limit_in_bytes\\\"\""

ふぁーーー！？もしかしたら先駆者がいるかもしれないので落ち着いてググり……いらっしゃいました。

$ sudo nano /boot/cmdline.txt

として末尾に cgroup_memory=1 を追記して再起動すると解決します。

これでAWS ConsoleでGreenglass用のHello Worldをデプロイすると上手く行きます。

自動起動はこのページを参考にして作りました。

[Unit]
Description=greengrass daemon
After=network.target

[Service]
ExecStart=/greengrass/ggc/core/greengrassd start
Type=simple
RestartSec=2
Restart=always
User=root
PIDFile=/var/run/greengrassd.pid

[Install]
WantedBy=multi-user.target

Mongoose OSでJavaScript IoTプログラミング

Mongoose OSを使うと簡単にAWS IoT(w/Greenglass)が使えるんだって！
ってことで前回はFlash方法を書きましたが……

ざっとプログラムの書き方でも。Mongoose OSのJavaScriptではNode.JSっぽい感じに書けるようで、GPIOピンの割り込みイベントを作るには以下のように書くようです。

let button = 4;
let message = "MQTT Pub";
let topic = "hello/world";
GPIO.set_button_handler(button, GPIO.PULL_UP, GPIO.INT_EDGE_NEG, 200, function() {
  let ok = MQTT.pub(topic, message, 1);
  print('Published:', ok, topic, '->', message);
}, null);

これはGPIOピン4をbutton変数として定義し、GPIOがGNDに落ちた時の立ち下がりエッジを割り込みトリガーとするイベントの定義になっています。
200と定数がありますが、ここはチャタリングが発生しないようイベントの最低発火頻度をmsecで指定するようです。

イベントを定義している匿名関数では事前に指定したMQTTのBrokerのTopicにPubしてシリアルコンソールにメッセージを投げるようになっています。

その他については今後記述していきますが、とりあえず公式ドキュメントを見るとよいでしょう。

ESP8266でMongoose OSを触る

みんな大好きなESP8266で簡単にAWS IoT(Greenglass対応)に参加するべくMongoose OSをインストールしてAWS IoTにThing Deviceとして登録してみましょう。

Mongoose OSのサイト からmosを落としてきます。Windowsも対応してます。

Windows版のmosでは起動するとブラウザが立ち上がってくるので、ESP8266が接続されているCOMポートを選択してください。

ESP8266をUART Download Mode(IO0 => GND, IO2 => 3V3, IO15 => GND)に設定したらRSTをGNDに落として書き込みモードに入れます。mos側でESP8266のdemo-jsをFlashしてあげて、Flash Boot Mode(IO0 => 3V3以外は同じ)にして起動させてみます。無事起動するとTick Tockとコンソールに出るので、WiFiの設定を行います。

続いてAWSはMongooseのIDE側で使うAPI KeyをIAM側で作成します。

最低限以下のポリシーがあれば大丈夫です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iot:DescribeEndpoint",
                "iot:CreateThing",
                "iot:AttachThingPrincipal",
                "iot:AttachPrincipalPolicy",
                "iot:CreatePolicy",
                "iot:ListPolicies",
                "iot:CreateCertificateFromCsr"
            ],
            "Resource": "*"
        }
    ]
}

ゲットしたAPI KeyとSecretをMongoose OSのDevice Configから突っ込みます。

Provision with AWS IoTを押すと自動でThing Deviceとして登録されます。

Windows Hello for Business (WHFB) をやる。

前提

• Windows Server 2012 R2以上のサーバが一つ以上
  (AD CS / スキーマアップグレード後のAD DS)
• Windows Server 2016 のサーバが一つ
  (AD FS / AD DS(アップグレード用))
  （ラボ環境であれば2016のサーバが一つあればOK.)
• Azure ADのテナントをつくる
  （Azure AD Premiumのライセンスが必要か不明）

というのを満たせばWindows Hello for Business(以下WHFB)のハイブリッド証明書構成を構築することが出来ます。
WHFBのキー信頼構成を行うとAD CSの構築は不要ですが、ドメインコントローラのどれか1台にWindows Server 2016 が必ず必要になります。

工程

工程は次のようになります

• AD DSのインストール
  (Windows Server 2012の場合には2016スキーマへアップグレード)
• AD DSの設定
• AD CSのインストール
• AD CSの設定
• AD FSのインストール
• AD FSの設定
• AAD Connectorのインストール
• AAD Connectorの設定
• GPOの設定
• Device Registrationの確認
• ユーザごとのPIN設定

（そのうち続く）

ツッコミ

公開鍵と秘密鍵って？ SSL通信に使う暗号方式【35日目】 - エンジニアの卵_level3

公開鍵暗号のキモが説明出来てないのでちょっと補足。

公開鍵暗号では、「公開鍵」で暗号化した文章は「公開鍵」では復号できず、「秘密鍵」のみで復号できます。
（厳密に言うと逆も出来るけど、基本的にはこの形が多い）

共通鍵暗号では同じ鍵を使用して暗号化と複合化が出来るようになっています。

確かSSL通信では証明書の検証に公開鍵暗号を使用し、通信では共通鍵暗号を使用しています。
（共通鍵の安全な鍵交換についてはここでは省略します）