コンテンツにスキップ

setup(600-899)

600_signage_jetson.sh

このスクリプトは、update_runner / update_manager / healthcheck のヘルパーを配置し、サイネージの更新管理を実行する systemd ユニット（signage-update.service） を作成・更新します。
ユニットは oneshot で起動し、/etc/signage/secret.env と /etc/signage/signage.env を読み込んだ上で、config.sh を source してから update_manager を実行します。

処理の流れ）

1) ヘルパー配置
install_or_link で update_runner / update_manager / healthcheck を所定パスへ配置（冪等）。

2) ディレクトリ準備/権限整備
- mkdir -p "$WIFI_FLAG_DIR" "$USER_SYSTEMD_DIR"
- chown -R "$USERNAME:$USERNAME" "$WIFI_FLAG_DIR" "$HOME_DIR/.config/systemd"
- chmod 755 "$WIFI_FLAG_DIR"

3) systemd ユニット生成/更新（冪等）
- signage-update.service を生成/更新。差分なしならスキップ。

注意

  • 実効ユーザ：ユニットに User= 指定が無いため root で実行されます。USERNAME=${USERNAME} というログ表記は説明用であり、実際にそのユーザで動かす場合はユニットに User=${USERNAME} を追加してください。
  • FailureAction=reboot：update_manager の失敗で 再起動が発生します。運用に応じて外す/変更（none など）を検討してください。

610_install_trt_runtime.sh

このスクリプトは、YOLOX 推論用の TensorRT / PyCUDA / OpenCV (Python) の最小ランタイムを Jetson に導入し、モデル格納ディレクトリを用意します。
Raspberry Pi は自動スキップ（BOARD_TYPE に pi/rasp を含む場合は即終了）。
既存の *.engine が無い場合はコピーを促すだけで生成はしません。

処理の流れ

1) Raspberry Pi 判定
BOARD_TYPE を小文字化して pi/rasp を含む場合は スキップして終了。

2) 定数定義
MODEL_DIR="/opt/models/yolox"・ENGINE_GLOB="${MODEL_DIR}/*.engine" を設定。

3) APT によるランタイム導入
python3-libnvinfer, python3-libnvinfer-dev, python3-pycuda, python3-opencv をインストール。

4) pip フォールバック（必要時のみ）
Python から tensorrt / numpy を import し、見つからない場合のみ
--extra-index-url https://pypi.nvidia.com で pip install 実行。

5) モデルディレクトリの作成
sudo mkdir -p /opt/models/yolox → sudo chown "${USER}:${USER}" /opt/models/yolox。

6) エンジンの有無を通知
*.engine があれば発見ログ、無ければ PC 生成エンジンのコピー を促す。

TensorRT 互換性

  • JetPack の TensorRT 版とエンジンの互換性（メジャー/ビルド差） が必要です。JetPack を変更した場合は エンジン再生成を推奨します。
  • pip で入る tensorrt は 不足時のフォールバックです。APT 版との混在は不整合の可能性があるため、基本は APT 版優先を推奨します。

所有者の指定（USER）

sudo 実行で USER が root になる環境があります。意図した所有者にしたい場合は、実行前に
export USER="$(logname)" などで明示してください。

700_jetson_server.sh

このスクリプトは、サイネージ用のコンテンツ格納ディレクトリを整備し、ユーザーの linger を有効化、ホスト名設定＋mDNS(Avahi) を有効化します。
さらに systemd --user サービス（Node.js サーバ）を生成・有効化して起動します。

処理の流れ

1) コンテンツディレクトリ作成（所有者: $USERNAME）
- ${HOME_DIR}/contents/{videos,images,playlists}
- …/videos/thumbnails, …/images/thumbnails
- /var/lib/signage_local（755, $USERNAME:$USERNAME）

2) linger 有効化（ログインセッション無しでも user サービスを稼働）
- loginctl enable-linger "$USERNAME"

3) ホスト名と mDNS(Avahi)
- hostnamectl set-hostname "$DEVICE_ID"
- /etc/hosts に 127.0.1.1 $DEVICE_ID を追記（未登録時のみ）
- avahi-daemon を enable --now（mDNS: ${DEVICE_ID}.local）

4) systemd --user サービス生成
- サイネージ機能の中核パッケージ signage-server の起動サービス

Node.js 実行環境

ExecStart=/usr/bin/node … を前提としています。Node.js の配置やバージョン（例: v22）を変更している場合は、パス・バージョン互換を確認してください。/etc/signage/signage.env の内容も合わせて点検してください。

710_signage_server_port_override.sh

このスクリプトは、systemd --user ユニット（signage-server.service）に drop-in を追加し、実行時環境変数 PORT=3001 を付与します。
作成後に user デーモンを daemon-reload → restart して反映します。

処理の流れ

1) drop-in ディレクトリ作成：${SIGNAGE_SERVER_DROPIN_DIR} を作成

2) drop-in 生成：${SIGNAGE_SERVER_DROPIN_FILE} に以下を書き込み 

[Service]
Environment=PORT=3001

優先度（Environment と EnvironmentFile）

Environment= は 後段で定義された値が優先 されます。drop-in の
Environment=PORT=3001 は、メインユニットや EnvironmentFile=/etc/signage/signage.env 内の PORT を 上書き します。

ポート設計

非特権ポート（>=1024）を推奨。3001 は安全な一般例です。
リバースプロキシ（nginx など）や他プロセスと ポート衝突 がないように設計してください。

720_nginx_admin_ui.sh

このスクリプトは、Nginx に vhost を作成し、http://:3000 を Node.js（127.0.0.1:3001）へリバースプロキシします。
/admin/ は 静的 React UI（/var/www/admin-ui/）を配信、/socket.io/ は WebSocket、/api/ は REST、その他は Node 側へフォールバック。
既定の :80 default サイトは 無効化（シンボリックリンク削除） します。

処理の流れ

1) 既定サイトの無効化
DEFAULT_SITE がシンボリックリンクなら削除（:80 default を外す）。

2) vhost 設定を書き込み（NGINX_AVAILABLE）
- map $http_upgrade $connection_upgrade { default upgrade; '' close; }
- upstream signage_node { server 127.0.0.1:3001; }
- server { listen 3000 default_server; server_name _; client_max_body_size 200m; … }
- location ^~ /admin/ { alias /var/www/admin-ui/; try_files $uri $uri/ /admin/index.html; }
- location /socket.io/ { proxy_pass http://signage_node; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }
- location /api/ { proxy_pass http://signage_node; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }
- location / { proxy_pass http://signage_node; }

3) サイトの有効化 & テスト
ln -sf "${NGINX_AVAILABLE}" "${NGINX_ENABLED}" → nginx -t

4) Nginx リロード

alias と末尾スラッシュ

location ^~ /admin/ { alias /var/www/admin-ui/; } のように
location 側と alias 側の双方に末尾 / が必要です。
どちらかが欠けるとパス解決が崩れ、静的ファイルの 404 や MIME ずれの原因になります。
併せて try_files $uri $uri/ /admin/index.html; を入れて SPA のルーティングを担保します。

WebSocket 透過

Socket.IO 等の WS は HTTP/1.1 + Upgrade が必須です。
- proxy_http_version 1.1
- Upgrade: $http_upgrade / Connection: $connection_upgrade（map で制御）
- Host / X-Real-IP をバックエンドへ伝搬
これらが無いと 101 Switching Protocols に到達できず、握手が失敗します。

FW/公開の考慮

本 vhost は listen 3000（非特権ポート）。LAN 外公開や 80/443 統合が必要なら
リバースプロキシ前段（例: 80/443 → 3000）を設け、TLS（Let's Encrypt/certbot） を終端してください。
併せて ファイアウォール（ufw allow 3000/tcp など）と ポート衝突 を確認しましょう。

800_firewall.sh

このスクリプトは、FIREWALL_PORTS 配列に列挙したポート/サービスを UFW(簡易ファイアウォール) に許可ルールとして追加します。
配列が空なら スキップ。ufw enable はデフォルト無効（コメントアウト）のため、必要に応じて手動で有効化します。

処理の流れ

1) 配列チェック：FIREWALL_PORTS が 空ならスキップ。

2) 許可ルール追加：各要素に対して ufw allow "<rule>" を実行（失敗しても続行）。

3) （任意）有効化：必要に応じて ufw --force enable を実行。

リモート作業時のロックアウト注意

UFW を有効化する前に、現在利用中の管理用ポート（例: SSH）を必ず許可してください。
例: sudo ufw allow OpenSSH または sudo ufw allow 22/tcp。
先に許可せず ufw enable すると 自分自身を閉め出す 可能性があります。

IPv6 を使う場合

IPv6 を利用するなら /etc/default/ufw の IPV6=yes を確認してください。
無効だと IPv6 側にルールが適用されません。 設定変更後は sudo ufw reload で反映します。