Linux on ポンコツ地方エンジニアの技術ブログ

Codex のレート制限リセット権の有効期限の確認方法

Thu, 09 Jul 2026 00:00:00 +0900

Codex で付与されたレート制限リセット権は有効期限が30日間となっていますが、現状、有効期限がいつまでかを簡単に確認する術がないようです。
以下に Windows 環境で確認するためのスクリプトが記載されていたので、これを参考に Ubuntu 用のスクリプトを作成しました。

https://note.com/moz_ai_tech/n/n84feff773b79

スクリプトの作成

ファイル名は何でもよいですが、例えば check_codex_reset_credits.sh として、以下の内容を保存してください。

#!/usr/bin/env bash
set -euo pipefail

AUTH_FILE="${HOME}/.codex/auth.json"
API_URL="https://chatgpt.com/backend-api/wham/rate-limit-reset-credits"

if ! command -v jq >/dev/null 2>&1; then
 echo "ERROR: jq が見つかりません。先にインストールしてください。"
 echo " sudo apt update && sudo apt install -y jq"
 exit 1
fi

if ! command -v curl >/dev/null 2>&1; then
 echo "ERROR: curl が見つかりません。先にインストールしてください。"
 echo " sudo apt update && sudo apt install -y curl"
 exit 1
fi

if [ ! -f "$AUTH_FILE" ]; then
 echo "ERROR: 認証ファイルが見つかりません: $AUTH_FILE"
 echo "Codex にログイン済みか確認してください。"
 exit 1
fi

ACCESS_TOKEN="$(jq -r '.tokens.access_token // empty' "$AUTH_FILE")"
ACCOUNT_ID="$(jq -r '.tokens.account_id // empty' "$AUTH_FILE")"

if [ -z "$ACCESS_TOKEN" ]; then
 echo "ERROR: access_token が取得できませんでした。"
 echo "$AUTH_FILE の形式が想定と異なるか、Codex の認証状態が無効です。"
 exit 1
fi

TMP_RESPONSE="$(mktemp)"
trap 'rm -f "$TMP_RESPONSE"' EXIT

if [ -n "$ACCOUNT_ID" ]; then
 HTTP_CODE="$(
 curl -sS \
 -o "$TMP_RESPONSE" \
 -w "%{http_code}" \
 -H "Authorization: Bearer ${ACCESS_TOKEN}" \
 -H "OpenAI-Beta: codex-1" \
 -H "originator: Codex Desktop" \
 -H "ChatGPT-Account-ID: ${ACCOUNT_ID}" \
 --max-time 30 \
 "$API_URL"
 )"
else
 HTTP_CODE="$(
 curl -sS \
 -o "$TMP_RESPONSE" \
 -w "%{http_code}" \
 -H "Authorization: Bearer ${ACCESS_TOKEN}" \
 -H "OpenAI-Beta: codex-1" \
 -H "originator: Codex Desktop" \
 --max-time 30 \
 "$API_URL"
 )"
fi

if [ "$HTTP_CODE" != "200" ]; then
 echo "ERROR: API 呼び出しに失敗しました。HTTP status: $HTTP_CODE"
 echo "レスポンス:"
 cat "$TMP_RESPONSE"
 echo
 exit 1
fi

jq -r '
 def fmt_time:
 if . == null or . == "" then
 "不明"
 else
 # jq の fromdateiso8601 は小数秒つき ISO8601 で失敗することがあるため除去する
 sub("\\.[0-9]+Z$"; "Z")
 | fromdateiso8601
 | localtime
 | strftime("%Y-%m-%d %H:%M:%S %Z")
 end;

 "利用可能なリセット権: \(.available_count // 0) 個",
 "",
 "状態\t付与日時\t有効期限",
 (
 (.credits // [])
 | map([
 (.status // "不明"),
 (.granted_at | fmt_time),
 (.expires_at | fmt_time)
 ])
 | .[]
 | @tsv
 )
' "$TMP_RESPONSE" | column -t -s $'\t'

実行手順

sudo apt update
sudo apt install -y curl jq

chmod +x check_codex_reset_credits.sh
./check_codex_reset_credits.sh

注意

このスクリプトは、参照記事の PowerShell 版と同じく、~/.codex/auth.json から access_token と account_id を読み取り、https://chatgpt.com/backend-api/wham/rate-limit-reset-credits に GET します。

注意点として、この方法は公式に公開された安定 API ではなく、参照記事でも「内部APIを使った非公式な確認方法」と説明されています。
Codex 側の仕様変更で動かなくなる可能性があります。

OCI や AWS EC2 でセッション切断後も処理を止めないよう tmux を使う

Sat, 30 May 2026 00:00:00 +0900

OCI や AWS EC2 で作業していると、SSH セッションを閉じたタイミングで実行中のプログラムが止まってしまうことがあります。

この問題は、tmux の「セッションを切り離す（detach）」を使うだけでほぼ解決できます。
私は今回初めて tmux を使ったため、必要な操作に限定してメモしておきます。

先にまとめ

「SSH を閉じても処理を動かし続ける」目的なら、tmux は以下だけで運用できます。

SSH ログイン後に tmux セッションを作る
tmux 内でプログラムを起動する
Ctrl+b → d で切り離す
SSH を切断しても処理は継続する
再ログイン後に tmux へ再接続する

コマンドだけ見ると以下です。

# セッション作成
tmux new -s app

# （tmux 内で）プログラム実行
python main.py

# 切り離し: Ctrl+b, d

# いまあるセッション確認
tmux ls

# 再接続
tmux attach -t app

tmux のインストール

Ubuntu 系なら以下で入ります。

sudo apt update
sudo apt install -y tmux

確認（バージョン表示）

tmux -V

まずは 1 回動かしてみる

1. セッションを作る

tmux new -s app

app はセッション名です。
あとで再接続するときに使うので、用途が分かる名前を付けると楽です。

📝 注記

tmux だけ打った場合、もし tmux サーバーがまだ動いていなければ、新しいセッションを作って接続します（デフォルト名で作成）。
すでに tmux が動いていて接続済みでない場合は、最近使われたセッションにアタッチします（新しいセッションは作成されません）。上記のコマンドは明示的に新規の名前付きセッションを作るコマンドになります。

2. プログラムを起動する

tmux の画面の中で、普段どおりコマンドを実行します。

python main.py

たとえば API サーバーなら、以下のように常駐するコマンドでも同じです。

uvicorn app:app --host 0.0.0.0 --port 8000

3. セッションを切り離す（detach）

以下の順でキーを押します。

Ctrl+b
d

これで tmux の外に戻ります。
プログラムは tmux セッション内でそのまま動き続けますので、SSH 自体を切断して問題ありません。
再ログイン後に tmux へ戻れます。

4. 再接続する（attach）

tmux ls でセッション一覧を見て、名前を確認します。

tmux ls

以下のコマンドで再接続します。

tmux attach -t app

セッションを終了して抜ける（プロセスを停止してセッションを閉じる）

tmux をデタッチせずにそのままセッションを終了して抜けたい場合は、主に次の方法があります。

セッション内から終了する（推奨 — プロセスを安全に停止）

tmux attach -t <セッション名> でセッションに戻る
実行中のプロセスを Ctrl+C などで停止する
シェルで exit または Ctrl+D を押すとウィンドウが閉じ、最後のウィンドウが閉じるとセッションは終了します

外からセッションを強制的に終了する（注意: プロセスが強制終了される）

tmux kill-session -t <セッション名>
全てのセッションを終了する場合は tmux kill-server

注意: セッションを閉じると、そのセッション内で動いていたプロセスは終了します。処理を継続させたい場合はデタッチしてください。

今回の用途で最低限覚えるコマンド

用途	コマンド
新規セッション作成	`tmux new -s app`
セッション一覧	`tmux ls`
セッション再接続	`tmux attach -t app`
セッション削除（停止）	`tmux kill-session -t app`

💡 ヒント

セッション内で動いているプロセスを止めたいときは、まず tmux に再接続して Ctrl+c で停止するのが安全です。

キー操作の最小セット

tmux は Ctrl+b を押したあとに次のキーを押す操作が基本です（prefix キー）。

コマンド	内容
`Ctrl+b` → `d`	セッション切り離し
`Ctrl+b` → `c`	新しいウィンドウ作成
`Ctrl+b` → `n`	次のウィンドウへ移動
`Ctrl+b` → `p`	前のウィンドウへ移動
`Ctrl+b` → `,`	ウィンドウ名を変更

最初は Ctrl+b → d だけ覚えれば十分です。

よくあるハマりどころ

SSH を切ったら止まった

tmux の中で起動せず、通常シェルで起動している可能性があります。
tmux attach -t app で戻って、そこで起動し直してください。

`tmux attach` で「no sessions」になる

セッションが存在しない状態です。新しく作成します。

tmux new -s app

セッション名を忘れる

tmux ls

一覧を出して、その名前で attach すれば戻れます。

OCI の Ubuntu インスタンスの初期設定

Fri, 29 May 2026 00:00:00 +0900

swap の設定

以下のように、Ubuntu のイメージにはスワップがありません。

$ free -m
 total used free shared buff/cache available
Mem: 954 343 225 4 538 610
Swap: 0 0 0

2GB のスワップファイル（Swap）を追加します。
すべてのコマンドは、管理者権限（sudo）を付けてターミナルで実行します。

1. スワップファイルの作成

dd または fallocate コマンドで 2GB のファイルを作成します。ここでは確実かつ高速な fallocate を使用します。

sudo fallocate -l 2G /swapfile

⚠️ 警告

もし「fallocate failed: Operation not supported」のようなエラーが出た場合は、以下の dd コマンドを代わりに試してください。
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048

2. 適切な権限の設定

セキュリティのため、スワップファイルは root ユーザーのみが読み書きできるように権限を 600 に制限します。

sudo chmod 600 /swapfile

3. スワップ領域の初期化

作成したファイルをスワップ領域としてフォーマットします。

sudo mkswap /swapfile

4. スワップの有効化

システムにスワップファイルを認識させ、有効化します。

sudo swapon /swapfile

5. 設定の確認

スワップが正しく有効化されたか確認します。2GB（約 2.0GiB）のスワップが表示されていれば成功です。

sudo swapon --show
# または
free -h

6. 再起動後も自動で有効化する設定

上記の設定だけでは、インスタンスを再起動するとスワップが解除されてしまいます。再起動後も自動的に有効化されるよう、/etc/fstab に追記します。

6-1. fstab のバックアップ（推奨）

念のため、設定ファイルをバックアップしておきます。

sudo cp /etc/fstab /etc/fstab.bak

6-2. 設定の追記

以下のコマンドを実行して、/etc/fstab の末尾に設定を追記します。

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

【おまけ】カーネルパラメータの最適化（推奨）

Linux には、メモリがどれくらい減ったらスワップを開始するかを決める swappiness という値があります。
初期値は 60 であることが多いですが、クラウド環境（特に SSD ストレージ）では **10〜20** 程度に下げて、できるだけ物理メモリを優先して使うように設定するのが一般的です。

1. 現在の swappiness を確認

cat /proc/sys/vm/swappiness

2. 一時的に `10` に変更

sudo sysctl vm.swappiness=10

3. 永続的に反映

再起動後もこの設定を維持するため、/etc/sysctl.conf の末尾に追記します。

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

これで 2GB のスワップ設定はすべて完了です！

タイムゾーンの変更

# 現在のタイムゾーンを確認
timedatectl
# JST に変更
sudo timedatectl set-timezone Asia/Tokyo
# 変更されたことを確認
timedatectl

nano のインストール

sudo apt update
sudo apt install -y nano

git のインストール

sudo apt update
sudo apt install -y git

glab のインストールと認証

諸事情で GitHub ではなく GitLab を使っているので、glab をインストールします。

1. ダウンロード

apt でインストールできるバージョンは古いので、公式リリースからダウンロードしてインストールします。

詳細は以下を参照してください。

https://blog.ponkotools.com/posts/2026/05/10/glab/

2. GitLab でのアクセストークン（PAT）の発行

CLI から GitLab にアクセスするために、事前にブラウザ側（GitLab のウェブ画面）で Personal Access Token（個人用アクセストークン）を発行しておく必要があります。
WSL を使っているからか、web での認証ではうまくいきませんでした。

GitLab にログインします（SaaS 版の gitlab.com または社内などのオンプレミス版）。
面左上の自分のアイコン＞ Preferences（設定）＞左メニューの Access Tokens の順に開きます。
Add new token をクリックし、以下のように入力します：
Token name: 任意の名前（例: oci-ubuntu-cli）
Expiration date: 空欄（無期限）または任意の有効期限
Scopes（権限）: CLI をフル活用するために、api と write_repository以下にチェックを入れます。

Create personal access token をクリックします。

画面に一度だけトークン（glpat-xxxx…）が表示されるので、必ずコピーして手元に控えておきます。（画面を閉じると二度と見られなくなります）

3. CLI の認証設定（ログイン）

OCI の Ubuntu ターミナルに戻り、以下のコマンドを実行して対話型セットアップを開始します。

glab auth login

実行すると、いくつか質問されるので以下のように回答していきます。

┃ What GitLab instance do you want to sign in to?
┃ > gitlab.com
┃ GitLab Self-Managed or GitLab Dedicated instance

gitLab.com（本家）を使っている場合は、そのまま gitLab.com を選択して Enter。
自社サーバーなどの場合は GitLab Self-Managed or GitLab Dedicated instance を選択し、その後 URL（例: https://gitlab.example.com）を入力します。

- Signing into gitlab.com
┃ How would you like to sign in?
┃ > Token
┃ Web

Token を選択します。

- Signing into gitlab.com
┃ What domains does this host use for the container registry and image dependency proxy?
┃ > gitlab.com,gitlab.com:443,registry.gitlab.com

そのまま Enter を押します。

The minimum required scopes are 'api' and 'write_repository'.
Generate a personal access token at https://gitlab.com/-/user_settings/personal_access_tokens?scopes=api,write_repository
┃ Paste your authentication token:
┃ >

先ほど GitLab 画面でコピーしたトークン（glpat-xxxx…）を貼り付けて Enter を押します。

┃ Choose default Git protocol:
┃ SSH
┃ > HTTPS
┃ HTTP

HTTPS を選択します。

セットアップが完了したら、以下のコマンドで無事にログインできているか確認します。

glab auth status

ご自身のユーザー名や「Logged in to gitlab.com」といったステータスが表示されれば、GitLab CLI の設定はすべて完了です！

tmux のインストール

セッションが切れても実行中のプログラムが停止しないよう tmux を使うためにインストールします。

sudo apt update
sudo apt install -y tmux

docker のインストール

1. インストール

公式ドキュメントの Install using the apt repository に従って最新版の docker をインストールします。

https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

2. docker の権限を設定 (sudo を不要にする)

sudo gpasswd -a $(whoami) docker
sudo chgrp docker /var/run/docker.sock

不要なサービスの停止

参考: https://qiita.com/ynott/items/4312cb34611d2e462779

systemctl | grep running で稼働中のサービス一覧を出力し、そのうち不要なものを AI に尋ねた結果が以下です。

確実に停止・無効化して良いサービス

サービス名	役割と停止して良い理由
`ModemManager.service`	3G/4G/5G などのモバイルモデムを管理するサービス。クラウドのサーバーでモデムを使うことはないため、完全に不要です。
`fwupd.service`	マザーボードやデバイスのファームウェアをアップデートするデーモン。仮想マシン（VM）のファームウェアは OCI 側が管理するため不要です。
`rpcbind.servicerpcbind.socket`	NFSv3（ネットワークファイルシステム）などで使われる古いポートマップサービス。NFS でストレージをマウントする予定がなければ不要です。
`iscsid.serviceiscsid.socket`	iSCSI ストレージに接続するためのクアドラント。OCI のブロック・ボリュームを iSCSI 経由で直接マウント（手動アタッチなど）していない限り、標準の準仮想化（Paravirtualized）アタッチであれば不要です。
`udisks2.service`	主にデスクトップ環境で USB メモリなどのディスクを自動認識・マウントするためのサービス。サーバー用途では不要です。

停止・無効化のコマンド例
単に stop するだけだと再起動時にまた動いてしまうので、disable –now で自動起動の解除と停止を同時に行います。

sudo systemctl disable --now ModemManager fwupd rpcbind rpcbind.socket iscsid iscsid.socket udisks2

条件付きで停止・削除できるサービス（効果大）

環境によっては不要、あるいは別の手段に切り替えることで大幅に軽量化できる重要ポイントです。

`snapd.service` / `snap.oracle-cloud-agent...` （メモリ節約効果：大）

Ubuntu のパッケージ管理システム「Snap」と、OCI の管理エージェントです。

判断基準
OCI のダッシュボードからインスタンスのメトリック（CPU使用率のグラフなど）を見たり、OS の診断機能を使ったりしない、かつ自分で snap コマンドを使ったアプリ（Nextcloud などの Snap版）を動かす予定がない場合。

解説
oracle-cloud-agent は便利ですが、メモリが 1GB 以下の環境ではかなりの重荷になります。これらを Snap ごと削除すると、数十MB〜100MB 以上のメモリが浮きます。

完全に削除する場合のコマンド

sudo snap remove oracle-cloud-agent
sudo apt purge snapd -y

メモリ使用量の変化

上記のサービスをすべて停止した場合の比較です。

サービス停止前

$ free -h
 total used free shared buff/cache available
Mem: 954Mi 360Mi 72Mi 4.9Mi 677Mi 594Mi
Swap: 2.0Gi 21Mi 2.0Gi

サービス停止後

$ free -h
 total used free shared buff/cache available
Mem: 954Mi 299Mi 313Mi 4.9Mi 483Mi 655Mi
Swap: 2.0Gi 10Mi 2.0Gi

OCI Bastion 経由でプライベート・サブネット内のインスタンスに SSH で接続

Tue, 26 May 2026 00:00:00 +0900

日本語では要塞と訳されています。

手元の PC からこの Bastion（踏み台の役割）を経由させることで、インスタンス自体にパブリックIPを一切持たせないまま、手元の PC のターミナルから直接 SSH 接続できるようになります。

設定には、ネットワーク（VCN）の構築段階からいくつか重要なポイント（ルーターやセキュリティ・リストの設定など）があり、結構はまったのでメモとして残しておきます。

仕組みとメリット

完全無料で、自分で踏み台用のサーバー（EC2など）を1台管理・維持する必要がありません。
接続が必要なときだけ、手元のPCから「3時間だけ有効な一時的な接続セッション（トンネル）」を発行して侵入します。時間が経てば自動で完全に閉じられるため、セキュリティが非常に強固です。

環境

ホストPC: Ubuntu 22.04
インスタンス: Oracle Linux 9

📝 注記

インスタンスが Oracle Linux の場合と、Ubuntu などの他の OS の場合とで方法が一部異なります。
今回は Oracle Linux 9 の場合で、Ubuntu についてはまた別で書きます。

Step1: VCN とサブネットの作成

まずは土台となる仮想クラウド・ネットワーク（VCN）を作成します。
手動で細かく作ることもできますが、「VCNウィザード」を使うのが一番簡単で確実です。
インターネットに出るための「インターネット・ゲートウェイ」だけでなく、プライベートVMがアップデート等で外と通信するための「NATゲートウェイ」や「サービス・ゲートウェイ」も自動で作成・紐付けされます。

OCIコンソールメニューから「ネットワーキング」 > 「仮想クラウド・ネットワーク」に移動します。

アクションから「VCNウィザードの起動」をクリックします。

「インターネット接続性を持つVCNの作成」を選択し、「VCNウィザードの起動」をクリックします。

以下の情報を入力・確認して「次へ」進み、作成します。

項目	内容
VCN名	任意の名前（例: my-bastion-vcn）
VCNの構成 CIDRブロック	10.0.0.0/16（デフォルトのままでOK）
パブリック・サブネットのCIDR	10.0.0.0/24
プライベート・サブネットのCIDR	10.0.1.0/24

Step2: インスタンスの作成

次に、パブリックIPを持たない接続先のインスタンスを作成します。
「コンピュート」 > 「インスタンス」から「インスタンスの作成」をクリックします。
インスタンスの作成については別記事でも書いているので詳細は割愛しますが、イメージは Oracle Linux 9 を選びます。

そして、ネットワーキングセクションで以下を選択します。

プライベート・サブネット（Step 1で作成したもの）を選択。
「パブリックIPアドレスの割当て」で「パブリックIPなし」を選択。

SSHキーのセクションでは、ご自身のPCで作成した公開鍵（.pub）をアップロード、または新規で生成して秘密鍵を保存してください。

設定したら「作成」をクリックします。

Stes3: Bastion プラグインの有効化 (Oracle Linux の場合のみ)

作成したインスタンスの詳細画面に入り、管理タブの「Oracle Cloud エージェント」で要塞を探し、有効化します。

要塞のステータスが停止済となります。
OSの内部でプログラムのダウンロードや配置が行われており、ステータスが「実行中」になるまでには5分〜10分ほどかかることがあります。

📝 注記

ここで要塞を有効にしておかないと、後述の管理対象SSHセッションの作成で API エラーとなります。

Step4: Bastionの作成

「アイデンティティとセキュリティ」 > 「要塞」（Bastion）に移動します。

「要塞の作成」をクリックし、以下のように設定します。

項目	内容
要塞名	任意の名前
ターゲット仮想クラウド・ネットワーク	Step 1で作成したVCN
ターゲット・サブネット	ターゲットVMがいる「プライベート・サブネット」を選択します。
CIDRブロックの許可リスト	0.0.0.0/0 （特定のIPだけに絞るとより安全です）

「要塞の作成」をクリックします（アクティブになるまで数分かかります）。

Step5: セッションの作成

作成した Bastion の詳細画面に入り、「セッションの作成」をクリックします。

以下のように設定します。

項目	内容
セッション・タイプ	Oracle Linux の場合は管理対象SSHセッションを選択します。
ユーザー名	Oracle Linux の場合は `opc` です。
ターゲット・コンピュート・インスタンス	Step2 で作成したプライベートVMを選択します。
SSHキー	ご自身のPCにある SSH 公開鍵をアップロード or ペーストするか、新規に生成します。VM作成時に使ったものと同じ、またはペアになるものをアップロードしても OK です（後述）。

「セッションの作成」をクリックします。
状態が作成中となり、しばらく経つとアクティブになります。

Step6: SSH接続の実行

セッションが「アクティブ」になったら、いよいよ接続です。作成したセッションの右側にある「3つの点」メニューから「SSHコマンドのコピー」をクリックします。

コピーされるコマンドは以下のような形をしています。

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1..." opc@10.0.1.x

<privateKey> 2箇所ありますので、それぞれ VM インスタンス作成時の秘密鍵、Bastion セッション作成時の秘密鍵のパスに変更して実行します。

# 例
ssh -i ~/.ssh/VM用の秘密鍵 -o ProxyCommand="ssh -i ~/.ssh/Bastion用の秘密鍵 -W %h:%p ..." opc@10.0.1.x

📝 注記

セッション作成時の SSH キーを VM 作成時と同じものにした場合は、2箇所とも同じ秘密鍵のパスを指定します。

📝 注記

Linux のルールとして、秘密鍵の権限が緩いままだとSSH接続が拒否されてしまいます。この場合、以下のコマンドでパーミッションを変更します。
chmod 600 ssh-key-xxxx.key

実行すると、Bastionを経由してパブリックIPのないプライベートVMに直接SSHログインが完了します。

SSH キーについての補足

セッション作成時のSSHキーはVM作成時と同じでも別のものでも大丈夫です。

OCI の Bastion サービスは、接続時に「2枚の壁（認証）」を通過するイメージになります。

Bastionセッション作成時のSSHキー（壁1：入口の鍵）

ローカルPCから、OCIのBastionサービス（要塞）に侵入するための鍵です。
Bastionサービス自体が「あなたは本当にこのセッションを作った本人ですか？」を確かめるために使います。

VM作成時のSSHキー（壁2：奥の部屋の鍵）

Bastionを通り抜けたあと、ターゲットのプライベートVMにログインするための鍵です。
VM（OS）側が「あなたはログインを許可されたユーザーですか？」を確かめるために使います。

このように鍵の役割が独立しています。
ただ、「同じ鍵」を使った場合と「別の鍵」を使った場合で、最後に実行するSSHコマンドの書き換え方が少し変わります。

① 同じ鍵を使った場合（一番シンプル）

すべて1つの秘密鍵（例: id_rsa）で開くので、コピーしたコマンド内の2箇所の <privateKey> に同じ秘密鍵のパスを指定すればOKです。

ssh -i ~/.ssh/id_rsa -o ProxyCommand="ssh -i ~/.ssh/id_rsa -W %h:%p ..." opc@10.0.1.x

② 別の鍵を使った場合（それぞれ指定が必要）

コマンドの「前半」と「後半」で、それぞれの秘密鍵を指定する必要があります。

前半の -i: VM作成時の秘密鍵を指定
中間の ProxyCommand内の -i: Bastionセッション作成時の秘密鍵を指定

ssh -i ~/.ssh/VM用の秘密鍵 -o ProxyCommand="ssh -i ~/.ssh/Bastion用の秘密鍵 -W %h:%p ..." opc@10.0.1.x

管理やコマンドの書き換えをシンプルにしたい場合は、「同じ鍵（ペア）」を使ってしまうのが一番迷わなくてラクです。

セキュリティ的な問題は？

個人開発や一般的な社内検証環境レベルであれば、同じ鍵を使い回しても実用上のセキュリティリスクは非常に低い（実質的に問題ない）と言えます。

ただし、厳格なエンタープライズ（企業）の運用基準や、セキュリティの理想論（ベストプラクティス）の観点から見ると、いくつか「知っておくべきリスクと理由」があります。
なぜ分けるのが理想とされるのか、その理由は以下です。

1. 鍵が漏洩した際の影響範囲（爆発半径）が広がる

これが最も大きな理由です。

鍵を分けている場合： もしBastion用の鍵が外部に漏れても、攻撃者はBastionの入り口までしか来られません。ターゲットVMの鍵が無事なら、中のデータにはアクセスできません。

同じ鍵を使っている場合： その1つの秘密鍵が漏洩した瞬間、Bastionの突破からターゲットVMへのログインまで、すべての防御壁が同時に崩壊します。

ひとつの鍵にすべての権限を持たせることは、セキュリティの世界で嫌がられる「単一障害点（Single Point of Failure）」を作ることになってしまいます。

2. 「誰が・どこに」アクセスしたかの監査（ログ）が曖昧になる

本番環境やチーム開発において重要な視点です。

Bastion（要塞）の本来の目的は、「いつ、誰が、どのサーバーに入ったか」を厳密に記録・コントロールすることです。

Bastion用の鍵：「あなたがクラウド環境のネットワークに入った」ことを証明する
VM用の鍵：「あなたが特定のサーバーの opc ユーザーとしてログインした」ことを証明する

これらを同じ鍵にしてしまうと、鍵の管理者が同一人物である前提になってしまい、「Bastionを通過した人と、実際にVMを操作した人が本当に同一人物か？」という厳密なトレース（監査ログの信頼性）が担保しにくくなります。

参考

OCI (Oracle Cloud Infrastructure) で VM インスタンスを作成する

Thu, 21 May 2026 00:00:00 +0900

OCI (Oracle Cloud Infrastructure)

OCI には Always Free（永久無料枠） という非常に強力な特典があり、4 OCPU / 24 GB メモリ という、他社クラウドであれば有料級のハイスペックな Arm サーバー（Ampere A1）を無料で 24時間365日動かすことができます。

OCI のコンピュート環境：VM とコンテナインスタンスの違い

OCI でアプリケーションを動かすアプローチとして、主に 「VM Compute（仮想マシン）」 と 「コンテナインスタンス（Container Instances）」 の 2つがあります。

どちらも Docker コンテナを動かせますが、その管理レイヤーと仕様には明確な違いがあります。

比較項目	VM Compute (仮想マシン)	コンテナインスタンス
管理の単位	OS（Linux / Windows）	コンテナ（Dockerイメージなど）
インフラ管理	必要（OSアップデート、SSH管理）	不要（サーバーレス。オラクルが基盤を管理）
起動スピード	数分（OSのブート時間必要）	数秒（コンテナの起動のみ）
永続ストレージ	ブロック・ボリュームを自由に追加・マウント可能	エフェメラル（一時的。再起動でデータ消滅）
永久無料枠	あり（4 OCPU / 24 GBメモリまで無料）	なし（秒単位の従量課金）

どちらを選ぶべきか？

コンテナインスタンスはサーバーレスで運用が手軽ですが、永久無料枠（Always Free）の対象外となります。また、コンテナの再起動によって内部のデータが消去される特性を持ちます。

そのため、「24時間いつでも無料で動かし続けたい」「生成されるログやデータをローカルディスクに安全に保持（永続化）したい」という場合は、VM Compute を選択するのが最適です。

OCI への登録

https://www.oracle.com/jp/cloud/free/ にアクセスして「無料で始める」をクリックして各種情報を入力します。
ちょっとした注意事項として、住所は英語で入力する必要があります。

参考

インスタンスの作成

ホームより インスタンス を選択します。

ホームにない場合は、左上のメニューから コンピュート > インスタンス でも OK です。

続いて インスタンスの作成 を選択します。

基本情報

イメージ

デフォルトでは Oracle linux になっています。
Oracle Linux は Red Hat Enterprise Linux（RHEL）をベースにした OS だそうです。

セキュリティの「保護インスタンス」は、仮想マシン（VM）の乗っ取りや、悪意のあるプログラムによるOS改ざんを防ぐための「セキュリティ強化機能が有効になっている状態」を指すそうですので、保護インスタンスになっているものを選択しておいたほうが良さそうです。

シェイプ

Always Free 対象のものとして以下の２つがあります。

項目	Ampere (A1.Flex)	AMD (E2.1.Micro)
最大リソース	4 OCPU / 24 GB（分配可能）	1 OCPU / 1 GB × 2台
アーキテクチャ	Arm (aarch64)	x86_64
主な用途	開発環境、Docker、高負荷な処理、Webサーバー	軽量なスクリプト実行、VPNサーバー、検証用

VM.Standard.A1.Flex

現在OCIで提供されている中で最もハイスペックかつ使い勝手の良い無料枠インスタンスです。
Ampere を選択し、VM.Standard.A1.Flex をチェックします。

シェイプ名横の ▼ を押すと CPU と RAM の設定ができます。

「4 OCPU / 24 GB」までは無料で使えるらしいです。

VM.Standard.E2.1.Micro

Ampere A1 は人気のため、空きがなくて作成できないことが多いです。
また、システムが Arm（Aarch64）アーキテクチャに対応しておらず、どうしても従来の x86_64 環境が必要な場合もあったりします。
そのような場合はこちらを選びます。
ただし、スペックは Ampere A1 に比べて大幅に低くなります。

専門と前世代 を選択し、VM.Standard.E2.1.Micro をチェックします。

上記のうち好きな方を選び、次へを押します。

セキュリティ

保護インスタンスの設定ができますが、予期せぬエラーや「動かない」トラブルの原因になりやすいそうなので、今回は OFF のままとしました。

ネットワーキング

プライマリVNIC

初めて OCI を使うので、まだ「既存のネットワーク」が存在しないため、新しく 新規仮想クラウド・ネットワーク を選択します。サブネットも自動的に 新規パブリック・サブネットの作成 に切り替わり、名前などが自動入力されます。

２回目は既存のネットワークを選択すれば OK です。

パブリックIPv4アドレス割当て

今回は外部からの通信（インバウンド）を受ける必要はないため、 パブリックIPv4アドレスの割当て は OFF にしておきました。

SSHキーの追加

キー・ペアを自動で生成 を選択し、秘密キーのダウンロード を押して秘密鍵をダウンロードしておきます。

📝 注記

SSH キーなしを選択すると、後述するように Cloud Shell からもインスタンスにアクセスできませんでした。外部から SSH でアクセスする予定がなくても SSH キーは作成しておかないといけないようです。

ストレージ

ここは全てデフォルトのままとしました。

「カスタム・ブート・ボリューム・サイズ…」について チェックがOFF（デフォルト）の場合、標準サイズである 46.6 GB のディスクが自動で割り当てられます。
OCIの無料枠では最大で合計200GBまでストレージが使え、ここにチェックを入れて数値を 100 や 200 に増やすことも可能です。
ただ、後からでもディスクサイズは簡単に拡張できるため、最初はデフォルトのままで様子見するのが安全です。

「転送中暗号化の使用」について デフォルトでONになっていますが、これは「仮想マシンとストレージの間の通信を暗号化して盗聴を防ぐ」というインフラ側の高度な保護機能です。
パフォーマンスへの影響も無視できるレベルですので、ON（今の状態）のままにしておきましょう。

「自分が管理するキーでこのボリュームを暗号化」について チェックがOFF（デフォルト）の場合、Oracleが管理する標準の暗号鍵で自動的にディスクが暗号化されます。
個人開発で自前の鍵管理（Vault/KMSなど）を入れると管理コストが増えて複雑になるため、OFFのままで問題ありません。

作成

次へ進み、「作成」 を押すとインスタンスが作成されます。
しばらく待つとインスタンスが作成されます（ステータス表示が 実行中 に変わります）。

API エラーが発生した場合

これは設定の間違いではなく、「現在、Oracleのデータセンター側で、無料枠用のArmサーバー（Ampere）の在庫が一時的に切れている」という、OCIの無料枠で最も頻繁に発生する有名な現象です。
世界中で無料枠のAmpereは非常に人気があるため、椅子取りゲームのようになっています。

解決策は以下です。

1：x86の「AMD枠」に切り替えて即時作成する（確実・おすすめ）

Arm（Ampere）の在庫がなくても、もう1つの無料枠であるAMD（VM.Standard.E2.1.Micro）であれば、在庫に余裕がありすんなり作成できるケースが非常に多いです。

2：「フォルト・ドメイン」を変更して再トライする

同じAmpere（Arm）のまま、サーバーが置かれる物理的な区画（フォルト・ドメイン）を変更することで、運よく在庫が引っかかることがあります。

3：数日〜数週間、時間を変えてクリックし続ける

どうしても強力な「Arm（4 OCPU / 24 GBを狙いたいなど）」が良い場合、誰かがインスタンスを削除して在庫が空くのを待つことになります。

インスタンスの起動

コンピュートの画面から インスタンス を選択し、該当のインスタンスをクリックします。

右上から起動を押します。

これでしばらく待つとインスタンスが起動します。

インスタンスへ接続（Cloud Shell で接続）

OCI 上から Cloud Shell でインスタンスに接続してみます。

Cloud Shell の起動

画面右上の 開発者ツール をクリックし、Cloud Shell を選択します。

画面下に端末が表示されますが、まだインスタンスの中には入っていません。
Cloud Shell が単体で起動しただけです。

ネットワークの変更

端末上部の「ネットワーク：パブリック」と表示されたプルダウンから「エフェメラル・プライベートネット・・・」を選択します。

インスタンス作成時に作成した VCN とサブネットを選択し、アクティブなネットワークとして使用 を押します。

秘密鍵ファイルのアップロード

先程ダウンロードした秘密鍵ファイルを端末上にドラッグ＆ドロップしてアップロードします。

Linux のルールとして、秘密鍵の権限が緩いままだとSSH接続が拒否されてしまうため、以下のコマンドでパーミッションを変更します。（※ファイル名はご自身のものに書き換えてください）

chmod 600 ssh-key-xxxx.key

SSH コマンドでログインする

以上で準備は完了です。
以下のコマンドで Cloud Shell インスタンスへと接続します。

ssh -i ssh-key-xxxx.key <username>@<private_ip_address>

<username> は、インスタンスのデフォルトのユーザー名です。
Oracle Linux および Redhat Enterprise Linux 互換イメージの場合、デフォルトのユーザー名は opc、Ubuntu イメージの場合、デフォルトのユーザー名は ubuntu だそうです。

<private_ip_address> は接続先インスタンスのプライベートIPアドレスです。
コンピュート > インスタンス で確認できます。10.0.x.x のような数字を入れてください。

コマンド入力後、Are you sure you want to continue connecting (yes/no)? と聞かれたら、 yes と入力してEnterを押します。

無事にプロンプトが <username>@instance-xxxx:~$ に切り替われば、インスタンスに接続できています。

とりあえずはここまで。

参考

Ubuntu のユーザー名を変更する

Tue, 02 Apr 2024 00:00:00 +0900

Ubuntu 20.04 で確認しました。

新しいユーザーを作成する

ログインユーザー自身のユーザー名は変更できないので、一時的に管理者権限を持ったユーザーを作成します。

Ubuntu の場合は以下のように GUI で簡単に追加できます。

設定 > ユーザー > ユーザーを追加

ユーザー名とグループ名の変更

作成した新しいユーザーでログインして行います。

ユーザー名の変更

以下のコマンドを実行します。

$ sudo usermod -l new_username -d /home/new_username -m old_username

尚、usermod コマンドの -g オプションでグループ名も一緒に変更できるような記述も見つけましたが、私の場合、usermod: グループ 'new_username' は存在しません のエラーが表示されてできなかったため、ユーザー名とグループ名の変更を分けて行いました。

グループ名の変更

以下のコマンドを実行します。

$ sudo groupmod -n new_username old_username

以上で、変更後のユーザーでログインして問題なく使えることを確認しました。
ただ、唯一、ユーザーのアイコン画像だけがクリアされていました。

参考 URL

Windows と Ubuntu でマウスとキーボードを共有する

Fri, 26 Jan 2024 00:00:00 +0900

Barrier というソフトを使って、マウスとキーボードを共有します。

環境

Windows 10
- barrier 2.4.0
Ubuntu 20.04
- barrier 2.3.2

Barrier を使う場合、どちらかをサーバーとして設定する必要がありますが、今回は Windows をサーバーとしました。

Windows 側

インストール

GitHub の Releases から最新の exe をダウンロードしてインストールします。
Bonjourというソフトをインストールするかどうか聞かれますが、インストールしませんでした。

設定

「サーバー」にチェックを入れる
「サーバーの構成設定」を選択し、「モニタの結びつき」で任意のマスをクリックして、クライアント側のモニターを追加する
- モニター名を後述のクライアント側の名前に合わせて入力する
メニューバーから、「Barrier > 設定の変更」を選択し、「SSL を使用」のチェックを外す。
開始を押す

Ubuntu 側

インストール

以下のコマンドを実行します。

$ sudo apt install barrier

設定

「クライアント」にチェックを入れる
「サーバーIP」にIPアドレスを入力する
メニューバーから、「Barrier > Change Settings」を選択し、「Enable SSL」のチェックを外す。
開始を押す

追加の設定

ログイン画面（ロック画面）になるとマウスとキーボードが効かなくなるので、以下の設定も行いました。

Windows (サーバー) 側

Barrier の設定で、権限昇格を「常に」に変更しました。
恐らくセキュリティ的によろしくないので、やるなら自己責任でお願いします。

Ubuntu (クライアント) 側

Ubuntu 20.04 を使用している場合、GNOME デスクトップ環境がデフォルトで採用されているため、GDM (GNOME Display Manager) の設定を変更しました。

まず、GDMの設定ファイルを開きます。

sudo nano /etc/gdm3/custom.conf

[daemon] セクションに以下を追加します。

[daemon]
Greeter-setup-script=/usr/bin/numlockx on

変更を有効にするためにGDMを再起動します。

sudo service gdm restart

ただし、セキュリティ的にはよろしくないので、やるなら自己責任でお願いします。

参考 URL

systemd で環境変数を展開する

Wed, 14 Jun 2023 00:00:00 +0900

環境変数を参照する Python アプリを systemd でサービス化したときにかなりはまってしまいました。

systemd はユーザーの環境変数を参照しないようなので、ユニット定義ファイルで環境変数を設定する必要があるそうで、Environment で記述したり、外部ファイルに定義して EnvironmentFile で読み込む方法があるようです。

また、上記だと変数を展開することができないので、そのような場合には以下のように ExecStartPre で systemctl の set-environment を使う方法などがあるようです。

https://qiita.com/kobanyan/items/f8e8a3bd5406e1d290fb

ただ、今回の私の場合は、シェル変数 HOSTNAME を環境変数に export して参照したかったのですが、systemd にはホスト名を表す特殊な変数として %H があるようなので、これを使って以下のようにすれば解決できました。

[Unit]
Description=My Python App

[Service]
ExecStart=/path/to/your/python/app.py
Environment="HOSTNAME=%H"

[Install]
WantedBy=multi-user.target

参考 URL

Linux で端末にリアルタイムに日時を表示する

Thu, 02 Feb 2023 00:00:00 +0900

watch コマンドと date コマンドを組み合わせると簡単にできます。

例えば以下のような感じです。

$ watch -t -n 0.01 date +%T.%N

watch は引数で指定したコマンドを一定間隔ごとに繰り返し実行するコマンドです。
-t はヘッダを非表示にします。
-n はコマンドを実行する間隔（秒）です。
ここでは date コマンドを 0.01 秒ごとに実行しています。
+%T.%N は日時の書式です。
例えば、以下のようにすれば日付も表示されます。

$ watch -t -n 0.01 "date '+%Y/%m/%d %T.%N'"

書式にスペースを含む場合、シングルコーテーションやダブルコーテーションで括る必要があります。

参考 URL

Ubuntu の Emergency Mode で日本語配列のキーボードを使う

Fri, 02 Dec 2022 00:00:00 +0900

Ubuntu 18.04 が emergency mode で起動した時に、キーボードの配列が日本語配列になっていなくて困ったのでメモです。

以下を実行すれば日本語配列のキーボードが使えるようになりました。

loadkeys jp

尚、上記のコマンドを入力するために、私の環境では以下のようにキーを押す必要がありました。

入力したい文字	実際に押したキー
`l`	`k`
`o`	`o`
`a`	左下の ctrl
`d`	`s`
`k`	`j`
`e`	`e`
`y`	`y`
`s`	`a`
スペース	`.`
`j`	`h`
`p`	`p`

これが何の配列になっていたのかはわかりませんでした。

参考 URL

https://kledgeb.blogspot.com/2016/05/ubuntu-1604-60.html

overlayroot の有効無効をシェルスクリプト化

Tue, 18 Oct 2022 00:00:00 +0900

overlayroot を使ってファイルシステムを読み取り専用にしましたが、現在読み取り専用になっているのかどうかのチェックと、有効無効を簡単に切り替えられるようなスクリプトを作成してみました。

overlayroot のインストールや設定方法については以下の記事を参照してください。

https://kuttsun.blogspot.com/2022/04/overlayroot-ubuntu.html

overlayroot が有効か無効かをチェック

#!/bin/bash

mount | grep 'overlayroot on / type overlay' &> /dev/null
if [ $? == 0 ]; then
 echo "overlayroot enabled" 
else
 echo "overlayroot disabled"
fi

&> /dev/null は標準出力と標準エラー出力の破棄です。

https://qiita.com/ritukiii/items/b3d91e97b71ecd41d4ea

$? は直前に実行したコマンドの終了値です（0は成功、1は失敗）。

https://qiita.com/zayarwinttun/items/0dae4cb66d8f4bd2a337

overlayroot を無効にする

#!/bin/bash

sudo overlayroot-chroot rm /etc/overlayroot.local.conf

overlayroot-chroot で一時的に書き込み可能状態にして /etc/overlayroot.local.conf を削除しているだけです。

overlayroot を有効にする

#!/bin/bash

echo 'overlayroot="tmpfs:recurse=0"' | sudo tee /etc/overlayroot.local.conf

/etc/overlayroot.local.conf を作成して overlayroot="tmpfs:recurse=0" を記述しているだけです。

サンプル

以上を踏まえて作成してみたのが以下のスクリプトです。

#!/bin/bash
# ex: ./overlayroot.sh disable
# ex: ./overlayroot.sh enable
# ex: ./overlayroot.sh

timeout=3

# 現在の overlayroot の状態を取得
mount | grep 'overlayroot on / type overlay' &> /dev/null
if [ $? == 0 ]; then
 overlay=true
 echo "overlayroot enabled"
else
 overlay=false
 echo "overlayroot disabled"
fi

if [[ $1 = disable ]]; then
 # overlayroot を無効にする
 if [ $overlay = true ]; then
 echo "disable overlayroot..."
 sudo overlayroot-chroot rm /etc/overlayroot.local.conf
 echo -e "\nReboot after ${timeout} seconds"
 sleep ${timeout}
 sudo reboot
 else
 echo "overlayroot already disabled"
 fi
elif [[ $1 = enable ]]; then
 # overlayroot を有効にする
 if [ $overlay = true ]; then
 echo "overlayroot already enabled"
 else
 echo "enable overlayroot..."
 echo 'overlayroot="tmpfs:recurse=0"' | sudo tee /etc/overlayroot.local.conf
 echo -e "\nReboot after ${timeout} seconds"
 sleep ${timeout}
 sudo reboot
 fi
fi

echo -e "\nCloses after ${timeout} seconds"
sleep ${timeout}

参考 URL

Docker Volume をコピー（複製）する

Fri, 14 Oct 2022 00:00:00 +0900

Linux だと /var/lib/docker/volumes/<volume_name> に保存されているため、基本的にはこれを cp コマンドでコピーするだけで OK です。

# -p to preserve permissions
$ sudo cp -rp /var/lib/docker/volumes/source_volume /var/lib/docker/volumes/target_volume

参考 URL

[Docker] コンテナ内の実行ユーザーをホストのユーザーと合わせる

Tue, 30 Aug 2022 00:00:00 +0900

Docker コンテナにホストのディレクトリをマウントしている場合、コンテナ内の実行ユーザーとホストのユーザーが一致していないと、コンテナ内で作成されたファイルにアクセス権限がなくて困ることがあります。

これはコンテナ内の実行ユーザーをホストのユーザーと合わせることで解決できますが、じゃあユーザーの指定はどうするのが一番良いか？ということで、以下の記事がとても参考になりました。

https://qiita.com/yohm/items/047b2e68d008ebb0f001

ほとんどの場合、以下で上手く行くそうです。

$ docker run -it \
 -v /etc/group:/etc/group:ro \
 -v /etc/passwd:/etc/passwd:ro \
 -u $(id -u $USER):$(id -g $USER) \
 ubuntu bash

私の場合もこれで上手く行きました。

参考 URL

https://qiita.com/yohm/items/047b2e68d008ebb0f001

シェルスクリプトをダブルクリックで端末内で実行する

Tue, 23 Aug 2022 00:00:00 +0900

Ubuntu 20.04 にて、デスクトップに置いたシェルスクリプトファイルをダブルクリックで実行し、かつ端末内で実行する方法です。
結構はまったのでメモしておきます。

#!/bin/bash
gnome-terminal -- bash -c "echo sample;sleep 5"

端末がすぐ閉じるのを防ぐために sleep 5 を入れています。

#!/bin/bash
gnome-terminal -- bash -c "/home/username/sample.sh;sleep 5"

参考 URL

https://askubuntu.com/questions/1259265/make-gnome-terminal-request-user-confirmation-before-close

overlayroot 環境内で docker を使う方法

Fri, 19 Aug 2022 00:00:00 +0900

overlayroot でルートファイルシステムを読み取り専用にしたところ、docker が使えなくなりました。

OS は Ubuntu 20.04 です。
overlayroot を有効にする方法などについては以前の記事を参考にしてください。

https://kuttsun.blogspot.com/2022/04/overlayroot-ubuntu.html

問題点

Docker がインストールされている環境で、overlayroot でルートファイルシステムを読み取り専用にした場合、docker コマンドを実行すると以下のようなエラーが発生します。

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

いろいろ調べてみた結果、基本的に overlayroot が有効な状態では docker は使えないようです。
一応以下にあるやり方で docker コンテナを立ち上げるところまではできました。

しかし、そもそも Docker ボリュームには DB のデータなどを逐次格納していっているので、tmpfs 上（＝メモリ上）だとメモリがすぐ枯渇してしまいそうです。
また、Docker コンテナ・イメージをアップデートしたい場合にも困ります。

というわけで、少なくとも /var/lib/docker の領域はパーティションを分けるしかないじゃないかというところに行き着きました。
以下のページでも書き込み可能としたい場合はパーティションを分ける方法が紹介されています。

https://armadillo.atmark-techno.com/index.php/blog/10899/8648

また、Docker に関するベストプラクティスでも、コンテナ用にパーティションを分けるとあります。

https://www.creationline.com/lab/aquasecurity/43087

その上で、Docker コンテナも read-only で起動すれば、ルートファイルシステムだけでなく Docker コンテナも保護できそうです。

対処方法

とりあえず以下のようにパーティションを分けることで overlayroot と docker の共存ができました。

パス	マウントポイント
/dev/sda1	EFI システムパーティション
/dev/sda2	/
/dev/sda3	/var

この状態で overlayroot をインストールし、/etc/overlayroot.local.conf に overlayroot="tmpfs:recurse=0" を記載します。コマンド一発でやる場合は以下です。

$ echo 'overlayroot="tmpfs:recurse=0"' | sudo tee -a /etc/overlayroot.local.conf

overlayroot のインストールや設定については以前の記事を参考にしてください。

https://kuttsun.blogspot.com/2022/04/overlayroot-ubuntu.html

今回はルートファイルシステムのみを読み取り専用にするので、tmpfs:recurse=0 を指定するらしいです。
以下が参考になりました。

https://gihyo.jp/admin/serial/01/ubuntu-recipe/0568

これで再起動すれば、ルートファイルシステムのみが読み取り専用となり、/var は読み書き可能な状態となります。
docker も普通に使えました。

参考 URL

WSL2 上の Docker コンテナに外部からアクセスする

Fri, 29 Jul 2022 00:00:00 +0900

Ubuntu で Docker を使っている場合はホストとコンテナのポートマッピングさえ行えば外部からアクセスできました。
しかし、WSL2 を使っている場合は Windows と WSL2(Ubuntu) のポートフォワーディングの設定を行わないと外部からはアクセスできません。

尚、タイトルには「Docker コンテナに外部からアクセス」と書きましたが、Windows と WSL2 の話なので、Docker は関係ありません。

環境

ホスト: Windows 10
WSL2: Ubuntu 20.04

設定方法

WSL2 の IP アドレスを調べる

まずは WSL2 上で以下のコマンドを実行し、eth0 の IP アドレスを調べます。

$ ip addr show dev eth0

または hostname -I でも調べられます。

Windows と WSL2 のポートフォワーディング設定

コマンドプロンプトまたは PowerShell で以下のコマンドを実行します。

> netsh interface portproxy add v4tov4 listenport=<ポート> connectaddress=<WSL2のIPアドレス>

これで外部からアクセス可能になります。
設定ができているか確認したい場合は以下のコマンドを実行します。

> netsh interface portproxy show v4tov4

ipv4 をリッスンする: ipv4 に接続する:

Address Port Address Port
--------------- ---------- --------------- ----------
* 5001 172.20.93.38 5001

設定を削除したい場合は以下のコマンドを実行します。

> netsh interface portproxy delete v4tov4 listenport=<ポート>

設定の自動化

WSL2 の IP アドレスは起動の度に変わるので、Windows 起動時に自動で設定するようにします。

Windows 上で WSL2 の IP アドレスを取得

PowerShell で以下を実行します。

> $IP = wsl -d Ubuntu-20.04 exec hostname -I

しかし、私の環境では複数の IP アドレスが表示されてしまいました。

> $IP
172.20.93.38 172.17.0.1 172.18.0.1

なので、以下のようにスペースで区切って最初の IP アドレスだけを取得できるようにしました。

> $IP = (wsl -d Ubuntu-20.04 exec hostname -I).split(" ")[0]

スクリプトファイルの作成と実行

以上を踏まえ、以下のようなスクリプトファイルを作成します。

$IP = (wsl -d Ubuntu-20.04 exec hostname -I).split(" ")[0]
netsh interface portproxy delete v4tov4 listenport=<ポート>
netsh interface portproxy add v4tov4 listenport=<ポート> connectaddress=$IP

あとはこれをタスクスケジューラーでログオン時に実行するようにすれば OK です。

参考 URL

ImageMagick で画像を一括で変換

Wed, 27 Jul 2022 00:00:00 +0900

Ubuntu で大量の画像ファイルを一括で変換したいときは、ImageMagick のコマンドを使うと便利です。

インストール

私の環境では最初からインストールされていましたが、ない場合は以下でインストールできます。

$ sudo apt install imagemagick

画像の変換

例えば、全ての png 画像を jpg に変更したい場合は以下のようにしします。

$ mogrify -format jpg *.png

元のファイルは残ったままです。

リサイズ

jpg ファイルを全てリサイズしたい場合、以下のようにします。

$ mogrify -resize 100x100 *.jpg

ただし、この場合アスペクト比は維持されます。なので、例えば、640x360 の画像を上記のコマンドでリサイズすると、100x56 のサイズになります。

アスペクト比を無視して強制的にリサイズしたい場合は ! をつけます。

$ mogrify -resize 100x100! *.jpg

また、割合で指定したい場合は以下のようにします。

$ mogrify -resize 50% *.jpg

参考 URL

docker-compose.yml で HOSTNAME が参照できない？

Thu, 30 Jun 2022 00:00:00 +0900

docker-compose.yml で $HOSTNAME と記述すると以下のようなエラーが表示され、かなりはまってしまいました。

The HOSTNAME variable is not set. Defaulting to a blank string

Ubuntu では HOSTNAME が export されていないそうなので、環境変数として参照できないようです。
どうやらかなり昔からの仕様のようですが、Ubuntu 20.04 でも状況は変わっていません。

https://ubuntuforums.org/archive/index.php/t-898924.html

私は誤解していましたが、HOSTNAME は環境変数ではなくシェル変数です。

そして、export されていないから環境変数として yml からは参照できないと。
なので、以下のようにすれば参照できるようになります。

$ export HOSTNAME && docker-compose up

毎回 export するのが面倒な場合は .bashrc に書いておくのがいいかもしれません。

参考 URL

[Docker] ログドライバーでログの出力先を syslog に設定する

Thu, 23 Jun 2022 00:00:00 +0900

Docker コンテナで標準出力されているログを syslog に記録するようにログドライバーを設定します。

Docker のログドライバーで設定できるものには他にもいろいろあります。

https://matsuand.github.io/docs.docker.jp.onthefly/config/containers/logging/configure/

オプションはログドライバーによって異なるようで、syslog の場合は以下になります。

https://matsuand.github.io/docs.docker.jp.onthefly/config/containers/logging/syslog/

以上を踏まえ、docker-compose でログドライバーを設定する例が以下になります。

logging:
 driver: syslog
 options:
 tag: 'my-app-name'

デフォルトでは appname がコンテナIDになって分かりづらいので、tag で設定しています。

余談

コンテナ内で動かしている Python のアプリケーションでは、もともと logging モジュールで syslog に記録するよう設定していました。
これを標準出力にし、Docker のログドライバーで設定できるようにすれば、コンテナを使う側が出力先を決められて便利かなと思いました。

しかし、Python 側では5段階に分けられていたログレベルが、標準出力を介すことで、Info (stdout) と Error (stderr) の2レベルに平坦化されてしまうことが分かり、結局 Python 側で syslog に記録するようにしました。

もしかしたから何か上手いやり方があるのかもしれませんが・・・。

参考 URL

https://qiita.com/Esfahan/items/5e5a9ae7882bb0eaaf5f

[Docker] コンテナ内からホストにアクセスする

Fri, 17 Jun 2022 00:00:00 +0900

コンテナ内では localhost はコンテナ自身を指すので使えません。
かといってホストの IP アドレスを直接参照すると、IP アドレスが変わったときに困ります。

このような場合、host.docker.internal を使います。

host.docker.internal はもともと Windows と Mac でしか使えなかったようですが、Docker 20.10 からLinux でも使えるようになったそうです。
この機能を有効化するには --add-host で host.docker.internal:host-gateway を指定する必要があるようです。

$ docker run -it --rm \
 --add-host=host.docker.internal:host-gateway \
 image_name

docker-compose の場合は extra_hosts で指定します。

services:
 app:
 extra_hosts:
 - "host.docker.internal:host-gateway"

参考 URL

[Docker] コンテナ内からホストにアクセスする

Thu, 16 Jun 2022 00:00:00 +0900

ググってもなかなかサンプルが見当たらずかなりはまりました。

最終的には以下のページが参考になりました。

https://qiita.com/shiitake256/items/a9cd1f525fd97c224f52

Docker + Traefik の基本的な設定は以前の記事をご覧ください。

https://kuttsun.blogspot.com/2022/06/docker-traefik.html

環境

Docker 20.10.12
Traefik v2.7

イメージ図

やりたいことは以下のような感じです。

<ホストのURL>/api1/ へのアクセスはポート3000へ
<ホストのURL>/api2/ へのアクセスはポート4000へ

サンプル

簡単な解説をコメントに書いています。

ports:
 - 3000:3000
 - 4000:4000
labels:
 - traefik.enable=true
 #------------------------------
 # foo という名前のルーターを定義し、エントリーポイント http と関連付け
 - traefik.http.routers.foo.entrypoints=http
 # リクエストパス /api1 とマッチするよう指定
 - traefik.http.routers.foo.rule=PathPrefix(`/api1{regex:$$|/.*}`)
 # foo-middleware という名前のミドルウェアを定義し、ルーター foo と関連付け
 - traefik.http.routers.foo.middlewares=foo-middleware
 # サービスにリクエストを行う前にリクエストパスの先頭の /api1 を取り除くように指定
 - traefik.http.middlewares.foo-middleware.stripprefix.prefixes=/api1
 # foo-service という名前のサービスを定義し、ルーター foo と関連付け
 - traefik.http.routers.foo.service=foo-service
 # foo-service へのアクセスをポート3000 へ飛ばす
 - traefik.http.services.foo-service.loadbalancer.server.port=3000
 #------------------------------
 - traefik.http.routers.bar.entrypoints=http
 - traefik.http.routers.bar.rule=PathPrefix(`/api2{regex:$$|/.*}`)
 - traefik.http.routers.bar.middlewares=bar-middleware
 - traefik.http.middlewares.bar-middleware.stripprefix.prefixes=/api2
 - traefik.http.routers.bar.service=bar-service
 - traefik.http.services.bar-service.loadbalancer.server.port=4000

ports でホストのポートとマッピングしていますが、実際には expose でコンテナ側のポートを開けるだけのほうがよいと思います。

参考 URL

Docker + Traefik で複数のポートを公開しているコンテナのルーティングを行う

Wed, 15 Jun 2022 00:00:00 +0900

ググってもなかなかサンプルが見当たらずかなりはまりました。

最終的には以下のページが参考になりました。

https://community.traefik.io/t/docker-container-with-multiple-ports/4657/2

Docker + Traefik の基本的な設定は以前の記事をご覧ください。

https://kuttsun.blogspot.com/2022/06/docker-traefik.html

環境

Docker 20.10.12
Traefik v2.7

イメージ図

やりたいことは以下のような感じです。

api1.localhost へのアクセスはポート3000へ
api2.localhost へのアクセスはポート4000へ

サンプル

簡単な解説をコメントに書いています。

ports:
 - 3000:3000
 - 4000:4000
labels:
 - traefik.enable=true
 #------------------------------
 # foo という名前のルーターを定義し、
 # エントリーポイント http (traefik側で設定した任意の名前) と関連付け
 - traefik.http.routers.foo.entrypoints=http
 # ルーター foo のホスト名を "api1.localhost" に設定
 - traefik.http.routers.foo.rule=Host(`api1.localhost`)
 # foo-service という名前のサービスを定義し、ルーター foo と関連付け
 - traefik.http.routers.foo.service=foo-service
 # foo-service へのアクセスをポート3000 へ飛ばす
 - traefik.http.services.foo-service.loadbalancer.server.port=3000
 #------------------------------
 - traefik.http.routers.bar.entrypoints=http
 - traefik.http.routers.bar.rule=Host(`api2.localhost`)
 - traefik.http.routers.bar.service=bar-service
 - traefik.http.services.bar-service.loadbalancer.server.port=4000

ports でホストのポートとマッピングしていますが、実際には expose でコンテナ側のポートを開けるだけのほうがよいと思います。

参考 URL

Docker + Traefik でリバースプロキシサーバーを立てる

Tue, 14 Jun 2022 00:00:00 +0900

最初 nginx でリバースプロキシサーバーを構築していたのですが、いろいろ調べていく中で Traefik というサーバーの存在を知りました。

https://doc.traefik.io/traefik/

公式ではエッジルーターという言い方がされていますが、要はリバースプロキシ＋ロードバランサーという感じらしいです。
nginx より後発で、Docker との親和性が高いとのことで試しに使ってみました。

環境

Docker: 20.10.12
Traefik: v2.7

Traefik 自身も Docker で動かします。

docker network の作成

アプリと Traefik で共通で使用するネットワークを作成しておきます。

$ docker network create sample-network

Traefik の設定

Traefik の設定は /etc/traefik/traefik.yml に記述する方法と、docker-compose.yml で指定する方法があるようです。
前者の例が多いですが、後者の方が docker-compose.yml 一つで設定が完結して良いと思うのは私だけでしょうか？

設定ファイルに記述する例

traefik.yml というファイルを作成して、以下のように記述します。

# Providers config
providers:
 # Docker との連携を有効にする
 docker:
 # false に指定することで Label 付けしていない docker コンテナを Traefik が無視するようになる
 exposedByDefault: false
 # 使用するネットワーク
 network: sample-network
entryPoints:
 # http という任意の名前のエントリーポイントを定義し、80番ポートをリッスンするよう指定
 http:
 address: ':80'
 https:
 address: ':443'
# API/Dashboard config
api:
 # WebUI にアクセスできるように設定
 insecure: true

Trafik を起動します。
ネットには docker-compose を使った例が多いですが、とりあえず docker run で動かしてみます。

$ docker run -it --rm \
 --name reverse-proxy \
 --network sample-network \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v $(pwd)/traefik.yml:/etc/traefik/traefik.yml \
 -p 80:80 \
 -p 8080:8080 \
 traefik:v2.7

とりあえずこれで、http://localhost:8080 にアクセスすると Traefik の WebUI が表示されるかと思います。

docker-compose.yml で設定する例

上記の設定を docker-compose.yml のみで行った場合の例です。

version: '3.9'
services:
 reverse-proxy:
 image: traefik:v2.7
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 # ファイルで設定する場合は以下
 #- type: bind
 # source: ./traefik.yml
 # target: /etc/traefik/traefik.yml
 ports:
 - 80:80
 - 8080:8080
 networks:
 - sample-network
 command:
 # traefik.yml の代わりに command で設定
 - --providers.docker.exposedByDefault=false
 - --providers.docker.network=sample-network
 - --entryPoints.http.address=:80
 - --entryPoints.https.address=:443
 - --api.insecure=true
networks:
 sample-network:
 external: true

アプリケーション側の設定

ルーティングの設定などは全てコンテナのラベルで設定します。他のサーバーだとサーバー側の設定を変更する必要がありますが、 Traefik+Docker だとコンテナの増減に対して対応しやすいなと思いました。

とりあえず docker run で動かしてみます。

docker run -it --rm \
 --network sample-network \
 -l "traefik.enable=true" \
 -l "traefik.http.routers.api.entrypoints=http" \
 -l "traefik.http.routers.api.rule=Host(\"api.localhost\")"
 sample_app

これで http://api.localhost/ に該当のアプリにアクセスすれば繋がると思います。
解説は次に書いてあります。

docker-compose での例

上記の設定は、docker-compose.yml で以下のように設定します。
コメントで簡単な解説をつけておきました。

labels:
 # Traefik の有効化(exposedByDefault:false に設定した場合に必要)
 - traefik.enable=true
 # api という名前のルーターを定義し、
 # エントリーポイント http (traefik.yml で定義した名前) と関連付け
 - traefik.http.routers.api.entrypoints=http
 # ルーター api のホスト名を "api.localhost" に設定
 - traefik.http.routers.api.rule=Host(`api.localhost`)

基本は以上です。
他の詳細な設定については追々記事を書こうかなと思っています。

参考 URL

Docker コンテナ内から Docker コマンドを使う

Thu, 26 May 2022 00:00:00 +0900

Docker コンテナ内のアプリケーションから Docker コンテナの操作をしたかったので、やってみました。

環境

Docker 20.10.12

DinD と DooD

Docker コンテナ内から Docker を扱う方法としては以下の２つがあるようです。

DinD: Docker in Docker
- Docker コンテナの中で Docker デーモンを動かす
- コンテナの中にコンテナを作成したりできる
- 非推奨
DooD: Docker outside of Docker
- ホストの docker.sock をコンテナにマウントし、Docker デーモンを共有する
- ホスト上の Docker コンテナを操作できる
- 基本的にこちらを使う

ここらへん以下のページが分かりやすかったです。

https://qiita.com/YukiMiyatake/items/2e68aa69a5ca3921d55d

DinD は Docker の開発用途のためのものらしく、セキュリティリスクなどもあることから非推奨で、基本的には DooD のほうを使うべきだそうです。
今回の用途的にも DooD のほうなので、DooD を試してみました。

DooD サンプル

ググってみると以下のようなサンプルが多いです。

$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker

確かにこれでコンテナ内で docker コマンドが使えました。
この場合では docker という Docker 一式が入ったイメージを使っているので、/var/run/docker.sock をマウントするだけで使えています。

しかし、実際にはアプリケーションのランタイムイメージをベースとすることが多いと思います。
試しに Ubuntu のイメージを使うと、以下のようにエラーになります。

$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu:20.04
# docker ps
bash: docker: command not found

Docker クライアントがインストールされていないからです。

この場合、コンテナ内で docker.io をインストールすれば docker コマンドが使えるようになります。
ついでに docker-compose もインストールしています。

$ sudo apt update
$ sudo apt install -y docker.io docker-compose

というわけで、DooD では

/var/run/docker.sock をマウント
ベースイメージに Docker クライアントがインストールされていなければインストール

で、コンテナ内から Docker コマンドが使えるようになります。

参考 URL

Ubuntu の IP アドレスを固定化する

Fri, 20 May 2022 00:00:00 +0900

いつもは GUI で設定するのですが、あるとき IP アドレスを変更しても再起動後に元に戻ってしまうという現象が発生して悩んでいました。
調べたら他の人が IP アドレスを固定化してたのが原因だとわかったので、ついでにそのやり方をメモしておきます。

環境

Ubuntu 20.04

設定方法

/etc/netplan/ に yaml ファイルを作成します。

ここに作成したファイルが名前順に読み込まれ、後に読み込まれた内容のほうが優先されるようです。

Ubuntu Desktop の場合、デフォルトで 01-network-manager-all.yaml があり、ネットワークマネージャーでの設定が反映されるようになっています。

IP アドレスを固定化したい場合は、/etc/netplan/99_config.yaml など、後に読み込まれるようなファイル名でファイルを作成し、設定を上書きしてやるそうです。
yaml ファイルの書き方なども含め、公式ドキュメントは以下になります。

https://ubuntu.com/server/docs/network-configuration

例えば以下のような感じです。

network:
 version: 2
 ethernets:
 eth0:
 addresses:
 - 192.168.1.10/24
 gateway4: 192.168.1.1
 optional: true

参考 URL

Jetson Xavier NX でルートファイルシステムを overlayroot で読み込み専用に設定する

Tue, 26 Apr 2022 00:00:00 +0900

以前、Ubuntu で overlayroot を使ってルートファイルシステムを読み込み専用にしてみたのですが、Jetson Xavier NX で同じように試してみたところ、それだけではだめでした。

恐らくですが、ブートローダーが EXTLINUX であることが原因のような気がしています。

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/uboot_guide.html#wwpID0E0YD0HA

Jetson Xavier NX ではどうやってやればいいのかググってみると、NVIDIA のフォーラムで議論されているのが見つかりました。

その中で、解決策として提示されていたのが以下です。

https://github.com/negachov/overlayroot-jetpack

環境

Jetson Xavior NX
Ubuntu 18.04
JetPack 4.5.1

overlayroot のインストールと有効化

以下の記事を参考にしてください。

https://kuttsun.blogspot.com/2022/04/overlayroot-ubuntu.html

Jetson Xavier NX ではこれに加え、次のことが必要でした。

/boot/initrd の置き換え

GitHub にスクリプトが公開されているので、まずこれをクローンします。

$ git clone https://github.com/negachov/overlayroot-jetpack

あとは以下を実行するだけです。

$ cd overlayroot-jetpack
$ sudo ./update-initramfs-jetpack
$ reboot

これで、再起動後に overlayroot が有効になっていました。

参考 URL

Ubuntu のファイルシステムを overlayroot で読み込み専用にする

Mon, 25 Apr 2022 00:00:00 +0900

電源ブチ切り対策の一環として、overlayroot で Ubuntu の rootfs を read only にしてみました。

やり方はいろいろググってみましたが、以下のサイトがとても参考になりました。

環境

Ubuntu 20.04 (デスクトップ版)

現在の状態を確認

mount コマンドで確認してみます。

$ mount

抜粋ですが、以下の状態が確認できます。

/dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro)

overlayroot のインストール

サーバー版には最初からインストールされているそうですが、デスクトップ版にはインストールされていないので、apt でインストールします。

$ sudo apt install overlayroot

overlayroot の有効化

overlayroot を有効化するには、以下のいずれかの対応が必要だそうです。

カーネルパラメーターに overlayroot=XXX を指定する
/etc/overlayroot.local.conf に overlayroot="XXX" を指定する
/etc/overlayroot.conf に overlayroot="XXX" を指定する

設定内容は上位のほうが優先されるそうです。
今回は /etc/overlayroot.local.conf に設定を追加します。
まずはエディタで開きます。

$ sudo gedit /etc/overlayroot.local.conf

以下を追記します。

overlayroot="tmpfs"

コマンド一発でやるなら以下です。

$ echo 'overlayroot="tmpfs"' | sudo tee -a /etc/overlayroot.local.conf

tmpfs はメモリ上に作成ファイルシステムで、一時的にデータを格納するために使われます。

https://linuc.org/study/knowledge/441/

Linux ではマウントするファイルシステムの情報が /etc/fstab に書かれていますが、ここが overlayroot における下位レイヤーとなり、読み込み専用レイヤーとなります。
そして、先ほど追記した tempfs が上位レイヤーとなり、書き込み可能レイヤーとなります。
ここらへんは後述するように mount コマンドで確認可能です。

ただし、tmpfs はメモリ上に作成されたファイルシステムなので、再起動時にはデータは消えます。

ルートファイルシステムのみを読み取り専用にする

パーティションを分けている場合などで、ルートファイルシステムのみを読み取り専用にするためには、/etc/overlayroot.local.conf に tmpfs:recurse=0 を指定するらしいです。
コマンド一発でやる場合は以下。

https://gihyo.jp/admin/serial/01/ubuntu-recipe/0568

echo 'overlayroot="tmpfs:recurse=0"' | sudo tee -a /etc/overlayroot.local.conf

これで再起動すれば、ルートファイルシステムのみが読み取り専用となり、他のパーティションは読み書き可能な状態となります。

確認

先ほどと同じように mount コマンドで確認してみます。

$ mount

抜粋ですが、以下の状態が確認できました。

/dev/sda2 on /media/root-ro type ext4 (ro,relatime)
tmpfs-root on /media/root-rw type tmpfs (rw,relatime,inode64)
overlayroot on / type overlay (rw,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_)

ルートファイルシステムが /media/root-ro に読み込み専用(ro)の下位レイヤー(lowerdir) として設定され、tmpfs が /media/root-rw/overlay に書き込み可能(rw)な上位レイヤー(upperdir) して設定されているのが確認できます。

ファイルが消えることを確認

ついでに、ホームディレクトリに適当にファイルを作成し、再起動時にファイルが消えていることを確認します。

overlayroot の無効化

/etc/overlayroot.local.conf を削除するか、/etc/overlayroot.local.conf を編集して中身を overlayroot="" に変更すれば、overlayroot の無効化されます。

しかし、現在は overlayroot が有効化になっている状況なので、このまま変更しても再起動後にはまた元に戻ってしまいます。
そのため、この変更は一時的に書き込みを許可した状態で行う必要があります。
一時的に書き込み可能な状態にするには以下のコマンドを実行します。

$ sudo overlayroot-chroot

そして、/etc/overlayroot.local.conf を削除するか、/etc/overlayroot.local.conf を編集して中身を overlayroot="" に変更します。

# rm /etc/overlayroot.local.conf

exit でシェルから抜ければ書き込み可能状態は終了します。

# exit

再起動後、overlayroot が無効状態になっています。

GRUB メニューで時間がかかることの対策

overlayroot を有効にした状態で再起動すると、GRUB メニューが表示され、30秒ほど待たされるようになります。
詳細は以下をご参照ください。

https://gihyo.jp/admin/serial/01/ubuntu-recipe/0568

起動が30秒も遅くなるのは困るので、以下を参考にして GRUB の設定を変更しました。

※以下は overlayroot を無効にした状態で行う必要があります！

/etc/default/grub をエディタで開きます。

$ sudo nano /etc/default/grub

以下を追記します。

GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT

設定を反映するために以下のコマンドを実行します。

$ sudo grub-mkconfig -o /boot/grub/grub.cfg

これで overlayroot を有効にしても起動時間は変わらなくなりました。

参考 URL

Ubuntu に GitLab-Runner を直接インストールする

Thu, 14 Apr 2022 00:00:00 +0900

docker で GitLab-Runner を動かしたことはありましたが、今回初めてホストに直接インストールしました。

公式ドキュメントは以下です。

https://docs.gitlab.com/runner/install/

インストール

apt でインストール

まずはリポジトリを追加します。

$ curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

apt でインストールします。

$ sudo apt-get install gitlab-runner

しかし、この方法でインストールしたら結構古いバージョン (11.2.0) がインストールされてしまいました。
最新のバージョンは 14.9.1 のはずなんですが・・・。

今動かしている GitLab と互換性がなく上手く動かなったので、最終的には次に示すように deb パッケージからインストールしました。

deb パッケージからインストール

https://docs.gitlab.com/runner/install/linux-manually.html

ドキュメントだと curl を使うようになっていますが、上手くダウンロードできなかったのと、環境変数 arch が空だったので、以下のコマンドでダウンロードしました。

$ wget "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb"

次のコマンドでインストールします。

$ dpkg -i gitlab-runner_amd64.deb

GitLab への登録

インストールが完了したら Gitlab-Runner を GitLab に登録します。

https://docs.gitlab.com/runner/register/index.html#linux

$ sudo gitlab-runner register

対話形式で入力していきます。

まず、GitLab の URL を指定します。

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://gitlab.example

次にトークンを入力します。
トークンは GitLab に管理者でログインし、Menu > Admin > Runner で確認できます。

Please enter the gitlab-ci token for this runner:
U6YYzWyiQYzzfCdDH1dv

ランナーの詳細を入力します。

Please enter the gitlab-ci description for this runner:

ランナーを識別するためのタグを指定します。

Please enter the gitlab-ci tags for this runner (comma separated):

次はオプションなので何も入力せず進みました。

Enter optional maintenance note for the runner:

最後にスクリプトの実行方法を指定します。
今回はホスト上で直接実行させたかったので、shell を指定します。

Please enter the executor: virtualbox, docker+machine, docker, docker-ssh, parallels, kubernetes, shell, ssh, docker-ssh+machine:

GitLab の Menu > Admin > Runner で登録されたことが確認できます。

参考 URL

Ubuntu に SSD をマウント

Sat, 09 Apr 2022 00:00:00 +0900

Ubuntu 20.04 のマシンに 2.5インチの SSD を追加し、起動時に自動でマウントするようにしました。

以下のページが参考になりました。

https://qiita.com/suisuina/items/7b55a640fdd6b299aa46

手順

UUID の確認

GUI で確認

Ubuntu の場合、メニューから disks を起動すれば、GUI で確認可能です。

コマンドで確認

まずは以下のコマンドでウントしたい SSD のパスを探します。

$ sudo fdisk -l

...

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 312580095 312578048 149.1G 83 Linux

今回は /dev/sda1 でした。
次に以下のコマンドで UUID を確認します。

$ sudo blkid /dev/sda1
/dev/sda1: LABEL="ssd" UUID="74172d4c-526a-42ac-9215-b6ea2dd93d9e" TYPE="ext4" PARTUUID="cb5573bc-01"

起動時にマウントするように設定

/etc/fstab を編集します。

$ sudo nano /etc/fstab

以下を追記します。

UUID=XXXXX /mnt/ssd auto defaults 0 0

今回マウント先は /mnt/ssd としました。

再起動して確認します。

Docker イメージの保存先を変更

Fri, 08 Apr 2022 00:00:00 +0900

ストレージの容量が少ない場合など、新たに SSD を接続し、そちらに Docker イメージを保存する方法です。

以下のページが参考になりました。

https://github.com/atinfinity/lab/wiki/change_docker_image_directory

環境

Ubuntu 18.04

手順

Docker サービスの停止

$ sudo service docker stop

既存データの退避

既存のデータは /var/lib/docker にあるので、これを外部ストレージに移動します。
SSD は /mnt/ssd にマウントしており、そこに docker というディレクトリを作成してデータを移動します。

$ sudo mkdir /mnt/ssd/docker
$ sudo rsync -aXS /var/lib/docker/. /mnt/ssd/docker/

設定変更

/etc/docker/daemon.json を開きます。

$ sudo nano /etc/docker/daemon.json

以下を記述して、保存先を /mnt/ssd/docker に設定します．

{
 "graph": "/mnt/ssd/docker"
}

設定の反映

$ sudo systemctl daemon-reload
$ sudo service docker start

動作確認

$ docker info | grep "Docker Root Dir"
Docker Root Dir: /mnt/ssd/docker

古いデータを削除

/var/lib/docker を削除します。

$ sudo rm -rf /var/lib/docker

`error creating overlay mount to` というエラーが表示される

Docker コンテナを作成しようとした際に、error creating overlay mount to みたいなエラーが表示されました。
私の場合はファイルシステムが NTFS だったことが原因でした。
EXT4 でフォーマットすれば正常にできました。

参考 URL

https://github.com/atinfinity/lab/wiki/change_docker_image_directory

nvidia-docker2 (nvidia-container-toolkit) のインストール

Thu, 31 Mar 2022 00:00:00 +0900

Docker コンテナ内で GPU を使うためには NVIDIA Container Toolkit をインストールする必要があります。

公式ドキュメントは以下です。

https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

インストール方法

上記のページにインストール手順も書いてあります。
（以下は見やすくするためにコマンドを分割しています。）

$ distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
$ curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add -
$ curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
$ sudo apt update
$ sudo apt install -y nvidia-docker2

nvidia-docker2 がトップレベルのパッケージらしいので、インストールするときは nvidia-container-toolkit ではなく nvidia-docker2 を指定するようです。
ここらへん以下のページが参考になりました。

https://qiita.com/tkusumi/items/f275f0737fb5b261a868

まぁ公式ドキュメントが nvidia-docker2 をインストールするようになっていますし、それに従えばよいかと。

また、古い記事では nvidia-docker と書いてあったりしますが、ここらへんの変遷は以下が参考になりました。

https://qiita.com/ksasaki/items/b20a785e1a0f610efa08

動作確認

nvidia-container-cli で確認できます。

$ nvidia-container-cli --version
cli-version: 1.8.1
lib-version: 1.8.1
build date: 2022-02-14T12:02+00:00
build revision: abd4e14d8cb923e2a70b7dcfee55fbc16bffa353
build compiler: x86_64-linux-gnu-gcc-7 7.5.0
build platform: x86_64
build flags: -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -DNDEBUG -std=gnu11 -O2 -g -fdata-sections -ffunction-sections -fplan9-extensions -fstack-protector -fno-strict-aliasing -fvisibility=hidden -Wall -Wextra -Wcast-align -Wpointer-arith -Wmissing-prototypes -Wnonnull -Wwrite-strings -Wlogical-op -Wformat=2 -Wmissing-format-attribute -Winit-self -Wshadow -Wstrict-prototypes -Wunreachable-code -Wconversion -Wsign-conversion -Wno-unknown-warning-option -Wno-format-extra-args -Wno-gnu-alignof-expression -Wl,-zrelro -Wl,-znow -Wl,-zdefs -Wl,--gc-sections

$ nvidia-container-cli info
NVRM version: 470.103.01
CUDA version: 11.4

Device Index: 0
Device Minor: 0
Model: NVIDIA GeForce RTX 3080
Brand: GeForce
GPU UUID: GPU-565ac97c-fe71-f49b-1ac0-7ac93c7dab8d
Bus Location: 00000000:01:00.0
Architecture: 8.6

参考 URL

Ubuntu 20.04 に古い NVIDIA Driver と CUDA をインストール

Wed, 30 Mar 2022 00:00:00 +0900

古いグラフィックボードが手に入ったので、それに対応した NVIDIA Driver および CUDA をインストールしたときのメモです。

環境

Ubuntu 20.04
GPU：NVIDIA Quadro 2000

NVIDIA Driver のインストール

以下のコマンドでインストールするドライバーのバージョンがわかります。

$ ubuntu-drivers devices

または、以下のページで必要なドライバーのバージョンを調べることもできます。

https://www.nvidia.com/Download/index.aspx

以上より必要なドライバーは 390 だとわかりました。
ドライバーは上記のページからダウンロードできますが、Ubuntu の場合は apt でインストールしたほうが楽です。

$ sudo apt -y install nvidia-driver-390

一度再起動し、nvidia-smi でドライバーが正しくインストールされたか確認します。

$ nvidia-smi
Tue Mar 15 13:51:47 2022
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.144 Driver Version: 390.144 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Quadro 2000 Off | 00000000:01:00.0 On | N/A |
| 30% 48C P12 N/A / N/A | 577MiB / 964MiB | 0% Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 1193 G /usr/lib/xorg/Xorg 141MiB |
| 0 2102 G /usr/lib/xorg/Xorg 220MiB |
| 0 2276 G /usr/bin/gnome-shell 206MiB |
+-----------------------------------------------------------------------------+

CUDA のインストール

NVIDIA Driver と CUDA のバージョンの関係は以下で確認できます。

https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html

今回インストールした NVIDIA Driver は 390.144 なので、CUDA は 9.1 インストールします。

CUDA のインストール方法ですが、以下でプラットフォームに応じた方法を調べることができます。

https://developer.nvidia.com/cuda-downloads

Ubuntu 20.04 では以下が表示されました。

$ wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin
$ sudo mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600
$ sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/7fa2af80.pub
$ sudo add-apt-repository "deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/ /"
$ sudo apt-get update
$ sudo apt-get -y install cuda

しかし、このコマンドでは CUDA のバージョンが指定されていないため、実行してしまうと最新の CUDA がインストールされてしまいます。
なので、次に示すように、バージョン 9.1 を指定してインストールしてやります。

CUDA 9.1 のインストール

CUDA 9.1 をインストールしたいところですが、apt でインストールできる CUDA の一覧を見てみても 9.1 はありません。
なので、以下を参考に Ubuntu 16.04 用のパッケージをインストールしました。

$ curl -sL http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub | sudo apt-key add

$ wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
$ sudo dpkg -i cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
$ sudo apt update

$ sudo apt --fix-broken install
$ sudo apt install cuda-toolkit-9-1
$ sudo reboot
$ rm cuda-repo-ubuntu1604_9.1.85-1_amd64.deb

注意点として、apt で cuda-9-1 をインストールすると NVIDIA Driver も最新に更新されてしまうので、cuda-toolkit-9-1 をインストールする必要があります。

https://zenn.dev/takeshita/articles/a02402e59d72a7

インストールが完了したら、~/.bashrc の末尾に以下を追記します。

export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="/usr/local/cuda/lib64:$LD_LIBRARY_PATH"

ここで再起動します。

CUDA バージョンの確認

nvidia-smi で確認できるはずなのですが、私の環境では何も表示されました。
ただ、nvcc では確認できたので、インストールはされているんじゃないかと。

$ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2017 NVIDIA Corporation
Built on Fri_Nov__3_21:07:56_CDT_2017
Cuda compilation tools, release 9.1, V9.1.85

また、以下でも確認できます。

$ cat /usr/local/cuda/version.txt
CUDA Version 9.1.85

CUDA のインストール後に NVIDIA Driver がおかしくなってしまった場合

前述したように、NVIDIA Driver と CUDA のバージョンが合っていなければ動作がおかしくなります。

以下を参考に NVIDIA Driver と CUDA を削除してからインストールをやり直す必要があります。

https://qiita.com/not_charge/items/dce7512544a7ead04bca

$ sudo apt-get --purge remove nvidia-*
$ sudo apt-get --purge remove cuda-*

docker コンテナ内で GPU が使えるか確認しようとして諦めた

せっかく CUDA がインストールできたので、機械学習で GPU が使えそうか確認します。
まず pytorch を使い、ホスト上で以下のコードで確認してみました。

import torch
print(torch.cuda.is_available())

すると、以下のようにエラーが表示されました。

UserWarning: CUDA initialization: The NVIDIA driver on your system is too old (found version 9010). Please update your GPU driver by downloading and installing a new version from the URL: http://www.nvidia.com/Download/index.aspx Alternatively, go to: https://pytorch.org to install a PyTorch version that has been compiled with your version of the CUDA driver. (Triggered internally at /pytorch/c10/cuda/CUDAFunctions.cpp:115.)
 return torch._C._cuda_getDeviceCount() > 0

PyTorch のバージョンも CUDA に合わせる必要があるようです。
以下のページを参考に pytorch のバージョンを指定してインストールしてみます。

https://varhowto.com/install-pytorch-cuda-9-1/

すると以下のエラーが表示されました。

$ pip3 install torch==1.1.0 torchvision==0.3.0 -f https://download.pytorch.org/whl/cu90/torch_stable.html
Looking in links: https://download.pytorch.org/whl/cu90/torch_stable.html
/usr/share/python-wheels/urllib3-1.25.8-py2.py3-none-any.whl/urllib3/connectionpool.py:999: InsecureRequestWarning: Unverified HTTPS request is being made to host '172.20.16.253'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
ERROR: Could not find a version that satisfies the requirement torch==1.1.0 (from versions: 1.4.0, 1.5.0, 1.5.1, 1.6.0, 1.7.0, 1.7.1, 1.8.0, 1.8.1, 1.9.0, 1.9.1, 1.10.0, 1.10.1, 1.10.2, 1.11.0)
ERROR: No matching distribution found for torch==1.1.0

ここらへんから面倒になり、先に docker コンテナを作ることにしました。
まずは NVIDIA Container Toolkit をインストールしようと以下のページを見ると、

https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

動作要件が以下のようになっていました。

GNU/Linux x86_64 with kernel version > 3.10
Docker >= 19.03 (recommended, but some distributions may include older versions of Docker. The minimum supported version is 1.12)
NVIDIA GPU with Architecture >= Kepler (or compute capability 3.0)
NVIDIA Linux drivers >= 418.81.07 (Note that older driver releases or branches are unsupported.)

というわけでここで諦めました。

参考 URL

Windows PC から NAS に接続できなくなった

Sat, 19 Mar 2022 00:00:00 +0900

ちょっと古めの NAS を持っているのですが、Windows 10 の PC からアクセスできなくなりました。

以前はアクセスできていたはずなのですが、いつの間にかアクセスできなくなっていました。スマホからはアクセスできているので機器の故障ではなく、またネットワークに問題がないことも確認済みです。

んで、いろいろ調べていたのですが、どうやらその NAS には SMB1 のプロトコルでアクセスする必要があるみたいで、Windows 10 では機能を有効化しないといけないようです。

上述したように以前はアクセスできていたはずなんですけど・・・、Windows Update かなんかで設定が変わったんですかね？

[スタート]-[Windows システムツール]-[コントロールパネル] を開く
[プログラム]-[プログラムと機能] を開く
[Windows の機能の有効化または無効化] をクリック
「SMB 1.0/CIFS ファイル共有のサポート」の「SMB 1.0/CIFS クライアント」にチェックを入れて [OK] をクリック

1. [今すぐ再起動]をクリックする。

再起動後にアクセスできるようになりました。

参考 URL

Ubuntu にリモートデスクトップ接続する

Sun, 13 Mar 2022 00:00:00 +0900

Windows から Ubuntu にリモートデスクトップで接続する方法です。

Ubuntu 側

Xrdp サーバーをインストールします。

$ sudo apt -y install xrdp

Windows 側

リモートデスクトップで Ubuntu の IP アドレスを入力して接続します。

画面が真っ暗な場合

同じユーザーで既に Ubuntu にログイン済みの場合、真っ暗な画面が表示されます。

Ubuntu 側で一度ログアウトするか、別途 SSH などで Ubuntu に接続し、以下のコマンドで gnome-session を終了させます。

$ pkill gnome-session

参考 URL

Ubuntuでデスクトップにアプリのショートカットを作る（デスクトップエントリ）

Sat, 12 Feb 2022 00:00:00 +0900

今までやったことなかったのでメモ。

環境

Ubuntu 20.04

.desktop ファイルの作成

.desktop という拡張子でファイルを作成し、デスクトップに配置します。
内容は以下のように記述します。

#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Exec=/home/user/run.sh
Name=Application Name
Comment=Test Application
Icon=/home/user/Pictures/icon.png

内容については省略します。

実行権限の付与

このファイルに実行権限を与えます。

$ chmod 755 test.desktop

デスクトップでこのファイルをダブルクリックすると、「起動を許可」というメニューがあるので、それを選択します。
すると、アイコンが変わり、ダブルクリックでアプリケーションが起動するようになります。

起動の許可が表示されない、テキストエディタが起動する場合

私の場合の例ですが、.desktop ファイルの Exec の項目でシェルスクリプトファイルを指定していた場合に、この状況が発生しました。

Exce で指定しているシェルスクリプトファイルにも実行権限を与えてやると解決しました。

参考 URL

http://appcel.sblo.jp/article/187826978.html

docker-compose での環境変数の参照方法

Fri, 29 Oct 2021 00:00:00 +0900

docker コンテナ内でホストと同じユーザーIDを指定するために、ホストの環境変数を参照していました。

例えば、docker コンテナ内でホストと同じユーザーIDを指定するために以下のように記述していましたが、

docker run -it \
 -e LOCAL_UID=$(id -u $USER) \
 -e LOCAL_GID=$(id -g $USER) \
 hoge:0 bash

これを docker-compose.yml ではどう書けばいいのか？結果的には以下のように記述することで上手くいきました。

environment: 
 - LOCAL_UID=${id:-u ${USER}}
 - LOCAL_GID=${id:-g ${USER}}

参考 URL

https://qiita.com/reflet/items/a96752b4cd3838ea6932

RabbitVCS のインストール

Thu, 01 Jul 2021 00:00:00 +0900

Windows では TortoiseSVN と TortoiseGit を使っていたので、Linux でも GUI で良いのがないかなと探していたら、RabbitVCS というのが Tortoise に似た感じだったので、インストールしてみました。

環境

Ubuntu 20.04

インストール

以下に説明があります。

http://wiki.rabbitvcs.org/wiki/install/ubuntu

以下のコマンドを実行するだけでインストールできました。

$ sudo apt install rabbitvcs-nautilus

これ一つで RabbitVCS SVN RabbitVCS Git RabbitVCS Hg が使えるようになるっぽい。

あとはファイル比較用の Meld とかいうツールも勝手に入ってました。

再起動後には Tortoise と同じように、フォルダにアイコンが表示されるようになっていました。

所感

まだ全然使っていませんが、とりあえず最新のコードをプルしたりだとか、コミットログを見たりだとか、ファイルの差分を閲覧する分には困っていません。

参考 URL

Linux で USB メモリをマウントする

Wed, 16 Jun 2021 00:00:00 +0900

Ubuntu とかだと USB メモリを挿したら自動でマウントされるので何も意識しなくもいいのですが、いざ他の Linux で USB メモリを挿したときにマウントってどうやるんだっけ？となったのでメモしておきます。

環境

Wind River Linux

マウント方法

USB メモリを挿すと、/dev/sda とか /dev/sdb とかいうファイル名で認識されます。
これを /mnt/usb にマウントしてやります。

$ mkdir /mnt/usb
$ mount /dev/sdb /mnt/usb

アンマウント方法

$ umount /mnt/usb

[python] ログを syslog に出力する

Tue, 15 Jun 2021 00:00:00 +0900

python でログをファイルに出力する記事を書きましたが、Linux には syslog があるので、アプリケーションのログも syslog に出力してみます。

ちなみに前回の記事はこちらです。

環境

Ubuntu 20.04
python 3.8.5

とりあえず簡単にやりたいなら

以下で OK です。

import syslog
syslog.syslog("This is a test message")
syslog.syslog(syslog.LOG_INFO, "Test message at INFO priority")

しかし、これだと syslog 固定なので、ログの出力先を変更したい場合に大変です。
なので、logger を使って抽象化したほうが良いと思います。

logger の出力先を syslog にする

from logging import handlers, basicConfig, getLogger, DEBUG

basicConfig(level=DEBUG, handlers=[handlers.SysLogHandler(address='/dev/log')])
#basicConfig(level=DEBUG, handlers=[handlers.SysLogHandler(address=("127.0.0.1",514))])

logger = getLogger('MyLogger')

logger.info('this is info')
logger.debug('this is debug')
logger.critical('this is critical')

標準出力にも出力したい

handlers に StreamHandler を追加すれば OK です。

basicConfig(level=DEBUG, handlers=[StreamHandler(), handlers.SysLogHandler(address = '/dev/log')])
#basicConfig(level=DEBUG, handlers=[StreamHandler(), handlers.SysLogHandler(address=("127.0.0.1",514))])

logger = getLogger('MyLogger')

logger.info('this is info')
logger.debug('this is debug')
logger.critical('this is critical')

Docker コンテナ内のアプリのログをホストの syslog に追加する

以下の記事で書いています。

https://kuttsun.blogspot.com/2021/12/python-syslog.html

参考 URL

Git で HTTPS を使う場合のアカウント情報を記憶させる

Tue, 01 Jun 2021 00:00:00 +0900

毎回打つのが面倒なので。

Windows の場合

クローンするときにユーザー名とパスワードが聞かれますが、一度入力すると資格情報マネージャーに登録されるので、２回目以降はユーザー名とパスワードの入力が不要になります。
もし入力間違いをしてしまった場合は、資格情報マネージャーで削除すれば OK です。

Linux の場合

Ubuntu 20.04 で確認しました。
libsecret をインストールして、credential.helper に設定してやります。

sudo apt-get install libsecret-1-0 libsecret-1-dev
cd /usr/share/doc/git/contrib/credential/libsecret
sudo make
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

これで、一度ユーザー名とパスワードを入力したら、次回以降は入力不要になります。

Linux on ポンコツ地方エンジニアの技術ブログ

Codex のレート制限リセット権の有効期限の確認方法

スクリプトの作成

実行手順

注意

OCI や AWS EC2 でセッション切断後も処理を止めないよう tmux を使う

先にまとめ

tmux のインストール

まずは 1 回動かしてみる

1. セッションを作る

2. プログラムを起動する

3. セッションを切り離す（detach）

4. 再接続する（attach）

セッションを終了して抜ける（プロセスを停止してセッションを閉じる）

今回の用途で最低限覚えるコマンド

キー操作の最小セット

よくあるハマりどころ

SSH を切ったら止まった

tmux attach で「no sessions」になる

セッション名を忘れる

OCI の Ubuntu インスタンスの初期設定

swap の設定

1. スワップファイルの作成

2. 適切な権限の設定

3. スワップ領域の初期化

4. スワップの有効化

5. 設定の確認

6. 再起動後も自動で有効化する設定

6-1. fstab のバックアップ（推奨）

6-2. 設定の追記

【おまけ】カーネルパラメータの最適化（推奨）

1. 現在の swappiness を確認

2. 一時的に 10 に変更

3. 永続的に反映

タイムゾーンの変更

nano のインストール

git のインストール

glab のインストールと認証

1. ダウンロード

2. GitLab でのアクセストークン（PAT）の発行

3. CLI の認証設定（ログイン）

tmux のインストール

docker のインストール

1. インストール

2. docker の権限を設定 (sudo を不要にする)

不要なサービスの停止

確実に停止・無効化して良いサービス

条件付きで停止・削除できるサービス（効果大）

snapd.service / snap.oracle-cloud-agent... （メモリ節約効果：大）

メモリ使用量の変化

OCI Bastion 経由でプライベート・サブネット内のインスタンスに SSH で接続

仕組みとメリット

環境

Step1: VCN とサブネットの作成

Step2: インスタンスの作成

Stes3: Bastion プラグインの有効化 (Oracle Linux の場合のみ)

Step4: Bastionの作成

Step5: セッションの作成

Step6: SSH接続の実行

SSH キーについての補足

① 同じ鍵を使った場合（一番シンプル）

② 別の鍵を使った場合（それぞれ指定が必要）

セキュリティ的な問題は？

1. 鍵が漏洩した際の影響範囲（爆発半径）が広がる

2. 「誰が・どこに」アクセスしたかの監査（ログ）が曖昧になる

参考

OCI (Oracle Cloud Infrastructure) で VM インスタンスを作成する

OCI (Oracle Cloud Infrastructure)

OCI のコンピュート環境：VM とコンテナインスタンスの違い

どちらを選ぶべきか？

OCI への登録

インスタンスの作成

基本情報

イメージ

シェイプ

セキュリティ

ネットワーキング

プライマリVNIC

パブリックIPv4アドレス割当て

SSHキーの追加

`tmux attach` で「no sessions」になる

2. 一時的に `10` に変更

`snapd.service` / `snap.oracle-cloud-agent...` （メモリ節約効果：大）