タグ: RockyLinux

Linuxサーバ、稼働中のサービスのバージョンを確認するワンライナー。

概要

Linuxサーバの構築時に非常に面倒で厄介な「動いているサービス(systemctl status hoge.service でenabledになっているもの)だけを取り出し、表に転記するという作業が

  • 限りなく単調で
  • とてもミスが多い

重箱の隅をつつくような作業を一発で解消するワンライナーの紹介です。

前提

RHEL系Linuxで動きます。(筆者環境Rocky Linux)

ワンライナー

※これは

sudo su 

としてから入力した方が無難です。(パッケージによっては一般的権限では見られないため)

 { echo -e "| ソフトウェア名 | バージョン |\n| --- | --- |"; systemctl list-unit-files --type=service --no-legend | awk '{print $1}' | grep -v '@\.service$' | xargs -r systemctl show -p FragmentPath | sed 's/^FragmentPath=//' | grep '^/' | sort -u | xargs -I {} sh -c 'if rpm -qf "{}" >/dev/null 2>&1; then rpm -qf "{}" --qf "| %{NAME} | %{VERSION}-%{RELEASE} |\n"; else echo "| $(basename "{}") | (not owned by any package) |"; fi' | sort -u; } 

スクリプトの解説

このコマンドは大きく分けて「ヘッダーの出力」「サービスファイルのパス特定」「パッケージ情報の取得と整形」の3つのフェーズで動いています。

1. 表のヘッダーを作成

  • { echo -e "| ソフトウェア名 | バージョン |\n| --- | --- |"; ... }
    • 最初にMarkdown形式の表の1行目(項目名)と2行目(区切り線)を出力します。
    • 全体を { } で囲むことで、ヘッダーと後の実行結果を一つの出力ストリームとしてまとめています。

2. サービス一覧からファイルパスを特定

ここからがメインのパイプラインです。

  • systemctl list-unit-files --type=service --no-legend
    • システム上の全サービスユニットを表示します。--no-legend でヘッダー行を省きます。
  • awk '{print $1}'
    • 出力結果から1列目(サービス名)だけを抜き出します(例: sshd.service)。
  • grep -v '@\.service$'
    • インスタンス化されたユニット(user@.service など)を除外します。これらは実ファイルが少し特殊なためです。
  • xargs -r systemctl show -p FragmentPath
    • 各サービスに対して、その定義ファイル(ユニットファイル)がディスク上のどこにあるか(FragmentPath)を取得します。
  • sed 's/^FragmentPath=//'
    • 出力に含まれる FragmentPath= という文字列を削除し、純粋なパス名だけにします。
  • grep '^/'
    • 空行や無効なパスを除外し、/ から始まる絶対パスのみを残します。
  • sort -u
    • 重複したパスを削除します。

3. RPMによるパッケージ照会と整形

特定されたファイルパスを一つずつ RPM データベースと照合します。

  • xargs -I {} sh -c '...'
    • 各パス({})に対して、シェルスクリプトを実行します。
  • if rpm -qf "{}" >/dev/null 2>&1; then ...
    • そのファイルが RPM パッケージによって管理されているかを判定します。
    • 管理されている場合: rpm -qf を使い、パッケージ名とバージョンを Markdown の行形式 | 名前 | バージョン | で出力します。
    • 管理されていない場合: (手動で作成したサービスなど)「(not owned by any package)」と出力します。
  • sort -u(最後)
    • 最終的なリストをソートし、重複を排除して綺麗に並べます。

実行結果のイメージ

コマンドを実行すると、以下のような結果が得られます。

ソフトウェア名バージョン
chrony4.1-3.el9
openssh-server8.7p1-10.el9
my-custom-script.service(not owned by any package)
systemd250-6.el9

このワンライナーの利点

  • 徹底した合理性。
    • なにせ「目視確認」という手段が排除されます。一切のヒューマンエラーがなくなります。
  • 一覧性と整合性。
    • 「最新の情報を全て表示せよ」という要求に対してもコマンドを叩くだけで済みます。
  • 再利用性
    • これが一番大きいです。2020年代ITで最も使いやすいMarkdownのテーブル形式。そのため、
      • Redmine
      • VS Code
      • Notion
        などにいくらでも反映可能。そして、一度テーブルにしてしまえばExcelへの転記も一発です。

まとめ

「ウサギとカメの寓話」は、コツコツやる者が強いパターンではありますが、「60分の道を頑張って55分に縮めるよりも、30分かけて『1分で終わる手段を考える』」方が、本当の「タイムパフォーマンス」だと思った次第です。

備考

Ubuntuサーバでも、このようにすれば動きます。

{
  echo -e "| ソフトウェア名 | バージョン |\n| --- | --- |"
  # 1. サービスファイルのパス一覧を取得
  systemctl list-unit-files --type=service --no-legend | \
  awk '{print $1}' | \
  grep -v '@\.service$' | \
  xargs -r systemctl show -p FragmentPath | \
  sed 's/^FragmentPath=//' | \
  grep '^/' | \
  sort -u | \
  # 2. 1行ずつ読み込んで処理(whileループでシェル起動を最小化)
  while read -r path; do
    # dpkg-query -S は dpkg -S より高速で安定しています
    res=$(dpkg-query -S "$path" 2>/dev/null)
    if [ $? -eq 0 ]; then
      pkg=$(echo "$res" | cut -d: -f1)
      # 複数のパッケージがヒットする場合があるため、最初の1つを取得して詳細表示
      dpkg-query -W -f="| \${Package} | \${Version} |\n" "${pkg%%,*}"
    else
      echo "| $(basename "$path") | (not owned by any package) |"
    fi
  done | sort -u
}

RHEL系Linux(Rocky Linux)でDockerのビルド領域変更

Dockerならではの問題に対処したのでメモを残します。

背景と課題

RHEL / Rocky Linux 9 環境のGPUサーバーにおいて、Dockerビルド(大規模LLMモデルの生成など)を実行した際、ルートパーティション(/)の使用率が100%に達する事象が発生しました。

  • 原因: Dockerはデフォルトで /var/lib/docker(ルート配下)にイメージやビルドキャッシュを保存します。
  • 環境: ルート領域は70GB程度ですが、/home 領域には数TBの空きがります。
  • 対策: パーティションリサイズ(LVM操作)はリスクが高いため、Dockerのデータ保存先(data-root)を /home 配下へ物理的に移行して解決します。

さっくりとした手順

  1. 現状を確認し、サービスを停止します。
  2. Dockerの移行ディレクトリを作成します。
  3. rsyncを用いて安全にデータを移行します。
  4. Dockerの設定ファイルを変更します。
  5. Dockerサービスの再起動を行います。
  6. 設定変更を確認します。

現状の確認とサービスの停止

まず、現在のDocker設定とディスク使用量を確認し、Dockerサービスを停止します。

  • Dockerの保存先確認
docker info | grep "Docker Root Dir"

(デフォルトは /var/lib/docker)

  • Dockerサービスを停止します。
sudo systemctl stop docker docker.socket
  • Dockerサービスの停止を確認します。
systemctl status docker

inactive(dead)を確認します。

移行先ディレクトリを作成します。

大容量領域(今回は /home 配下)に新しい保存用ディレクトリを作成します。

  • ディレクトリ作成
sudo mkdir -p /home/docker/data

データの移行(最重要)

既存のイメージやコンテナデータを保持するため、rsync を用いてデータを同期します。
cp コマンドよりも、権限やタイムスタンプを正確に保持できる rsync を推奨します。
rsyncはRocky9に最初から入っているコマンドです。

  • /var/lib/dockerの中身を、新ディレクトリへコピー
sudo rsync -aqxP /var/lib/docker/ /home/docker/data/

-a: アーカイブモード(権限等を保持)
-x: ファイルシステム境界を越えない
注意: コピー元のパス末尾に / を付けることで、ディレクトリそのものではなく「中身」を転送先に展開します。

設定ファイルの変更 (daemon.json)

  • ファイルのバックアップを取ります。(凄く重要)

何かあったときの切り戻しのため。特に、後述するjsonの編集をミスると地獄行きの通過駅無しの特急が待っています。

sudo cp -pi /etc/docker/daemon.json /path/to/backup/directory/daemon.json.$(date +%Y%m%d)
  • ファイルのバックアップをdiffで取ります。
sudo diff -u /path/to/backup/directory/daemon.json.$(date +%Y%m%d) /etc/docker/daemon.json

一般ユーザが読み取れないディレクトリ構造も考慮して、念のためsudoをつけます。

→ エラーがなければバックアップ成功。ここでコピー元とコピー先を逆にしているのは編集後のdiffを取るためです。

  • Dockerに新しい保存先を認識させるため、/etc/docker/daemon.json を編集します。(エディタは宗教問題のため、自分の教義・信仰に沿ったものを利用してください)

変更例:
data-root オプションを追記します。
JSON形式のため、行末のカンマ(,)の有無に注意してください。

{
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    },
    "data-root": "/home/docker/data"
}
  • 編集後の差分をdiffで確認します。
sudo diff -u /path/to/backup/directory/daemon.json.$(date +%Y%m%d) /etc/docker/daemon.json

以下のようになっていることを確認します。

-     "data-root": "/var/lib/docker"
+     "data-root": "/home/docker/data"

サービスの起動と確認

Dockerを起動し、設定が反映されているか確認します。

  • Dockerサービスを起動します。
sudo systemctl start docker
  • Dockerサービスの起動を確認します。
systemctl status docker

active(running)を確認します。

  • 設定反映の確認
docker info | grep "Docker Root Dir"

=> Docker Root Dir: /home/docker/data となっていれば成功です。

不要データの削除(任意)

動作確認後、元の /var/lib/docker を削除または退避させて、ルートパーティションの空き容量を回復させます。

安全のため、バックアップを取るか慎重に削除してください。この作業を行うときは深呼吸を3回ほど行い、飲み物を飲むなどして落ち着いてから行いましょう。

sudo rm -rf /var/lib/docker

結果

本対応により、ルートパーティションの圧迫が解消されました。

Before:

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   70G   70G   20K 100% /

After:

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   70G  6.0G   65G   9% /
/dev/mapper/rl-home  6.9T  198G  6.7T   3% /home

トラブルシューティング

  • SELinux: 起動に失敗する場合、SELinuxが非標準ディレクトリへのアクセスをブロックしている可能性があります。一時的に setenforce 0 で切り分けを行うか、適切なコンテキストを設定してください。
  • JSON構文エラー: daemon.json の記述ミス(カンマ忘れなど)があるとDockerが起動しません。編集後は慎重に確認を行いましょう。

RHEL系LinuxサーバにRTX 6000を認識させる。

※昨今のトレンドである「GPU前提のLinuxサーバ」つまり、AI環境に必須の

  • データセンタークラスのGPU
  • それをRHEL系Linuxに認識させ
  • 更にDockerというトレンドでも動かす

という難易度が高く――そして、インフラ屋にとって極上の素材を得る経験がありました。

そのときのメモです。(氷見の本マグロを捌くことになった調理師のような気分でした)

“逸般”の誤家庭的な環境

まず、これを一般家屋に置くと言うことはないでしょう。

  • OS:
    • Rocky Linux 9.x (Minimal Install)
  • Kernel:
    • 5.14.0-x (RHEL 9 Standard)
  • GPU:
    • NVIDIA RTX 6000 Ada Generation x 1
      • →2025/12/06時点でもちょっとした軽自動車が買えるやつです
  • Driver:
    • NVIDIA Driver 590.xx (Open Kernel Module)
  • Container Runtime:
    • Docker CE 27.x + NVIDIA Container Toolkit

前提環境の整備

  1. OSインストールを行います。(Rocky Linux Minimal)
  2. ネットワークの設定を行います。
  3. dnf updateを済ませます。

NetworkManagerによるネットワーク設定

固定IP化および自動接続設定を行う。

  • 接続プロファイル名の正規化 (デバイス名と合わせる)
sudo nmcli connection modify "Wired connection 1" connection.id eno2
  • 固定IP設定
sudo nmcli connection modify eno2 ipv4.addresses xx.xx.x.x/16
sudo nmcli connection modify eno2 ipv4.gateway Gateway IP
sudo nmcli connection modify eno2 ipv4.dns "DNS1 DNS2"
sudo nmcli connection modify eno2 ipv4.method manual
sudo nmcli connection modify eno2 connection.autoconnect yes

→ これをやっておかないと、再起動したときにNW設定が消えます。

  • 設定反映
sudo nmcli connection up eno2

システム更新とリポジトリ適用

RHEL 9 系でサードパーティ製パッケージを入れるため、これは必須です。特に、CRB (CodeReady Builder) の有効化を忘れると依存解決ができず、高性能GPUを認識させることができません。

  • dnf全更新
sudo dnf update -y
  • サーバ再起動
sudo reboot

→ カーネルアップデートも含まれるため。

  • CRB有効化 (旧 PowerTools)
sudo dnf config-manager --set-enabled crb
  • EPEL導入
sudo dnf install epel-release -y

NVIDIA Driver の導入

ここまで来たらいよいよ本命。(先のマグロの例に例えると、いよいよマグロの身に刃を当てていきます)

【重要】 RTX 6000 Ada はプロプライエタリ版ドライバではなく、Open Kernel Module (open-dkms) を要求します。これに気づかずハマりかけました。

依存関係の解決とリポジトリの導入。

  • 開発ツールの導入
sudo dnf groupinstall "Development Tools" -y
  • カーネルヘッダの導入
sudo dnf install kernel-devel-$(uname -r) kernel-headers-$(uname -r) -y
  • NVIDIA公式リポジトリ (RHEL9用) 追加
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo

旧ドライバ/競合の排除

以前のインストール試行や(ハマったところ)、OSに入っているであろうGPUドライバを取り除かないと詰まります。

  • nvidia dkmsドライバのアンインストール
sudo dnf remove nvidia-driver kmod-nvidia-latest-dkms -y
  • nvidia dkmsドライバのリセット
sudo dnf module reset nvidia-driver -y

Open Kernel Module 版のインストール

  • dnf module機能を使って open-dkms ストリームを指定してインストール
sudo dnf module install nvidia-driver:open-dkms -y
  • サーバ全体を再起動してカーネルモジュールをロード
sudo reboot

ドライバ動作確認

nvidia-smi

-> `Driver Version: 590.xx / GPU Name: RTX 6000 Ada / VRAM: xxGB が表示されることを確認します。

コンテナ基盤の構築

筆者はコンテナが好みではないのですが、それはそれです。相手のオーダーに答えるのもまたお仕事。

Docker CE のインストール

ここではpodman ではなく Docker CE を採用しました。

  • Docker CEレポジトリ追加
sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
  • Docker CEインストール
sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
  • Docker 自動起動有効化
sudo systemctl enable --now docker
  • 現在のユーザをDockerグループに加える
sudo usermod -aG docker $USER

NVIDIA Container Toolkit の導入

DockerコンテナでGPUが見えないと、せっかく「Dockerを入れろ」というオーダーが無になります。

  • Toolkitインストール
sudo dnf install nvidia-container-toolkit -y
  • Dockerランタイム設定 (daemon.jsonの更新)
sudo nvidia-ctk runtime configure --runtime=docker
  • Tookit/ランタイム反映
sudo systemctl restart docker

動作確認 (パススルーテスト)

コンテナ内部から GPU が見えるか確認します。

sudo docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

成功時、コンテナ内からホスト同様の nvidia-smi 結果が出力されれば動作完了です。

追加要素:最新トレンドに合わせた開発環境の用意。

言語ランタイム (Modern Runtime)の導入

OS標準を汚さず、最新の開発環境を整備する。

  • Node.js 22+:
    • NodeSourceリポジトリより導入。これは割愛です。(どっかしら探せば出てくるので)
  • Python 3.12:
    • Rocky Linuxは3.9。しかも、OSの核となっているプログラムなので、ソースコードを用いて altinstall (共存インストール) しないとサーバそのものが吹っ飛びます。

※実行例

  • 開発環境導入
sudo dnf install -y openssl-devel bzip2-devel libffi-devel zlib-devel readline-devel sqlite-devel tk-devel xz-devel
  • ソースコードダウンロード
wget https://www.python.org/ftp/python/3.12.8/Python-3.12.8.tgz
  • ソースコード展開
tar xzf Python-3.12.8.tgz && cd Python-3.12.8
  • ソースコードconfigure(最適化オプション)
./configure --enable-optimizations
  • CPUコアフルに用いての高速メイク
make -j $(nproc)
  • altinstall
sudo make altinstall

altinstallを入れないと上述したようにサーバが吹っ飛びます。

トラブルシューティング (Tips)

以下のエラーに出くわしたときの原因と対策です。

  • NVRM: requires use of the NVIDIA open kernel modules:
    • 原因: Ada世代のGPUに対し、従来のプロプライエタリドライバを入れたため。
    • 対策: dnf module install nvidia-driver:open-dkms を使用しました。
  • Secure Boot:
    • ドライバ導入前に BIOS/UEFI で Disabled になっていることを確認すること(署名周りのトラブル回避)。

RHEL系サーバ、実物環境下でのネットワーク設定

はじめに

GUIが多くなったとは言え、Linuxサーバは基本的にCLI(コマンドライン)・SSH接続によるリモート操作が基本です。この、CLIの環境下でのネットワーク設定という基本のメモです。

環境とやったこと

極めてよくあるユースケースです。即ち

「サーバ実機はこれである。ひとまず組織内(社内)ネットワークにつなげ」

という指令への対処。

  • 物理サーバ
    • 今回はVPSではありません。実機です。
    • その大きさ、重さを知るのもインフラ屋の醍醐味です。
  • Rocky Liunx 9.x
    • (RHEL系フォーク、ミニマルインストール)
  • ローカルNWにサーバのIPを割り当てる。
  • NW設定を有効化する。
    • 固定IP。クライアントならいざ知らず、サーバ運用は固定IPであるべきです。
    • IP: 172.xx.xx.xx/16 (/16はサブネットマスク255.255.0.0を意味します)
    • GW: 172.xx.254.254 (※これはあくまでも例です)
    • DNSサーバ/ドメイン:ローカルで定められているもの。

さっくりとした手順

ではありますが、かなり慎重に書いています。

  1. RockyLinuxサーバをMinimalでインストールします。
  2. サーバコンソールに直接ログインします。
  3. ネットワークインタフェースを確認します。
  4. nmcliによりネットワークを設定します。
  5. ネットワークインタフェースを有効化します。
  6. サーバを結線してリンクアップを確認します。
  7. 最初のdnf updateを行います。

RockyLinux 9.6インストール

インストール方法については割愛。GUI無しのMinimalをインストールします。というのも、多くのサービスが入ってしまうと、自分が管理しきれない部分が増えると共に、そこが脆弱性となるからです。

また、ここでは最初からネットワークにつなぎません。設置する組織によってはLAN接続も許可制になっているパターンが極めて多いです。(IPも指定されたものを使うというのが実情でしょう)

サーバコンソールにログイン

この段階ではrootでも構いません。何せ、物理的に言葉通りの意味で切断されているのですから。

物理ネットワークの確認

vpsと違い、最初からネットワークにつながっていません。当然、IPも振られていません。なので「どのLANポートを使うか?」から始まります。

nmcli

を実行します。これはNetwork Manager Command Line Interfaceの略であり、RHELサーバの肝と言えるネットワーク設定コマンドです。(普段Ubuntuサーバを使う筆者は少々混乱しました)

筆者環境では

  • eno2
  • eno3

がありました。ここではeno2を確認していきます。

ネットワーク設定

  • 現状確認
nmcli connection show

以下のような例が出てきます。

NAME     UUID                                  TYPE      DEVICE
eno2     UUID文字列                             ethernet  eno2
lo       UUID文字列                             loopback  lo
eno3     UUID文字列                             ethernet  eno3

この、eno2というポートを使います。

  • ※例外

もし、もし NAME 列に Wired connection 1 とあり、DEVICE 列が eno2 ならば、次の手順で名前を変更します。

  • ※例外時の実施- "Wired connection 1" を "eno2" にリネーム
sudo nmcli connection modify "Wired connection 1" connection.id eno2
  • IPとサブネット設定 (CIDR表記でスマートに)
sudo nmcli connection modify eno2 ipv4.addresses 172.xx.xx.xx/16

→ 実際に指定されたIPアドレスを入力します。このとき、二重チェックで「同一ネットワーク内にIPアドレスが無いか? / 打ち間違いがないか?」を確認しましょう。被ってしまうと単純な破滅が待っています。

  • ゲートウェイ設定
sudo nmcli connection modify eno2 ipv4.gateway 172.xx.254.254

こちらも同様。別のゲートウェイを設定していないかを確認。

  • DNS設定
sudo nmcli connection modify eno2 ipv4.dns "DNS1 IPアドレス DNS2 IPアドレス"

→ DHCPと異なり、固定IPはDNSサーバを指定します。組織内では冗長性のため複数あるケースがほとんどです。

  • ドメイン設定
sudo nmcli connection modify eno2 ipv4.dns-search "組織内ドメイン"

→ 組織内ドメインで、FQDNの名前解決を効率化するため。

  • メソッドを手動にしてIPアドレス固定
sudo nmcli connection modify eno2 ipv4.method manual
  • 【重要】自動接続をONにする (これを忘れると再起動後に死ぬ)
sudo nmcli connection modify eno2 connection.autoconnect yes

→ autoconnect no の状態だと、システムが再起動した後、NetworkManagerは設定ファイルは認識していますが、その接続を自発的に起動しません。つまり、何らかの事情でサーバそのものを再起動した場合、このネットワーク設定が断たれます。即ち、あらゆるネットワークから完全に切り離されます。

ネットワーク設定の有効化

ここまで来たらいよいよサーバにネットワークを認識させます。このコマンドの前に深呼吸をして落ち着きましょう。(サーバ室/データセンターからの離席を許されるならこの段階で)

  • 再起動して設定をロード
sudo nmcli connection up eno2
  • IPアドレスの確認
ip addr show eno2

→ インターフェース eno2 に正しいIPアドレス、ネットマスクが割り当てられたか。

eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
  • ルーティングの確認
ip route

→ デフォルトゲートウェイ(外部ネットワークへの出口)が正しく設定されたか。

IPアドレスが正しくても、どこへパケットを送るか(経路情報)がなければ、ローカルネットワーク外へは通信できません。

default via  172.xx.254.254 dev eno2

などの行がないと、外部環境は無意味です。初歩的ですが非常に詰まりやすいポイントです。

  • DNS設定の確認
cat /etc/resolv.conf

→ ネームサーバーと検索ドメインが設定ファイルに反映されたか。

nameserver: 設定した社内のDNSサーバーのIPアドレス(例: nameserver 192.168.1.53)が正しくリストアップされているか。
もしこれらが正しく反映されていなければ、名前解決ができず、Webサイトの閲覧やホスト名でのサーバーアクセスができなくなります。

サーバの結線

上記が確認できたら、サーバという鉄の箱を「ネットワークと通信ができる」状態へと落とし込みます。ここでも、単純ながら致命的なミスが待ち構えています。

以下を確認しましょう。

  • LANポートの接続先と接続元は合っているか?
    • 特に、LANポートの迷路とも言えるサーバ室やデータセンターではこれらを間違えると地獄が待っています。比喩的な意味では無く。
  • LANケーブルは断線が無いか?
    • 切り分けの手間を減らします。
  • ストレートとクロスを間違えていないか?
    • たまにありますが結構盲点です。

疎通確認

  1. Gatewayへの Ping:ping -c 4 172.xx.254.254
    • これが通れば、L2/L3(組織/社内ネットワークへの物理・論理接続)は成功しています。
  2. DNSサーバへの Ping:ping -c 4 [DNSサーバーのIP]
    • これが通れば、名前解決の準備OKです。
  3. 外の世界への Ping:ping -c 4 google.com
    • これで初めて「インターネット接続完了」です。

DNFアップデート

サーバ全体のLinuxシステムを「最新の状態にする」おまじないです。

sudo dnf update -y

ここでの注意点はトラフィック。大容量のデータがこのサーバに流れます。貧弱な回線ではたちまちパンクします。

Complete!と表示されたら、

sudo reboot

で物理的に再起動します。というのも、dnfアップデートはたいがいカーネルの更新も伴うからです。

この再起動後、「先ほどのネットワーク設定が活きているか? 失われていないか?」が伴い、初めてこのネットワーク設定という初歩的な設定が完了します。

Ubuntuでプロンプトの挙動を変更(ちょいハマり-1-)。

ちょっとハマっていること

LinuxのCUI操作で、

  1. プロンプトの内容を「ユーザ名@ホスト名 カレントディレクトリ」に変更する。
  2. 一般ユーザの場合はプロンプトを緑にして\&で表記。
  3. rootに昇格した場合はプロンプトを赤にして#で表記。

という挙動にしています。

RockyLinuxの場合:OK

以下の内容を /etc/bashrc に組み込めばOKでした。

if [ "$PS1" ]; then
  if [ "$(id -u)" -eq 0 ]; then # rootユーザの場合
    PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
  else # 一般ユーザの場合
    PS1='\[\e[0;32m\][\u@\H \W]\$\[\e[0m\] '
  fi
fi

Ubuntuの場合:NG

ところが、Ubuntu系は

  1. 上記の設定を/etc/bash.bashrcに追記してもプロンプトの動きが想定通りとならない。
  2. source /etc/bash.bashrcと実行すると、設定が反映される。

これは相当面倒です。ログイン時に別のスクリプトか何かでこれを実行すればいいのでしょうが、新しいユーザを作成した場合など不都合が生じます。

Ubuntuでのワークアラウンド

取り急ぎ、当初の目的である「一般ユーザと特権ユーザでプロンプトの色や記号を変える」を優先させます。

ログインユーザ(一般ユーザ)の設定ファイル

  • ~.bashrc

末尾に以下を追記します。

# 一般ユーザ向けのプロンプト設定
if [ "$PS1" ]; then
  if [ "$(id -u)" -eq 0 ]; then # rootユーザの場合
    PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
  else # 一般ユーザの場合
    PS1='\[\e[0;32m\][\u@\H \W]\$\[\e[0m\] '
  fi
fi

rootの設定ファイル

  • /root/.bashrc

末尾に以下を追記します。

# rootユーザ向けのプロンプト設定
if [ "$PS1" ]; then
  PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
fi

これで当面の問題は回避できましたが、根本的な解決には至らず。

もう少し調査が必要です。

Powered by WordPress & Theme by Anders Norén