メモのページ - チラシの裏メモ 3枚目

気になった事を黙々とメモし続ける

VirtualboxとDocker Desktopの共存について

自分の環境だけだろうか、VirtualboxとDocker Desktopは同一PC内にて共存出来なかった。
Docker Desktopを削除し、WindowsLinuxサブシステムと仮想マシンプラットフォームを無効にした結果、ようやくVirtualboxのゲストOSのデプロイと起動と設定が可能になった。
以下は、Docker Desktopが入っていた環境にてVirtualboxのゲストOSを再びデプロイ・起動が出来るようにした際のメモ。


当方の環境
ホストOS:Windows10 64bit版 / RAM: 8GB / CPU: Intel Core i5 M460 2.53GHz
Docker Desktop for Windows:2.4.0.0
Oracle Virtualbox:6.1.16

ゲストOS:
Arista vEOS 4.24.2F/Aboot 8.0.0
HPE VSR1000 CMW710-E0621
Cisco CSR1000v 16.9.5
Cumulus VX 2.5.11
Cumulus VX 4.2.1
Cumulus VX 3.7.13



以下の流れで試してみた...
VirtualboxとDocker Desktopがインストールされた状態
VirtualboxにてゲストOSを起動:ゲストOSのウインドウが立ち上がるものの、真っ黒なまま何も表示されない。
VirtualboxにてゲストOSをデプロイ:ゲストOSのウインドウが立ち上がりGNU GRUBの画面が表示されるが、その先から進まない。

②Docker Desktopをアンインストール
上記①と状況は同じ

Virtualboxを再インストール
上記①と状況は同じ

WindowsLinuxサブシステムを無効化(※1)
HPE VSR1000とCumulus VX 2.5.11のみ、デプロイ・起動が可能になる。
他は上記①と同じ。

仮想マシン プラットフォームを無効化(※1)
Arista vEOSとCumulus VXとCisco CSR1000vもデプロイ・起動が可能になった。



結果
Cumulus VXはバージョン2.xと3.x以降でアーキテクチャが異なるのだろうか、上記④の段階で使えるようになった。
Docker Desktopの削除と仮想化支援機能の無効化で、ようやくVirtualboxがまともに使用出来るようになった。
Docker Desktopを使いたくなったら、仮想マシンプラットフォームとWindowsLinuxサブシステムを有効にし、Docker Desktopをインストールする。
毎回毎回上記の手順を繰り返すのは面倒。引き続き、共存可能な方法を探してみる。


以下の画像のキャラクターは、Cumulus LinuxのRocket Turtle。キャラクターが何故亀なのかは不明。
背負っている赤い筒状のような物はロケットで、取り外しは不可能。


※1 Windowsシステムツール>コントロールパネル>プログラム>プログラムと機能



https://www.virtualbox.org/ Oracle Virtualbox
https://www.docker.com/products/docker-desktop Docker Desktop
https://cumulusnetworks.com/lp/rocket-turtle-creator/ Rocket Turtle creator
https://cumulusnetworks.com/blog/hey-rocket-turtle-pimp-ride/ Hey Rocket Turtle, Pimp My Ride!

Cisco ISR4000シリーズルータのシャーシ~Ether Module間通信

Cisco ISR4000シリーズルータに触れる機会が有り、LAN側インタフェースにEtherModule SM-X-ES3-16Pを導入。
L2環境での筐体内部の通信、ISR4000ルータの筐体~Ether Module間の通信の設定に手間取った。
L3の設定ならCiscoのサイトに載っているもののL2の設定に関しては少し触れている程度。
試行錯誤の結果、以下の設定でLAN方向への通信が可能になったので、備忘録として残す。



当方の環境
ルータ:Cisco ISR4321 / IOS-XE 16.8.0
モジュール:SM-X-ES3-16P / IOS 15.2(3)E ※Catalyst3560X相当
LAN側はL2。対向先のデバイスとの間はそれぞれL2のLAG(Ether Channel)を組む事とする。


筐体内部の概要(クリックすると拡大表示します)

筐体とモジュール間の通信に、筐体側はinterface Ethernet-Internal 1/0/1と1/0/2、モジュール側はinterface GigabitEthernet0/17と0/18がアサインされている。
筐体側、モジュール側共に筐体~モジュール間通信で使用するインタフェースを変える事は出来ない。



設定の流れ
1.筐体側(IOS-XE)にて各種設定。
LAN方向に伸ばしたいVLAN(必要が有ればSVIも)を作成。
Ethernet-Internal 1/0/1にswitchport mode trunkとno negotiation autoを投入。
Ethernet-Internal 1/0/0には設定追加しなかったが、LAN方向への通信は出来た。
WAN方向の設定は要件に従って設定。


2.モジュール側(IOS)に入る。
hw-session module 1/0コマンドを打つ。
hw-session module 1/0の1という値は、対象となるEther Moduleが筐体のSlot1に挿入されている事を示す。
打った後に出力されるログを見ると、筐体内部のシリアルポート経由をモジュールにアクセスしているように見える。

# hw-session module 1/0

picocom v2.2
port is			:/dev/ttyDASH0
flowcontrol		:none
baudrate is		:9600
parity is		:none
:
:


3.モジュール側にて各種設定。
show versionを打つとCatalyst3560Xが動作しているように見える。ISR4321の内部でCatalyst3560Xが動作しているという変な感じ。
勿論、show inventoryやshow env all、show proccess cpu historyやdirコマンドも実行可能。
モジュール内では、Catalystスイッチと同様にEther Channelのインタフェース、LAN向けインタフェースにスイッチポートやL2のEther Channelの設定。
筐体と接続するポートGi0/17とGi0/18には、switchport mode trunkとswitchport trunk encap dot1qを投入。
SVIやWAN方向へのルーティングの設定は不要。
設定後は勿論、write memoryで設定内容を保存する。


4.モジュール(IOS)から抜けて筐体(IOS-XE)に戻る。
Ctrl + AとCtrl + Qで筐体に戻る事が出来る。


設定箇所の概要(クリックすると拡大表示します)

筐体側、筐体~Ether Module間インタフェース、Ether Module側の3か所にて、通したいVLANの設定が入っていれば通信が可能。
Ether Module側はL3SW化させない。L3SW化させたい場合は下記リンク先を参照。



参照
https://www.cisco.com/c/ja_jp/products/collateral/routers/4000-series-integrated-services-routers-isr/datasheet-c78-732542.html Cisco ISR4000シリーズルータ データシート
https://www.cisco.com/c/en/us/td/docs/routers/access/interfaces/eesm/software/configuration/guide/4451_config.html Cisco SM-X Layer 2/3 EtherSwitchモジュール 設定例

Docker Desktop for WindowsでArista cEOSコンテナの保存

Arista cEOSのDockerコンテナを他のDocker環境で使用する事を想定し、コンテナの保存方法を確認した。
今回は、Arista cEOSのDockerコンテナをDocker Desktopを動作させているPCのローカルディスクに一旦保存し、その後他のPCのDocker Desktopにて動作させる...といった事を想定。
コンテナをローカルのディスクに保存する方法は2つあるのだが、それぞれの方法で保存されたファイルの内容は異なっている。



当方の環境
ホストOS:Windows10 64bit版 / RAM: 8GB / CPU: Intel Core i5 M460 2.53GHz
作業用ディレクトリ:ホスト機のC:\Workspace
コンテナ:Arista Networks cEOS 4.24.2.1F 64bit版
Docker Desktop for Windows:2.4.0.0
Windows PowerShell 7.0.3



今回の前提条件
前回の記事にて導入されたArista cEOSが対象。
コンテナ移動先のDocker Desktop for WindowsWindows PowerShellのバージョンは、自分の環境と同じ。



Export/Importによる保存と読み込み
Dockerコンテナをファイルシステムとして保存。アーカイブとして保存され、メタ情報は含まれない。

docker psコマンドを打ち、exportするDockerコンテナの情報を確認。

> docker ps
CONTAINER ID      IMAGE                   COMMAND                  CREATED           STATUS              PORTS           NAMES
a11e1dade1ac      ceosimage:4.24.2.1F_1   "/sbin/init systemd.…"   3 minutes ago     Up 2 minutes                        cEOS-lab-4.24.2.1F_1
>
> docker images
REPOSITORY                      TAG                 IMAGE ID            CREATED             SIZE
ceosimage                       4.24.2.1F_1         411e80d356a3        4 minutes ago       1.77GB
>


docker exportコマンドを打ち、Arista cEOSコンテナをtar形式でアーカイブとして保存。

> docker export --output="C:\Users\User\Docker\vm-data\DockerDesktop\ceos-lab-4.24.2.1f-20201012-2355.tar" cEOS-lab-4.24.2.1F 


上記で作成したアーカイブを他の端末(勿論、自分の端末でもOK)に持ち込み。
持ち込み先のDocker Desktopにて、上記で作成したアーカイブをimportコマンドで読み込み。

> docker import C:\Users\User\Docker\vm-data\DockerDesktop\ceos-lab-4.24.2.1f-20201012-2355.tar ceosimage:cEOS-lab-4.24.2.1F-20201012-2355


Dockerイメージの一覧を確認。上記にて読み込まれたArista cEOSのイメージが出力されている。

> docker images
REPOSITORY          TAG                    IMAGE ID            CREATED             SIZE
ceosimage           cEOS-lab-4.24.2.1F_1   2844af232da3        10 seconds ago      1.77GB
>


docker createコマンドを打ち、上記にて読み込ませたイメージをコンテナ化する。
この後は前回と同じ流れで、docker network createでネットワーク作成、docker network connectでコンテナをネットワークに接続し、docker startでコンテナを立ち上げる。

> docker create --name=cEOS-lab-4.24.2.1F_1 --privileged -e INTFTYPE=eth -e ETBA=1 -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e CEOS=1 -e EOS_PLATFORM=ceoslab -e container=docker -i -t ceosimage:cEOS-lab-4.24.2.1F_1 /sbin/init systemd.setenv=INTFTYPE=eth systemd.setenv=ETBA=1 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker
cf92a89ba7c0f3f8755c4abbe93ea6ced6e5044c6bf70897ca6e542c6c69d15b
>


save/loadによる保存と読み込み

Googleで検索すると、docker loadまでは多くのサイト・ブログにて記載されている。
しかしそこから先の流れに関する記載はなかなか見つからず。試しに前回の初期構築時の長々としたコマンドを、runに置き換えたもので打ったら成功した。

まずはdocker commitコマンドでイメージの作成。
55266e136d62はイメージID、ceos-lab-4.24.2.1f-20201016-2340はイメージ名。

> docker commit 55266e136d62 ceos-lab-4.24.2.1f-20201011-2140


docker saveコマンドを打ち、作成したイメージをtar形式で保存。

> docker save ceos-lab-4.24.2.1f-20201011-2140 --output=C:\Users\User\Docker\vm-data\DockerDesktop\ceos-lab-4.24.2.1f-20201011-2140.tar


他の端末のDocker Desktopにて、上記で保存したイメージを解凍し読み込ませる。

> docker load --input="C:\Users\User\Docker\vm-data\DockerDesktop\ceos-lab-4.24.2.1f-20201011-2140.tar"
c721a7ac8eae: Loading layer [==================================================>]  1.836GB/1.836GB
c27e2b925526: Loading layer [==================================================>]  2.111MB/2.111MB                      
Loaded image: ceos-lab-4.24.2.1f-20201011-2140:latest


Dockerイメージの一覧を確認。上記にて読み込まれたArista cEOSのイメージが出力されている。

> docker images
REPOSITORY                         TAG                 IMAGE ID            CREATED             SIZE
ceos-lab-4.24.2.1f-20201011-2140   latest              b3c2204bbfd3        About an hour ago   1.77GB
>


docker runコマンドを打ち、上記にて読み込まれたコンテナを起動させる。
どこかで見た、長々としたオプション。初回導入時(docker create)の際に投入したオプションとほぼ同じ。

  • dオプションを付けると、PowerShellのウインドウをもう1枚立ち上げる必要は無くなる。
>docker run -d --name b3c2204bbfd3 --privileged -e INTFTYPE=eth -e ETBA=1 -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e CEOS=1 -e EOS_PLATFORM=ceoslab -e container=docker -i -t ceos-lab-4.24.2.1f-20201011-2140 /sbin/init systemd.setenv=INTFTYPE=eth systemd.setenv=ETBA=1 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker

今回の振り返り。
saveはDockerコンテナとして保存、レイヤの構造やメタ情報が含まれる。
exportはアーカイブとして保存。ファイルシステムが保存される。
単に自分の環境で立てたDockerコンテナを手を加えずそのまま他の環境に持ち出すだけなら、save/loadとexport/importのどちらでも良さそう。
一部のdockerコマンドにてGoogleで検索し引っかかった内容をそのまま実行する事が出来ない事も分かった。ファイルの保存先を指定するオプションの書き方。
上記の一連の流れでは他は無かったと思うが、Linux環境とWindowsPowerShell環境との差異に要注意。





参照サイト
https://hodalog.com/how-to-save-and-load-docker-container/ dockerコンテナをバックアップ・保存・ロードしたりする方法 (HODALOG)
https://qiita.com/leomaro7/items/e5474e67a8e41536f0ff  Docker save→load export→import どっち?(leomaro7さん)
https://debslink.hatenadiary.jp/entry/20200906/1599399643 前回の記事 (Docker Desktop for WindowsでArista cEOS)
https://www.arista.com/en/ Arista Networks
https://www.arista.com/jp/support/software-download cEOSのダウンロードサイト有り

Docker Desktop for WindowsでArista cEOS

インフラエンジニアやWebエンジニアの方々にはお馴染みのDocker、しかしオンプレ環境を対象としたネットワークの設計の業務に携わっている者にとって、業務で触れる機会が殆ど無いツールだろう。
このままではいけないという危機感は無いが、1台のソフトウェアルータを動作させるだけで精一杯なVirtualboxな検証環境からの脱却を図るべく他の手段を調べていると、Docker環境では複数台のコンテナを同時に立ち上げられる事と、コンテナ同士で通信が可能である事が分かった。
VMware Playerでも複数台の仮想ルータ/スイッチを同時に立ち上げられる事は知っていたが、Dockerでも同じような事が出来るのであれば、VMware PlayerやVirtualboxからDockerへの移行を計画しよう、ついでにDockerの勉強も開始しよう...という事で、Dockerの手始めとしてArista Networksのソフトウェアルータ、cEOS-labのコンテナを作成してみた。
今回は、Docker DesktopにArista Networksのソフトウェアルータ、cEOS-labのコンテナを3台作成し、各コンテナ間でOSPFネイバを張ってみた時のメモ。



Docker Desktopとは
Docker Desktopとは、MacOSおよびWindows環境にてDocker EngineやKubernetes等が簡単に実行可能な環境。



当方の環境
ホストOS:Windows10 64bit版 / RAM: 8GB / CPU: Intel Core i5 M460 2.53GHz
コンテナ:Arista Networks cEOS 4.24.2.1F 64bit版
Docker Desktop for Windows:2.3.0.4



Docker Desktop for Windowsのインストール
Docker Desktop for Windowsを初めてインストールする際、Hyper-Vの有効化とWindows PowerShellのインストールが必要となる。
自分の環境ではWindows PowerShell 1.0が既にインストール済みだったが、最新版を改めてインストールした。
インストールの前に、Hyper-Vを有効化。
スタートボタンからWindowsシステムツールに入り、コントロールパネルを選択。プログラム→Windowsの機能の有効化または無効化→Hyper-Vの順に移り、Hyper-Vにチェックを入れてOKをクリック。設定内容をシステムに反映させる為、Windows10を再起動させる。


次は、Windows PowerShellのインストール。
以下からプレビュー版のv7.1.0-preview.6ではなく、v7.0.3のインストーラ(PowerShell-7.0.3-win-x64.msi)をダウンロードし、インストール。
https://github.com/PowerShell/PowerShell/releases


Windows PowerShellのインストールの次は、Docker Desktop for Windowsのインストール。
以下のリンク先にてDocker Desktop欄内のDownload for Windowsをクリックし、インストーラーのファイルをダウンロード。
ダウンロード後はインストーラー(自分の環境では、Docker Desktop Installer.exe)を叩いてインストール開始。
https://www.docker.com/get-started



Arista cEOSの準備
Arista Networksのダウンロードサイトにアクセスし、cEOS-labを選択。
バージョンは、現段階では最新のEOS-4.24.2.1Fを選択。cEOS64-lab-4.24.2.1F.tar.xzファイルをダウンロードした。
手順は、ダウンロードサイト内に有るcEOS-lab-README-generic.txtを参考にした為、cEOS-lab-README-generic.txtもダウンロードした。



Docker Desktop for Windowsの設定
自分の環境では、デフォルト設定ではcEOSを複数台立ち上げるとエラーが頻発し、cEOS-labのCLIに入る事が出来なかった。
以下に設定変更する事で、3台のcEOS-labを立ち上げてOSPFのネイバを張る事に成功した。

Dockerのアイコンを右クリックし、Dashboardを選択。※Windows10の場合、タスクバー内の小さなアイコン。
Docker Desktopのウインドウ内右上の歯車のようなアイコンをクリックし、Resourcesを選択。
・ADVANCEDにてCPUsを2に修正、Memoryを2.25GBに修正。
・動作には関係しないと思うが、Disk image locationをアクセスし易いフォルダに修正。
・設定を終えたらDocker Desktopのウインドウ内右下の「Apply & Restart」をクリックし、設定内容を反映させる。ここでDocker Desktopは再起動する。



いよいよ、cEOS-labのインポート
Googleで検索すると幾つかのサイトがヒットする。
検索で引っかかったサイトに書かれている内容を実行したものの、自分の環境ではcEOS-labを立ち上げる事が出来なかった。
Arista cEOSのダウンロードサイトに有る「cEOS-lab-README-generic.txt」の内容と下記リンク先に記載したブログの内容を合わせた感じで実行した結果、cEOS-labを立ち上げる事が出来た。
今回は3台のcEOS-labでOSPF構成を組む為、cEOS-lab-README-generic.txtの内容を少し内容を修正している。



以下より、Windows PowerShellにて実行。
1.以下のコマンドを打ち、ダウンロードしたcEOS-labのファイル(イメージ)をインポート。
今回は3台のcEOS-labをインポートする為、イメージの名称(ceosimage)が重複しないよう番号を降った。

>docker import cEOS64-lab-4.24.2.1F.tar ceosimage:4.24.2.1F_1
>docker import cEOS64-lab-4.24.2.1F.tar ceosimage:4.24.2.1F_2
>docker import cEOS64-lab-4.24.2.1F.tar ceosimage:4.24.2.1F_3


2.以下のコマンドを打ち、cEOS-labコンテナの生成。
今回は初Dockerにつき細かな設定は行わず、インスタンス名およびイメージ名以外はcEOS-lab-README-generic.txtの内容をそのまま拝借。
よって長いオプションとその意味は何であるか考慮無しに、コマンドを投入している。

>docker create --name=cEOS-lab-4.24.2.1F_1 --privileged -e INTFTYPE=eth -e ETBA=1 -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e CEOS=1 -e EOS_PLATFORM=ceoslab -e container=docker -i -t ceosimage:4.24.2.1F_1 /sbin/init systemd.setenv=INTFTYPE=eth systemd.setenv=ETBA=1 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker
>docker create --name=cEOS-lab-4.24.2.1F_2 --privileged -e INTFTYPE=eth -e ETBA=1 -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e CEOS=1 -e EOS_PLATFORM=ceoslab -e container=docker -i -t ceosimage:4.24.2.1F_2 /sbin/init systemd.setenv=INTFTYPE=eth systemd.setenv=ETBA=1 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker
>docker create --name=cEOS-lab-4.24.2.1F_3 --privileged -e INTFTYPE=eth -e ETBA=1 -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e CEOS=1 -e EOS_PLATFORM=ceoslab -e container=docker -i -t ceosimage:4.24.2.1F_3 /sbin/init systemd.setenv=INTFTYPE=eth systemd.setenv=ETBA=1 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker


3.Docker内部で使用するネットワークの作成。
Googleでコンテナ間の通信に関して検索すると幾つかの方法が見つかったが、今回は一番簡単な方法で。
自分の環境では、--subnetオプションでネットワークアドレスを指定したら各コンテナ間で通信が可能になった。

>docker network create --subnet 192.168.185.32/28 --attachable net1
>docker network create --subnet 192.168.202.0/24 --attachable net2
>docker network create --subnet 192.168.203.0/24 --attachable net3
>docker network create --subnet 192.168.204.0/24 --attachable net4


4.上記3にて作成したネットワークを、cEOS-labコンテナに適用。

>docker network connect net1 cEOS-lab-4.24.2.1F_1
>docker network connect net2 cEOS-lab-4.24.2.1F_1
>docker network connect net3 cEOS-lab-4.24.2.1F_1
>docker network connect net4 cEOS-lab-4.24.2.1F_1

>docker network connect net1 cEOS-lab-4.24.2.1F_2
>docker network connect net2 cEOS-lab-4.24.2.1F_2
>docker network connect net3 cEOS-lab-4.24.2.1F_2
>docker network connect net4 cEOS-lab-4.24.2.1F_2

>docker network connect net1 cEOS-lab-4.24.2.1F_3
>docker network connect net2 cEOS-lab-4.24.2.1F_3
>docker network connect net3 cEOS-lab-4.24.2.1F_3
>docker network connect net4 cEOS-lab-4.24.2.1F_3


5.cEOS-labコンテナの起動。
以下のコマンド3つを一度に流すのではなく、1台づつコンテナを立ち上げると各コンテナ共に正常に起動完了する。

>docker start cEOS-lab-4.24.2.1F_1
>docker start cEOS-lab-4.24.2.1F_2
>docker start cEOS-lab-4.24.2.1F_3


6.cEOS-labに入る
cEOS-labコンテナの状態は、以下のコマンドで確認出来る。
オプション--format='{{.State.Status}}'無しの場合、出力内容が多くなりrunningの文字列を見つけ辛い。

>docker inspect --format='{{.State.Status}}' cEOS-lab-4.24.2.1F_1
running

出力内容がrunningであれば起動完了。以下のコマンドを打つとArista cEOSのCLIにアクセスする。

>docker exec -it cEOS-lab-4.24.2.1F_1 Cli


cEOSの設定
OSPFおよびVRRPの設定コマンドはCisco IOSと酷似している為、ここでは割愛。
酷似といったレベルではなくほぼ同じな上、通信プロトコルはベンダ独自規格な実装でない限り動作はほぼ同じと思われる為、そう言えばあのコマンド何だっけ?という場面で確認用として使えそう。
以下の図は、今回の検証で組んだ構成を表す。


設定の結果、Docker内部のネットワーク設定を各コンテナに適用させる事により、3つのcEOS-labの間でOSPFのネイバを張る事と、2台のcEO-labS(RT#1,RT#2)の間でVRRP構成を組む事が出来た。
show ip ospf neighborsコマンドはエラーを吐いて出力出来なかったが、show ip ospf neighbors summaryでは認識出来ていた。

jpmtkdkrt01#
jpmtkdkrt01#show ip ospf neighbor
Neighbor ID     Instance VRF      Pri State                  Dead Time   Address         Interface

% Internal error
% To see the details of this error, run the command 'show error 1'
jpmtkdkrt01#
jpmtkdkrt01#
jpmtkdkrt01#show ip ospf neighbor summary
OSPF router with (Instance ID 11) (VRF default)
      0 neighbors are in state DOWN
      0 neighbors are in state GRACEFUL RESTART
      0 neighbors are in state INIT
      0 neighbors are in state LOADING
      0 neighbors are in state ATTEMPT
      1 neighbors are in state FULL
      0 neighbors are in state EXCHANGE
      0 neighbors are in state 2 WAYS
      0 neighbors are in state EXCH START
jpmtkdkrt01#
jpmtkdkrt98#show ip ospf neighbor
Neighbor ID     Instance VRF      Pri State                  Dead Time   Address         Interface

% Internal error
% To see the details of this error, run the command 'show error 0'
jpmtkdkrt98#
jpmtkdkrt98#
jpmtkdkrt98#show ip ospf neighbor summary
OSPF router with (Instance ID 11) (VRF default)
      0 neighbors are in state DOWN
      0 neighbors are in state GRACEFUL RESTART
      0 neighbors are in state INIT
      0 neighbors are in state LOADING
      0 neighbors are in state ATTEMPT
      2 neighbors are in state FULL
      0 neighbors are in state EXCHANGE
      0 neighbors are in state 2 WAYS
      0 neighbors are in state EXCH START
jpmtkdkrt98#
jpmtkdkrt99#show ip ospf neighbor
Neighbor ID     Instance VRF      Pri State                  Dead Time   Address         Interface

% Internal error
% To see the details of this error, run the command 'show error 0'
jpmtkdkrt99#
jpmtkdkrt99#
jpmtkdkrt99#show ip ospf neighbor summary
OSPF router with (Instance ID 11) (VRF default)
      0 neighbors are in state DOWN
      0 neighbors are in state GRACEFUL RESTART
      0 neighbors are in state INIT
      0 neighbors are in state LOADING
      0 neighbors are in state ATTEMPT
      1 neighbors are in state FULL
      0 neighbors are in state EXCHANGE
      0 neighbors are in state 2 WAYS
      0 neighbors are in state EXCH START
jpmtkdkrt99#

VRRPは以下のとおり。
設定内容のとおり、RT#1(jpmtkdkrt98)はVRRP Master機、RT#2(jpmtkdkrt99)はVRRP Backup機になっていた。

jpmtkdkrt98#show vrrp brief
Interface VRF        ID  Ver Pri Time  State  Last Transition     VR IP Addresses
--------- ---------- --- --- --- ----- ------ ------------------- ---------------
Et4       default    11  2   105 3580  Master 00:02:27 ago        192.168.200.1
jpmtkdkrt98#
jpmtkdkrt98#
jpmtkdkrt99#show vrrp brief
Interface VRF        ID  Ver Pri Time  State  Last Transition     VR IP Addresses
--------- ---------- --- --- --- ----- ------ ------------------- ---------------
Et4       default    11  2   95  3620  Backup 00:02:00 ago        192.168.200.1
jpmtkdkrt99#
jpmtkdkrt99#


今回はcEOS-labをインポートし通信設定しただけで終えたが、DockerやDocker Desktopで何が出来るか、インポートの先は何か把握していない。
MirageOS Unikernelとの絡みもあまり理解していない。この先は参考書を買って少しづつ勉強を進めたい。
また、Dockerで検証環境がある程度のレベルまで組めそうな事は分かった。cEOS-labのもう少し古いバージョンと、Docker DesktopのResourcesの設定次第では4~5台の構成を組めそうな気がした。





リンク先
cEOS-labのインポートにおいて非常に参考になったのは、cEOSのダウンロードサイトに有るcEOS-lab-README-generic.txtの記載内容と、akira6592様のブログの記事。
AristaのvEOSやcEOSを知ったのは、CiscoからAristaに移籍した某先生のJANOGのプログラム内容にて。

https://www.docker.com/ Docker
https://docs.docker.com/ Dockerのドキュメントサイト
https://www.arista.com/en/ Arista Networks
https://www.arista.com/jp/support/software-download cEOSのダウンロードサイト有り
https://tekunabe.hatenablog.jp/entry/2018/12/17/arista_cEOS-lab_one Arista EOS の検証用コンテナ版「cEOS-lab」の環境構築手順(1台編)
https://www.janog.gr.jp/meeting/janog43/application/files/5015/4800/2310/janog43-shtsuchi-lxc-00.pdf ネットワークの上のコンテナネットワーク

Fortinet NSE試験を受けてみた

UTM(Unified Threat Management:総合脅威管理)製品の世界シェア1位であるFortigateの開発および生産、販売を行っているFortinet社の認定試験、Fortinet NSE Level1を帰宅後に受験してみた。



Fortinet NSE試験とは
セキュリティアプライアンス機器ベンダであるFortinet社が主催している認定試験。ネットワークセキュリティの概念や、Fortinet社製セキュリティアプライアンス機器による設定や運用等のテクニカルスキルが問われる。
Fortinet NSE(Network Security Expart)試験は、難易度や出題分野によってLevel1からLevel8まで8段階に分かれている。
Level1からLevel3はFortinet NSEのサイト内に用意されている自習型教材(動画)をオンラインで受講し、テストを受験する。インターネットへの接続可能な環境が有れば、どこでも受講、受験が可能。
Level4以降はCisco SystemsCCNACCNP同様にPiason VUEで受験するが、最高位のLevel8はラボ試験も有る。



Fortinet NSE Level1の対象
・インターネットのセキュリティ、ネットワークセキュリティの入門者
・ネットワークセキュリティの入門レベルの英語のウェビナーを視聴したい人 ※視聴しなくても受験可能


受験の動機
8月より新規に着任した案件にて、Fortinet社製ファイアウォールFortigateに触れる事になった。
着任早々にFortigateの挙動に関する調査を行う事になったが、触れていくうちにFortigateのアーキテクチャや挙動に関して興味を持ち始め、Fortigateの勉強を開始。ふと、Cisco SystemsやJuniper Networksのように認定試験が有るのか調べたら、Fortinet NSE Instituteが実施しているFortinet NSE Level1~Level8まで8つの認定試験が有る事が分かった。
Fortigate 50Eの中古機とFortigateの参考書は購入済みで学習環境は揃っている。Fortigateの勉強がてら、まず最初に入門レベルのFortinet NSE Level1の勉強と受験を試みた。



試験要綱
以下の4つのセクションの動画を視聴し、各セクション終了後にテスト問題を解く。
テスト問題は各セクション共に80%以上の正答率で合格。全セクションで80%以上の正答で完了する事で、晴れてFortinet NSE Level1の認定となる。
・Bad Actors
・Data Security Perspectives
・Password Perspectives
・Internet Threat Perspectives
対応言語は英語とスペイン語ポルトガル語のみ。

2020/8/31追記
各セクションの動画の受講とテスト問題は共に無料。



受験準備
通信やITの業界に居る人の多くは、自社や常駐先にてセキュリティ研修を受講するだろう。それらの内容を覚えていれば予習は不要かも。自分はつい先日受講し内容を覚えている為、セキュリティ全般を網羅するような内容の参考書は購入せずそのまま突撃した。



いざ受験
Level1とLevel2はPCのWebブラウザにて受講と受験が可能だ。自分の場合、帰宅後に実施した。
動画視聴や受験の前に、まずはFortinet NSE Institute用のアカウント作成から始める。
Fortinet NSE InstituteのWebサイトにアクセスし、画面右上のLog inをクリックしSign Upをクリック。
個人での受講、受験である為、Log Inページにて「Public」を選択。
Sign In画面内下部のSign Upをクリックし、遷移先のページにてメールアドレスや勤務先等の情報を入力し、Fortinet NSE用のアカウントを作成する。Fortigateのユーザサポート用アカウントはFortinet NSE用アカウントと紐付け出来ない為、新規に作成しなければならない。
アカウント作成後、すぐに受講・受験が可能になる。


動画を視聴した後にテストを受験する。
8割の正答で合格となり次のセクションに進む。合格になるとPASSの文字列が表示される。合格となっても画面右下にテスト開始のボタンが有る為、本当に次に進んで良いか少し不安になるが、次のセクションに進むには画面左上の「Information Security Awareness」をクリックし、Dashboard画面に戻り次のセクションにアクセスする。
合格時に画面右下のテスト開始ボタンをクリックしても次のセクションの問題は表示されない。合格しても今居るセクションの問題を何度も解けるというやつだ。
テスト問題の正答率が8割を切った際は、8割超えるまで何度もテストを受験出来る。



結果
4つのセクション全て8割以上の正答で合格し、Fortinet NSE Level1に認定された。
Piason VUEで実施するような試験とは異なり、合格しましたおめでとうといった感じのページに遷移しない為、本当にNSE Level1に認定されたかどうか不安になるが、5分程後にDashboardに戻ると、Completedのステータスになっている事から完了した事が分かる。

終えてから約30分経つと、Dashboardページやアカウントのプロファイルページにて認定証のダウンロードリンクが表示されるようになり、クリックすると認定証のPDFファイルがダウンロードされる。



難易度
動画およびテスト問題は入門者レベルで、企業で一般的に行われているIT・非IT業務従事者向けの基本的なセキュリティ研修と同レベルと思われる。
テスト問題の英文は公立校の高校受験レベルで長文は無い。業務にて通信機器ベンダの英語のドキュメントを何となく読める、オライリーの英語版を少しづつではあるが読める...というレベルであれば臆する事は無い。
動画の英語はやや早口で聞き取り辛かったが動画は何度も再生可能、且つ重要な用語や短文は動画内で表示される為、テスト問題自体は決して難しくはない。英語さえ何とかなれば楽勝。
動画の登場人物の属性は善悪が見た目ではっきりしていて、英語が聞き取り辛くても非常に分かりやすい。彼らはテスト問題を解き進める上で鍵となるので、どういった事をする人達なのか把握すると良い。
Fortinetの製品やFortigateのアーキテクチャや機能、ファイアウォールの設定等はLevel1の範囲外につき出題されなかった。Level1に関しては、Fortigateの中古機器や参考書を使用した学習は不要。
Level1の場合、早ければ4つの動画全ての視聴とテスト問題の受験で1時間程度で完了するだろう。



その他
実はLevel2も認定済である。Level2はセクションの数が3倍程に増えている為、帰宅後に一気に進めると非常に疲れる為、2日間に分けたり休日に1日かけて実施する方が良いかもしれない。
Level3は、Fortinet社の従業員とパートナー契約を結んでいる企業の従業員のみ受講、テストの受験が可能である。よって自分の場合は次に進めるとなるとLevel4になる。
他のIT系認定試験でたまに見かける、オンラインで試験官とのやりとりは一切発生しない。途中で飲食やトイレ休憩等は可能。





https://www.fortinet.com/ (Fortinet)
https://training.fortinet.com/ (Fortinet NSE Institute)
https://training.fortinet.com/local/staticpage/view.php?page=nse_1 (Fortinet NSE Level1)

MirageOS Unikernelでデータベース

前回は、MirageOSのチュートリアルとして用意されているWebサーバ「static website tls」をローカルで立ち上げ、テキストベースのWebブラウザLynxを使用し、WebサーバへのHTTPアクセスを成功させた。
ここまで来たら、次はファイルサーバやAPサーバだな、という事でMirageOSのGithub内を探してみたら、Irminを見つけた。README.mdを見るとデータベースとの事。
MirageOSのお試しとして不足無し...という事で、今回はOcamlで書かれたデータベースIrminの導入を試みた。
データベースは予備知識ほぼゼロな状態で業務・個人環境共に初めて触れる為、今回はIrminの導入と簡単なデータ(文字列)の出し入れに留めた。

※前回:https://debslink.hatenadiary.jp/entry/20200726/1595768920 (MirageOS UnikernelでWebサーバ)
※前々回:https://debslink.hatenadiary.jp/entry/20200718/1595076105 (Ubuntu 20.04でMirageOS Unikernel)



当方の環境
ホストOS:Windows10 64bit版 / RAM: 8GB / CPU: Intel Core i5 M460 2.53GHz
ゲストOS:Ubuntu Server 20.04 x86 64bit版
Virtualbox 5.2.32
MirageOS 3.8.0
OCaml 4.10.0
今回よりホスト機のOSがWindows7 32bit版からWindows10 64bit版に変更。
Ubuntu Linuxは既にデプロイ済みである事とする。
PCのCPU仮想化支援機構はBIOSにて既に有効設定済みである事とする。
Ubuntu Linuxカーネルやバージョンやインストール済みのツール等は、前回のWebサーバ構築以降変えていない。



MirageOSのインストール
MirageOSインストールの準備、opamの環境設定、MirageOSのインストールに関しては、以下のリンク先を参照。
https://debslink.hatenadiary.jp/entry/20200718/1595076105



データベース Irminのインストール
Irminとはgitライクなデータベースで、OCamlで書かれている。
MirageOSプロジェクトの中の一つである為、UnikernelsやMirageOSがメジャーな存在になる、OCaml以外の他の言語で再作成される等のような事が無い限り、今後も存在自体が多くのプログラマやデータベースエンジニア達に気付かれる事は無いだろう。
Irminの特徴や使い方は下記のリンク先を参照する事とし、インストールを開始。


Irminのインストールは非常に簡単で、opam install irmin-unixコマンドを実行すればIrminと実行に必要なパッケージが自動でダウンロードとインストールされる。
自分の環境では、Irminとコマンドラインツール、動作に必要なパッケージ群を一度にインストールする為、opam install irmin-unixを実行。
インストールに関しては選択肢が有り、ミニマルインストールで良い場合はopam install irminコマンド、インメモリーデータベースで良い場合はopam install irmin-memコマンドを実行する。


eval $(opam env)を打って環境変数の設定後、まずはopamコンパイラのバージョンを確認。インストールされているのは最新版の4.10。

$ eval $(opam env)
$ opam switch list
#  switch   compiler                    description
→  4.10.0   ocaml-base-compiler.4.10.0  4.10.0
   default  ocaml-system.4.08.1         default
$


MirageOSのバージョンを確認。最新版の3.8.0である事が分かる。

$ mirage --version
v3.8.0
$ 


実行環境の確認を終えたら、Irminのインストールに進む。
Irmitのインストールに伴い、動作に必要なパッケージが自動で追加ダウンロードとインストールが実行される。DebianUbuntuのaptコマンドのようで楽。
Do you want to continue? と聞かれたらyキーを叩いて、ダウンロードとインストールを進める。

$ opam install irmin-unix
The following actions will be performed:
  ? install conf-pkg-config         1.2          [required by ctypes]
  ? install dispatch                0.4.1        [required by webmachine]
  ? install base64                  3.4.0        [required by irmin]
  ? install menhirLib               20200624     [required by menhir]
  ? install uchar                   0.0.2        [required by jsonm]
:
省略
:
  ? install git-http                2.1.3        [required by git-unix]
  ? install conduit-lwt-unix        2.2.2        [required by cohttp-lwt-unix]
  ? install cohttp-lwt-unix         2.5.4        [required by git-unix]
  ? install git-unix                2.1.3        [required by irmin-unix]
  ? install irmin-unix              2.2.0
===== ? 77 =====
Do you want to continue? [Y/n] y


yキーを叩いた後、Irmin含め、77個のパッケージのダウンロードとインストールが開始される。

<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[base64.3.4.0] downloaded from cache at https://opam.ocaml.org/cache
[angstrom.0.14.1] downloaded from cache at https://opam.ocaml.org/cache
[bigarray-compat.1.0.0] downloaded from cache at https://opam.ocaml.org/cache
[base.v0.14.0] downloaded from cache at https://opam.ocaml.org/cache
[bigarray-overlap.0.2.0] downloaded from cache at https://opam.ocaml.org/cache
:
省略
:
? installed graphql.0.13.0
? installed graphql-cohttp.0.13.0
? installed graphql-lwt.0.13.0
? installed irmin-graphql.2.2.0
? installed irmin-unix.2.2.0
Done.
$


これでIrminのインストールが完了。今回よりホスト機をスペックが高いPCに替えた事も有ってか、早く完了した。
インストールが成功すると、以下のようにIrminのバージョンを確認出来る。

$ irmin --version
2.2.0
$


Irminの動作確認
インストール後、Irminのチュートリアルページの内容を参考に、IrminのCLIで簡単な動作確認。
irmin initコマンドで初期化後、新規にストアを作成しIrmin TESTという文字列の出し入れを行ってみた。

$ cd .opam/4.10.0/.opam-switch/sources/irmin-unix.2.2.0
$ echo "root: ." > irmin.yml
$
$ irmin init
$ irmin set foo/bar "Irmin TEST"
$ irmin get foo/bar
Irmin TEST
$


また、Irminはgitライクなデータベースをうたっている事もあり、gitコマンドを絡めて以下のように文字列の出し入れのような事も出来る。

$ export EXAMPLE=/tmp/irmin/example
$ mkdir -p $EXAMPLE
$
$ irmin set -s git --root $EXAMPLE "My key" "My value"
$ irmin get -s git --root $EXAMPLE "My key"
My value
$

今回の構成は以下の図のとおり。
今までとは異なり、Ubuntu LinuxとMirageOSとの間にSolo5環境は存在しない。



今回の振り返り。
簡単な文字列の出し入れのみではあるが、データベース「Irmin」の実行および簡単な文字列の出し入れに成功した。
opam installコマンドだけでIrminや動作に必要なパッケージのインストールや初期設定が自動で実行され、導入自体は拍子抜けする程楽だった。
Irminをデータベースの学習のきっかけとして今後も触れてみるかと言うと、IrminはOCamlの知識が前提となっている上、巷では多く導入されているMySQLOracle等とは方向性が異なるもののようなので、こういった物もMirageOSで動作させる事が出来るんだよ...といった程度で収めようと思う。





リンク先
https://mirage.io/ Mirage OS
https://github.com/mirage Mirage OS (github)
https://ocaml.org/ OCaml
https://releases.ubuntu.com/20.04/ Ubuntu 20.04
https://irmin.org/ Irmin
https://github.com/mirage/irmin Irmin (github)


過去のMirageOSのエントリ
https://debslink.hatenadiary.jp/entry/20200726/1595768920 前回:MirageOS UnikernelでWebサーバ
https://debslink.hatenadiary.jp/entry/20200718/1595076105 前々回:Ubuntu 20.04でMirageOS Unikernel
https://debslink.hatenadiary.jp/entry/20200526/1590495778 前々々回:MirageOS Unikernelで通信プログラムの実行
https://debslink.hatenadiary.jp/entry/20200516/1589616362 初回:MirageOSのインストールとHello Worldの実行


自分にとって、UnikernelsやMirageOSの始めの一歩となったサイト (MirageOS のインストールから Hello World までを試す)
https://qiita.com/t-imada/items/6ee299653ac063532b4f

MirageOS UnikernelでWebサーバ

前回は、Ubuntu Linuxの最新バージョン20.04にMirageOSをインストール、Hello Worldアプリの実行を成功させた。
Hello Worldアプリは立ち上げてHello Worldを自動で出力させるだけ。これで満足するするような自分ではない。もっと本格的なツール、例えばFTPサーバやWebサーバ等は無いか探したところ、チュートリアル的なDNSサーバやHTTPサーバ等がmirage-skeltonディレクトリ配下やGithubに有る事に気が付いた。
4連休全て天気予報は雨との事で外出の予定無し。時間はたっぷり有る。
...という事で、今回は簡易なWebサーバ「static website tls」の導入を試みた。
※前回:https://debslink.hatenadiary.jp/entry/20200718/1595076105



当方の環境
ホストOS:Windows7 32bit版 / RAM: 4GB / CPU: Intel Core i3-2350M 2.30GHz
ゲストOS:Ubuntu Server 20.04 x86 64bit版
Virtualbox 5.2.32
MirageOS 3.8.0
OCaml 4.10.0
Ubuntu Linuxは既にデプロイ済みである事とする。
PCのCPU仮想化支援機構はBIOSにて既に有効設定済みである事とする。
Ubuntu Linuxカーネルやバージョンやインストール済みのツール等は、前回のHello Worldから変えていない。



MirageOSのインストール
MirageOSインストールの準備、opamの環境設定、MirageOSのインストールに関しては、以下のリンク先を参照。
https://debslink.hatenadiary.jp/entry/20200718/1595076105



下準備
前回ではopamおよびMirageOSのインストールの為に外部リポジトリの使用を試みたものの、Ubuntu 20.04用のディレクトリがまだ準備されていなかった為に、Ubuntuリポジトリを使用しインストールした。
ところが外部リポジトリの設定の事はすっかり忘れ、消さずにそのまま残していた為にapt-getで導入済みのツールのアップデートが出来なかった。
よって、今回は外部リポジトリの削除から始めた。

$ sudo apt-get update
Hit:1 http://jp.archive.ubuntu.com/ubuntu focal InRelease
Get:2 http://jp.archive.ubuntu.com/ubuntu focal-updates InRelease [111 kB]
Get:3 http://jp.archive.ubuntu.com/ubuntu focal-backports InRelease [98.3 kB]
Get:4 http://jp.archive.ubuntu.com/ubuntu focal-security InRelease [107 kB]
Ign:5 http://ppa.launchpad.net/avsm/ppa/ubuntu focal InRelease
Err:6 http://ppa.launchpad.net/avsm/ppa/ubuntu focal Release
  404  Not Found [IP: 91.189.95.83 80]
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/avsm/ppa/ubuntu focal Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
$
$ sudo add-apt-repository --remove ppa:avsm/ppa
[sudo] password for hoge: 
 Latest stable versions of OCaml and OPAM.
 More info: https://launchpad.net/~avsm/+archive/ubuntu/ppa
Press [ENTER] to continue or Ctrl-c to cancel removing it.


apt-get updateおよびapt-get upgradeの次は、Ubuntu Linux側でtap0インタフェースの作成。Ubuntu LinuxとMirageOSとの間の通信にてtap0インタフェースが使用される為である。
Ubuntu Linux側では既に生成されているブリッジインタフェースvirbr0とWebサーバを同じネットワークに属させ、tap0インタフェース経由でWebサーバにアクセスさせる為。

$ sudo ip tuntap add tap0 mode tap
$ sudo ip link set dev tap0 up
$ sudo brctl addif virbr0 tap0


その後、Webサーバへのアクセス確認用として、テキストベースのWebブラウザLynxをインストール。

$ sudo apt-get install lynx
Reading package lists...
Done
libcrypt-dev is already the newest version (1:4.4.10-10ubuntu4).
libcrypt-dev set to manually installed.
The following additional packages will be installed:
  libzarith-ocaml lynx-common
The following NEW packages will be installed:
  libcryptokit-ocaml libssl-ocaml libzarith-ocaml lynx lynx-common
0 upgraded, 5 newly installed, 0 to remove and 23 not upgraded.
Need to get 1,842 kB of archives.
After this operation, 6,744 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y


mirageコマンドが実行出来るよう、eval $(opam env)を実行し環境変数を設定。

$ 
$ eval $(opam env)
$


ちなみに、MirageOSおよびOCamlコンパイラのバージョンは以下のとおり。
前回のHello World完了後から変わらず、MirageOSのバージョンは3.8.0、OCamlコンパイラのバージョンは4.10.0。

$ mirage --version
v3.8.0
$ 
$ opam switch list
#  switch   compiler          description
→  4.10.0   ocaml-base-compiler.4.10.0  4.10.0
   default  ocaml-system.4.08.1 default
$ 


Webサーバ static_website_tlsのインストール
下準備を終えたところで、Webサーバプログラム「static website tls」のコンパイルとインストールに進む。
前回同様、OCamlでWebサーバプログラムを1から書くのではなく、MirageOSの公式githubからホームディレクトリに持ち出す。
clone完了後、lsコマンドを打つとstatic_website_tlsディレクトリが作成されている事が確認出来る。
このstatic_website_tlsディレクトリ配下にディスパッチファイル(dispatch.ml)と構成ファイル(config.ml)が有り、この2つのファイルが保存されているディレクトリ内でインストール作業をする為、cdコマンドで移動する。

$ cd mirage-skeleton/applications/static_website_tls/
$
$ ls
config.ml  dispatch.ml  htdocs  tls
$


自分の環境では、前もってmirage-crypto-rng-mirageをインストールする。
実は、Webサーバの導入は成功するまで何度も何度も失敗。いづれもWebサーバの動作確認の際に、Webブラウザ上でテスト用HTMLファイル(Hello MirageOS World!)を表示させる事が出来なかった。
その際に吐かれたログは以下のとおりだった。

2020-07-26 08:02:11 +00:00: WRN [tcpip-stack-socket] error The default generator is not yet initialized.
To initialize the RNG with a default generator, and set up entropy collection and periodic reseeding as a background task, do the following:
  If you are using MirageOS, use the random device in config.ml: `let main = Mirage.foreign "Unikernel.Main" (random @-> job)`, and `let () = register "my_unikernel" [main $ default_random]`.
  If you are using Lwt, execute `Mirage_crypto_rng_lwt.initialize ()` at the beginning of your event loop (`Lwt_main.run`) execution.
  If you're using neither MirageOS nor lwt, there is no periodic reseeding. For an initial seed from getrandom(), execute `Mirage_crypto_rng_unix.initialize ()`. 
You can use `Mirage_crypto_rng.accumulate` and `Mirage_crypto_rng.reseed` to reseed the RNG manually. in callback


config.mlファイルに`let main = Mirage.foreign "Unikernel.Main" (random @-> job)`と`let () = register "my_unikernel" [main $ default_random]`を書けみたいな事を言っている為、何度もconfig.mlファイルに追記・修正・挙げ句の果てに上記2行だけのconfig.ml作成等をするも、事象に変化無し。
config.mlやdispatch.mlは諦めて、次に怪しいと思っていた箇所 RNG(random number generator)に着手。error The default generator is not yet initialized.と言っている為、RNG関連のパッケージがインストールされていないのであればインストールしてみよう...と言う事で、opam search rngで関係が有りそうなツールの検索とインストールの有無の確認結果、mirage-crypto-rng-mirageがヒットした。
未インストールとの事だった為、opam install mirage-crypto-rng-mirageでインストール。

$ opam install mirage-crypto-rng-mirage
The following actions will be performed:
  ? install eqaf                     0.7   [required by mirage-crypto]
  ? install mtime                    1.2.0 [required by mirage-crypto-rng]
  ? install mirage-crypto            0.8.1 [required by mirage-crypto-rng]
  ? install mirage-crypto-rng        0.8.1 [required by mirage-crypto-rng-mirage]
  ? install mirage-crypto-rng-mirage 0.8.1
===== ? 5 =====
Do you want to continue? [Y/n] Y
:
省略
:
? installed eqaf.0.7
? installed mirage-crypto.0.8.1
? installed mtime.1.2.0
? installed mirage-crypto-rng.0.8.1
? installed mirage-crypto-rng-mirage.0.8.1
Done.
$


mirage-crypto-rng-mirageのインストールは正常完了。ツールの追加インストールは想定外だったが、作業続行。
Virtioオプションを付けてmirage configureコマンドを叩き、コンパイルに必要なファイルを生成。
上記で作成したtup0インタフェースにIPアドレス192.168.122.100/24をアサイン。
GWの192.168.122.1は元から有ったブリッジインタフェースvirbr0にアサインされていたIPアドレス
HTTPおよびHTTPSのポート番号はMirageOSのWebサーバのデフォルト値と同じにつき、ここで指定しなくとも正常に動作すると思われる。

引き続き、make dependコマンドを打ち、依存関係の有るopamツールおよびUbuntuのパッケージを自動でインストール。
Package mirage-unikernel-hello-virtio does not exist, create as a NEW package? [Y/n]
では yキーを叩いてopamツールのインストールを進める。

$  mirage configure -t virtio --ipv4=192.168.122.100/24 --ipv4-gateway=192.168.122.1 --http=8080 --https=4433
$
$ make depend
opam pin add -k path --no-action --yes mirage-unikernel-https-virtio . && opam depext --yes --update mirage-unikernel-https-virtio ; opam pin remove --no-action 

mirage-unikernel-https-virtio
Package mirage-unikernel-https-virtio does not exist, create as a NEW package? [Y/n] y
[mirage-unikernel-https-virtio.~dev] synchronised from file:///home/hechtia/mirage-skeleton/applications/static_website_tls
[WARNING] Failed checks on mirage-unikernel-https-virtio package definition from source at
          file:///home/hechtia/mirage-skeleton/applications/static_website_tls:
  warning 37: Missing field 'dev-repo'
  warning 49: The following URLs don't use version control but look like version control URLs:
              "https://github.com/mirage/mirage-skeleton.git#master"
mirage-unikernel-https-virtio is now pinned to file:///home/hechtia/mirage-skeleton/applications/static_website_tls (version ~dev)
# Detecting depexts using vars: arch=x86_64, os=linux, os-distribution=ubuntu, os-family=debian
:
省略
:
? installed mirage-crypto-pk.0.8.1
? installed x509.0.11.2
? installed tls.0.12.3
? installed tls-mirage.0.12.3
? installed conduit-mirage.2.2.1
? installed cohttp-mirage.2.5.3
Done.
$


最後にmakeコマンドを打ち、Hello Worldのアプリケーションバイナリファイルhttps.virtioを生成。staticファイルも生成される。
仮想マシンのバイナリファイルsolo5-virtio-runは前回のHello Worldの際に生成済みにつき、今回は生成されない。
完了後、lsコマンドの実行でhttps.virtioが当フォルダ内に有る事を確認。

$ make
mirage build
Generating static1.ml
Generating static1.mli
Generating static2.ml
Generating static2.mli
config.exe: [WARNING] pkg-config solo5-bindings-virtio --variable=ld returned nothing, using ld
$
$ ls
_build       dune         dune-project       https.virtio  Makefile                            static1.ml   static2.mli
config.ml    dune.build   htdocs             key_gen.ml    mirage-unikernel-https-virtio.opam  static1.mli  tls
dispatch.ml  dune.config  https_libvirt.xml  main.ml       myocamlbuild.ml                     static2.ml
$


今回のWebサーバ、static website tlsとMirageOSとSolo5の関係を簡単に表現すると、以下の図のような感じ。
当記事で触れている箇所を赤枠で示している。
OSの中にOSが有るのは変に見えるが、本来はXenなどHypervisor上で動作する。
MirageOSとWebサーバプログラムは1対1で動作する。よってDNSサーバプログラムや他のプログラムをMirageOS上で動作させたい場合は、プログラムを動作させる為のMirageOSが1つづつ必要となる。




Webサーバプログラムの実行
Webサーバプログラム、static website tlsの実行まで辿り着いた。Webサーバの起動後、LynxというテキストベースのWebブラウザで動作確認。
仮想マシンバイナリファイルsolo5-virtio-runでアプリケーションバイナリhttp.virtioを実行させる。
Webブラウザ上で「Hello Mirage World!」が表示されれば、Webブラウザプログラムの生成とHTTP/HTTPSアクセスは成功となる。

$ sudo /home/hechtia/.opam/4.10.0/bin/solo5-virtio-run -n tap0 https.virtio
+ exec qemu-system-x86_64 -cpu Westmere -m 128 -nodefaults -no-acpi -display none -serial stdio -device virtio-net,netdev=n0 -netdev 

tap,id=n0,ifname=tap0,script=no,downscript=no -device isa-debug-exit -kernel /home/hechtia/mirage-skeleton/applications/static_website_tls/https.virtio
            |      ___|
  __|  _ /  |  _ / __ /
/__ / (   | | (   |  ) |
____//___/ _|/___/____/
Solo5: Bindings version v0.6.5
Solo5: Memory map: 128 MB addressable:
Solo5:   reserved @ (0x0 - 0xfffff)
Solo5:       text @ (0x100000 - 0x419fff)
Solo5:     rodata @ (0x41a000 - 0x4a5fff)
Solo5:       data @ (0x4a6000 - 0x6d3fff)
Solo5:       heap >= 0x6d4000 < stack < 0x8000000
Solo5: Clock source: TSC, frequency estimate is 2296908200 Hz
Solo5: PCI:00:02: virtio-net device, base=0xc000, irq=10
Solo5: PCI:00:02: configured, mac=52:54:00:12:34:56, features=0x79bfffe7
Solo5: Application acquired 'service' as network device
2020-07-26 08:54:12 -00:00: INF [netif] Plugging into service with mac 52:54:00:12:34:56 mtu 1500
2020-07-26 08:54:12 -00:00: INF [ethernet] Connected Ethernet interface 52:54:00:12:34:56
2020-07-26 08:54:12 -00:00: INF [ARP] Sending gratuitous ARP for 192.168.122.100 (52:54:00:12:34:56)
2020-07-26 08:54:12 -00:00: INF [udp] UDP interface connected on 192.168.122.100
2020-07-26 08:54:12 -00:00: INF [tcpip-stack-direct] stack assembled: mac=52:54:00:12:34:56,ip=192.168.122.100
2020-07-26 08:54:12 -00:00: INF [https] listening on 4433/TCP
2020-07-26 08:54:12 -00:00: INF [http] listening on 8080/TCP


コマンドsudo /home/hechtia/.opam/4.10.0/bin/solo5-virtio-run -n tap0 https.virtioの実行後、Webサーバのログが出力される。
[https] listening on 4433/TCPと[http] listening on 8080/TCPで停止し、リスニングの状態になりWebブラウザからのアクセスを待つ。
出力内容から分かるとおり、このWebサーバではHTTPとHTTPSの両方が立ち上がっているが、外部からのアクセスはHTTPで受け、Webサーバ内部でHTTPSに渡されるという仕組みになっている。

ここでTera Termなどターミナルツールをもう1枚立ち上げMirageOSを立ち上げているVirtualboxゲストOS(ここではUbuntu Linux)にログインし、LynxWebブラウザにアクセスを試みると...

$
$ lynx http://192.168.122.100:8080

下の画像内に表示されているとおり、「Hello MirageOS World!」の表示に成功。
ここに辿り着くまで、長かった......



WebブラウザLynxでアクセスした際のログは、以下のとおり。
HTTPからHTTPSに渡される様子とSSLハンドシェイクの簡易なログが出力されている。

2020-07-26 08:54:34 -00:00: INF [https] [1] serving //192.168.122.100:8080/.
2020-07-26 08:54:34 -00:00: INF [http] [//192.168.122.100:8080/] -> [https://192.168.122.100:4433/]
2020-07-26 08:54:34 -00:00: INF [https] [1] closing
2020-07-26 08:54:36 -00:00: INF [handshake] cipher AES_128_GCM_SHA256
2020-07-26 08:54:36 -00:00: INF [handshake] group X25519
2020-07-26 08:54:47 -00:00: INF [https] [2] serving //192.168.122.100:4433/.
2020-07-26 08:54:47 -00:00: INF [https] [2] closing


今回の振り返り。VirtualboxのゲストOS内の話ではあるが、Tutorial用プログラムのWebサーバ「static_website_tls」の実行と、HTTP/HTTPSアクセスおよびWebブラウザLynxでHello MirageOS World!の表示に成功した。
外部からのアクセスも可能のようだが、その際は自己証明書ではなく信頼出来る認証局サーバ証明書が必要となる。
海外のブログにLet's Encryptでの事例が有り(https://www.davidudelson.com/blog/2017/06/13/aws-unikernel-guide/)、自分も試してみたものの今のところ成功していない。



リンク先
https://mirage.io/ Mirage OS
https://github.com/mirage Mirage OS (github)
https://ocaml.org/ OCaml
https://releases.ubuntu.com/20.04/ Ubuntu 20.04
https://github.com/Solo5/solo5 Solo5
https://lynx.invisible-island.net/lynx.html Lynx


MirageOCaml、他各ツールの最新バージョンは以下のリンク先で検索し確認可能。
画面右上の「Search Packages」の窓内にパッケージ名を入力し検索。
https://opam.ocaml.org/packages/


他のMirageOSのエントリ
https://debslink.hatenadiary.jp/entry/20200815/1597493701 追記:MirageOS Unikernelでデータベース
https://debslink.hatenadiary.jp/entry/20200718/1595076105 前回:Ubuntu 20.04でMirageOS Unikernel
https://debslink.hatenadiary.jp/entry/20200526/1590495778 前々回:MirageOS Unikernelで通信プログラムの実行
https://debslink.hatenadiary.jp/entry/20200516/1589616362 初回:MirageOSのインストールとHello Worldの実行


自分にとって、UnikernelsやMirageOSの始めの一歩となったサイト (MirageOS のインストールから Hello World までを試す)
https://qiita.com/t-imada/items/6ee299653ac063532b4f