| | 本章では、ここまでの内容で紹介しきれなかった、より細かな Armadillo の設定方法や、開発に役立つヒントなどを紹介します。 各トピックを羅列していますので、目次の節タイトルからやりたいことを探して辞書的にご使用ください。 初期状態では「root」ユーザーと、一般ユーザーである「atmark」ユーザーが存在しますが、「atmark」ユーザーは初期状態ではロックされています。
ロックを解除するためには、「atmark」ユーザーのパスワードを設定した initial_setup.swu をインストールするか、CUIからパスワードを直接設定します。 CUIからパスワードを直接設定する手順では、以下のように一度「root」ユーザーでログインしてから passwd atmark コマンドで「atmark」ユーザーのパスワードを設定します。 armadillo:~# passwd atmark 
New password: 
Retype new password: 
passwd: password updated successfully
armadillo:~# persist_file /etc/shadow 
armadillo:~# exit
: (省略)
armadillo login: atmark
Password: 
Welcome to Alpine! |
atmarkユーザーのパスワード変更コマンドです。
| |
新しいパスワードを入力します。設定するパスワードには大文字のアルファベット、小文字のアルファベット、0から9までの数字、その他(記号・句読点など)を含める事ができます。
| |
新しいパスワードを再入力します。
| |
パスワードファイルを永続化します。
| |
設定したパスワードでログインすることができます。
|
10.2. swupdateを使用してアップデートする10.2.1. swupdate で可能なアップデートswupdate を実行する目的としては以下が考えられます。
コンテナをアップデートしたい
開発したコンテナのアップデートが可能です。
ユーザーデータディレクトリや Armadillo Base OS のファイルを差分アップデートしたい
ユーザーデータをアップデートする場合は、以下のディレクトリを更新します。 -
/var/app/rollback/volumes
ユーザーディレクトリについては「電源を切っても保持されるディレクトリ(ユーザーデータディレクトリ)」を参照してください。 ![[警告]](images/warning.png) | |
|---|
SWUpdate による /var/app/volumes の更新は推奨しません。 /var/app/volumes が二面化されていないため、書込みの途中で問題が発生した場合、
不完全な書込みになる恐れがあります。
また、アップデート中にアプリケーションがそのデータに
アクセスすると、書込み中のデータにアクセスすることになります。 /var/app/volumes のデータに対して更新が必要な場合、SWUpdate では /var/app/rollback/volumes に更新するデータを書き込んでください。
その後、次回起動時にアプリケーション側から /var/app/rollback/volumes に書き込んだデータを /var/app/volumes に移動するようにしてください。
|
Armadillo Base OS を一括アップデートしたい
アットマークテクノがリリースする Armadillo Base OS の機能追加、更新、セキュリティパッチの追加が可能です。
ブートローダーをアップデートしたい
アットマークテクノがリリースするブートローダーのアップデートが可能です。
「Armadillo Base OSとは」で示すように、Armadillo Base OS は OS・ブートローダー・コンテナ部分の安全性を担保するため二面化しています。 それにより、万が一アップデートに失敗した場合でも起動中のシステムに影響ありません。 以降、それぞれの目的ごとに swupdate によるアップデートの流れを示します。 10.2.2. コンテナのアップデート、ユーザーデータディレクトリや Armadillo Base OS の差分アップデート以下にアップデートの流れを示します。 ここでは、boot して起動中の面を A 面、アップデート先の面を B 面とします。
Armadillo Base OS を B 面へコピー
Armadillo Base OS を B 面にコピーする流れを図10.1「Armadillo Base OS を B 面にコピー」に示します。 A 面と B 面の Armadillo Base OS が同期しているか確認します。 同期していない場合、 A 面の Armadillo Base OS を B 面にコピーします。 同期している場合はコピーしません。 swdesc_option version で指定するバージョンの書き方については「インストールバージョンを指定する」を参照してください。
コマンドを順番に実行
図10.2「desc ファイルに記述したswudesc_* コマンドを実行」に示すように、desc ファイルに記述した順番に従って swudesc_* コマンドを実行します。 「インストールバージョンを指定する」に示すように、swdesc_* コマンドによって Armadillo Base OS に対して書き込みをする場合は --extra-os オプションをつけてください。
swudesc_* コマンドの種類を表10.1「swudesc_* コマンドの種類」に示します。 表10.1 swudesc_* コマンドの種類 | おおまかな機能 | コマンド名 | 説明 |
|---|
ファイル転送
参照先：「Armadillo へファイルを転送する」 | swdesc_files | 指定したファイルをアップデート先の環境にコピー | swdesc_tar | 指定した tar アーカイブをアップデート先の環境に展開してコピー | コマンド実行
参照先：「Armadillo 上で任意のコマンドを実行する」 | swdesc_command | 指定したコマンドをアップデート先の環境で実行 | swdesc_script | 指定したスクリプトをアップデート先の環境で実行 | ファイル転送 + コマンド実行
参照先：「Armadillo にファイルを転送し、そのファイルをコマンド内で使用する」 | swdesc_exec | 指定したファイルをアップデート先の環境にコピーした後、そのファイル名を"$1"としてコマンドを実行 | 起動中の面に対してコマンド実行（非推奨）
参照先：「動作中の環境でのコマンドの実行」 | swdesc_command_nochroot | 指定したコマンドを起動中の環境で実行 | swdesc_script_nochroot | 指定したスクリプトを起動中の環境で実行 | 起動中の面に対してファイル転送 + コマンド実行（非推奨）
参照先：「動作中の環境でのコマンドの実行」 | swdesc_exec_nochroot | 指定したファイルを起動中の環境にコピーした後、そのファイル名を"$1"としてコマンドを実行 | コンテナイメージの転送
参照先：「Armadillo にコンテナイメージを転送する」 | swdesc_embed_container | SWU ファイルに含まれるコンテナイメージの tar アーカイブをアップデート先の環境に展開 | swdesc_pull_container | アップデート先の環境でコンテナイメージをダウンロード | swdesc_usb_container | SWU ファイルに含めない形で用意したコンテナイメージの tar アーカイブをアップデート先の環境に展開 |
アップデート完了後の挙動
デフォルトではアップデート後に再起動（ POST_ACTION=reboot ）が行われます。
アップデート後の挙動を変更するには desc ファイルに swdesc_option POST_ACTION を追加してください。 swdesc_option POST_ACTION に指定できる挙動の種類を表10.2「アップデート完了後の挙動の種類」に示します。
表10.2 アップデート完了後の挙動の種類 | オプション名 | 説明 |
|---|
container | アップデート後にコンテナのみを再起動
（ただし、アップデート時に --extra_os オプションを指定したコマンドが実行された場合は reboot になる） | poweroff | アップデート後にシャットダウン | reboot | アップデートの後に再起動 | wait | アップデート後に再起動は行われず、次回起動時に B 面に切り替わる |
swdesc_option POST_ACTION の詳細は「SWUpdate 実行中/完了後の挙動を指定する」を参照してください。
B 面への切り替え
図10.4「B 面への切り替え」に示すように、正常にアップデートが行われると、次回起動時に B 面に切り替わります。
desc ファイルの書き方の例
下記に SWUpdate を用いたアップデートの例を示します。
10.2.3. Armadillo Base OS の一括アップデートアップデートの流れを示します。 ここでは、boot して起動中の面を A 面、アップデート先の面を B 面とします。 swdesc_* コマンドには、swdesc_boot を指定してください。 swdesc_boot については「Armadillo のブートローダーを更新する」を参照してください。 ブートローダーのアップデートの流れは以下の通りです。
desc ファイルに swdesc_boot がある場合
SWU ファイルに含まれるブートローダーを B 面に書き込む
desc ファイルに swdesc_boot がない場合
A 面のブートローダーを B 面にコピーする
下記に SWUpdate を用いたアップデートの例を示します。 10.2.5. swupdate がエラーする場合の対処SWU イメージのインストール動作は、「SWU イメージとは」で述べたように swupdate が実行します。
mkswu で作成した SWU イメージの内容が適切でなかったり、あるいは、ストレージの空き容量が不足していたりするなど、いくつかの理由で swupdate のインストール動作が失敗することがあります。
インストールに失敗すると、swupdate は /var/log/messages にエラーメッセージのログを残しますので、エラーメッセージを見ると、エラーの内容・原因が分かります。 エラーの原因ごとに、エラーメッセージとエラーの内容および対処方法を記した FAQ ページ (https://armadillo.atmark-techno.com/faq/swupdate-troubleshooting-abos) を公開しています。
SWU イメージのインストールに失敗して対処法が分からないときは、この FAQ ページをご覧ください。 10.3. mkswu の .desc ファイルを編集するmkswu で SWU イメージを生成するためには、 desc ファイルを正しく作成する必要があります。
以下では、 desc ファイルの記法について紹介します。 swdesc_option component=<component>
swdesc_option version=<version>
か
swdesc_xxx --version <component> <version> [options]
<component>は以下のどれかにしてください (デフォルトでは .desc ファイルのファイル名を使います）
base_os: rootfs (Armadillo Base OS)を最初から書き込む時に使います。現在のファイルシステムは保存されないです。
この場合、/etc/swupdate_preserve_filesに載ってるファイルのみをコピーして新しいbase OSを展開します。 このcomponentがないと現在のrootfsのすべてがコピーされます。 swdesc_tar コマンドで rootfs (Armadillo Base OS) の tar アーカイブを展開する時に、--base-os オプションをつけることで component に base_os を指定したときと同じ動作となります。
extra_os.<文字列>: rootfsの変更を行う時に使います。<文字列> には任意の文字列を指定します。
rootfsを変更を行う時に使います。 swdesc_* コマンドに --extra-os オプションを追加すると、 component に自動的に extra_os. を足します。
<文字列> (コンテナの名前などの任意の文字列）: rootfsの変更がないときに使います。
このcomponentを使うとrootfsの変更ができませんのでご注意ください。
アップデートを行う際にこのバージョンと現在のバージョンを比べてアップデートの判断を行います。
<component> がまだインストールされてなかった時や <version> が上がる時にインストールします。 デフォルトではダウングレードはできませんが、 --install-if=different オプションを追加することで <version> が変わる際にインストール可能になります。 アップデートの一部をインストールすることもありますので、複数の component で管理し、いくつかの古いバージョンに対応するアップデートも作成可能です。
バージョンの指定方法
swdesc_option version で指定可能なバージョンのフォーマットは以下の 2 種類があります。
x[.y[.z[-t]]]
x, y, z にはそれぞれ 0 ～ 2147483647 の整数を適用してください。
t には任意のアルファベットまたは 0 ～ 147483647 の整数を適用してください。 成功例は以下です： -
1
-
1.2.3
-
1.2.3-4
-
1.2.3-abc.4
-
1.2.3-a.b.c.4
失敗例は以下です：
2147483648
x には 0 ～ 2147483647 の整数を適用してください。
1.2.3-a.2147483648
t には 0 ～ 2147483647 の整数を適用してください。
1.2.3-abc123
t には 数字とアルファベットを混在しないでください。
1.2.3-abc.123 ならば可能です。
a.2.3
x にはアルファベットではなく 0 ～ 2147483647 の整数を適用してください。
1.1.1.1-a
x[.y[.z[-t]]]の形式で書いてください。
x.y.z.t
x, y, z, t にはそれぞれ 0 ～ 65535 の整数を適用してください。 成功例は以下です： -
1.2.3.4
-
65535.65535.65535.65535
-
65535.2.3.4
| |
|---|
アットマークテクノがリリースするファームウェアはバージョンのサフィックスとして"-at.[数字]"を含めています。
オリジナルのサフィックスをつける場合は、"-at.[数字]"を使用しないことを強く推奨します。 |
失敗例は以下です：
10.3.2. Armadillo へファイルを転送する
swdesc_tar と swdesc_files でファイルを転送します。
swdesc_tar [--dest <dest>] [--preserve-attributes] <tar_file>
swdesc_files [--dest <dest>] [--basedir <basedir>] [--preserve-attributes] \
<file> [<more files>]swdesc_tar の場合、予め用意されてあるtarアーカイブをこのままデバイスで展開します。
--dest <dest> で展開先を選ぶことができます。デフォルトは / （--extra-os を含め、バージョンの component は base_os か extra_os.* の場合）か /var/app/rollback/volumes/ （それ以外のcomponent）。
後者の場合は /var/app/volumes と /var/app/rollback/volumes 以外は書けないので必要な場合に --extra-os を使ってください。
--preserve-attributes を指定しない場合はファイルのオーナー、モード、タイムスタンプ等が保存されませんので、必要な場合は設定してください。バージョンが base_os の場合は自動的に設定されます。
swdesc_files の場合、mkswu がアーカイブを作ってくれますが同じ仕組みです。
--basedir <basedir> でアーカイブ内のパスをどこで切るかを決めます。
-
例えば、
swdesc_files --extra-os --basedir /dir /dir/subdir/file ではデバイスに /subdir/file を作成します。
-
デフォルトは <file> から設定されます。ディレクトリであればそのまま basedir として使います。それ以外であれば親ディレクトリを使います。
10.3.3. Armadillo 上で任意のコマンドを実行する
swdesc_command や swdesc_script でコマンドを実行します。
swdesc_command <command> [<more commands>]
swdesc_script <script> アップデート先の環境でコマンドやスクリプトファイルを実行します。 バージョンの component は base_os と extra_os 以外の場合、 /var/app/volumes と /var/app/rollback/volumes 以外は変更できないのでご注意ください。 コマンドの実行が失敗した場合、アップデートも失敗します。
10.3.4. Armadillo にファイルを転送し、そのファイルをコマンド内で使用する
swdesc_exec でファイルを配り、コマンド内でそのファイルを使用します。
swdesc_exec <file> <command> swdesc_command と同じくコマンドを実行しますが、<file> を先に転送してコマンド内で転送したファイル名を"$1"として使えます。
| |
|---|
本節で紹介する swdesc_command_nochroot、swdesc_script_nochroot、swdesc_exec_nochroot は基本的に使用することはありません。 swdesc_command、swdesc_script、swdesc_exec をご使用ください。
|
swdesc_command_nochroot, swdesc_script_nochroot, swdesc_exec_nochroot は アップデート先の環境ではなく動作中の環境でコマンドを実行します。
使い方は「Armadillo へファイルを転送する」と「Armadillo にファイルを転送し、そのファイルをコマンド内で使用する」に示した nochroot なしのバージョンと同じです。 アップデート先の環境は /target にマウントされるので、nochroot のコマンドを用いてアップデート先の環境に対してアクセスすることは可能です。 しかし、その方法によるアップデート先の環境に対するコマンドの実行は nochroot なしのコマンドでは実現できない特殊な場合にのみ行ってください。 | |
|---|
nochroot コマンドは確認を一切しないため、Armadillo が起動できない状態になる可能性もあります。充分にご注意ください。
例が必要な場合は /usr/share/mkswu/examples/firmware_update.desc を参考にしてください。 |
10.3.6. Armadillo にコンテナイメージを転送する
swdesc_embed_container, swdesc_usb_container, swdesc_pull_container で予め作成したコンテナを転送します。
swdesc_embed_container <container_archive>
swdesc_usb_container <container_archive>
swdesc_pull_container <container_url> 例は「リモートリポジトリにコンテナを送信する」、「コンテナイメージを SWUpdate で転送する」を参考にしてください。
10.3.7. Armadillo のブートローダーを更新するコマンドの他には、設定変数もあります。以下の設定は /home/atmark/mkswu/mkswu.conf に設定できます。 -
DESCRIPTION="<text>": イメージの説明、ログに残ります。
-
PRIVKEY=<path>, PUBKEY=<path>: 署名鍵と証明書
PRIVKEY_PASS=<val>: 鍵のパスワード（自動用）
openssl のPass Phraseをそのまま使いますので、pass:password, env:var や file:pathname のどれかを使えます。
pass や env の場合他のプロセスに見られる恐れがありますのでfileをおすすめします。
-
ENCRYPT_KEYFILE=<path>: 暗号化の鍵
10.3.9. Armadillo 上のコンテナイメージと自動起動用confファイルを削除する以下のオプションも mkswu.conf に設定できますが、.descファイルにも設定可能です。swdesc_option で指定することで、
誤った使い方をした場合 mkswu の段階でエラーを出力しますので、必要な場合は使用してください。 10.3.10. SWUpdate 実行中/完了後の挙動を指定する以下のオプションは Armadillo 上の /etc/atmark/baseos.conf に、例えば MKSWU_POST_ACTION=xxx として設定することができます。 その場合に swu に設定されなければ /etc の設定で実行されますので、
アットマークテクノが用意している Base OS のアップデートでも動作の変更は可能です。
swu に特定のオプションが設定された場合は設定されたオプションが優先されますので、一時的な変更も可能です。 -
swdesc_option POST_ACTION=container: コンテナのみのアップデート後に再起動を行いません。
コンテナの中身だけをアップデートする場合、Armadillo-900 開発セットを再起動せずにコンテナだけを再起動させます。
-
swdesc_option POST_ACTION=poweroff: アップデート後にシャットダウンを行います。
-
swdesc_option POST_ACTION=wait: アップデート後に自動的に再起動は行われず、次回起動時にアップデートが適用されます。
-
swdesc_option POST_ACTION=reboot: デフォルトの状態に戻します。アップデートの後に再起動します。
swdesc_option NOTIFY_STARTING_CMD="command", swdesc_option NOTIFY_SUCCESS_CMD="command", swdesc_option NOTIFY_FAIL_CMD="command": アップデートをインストール中、成功した場合と失敗した場合に実行されるコマンドです。
コマンドを実行する事で、アプリケーションやユーザーにアップデートを知らせることができます。 LEDで知らせる例を /usr/share/mkswu/examples/enable_notify_led.desc に用意してあります。
/usr/share/mkswu/examples/enable_sshd.desc を参考にします。
descファイルを編集する必要がありませんが自分の公開鍵を指定された場所に配置してください。 [ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/enable_sshd* .
[ATDE ~/mkswu]$ cat enable_sshd.desc
swdesc_option component=extra_os.sshd version=1
# add your public key in enable_sshd/root/.ssh/authorized_keys
if [ -z "$SWDESC_TEST" ]; then
grep -qE '^ssh-' enable_sshd/root/.ssh/authorized_keys \
|| error "Add your keys in enable_sshd/root/.ssh/authorized_keys"
fi
swdesc_files --dest /root enable_sshd/root
swdesc_command "ssh-keygen -A" \
"rc-update add sshd"
[ATDE ~/mkswu]$ cp ~/.ssh/id_rsa.pub \
enable_sshd/root/.ssh/authorized_keys
[ATDE ~/mkswu]$ mkswu enable_sshd.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
enable_sshd.swu を作成しました。 |
自分の公開鍵を転送します。デフォルトのオプションなので enable_sshd/root ディレクトリの中身をこのまま /root に転送されます。
| |
再起動する度に新しいサーバーの鍵が変わらないように、アップデートの時に一回作成します。
| |
サービスを有効にします。
| |
自分の公開鍵を指定された場所に配置します。
| |
イメージを作成します。パスワードは証明鍵のパスワードです。
|
10.3.11.2. 例: Armadillo Base OSアップデートここでは、「Armadilloのソフトウェアをビルドする」でメインシステム向けのビルドで作成したファイルを使用します。 /usr/share/mkswu/examples/OS_update.desc を参考にします。
[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/OS_update.desc update-[VERSION].desc
[ATDE ~/mkswu]$ vi update-[VERSION].desc
# uboot image can be generated with atmark imx-boot script
swdesc_uboot imx-boot_armadillo_x2
# base OS is a tar that will be extracted on a blank filesystem,
# after copying just a few key config files.
#
# OS updates are only installed if version is greater than previous update
# so if you install your own updates atmark-techno provided Armadillo Base OS
# updates might not get installed
swdesc_tar "baseos-x2-[VERSION].tar.zst" \
--version base_os [VERSION]
[ATDE ~/mkswu]$ mkswu update-[VERSION].desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
update-[VERSION].swu を作成しました。 |
imx-bootでビルドしたイメージを使います。
| |
build-rootfsでビルドしたイメージを使います。
| |
バージョンが上がるときにしかインストールされませんので、現在の/etc/sw-versionsを確認して適切に設定してください。
| |
イメージを作成します。パスワードは証明鍵の時のパスワードです。
|
10.3.11.3. 例: swupdate_preserve_files で Linux カーネル以外の Armadillo-900 開発セット 向けのイメージをインストールする方法Armadillo-900 開発セット 向けのアップデートイメージに Linux カーネルが含まれています。 swupdate_preserve_files を使って、以下のコマンドでインストール後に現在のカーネルをコピーして更新させないようにします。
[armadillo ~]# echo 'POST /boot' >> /etc/swupdate_preserve_files
[armadillo ~]# echo 'POST /lib/modules' >> /etc/swupdate_preserve_files
[armadillo ~]# persist_file /etc/swupdate_preserve_files |
swupdate_preserve_files に /boot と /lib/modules を保存するように追加します。
| |
変更した設定ファイルを保存します
|
![[ティップ]](images/tip.png) | |
|---|
/usr/share/mkswu/examples/kernel_update*.desc のように update_preserve_files.sh のヘルパーで、パスを自動的に /etc/swupdate_preserve_files に追加することができます。
[ATDE ~/mkswu]$ cat example.desc
swdesc_script "$SCRIPT_DIR/examples/update_preserve_files.sh" -- \
"POST /boot" \
"POST /lib/modules" |
スクリプトの内容確認する場合は /usr/share/mkswu/examples/update_preserve_files.sh を参照してください。
|
|
| |
|---|
Armadillo Base OS のカーネルを再び使用したい場合は同じスクリプトの --del オプションで行を削除することができます。 [ATDE ~/mkswu]$ cat example.desc
swdesc_script "$SCRIPT_DIR/examples/update_preserve_files.sh" -- \
--del "POST /boot" "POST /lib/modules" |
10.4. swupdate_preserve_files についてextra_os のアップデートで rootfs にファイルを配置することができますが、次の OS アップデートの際に削除される可能性があります。
デフォルトでは、 /etc/atmark と、 swupdate 、 sshd やネットワークの設定を保存しますがそれ以外はコピーされてません。 そうでないファイルを更新する際には /etc/swupdate_preserve_files に記載します。「例: swupdate_preserve_files で Linux カーネル以外の Armadillo-900 開発セット 向けのイメージをインストールする方法」 を参考にしてください。 コピーのタイミングによって、以下のどれかを使用してください：
単にファイルを記載する
この場合、アップデートする前にファイルをコピーします。 baseos のイメージと同じ swu にアップデートしたいファイルを記載していても、
このファイルが Armadillo Base OS に含まれないのであれば問題なくアップデートできます。 例: echo "/root/.profile" >> /etc/swupdate_preserve_files
POST のキーワードの後に記載する
この場合、アップデートの最後でコピーします。 Armadillo Base OS に含まれてるファイルであれば、インストール前にコピーしても保存されないのでコピーのタイミングをずらします。 そのコピーが最後に行われるので、同じアップデートでファイルの変更ができません。アップデートを別けて、 baseos のイメージをインストールしてからこのファイルを更新することができます。 例: echo "POST /etc/conf.d/podman-atmark" >> /etc/swupdate_preserve_files
mkswu --show [file.swu] で SWU イメージの内容を確認することができます。
出力は desc ファイルに似ていますが、そのまま desc ファイルとして利用できませんので確認用としてお使いください。 [ATDE ~/mkswu]$ mkswu --show enable_sshd.swu
enable_sshd.swu
# built with mkswu 4.1
swdesc_files --dest /root enable_sshd/root
--version extra_os.sshd 1
(encrypted)
swdesc_command ssh-keygen -A && rc-update add sshd default
--version extra_os.sshd 1 mkswu --init の時に暗号化を有効にする場合は AES でファイルを暗号化します。
現在使われてる SWUpdate の暗号化はコマンドやメタデータを含む sw-description ファイルは暗号化されてません。
そのため、通信の暗号化（HTTPSで送信するなど）を使うことを推奨します。 10.7. SWUpdate の署名鍵と証明書の更新mkswu で SWU イメージを生成する際に SWU イメージ内の sw-description という命令ファイルを ATDE にある署名鍵と証明書を用いて署名します。
swupdate を実行する際には、署名に使用した証明書が /etc/swupdate.pem に含まれているかを確認します。
その署名を確認できなかった場合、SWU イメージをインストールできないので、Armadillo にある証明書を管理しなければなりません。 また、暗号鍵管理のガイドラインとしては定期的に鍵を交換することが強く推奨されています。
mkswu --init を実行した際に１つだけ署名鍵と証明書を生成しましたが、ここでは他の署名鍵および証明書の生成と Armadillo 側の管理の方法について説明します。 署名鍵と証明書の生成は以下の様に、 mkswu --genkey で行います。 |
Enterキーを押下します。
| |
[COMMON_NAME] には会社や製品が分かる任意の名称を入力してください。任意ではありますが、一つ目の鍵と違う名前にすることを推奨します。
| |
署名鍵を保護するパスフレーズを2回入力します。
|
このコマンドを実行すると以下の文字列が ~/mkswu/mkswu.conf に追加されます。 |
PUBKEY の値に生成した証明書のパスが追加されます。
UPDATE_CERTS=yes を設定して生成した SWU イメージは、PUBKEY の値にリストされている証明書を全て Armadillo にインストールします。
PUBKEY にリストされてない証明書、またはアットマークテクノ側で管理している証明書以外は全て削除されます。
| |
新しい署名鍵のパスです。この段階では未使用になります。
|
この状態で任意 (POST_ACTION=container以外) の SWU イメージを生成し、インストールすると Armadillo の /etc/swupdate.pem に PUBKEY にリストされている両方の証明書がインストールされます。
Armadillo にインストールされている鍵は、abos-ctrl certificates list で確認できます： |
追加した証明書のコモンネーム
| |
mkswu --init 時に生成した証明証のコモンネーム。当時の mkswu のバージョンによっては swupdate.pem が記載されてない可能性があります。
|
この状態で新しい鍵を使えるようになります。 上記のように Armadillo に複数の署名鍵を使用できる状態になった場合は証明に使う署名鍵と証明書を切り替えることができます。 mkswu.conf の PUBKEY の値から一つ目の値を削除し、 PRIVKEY に新しい値を設定し、必要であれば UPDATE_CERTS=yes を記述します。
署名鍵の追加と同じく、この状態で SWU イメージを生成し Armadillo にインストールすると前の証明書が削除されます。 こちらも abos-ctrl certificates list コマンドで確認可能です。 ここでは、Podman やコンテナのより応用的な使用方法について説明します。 10.8.1.1. ユーザーデータディレクトリを使用するpodman_start の add_volumes コマンドでコンテナに Armadillo Base OS のディレクトリをコンテナで使うことができます。
保存するデータの性質によって、保存先を選択してください。 -
/var/app/volumes/myvolume: アップデートした場合はコピーされません。
ログやデータベースなど、アプリケーションが作成し続けるようなデータの保存に向いています。
-
myvolume か /var/app/rollback/volumes/myvolume: アップデートの際にコピーしてアップデートを行うので、アップデート中でも安全に使いつづけます。
アプリケーションと一緒にアップデートするようなデータの保存に向いています。
10.8.1.2. コンテナイメージをアーカイブにするpodman save コマンドで、コンテナイメージを .tar 形式で保存することができます。
作成した .tar アーカイブは 「mkswu の .desc ファイルを編集する」 の swdesc_embed_container と swdesc_usb_container で使えます。
10.8.1.3. コンテナイメージをアップデートするイメージを前のバージョンからアップデートします。 +
この場合、 podman_partial_image コマンドを使って、差分だけをインストールすることもできます。 + [armadillo ~/podman-build-update]# podman_partial_image -b my_image:1 \
-o my_image_2_partial.tar my_image:2
[armadillo ~/podman-build-update]# ls -lh
-rw-r--r-- 1 root root 88 Dec 21 15:24 Dockerfile
-rw-r--r-- 1 root root 9.4M Dec 21 15:26 my_image_1.tar
-rw-r--r-- 1 root root 9.4M Dec 21 15:26 my_image_2.tar
-rw-r--r-- 1 root root 51K Dec 21 15:26 my_image_2_partial.tar10.8.1.4. コンテナイメージを eMMC に保存するここまでで、コンテナイメージのダウンロード・作成（ podman pull, podman build ）とコンフィグファイルの作成を行いました。
ですが、 podman pull や podman build で用意したコンテナイメージや、作成・変更したコンフィグファイルはデフォルト状態ではメモリ上にしか保存されません。これは、Armadillo Base OS の仕様により Podman のデータは tmpfs に保存されるためです。 そのため、このまま Armadillo を終了すると、これらのデータは消えてしまいます。
Armadillo を終了してもデータが消えないようにするためには、
ファイルは persist_file で保存し、コンテナイメージは abos-ctrl podman-storage --disk で podman のストレージを eMMC に切り替えるか abos-ctrl podman-rw で一時的に eMMC に保存します。 また、起動時にコンテナを起動する場合にもイメージを eMMC に書き込む必要があります。 開発が終わって運用の場合は 「コンテナイメージを SWUpdate で転送する」 でコンテナのイメージを転送します。この場合は読み取り専用の app パーティションのサブボリュームに展開します。
運用中の Armadillo には直接に変更をせず、 SWUpdate でアップデートしてください。 abos-ctrl podman-rw を使えば、read-only になっているイメージを扱う事ができます。
abos-ctrl podman-storage はメモリとディスクの切り替えの他に、読み書きストレージから読み取り専用ストレージへのコピーもできます。
|
イメージを書き込み可能ストレージに取得します。
| |
abos-ctrl podman-storage をオプション無しで実行します。
| |
書き込み可能ストレージにイメージがある場合に対応を聞かれます。今回はコピー（copy）します。
| |
abos-ctrl podman-storage にオプションを指定しなかったので、ストレージが tmpfs のままになります。すでに --disk で切り替えた場合にディスクのままでも可能です。
| |
コピーされたイメージを確認します。イメージが読み取り専用（R/O, Read only）になりました。
|
| |
|---|
podman が壊れやすいので、デフォルトの「abos-ctrl podman-storage --tmpfs」で運用することを推奨しますが、tmpfs の容量が小さくてイメージの操作には向いてません。 開発時には「abos-ctrl podman-storage --disk」の状態で作業を行い、運用時には「abos-ctrl podman-storage --tmpfs」に戻してください。
戻る際に「copy」を選択する場合は一時的なストレージをそのまま使いつづけますので、すべての変更が残ります。 |
| |
|---|
SWUpdate でアップデートをインストールする際には、/var/lib/containers/storage_readonly ディレクトリの不要になったイメージを自動的に削除します。 自動起動させる予定がなくても、「コンテナ起動設定ファイルを作成する」 を参考にして、 /etc/atmark/containers/*.conf を使ってください。 set_autostart no を設定することで自動実行されません。 |
複数のコンテナを実行している環境で、それらのコンテナ間で通信を行う方法を示します。
これにより、例えば SQL サーバを実行しているコンテナに対し別のコンテナから接続するといった
使い方ができます。 コンテナには作成した時点でローカル IP アドレスが割り当てられるので、コンテナの名前かその IP アドレスで通信を行うことができます。 準備として、2 つのコンテナを作成します。 コンテナに割り当てられた IP アドレスを確認するには podman inspect コマンドを実行します。 これらの IP アドレスを使って、一方のコンテナからもう一方のコンテナへ対し ping コマンドで疎通確認を行うことができます。 このように、my_container_1(10.88.0.108) から my_container_2(10.88.0.109) への通信が確認できます。 10.8.1.6. podでコンテナのネットワークネームスペースを共有するpodman_start で pod 機能を使うことができます。
pod を使うことで、複数のコンテナが同じネットワークネームスペースを共有することができます。
同じ pod の中のコンテナが IP の場合 localhost で、 unix socket の場合 abstract path で相互に接続することができます。
コンテナと同じく、 /etc/atmark/containers/[NAME].conf ファイルを作って、 set_type pod を設定することで pod を作成します。 pod を使う時にコンテナの設定ファイルに set_pod [NAME] の設定を追加します。 ネットワークネームスペースは pod を作成するときに必要なため、 ports, network と ip の設定は pod
のコンフィグファイルに入れなければなりません。 必要であれば、他の podman pod create のオプションを add_args で設定することができます。 .conf ファイルで使用できる各種パラメータについては、「コンテナ起動設定ファイルを作成する」を参照してください。
podman_start で podman の network も作成できます。
デフォルトの 10.88.0.0/16 が使えない場合、あるいはコンテナ同士で接続できないようにしたい場合は使ってください。 コンテナと同じく、 /etc/atmark/containers/[NAME].conf ファイルを作って、 set_type network を設定することで network を作成します。 そのネットワークを使う時にコンテナの設定ファイルに set_network [NAME] の設定をいれます。 ネットワークのサブネットは set_subnet [SUBNET] で設定します。
この設定は set_type network の後しか使えませんので、set_type はファイルの最初のところに使ってください 他の podman network create のオプションが必要であれば、 add_args で設定することができます。 .conf ファイルで使用できる各種パラメータについては、「コンテナ起動設定ファイルを作成する」を参照してください。
podman では REST API による管理アクセスも可能です。 自分のコンテナから他のコンテナの管理が必要な場合に、ホストの podman サービスを有効にして、
コンテナに /run/podman をボリュームマウントすれば podman --remote で管理できます。 | |
|---|
コンテナの設定によって podman の socket へのパスが自動設定されない場合もあります。
podman --remote でエラーが発生した場合に CONTAINER_HOST=unix:/path/to/podman.sock で
socket へのパスを設定してください。 |
Armadillo のホスト側の udev rules からコンテナを起動する場合は podman_start 等を直接実行すると
udev の子プロセス管理によってコンテナが停止されますので、その場合はサービスを有効にし、
podman_start --create <container> コマンドまたは set_autostart create の設定でコンテナを生成した上
podman --remote start <container> で起動してください。 10.8.1.9. リモートリポジトリにコンテナを送信する
イメージをリモートリポジトリに送信する：
[armadillo ~]$ podman image push <localimage> docker://<registry>/<remoteimage>:<tag>
set_pull always を設定しないかぎり、SWUpdateでダウンロードの命令を送らないとアップデートを行いません。
（mkswuについては「Armadillo のソフトウェアをアップデートする」を参考にしてください） [ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/pull_container_nginx.desc .
[ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start .
[ATDE ~/mkswu]$ cat pull_container_nginx.desc
swdesc_option version=1
swdesc_pull_container "docker.io/nginx:alpine"
swdesc_files --extra-os nginx_start
[ATDE ~/mkswu]$ mkswu pull_container_nginx.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
pull_container_nginx.swu を作成しました。
10.8.1.10. コンテナイメージを SWUpdate で転送する
イメージをファイルに保存する：
[armadillo ~]$ podman image save -o <myimage>.tar <localimage>
ファイルをSWUpdateのイメージに入れる。
二つのやり方があります：
SWUイメージ内に組み込む
[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/embed_container_nginx.desc .
[ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start .
[ATDE ~/mkswu]$ cat embed_container_nginx.desc
swdesc_option version=1
swdesc_embed_container "nginx_alpine.tar"
swdesc_files --extra-os nginx_start
[ATDE ~/mkswu]$ podman pull --arch arm64 docker.io/nginx:alpine
[ATDE ~/mkswu]$ podman run --rm docker.io/nginx:alpine uname -m
aarch64
[ATDE ~/mkswu]$ podman save docker.io/nginx:alpine > nginx_alpine.tar
[ATDE ~/mkswu]$ mkswu embed_container_nginx.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
embed_container_nginx.swu を作成しました
USBドライブに保存する
[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/usb_container_nginx.desc .
[ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start .
[ATDE ~/mkswu]$ cat usb_container_nginx.desc
swdesc_option version=1
swdesc_usb_container "nginx_alpine.tar"
swdesc_files --extra-os nginx_start
[ATDE ~/mkswu]$ podman pull --arch arm64 docker.io/nginx:alpine
[ATDE ~/mkswu]$ podman run --rm docker.io/nginx:alpine uname -m
aarch64
[ATDE ~/mkswu]$ podman save docker.io/nginx:alpine > nginx_alpine.tar
[ATDE ~/mkswu]$ mkswu -o usb_container_nginx.swu usb_container_nginx.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
以下のファイルをUSBメモリにコピーしてください：
'/home/atmark/mkswu/usb_container_nginx.swu'
'/home/atmark/mkswu/nginx_alpine.tar'
'/home/atmark/mkswu/.usb_container_nginx/nginx_alpine.tar.sig'
usb_container_nginx.swu を作成しました。
10.8.2. コンテナとコンテナに関連するデータを削除する | |
|---|
全てのコンテナとコンテナイメージ、コンテナに関するデータが削除されるため、充分に注意して使用してください。 |
VS Code 上で ABOSDE(Armadillo Base OS Development Environment) から、
Armadillo のコンテナイメージを全て削除する SWU イメージを作成することができます。 VS Code の左ペインの [COMMON PROJECT COMMAND] から [Generate Container Clear Swu] を実行すると、SWU イメージが作成されます。
SWU イメージは ~/mkswu/container_clear.swu に保存されます。 この SWU イメージを 「SWU イメージのインストール」 を参照して Armadillo へインストールしてください。 abos-ctrl container-clear を使用すると、コンテナ、コンテナイメージ、コンテナに関するデータを削除することができます。
abos-ctrl container-clear は以下の通り動作します。
10.8.3. コンテナ起動設定ファイルを作成するArmadillo Base OSでは、/etc/atmark/containers/*.confファイルに指定されているコンテナがブート時に自動的に起動します。
nginx.confの記載例を以下に示します。 .conf ファイルに設定可能なパラメーターの説明を以下に記載します。
podman_start --long-help コマンドでも詳細を確認できます。
set_image [イメージ名]
イメージの名前を設定できます。 例: set_image docker.io/debian:latest, set_image localhost/myimage イメージをrootfsとして扱う場合に --rootfs オプションで指定できます。 例: set_image --rootfs /var/app/volumes/debian add_ports [ホストポート]:[コンテナポート]
設定したポートで外部からコンテナへのアクセスが可能となります。 デフォルトはTCPで、UDPも /udp を付けて使えます。スペースで分けて複数のポートを設定することができます。 以下の例では、ポート80、443(web)、UDPの69(tftp)にアクセスすることができ、コンテナのポート22(ssh)にはポート2222からアクセスすることができます。 例: add_ports 80:80 443:443 2222:22 69:69/udp | |
|---|
pod を使う場合、このオプションはpodの設定にしないと有効になりませんのでご注意ください。 |
add_devices [ホストパス]:[コンテナパス]
コンテナでデバイスを作成して、使用可能となります。 コンテナパスを設定しない場合はホストと同じパスを使います。 複数のデバイスを作成したい場合はスペースで分けて設定してください。 例: add_devices /dev/galcore /dev/v4l/by-id/usb-046d_HD_Pro_Webcam_C920_78DA8CAF-video-index0:/dev/video3 ホストパスに「:」を含む場合は add_device "[ホストパス]" "[コンテナパス]" で追加できます。 例: add_device "/dev/v4l/by-path/platform-xhci-hcd.1.auto-usb-0:1.1:1.0-video-index1" "/dev/video3" コンテナパスに「:」を含むようなパスは設定できません。 add_volumes [ホストパス]:[コンテナパス]:[オプション]
指定するパスをコンテナ内でマウントして、データの保存や共有ができます。 ホストパスは以下のどれかを指定してください。
/var/app/rollback/volumes/<folder> か <folder>:
アップデートの際に新しくコピー（snapshot）した場合、コピー先のみ変更しますので、
アップデート中でもこのデータを使うことができます。
途中で電源が落ちた場合でも、このデータに影響はありません。 SWUpdateでアップデートするデータに向いています。
/var/app/volumes/<folder>: appパーティションに書きます。
アップデートの際にコピーされませんので、アップデート中の新たな変更は
更新されたコンテナ内のアプリケーションで見れます。 ログやデータベースに向いています。 -
/tmp/<folder>: 複数のコンテナでメモリファイルシステムを共有したい場合に使ってください。
-
/opt/firmware: 学習能力に必要なファムウェアライブラリーのパス。
コンテナパスを設定しない場合はホストパスと同じパスを使います。 オプションは podman run の --volume のオプションになりますので、 ro (read-only), nodev, nosuid, noexec, shared, slave 等を設定できます。 例：add_volumes /var/app/volumes/database:/database: ロールバックされないデータを/databaseで保存します。 例: add_volumes assets:/assets:ro,nodev,nosuid /opt/firmware: アプリケーションのデータを/assetsで読み取り、/opt/firmwareのファームウェアを使えます。 「:」はホスト側のパスとコンテナの側のパスを分割する意味があるため、ファイル名に「:」を使用することはできません。
ホスト側のパスにのみ「:」が含まれてる場合は「 add_volumes "[ホストパス]" "[コンテナパス]" "[オプション]" 」と指定することで設定できます。 | |
|---|
複数のコンテナでマウントコマンドを実行することがあれば、shared のフラグで起動後のマウントを共有することができます。
|
マウントを行うコンテナに shared の設定とマウント権限 (SYS_ADMIN) を与えます。
| |
マウントを使うコンテナに slave だけを設定すれば一方にしか共有されません。
| |
USB デバイスをマウントします。
| |
マウントされたことを確認します。
|
|
add_hotplugs [デバイスタイプ]
コンテナ起動後に挿抜を行なっても認識される(ホットプラグ)デバイスを設定できます。 通常、コンテナ内からデバイスを扱うためには、あらかじめ Armadillo 本体に当該のデバイスを接続した状態で、コンテナを起動する必要がありますが、 add_hotplugs を使用することでホットプラグに対応できます。 例: add_hotplugs input add_hotplugs に指定できる主要な文字列とデバイスファイルの対応について、表10.5「add_hotplugsオプションに指定できる主要な文字列」に示します。
表10.5 add_hotplugsオプションに指定できる主要な文字列 | 文字列 | 引数の説明 | 対象のデバイスファイル |
|---|
input | マウスやキーボードなどの入力デバイス | /dev/input/mouse0, /dev/input/event0 など | video4linux | USB カメラなどの video4linux デバイスファイル | /dev/video0 など | sd | USB メモリなどの SCSI ディスクデバイスファイル | /dev/sda1 など |
表10.5「add_hotplugsオプションに指定できる主要な文字列」に示した文字列の他にも、/proc/devicesの数字から始まる行に記載されている文字列を指定することができます。
図10.27「/proc/devicesの内容例」に示す状態の場合、デバイスタイプを示す文字列としては、各行の先頭の数字を除いた mem や pty などを指定できることがわかります。 デバイスタイプと実際のデバイスファイルの対応については、 カーネルドキュメント: devices.txt(Github) を参照してください。 複数のデバイスタイプを指定したい場合はスペースで分けて設定してください。 例: add_hotplugs input video4linux sd set_network [ネットワーク名]
この設定に「networkの作成」で作成したネットワーク以外に none と host の特殊な設定も選べます。 none の場合、コンテナに localhost しかないネームスペースに入ります。
host の場合はOSのネームスペースをそのまま使います。
例: set_network mynetwork set_ip [アドレス]
コンテナの IP アドレスを設定することができます。 例: set_ip 10.88.0.100 | |
|---|
コンテナ間の接続が目的であれば、podを使ってlocalhostかpodの名前でアクセスすることができます。 |
set_readonly yes
コンテナ内からのファイルシステムへの書き込み許可を設定します。 デフォルトで書き込み可能となっています。 コンテナ内からのファイルシステムへの書き込みを禁止することで、
tmpfs として使うメモリの消費を明示的に抑えることができますが、
アプリケーションによっては読み込み専用のファイルシステムでは動作しない可能性もあります。 10.8.3.11. イメージの自動ダウンロード設定set_pull [設定]
この設定を missing にすると、イメージが見つからない場合にイメージを自動的にダウンロードします。 always にすると、イメージがすでにダウンロード済みでも起動前に必ず更新の確認を取ります。
デフォルトでは never で、イメージが見つからない場合にエラーを表示します。 例：set_pull missing か set_pull always set_restart [設定]
コンテナが停止した時にリスタートさせます。 podman kill か podman stop で停止する場合、この設定と関係なくリスタートしません。
デフォルトで on-failure になっています。 例: set_restart always か set_restart no 10.8.3.13. 信号を受信するサービスの無効化set_init no
コンテナのメインプロセスが PID 1 で起動していますが、その場合のデフォルトの信号の扱いが変わります: SIGTERM などのデフォルトハンドラが無効です。 そのため、init 以外のコマンドを set_command で設定する場合は podman-init のプロセスを PID 1 として立ち上げて、設定したコマンドをその子プロセスとして起動します。 例: set_init no 10.8.3.14. podman logs 用のログサイズ設定set_log_max_size <サイズ>
podman logs でログを表示するために /run にログファイルを保存しています。
そのログのサイズが設定したサイズを越えるとクリアされます。デフォルトは「1MB」です。 10.8.3.15. podman のフックの仕組みadd_hook --stage <ステージ> [--] コマンド [コマンド引数]
コンテナが起動されるなど、動作ステージの変化をフックとしてコマンドを実行します。
複数のステージで実行したい場合は --stage オプションを複数設定してください。 指定可能なステージは precreate, prestart, createRuntime, createContainer, startContainer, poststart, と poststop です。
ステージの意味や使用方法の詳細は podman のドキュメンテーションを参照してください。 | |
|---|
Armadillo Base OS 3.19.1-at.4 現在では set_restart によるコンテナの再起動でも 1 度目の停止時のみ poststop フックが実行されます。
2 度目以降の停止では実行されませんのでご注意ください。 |
set_healthcheck [引数] [--] コマンド [コマンド引数]
定期的にコマンドを実行して、コンテナの正常性を確認します。
指定可能な引数は以下のとおりです： また、いくつかのタイミングでコマンドを実行させることができます： -
set_healthcheck_start_command コマンド [コマンド引数]: コンテナ起動後にヘルスチェックが初めて成功した際に実行されるコマンドです。
-
set_healthcheck_fail_command コマンド [コマンド引数]: ヘルスチェックが retries 回失敗した後に実行されるコマンドです。このコマンドは set_healthcheck の --action 設定の前に実行されますので、コマンドだけを実行したい場合は --action none で無効化してください。
-
set_healthcheck_recovery_command コマンド [コマンド引数]: ヘルスチェックが retries 回失敗した後に再び成功した際に実行されるコマンドです。コンテナを起動する際に成功せずに失敗した場合は、その 1 回目の成功の際に set_healthcheck_start_command で設定されたコマンドのみが実行されます。
例: set_healtcheck -- curl -s --fail http://localhost:8080/status
例: set_healthcheck_start_command abos-ctrl rollback-clone set_autostart no または set_autostart create
Armadillo の起動時にコンテナを自動起動しないように設定できます。 create を指定した場合はコンテナは生成されており、podman start <name> で起動させることができます。
no を指定した場合は podman_start <name> で起動させることができます。
| |
|---|
コンフィグに記載していないイメージはアップデートの際に削除されますので、そういったイメージに対して設定してください。 |
set_command [コマンド]
コンテナを起動するときのコマンド。設定されなかった場合、コンテナイメージのデフォルトを使います。 例: set_command /bin/sh -c "echo bad example" 10.8.3.19. コンテナ起動前にコマンドを実行するadd_pre_command [コマンド]
コンテナを起動する直前に設定したコマンドを実行します。 Armadillo Base OS の環境で実行されてますので、ハードウェアの設定等に適切です。 また、複数のコマンドを実行する場合は順番に実行されます。
設定したコマンドが1つでも失敗した場合は、コンテナは起動されません。 例: add_pre_command gpioset --daemonize CONx_y=1 10.8.3.20. podman run に引数を渡す設定add_args [引数]
ここまでで説明した設定項目以外の設定を行いたい場合は、この設定で podman run に直接引数を渡すことができます。 例：add_args --cap-add=SYS_TTY_CONFIG --env=XDG_RUNTIME_DIR=/run/xdg_home 10.8.4. アットマークテクノが提供するイメージを使うアットマークテクノは、動作確認環境として使用できる Debian ベースのイメージを提供しています。
ここでは以下の 3 つの手順について説明します。 -
ABOSDE からインストールする方法
-
Docker ファイルからイメージをビルドする方法
-
すでにビルド済みのイメージを使う方法
10.8.4.1. ABOSDE からインストールする
インストール用のプロジェクトを作成する
VS Code の左ペインの [A9E] から [Atmark Container New Project] を実行し、
表示されるディレクトリ選択画面からプロジェクトを保存するディレクトリを選択してください。
保存先を選択すると、プロジェクト名を入力するダイアログが表示されるので、
任意のプロジェクト名を入力してエンターキーを押してください。
この操作により、選択した保存先に、入力したプロジェクト名と同名のディレクトリが作成されます。 また、ここでは次のように設定しています。 -
保存先 : ホームディレクトリ
プロジェクト名 : my_project
SWU イメージを作成する
VS Code の左ペインの [my_project] から [Generate at-debian-image container setup swu] を実行してください。
作成した SWU ファイルは container_setup/at-debian-image/at-debian-image.swu に保存されています。
この SWU イメージを 「SWU イメージのインストール」 を参照して Armadillo へインストールしてください。
SBOM 生成に関わる設定を行う
ABOSDE から作成した場合は SBOM が同時に生成されます。
詳細は 「SBOM 生成に関わる設定を行う」 をご確認ください。
SBOM の生成には以下の二つのファイルが必要です。 -
コンフィグファイル
desc ファイル
SBOM の生成にはライセンス情報を示したコンフィグファイルを使用します。
コンフィグファイルは container_setup/at-debian-image.sbom_config.yaml.tmpl になります。
SWU イメージ作成時にこのコンフィグファイルからバージョン番号をアップデートした container_setup/at-debian-image.sbom_config.yaml が生成されます。 リリース時にはコンフィグファイルの内容を確認し、正しい内容に変更してください。
各項目の詳細な説明については SPDX specification v2.2.2 (https://spdx.github.io/spdx-spec/v2.2.2/) をご覧ください。
SBOM に含めるコンテナイメージ等の情報については desc ファイルに記載されています。
各項目の説明については 「desc ファイルを編集する」 をご覧ください。
10.8.4.2. Docker ファイルからイメージをビルドするArmadillo-900 開発セット コンテナ から
「Debian [VERSION] サンプル Dockerfile」 ファイル (at-debian-image-dockerfile-[VERSION].tar.gz) をダウンロードします。
その後 podman build コマンドを実行します。 podman images コマンドにより at-debian-image がビルドされたことが確認できます。
library/debian イメージはベースとなっている Debian イメージです。 10.8.4.3. ビルド済みのイメージを使用するArmadillo-900 開発セット コンテナ から
「Debian [VERSION] サンプルコンテナイメージ」 ファイル (at-debian-image-[VERSION].tar) をダウンロードします。
その後 podman load コマンドを実行します。 podman images コマンドにより at-debian-image がビルドされたことが確認できます。 10.8.5. alpine のコンテナイメージをインストールするalpine のコンテナイメージは、 ABOSDE を用いてインストールすることが可能です。
「ABOSDE からインストールする」 を参照して、 インストール用のプロジェクトを作成しておいてください。 VS Code の左ペインの [my_project] から [Generate alpine container setup swu] を実行してください。 作成した SWU ファイルは container_setup/alpine/alpine.swu に保存されています。
この SWU イメージを 「SWU イメージのインストール」 を参照して Armadillo へインストールしてください。 10.8.5.1. SBOM 生成に関わる設定を行うABOSDE から作成した場合は SBOM が同時に生成されます。
詳細は 「SBOM 生成に関わる設定を行う」 をご確認ください。
SBOM の生成には以下の二つのファイルが必要です。 SBOM の生成にはライセンス情報を示したコンフィグファイルを使用します。
コンフィグファイルは container_setup/alpine.sbom_config.yaml.tmpl になります。
SWU イメージ作成時にこのコンフィグファイルからバージョン番号をアップデートした container_setup/alpine.sbom_config.yaml が生成されます。 リリース時にはコンフィグファイルの内容を確認し、正しい内容に変更してください。
各項目の詳細な説明については SPDX specification v2.2.2 (https://spdx.github.io/spdx-spec/v2.2.2/) をご覧ください。
SBOM に含めるコンテナイメージ等の情報については desc ファイルに記載されています。
各項目の説明については 「desc ファイルを編集する」 をご覧ください。 この章では、コンテナ内のネットワークを扱う方法について示します。 10.8.6.1. コンテナの IP アドレスを確認する基本的にコンテナの IP アドレスは Podman イメージからコンテナを作成したときに自動的に割り振られます。
コンテナに割り振られている IP アドレスはホスト OS 側からは podman inspect コマンドを用いて、以下のように確認することができます。 コンテナ内の ip コマンドを用いて確認することもできます。 10.8.6.2. コンテナに固定 IP アドレスを設定する | |
|---|
podman はデフォルトで 10.88.0.0/16 を使います。 他に使用しているIPアドレスと被った場合等はコンテナに別のIPアドレスを設定してください。 |
コンテナに固定 IP アドレスを設定するためには、最初にユーザ定義のネットワークを作成する必要があります。
以下に 198.51.100.0/24 にユーザ定義のネットワークを作成する例を示します。 コンテナを作成する際に、上記で作成したネットワークと設定したい IP アドレスを渡すことで、
コンテナの IP アドレスを固定することができます。
以下の例では、IPアドレスを 198.51.100.10 に固定します。 コンテナの IP アドレスが、198.51.100.10 に設定されていることが確認できます。 この章では、コンテナ内で様々なサーバを構築する方法について示します。
この章で取り上げているサーバは alpine の apk コマンドでインストールすることが可能です。 ここでは、HTTP サーバとして Apache と lighttpd の 2 種類を使用する場合について説明します。 alpine イメージからコンテナを作成し、そのコンテナ内に Apache をインストールします。
コンテナ作成の際に、ホスト OS の 8080 番ポートをコンテナ内の 80 番ポートに転送する指定を行っています。 他の PC などの Web ブラウザから、ホスト OS の IP アドレスの 8080 番ポートに接続すると、
動作確認用ページが表示されます。
デフォルトでは、/var/www/localhost/htdocs ディレクトリにファイルを置くことで Web ブラウザから閲覧できます。
Apache の詳細な設定は、/etc/apache2 ディレクトリにある設定ファイルを編集することで変更可能です。 alpine イメージからコンテナを作成し、そのコンテナ内に lighttpd をインストールします。
コンテナ作成の際に、ホスト OS の 8080 番ポートをコンテナ内の 80 番ポートに転送する指定を行っています。 lighttpd はデフォルトでは動作確認用ページが用意されていないため、上記の手順では簡単なページを
/var/www/localhost/htdocs ディレクトリの下に配置しています。
他の PC などの Web ブラウザから、ホスト OS の IP アドレスの 8080 番ポートに接続すると表示されます。
lighttpd の詳細な設定は、/etc/lighttpd ディレクトリにある設定ファイルを編集することで変更可能です。 ここでは、FTP サーバとして vsftp を使用する場合について説明します。
alpine イメージからコンテナを作成し、そのコンテナ内に vsftpd をインストールします。
コンテナ作成の際に、FTP 通信で使用するポートについてホスト OS 側からコンテナ内のポートに転送する指定と、
コンテナ内の環境変数として PASV_ADDRESS にホスト OS 側の IP アドレスの指定を行っています。 コンテナ内にユーザアカウントを作成し、このユーザで ftp ログインできるようにします。 作成したユーザで ftp ログインできるように、vsftpd の設定ファイルを編集します。 編集した設定ファイルを指定して vftpd を起動することにより、ftp 接続可能となります。
ftp ログイン時のアカウントは前述の手順で作成したものを使用します。 ここでは、Samba サーバの構築方法について説明します。
alpine イメージからコンテナを作成し、そのコンテナ内に samba をインストールします。
コンテナ作成の際に、samba で使用するポートについてホスト OS 側からコンテナ内のポートに転送する指定を行っています。 コンテナ内にユーザアカウントを作成し、このユーザで samba にログインできるようにします。 samba を起動すると、前述の手順で作成したユーザアカウントで他の PC などからログインすることができます。 共有するディレクトリの指定などの詳細設定は /etc/samba/smb.conf ファイルを編集することで変更可能です。 ここでは、RDMS として sqlite を使用する場合について説明します。
alpine イメージからコンテナを作成し、そのコンテナ内に sqlite をインストールします。 コンテナ内に入り、sqlite3 コマンドを実行すると sqlite のプロンプトが表示され
データベースの操作ができるようになります。 10.8.8. コンテナからのpoweroff及びrebootArmadillo Base OSはbusybox initでshutdownとrebootを対応します。 busybox initでPID 1にsignalを送ることでshutdownやrebootとなります。
コンテナからsignalを送るように、pid namespaceを共有する必要がありますが、共有されたらkillで実行できます。 この章では、コンテナ内で動作しているアプリケーションに何らかの異常が発生し停止してしまった際に、
ソフトウェアウォッチドッグタイマーを使って、システムを再起動する方法について示します。 10.8.9.1. ソフトウェアウォッチドッグタイマーを扱うコンテナ内で動作するアプリケーションからソフトウェアウォッチドッグタイマーを扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/watchdogN を渡す必要があります。以下は、/dev/watchdog0 を渡して alpine イメージからコンテナを作成する例です。 ソフトウェアウォッチドッグタイマーは、プログラム内からデバイスファイル /dev/watchdog0 を open した時点で起動します。
コンテナ内に入ってソフトウェアウォッチドッグタイマーを echo コマンドで起動する例を以下に示します。 ソフトウェアウォッチドッグタイマーを起動した後、/dev/watchdog0 に（ V 以外の）任意の文字を書き込むことで
ソフトウェアウォッチドッグタイマーをリセットすることができます。
60 秒間（ V 以外の）任意の文字の書き込みがない場合は、システムが再起動します。 ソフトウェアウォッチドッグタイマーを停止したい場合は、/dev/watchdog0 に V を書き込みます。 10.9. Web UI から Armadillo をセットアップする (ABOS Web)ABOS Web は、Web ブラウザから Armadillo の動作設定を行う機能で、ABOS (Armadillo Base OS) を搭載する全ての Armadillo に対応しています。 詳細は、「ABOS Web とは」を参照してください。 10.9.1. ABOS Web ではできないことABOS Web は、ABOS の詳細や Linux のコマンドシェルの操作に詳しくない方でも、簡単に Armadillo のセットアップを行なえることを目的にしています。
そのための、Armadillo の動作設定を行う機能ですから、動作設定以外のこと、たとえば、Armadillo の動作状態を監視したりすることは、できません。
さらに、Armadillo をインターネットから設定操作する、リモート操作もできません。
セキュリティの観点から、ABOS Web は、同じ LAN 内からの接続しか受け付けないように実装しています。 ABOS Web でできる Armadillo の設定については、「ABOS Web の設定機能一覧と設定手順」を参照してください。
なお、ABOS Web は OSS で提供していますので、現在の ABOS Web に無い設定機能を、ご自分で実装して機能追加することも可能です。 10.9.2. ABOS Web の設定機能一覧と設定手順現在、ネットワークに関して ABOS Web で設定できるのは以下のものです。 -
WWAN設定
-
WLAN設定
-
各接続設定（各ネットワークインターフェースの設定）
-
DHCPサーバー設定
-
NAT設定
-
VPN設定
これらについては、「ABOS Web を用いたネットワーク設定方法」で紹介していますので、そちらを参照してください。 ネットワーク以外にも ABOS Web は以下の機能を持っています。 -
コンテナ管理
-
SWUインストール
-
時刻設定
-
アプリケーション向けのインターフェース (Rest API)
-
カスタマイズ
本章では、これらのネットワーク以外の設定項目について紹介します。 ABOS Web から Armadillo 上のコンテナを一覧表示して、コンテナごとに起動・停止を行うことができます。 ABOS Web のトップページから、"コンテナ管理"をクリックすると、図10.56「コンテナ管理」の画面に遷移します。 この画面では、ABOS 上にあるコンテナ全てについて、イメージ名やコンテナ名、現在状態を一覧表示します。
コンテナの一覧表示欄で選択したコンテナに対し、起動と停止、および、コンテナから出力されたログの表示を行うことができます。 ![[注記]](images/note.png) | |
|---|
「VPN設定」に記載のとおり、VPN 接続を設定すると、abos_web_openvpn のコンテナが作成されます。
VPN 接続中は、このコンテナが動作状態になっており、このコンテナをコンテナ管理画面で停止すると、VPN 接続が切断されます。 |
ABOS Web から PC 上の SWU イメージや HTTP サーバー上の SWU イメージを Armadillo にインストールすることができます。 SWU イメージについては、「SWU イメージとは」を参照してください。 ABOS Web のトップページから、"SWU インストール"をクリックすると、図10.57「SWU インストール」の画面に遷移します。 この画面では、PC 上の SWU イメージファイルまたは、HTTP サーバー上の SWU イメージファイルの URL を指定して、Armadillo にインストールすることができます。
Armadillo のソフトウェアのアップデート用に最初に行う設定で作成する initial_setup.swu が、まだ Armadillo にインストールされていなければ、"mkswu --init で作成した initial_setup.swu をインストールしてください。" というメッセージを画面上部に表示します。 SWU イメージのインストール動作を実行する時には、進行状況を示すログを表示します。
"現在の SWU で管理されているバージョン" 欄には、ABOS の各ソフトウェアコンポーネントの名前とバージョン情報を一覧表示します。 10.9.6. アプリケーション向けのインターフェース (Rest API)コンテナやスクリプトから ABOS Web の一部の機能を使用できます。 10.9.6.1. Rest API へのアクセス権の管理Rest API は ABOS Web のパスワードと Rest API 用のトークンで認証されます。 また、接続可能なネットワークにも制限をかけております。初期状態では、同一サブネットからのアクセスのみ許容しています。
同一サブネット外の IP アドレスからアクセスしたい場合は設定が必要です。
設定方法は 「ABOS Web へのアクセス」 を参照してください。 各リクエストは以下のどちらかの Authorization ヘッダーで認証されます： -
Basic (パスワード認証）: curl の -u :<password> 等で認証可能です。<password> の文字列は ABOS Web で設定したパスワードです。
-
Bearer (トークン認証）: curl の -H "Authorization: Bearer <token> 等で認証可能です。<token> は /api/tokens であらかじめ生成した文字列です。
また、トークンには権限も設定できます。Admin で生成されたトークンはすべてのインターフェースにアクセスできますが、
一部のインターフェースしか使用しない場合はそのインターフェースに必要な権限だけを持つトークンを生成してください。 トークンの管理は ABOS Web の「設定管理」ページで行えます: | |
|---|
ABOS Web の バージョン 1.2.3 以降では、Token ID の横にあるクリップボードアイコンをクリックするとクリップボードにコピーすることができます。 |
10.9.6.2. Rest API 使用例の前提条件各 Rest API の使用例を説明します。使用例では以下を前提としています。： -
ABOS Web に
https://armadillo.local:58080 でアクセスします。
-
「
AUTH 」環境変数に ABOS Web で生成したトークンを設定します。
例： AUTH="Authorization: Bearer 35ac39a8-1eeb-4bb2-84d2-cb542cdbc873"
-
curl コマンドを省略するため、以下のように alias を使用します：
[ATDE ~]$ alias curl_rest='curl -k -H "$AUTH" -w "\nhttp code: %{http_code}\n" ' | |
|---|
コンテナから ABOS Web には「https://host.containers.internal:58080」でアクセスできます。 |
| |
|---|
この章で説明する例では、curl のオプションに -k を指定して証明書を無視するようにしています。
もし、証明書を使用したい場合は以下のように設定してください。 [ATDE ~]$ openssl s_client -showcerts -connect armadillo.local:58080 </dev/null 2>/dev/null | openssl x509 -outform PEM > abosweb.pem
[ATDE ~]$ CERT="$PWD/abosweb.pem"
[ATDE ~]$ alias curl_rest='curl -H "$AUTH" --cacert "$CERT" -w "\nhttp code: %{http_code}\n" ' |
10.9.6.3. Rest API の入力と出力インターフェースの一部にはパラメータを取るものがあります。パラメータがある場合は json (Content-Type を application/json に設定する）と
form（デフォルトの application/x-www-form-urlencoded でのパラメータ）のどちらでも使用可能です。 インターフェースの出力がある場合は json object で出力されます。
今後のバージョンアップで json object のキーが増える可能性があるため、
出力された値を処理する場合はその点に留意してください。 エラーの場合は json object の「error」キーに文字列のエラーが記載されています。
http のステータスコードも 50x になります。 エラーの例： [ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/tokens/3b2d830d-2f64-4e76-9e59-316da82eefc4
{"error":"No such token"}
http code: 50010.9.6.4. Rest API : トークン管理トークン管理のためのインターフェースは以下のとおりです：
トークン一覧
GET "/api/tokens"
必要権限: Admin
パラメータ: 無し
出力: トークンリスト
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/tokens
{"tokens":[{"token":"35ac39a8-1eeb-4bb2-84d2-cb542cdbc873","permissions":["Admin"]},{"token":"5c426ce5-8fcb-4e54-9ff6-80aba50935ee","permissions":["Reboot","NetworkView"]}]}
http code: 200
トークン取得
GET "/api/tokens/<token>"
必要権限: Admin
パラメータ: 無し
出力: トークン情報
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/tokens/35ac39a8-1eeb-4bb2-84d2-cb542cdbc873
{"token":"35ac39a8-1eeb-4bb2-84d2-cb542cdbc873","permissions":["Admin"]}
http code: 200
トークン生成
POST "/api/tokens"
必要権限: Admin
パラメータ: 付与したい permissions 権限リスト(ない場合は「Admin」で生成されます）
出力: 生成されたトークン情報
[ATDE ~]$ curl_rest -H "Content-type: application/json" -d '{"permissions": ["SwuInstall", "ContainerView"]}' https://armadillo.local:58080/api/tokens
{"token":"3b2d830d-2f64-4e76-9e59-316da82eefc4","permissions":["SwuInstall","ContainerView"]}
http code: 200
トークン編集 (存在しない場合は指定のトークンで生成されます）
POST "/api/tokens/{token_id}"
必要権限: Admin
パラメータ: 付与したい permissions 権限リスト(ない場合は編集しません）
出力: 編集か生成されたトークン情報
[ATDE ~]$ curl_rest -X POST -d permissions=Poweroff -d permissions=ContainerAdmin https://armadillo.local:58080/api/tokens/3b2d830d-2f64-4e76-9e59-316da82eefc4
{"token":"3b2d830d-2f64-4e76-9e59-316da82eefc4","permissions":["Poweroff","ContainerAdmin"]}
トークン削除
DELETE "/api/tokens/{token_id}"
必要権限: Admin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/tokens/3b2d830d-2f64-4e76-9e59-316da82eefc4
http code: 200
abos-web パスワード変更
POST "/api/password"
必要権限: Admin
パラメータ: password でハッシュ済みのパスワード文字列か hashed=false が設定されている場合は平文の文字列
出力: 無し
[ATDE ~]$ PWD_HASH=$(openssl passwd -6)
Password:
Verifying - Password:
[ATDE ~]$ echo $PWD_HASH
$6$LuXQduN7L3PwbMaZ$txrw8vLJqEVUreQnZhM0CYMQ5U5B9b58L0mpVRULDiVCh2O46GKscq/xsDPskjxg.x8ym0ri1/8NqFBu..IZE0
[ATDE ~]$ curl_rest --data-urlencode "password=$PWD_HASH" -X POST https://armadillo.local:58080/api/password
http code: 200
インストール済み SWU のバージョン情報取得
GET "/api/swu/versions"
必要権限: SwuView
パラメータ: 無し
出力: Swupdate の各バージョン情報
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/swu/versions
{"extra_os.custom":"54","extra_os.container":"1","custom":"54","extra_os.initial_setup":"4","boot":"2020.4-at19","base_os":"3.18.4-at.6","extra_os.sshd":"1"}
http code: 200-
アップデートステータス取得
GET "/api/swu/status"
必要権限: SwuView
パラメータ: 無し
出力: rollback_ok: ロールバック状態 (false の場合は rollback されています)、last_update_timestamp: UTC の unix epoch (数字での日付)、
last_update_versions: 最新のアップデートで更新されたバージョン情報 (コンポーネント → [更新前のバージョン, 更新後のバージョン]。
更新前に存在しなかったコンポーネントの場合は null で記載されています)
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/swu/status
{"rollback_ok":true,"last_update_timestamp":1703208559,"last_update_versions":{"custom":[null,"54"],"extra_os.custom":["53","54"]}}
http code: 200
SWU をファイルアップロードでインストール
POST "/api/swu/install/upload"
必要権限: SwuInstall
パラメータ: multipart/form-data で swu の転送
出力: swupdate プロセスの出力 (stdout または stderr)、またはアップデートプロセスの出力ステータス (exit_code または exit_signal)
[ATDE ~]$ curl_rest -F swu=@"$HOME/mkswu/file.swu" https://armadillo.local:58080/api/swu/install/upload
{"stdout":"SWUpdate v2023.05_git20231025-r0\n"}
{"stdout":"\n"}
{"stdout":"Licensed under GPLv2. See source distribution for detailed copyright notices.\n"}
{"stdout":"\n"}
{"stdout":"[INFO ] : SWUPDATE running : [main] : Running on AGX4500 Revision at1\n"}
{"stdout":"[INFO ] : SWUPDATE started : Software Update started !\n"}
{"stdout":"[INFO ] : SWUPDATE running : [install_single_image] : Installing pre_script\n"}
{"stdout":"[INFO ] : SWUPDATE running : [read_lines_notify] : No base os update: copying current os over\n"}
: (省略)
{"stdout":"[INFO ] : SWUPDATE running : [install_single_image] : Installing post_script\n"}
{"stdout":"[INFO ] : SWUPDATE running : [read_lines_notify] : Removing unused containers\n"}
{"stdout":"[INFO ] : SWUPDATE running : [read_lines_notify] : swupdate triggering reboot!\n"}
{"stderr":"Killed\n"}
{"exit_code":0}
http code: 200
SWU を URL でインストール
POST "/api/swu/install/url"
必要権限: SwuInstall
パラメータ: url=<SWU をダウンロードできる URL>
出力: swupdate プロセスの出力 (stdout または stderr)、またはアップデートプロセスの出力ステータス (exit_code または exit_signal)
[ATDE ~]$ curl_rest -d url=https://url/to/file.swu https://armadillo.local:58080/api/swu/install/url
{"stdout":"Downloading https://url/to/file.swu...\n"}
{"stdout":"SWUpdate v2023.05_git20231025-r0\n"}
{"stdout":"\n"}
{"stdout":"Licensed under GPLv2. See source distribution for detailed copyright notices.\n"}
{"stdout":"\n"}
{"stdout":"[INFO ] : SWUPDATE running : [main] : Running on AGX4500 Revision at1\n"}
{"stdout":"[INFO ] : SWUPDATE started : Software Update started !\n"}
{"stdout":"[INFO ] : SWUPDATE running : [install_single_image] : Installing pre_script\n"}
{"stdout":"[INFO ] : SWUPDATE running : [read_lines_notify] : No base os update: copying current os over\n"}
: (省略)
{"stdout":"[INFO ] : SWUPDATE running : [install_single_image] : Installing post_script\n"}
{"stdout":"[INFO ] : SWUPDATE running : [read_lines_notify] : Removing unused containers\n"}
{"stdout":"[INFO ] : SWUPDATE running : [read_lines_notify] : swupdate triggering reboot!\n"}
{"stderr":"Killed\n"}
{"exit_code":0}
http code: 200
10.9.6.6. Rest API : コンテナ操作
コンテナ一覧
GET "/api/containers"
必要権限: ContainerView
パラメータ: 無し
出力: 各コンテナの id, name, state, command, image 情報
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/containers
{"containers":[{"id":"02616122dcea5bd75c551b29b2ef54f54e09f59c50ce3282684773bc6bfb86a8","name":"python_app","state":"running","command":["python3","/vol_app/src/main.py"],"image":"localhost/python_arm64_app_image:latest"}]}
http code: 200
コンテナログ取得
GET "/api/containers/{container}/logs"
必要権限: ContainerView
パラメータ: follow=true (podman logs -f と同様の効果)
出力: podman logs プロセスの出力 (stdout または stderr)、またはアップデートプロセスの出力ステータス (exit_code または exit_signal)
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/containers/python_app/logs
{"stdout":"Some message\n"}
{"exit_code":0}
http code: 200follow=true を付与する例 [ATDE ~]$ curl_rest https://armadillo.local:58080/api/containers/python_app/logs?follow=true
{"stdout":"Some message\n"}
Ctrl-C で終了
コンテナ起動
POST "/api/containers/{container}/start"
必要権限: ContainerAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/containers/python_app/start
http code: 200
コンテナ停止
POST "/api/containers/{container}/stop"
必要権限: ContainerAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/containers/python_app/stop
http code: 200
10.9.6.7. Rest API : ネットワーク設定
ネットワーク設定一覧
GET "/api/connections"
必要権限: NetworkView
パラメータ: 無し
出力: ネットワーク設定一覧と各接続の uuid, name, state, ctype, 存在すれば device 情報
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/connections
{"connections":[{"name":"Wired connection 1","state":"activated","uuid":"18d241f1-946c-3325-974f-65cda3e6eea5","ctype":"802-3-ethernet","device":"eth0"},{"name":"lo","state":"activated","uuid":"529ec241-f122-4cb2-843f-ec9787b2aee7","ctype":"loopback","device":"lo"},{"name":"podman0","state":"activated","uuid":"be4583bc-3498-4df2-a31c-773d781433aa","ctype":"bridge","device":"podman0"},{"name":"veth0","state":"activated","uuid":"03446b77-b1ab-47d0-98fc-f167c3f3778a","ctype":"802-3-ethernet","device":"veth0"},{"name":"Wired connection 2","state":"","uuid":"181f44df-850e-36c1-a5a4-6e461c768acb","ctype":"802-3-ethernet"},{"name":"Wired connection 3","state":"","uuid":"e4381368-6351-3985-ba6e-2625c62b8d39","ctype":"802-3-ethernet"}]}
http code: 200
ネットワーク設定詳細取得
GET "/api/connections/{connection}"
必要権限: NetworkView
パラメータ: 無し（URL の connection は UUID または接続名で使用可能）
出力: 接続の詳細情報（Network Manager のプロパティ）
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/connections/Wired%20connection%201
{"name":"Wired connection 1","state":"activated","uuid":"18d241f1-946c-3325-974f-65cda3e6eea5","ctype":"802-3-ethernet","device":"eth0","props":{"802-3-ethernet.accept-all-mac-addresses":"-1","802-3-ethernet.auto-negotiate":"no","802-3-ethernet.cloned-mac-address":"","802-3-ethernet.duplex":"","802-3-ethernet.generate-mac-address-mask":"","802-3-ethernet.mac-address":"","802-3-ethernet.mac-address-blacklist":"","802-3-ethernet.mtu":"auto","802-3-ethernet.port":"","802-3-ethernet.s390-nettype":"","802-3-ethernet.s390-options":"","802-3-ethernet.s390-subchannels":"","802-3-ethernet.speed":"0","802-3-ethernet.wake-on-lan":"default","802-3-ethernet.wake-on-lan-password":"","GENERAL.CON-PATH":"/org/freedesktop/NetworkManager/Settings/1","GENERAL.DBUS-PATH":"/org/freedesktop/NetworkManager/ActiveConnection/6","GENERAL.DEFAULT":"yes","GENERAL.DEFAULT6":"no","GENERAL.DEVICES":"eth0","GENERAL.IP-IFACE":"eth0","GENERAL.MASTER-PATH":"","GENERAL.NAME":"Wired connection 1","GENERAL.SPEC-OBJECT":"","GENERAL.STATE":"activated","GENERAL.UUID":"18d241f1-946c-3325-974f-65cda3e6eea5","GENERAL.VPN":"no","GENERAL.ZONE":"","IP4.ADDRESS[1]":"198.51.100.123/16","IP4.DNS[1]":"192.0.2.1","IP4.DNS[2]":"192.0.2.2","IP4.GATEWAY":"198.51.100.1","IP4.ROUTE[1]":"dst = 198.51.100.0/16, nh = 0.0.0.0, mt = 100","IP4.ROUTE[2]":"dst = 0.0.0.0/0, nh = 198.51.100.1, mt = 100","IP6.ADDRESS[1]":"fe80::211:cff:fe00:b13/64","IP6.GATEWAY":"","IP6.ROUTE[1]":"dst = fe80::/64, nh = ::, mt = 1024","connection.auth-retries":"-1","connection.autoconnect":"yes","connection.autoconnect-priority":"-999","connection.autoconnect-retries":"-1","connection.autoconnect-slaves":"-1","connection.dns-over-tls":"-1","connection.gateway-ping-timeout":"0","connection.id":"Wired connection 1","connection.interface-name":"eth0","connection.lldp":"default","connection.llmnr":"-1","connection.master":"","connection.mdns":"-1","connection.metered":"unknown","connection.mptcp-flags":"0x0","connection.multi-connect":"0","connection.permissions":"","connection.read-only":"no","connection.secondaries":"","connection.slave-type":"","connection.stable-id":"","connection.timestamp":"1703208824","connection.type":"802-3-ethernet","connection.uuid":"18d241f1-946c-3325-974f-65cda3e6eea5","connection.wait-activation-delay":"-1","connection.wait-device-timeout":"-1","connection.zone":"","ipv4.addresses":"198.51.100.123/16","ipv4.auto-route-ext-gw":"-1","ipv4.dad-timeout":"-1","ipv4.dhcp-client-id":"","ipv4.dhcp-fqdn":"","ipv4.dhcp-hostname":"","ipv4.dhcp-hostname-flags":"0x0","ipv4.dhcp-iaid":"","ipv4.dhcp-reject-servers":"","ipv4.dhcp-send-hostname":"yes","ipv4.dhcp-timeout":"0","ipv4.dhcp-vendor-class-identifier":"","ipv4.dns":"192.0.2.1,192.0.2.2","ipv4.dns-options":"","ipv4.dns-priority":"0","ipv4.dns-search":"","ipv4.gateway":"198.51.100.1","ipv4.ignore-auto-dns":"no","ipv4.ignore-auto-routes":"no","ipv4.link-local":"0","ipv4.may-fail":"yes","ipv4.method":"manual","ipv4.never-default":"no","ipv4.replace-local-rule":"-1","ipv4.required-timeout":"-1","ipv4.route-metric":"-1","ipv4.route-table":"0","ipv4.routes":"","ipv4.routing-rules":"","ipv6.addr-gen-mode":"eui64","ipv6.addresses":"","ipv6.auto-route-ext-gw":"-1","ipv6.dhcp-duid":"","ipv6.dhcp-hostname":"","ipv6.dhcp-hostname-flags":"0x0","ipv6.dhcp-iaid":"","ipv6.dhcp-send-hostname":"yes","ipv6.dhcp-timeout":"0","ipv6.dns":"","ipv6.dns-options":"","ipv6.dns-priority":"0","ipv6.dns-search":"","ipv6.gateway":"","ipv6.ignore-auto-dns":"no","ipv6.ignore-auto-routes":"no","ipv6.ip6-privacy":"-1","ipv6.may-fail":"yes","ipv6.method":"auto","ipv6.mtu":"auto","ipv6.never-default":"no","ipv6.ra-timeout":"0","ipv6.replace-local-rule":"-1","ipv6.required-timeout":"-1","ipv6.route-metric":"-1","ipv6.route-table":"0","ipv6.routes":"","ipv6.routing-rules":"","ipv6.token":"","proxy.browser-only":"no","proxy.method":"none","proxy.pac-script":"","proxy.pac-url":""}}
http code: 200
ネットワーク設定の変更
PATCH "/api/connections/{connection}"
必要権限: NetworkAdmin
パラメータ: Network Manager で編集可能な値
出力: 無し
[ATDE ~]$ curl_rest -X PATCH -d ipv4.method=manual -d ipv4.addresses=198.51.100.123/16 https://armadillo.local:58080/api/connections/Wired%20connection%201
http code: 200
ネットワークの接続
POST "/api/connections/{connection}/up"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/connections/Wired%20connection%201/up
http code: 200
ネットワークの切断
POST "/api/connections/{connection}/down"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/connections/Wired%20connection%201/down
http code: 200
ネットワーク設定の削除
DELETE "/api/connections/{connection}"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/connections/178b8c95-fcad-4bb1-8040-5a02b9ad046f
http code: 200 | |
|---|
通信に使用しているネットワークの設定を削除した場合は Armadillo へアクセスできなくなりますので、ご注意ください。 |
10.9.6.8. Rest API : WLAN
無線ネットワークのリスト取得
GET "/api/wlan/scan"
必要権限: NetworkView
パラメータ: (任意)rescan=true/false, false を指定するとキャッシュされているスキャン結果を出力します。
出力: リスト
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wlan/scan
[{"id":"my_ap","signal":74,"bssid":"04:42:1A:E4:78:0C","chan":44,"rate":"540 Mbit/s","security":"WPA2 WPA3"},{"id":"other_ap","signal":65,"bssid":"AC:44:F2:56:22:38","chan":1,"rate":"130 Mbit/s","security":"WPA2"}]
http code: 200
*無線ネットワークの接続
POST "/api/wlan/connect"
必要権限: NetworkAdmin
パラメータ： ssid, passphrase, ifname, bssid, hidden. ssid 以外は任意です。
出力: 生成した接続の uuid
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wlan/connect -d ssid=my_ap -d passphrase=my_passphrase
{"uuid":"178b8c95-fcad-4bb1-8040-5a02b9ad046f"}
http code: 200
無線ネットワーク アクセスポイントの設定
POST "/api/wlan/ap"
必要権限: NetworkAdmin
パラメータ: ssid, passphrase, bridge_addr, hw_mode/channel, interface.
interface は任意です。hw_mode:2.4GHz を使用する場合は "g"、5GHz を使用する場合は "a" を設定します。
channel: 2.4GHz の場合は 1 〜 13、5GHz の場合は 36、40、44、48 を設定します。
hw_mode/channel を設定しない場合は自動的に選択されますが、両方を未設定にすることはできません。
出力: 無し
[ATDE ~]$ curl_rest -d ssid=my_ap -d passphrase=my_passphrase -d bridge_addr=198.51.100.1/24 -d channel=3 https://armadillo.local:58080/api/wlan/ap
http code: 200 | |
|---|
アクセスポイントを設定するとクライアントの接続が無効になります。 |
| |
|---|
クライアントの接続の削除は DELETE "/api/connections/{connection}" で行えます。 |
無線ネットワーク アクセスポイントの削除
DELETE "/api/wlan/ap"
必要権限: NetworkAdmin
パラメータ: interface (任意)
出力: 無し
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/wlan/ap
http code: 200
10.9.6.9. Rest API : WWAN の設定
WWAN の設定追加
POST "/api/wwan"
必要権限: NetworkAdmin
パラメータ: apn, user, password, auth_type (CHAP/PAP, デフォルト CHAP), mccmnc, ipv6 (bool、デフォルト true)
apn 以外は任意です。
出力: 追加された接続の uuid
[ATDE ~]$ curl_rest -d apn=provider.tld -d user=provider -d password=provider https://armadillo.local:58080/api/wwan
{"uuid":"ce603d3e-838b-4ac8-b7fd-6a3f1abe4003"}
http code: 200
WWAN の設定削除
DELETE "/api/wwan"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/wwan
http code: 200
| |
|---|
WWAN の設定確認または一時的な切断は connection の API で行ってください。 |
IMEI の取得
GET "/api/wwan/imei"
必要権限: NetworkView
パラメータ: 無し
出力: LTE モジュールの IMEI
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wwan/imei
{"imei":"XXXXXXXXXXXXXXX"}
http code: 200
電話番号の取得
GET "/api/wwan/phone_numbers"
必要権限: NetworkView
パラメータ: 無し
出力: SIM カードに設定されている電話番号
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wwan/phone_numbers
{"phone_numbers":["XXXXXXXXXXX"]}
http code: 200
電波品質の取得
GET "/api/wwan/signal_quality"
必要権限: NetworkView
パラメータ: 無し
出力: 電波品質(mmcli コマンドで出力される signal quality 相当の値)
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wwan/signal_quality
{"signal_quality":"54"}
http code: 200
SMS 一覧の取得
GET "/api/wwan/sms"
必要権限: SmsView
パラメータ: 無し
出力: SMS メッセージ ID 一覧
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wwan/sms
{"message_ids":["0", "1"]}
http code: 200
SMS の取得
GET "/api/wwan/sms/{message_id}"
必要権限: SmsView
パラメータ: 無し
出力: SMS の内容
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wwan/sms/0
{"sms":{"content":{"data":"--","number":"XXXXXXXXXXX","text":"message"},"dbus_path":"/org/freedesktop/ModemManager1/SMS/0","properties":{"pdu_type":"deliver","state":"received","storage":"me","timestamp":"20YY-MM-DDThh:mm:ss+ZZ"}}}
http code: 200
| |
|---|
message_id は SMS 一覧の取得で表示された値を使用します。 |
SMS の作成・送信
POST "/api/wwan/sms"
必要権限: SmsSend
パラメータ: phone_number: 送信先電話番号, message: 送信するメッセージ
出力: 無し
[ATDE ~]$ curl_rest -d phone_number=XXXXXXXXXXX -d message="message" https://armadillo.local:58080/api/wwan/sms
http code: 200
SMS の削除
DELETE "/api/wwan/sms/{message_id}"
必要権限: SmsView
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/sms/0
http code: 200
| |
|---|
message_id は SMS 一覧の取得で表示された値を使用します。 |
10.9.6.10. Rest API : DHCP の設定
DHCP の設定確認
GET "/api/dhcp"
必要権限: NetworkView
パラメータ: 無し
出力: interface, ip_addr, start_addr, end_addr, lease_time のリスト
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/dhcp
[{"interface":"br_ap","ip_addr":"198.51.100.1/24","start_addr":"198.51.100.10","end_addr":"198.51.100.20","lease_time":"3600"}]
http code: 200
DHCP の設定
POST "/api/dhcp/{interface}"
必要権限: NetworkAdmin
パラメータ: start_addr, end_addr, lease_time
lease_time を設定しなかった場合は 3600 (秒）とする
出力: 無し
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/dhcp/br_ap -d start_addr=198.51.100.10 -d end_addr=198.51.100.20
http code: 200
DHCP の設定削除
DELETE "/api/dhcp/{interface}"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/dhcp/br_ap
http code: 200
10.9.6.11. Rest API : NAT の設定
NAT (masquerade) の設定確認
GET "/api/nat"
必要権限: NetworkView
パラメータ: 無し
出力: NAT されている interface のリスト
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/nat
[{"interface":"eth0"}]
http code: 200
NAT の設定
POST "/api/nat/{interface}"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/nat/eth0
http code: 200
NAT の削除
DELETE "/api/nat/{interface}"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/nat/eth0
http code: 200
ポートフォワードの設定確認
GET "/api/port_forwarding"
必要権限: NetworkView
パラメータ: 無し
出力: フォワードされてるポート
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/port_forwarding
[{"interface":"eth0","protocol":"tcp","dport":"22","destination":"127.0.0.1","destination_port":"2222"}]
http code: 200
ポートフォワードの設定
POST "/api/port_forwarding"
必要権限: NetworkAdmin
パラメータ: interface, protocol (デフォルト tcp), dport, destination, destination_port
出力: 無し
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/port_forwarding -d interface=eth0 -d dport=22 -d de
stination=127.0.0.1 -d destination_port=2222
http code: 200
ポートフォワードの削除
DELETE "/api/port_forwarding"
必要権限: NetworkAdmin
パラメータ: interface, protocol (デフォルト tcp), dport, destination, destination_port
出力: 無し
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/port_forwarding -X DELETE -H "Content-Type: application/json" -d '{"interface":"eth0","protocol":"tcp","dport":"22","destination":"127.0.0.1","destination_port":"2222"}'
http code: 200
10.9.6.12. Rest API : VPN の設定VPN クライアントは、現在 OpenVPN をサポートしています。 -
VPN の設定
POST "/api/vpn/openvpn"
必要権限: VpnAdmin
パラメータ: setting_name, conf, auth_type, username, password, cert, key, key_pass
setting_name: 設定名です。任意の文字列を設定してください。
conf: OpenVPN の設定ファイルです。
auth_type: 認証方式です。userpass(ユーザ名とパスワード) または cert(証明書) を設定してください。
username: auth_type が userpass の場合、ユーザ名を設定します。
password: auth_type が userpass の場合、パスワードを設定します。
cert: auth_type が cert の場合、証明書ファイルを設定します。OpenVPN の設定ファイルに含まれている場合は不要です。
key: auth_type が cert の場合、鍵ファイルを設定します。OpenVPN の設定ファイルに含まれている場合は不要です。
key_pass: 鍵がパスワードで保護されている場合、そのパスワードを設定します。
出力: 無し
| |
|---|
コンテナ内から VPN 設定の Rest API を使う場合、 Armadillo 上に alpine_openvpn コンテナイメージが存在していないと、
正しく設定されません。このコンテナイメージが存在していない場合、先に ABOS Web の Web UI やコンテナ外からの Rest API で
設定を行ってください。一度 alpine_openvpn コンテナイメージがインストールされれば、コンテナ内からも Rest API で設定できます。
alpine_openvpn コンテナイメージは VPN 設定を削除しても残り続けますが、VPN 設定を削除した後に
swupdate でアップデートを行うと削除されますので、その場合は再度 alpine_openvpn コンテナイメージのインストールを行う必要があります。 |
-
VPN の接続
POST "/api/vpn/up"
必要権限: VpnAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/vpn/up
http code: 200 -
VPN の切断
POST "/api/vpn/down"
必要権限: VpnAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/vpn/down
http code: 200 -
VPN 設定の削除
DELETE "/api/vpn/openvpn"
必要権限: VpnAdmin
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/vpn/openvpn
http code: 200 10.9.6.13. Rest API : 時刻の設定-
時刻の状況確認
GET "/api/time/ntp_info"
必要権限: TimeView
パラメータ: 無し
出力: time_now: epoch 形式の現在時刻、ntp_server_ip: 現在同期中のサーバーアドレス。同期されていない場合は「null」となります。
ntp_server_offset: 現在同期中のサーバーとの時刻の遅れ（マイナスの場合は Armadillo がサーバーより早いです）
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/ntp_info
{"ntp_server_ip":"203.0.113.10","ntp_server_offset":"-0.000015824","time_now":1710139558}
http code: 200-
NTP の設定確認
GET "/api/time/ntp_config"
必要権限: TimeView
パラメータ: 無し
出力: servers: 同期する対象、initstepslew: Armadillo 起動時に同期するかどうかの設定
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/ntp_config
{"servers":["pool pool.ntp.org iburst"],"initstepslew":"10 pool.ntp.org"}
http code: 200-
NTP の設定
POST "/api/time/ntp_config"
必要権限: TimeAdmin
パラメータ: servers: 同期する対象、initstepslew: Armadillo 起動時に同期するかどうかの設定。パラメータを送信しない場合は設定されません。
値が空の場合は設定が削除されて、「 default 」の場合は Armadillo Base OS のデフォルトに戻ります。
出力: 取得時と同じ
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/ntp_config -X POST -d "servers=server 203.0.113.10 iburst" -d "servers=server 203.0.113.11 iburst" -d "initstepslew="
{"servers":["server 203.0.113.10 iburst","server 203.0.113.11 iburst"],"initstepslew":null}
http code: 200
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/ntp_config -X POST -d "servers=default&initstepslew=default"
{"servers":["pool pool.ntp.org iburst"],"initstepslew":"10 pool.ntp.org"}
http code: 200-
タイムゾーンの確認
GET "/api/time/timezone"
必要権限: TimeView
パラメータ: 無し
出力: timezone: 使用されているタイムゾーン
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/timezone
{"timezone":"Asia/Tokyo"}
http code: 200-
タイムゾーンの設定
POST "/api/time/timezone"
必要権限: TimeAdmin
パラメータ: timezone: 設定するタイムゾーン
出力: 無し
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/timezone -X POST -d "timezone=Asia/Tokyo"
http code: 200 -
時刻を強制的に設定する
POST "/api/time/set"
必要権限: TimeAdmin
パラメータ: timestamp: epoch 形式の時刻
出力: 無し
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/set -X POST -d "timestamp=$(date +%s)"
http code: 200 10.9.6.14. Rest API : 電源制御
再起動
POST "/api/reboot"
必要権限: Reboot
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/reboot
http code: 200
停止
POST "/api/poweroff"
必要権限: Poweroff
パラメータ: 無し
出力: 無し
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/poweroff
http code: 200
10.9.6.15. Rest API : ABOS Web 制御
リスタート
POST "/api/abosweb/restart"
必要権限: AbosWebRestart
パラメータ: 無し
出力: コネクションリセット。ABOS Web はリスタートする前に一度終了するためコネクションリセットが発生します。
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/abosweb/restart
http code: 000
curl: (52) Empty reply from server
10.9.6.16. Rest API : ユーザー設定とユーザーデータの管理
ユーザー設定とユーザーデータの削除
POST "/api/reset_default"
必要権限: ResetDefault
パラメータ: 無し
出力: abos-ctrl reset-default の出力 (stdout または stderr)、および出力ステータス (exit_code または exit_signal)
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/reset_default
{"stdout":"rm -f /etc/NetworkManager/system-connections/*\n"}
{"stdout":"persist_file -r /etc/NetworkManager/system-connections\n"}
{"stdout":"persist_file -r /etc/dnsmasq.d\n"}
{"stdout":"rc-service dnsmasq restart\n"}
{"stdout":"/etc/init.d/iptables save\n"}
{"stdout":"sed -i -e '/NETAVARK/d' /etc/iptables/rules-save\n"}
{"stdout":"persist_file /etc/iptables/rules-save\n"}
{"stdout":"podman stop -a\n"}
{"stdout":"find /var/app/volumes /var/log -mindepth 1 -delete\n"}
{"stdout":"Starting clone to /dev/mmcblk0p1\n"}
{"stdout":"Cloning rootfs\n"}
{"stdout":"Updating appfs snapshots\n"}
{"stdout":"Reusing up-to-date bootloader\n"}
{"stdout":"Rollback clone successful\n"}
{"stderr":"WARNING: Rebooting!\n"}
{"exit_code":0}
http code: 200
10.9.6.17. Rest API : カスタムスクリプトの実行ユーザが Armadillo に追加したスクリプトを Rest API を使用して実行することができます。
実行したいスクリプトに実行権限を付与し、Armadillo の /etc/atmark/abos_web/customize_rest ディレクトリ下に置いてください。 実行に root 権限が必要なスクリプトの場合は、 以下のように /etc/doas.d/abos_web_customize.conf にスクリプトを追加してください。 [armadillo ~]# cat /etc/doas.d/abos_web_customize.conf
permit nopass abos-web-admin as root cmd /etc/atmark/abos_web/customize_rest/root_command.sh
任意のスクリプト実行
POST "/api/custom/{script}"
必要権限: Custom
パラメータ: args でスクリプトの引数を順番に指定できます。
root を true に設定すると root 権限でスクリプトを実行します。
出力: /etc/atmark/abos_web/customize_rest/{script} {args} {args...} を実行して、
そのスクリプトの出力を stdout/stderr で返します。スクリプトが終了した際の出力ステータスは exit_code または exit_signal (どちらも int) です。
[armadillo ~]# cat /etc/atmark/abos_web/customize_rest/print_args.sh
#!/bin/sh
printf "arg: %s\n" "$@"
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/custom/print_args.sh \
-H 'Content-type: application/json' -d '{"args": ["param", "second arg"], "root":false}'
{"stdout":"arg: param\n"}
{"stdout":"arg: second arg\n"}
{"exit_code":0}
| |
|---|
標準の ABOS Web には最小限の権限しか与えていません。
root 権限でスクリプトを実行する場合、 Armadillo の故障やセキュリティにも関わりますので、十分注意して追加してください。 |
10.9.8. ユーザー設定とユーザーデータの削除カスタマイズと Rest API トークン以外の設定内容と、
ユーザーデータを一括削除することができます。 ユーザーデータの削除では以下のデータを削除します。 -
/var/app/volumes ディレクトリ下のファイルを全て
-
/var/log ディレクトリ下のファイルを全て
ABOS Web のトップページから、「設定管理」ページへ移動し「ユーザー設定とユーザーデータの削除」にある
「削除」ボタンを押すと削除できます。削除後は Armadillo が再起動するので引き続き ABOS Web を使用する場合は、
再起動が完了してからアクセスしてください。 図10.65「ABOS Web を停止する」に ABOS Web のサービスを停止する方法を示します。 |
OpenRC に ABOS Web のサービスが登録されていることを確認します。
| |
ABOS Web のサービスが起動していることを確認します。
| |
ABOS Web のサービスを停止します。
| |
サービスを管理している OpenRC から ABOS Web のサービスの登録を解除します。
| |
サービス設定ファイルの削除を永続化します。
|
ABOS Web を停止すると ABOS Web の Rest API も使用できなくなります。 図10.66「ABOS Web を起動する」に ABOS Web のサービスを起動する方法を示します。 |
OpenRC に ABOS Web のサービスが登録されていないことを確認します。何も出力されなければ登録されていません。
| |
サービスを管理している OpenRC に ABOS Web のサービスを登録します。
| |
ABOS Web のサービスを起動します。
| |
サービス設定ファイルを永続化します。
|
10.9.11. ABOS Web のセキュリティ対策ABOS Web は開発時には便利ですが、運用時にはできることの多さ故に外部からの攻撃面になり得ます。
ここでは、 ABOS Web が具備しているセキュリティ対策機能について紹介します。 10.9.11.1. 同一 LAN 以外からのアクセス禁止「ABOS Web ではできないこと」でも紹介している通り、 ABOS Web は同一 LAN 内からのみ接続でき、それ以外の接続は拒否します。
これによって ABOS Web はインターネット側からの攻撃面となり得ず、攻撃者は同一の LAN 内に侵入してから ABOS Web にアクセスする必要があります。 10.9.11.2. ABOS Web のユーザ認証ABOS Web はユーザ認証としてパスワードによる認証を行います。
初回起動時には必ずパスワードの設定を求められます。
このとき設定するパスワードは8文字以上のものに強制しています。 また、ユーザ認証のブルートフォースアタック対策として、パスワードを間違える等でユーザ認証に失敗した場合に、次回再認証まで2秒間時間を空ける実装になっています。
これによって、機械的に総当りでパスワードを解析するまでの時間が大幅に増大することが見込めます。 ABOS Web の通信は TLS によって暗号化されています。
使用する TLS 証明書は ECDSA (secp384r1) の暗号技術を用いて生成されています。 10.10. ABOSDE から ABOS Web の機能を使用するABOSDE は以下に示す ABOS Web の情報取得や動作を行うことができます。 -
Armadillo の SWU バージョンを取得する
-
Armadillo のコンテナの情報を取得する
-
Armadillo のコンテナを起動・停止する
-
Armadillo のコンテナのログを取得する
-
Armadillo に SWU をインストールする
ABOSDE は ABOS Web の Rest API を用いて通信を行っていますので、ABOS Web にパスワードでログインができる状態である必要があります。
ABOS Web へのログインを行っていない場合は「ABOS Web とは」を参考にしてください。 ABOSDE から ABOS Web の機能を使用するには通信を行う対象の Armadillo を選択する必要があります。
図10.67「ABOSDE で ローカルネットワーク上の Armadillo をスキャンする」 の赤枠で囲まれているボタンをクリックすることで、ローカルネットワーク上で ABOS Web が動作している Armadillo をスキャンすることができます。
ただし、ATDE のネットワークを NAT に設定している場合は Armadillo がリストに表示されません。 ABOSDE から ABOS Web に初めて通信を行う時、ABOS Web は通信に使用するためのトークンを発行します。
そのため、ABOSDE では 図10.68「ABOSDE の ABOS Web パスワード入力画面」 のように ABOS Web のパスワードを求められますので、設定したパスワードを入力してください。 10.10.2. Armadillo のコンテナの情報を取得するローカルネットワーク上の Armadillo をスキャンした後に、
図10.70「ABOSDE で Armadillo のコンテナ情報を取得」 の赤枠で囲まれているボタンをクリックすることで、選択した Armadillo のコンテナの情報を取得できます。
表示されるコンテナの情報は以下の通りとなります。 -
state : コンテナが起動中の場合は running、コンテナが停止中の場合は exited
-
image : コンテナのイメージ名
-
command : コンテナ起動時に実行しているコマンド
10.10.5. Armadillo に SWU をインストールするローカルネットワーク上の Armadillo をスキャンした後に、
図10.74「ABOSDE で Armadillo に SWU をインストール」 の赤枠で囲まれているボタンをクリックすることで、選択した Armadillo に SWU をインストールすることができます。
SWU インストールのログは VS Code 画面下部の OUTPUT に表示されます。 10.11. ssh 経由で Armadillo Base OS にアクセスするArmadillo-900 開発セット にはopensshがインストールされていますが、デフォルトではSSHサーバーが起動していません。 SSHサーバーを自動的に起動するようにするためには、以下のコマンドを実行してください。 [armadillo:~]# rc-update add sshd
* service sshd added to runlevel default
[armadillo ~]# persist_file /etc/runlevels/default/sshd
[armadillo ~]# reboot 上記の例では、再起動後も設定が反映されるように、 persist_file コマンドでeMMCに設定を保存しています。 10.12. 電源を安全に切るタイミングを通知するArmadillo Base OS には、シャットダウン中に電源を切っても安全なタイミングで通知する機能があります。通知は GPIO 出力を用いて行います。
どの GPIO 出力ピンを使うのかを Device Tree で設定します。Device Tree で通知用に設定された GPIO 出力ピンの出力レベルを変化させる動作は、
シャットダウン中に実行される signal_indicator が行います。 Device Tree の設定手順を順に述べます。Device Tree の設定は、DTS overlays を使用して行います。 10.12.1. DTS overlays の設定あらかじめ、CON16(拡張インターフェース)の26番ピンを使用する場合の Device Tree を用意してあります。 その場合は以下の、「CON16(拡張インターフェース)の26番ピンを使用する」 の設定を行ってください。
これ以外のピンを使用する場合はデバイスツリーを記載してビルドする必要があります。 10.12.1.1. CON16(拡張インターフェース)の26番ピンを使用する「DTS overlays によるカスタマイズ」 を参考にして /boot/overlays.txt に armadillo_iotg_a9e-stdwn-ind-con10-pin26.dtbo を追加してください。 ここまで述べた設定を行うと、シャットダウン動作中に通知が行われるようになります。シャットダウン動作の最後の方で、以下のメッセージを出力するのと同じタイミングで通知を行います。
つまり、通知用に割り当てた GPIO 出力ピンの出力レベルが、0/Low から 1/High に変わります。
シャットダウンが完了して SoC (CPU) への給電がオフすると、出力レベルが 0/Low に戻ります。
出力レベルが 0/Low から 1/High に変化した時点以降であれば、Armadillo の電源を切っても安全です。 10.13. Armadillo Base OS をアップデートするArmadillo Base OS は SWUpdate によってアップデートすることができます。 アップデートする際には、rootfs ファイルシステムにインストールされたファイルをすべて消して、アップデートの中身と /etc/swupdate_preserve_files に記載されているファイルで新しい rootfs を作ります。「swupdate_preserve_files について」 を参照してください。 アップデートでファイルを削除してしまった場合に abos-ctrl mount-old で前のシステムを read-only でマウントして、
削除されたファイルをコピーすることもできます。 Armadillo Base OS のルートファイルシステムが破損し起動できなくなった場合、自動的に以前のバージョンで再起動します。 abos-ctrl status コマンドでロールバックされてるかどうかを確認できます。
表10.7 rollback-status の出力と意味 | 出力 | 説明 |
|---|
OK
| ロールバックされていません。 | rolled back
| ロールバックされています。 |
表10.8 rollback-status 追加情報の出力と意味 | 出力 | 説明 |
|---|
no fallback (fresh install)
| 初期化状態。 | no fallback
| 何かの理由でB面が起動できない状態になっています（アップデート失敗後等）。 | auto-rollback enabled (post-update)
| アップデート直後でまだ再起動していない状態です。再起動して失敗した場合にロールバックが発生します。 | auto-rollback enabled (cloned)
| abos-ctrl rollback-clone コマンドを実行した後の状態です。同じくロールバック可能です。
| available, no auto-rollback
| アップデートの後に正常に起動できたので、自動ロールバックが無効になっていますが abos-ctrl rollback --allow-downgrade コマンドで手動ロールバック可能です。 |
| |
|---|
Armadillo Base OS 3.19.1-at.4 以下のバージョンでは「アップデート直後」の概念がなかったため、ステータスは「no fallback」（B面がない状態）、
「optimal」（ロールバック可能）、と「rolled back」の3択だけでした。 |
必要な場合（例えば、自分のアプリケーションがアップデート直後に問題があった場合）、 abos-ctrl rollback で手動のロールバックも可能です。ロールバックにエラーがなければ、再起動してロールバックを完了します。 なお、/var/at-log/atlog に切り替えの際に必ずログを書きますので、調査の時に使ってください。
以下の例では、Armadillo Base OS を更新した後に起動できないカーネルをインストールして、起動できなかったためにロールバックされました。 10.15. Armadillo 起動時にコンテナの外でスクリプトを実行する起動時に何かスクリプトを走らせるためにはコンテナとして実行することを推奨します。 「コンテナ起動設定ファイルを作成する」 を参照してください。 コンテナで実行不可能な場合に、「local」サービスを使うことができます: /etc/local.d ディレクトリに
.start ファイルを置いておくと起動時に実行されて、 .stop ファイルは終了時に実行されます。 |
スクリプトを作ります。
| |
スクリプトを実行可能にします。
| |
スクリプトを保存して、再起動します。
| |
実行されたことを確認します。
|
USB コンソールインターフェース 上で "t" キー以外のキーを押したまま電源を接続すると U-Boot のプロンプトが表示されます。
何もキーを押していなければ自動的に Linux カーネルが起動します。 U-Boot SPL 2023.04-at3 (Apr 14 2025 - 05:58:59 +0000)
Normal Boot
ELE firmware version 1.0.0-344acb84
: (省略)
U-Boot 2023.04-at3 (Apr 14 2025 - 05:58:59 +0000)
M33 Sync: OK
CPU: i.MX8ULP(Dual 5) rev1.2 at 800MHz
CPU current temperature: 26
Reset cause: POR
Boot mode: Single boot
Model: Atmark-Techno Armadillo-900
DRAM: Hold key pressed for tests: t (fast) / T (slow)
992 MiB
Disabled RTC alarm
Core: 51 devices, 23 uclasses, devicetree: separate
MMC: FSL_SDHC: 0, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
SEC0: RNG instantiated
switch to partitions #0, OK
mmc0(part 0) is current device
flash target is MMC:0
Net: eth0: ethernet@29950000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
=> u-boot の環境変数を変更するには /boot/uboot_env.d/ ディレクトリに環境変数が書かれた設定ファイルを配置します。 ファイルの構文は fw_setenv が扱うことができるもので、以下のとおりです： -
# で始まる行はコメントと扱われる為、無視されます。また、 環境変数への代入を示す = がない場合も無視されます。
-
[変数]=[値] で変数を設定します。スペースや引用符を含め他の文字は有効ですので、変数の名前と値に不要な文字を入れないように注意してください。
-
[変数]= で変数を消します。値がない場合に変数が消去されます。
このファイルによるアップデート内容は swupdate でアップデートする際に適用されます。 実行中のシステムに影響がありませんので、設定ファイルを swupdate で転送しない場合はファイル永続化後に fw_setenv -s /boot/uboot_env.d/[ファイル名] で変数を書き込んでください。 swupdate でファイルを転送した場合には、変数はすぐに利用されます。 |
コンフィグファイルを生成します。
| |
ファイルを永続化します。
| |
変数を書き込みます。
| |
書き込んだ変数を確認します。
|
| |
|---|
mkswu バージョン 4.4 以降が必要です。必要な場合はアップデートしてください。 [ATDE ~]$ sudo apt update && sudo apt upgrade 書き方は、 /usr/share/mkswu/examples/uboot_env.desc を参考にしてください。 |
| |
|---|
「ブートローダーをビルドする」 の際に u-boot のデフォルトを変更した場合や、u-boot のプロンプトで「setenv」や「saveenv」を実行しても、 /boot/uboot_env.d/00_defaults によって変更がアップデートの際にリセットされます。 00_defaults のファイルは Base OS の一部で更新されることもありますので、変更を望む場合は別のファイルを作って設定してください。
ファイルはアルファベット順で処理されます。 00_defaults にある変数を後のファイルにも設定した場合はそのファイルの値だけが残ります。
|
主要なu-bootの環境変数を以下に示します。 表10.9 u-bootの主要な環境変数 | 環境変数 | 説明 | デフォルト値 |
|---|
console | コンソールのデバイスノードと、UARTのボーレート等を指定します。 | ttyLP0,115200 | bootcount | 起動回数を示します。初回起動時に1となり、起動に失敗する度にインクリメントされます。ユーザーランドのreset_bootcountサービスが起動されると、この値はクリアされます。この値が"bootlimit"を越えた場合はロールバックします。ロールバックの詳細については、「ロールバック(リカバリー)」を参照してください。 | 1 | bootlimit | "bootcount"のロールバックを行うしきい値を指定します。 | 3 | upgrade_available | 1以上の場合は bootcount を管理してロールバック可能になります。0 か空の場合はロールバックできません。値を abos-ctrl status で確認できます。 | 状況による | bootdelay | 保守モードに遷移するためのキー入力を待つ時間を指定します(単位:秒)。次の値は特別な意味を持ちます。
-
-1: キー入力の有無に関らず保守モードに遷移します。
-
-2: キー入力の有無に関らず保守モードに遷移しません。
| 2 | image | Linuxカーネルイメージファイルのパスです。"mmcdev"で指定されたデバイスの、"mmcpart"で指定されたパーティションのルートディレクトリからの相対パスで指定します。 | boot/Image | fdt_file | DTBファイルのパスです。"mmcdev"で指定されたデバイスの、"mmcpart"で指定されたパーティションのルートディレクトリからの相対パスで指定します。 | boot/armadillo.dtb | overlays_list | DT overlayの設定ファイルのパスです。"mmcdev"で指定されたデバイスの、"mmcpart"で指定されたパーティションのルートディレクトリからの相対パスで指定します。DT overlayの詳細については、「DTS overlays によるカスタマイズ」を参照してください。 | boot/overlays.txt | mmcautodetect | mmcデバイスの自動検出機能の有効/無効を指定します。yesを指定した場合のみ、u-bootが起動されたmmcデバイスが自動的にmmcdevとして利用されます。 | yes | mmcdev | "image"や"fdt_file"で指定されたファイルが配置してあるmmcデバイスのインデックスを指定します。インデックスとmmcデバイスの対応は次の通りです。
-
0: eMMC
-
1: microSD/microSDHC/microSDXC カード
"mmcautodetect"にyesが指定されている場合は、u-bootの起動時に上書きされます。 | 0 | mmcpart | "image"や"fdt_file"で指定されたファイルが配置してある、"mmcdev"で指定されたmmcデバイスのパーティション番号を指定します。"mmcautodetect"にyesが指定されている場合は、u-bootの起動時に上書きされます。 | 1 | mmcroot | ルートファイルシステムが配置されているデバイスノードと、マウントオプションを指定します。"mmcautodetect"にyesが指定されている場合は、u-bootの起動時に上書きされます。overlayfsが正しく機能しなくなる場合があるので、roの指定は変更しないでください。 | /dev/mmcblk0p1 rootwait ro | optargs | Linuxカーネル起動時パラメータを指定します。"quiet"を削除すると、コンソールに起動ログが出力されるようになりますが、起動時間が長くなります。 | quiet | loadaddr | LinuxカーネルがRAMにロードされる物理アドレスを指定します。 | 0x80400000 | fdt_addr | DTBがRAMにロードされる物理アドレスを指定します。 | 0x83000000 | overlay_addr | DT overlayのワーク領域として利用されるRAMの物理アドレスを指定します。 | 0x83040000 |
10.16.1.1. u-boot の環境変数の変更を制限するCONFIG_ENV_WRITEABLE_LIST=y を追加すると、変更可能と明示したもの以外の環境変数を変更不可にすることができます。
CFG_ENV_FLAGS_LIST_STATIC で設定します。 デフォルトのコンフィグでは、以下の環境変数が変更可能です： -
upgrade_available と bootcount: ロールバック機能に必要な変数です。ロールバック機能を無効に
する場合は必ず upgrade_available のデフォルト値も空にしてください。
u-boot のソースの取得方法、ビルド方法およびインストール方法については 「ブートローダーをビルドする」 を参照してください。
ビルドしたものをインストールすると CFG_ENV_FLAGS_LIST_STATIC で設定した環境変数以外は変更できなくなります。 本章では、microSD カードから直接起動(以降「SDブート」と表記します)する手順を示します。
SD ブートを活用すると、microSD カードを取り替えることでシステムイメージを変更することができます。
本章に示す手順を実行するためには、容量が 8Gbyte 以上の microSD カードを必要とします。 | |
|---|
SD ブートを行った場合、ブートローダーの設定は microSDカード に保存されます。 |
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a900 \
--boot ~/imx-boot-[VERSION]/imx-boot_armadillo-900
: (省略)
[ATDE ~/build-rootfs-[VERSION]]$ ls baseos-900*img
baseos-900-[VERSION].img
ブートディスクイメージの書き込み
ブートディスクイメージの書き込みは「初期化インストールディスクの作成」を参照してください。
参照先では初期化インストールディスクの場合の手順を示していますが、ここでビルドしたイメージについても同じ手順になります。
| |
|---|
microSDカードのパーティション構成は次のようになっています。 表10.10 microSDカードのパーティション構成 | パーティション | オフセット | サイズ | 説明 |
|---|
- | 0 | 10MiB | ブートローダー | 1 | 10MiB | 300MiB | A/B アップデートのA面パーティション | 2 | 310MiB | 300MiB | A/B アップデートのB面パーティション | 3 | 610MiB | 50MiB | ログ用パーティション | 4 | 660MiB | 100MiB | ファームウェア | 10 | 710MiB | 50MiB | セキュアブート用のA面パーティション[] | 11 | 760MiB | 50MiB | セキュアブート用のB面パーティション[] | 5 | 860MiB | 残り | アプリケーション用パーティション |
gdiskで確認すると次のようになります。 [ATDE ~]$ sudo gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.6
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 60506112 sectors, 28.9 GiB
Model:
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 44B816AC-8E38-4B71-8A96-308F503238E3
Partition table holds up to 128 entries
Main partition table begins at sector 20448 and ends at sector 20479
First usable sector is 20480, last usable sector is 60485632
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector) End (sector) Size Code Name
1 20480 634879 300.0 MiB 8300 rootfs_0
2 634880 1249279 300.0 MiB 8300 rootfs_1
3 1249280 1351679 50.0 MiB 8300 logs
4 1351680 1761279 200.0 MiB 8300 firm
5 1761280 60485632 28.0 GiB 8300 app |
「ブートディスクの作成」で作成したブートディスクから起動する方法を説明します。 -
Armadillo-900 開発セットに電源を投入する前に、ブートディスクをCON1(SD インターフェース)に挿入します。
また、SW4 を 起動デバイスは microSD 側設定します。SW4 に関しては、図5.153「スイッチの状態と起動デバイス」 を参照ください。
電源を投入します。
U-Boot 2023.04-at1 (Apr 01 2025 - 03:59:06 +0000)
M33 Sync: OK
CPU: i.MX8ULP(Dual 5) rev1.2 at 800MHz
CPU current temperature: 29
Reset cause: POR
Boot mode: Single boot
Model: Atmark-Techno Armadillo-900
DRAM: Hold key pressed for tests: t (fast) / T (slow)
992 MiB
Core: 51 devices, 23 uclasses, devicetree: separate
MMC: FSL_SDHC: 0, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
SEC0: RNG instantiated
switch to partitions #0, OK
mmc2 is current device
flash target is MMC:2
Net: eth0: ethernet@29950000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc2 is current device
Failed to load 'boot/boot.scr'
23122432 bytes read in 2942 ms (7.5 MiB/s)
Booting from mmc ...
40248 bytes read in 45 ms (873 KiB/s)
Loading fdt boot/armadillo.dtb
Working FDT set to 83000000
...中略...
Welcome to Alpine Linux 3.21
Kernel 5.10.235-1-at on an aarch64 (/dev/ttyLP0)
armadillo login:
10.18. Device Treeをカスタマイズする10.18.1. DTS overlays によるカスタマイズDevice Treeは「DTS overlay」(dtbo) を使用することで変更できます。 DTS overlay を使用することで、通常の dts の更新が自動的に入りつづける状態で
dts の変更でしかできない設定を行うことができます。 /boot/overlays.txt に fdt_overlays を dtbo 名で設定することで、
u-bootが起動時にその DTS overlay を通常の dtb と結合して起動します。
複数の DTS overlay を使う場合は以下の例のようにスペースで別けたファイル名を記載することができます。 |
/boot ディレクトリに保存されている dtbo ファイルを確認します。
| |
/boot/overlays.txt ファイルに使用したい dtbo ファイルを追加します。
ファイルが存在しない場合は新規に作成してください。
このファイルの詳細については 「DTS overlays によるカスタマイズ」 を参照してください。
| |
/boot/overlays.txt を保存し、アップデートの場合でも保存します。
| |
overlay の実行のために再起動します。
| |
シリアルコンソールの場合に、u-bootによるメッセージを確認できます。
|
10.18.1.1. 提供している DTS overlay以下の DTS overlay を用意しています： -
armadillo_900-evaboard.dtbo: 自動的に使用します。
-
armadillo_iotg_a9e-sim7672.dtbo: LTE Cat.1 bis モジュールに関する dtbo です。自動的に使用します。
-
armadillo_iotg_a9e-lbes5pl2el.dtbo: WLAN+BT+TH コンボモジュールに関する dtbo です。自動的に使用します。
-
armadillo_iotg_a9e-stdwn-ind-con10-pin26.dtbo: /boot/overlays.txt に記載することで使用できます。使用方法は「電源を安全に切るタイミングを通知する」を参照ください。
-
armadillo_900-evaboard-con10-waveshare4-3-inch-dsi.dtbo: Raspberry Pi用 4.3インチ タッチスクリーン液晶用の dtbo です。/boot/overlays.txt に記載することで使用できます。
-
armadillo_900-evaboard-con9-ox01f10.dtbo: KBCR-S08MM用の dtbo です。/boot/overlays.txt に記載することで使用できます。
10.18.2. 独自の DTS overlay を追加する標準イメージで提供している DTS overlay では不十分な場合に、独自の DTS overlay を作成し Armadillo へ適用する手順を示します。
「Linux カーネルをビルドする」 を参照の上、最新版カーネルのビルドまで実施してください。
以下、ATDE のホームディレクトリに linux-[VERSION] ディレクトリができている前提で進めます。
カスタマイズ用に用意している arch/arm64/boot/dts/freescale/armadillo_900-customize.dts を編集します。
編集したファイルをビルドします。
ビルドしてできた armadillo_900-customize.dtbo を Armadillo の /boot/ に配置します。
配置した dtbo を永続化します。
このとき、配置した dtbo が SWUpdate 時に消去されてしまわないように、 -p オプションを付与して dtbo を swupdate_preserve_files に追記させます。
/boot/overlays.txt に armadillo_900-customize.dtbo を追記し、/boot/overlays.txt を永続化します。
|
すでに別の dtbo ファイルが記載されている場合、スペースを挿入して後ろに追加してください。
|
-
Armadillo を再起動し、動作確認をします。
10.19. Armadilloのソフトウェアをビルドするここでは、Armadillo-900 開発セット で使用するソフトウェアのビルド方法を説明します。 ここでは、ATDE 上で Armadillo-900 開発セット 向けのブートローダーイメージをビルドする方法を説明します。
ブートローダーのビルドに必要なパッケージのインストール
次のコマンドを実行します。 [ATDE ~]$ sudo apt install build-essential git wget crossbuild-essental-arm64 bison flex zlib1g-dev python3-pycryptodome python3-pyelftools python3-cryptography device-tree-compiler
ソースコードの取得
Armadillo-900 開発セット ブートローダー から
「ブートローダー ソース」ファイル (imx-boot-[VERSION].tar.zst) を次のようにダウンロードします。 [ATDE ~]$ wget https://download.atmark-techno.com/armadillo-900/bootloader/imx-boot-[VERSION].tar.zst
[ATDE ~]$ tar xf imx-boot-[VERSION].tar.zst
[ATDE ~]$ cd imx-boot-[VERSION]
ビルド
次のコマンドを実行します。 [ATDE ~/imx-boot-[VERSION]]$ make imx-boot_armadillo-900
:
: (省略)
:
Note: Please copy image to offset: IVT_OFFSET + IMAGE_OFFSET
cp flash.bin boot-spl-container.img
append u-boot-atf-container.img at 289 KB
3079+0 レコード入力
3079+0 レコード出力
3152896 bytes (3.2 MB, 3.0 MiB) copied, 0.00455921 s, 692 MB/s
make[1]: ディレクトリ '/home/atmark/imx-boot-[VERSION]/imx-mkimage/armadillo-900' から出ます
cp imx-mkimage/armadillo-900/flash.bin imx-boot_armadillo-900 初めてのビルドの場合、i.MX 8ULP に必要なファームウェアの EULA
への同意を求められます。
内容を確認の上、同意してご利用ください。[] Welcome to NXP firmware-upower-1.3.0.bin
You need to read and accept the EULA before you can continue.
LA_OPT_NXP_Software_License v45 May 2023
:
: (省略)
:
Do you accept the EULA you just read? (y/N) | m33-firmware-at ビルド状態の確認 |
|---|
imx-boot のソースアーカイブにはビルド済みの M33 ファームウェアは含まれていますので、
変更しない場合はビルド不要です。
ビルドが必要な場合は gcc-arm-none-eabi パッケージをインストールすると自動的にビルドされます。
詳細は 「RTOS ファームウェアの開発」 を参照ください。 [ATDE ~/imx-boot-[VERSION]]$ make
: (省略)
Not rebuilding m33-firmware-at.bin without arm-none-eabi-gcc
: (省略)
[ATDE ~/imx-boot-[VERSION]]$ sudo apt install gcc-arm-none-eabi
[ATDE ~/imx-boot-[VERSION]]$ make
: (省略)
[ 3%] Linking C executable release/m33-firmware-at.elf
Memory region Used Size Region Size %age Used
m_interrupts: 792 B 800 B 99.00%
m_text: 95608 B 253152 B 37.77%
m_m33_suspend_ram: 0 GB 16 KB 0.00%
m_a35_suspend_ram: 0 GB 16 KB 0.00%
m_data: 61336 B 160 KB 37.44%
m_ncache: 0 GB 32 KB 0.00%
make[3]: Leaving directory '/home/atmark/imx-boot-[VERSION]/m33_firmware_at/armgcc'
[100%] Built target m33-firmware-at.elf
make[2]: Leaving directory '/home/atmark/imx-boot-[VERSION]/m33_firmware_at/armgcc'
make[1]: Leaving directory '/home/atmark/imx-boot-[VERSION]/m33_firmware_at/armgcc'
cp m33_firmware_at/m33-firmware-at.bin imx-mkimage/armadillo-900/m33_image.bin
: (省略) |
ビルドされなかった場合の出力
| |
パッケージのインストールコマンド
| |
ビルドされた場合の出力
|
|
インストール
ビルドしたブートローダーは、以下に示すどちらかの方法でインストールしてください。
swupdate でインストールする
mkswu の初期化を行った後に 提供されているスクリプトを使ってSWUイメージを作成してください。 [ATDE ~/imx-boot-[VERSION]]$ echo 'swdesc_boot imx-boot_armadillo-900' > boot.desc
[ATDE ~/imx-boot-[VERSION]]$ mkswu boot.desc
boot.swu を作成しました。 作成された boot.swu のインストールについては 「SWU イメージのインストール」 を参照ください。
「ブートディスクの作成」 でインストールする
手順を参考にして、ビルドされた imx-boot_armadillo-{product-image-name} を使ってください。
10.19.2. Linux カーネルをビルドするここでは、Armadillo-900 開発セット 向けのLinuxカーネルイメージをビルドする方法を説明します。 | |
|---|
Armadillo-900 開発セットでは、基本的にはLinuxカーネルイメージをビルドする必要はありません。
「Alpine Linux ルートファイルシステムをビルドする」の手順を実施することで、標準のLinuxカーネルイメージがルートファイルシステムに組み込まれます。 標準のLinuxカーネルイメージは、アットマークテクノが提供する linux-at というAlpine Linux用のパッケージに含まれています。 カスタマイズしたLinuxカーネルイメージを利用する場合は、
以下に示す手順を参照してください。 |
ソースコードの取得
Armadillo-900 開発セット Linuxカーネル から
「Linuxカーネル」ファイル (linux-at-a9-[VERSION].tar) をダウンロードして、次のコマンドを実行します。 [ATDE ~]$ tar xf linux-at-a9-[VERSION].tar
[ATDE ~]$ tar xf linux-at-a9-[VERSION]/linux-[VERSION].tar.gz
[ATDE ~]$ cd linux-[VERSION]
デフォルトコンフィギュレーションの適用
次のコマンドを実行します。 [ATDE ~/linux-[VERSION]]$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- armadillo_a9_defconfig
Linux カーネルコンフィギュレーションの変更
コンフィギュレーションの変更を行わない場合はこの手順は不要です。
変更する際は、図10.86「Linux カーネルコンフィギュレーションの変更」に示すコマンドを実行します。
コマンドを実行するとカーネルコンフィギュレーション設定画面が表示されます。
カーネルコンフィギュレーションを変更後、"Exit"を選択して「Do you wish to save your new kernel configuration? (Press <ESC><ESC> to continue kernel configuration.)」で "Yes" を選択し、 カーネルコンフィギュレーションを確定します。
| |
|---|
Linux Kernel Configuration メニューで"/"キーを押下すると、カーネルコンフィギュレーションの検索を行うことができます。
カーネルコンフィギュレーションのシンボル名(の一部)を入力して"Ok"を選択すると、部分一致するシンボル名を持つカーネルコンフィギュレーションの情報が一覧されます。 |
ビルド
次のコマンドを実行します。 [ATDE ~/linux-[VERSION]]$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j5
インストール
ビルドしたカーネルは、以下に示すどちらかの方法でインストールしてください。
swupdate でインストールする
mkswu の初期化を行った後に 提供されているスクリプトを使ってSWUイメージを作成してください。
作成された kernel.swu のインストールについては 「SWU イメージのインストール」 を参照ください。
build_rootfs で新しいルートファイルシステムをビルドする場合は build_rootfs を展開した後に以下のコマンドでインストールしてください。
|
build_rootfs のディレクトリ名を設定します。これによって、長いディレクトリ名を何度も入力する必要が無くなります。
| |
アットマークテクノが提供するカーネルをインストールしない様に、 linux-at-a9@atmark と記載された行を削除します。
| |
別のカーネルをすでにインストールしている場合は、新しいモジュールをインストールする前に古いモジュールを削除する必要があります。
|
10.19.3. Alpine Linux ルートファイルシステムをビルドするここでは、build-rootfs を使って、 Alpine Linux ルートファイルシステムを構築する方法を説明します。 build-rootfs は、ATDE 上で Armadillo-900 開発セット 用の Alpine Linux ルートファイルシステムを構築することができるツールです。
ルートファイルシステムのビルドに必要な Podman のインストール
次のコマンドを実行します。 [ATDE ~]$ sudo apt install podman btrfs-progs xxhash
build-rootfs の入手
{Armadillo-900 開発用ツール から 「Alpine Linuxルートファイルシステムビルドツール」 ファイル (build-rootfs-[VERSION].tar.gz) を次のようにダウンロードします。 [ATDE ~/]$ wget https://download.atmark-techno.com/armadillo-900/tool/build-rootfs-latest.tar.gz
[ATDE ~/]$ tar xf build-rootfs-latest.tar.gz
[ATDE ~/]$ cd build-rootfs-[VERSION]
Alpine Linux ルートファイルシステムの変更
a900ディレクトリ以下のファイルを変更することで、
ルートファイルシステムをカスタマイズすることができます。 | |
|---|
commonとa900 ディレクトリ直下にあるfixupやpackagesなどの同名ファイルは、それぞれのファイルを連結して利用されます。パッケージの削除などを行う場合は、commonディレクトリ以下のファイルも確認してください。 commonとa900内のサブディレクトリにある同名ファイルは、a900のファイルが利用されます。 |
build-rootfsに含まれるファイルの説明は次の通りです。 表10.11 build-rootfsのファイル説明 | ファイル | 説明 |
|---|
a900/resources/* | 配置したファイルやディレクトリは、そのままルートファイルシステム直下にコピーされます。
ファイルを追加する場合は、このディレクトリに入れてください。 | a900/packages | このファイルに記載されているパッケージはルートファイルシステムにインストールされます。
パッケージを追加する場合はこのファイルに追加してください。 | a900/fixup | このファイルに記載されているコマンドはパッケージのインストールが完了した後に実行されます。 | a900/image_firstboot/* | 配置したファイルやディレクトリは、「ブートディスクの作成」や「インストールディスクの作成」の手順
のようにブートディスクイメージを作成する際、そのままルートファイルシステム直下にコピーされます。 | a900/image_installer/* | 配置したファイルやディレクトリは、「インストールディスクの作成」の手順
のようにインストールディスクイメージを作成する際、
そのままインストーラーにコピーされます。ルートファイルシステムに影響はありません。 | a900/image_common/* | 配置したファイルやディレクトリは、ブートディスクイメージおよびインストールディスクイメージを
作成する際、ルートファイルシステム、インストーラにそれぞれコピーされます。 |
| |
|---|
利用可能なパッケージは以下のページで検索することができます。 Alpine Linuxルートファイルシステムを起動している
Armadilloでも検索することができます。 [armadillo ~]# apk update
[armadillo ~]# apk search ruby
grpc-plugins-1.62.1-r2
jruby-9.3.13.0-r0
jruby-irb-9.3.13.0-r0
:
: (省略)
:
unit-ruby-1.34.1-r0
xapian-bindings-ruby-1.4.26-r0 |
ビルド
次のコマンドを実行します。 パッケージをインターネット上から取得するため回線速度に依存しますが、ビルドには数分かかります。 [ATDE ~/build-rootfs-[VERSION]]$ ./build_rootfs.sh -b a900
use default(outdir=/home/atmark/work/build-rootfs-v3.21-at.1)
use default(output=baseos-900-ATVERSION.tar.zst)
:
: (略)
:
INFO:root:Building SBOM...
INFO:root:created baseos-900-3.21.3-at.1.20250226.tar.zst.spdx.json
Successfully built /home/atmark/work/build-rootfs-v3.21-at.1/baseos-900-3.21.3-at.1.20250226.tar.zst | |
|---|
リリース時にバージョンに日付を含めたくないときは --release を引数に追加してください。 |
| |
|---|
任意のパス、ファイル名で結果を出力することもできます。 [ATDE ~/build-rootfs-[VERSION]]$ ./build_rootfs.sh -b a900 ~/alpine.tar.zst
:
: (略)
:
[ATDE ~/build-rootfs-[VERSION]]$ ls ~/alpine.tar.zst
~/alpine.tar.zst |
「Alpine Linux ルートファイルシステムビルドツール」のバージョンが3.18-at.7以降を使用している場合は、ビルドが終わると SBOM も [output].spdx.json として出力されます。
ライセンス情報等を記載するためのコンフィグファイルはデフォルトは baseos_sbom.yaml となっています。コンフィグファイルを変更する場合は --sbom-config <config> に引数を入れてください。
SBOM が不要な場合は --nosbom を引数に追加してください。 SBOM のライセンス情報やコンフィグファイルの設定方法については 「ビルドしたルートファイルシステムの SBOM を作成する」 をご覧ください。
インストール
ビルドしたルートファイルシステムは、以下に示すどちらかの方法でインストールしてください。
「SWU イメージのインストール」 でインストールする
mkswu の初期化を行った後に 提供されているスクリプトを使ってSWUイメージを作成してください。 [ATDE ~/build-rootfs-[VERSION]]$ vi OS_update.desc
swdesc_tar --version base_os [VERSION] \
--preserve-attributes baseos-900-[VERSION].tar.zst
[ATDE ~/build-rootfs-[VERSION]]$ mkswu OS_update.desc
OS_update.swu を作成しました。作成された OS_update.swu のインストールについては 「SWU イメージのインストール」 を参照ください。
「ブートディスクの作成」 でインストールする
手順を実行すると、ビルドされた baseos-{product-image-name}-[VERSION].tar.zst が自動的に利用されます。
| |
|---|
アットマークテクノがリリースするファームウェアはバージョンのサフィックスとして"-at.[数字]"を含めています。
オリジナルのサフィックスをつける場合は、"-at.[数字]"を使用しないことを強く推奨します。 |
アットマークテクノでは ABOS 及び ABOS 上で動作する標準ソフトウェアの SBOM を提供しています。
また、開発したソフトウェアの SWU イメージを作成するタイミングで SBOM を生成することができます。
SBOM 生成手順は 「ビルドしたルートファイルシステムの SBOM を作成する」 もしくは 「SWU イメージと同時に SBOM を作成する」 を参照ください。 SBOM（Software Bill of Materials: ソフトウェア部品表) は、
ソフトウェアを構成するコンポーネントやソフトウェア間の依存関係、ライセンス情報を記したリストです。
経済産業省は、ソフトウェアサプライチェーンが複雑化する中で、
急激に脅威が増しているソフトウェアのセキュリティを確保するための管理手法の一つとして SBOM の導入を推進しています。
SBOM の導入はソフトウェアのトレーサビリティを確保し、脆弱性残留リスクの低減、脆弱性対応期間の低減に繋がります。
アットマークテクノが提供する SBOM は
ISO/IEC5962で国際標準となっているSPDX2.2のフォーマットに準拠しています。 SPDX2.2 の詳細については以下のドキュメントをご参照ください。 The Software Package Data Exchange® (SPDX®) Specification Version 2.2.2 アットマークテクノの提供する mkswu コマンドでは SWU を作成するタイミングで SBOM を生成することができます。 SBOM の利点はソフトウェアのサプライチェーン攻撃への対応です。
ソフトウェアのセキュリティ対策は日々見直されており、
トレーサビリティが明らかになることで、ソフトウェアに含まれる脆弱性に速やかに対処することが可能になります。
SBOM はトレーサビリティを辿るのに優れており、加えて、脆弱性スキャンツールを用いることで、
表面化していない脆弱性の発見に利用できます。
脆弱性スキャンツールには例として、Google が提供する osv-scanner が挙げられます。
脆弱性に関する詳細なリンクや、脆弱性の深刻度を示す CVSS(Common Vulnerability Scoring System) を出力します。
アットマークテクノが提供する SBOM は osv-scanner のスキャンに対応しています。 osv-scanner を用いた SBOM のスキャンについては「生成した SBOM をスキャンする」をご参照ください。 アットマークテクノが提供している ABOS は
GPLv3（GNU General Public License 第3版）のソフトウェアを含まない構成で提供しています。
OSS（オープンソース・ソフトウェア）利用者に広く普及しているGPLv3は、
インストール用情報の開示義務、関連する特許ライセンスの許諾について定める条項が含まれ、
組み込み機器に適用する際の妨げになる場合があります。
SBOM にはパッケージのライセンス情報が含まれているため、GPLv3 ライセンスが含まれているかどうかの検出を可能にします。 10.20.3. ビルドしたルートファイルシステムの SBOM を作成する「Alpine Linux ルートファイルシステムをビルドする」 を実行すると、OS_update.swu と同じ場所に SBOM を作成します。
SBOM を作成するには、作成する対象のファイルとライセンス情報等を記載するためのコンフィグファイルが必要となります。
また、baseos-900-[VERSION].tar.zst から、アーカイブに含まれるパッケージ情報やファイル情報を SBOM に記載します。 ライセンス情報等を記載するためのコンフィグファイルの例は以下のコマンドで確認することができます。
各項目に関する説明はコメントに記載しておりますので、必要に応じて値を変更してください。
各項目の詳細な説明については SPDX specification v2.2.2 (https://spdx.github.io/spdx-spec/v2.2.2/) をご覧ください。 [ATDE ~/build-rootfs-[VERSION]]$ cat submodules/make-sbom/config.yaml 作成したコンフィグファイルと、baseos-900-[VERSION].tar.zst から OS_update.swu の SBOM を作成します。 [ATDE ~/build-rootfs-[VERSION]]$ ./build_sbom.sh -i OS_update.swu -c <コンフィグファイル> -f baseos-900-[VERSION].tar.zst
INFO:root:created OS_update.swu.spdx.json 作成される SBOM は OS_update.swu.spdx.json になります。
json 形式で ISO/IEC5962で国際標準となっているSPDX2.2のフォーマットに準拠しています。 アットマークテクノが提供しているソフトウェアの SBOM は
ソフトウェアダウンロード
の各ソフトウェアダウンロードページからダウンロードすることができます。 10.20.4. SWU イメージと同時に SBOM を作成する「SWUイメージの作成」 の実行時に SBOM を作成する方法について説明します。
SWU イメージは desc ファイルから作成されます。この desc ファイルに SBOM 作成に必要な情報についても記載します。 10.20.4.1. コンフィグファイルを作成するSBOM を作成するには、作成する対象のファイルとライセンス情報等を記載するためのコンフィグファイルが必要となります。
コンフィグファイルについて指定がない場合はデフォルトのコンフィグファイルで SBOM を作成します。
デフォルトのコンフィグファイルは /usr/share/make-sbom/config/config.yaml にあります。
このファイルは SBOM 作成ツールによって配置されます。
コンフィグファイルを編集するために、例としてカレントディレクトリにコピーします。
リリース時には正しいコンフィグファイルの内容を記載してください。 [ATDE ~]$ cp /usr/share/make-sbom/config/config.yaml .
[ATDE ~]$ vi config.yaml ライセンス情報等を記載するためのコンフィグファイルの例は以下のコマンドで確認することができます。
各項目に関する説明はコメントに記載しておりますので、必要に応じて値を変更してください。
各項目の詳細な説明については SPDX specification v2.2.2 (https://spdx.github.io/spdx-spec/v2.2.2/) をご覧ください。 「desc ファイルを編集する」 で desc ファイルに編集したコンフィグファイルのパスを指定します。 10.20.4.2. desc ファイルを編集するSBOM 作成のために、desc ファイルに記載する項目を以下に示します。 表10.12 descファイルの設定項目 | 項目 | 設定値 | 説明 |
|---|
swdesc_option BUILD_SBOM=<mode> | auto(デフォルト): SBOM 作成ツールがある場合作成する | SBOM を作成するかどうか。記載がない場合は auto が選択される | yes: SBOMを作成する。SBOM 作成ツールがない場合はエラーする | no: SBOM を作成しない | swdesc_option sbom_config_yaml=<path> | ファイルパス | コンフィグファイルのパスを指定する。記載がない場合はデフォルトのコンフィグファイルを使用する | swdesc_sbom_source_file <path> | ファイルパス | SBOM に含めるファイルを指定する。記載がない場合は SBOM に含まれない |
以下に desc ファイルの記載例について示します。 |
SBOM を作成するように設定します。例として必ず作成するように "yes" を指定します。
| |
コンフィグファイルのパスを設定します。例としてカレントディレクトリにある config.yaml を指定します。
| |
SBOM に含めたいファイルがある場合に指定します。例として manifest.json を指定します。
|
desc ファイルの作成が出来たら 「SWUイメージの作成」 を実行すると、SWU イメージと同じ場所に SBOM が作成されます。
desc ファイルの内容によっては SBOM 作成に数分かかります。
作成される SBOM のファイル名は <SWU イメージ名>.spdx.json になります。
json 形式で ISO/IEC5962で国際標準となっているSPDX2.2のフォーマットに準拠しています。 eMMC は主に NAND Flash メモリから構成されるデバイスです。
NAND Flash メモリには書き込みしてから1年から3年程度の長期間データが読み出されないと電荷が抜けてしまう可能性があります。
その際、電荷が抜けて正しくデータが読めない場合は、eMMC 内部で ECC (Error Correcting Code) を利用してデータを訂正します。
しかし、訂正ができないほどにデータが化けてしまう場合もあります。
そのため、一度書いてから長期間利用しない、高温の環境で利用するなどのケースでは、データ保持期間内に電荷の補充が必要になります。
電荷の補充にはデータの読み出し処理を実行し、このデータの読み出し処理をデータリテンションと呼びます。 Armadillo-900 開発セットに搭載のeMMCは、eMMC自身にデータリテンション機能が備わっており、Armadillo に電源が接続されてeMMCに電源供給されている状態で、
eMMC内部でデータリテンション処理が自動実行されます。 Armadillo-900 開発セット ではシステムが出力するログの一部は、
一般的な /var/log ディレクトリではなく、/var/at-log ディレクトリに出力されます。
/var/at-log は、ルートファイルシステムとは別のパーティションになっているので、
ルートファイルシステムに障害が発生した場合でも、/var/at-log のパーティションが無事であれば、
ログファイルを取り出して、不具合等の解析に利用することができます。 Armadillo-900 開発セット で /var/log 配下に出力するログに関しては 「/var/log/ 配下のログに関して」 を参照ください。 ログファイルは /var/at-log ディレクトリ内に atlog というファイル名で作成されているので、
これを任意のディレクトリにコピーすることで取り出せます。
もし、eMMC 上のルートファイルシステムが壊れてしまい起動できない場合は、
microSD カードから起動することでログファイルを取り出すことができます。 | |
|---|
/var/at-log/atlog はファイルサイズが 3MiB になるとローテートされ /var/at-log/atlog.1 に移動されます。 /var/at-log/atlog.1 が存在する状態で、更に /var/at-log/atlog のファイルサイズが 3MiB になった場合は、 /var/at-log/atlog の内容が /var/at-log/atlog.1 に上書きされます。 /var/at-log/atlog.2 は生成されません。 |
ログファイルの内容はテキストデータであり、以下のようなフォーマットになっています。 atlog には以下の内容が保存されています。 -
インストール状態のバージョン情報
-
swupdate によるアップデートの日付とバージョン変更
-
abos-ctrl / uboot の rollback 日付
-
uboot で wdt による再起動があった場合にその日付
ログ出力先である /var/at-log ディレクトリには、
GPP である /dev/mmcblk0gp1 パーティションがマウントされています。
このパーティションに論理的な障害が発生した場合は、/dev/mmcblk0gp1 の
データを /dev/mmcblk0gp2 にコピーし、/dev/mmcblk0gp1 は FAT ファイルシステムで
フォーマットされます。
このパーティションの障害チェックはシステム起動時に自動的に実行されます。 10.22.5. /var/log/ 配下のログに関して表10.13「/var/log/ 配下のログ」 に Armadillo-900 開発セット で /var/log/ 配下に出力するログを示します。 最大ファイルサイズを超えると 表10.13「/var/log/ 配下のログ」 の「ファイル名」の 2 行目に記載されたファイル名にコピーします。 その状態から更に最大ファイルサイズを超えた場合、 表10.13「/var/log/ 配下のログ」 の「ファイル名」の 2 行目に記載されたファイル名に上書きします。 表10.13 /var/log/ 配下のログ | ファイル名 | 説明 | 最大ファイルサイズ | 最大ファイル数 |
|---|
/var/log/messages
/var/log/messages.0 | 通常のログです。 | 4MiB | 2 | /var/log/armadillo-twin-agent/agent_log
/var/log/armadillo-twin-agent/agent_log.1 | Armadillo Twin Agent の動作ログです。 | 1MiB | 2 |
10.23. ATDE・Linux でインストールディスクを作成するATDE や Linux でインストールディスクイメージからインストールディスクを作成する方法を紹介します。
（Windows でインストールディスクを作成する方法については「初期化インストールディスクの作成」を参照してください。
参照先は初期化インストールディスクイメージを使用した方法ですが、それ以外のインストールディスクイメージでも同様の手順で行うことができます。） ここでは、例としてATDEで初期化インストールディスクを作成する2種類の方法（CUI・GUI）を記載しています。
初期化インストールディスクイメージ以外のインストールディスクイメージでも同様の手順で行うことができます。 いずれの方法でも、まずは次の共通の手順を実施してください。 10.23.1. GUI でインストールディスクを作成する
ダウンロードしたzipファイルを展開します。図のとおり、zipファイルを選択して右クリックし、「ここで展開」をしてください。
-
ATDE に microSD カードを接続します。詳しくは「取り外し可能デバイスの使用」を参考にしてください。
展開したフォルダ内にあるインストールディスクイメージ（.img）をダブルクリックして、「ディスクイメージをリストア」のウィンドウを表示します。
microSD カードを指定します。[転送先]から接続した microSD カードに対応するものを選びます。
| |
|---|
[転送先]は細心の注意を払って選んでください。
[転送先]にはATDEのシステムディスク（右側に VBOX HARDDISK や /dev/atde9-vg* と記載されているもの）も表示されていますが、これらは決して選択しないでください。
誤って選択して書き込んでしまった場合、ATDEが破壊される可能性があります。 また、他に接続されているデバイスに意図せず書き込んでしまった場合、そのデバイスのデータが上書きされてしまいます。
選んだ[転送先]が目的の microSD カードなのかどうか、しっかりと確認してください。microSDカードやカードリーダーの挿抜による[転送先]の表示の変化で確かめることもできます。 |
-
[リストアを開始]ボタンをクリックして、書き込みを開始します。
確認のウィンドウが現れるので、今一度確認した上で[リストア]をクリックします。
パスワードが要求されるので入力します。
-
書き込みが完了したら、 microSD カードを取り外します。
10.23.2. CUI でインストールディスクを作成する-
ATDE に microSD カードを接続します。詳しくは「取り外し可能デバイスの使用」を参考にしてください。
microSD カードのデバイス名を確認します
[ATDE ~]$ ls /dev/sd?
/dev/sda /dev/sdb
[ATDE ~]$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 7.22 GiB, 7751073792 bytes, 15138816 sectors
Disk model: SD/MMC
: (省略)
microSD カードがマウントされている場合、アンマウントします。
[ATDE ~]$ mount
: (省略)
/dev/sdb1 on /media/52E6-5897 type ext2 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=cp437,iocharset=utf8,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks)
[ATDE ~]$ sudo umount /dev/sdb1
ダウンロードしたファイルを展開し、以下の dd コマンドで img ファイルを microSD カードに書き込んでください。
[ATDE ~]$ unzip baseos-900-installer-[VERSION].zip
[ATDE ~]$ sudo dd if=baseos-900-installer-[VERSION].img \
of=/dev/sdb bs=1M oflag=direct status=progress-
書き込みが完了したら、 microSD カードを取り外します。
10.24. シリアル通信ソフトウェア(minicom)Linux や ATDE で使用できるシリアル通信ソフトウェアとして minicom の使用方法を紹介します。 10.24.1. シリアル通信ソフトウェア(minicom)のセットアップ | |
|---|
ATDE9 v20240925 以降の ATDE では以下の設定を実施した状態のイメージを配布しています。
これより前のバージョンの場合は、次の手順に沿って minicom のシリアル通信設定を実施してください。 |
minicom を使用して Armadillo とシリアルコンソール経由で通信を行うためには、
表10.14「シリアル通信設定」 のとおりにあらかじめ設定しておく必要があります。
ここでは、その設定手順について説明します。
また、minicomを起動する端末の横幅を80文字以上にしてください。横幅が80文字より小さい場合、コマンド入力中に表示が乱れることがあります。 表10.14 シリアル通信設定 | 項目 | 設定 |
|---|
転送レート | 115,200bps | データ長 | 8bit | ストップビット | 1bit | パリティ | なし | フロー制御 | なし |
図10.98「minicomの設定の起動」に示すコマンドを実行し、minicomの設定画面を起動してください。
図10.99「minicomの設定」が表示されますので、「Serial port setup」を選択してください。
図10.100「minicomのシリアルポートの設定」が表示されますので、Aキーを押してSerial Deviceを選択してください。
Serial Device に使用するデバイスファイル名として /dev/ttyUSB0 を入力してEnterキーを押してください。
| デバイスファイル名の確認方法 |
|---|
デバイスファイル名は、環境によって /dev/ttyS0 や /dev/ttyUSB1 など、本書の実行例とは異なる場合があります。 その場合は以下の方法でデバイスファイル名を確認してください。 Linux で PC と Armadillo 側のシリアルポートを接続した場合、コンソールに以下のようなログが表示されます。
ログが表示されなくても、dmesgコマンドを実行することで、ログを確認することができます。 例. シリアルポート接続時のログ. 上記の例では Armadillo 側のシリアルポートが ttyUSB0 に割り当てられたことが分かります。 |
-
Fキーを押してHardware Flow ControlをNoに設定してください。
-
Gキーを押してSoftware Flow ControlをNoに設定してください。
キーボードのEキーを押してください。
図10.101「minicomのシリアルポートのパラメータの設定」 が表示されます。
-
図10.101「minicomのシリアルポートのパラメータの設定」では、転送レート、データ長、ストップビット、パリティの設定を行います。
現在の設定値は「Current」に表示されています。
それぞれの値の内容は図10.102「minicomシリアルポートの設定値」を参照してください。
-
Eキーを押して、転送レートを115200に設定してください。
-
Qキーを押して、データ長を8、パリティをNone、ストップビットを1に設定してください。
-
Enterキーを2回押して、図10.99「minicomの設定」に戻ってください。
-
図10.99「minicomの設定」から、「Save setup as dfl」を選択し、設定を保存してください。
-
「Exit from Minicom」を選択し、minicomの設定を終了してください。
| |
|---|
Ctrl-a に続いて z キーを入力すると、minicomのコマンドヘルプが表示されます。
|
ATDE の場合は、minicom を起動する前に シリアルコンソールとして使用する取り外し可能デバイスに示すデバイスを ATDE に接続してください。 シリアルコンソールとして使用する取り外し可能デバイス. 図10.103「minicom起動方法」のようにして、minicom を起動してください。
また、minicomを起動する端末の横幅を80文字以上にしてください。横幅が80文字より小さい場合、コマンド入力中に表示が乱れることがあります。 | |
|---|
デバイスファイル名は、環境によって /dev/ttyS0 や /dev/ttyUSB1 など、本書の実行例とは異なる場合があります。 |
| |
|---|
minicomがオープンする /dev/ttyS0 や /dev/ttyUSB0 といったデバイスファイルは、 root または dialout グループに属しているユーザーしかアクセスできません。 ユーザーを dialout グループに入れることで、以降、sudoを使わずにminicomで /dev/ttyUSB0 をオープンすることができます。 [ATDE ~]$ sudo usermod -aG dialout atmark
[ATDE ~]$ LANG=C minicom --wrap --device /dev/ttyUSB0 |
minicomを終了させるには、まず Ctrl-a に続いて q キーを入力します。その後、以下のように表示されたら「Yes」にカーソルを合わせてEnterキーを入力するとminicomが終了します。 10.25. 不正な USB デバイスの接続を拒否するIoT 機器において、悪意のある第三者が容易に悪用できる USB コネクタなどのインターフェースを外部に露出したままでの運用は、セキュリティ的な脆弱性に繋がります。
しかし、保守運用のために USB インターフェースを露出しておかなければならない場合や、機器として USB で接続する周辺デバイスがある場合など、全ての USB インターフェースを物理的に閉じておくことが難しいことも考えられます。 Armadillo Base OS は、 USB デバイスの許可リストを作成・管理し、許可リストにないデバイスが接続されても認識しないように設定できる USB 接続制御機能を持っています。
この機能を用いることで、悪意のある第三者が不正な USB デバイスを接続しても、システムに影響を与えません。 | |
|---|
USB 接続制御機能は、 ABOS バージョン 3.20.3-at.8 以降で対応しています。 |
10.25.2. 接続済みの USB デバイスの一覧を表示する図10.109「接続されているUSB デバイスをリストする」に示すコマンドを実行することで、 Armadillo に接続されている全ての USB デバイスのリストを表示します。 1行につき1つのデバイスの情報をスペース区切りで示しています。
各列が何を示しているかは表10.15「デバイスリストの各列の意味」を参照してください。 表10.15 デバイスリストの各列の意味 1列目 | そのデバイスに割り当たっている ID です。USB デバイスを許可/拒否する際に識別子として使用されます | 2列目 | そのデバイスが現在許可(allow)されているか。拒否(block)されているかを示します | 3列目 | そのデバイスに割り当たっている USB バス番号とデバイス番号のペアです | 4列目 | そのデバイスのベンダーIDです | 5列目 | そのデバイスのモデルIDです | 6列目 | そのデバイスのモデル名です | 7列目 | そのデバイスのUSBクラスコードです。デバイスによっては複数存在するものもあり、":"(コロン)区切りで表示されます | 8列目 | そのデバイスのシリアル番号です。一般に同じ製品であっても個体ごとに一意な値です | 9列目 | そのデバイスに割り当たっている/sys以下のディレクトリパスです |
10.25.5. USB デバイスクラス単位で USB デバイスの接続を許可する「USB デバイスの接続を許可する」の手順では、 USB デバイスのベンダー ID やプロダクト ID、シリアル番号などが完全一致したデバイスのみを許可します。
そのため同じメーカーの同じデバイスであっても、シリアル番号が一致しないと許可されません。
ここでは、「USB メモリの接続はどのメーカーのどの製品であっても全て許可するが、 USB カメラなどの接続は拒否する」といったルールを手軽に作成する機能を紹介します。 abos-ctrl usb-filter allow-class コマンドを用いて、指定した USB デバイスクラスのみを許可することができます。
例として、図10.112「指定した USB デバイスクラスを許可する」では、 USB MassStorage クラスのデバイス(USB メモリなど)を許可します。 図10.112「指定した USB デバイスクラスを許可する」の例では、引数として"MassStorage"を指定していますが、他にも指定できるデバイスクラスがあります。
図10.113「指定可能な USB デバイスクラスを確認する」に示すコマンドを実行することで、引数として指定できる文字列を確認できます。 各 USB デバイスクラスについては、 Defined Class Codes を参照してください。 1つのデバイスで複数のデバイスクラスを持っている場合、そのデバイスの全てのデバイスクラスが許可されていなければ認識されません。
例えば、図10.109「接続されているUSB デバイスをリストする」の1番目に認識されている USB カメラは Video と Audio の2つのデバイスクラスを持っています。
このデバイスは、 Video と Audio 両方のデバイスクラスを許可している場合に認識されます。 本章では、Armadillo-900 開発セットのオプション品について説明します。 表10.17 Armadillo-900 開発セット 関連のオプション品 | 名称 | 型番 |
|---|
ACアダプタ（12V/2.0A φ2.1mm）温度拡張品 効率レベルVI品 | OP-AC12V4-00 |
| |
| | | |
| |
