ネットワーク接続の復旧（Bootstrapping a network connection）

DistroWatch Weekly, Issue 1060, 4 March 2024 より抜粋
Questions and Answers (by Jesse Smith)（元記事）

ネットワーク接続の復旧（Bootstrapping a network connection）

No-longer-connected asks:ネットワークユーティリティを切り替えようとして、誤ってNetwork Managerを削除してしまった。今は有線接続ができず、無線接続するツールもありません。OSを最初からインストールし直さなくても、Network Managerを再びインストールする方法はありますか？

DistroWatch answers:インストールしているオペレーティングシステムのライブディストリビューションを使用して、コンピュータをオンラインにし、ネットワーキングクライアントをインストールするのが最善の方法です。ほとんどのライブデスクトップディストリビューションには、オンラインにするためのユーティリティ（Network Managerなど）が含まれています。インターネット接続を確立したら、次のステップでは、chroot でルートディレクトリを変更します。その後、ライブメディアのインターネット接続を使用して、chroot した環境に必要なパッケージをインストールできます。

では、これが実際の手順を見てみましょう。いくつかのステップを踏む必要があります：

1. インストールされているオペレーティングシステムがどのパーティションにあるかを確認する。
2. ライブデスクトップメディアで起動する。
3. インターネット接続を確立する。
4. インストールしたオペレーティングシステムにアクセスし、chrootでルートディレクトリを変更する。
5. 足りないパッケージをインストールする。
6. chrootで元にもどる。
7. コンピュータを再起動し、変更がうまくいったことを確認する。

インストールされているLinuxディストリビューションにアクセスして修復しようとする例を見てみましょう。

オペレーティング・システムがどのパーティションにあるかを調べる

最初にすべきことは、ディストリビューションがどのディスクパーティションにあるかを調べることです。これにはいくつかの方法があります。1つの方法は、mountコマンドとgrepを使って、ルートパーティション（「/」の記号）がどこにあるかを調べることです。ここではターミナルを開き、ルートパーティションがデバイス/dev/sda2にあることを確認します：

$ mount | grep " / "
/dev/sda2 on / type ext4 (rw,noatime) 

ライブメディアから起動

次にすべきことは、ライブメディアからブートすることです。おそらく、最初にディストリビューションをインストールしたときに使ったのと同じメディアです。オリジナルのインストールメディアが入手できない場合は、デスクトップ環境のあるメインストリームのLinuxライブメディアであれば、どんなものでも大丈夫です。

インターネットに接続する

ライブ・デスクトップ環境が起動したら、ネットワーク・ユーティリティを開き、通常使用する方法でインターネットに接続する。

chroot環境を作成する

次に、ディストリビューションのルートファイルシステム（先ほど/dev/sda2パーティションにあることがわかりました）にアクセスし、chroot環境で分離する必要があります。まず、ターミナルを開き、ルートパーティションをマウント（アクセス）します。

$ mkdir myroot
$ sudo mount /dev/sda2 myroot

この時点では、ルートパーティションはマウントされていますが、ルートディレクトリは変更されていません。次のコマンドでルートディレクトリの変更を行います：

$ sudo chroot myroot

不足しているネットワーク・ユーティリティをインストールする

＃で始まるプロンプトが表示されるはずです。ここから、ディストリビューションのパッケージマネージャを使って、不足しているネットワークユーティリティをインストールすることができます。

Network Manager のようなネットワークユーティリティをインストールするのに必要なコマンドは、使っているディストリビューションによって多少異なります。例えば、Arch ベースのディストリビューションでは、次のように実行します：

# pacman -Sy networkmanager network-manager-applet

DebianやUbuntuファミリーを実行している人なら次のように実行します：

# apt-get update; apt-get install network-manager nm-tray

Fedoraディストリビューションを使っている人は次のように実行します：

# dnf install NetworkManager

ディストリビューションのドキュメントをチェックして、どのパッケージマネージャを使うか、新しいパッケージを見つけてインストールするための適切なコマンドを確認すると良いでしょう。

chrootを残してクリーンアップする

ネットワーク・ユーティリティのインストールが完了したら、コマンド・プロンプトで "exit "とタイプして chroot を離れることができます：

# exit

それからルートファイルシステムをアンマウントし、変更がハードドライブに反映されているか確認する。

$ sudo umount myroot

ルートファイルシステムがアンマウントされたら、コンピュータを再起動し、ライブメディアを外します。インストールしたオペレーティング・システムが起動したら、ネットワーク・ユーティリティを実行してオンラインになることができるようになっています。

man の使い方（Navigating manual pages）

DistroWatch Weekly, Issue 1059, 26 February 2024 より抜粋
Questions and Answers (by Jesse Smith)（元記事）

man の使い方（Navigating manual pages）

最近、私はcronジョブの実行に問題を抱えている同僚と話していた。cronジョブとは、スケジュールされた時間に実行されるタスクやコマンドのことである。スケジュールされたジョブは実行されていたが、渡された引数を適切に処理していなかった。彼がトラブルシューティングに取り組んでいる間、私は自分のコンピューターのローカルマニュアルのページにアクセスした。コマンドのパラメータにパーセント記号（%）が設定ファイル（crontabファイルとしても知られている）に含まれており、それがcronによって特殊文字として解釈されてしまっていたのだ。

ちょっとした ことなのだが、私の尊敬する同僚がcrontabのマニュアルページをチェックしたところ（"man crontab "を実行）、パーセント記号がどのように異なって解釈されるかについての記述を見つけられなかったからである。一方、私は該当するマニュアルページの該当箇所をすぐに見つけた。たまたま、私たちは2つの異なるマニュアルページを見ていて、どちらも "crontab "という名前だったのだが、彼が役に立たないページを見せられている間に、私は該当するページから探してしまったのだ。なぜだろう？さて、マニュアルページの構成を見てみよう。

ローカルマニュアルページ（しばしば「man pages」と呼ばれる）は、9つの文書カテゴリーに分類されている： 

1. Executable programs and shell commands
   （プログラムとシェル）
2. System calls
   （システムコール）
3. Library calls
   （ライブラリ）
4. Special files (例えば /dev ディレクトリにあるようなファイル)
   （スペシャルファイル）
5. File formats and conventions (crontab や /etc/passwd など)
   （ファイルの書式）
6. Games（ゲーム）
7. Miscellaneous（その他）
8. System administration commands (ルート用のコマンド群)
9. Kernel routines（カーネル）

マニュアルのページを別々のカテゴリーに分類することは、いくつかの点で役に立つ。ページのグループをブラウズして目的のものを見つけるのに役立ちます。また、このようにページを整理することで、ソフトウェアをパッケージングする人は、設定ファイルに関する文書（セクション5「ファイルの書式」）と、同じ名前の実行ファイル（セクション1）を分けることができます。しかし、このような構成は問題も引き起こします。つまり、マニュアルページをmanコマンドで検索すると、最初に見つかった名前のエントリーが表示され、必ずしも目的のエントリーが表示されるとは限らないのです。

私の同僚と私の場合、彼が "man crontab "というコマンドを実行すると、manプログラムはカテゴリーを順番に検索し、crontab実行プログラムのマニュアルページをすぐに見つけた。このマニュアルページは "crontab (1) "とも呼ばれていて、実行プログラムのドキュメントがカテゴリー番号1にあるからです。

私は別のアプローチをとりました。コマンド "man -k crontab "を実行すると、タイトルのどこかに "crontab "という単語が含まれているページのリストが表示されました。"k "フラグはキーワード検索であることを表しています。出力はこんな感じでした：

$ man -k crontab
anacrontab (5) - configuration file for anacron
crontab (1) - maintain crontab files for individual users (Vixie Cron)
crontab (5) - tables for driving cron

私はcron table（またはcrontab）のフォーマットに関心があったので、"crontab (5) "というエントリーが正しいように思えました。そして、"man 5 crontab "を実行すると、5番目のドキュメント・カテゴリーにあるcrontabのエントリーが表示されました。もしcrontab実行プログラムのマニュアルページを指定したかったら、"man 1 crontab "を実行します。crontabファイルをフォーマットするためのマニュアル・ページが表示されたので、フォーマットや特殊文字に関する情報を簡単に見つけることができました。

マニュアル・ページは通常、/usr/share/manディレクトリの下に保存され、カテゴリーごとにディレクトリが分けられています。つまり、適切なディレクトリの内容をリストアップすることで、特定のカテゴリーに属するすべてのマニュアルページのインデックスを閲覧できます。例えば、ファイルの書式（カテゴリー5）に関するすべてのドキュメントを見たい場合、次のように実行します： 

ls /usr/share/man/man5

一方、実行可能ファイルに関するすべてのマニュアルページを閲覧したい場合は、以下のコマンドを実行してセクション1のすべてのページを確認します：

ls /usr/share/man/man1

あるページのドキュメントが、別のページの関連ドキュメントを参照していることはよくあります。多くのマニュアルページには、一番下に "See Also "セクションがあり、興味のありそうな他のページをリストアップしています。例えば、crontab実行コマンドのマニュアルページでは、"crontab(5), cron(8) "も参照することを勧めています。最初のページは、スケジュールされたcronジョブを設定するためのファイルフォーマットについて述べています。2番目のページは、鋭い目を持つ読者なら、システム管理に関する8番目のドキュメントのカテゴリーにあることに気づくと思いますが、cronバックグラウンド・サービスの実行と管理方法について述べています。

ローカルのマニュアルページにアクセスして調べる方法についての追加情報は、コマンド "man man "を実行すると、マニュアルページビューアのドキュメントが表示されます。

どのくらいのディスク容量を割り当てるか

DistroWatch Weekly, Issue 1058, 19 February 2024 から抜粋
Questions and Answers (by Jesse Smith)（元記事）

どのくらいのディスク容量を割り当てるか

Making-space-for-everything asks: 初めてのLinuxディストロ、おそらくLinux Mintをセットアップしようと思っています。Windows 11とデュアルブートするつもりです。ゲームをしたり、仮想マシンをセットアップして遊んだりするつもりです。

DistroWatch answers: 一般的にLinuxディストリビューションは、新規インストール時に3つのディスクパーティションがセットアップされます。1つはオペレーティング・システム（これはルート・パーティションと呼ばれます）、1つはユーザーのファイルと設定（これは/homeパーティションと呼ばれます）、そして多くの場合、スワップ領域と呼ばれるデータを一時的に保持するための3つ目のパーティションがあります。

最近では、スワップ・パーティション（作成される場合）はコンピュータのRAMと同じサイズにするのが一般的である。言い換えれば、8GBのRAMを搭載したコンピュータがある場合、ハイバネーションモードを使用することを想定して、スワップ領域は8GBになる可能性があります。ハイバネーション機能を使ってコンピュータを使わないときにエネルギーを節約するつもりがないのであれば、スワップパーティションは通常1GB程度と小さめでも大丈夫です。(ハイバネーションはスリープモードとは別物です。コンピュータをスリープモードにするためにスワップ領域は必要ありません)。

homeパーティションは、保存する予定のデータやインストールする予定のサードパーティゲームを保存するのに十分な大きさが必要です。このパーティションは1GBから数テラバイトまで、事実上どのようなサイズにもなり得るので（あなたのニーズ次第）、他の2つのパーティションが作成された後、/homeパーティションが残りのスペースを占めるのが普通です。

残るはルートパーティションです。数年前までなら、オペレーティング・システム用のルート・パーティションは20GBから25GBあれば十分で、余分なスペースも残されていたでしょう。しかし最近では、多くのディストリビューションが、かさばる、あるいは時間の経過とともに容量を食うテクノロジーを提供しています。ポータブルパッケージフォーマット、ファイルシステムのスナップショット、Nixパッケージの世代、スワップファイルなどは、すぐに何GBも消費してしまいます。最近では、ルートパーティションに25GBの容量を消費するのはよくあることで、開発ツールをインストールしたり、ファイルシステムのスナップショットを取りたい場合は、もっと必要になります。

この時点で、32GB程度のルートパーティションを設定することをお勧めします。スワップ・パーティションはRAMと同サイズ（ハイバネーションを使う場合）、使わない場合は1GB。そして残りのスペースを/homeに割り当てます。ただし、デュアルブートする場合、「残りの領域」というのは厄介な概念で、あなたのコンピュータにはすでに別のオペレーティングシステムが入っているからです。

ゲームと仮想マシンに必要な容量を大まかに見積もってみてください。おそらく、仮想マシン1台につき少なくとも32GB、大作ゲーム1本につき10GBのスペースが必要ではないかと思います。それから、私たちはいつも何かを忘れたり、もっと何かを欲しがったりするので、/homeパーティションの大きさの見積もりを得るために、思いついた数字を2倍にしてください。ディスク容量はいつでも増やせます。

なぜオペレーティング・システムとユーザー・データを別々のパーティションに保存することが多いのか、不思議に思うかもしれません。これは必須ではありませんが、習慣にしておくとよいでしょう。ファイルや設定をオペレーティング・システムとは別のパーティションに保存しておけば、個人データ（/homeパーティション）はそのままに、ディストリビューションを再インストールしたり、別のディストリビューションに乗り換えたりすることができます。これにより、OSの再インストールや乗り換えのたびに、すべてのファイルをバックアップからリストアする手間が省けます。

コンテナ管理に使っていた portainer のコンテナが壊れた

さて、僕がいつも使ってる雑務用のPCで、Dockerっていうのを使ってウェブアプリを個人的に動かしてるんだ。これを外からも使えたら便利だなと思ってね。 ただ、いちいちコマンド打つのがめんどくさいし、よく打ち間違えては調べる羽目になるんだ。過去にはチートシートを持ってたけど、たまにしか使わないから、それすらめんどくさくなってね。 で、Portainerっていうツールを導入して、操作をもっと視覚的にやってみたんだ。これがあると複数のコンテナを管理するのもラクになるし。初めて使ってみたら、忘れがちだったコンテナもサッとわかるようになったんだ。 LinuxにもDocker Desktopがあるけど、そっちをわざわざ導入するのもなんか面倒でね。Portainerを入れてからずっと快適に使ってたから安心してたんだけど、ある日システムアップデートをしたら、なんとPortainerにつながらなくなってしまって。 何が直接の原因かはわかんないけど、アップデート後の問題っぽいんだよね。ちょっとパニックになった。 とりあえずコンテナを作り直すことにしたんだ。状況を確認してみると、普通に稼働してるように見える。Dockerコンテナの状態をコマンドで調べたり、netstatでポートを確認したりしたけど、そこには問題がなかった。 データを保存してるわけじゃなかったから、作り直しても大丈夫なんだ。でも、作り直してみてもダメ。ちゃんと動いているように見えるけど、つながらないんだよね。 それで、思い当たるのがボリュームかなと思って調べてみたら、なんとPortainerの名前があって。とりあえずボリュームを消して、コンテナを作り直してみたんだ。 そしたらなんと、復旧したんだよ！ 使えるようになってホッとしたけど、何が原因だったかはわかんないから、まだ不安は残ってる。再発対策ができないのが悲しいけどね…。

ChatGPT に校正頼んだら、むっちゃむかつく文体で帰ってきた。おもしろいので、そのまま掲載します。

さて、僕がいつも使ってる雑務用のPCで、Dockerっていうのを使ってウェブアプリを個人的に動かしてるんだ。ウェブアプリを外からも使えたら便利だなと思ってね。

ただ、いちいちコマンド打つのがめんどくさいし、よく打ち間違えては調べる羽目になるんだ。過去にはチートシートを持ってたけど、たまにしか使わないから、それすらめんどくさくなってね。

で、Portainerっていうツールを導入して、操作をもっと視覚的にやってみたんだ。これがあると複数のコンテナを管理するのもラクになるし。初めて使ってみたら、忘れがちだったコンテナもサッとわかるようになったんだ。

LinuxにもDocker Desktopがあるけど、そっちをわざわざ導入するのもなんか面倒でね。Portainerを入れてからずっと快適に使ってたから安心してたんだけど、ある日システムアップデートをしたら、なんとPortainerにつながらなくなってしまって。

何が直接の原因かはわかんないけど、アップデート後の問題っぽいんだよね。ちょっとパニックになった。

とりあえずコンテナを作り直すことにしたんだ。状況を確認してみると、普通に稼働してるように見える。Dockerコンテナの状態をコマンドで調べたり、netstatでポートを確認したりしたけど、そこには問題がなかった。

データを保存してるわけじゃなかったから、作り直しても大丈夫なんだ。でも、作り直してみてもダメ。ちゃんと動いているように見えるけど、つながらないんだよね。

それで、思い当たるのがボリュームかなと思って調べてみたら、なんとPortainerの名前があって。とりあえずボリュームを消して、コンテナを作り直してみたんだ。

そしたらなんと、復旧したんだよ！ 使えるようになってホッとしたけど、何が原因だったかはわかんないから、まだ不安は残ってる。再発対策ができないのが悲しいけどね…。

Proxmox VEのクラスタ構築の闇と脱出法

Proxmox VEでのクラスタリングが手軽だと思いきや、実際には大変でした

サーバー関連の作業をするとき、Proxmox VEは避けて通れない存在です。少なくとも競合製品であるVMware ESXiのいずれかには触れたことがあるでしょう。私自身、業務上の理由から久しぶりにProxmox VEを使いましたが、クラスタリングのテスト中に大きく躓き、その記録としてこのメモを残します。

バージョン8.1.4をインストールし、スタンドアロンで快適に「仮想化が楽だな」と感心していましたが、次に2台でのクラスタ構築に挑戦しました。理想は3台構成ですが、利用可能な実機がなかったためです。多少の困難を乗り越えてクラスタを構築した後で「スタンドアロンに戻そう」と考えた矢先、予期せぬことが起こりました。

コマンドでしかクラスタ解消ができない

Webインターフェースを隅々まで調べて「クラスタ解消ボタン」を探しましたが、見つかりませんでした。なぜでしょうか？調べてみると、「コマンドを入力してください」という情報が得られました。

# まずは現状確認
pvecm nodes
# 次に削除コマンド
pvecm delnode <ノード名>

コマンドを実行し、コマンドライン上で確認したところ、削除されたノードが表示されていないことを確認しました。しかし、Webインターフェイス上では、ページを完全に再読み込みしてもノードが残っており、一部は機能しているようです。「こんなの意味がないように思えます...」（実際にはそうではありません）

そして、多くの解説サイトではここまでの情報をもって「まだ続きの作業がある...」と説明されています。

    rm -fr /etc/pve/nodes/<ノード名>

してくれとのこと。コマンドを打ったところ、「パーミッションがないため実行できない」というエラーメッセージが表示されました。さらに調査を進めて、いくつかのサイトを読んでみましたが、どれも「削除してからリロードすれば問題が解決する」という情報しか書かれていませんでした。一体何が起こっているのでしょうか。

諦めて英語の情報をあさる

私はよく英語を間違って読んでしまうため、英語が苦手です。ですが、DeepLの助けを借りながら調べてみたところ、本家のProxmoxフォーラムに答えが掲載されているのを見つけました。

forum.proxmox.comどうやら、デーモンを停止させたり、設定用のファイルシステムをロックしなければならないようです。

ノード削除の操作

    systemctl stop pve-cluster corosync
    pmxcfs -l
    rm /etc/corosync/*
    rm /etc/pve/corosync.conf
    killall pmxcfs
    systemctl start pve-cluster

理解してしまえば「なんだ、こんなことか」と思うのですが、上記の投稿を見るまで全くわかりませんでした。

ノードの切り離しをなんとか完了させた後でわかったのですが、切り離したノードは基本的に新規インストールが必要とされていました。そのため、ノードを切り離す前に中身をすべて空にして、そのノードに関連するジョブも全て修正しなければならないということでした。

ちなみに、再インストールしなくても、他のネットワークで端末を短時間使用したい場合にも、切り離し作業を行わなければ、以前の親ノードの表示が引き続き残ってしまいます。

ところで、corosync ってなに

OpenAISのクラスタ管理ソフトらしいです。

www.designet.co.jp

pve-cluster とか、pmxcfsってなに

本家のリファレンスに載ってました。英語ができないって不便ね。

pve.proxmox.com

ノートパソコンサーバーの蓋閉じて自動停止！解決方法があった！ #家庭あるある

逸般家庭あるある「ノートパソコンサーバーの蓋が閉じて、サービスが止まった」

自宅に複数の検証用サーバーをお持ちの方は、その中に少なくとも一台はノートパソコンをサーバーとして使用していることがあるのではないでしょうか。もし現在は使っていないとしても、以前に一度でも利用した経験がおありではないですか。

ノートパソコンをサーバーとして利用する際の問題点として、「蓋を閉じると電源が切れるか、スリープ状態になってしまう」ということが挙げられます。知識がない家族がうっかり蓋を閉じてしまったり、あるいは私自身が何気なく蓋を閉じてしまうこともあります。一方で、蓋を開けたままだと邪魔になることもありますし、例えば本棚に収めた状態で運用したい場合もあります。そのため、蓋を閉じた状態でもしっかりと稼働していてほしいわけです。

Debian ではこうする

それでは、Debian での解決策について説明しましょう。

1. /etc/systemd/logind.conf　を root 権限で適当なエディタで開く
2. デフォルトでは

   HandleLidSwitch=suspend

   なので

   HandleLidSwitch=ignore

   へ変更する

3. 保存して root 権限で以下を実行

   systemctl restart systemd-logind.servic

Linux Mint で docker を導入するときの注意

他のディストリでトラブルが続くので、Ubuntu 系の Linux Mint に切り替えました。Ubuntu は茶色いので、もっぱら緑の方を使っています。デフォのままで日本語環境が問題なく使えるので、デスクトップとして使いたいときは便利だと思ってます。

環境構築が楽な Linux Mint ですが、一箇所引っかかりました。公式の手順に則って、脳死状態で docker を導入していたら、docker のリポジトリが引けてこない。おかしい、Ubuntu ベースだから簡単なはずなのに...、リポジトリの設定が変なのかな？ /etc/apt/sources.list.d/docker.list を覗いてみて理解しました。

Linux Mint のコードネームは victoria、でも、ベースになった Ubuntu のコードネームは jammy jerryfish。リポジトリの参照先、末尾を victoria から jammy に変更したら、問題なく使えるようになりました。

デビアンのアップグレードでリポジトリの切り替えなんてよくあることなんですが、脳死状態で作業をしているとハマりますね。