シェルスクリプトまとめ

シェルスクリプト

curl オプションなしでbodyのみ表示

curl/httpie 比較チートシート - アルパカDiary Pro

curlでHTTPレスポンスのみを表示する方法 - 養殖Geekは川を上るか

wオプションでいろいろ取得

curl コマンドで、特定の(ヘッダ)情報だけを取り出す。レスポンスヘッダ - それマグで！

curl コマンド | コマンドの使い方(Linux) | hydroculのメモ

BODY=`curl (URL)`

とやって、BODYのjsonを解析したい。どうする。

jq コマンド使えばよい。

jq コマンドを使う日常のご紹介 - Qiita

ダブルクオーテーション外す方法は、jq の r オプション。

jqに痺れた … AWS CLIで演習など | OpenGroove

shとbashの違い bashで使えない機能がある

シェルスクリプトの1行目に書くおまじないで使える便利オプション集 - Qiita

シェルコマンドまとめ

whileループ

while 文の使用方法 | UNIX & Linux コマンド・シェルスクリプト リファレンス

条件式

if 文と test コマンド | UNIX & Linux コマンド・シェルスクリプト リファレンス

関数

シェルスクリプトで関数を利用する - Qiita

シェルスクリプトで外部ファイルに記述された変数を利用する方法 | 俺的備忘録 〜なんかいろいろ〜

時間計測のための変数

bashのSECONDS変数で簡単に処理時間を測定する - Qiita

AWS EC2 でWEBサーバーお試し

amazon AWS EC2 サービスを使用して、WEBサーバーのお試し。

手順概要

手順は以下を参考させていただいた。特につまることもなく簡単に作成できた。 AWS EC2でWebサーバーを構築してみる - Qiita

課金されないために

今回、AWS 無料利用枠のマシンを選択した。

AWS無料利用枠の詳細： AWS クラウド無料利用枠 | AWS

EC2の場合、750時間/月 以下の稼働であれば課金なし。つまり1台を1ヶ月常に動かした場合(24時間×31日=744時間)は課金されない。2台以上稼働させる場合は注意。

AWS クラウド無料利用枠 | AWS

また、AWSサインアップから24ヶ月は無料だが、24ヶ月すぎると課金されるので注意。

MacOS でパッケージ管理

Linux で使用している tree コマンドが Mac OS にはない。で調べていたら MacOS のパッケージマネージャー HomeBrew で tree コマンドインストールできるっぽいのでやってみた。

環境

OS: macOS Sierra 10.12.6

HomeBrewインストール

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

パッケージインストール

今回はtreeコマンドインストール

$ brew install tree

その他、インストールできたコマンド

jq,

参考

AGLニュース

AGL

AGLニュース

ニュース

2017

6/7: 車載Linux「AGL」の本格採用を始めるトヨタ、特許リスクも見据える

5/8: 車載Linux“AGL”の採用が2017年から日本で始まる

1/23: 無線ネットワークによるソフトウェア更新、車載Linuxベースの車載情報機器で

2016

10/27: 車載機器プラットフォームの標準化Automotive Grade Linuxの動向

8/24: “自動車業界の共同開発部門”が1年以内に車載Linuxから生み出したものとは

  • 「AGL UCB（Unified Code Base）」のバージョン2.0（UCB2.0）が公開された。
  • AGLは自動車業界の共通の開発部門のようなもので、使える機能や新しいフレームワークをどんどん出していくのが役割だ。ただ、提供するのはそのまま製品に使えるものではなく、7～8割までは出来上がっているものだ。これをベースに味付けしてメーカーなりの個性を出していっていただきたいと考えている。

7/24 車載Linuxの開発が軌道に乗るもトヨタ自動車は「まだ満足してない」

3/11: 車載Linuxのオープンソース活動はアップルとグーグルへの対抗軸に成り得るか

1/6: 車載Linuxに新開発のディストリビューション、Tizen IVIではない

  • AGLは2014年まで「Tizen IVI」をリファレンスとしていたが、2015年から方針を転換。ユニファイドコードベース（UCB）と呼ぶ、Yocto Projectベースにした新しいディストリビューションを開発する方針を打ち出していた。UCBでは、これまでのTizen IVIを使って得た知見や、AGLと協調して活動してきたGENIVIアライアンスの成果など、既存のオープンソースプロジェクトの最良のソフトウェア部分を利用している。

2015

6/3: トヨタはスマホと車載機の連携基盤もオープンソース、AppleとGoogleに対抗

6/2: 車載Linux開発に注力するトヨタ、課題解決に向け開発体制の一本化を提案

6/2: 初めてのオープンな車載機器用Linux要件仕様書を公開

  • Cauchy は AGL 準拠システム搭載の最初の自動車がいつ出回るかについては話しませんでした。しかし、トヨタと Jaguar/Land Rover が同プロジェクトに積極的に取り組んでいることを指摘しました。

6/1: 車載Linuxの要求仕様が決定、「将来的に運転支援システムもカバー」

3/12: ルノーと日産がカーナビにLinuxを全面採用、サプライヤはボッシュ

1/23: 「Tizen IVI 3.0」ベースの車載情報機器を高速起動、最終目標は5秒以下

2014

9/17: 「日本の車載情報機器開発を支える」、ユビキタスとミラクル・リナックスが提携

7/9: ARMコアSoCも「Tizen Common」世代の「Tizen IVI」に対応、ルネサスが開発

  • 「R-Car M2」などの評価ボード上で、車載情報機器向けLinuxプラットフォーム「Tizen IVI」を動作させるデモンストレーションを披露した
  • GLの活動のリファレンスプラットフォームとなっているのが、Intelが開発を主導するTizen IVIだ
  • Tizen IVIとモバイル機器向けの「Tizen Mobile」の共通部分から基礎プラットフォーム「Tizen Common」を構築

7/4: 車載Linuxのオープンソース活動は携帯電話機の轍を踏んではならない

  • AGLのようなオープンソースプロジェクトによって共通プラットフォームの開発を加速させなければ、車載情報機器の開発期間はどんどん長くなっていく
  • パナソニックが参加して2007年に結成されたのが、携帯電話機向けLinuxプラットフォームの開発団体であるLiMo Foundation
  • LiMo FoundationもAGLも目指すところはほぼ変わらない。だからこそ「オープンソース活動では、議論だけに時間を費やすべきではない。開発成果を実装する必要がある」

7/2: Automotive Grade Linuxが開発成果を発表、リファレンスは「Tizen IVI 3.0」

  • 6月30日AGLが最初のバージョンを公開した
  • Tizen mobile はSamsung。Tizen IVIの開発は、Intelが主導
  • Tizen IVI 3.0はAGLのリファレンスプラットフォームになっている
  • Tizen IVI 3.0は、HTML5ベースのアプリケーションの活用が容易なことを特徴としている
  • アップストリーム・ファースト

2013

6/13 Automotive Linux Summit Spring 2013リポート：Linuxとイーサネットが鍵を握る車載情報機器の進化

  • スマートフォンやタブレット端末と同じようなユーザー体験を自動車の中でも実現してほしい
  • 日本国内の車載ソフトウェア標準化団体である「JasPar（Japan Automotive Software Platform and Architecture）」
  • 車載情報機器には複数のネットワーク規格が利用されている。これを「イーサネットAVB」（IEEE802.1 Audio/Video Bridging）で置き換える

5/27: トヨタが「Tizen IVI」の開発に参加、車載情報機器のLinux採用に本腰

2012

9/25: オープンソースな自動車へ：Linux「AGL」発足

  • 目的：「自動車業界に幅広い協力体制を作り上げ、車載端末の共同開発を進めることで、各社が製品開発に利用できる標準仕様を作る」
  • 目標：現在の家庭やオフィスと同水準の接続環境を自動車内に求める消費者の期待に応えること

9/20: Linux Foundation、トヨタや日産らと車載システムのワークグループAGLを立ち上げ

参考 MONOist 「Automotive Grade Linux」最新記事一覧 MONOist 車載ソフトウェア:Automotive Grade Linux 日経テクノロジーまとめ

AGL/Phase 2 - Application Framework Core

AGL/Phase 2 - Application Framework Core AGL/Phase 2 - Application Framework Core Developer Documentation v2.0

11. Guide for developing with events

Signaling agent はシグナル受信を登録したクライアントへデータを送信するサービスです。 Signaling agent の書き方について良く理解できるように、登録、登録削除、シグナル作成、送信、受信のアクションが説明されていなければいけない。 以下の図は、Signaling agent の基本シーケンス。

basis_of_signaling_agent.png

この図はイベント通知のための signaling-framework の主な役割を示している。 frameworkをよく知らない人にとっては、signaling agent と binding は似ているように見える。

11.1.1. Subscribing and unsubscribing

登録と登録削除はクライアントが Signaling agent からのデータ受信できるようにするためのアクションです。 登録時に、データを生成するためのリソースとクライアントにデータを送信するためのリソースを作らなければいけない。 これらは同じソフトウェアのピースから操作されない：frameworkによってデータ送信されている間は、データを生成することはSignaling agent の開発者の責任です。　

クライアントがイベント受信を登録するとき、agentは以下のことをしなければいけない。 1. 登録のリクエストが正しいことを確認する 2. 要求されているデータの連鎖した計算結果を成立させてください？？まだであれば、 3. 計算されたデータのために挙げられた？イベントを作成してください。まだであれば、 4. frameworkにリクエストに対するイベントの登録の確立を頼んでください。 5. オプション　クライアントのリプライに含まれるイベントについて指示してください。

AGL Application Framework - Privileges Management

AGL

AGL Application Framework - Privileges Management 翻訳元

1.概要

　AGLが最小のセキュリティー要件を満たすために、アプリケーションの実行に関する２つの基本的な仕組みがある。

  • ユーザー単位で許可を制限する：１つの車に対して、所有車、整備士、運転手、乗客 のように複数のユーザーがいる。それぞれのユーザーの特権は異なり、何人かは他のユーザーよりも権利を持つべきです。これは、ユーザーまたはプロフィールに関連した許可によって管理される。

  • アプリケーション単位で許可を制限する： アプリケーションは適切な操作をするために必要となる許可を要求しなければいけない。許可が与えられたとき、アプリケーションは保護されたサービスやリソースにアクセスすることができる。

　このドキュメントは次の事に焦点を当てています。 　："ユーザー"のために起動している"アプリケーション"が"許可"によって、制限されたリソースにアクセスする必要があるとき、(許可、ユーザー、アプリケーション)の３つはチェックしなければいけない。

The following diagram summarizes how restrictions should apply: overview.png

　現在のAGL Application Frameworkの実装では、アクセス制御の仕組み(DAC1/MAC2)が全体的なセキュリティとシステム全体の分離のために使われている。 　両方の仕組みは、より低いレベルのサービスとハードウェアへアクセスするために、アプリケーションに認証された通信路とAPIを使うことを強制するために使われる。しかし、実用的な許可をチェックする役割を持つ他の仕組みが必要である。：現在、AGLにはこの仕事はポリシーチェッカーサービス(Cynara)に依存している。 　ここに、AGL Application Framework を通してアプリケーションを実行する典型的なアーキテクチャを示す。：

architecture.png

　セキュリティコンテキストの違いを提供し、アプリケーションに低レベルのサービスとリソースにアクセスする既知のAPI呼び出しをすることを強制するために、アーキテクチャは階層化される。

SMACKはアプリケーションからシステムサービスに直接アクセスするのを防ぐ責任がある。

アプリケーションをインストールするどんなユーザーも、そのアプリケーションが何を要求するのか、何もないのか予想する。： 例えば、用心深いユーザーは、SMSを送信する、連絡帳を読み出す、インターネットアクセスするなどのいづれかを必要とする電卓アプリはインストールしないでしょう。

アプリケーションの許可(または、特権)は、特定のユーザーがサービスにアクセスでき、いくつかのサービスAPIの一部を使う権利を持っているかを検証するために用いられる。 この操作は上図の“Privileges Check”を指す。

アプリケーションの許可は"特権の分離"の法則が大事にされている時だけ意味をなす。： すべてのアプリケーションが実行などに必要な特権とリソースを持たなければいけないということを述べている。

だから、システムが失敗した場合、その損害は使われる特権とリソースによって認証されることを超えない。(特権の分離によって制限されるかもしれない)。

違いを言うと：理論的には、アプリケーションは常に最小限の特権を要求すべきで、それ以上はいらない。

したがって、sensitiveで保護されたAPIを使うアプリケーションは、WGTパッケージに含まれているアプリケーションの設定ファイルの中に、要求された特権を宣言しなければいけない： 要求された特権は、ユーザー承認後に、application framework と Cynara によって検査され保存される。

このステップで、ユーザーはインストールをキャンセルできる、また、要求された特権を調整できる。 特権を調整するとはつまり、以下のカテゴリの１つを特権に設定することです。：

  • Permit: ユーザーによらず、capabilityの使用が常に許可される。
  • Deny: Use of the device capability is always denied It’s also possible to envision dynamic privileges granted/revoked by the user at run time by using some extra states:
  • Blanket Prompt: User is prompted for confirmation the first time the API function is called by the widget, but once confirmed, prompting is never required again.
  • Session Prompt: User is prompted once per session.
  • One-Shot Prompt: User is prompted each time the restricted API is invoked.

特権をスマートに管理する別の方法は、オプションの特権を定義することです: もし実行時に、特権が与えられていなかったら、アプリケーションは優しく行動し、後で特権を尋ねるか、目的に達成できる他の資産を使うべき。 つまり、実行時、システムは、与えられたアプリケーションは要求されて与えられた特権にアクセスする サービスを使うだけであることを保証する。 インストール時のユーザー設定によるが、いくつかの動的な特権の獲得や破棄は実行時に起こる。

2.特権: 定義

2.1. Format

特権は多くのユニークな文字列によって説明でき特定できる 。 しかし、特権を簡単に認識できる共有の記法、その起源、およびそれを適用するコンテキスト(“profile”)を使うこと は良い習慣だろう。 この視点でみると、以下のフォーマットのうち１つを使うことで開始することができる。

  • URN style (好まれる)
    urn:<vendor>:privilege:<profile>:<name>[:<operation>]
  • URL style (Tizen 記法に近い):
    http://<vendor>/privilege/<profile>/<name>[.<operation>]

この記法を使うと、以下のようないくつかの特権を定義できる：

  • urn:automotivelinux.org:privilege:common:alarm:set
    いくつかのAGL ECU でアラーム設定するために使われる。
  • urn:automotivelinux.org:privilege:telematics:diagnostics:send
    ECUで“Telematics”プロフィールをでアクセスするために使われる。
  • urn:renesas.com:privilege:porter_ext:imu
    IMUチップにアクセスするために、Porterボードに拡張ボードを適用する。
  • urn:toyota.com:privilege:hybrid:energy:manage
    いくつかの製品範囲のために、OEMに定義されている特権の例です is an example of privilege defined by an OEM for some product range

AGLの特権のリストは書いた時点では決まっていない、が、異なる組み込みシステムで定義されている特権は開始ポイントで使われるだろう。：
AGLはおそらく、ベースの資源(5章？の網羅リストを見てください。)を保護するために、同じ特権分離を再利用または共有できるだろう。

2.2.Levels

すべてのインストールされたアプリケーションパッケージは正しい署名3を含んでいる。署名は主にパッケージの作者を識別し、ディストリビューターの署名も含んでいる場合もある。これらの署名を使用して、必要な"level"をもつ特定の作者のみが使用できる権限を設定できる。

言い換えれば、特権レベルは階層を導入する方法です。： 特定のレベルの特権は、パッケージ/アプリケーションの起源が必要なレベルを持つことがわかっている場合にのみ、インストール時にアプリケーションに付与することができます。

level.png

例えば、Tizenはplatform, partner, public の３つの特権レベルを定義している。：

  • “platform” は最も高い特権レベルです。platformの署名がされているアプリケーションは多くの定義された特権を使用できる。例えば、特権 “KEYGRAB” はplatformの特権です。
  • “partner” は、何らかの形の拡張特権を持つかもしれないが、"プラットフォーム "と比較して範囲が狭い仲介者です。
  • “public” は一番低い特権レベルです。このレベルのアプリケーションは、より高いレベルの特権を使用する権限は決してありません。

AGLでは, よく似た階層を持っている。

  • “vendor”: 最も高いレベルで、OEM特権アプリケーション用に予約されている。h
  • “tier1”: 中間レベルで。Tier1の特権が予約されている。
  • “partner”: 最も低いレベル。その他パートナー用に予約されている。
  • “public”: ベースのレベル。

2.3.Privileges Hierarchies/Dependencies

一方で、システムのために定義されたスタティックな特権の数が、異なるドメインの数と保護された操作の粒度のために重要かもしれません。(see in §5: ~100 for Tizen 2.x, ~130 for Android). 他方で、セキュリティルールが増えていくことはセキュリティホールになる(複雑でエンドユーザーが膨大な特権リストをレビューする時間がとれず、多かれ少なかれアプリケーションに盲目的になる？という事実のため)。 これは開発者にとっても面倒です(アプリケーションの特権リストを維持することが悪夢になるため)。 これらの事実を考えると、特権の階層を導入することはおもしろいかもしれない(階層化されたモデルで実行するのではなく)。例えば：

  • 特権をグループ化すると、Bluetoothをグローバルに有効/無効にしたり、単一の機能やプロファイルを許可/拒否することができるだろう。
  • 特権の階層化を導入すると、電話ディレクトリへの「書き込みアクセス権」をもつアプリケーションが、「読み出しアクセス権」を要求なしに自動的に承継することができる。
  • 抽象化の導入：ジオロケーションAPIを使うことは　GPSデータやUMTSネットワークジオロケーションへアクセスできることを意味する。

これは大きな利点をもたらす：

  • 開発者の視点では、アプリケーション構成ファイルを書くときに扱いが簡単になる。
  • 長期的には異質なシステムを扱うのにとても興味深い抽象化を作り出すことができる。：特権階層はアプリケーションによって宣言されているメタ特権を変えずに、時間とともに進化できる可能性がある。

注意：このトピックは進行中の作業であり、イン・アウトについてさらに研究していく価値がある。

2.4.Relationship with APIs

3.Cynara

4.Developing applications with privileges

5.Similar mechanisms on other systems

5.1.Tizen

5.2.Android

  1. DAC: Discretionary Access Control (POSIX user/group permissions)↩

  2. MAC: Mandatory Access Control (currently implemented with SMACK)↩

  3. http://www.w3.org/TR/widgets-digsig/↩