2023-05-04

Fedora38の変更点

Linux

fedora_logo

Fedoraの変更点シリーズ

過去リリース分の記事は、以下のリンクを参照してください。

Fedoraの変更点シリーズ

お伝えしたいこと

Fedora38のリリースノートを読んで、個人的に気になった項目をまとめ...ようと思いましたが、今回は私目線で気になる更新点は1つもありませんでした。

リリースノートの読み方や不具合情報の探し方については、以下の過去記事を参照してください。
Fedora37の変更点 - #公式情報の見方

以上。

2022-11-20

Fedora37の変更点

Linux

fedora_logo

Fedoraの変更点シリーズ

過去リリース分の記事は、以下のリンクを参照してください。

Fedoraの変更点シリーズ

お伝えしたいこと

Fedora37のリリースノートを読んで、個人的に気になった項目をまとめます。

私目線では、今回のFedora37リリースにはあまり大きな変更がありませんでした。

Fedoraの変更点シリーズ
お伝えしたいこと
公式情報の見方
Release Notes & Changes
- Python 3.11
Bugs
その他
- Kickstartのオプション
まとめ

公式情報の見方

Fedora 37の変更点は、以下のリンクに載っています。
概要はリリースノートに、詳細情報はChange Setsのページに書いてあります。

Change Setの各サブタイトルのリンクから詳細情報に飛べるようになっています (下図赤枠部)。
詳細を知りたい時に便利なので、こちらも活用ください。

fedora_change_sets

Fedora37の既知の問題は、以下にまとめられています。

Ask Fedora - Common Issues - all - F37

他バージョンのFedoraについて知りたい場合は、以下のリンクを参照してください。

Fedora Docs - Fedora Linux User Documentation → 右上から該当バージョンを選択してRelease Notesのリンクに移動
Fedora Wiki - Changes

Release Notes & Changes

Python 3.11

Fedora36時点ではPython3.10が同梱されていましたが、Fedora37以降はPython3.11が同梱されます。

Bugs

f37タグ付きのCommon Issuesを確認しましたが、特に気になるものはありませんでした。

強いて言うなら、GNOME Desktopをお使いの方はざっとタイトルをチェックしてみると良いと思います。

その他

Kickstartのオプション

LinuxなどのOSインストールを自動化するKickstart処理のオプションとして、rootユーザーのパスワードを指定するrootpwというコマンドがあります。
このrootpwコマンドに、Fedora37から--allow-sshオプションが追加されました。

このオプションを指定すると、rootユーザーに対してSSHによるパスワードログインが許可されます。

なお、--allow-sshオプションはRHEL9でも利用可能です。
RHEL9 - Performing an advanced RHEL 9 installation - #rootpw

本件はFedora 37のRelease Notesには掲載されていませんでしたが、--allow-ssh付きのKickstartファイルでFedora36をインストールしようとしたときにエラーになったことでたまたま気づきました。

まとめ

興味を持ったトピック限定ですが、Fedora37の更新点をまとめました。

2022-05-22

Fedora36の変更点

Linux

fedora_logo

Fedoraの変更点シリーズ

過去リリース分の記事は、以下のリンクを参照してください。

Fedoraの変更点シリーズ

お伝えしたいこと

Fedora36のリリースノートを読んで、個人的に気になった項目をまとめます。

Fedoraの変更点シリーズ
お伝えしたいこと
公式情報の見方
Release Notes & Changes
- remove-retired-packagesコマンドがインストール可能に
- /etc/sysconfig/network-scripts/ifcfg-* がデフォルト無効に
Bugs
- Fedora36にアップデートした後SELinuxの不具合が出る
まとめ

公式情報の見方

Fedora 36の変更点は、以下のリンクに載っています。
概要はリリースノートに、詳細情報はChange Setsのページに書いてあります。

fedora_change_sets

Fedora36の既知の問題は、以下にまとめられています。

Ask Fedora - Common Issues - all - F36

他バージョンのFedoraについて知りたい場合は、以下のリンクを参照してください。

Fedora Docs - Home → 該当バージョンを選択してRelease Notesのリンクに移動
Fedora Wiki - Changes

Release Notes & Changes

remove-retired-packagesコマンドがインストール可能に

Fedora公式リポジトリでremove-retired-packagesというパッケージの配布が開始されました。

remove-retired-packagesコマンドを使うと、その名の通りretired packagesを自動的に検出してアンインストールを提案してくれます。

retired packagesとは、Fedora公式リポジトリで配布されなくなったパッケージのことです。
retired packagesになる主な理由は、アップストリームの更新が停止したことが挙げられます。

デフォルトでは1世代前のFedoraバージョンからretired packagesを検出して、対象のパッケージに対してdnf removeを実行します。
remove-retired-packages 34のように引数を指定することで、検索範囲を広げてくれます。

更新が停止したパッケージを残しておくとセキュリティリスクがありますので、Fedoraをバージョンアップするたびにこのコマンドを実行することが推奨されます。

過去記事のFedoraのOSバージョンアップ手順にremove-retired-packagesの使い方を追記しましたので、詳細はこちらをご覧ください。

/etc/sysconfig/network-scripts/ifcfg-* がデフォルト無効に

Fedora36以降、NetworkManagerはデフォルトで/etc/sysconfig/network-scripts/ifcfg-*ファイルを一切使わなくなります。
それどころか、/etc/sysconfig/network-scripts/フォルダ自体存在しなくなります。
追加のRPMパッケージをインストールすれば従来の構成に戻すことは可能ですが、ifcfg-*は今後なくなっていく流れですので、それに逆行することは推奨しません。

Connectionの定義ファイルを直接見ることがない方にとっては、この変更点はほぼ影響ありません。
例えば、普段nmcliを使っている方に取ってはあまり気にならないと思います。
もしもifcfg-*ファイルを編集してnmcli reloadやsystemctl restart NetworkManager.serviceなどで設定を再読込する運用をしている方がいれば、今回の変更は重要なものになります。
少数派だと思いますが...。

では、詳細に移ります。
この先は興味のある方のみお読みください。

全体像を理解するために、今までのLinuxのネットワーク設定変更の主だった動きを追ってみます。
私の知識の偏りにより、RHELとFedoraが混在した時系列になっていますがご了承ください。

RHEL6の頃、ネットワーク設定変更といえば以下の流れが主流でした。

/etc/sysconfig/network-scripts/ifcfg-*ファイルを編集する
service network restartによって反映する

RHEL7以降は、NetworkManagerを常時有効化することが主流となりました。
NetworkManager利用した設定変更の方法は複数ありますが、nmcliコマンドによる変更が最も基本的だと思います。

NetworkManagerには、/etc/NetworkManager/NetworkManager.confという設定ファイルがあります。
この設定ファイルにはpluginsという設定項目があり、デフォルトではコメントアウトされています。

#plugins=keyfile,ifcfg-rh

nmcliなどで変更したconnection設定はOS再起動後ももちろん残ります。
その裏では、NetworkManagerが設定内容をファイルに保存しています。

私はあまりやったことがないのですが、NetworkManagerを使っている環境においてもこの設定ファイルを書き換えて、nmcli connection reloadコマンドによって設定ファイルを再読込させることが可能です。
ファイルを書き換えるよりも、nmcli connection modifyコマンドを使うほうが一般的だと思いますが...。

さて、この「Connection設定が保存されたファイル」がどのような形式で、どういったファイルパスに保存されるかを指定するのが上述のplugins設定です。
plugins設定はNetworkManager.confで明示的に指定することが可能ですが、コメントアウトされている場合にはディストリビューション固有のデフォルト値を取ります。

pluginsの取りうる値は、man NetworkManager - #PLUGINSに書いてあります。

ここで紹介するpluginsは以下の2つのみです。

plugins	説明
`keyfile`	最も基本形のフォーマット NetworkManagerと必ず同梱される INI形式 `/etc/NetworkManager/system-connections/*`に格納される
`ifcfg-rh`	RHEL系のレガシーなフォーマット `/etc/sysconfig/network-scripts/ifcfg-*`に格納される

ここでFedoraバージョン依存の話が出てきます。

Fedoraのバージョンが上がるにつれて、pluginsのデフォルト値は以下のように変遷しました。¹

バージョン	`plugins`のデフォルト値
Fedora32以前	`ifcfg-rh,keyfile`
Fedora33以降	`keyfile,ifcfg-rh`

ifcfg-rh,keyfileは、「基本的にifcfg-rhを優先するが、もしこのPluginが利用不可だった場合にはkeyfileを使う」という意味です。
keyfile,ifcfg-rhはその逆で、「keyfileを優先し、次にifcfg-rhを使う」という意味になります。

keyfile Pluginは、NetworkManagerのRPMファイルに必ず同梱されます。
一方で、ifcfg-rhについてはFedoraのバージョンによって以下のように構成が変わりました。
これがFedora36の差分です。

バージョン	RPMパッケージ
Fedora35以下	`NetworkManager`に同梱される初期状態で`ifcfg-rh`プラグインを利用可能
Fedora36以降	`NetworkManager` RPMパッケージに同梱されない初期状態では`ifcfg-rh`プラグインを利用不可 `NetworkManager-initscripts-ifcfg-rh` RPMパッケージを別途インストールすれば使える

Fedora36以降は、ifcfg-rhプラグインがデフォルトでインストールされません。
また、/etc/sysconfig/network-scripts/ディレクトリもデフォルトで存在しません。

レガシーなifcfg-rhは今後なくなっていく流れですので、今後はkeyfileを使うことを前提に考えると良いと思います。

NetworkManager-initscripts-ifcfg-rh RPMパッケージを導入してifcfg-rhを使い続けるという選択肢もありますが、恐らくあまり良い選択ではありません。
このパッケージが今後提供されなくなる可能性が少なくないためです。

Bugs

Bugsの中から気になる情報を拾います。

Fedora36にアップデートした後SELinuxの不具合が出る

Ask Fedora - SELinux-related errors when updating packages or using certain tools, after upgrade to Fedora 36

タイトルのとおりです。
投稿された事例では、dnf upgrade, flatpak update, setseboolなどのコマンドを実行した時にWarningが出たとのことです。

回避策は、Fedoraをバージョンアップする前にsudo dnf upgradeでパッケージを最新化しておくことです。
これはFedoraバージョンアップの公式手順にも記載されていることですので、マニュアル通りに作業していれば問題ありません。

Fedora36で事象が発生してしまったときのワークアラウンドとしては、以下が紹介されています。

SELinux関連パッケージを再インストールする
1で直らなかった場合は以下を実施
1. SELinuxの関連モジュールを停止する
2. SELinux関連パッケージを再インストールする
3. SELinuxのrelabelを行う

サイト上で紹介されているコマンドは一例です。
環境に応じて実行するコマンドを変更する必要があると思います。

ちなみに、私がもし事象を踏んだときは以下の手順で対処すると思います。
私は事象を踏んでおらず、未検証の手順なのでご参考までに...。

まず、事象を踏んだときのコマンドを覚えておきます (sudo dnf upgradeなど)。

続いて、SELinux関連パッケージを再インストールします。
この時、再インストールすべきパッケージは以下のコマンドで洗い出します (※)。
(※) SELinuxのコアなパッケージはselinux-policyとselinux-policy-targetedの2つです。そして、製品に対応したSELinuxの追加ルール (Security Policy) をインストールするパッケージは、製品名-selinuxというパッケージ名であることが多いです。したがって、以下のコマンドで必要なパッケージは一通り洗い出せます

dnf list installed *selinux*

上記を実施後、事象が継続しているかを確認します (例えば、sudo dnf upgradeを実行し、Warningが発生するかを確認します)。

事象が継続している場合、以下の手順を実施します。

SELinuxを無効化する (参考手順)
SELinux関連パッケージを再インストールする (上述と同じ手順)
SELinuxのrelabelを行う (sudo fixfiles onboot; sudo reboot。参考: fixfiles onbootについて)

個人的には、sudo fixfiles onbootに-Fを指定する必要はないかなと思います。
-Fを指定しても害はありませんが、通常の環境 (targeted policy) では指定してもしなくても差はありません。

まとめ

興味を持ったトピック限定ですが、Fedora36の更新点をまとめました。

Fedora wiki - Changes/NetworkManager keyfile instead of ifcfg rh ↩

2022-05-17

FedoraにSlackをインストールする方法 (Snap利用)

Linux

お伝えしたいこと

Snapによって、FedoraにSlackをインストールする手順を紹介します。

FedoraでSlackをインストールする場合、現状Snapを使うのが最も無難な方法だと思います。
その理由については、#(参考) Snapを使う理由に記載しましたので、興味のある方はご確認ください。

お伝えしたいこと
- Snapとは
Snapdのインストール
Slackのインストール
その他の基本コマンド
(参考) Snapを使う理由
(参考) classic confinementのパッケージインストール
まとめ
Linux PC関連まとめ

Snapとは

SnapはLinuxにソフトウェアをインストールするパッケージの1種です。
以下の特徴を持ちます。¹

複数のディストリビューションにて動作する (Ubuntu, Fedora, Arch Linux, ...)²
Snapファイル内に依存ライブラリを全て含むため、依存パッケージのインストールが不要

Snapdのインストール

snapコマンドはsnapdデーモンと共に動作します。
Fedora上でsnapコマンドを使用するために、snapdをインストールします。

sudo dnf install snapd

snap versionでsnapやsnapdのバージョンが表示されれば、正しくインストールできています。

snap version
# snap    2.55.3-2.fc35
# snapd   2.55.3-2.fc35
# series  16
# fedora  35
# kernel  5.16.12-200.fc35.x86_64

インストール後、一旦ログインし直します。
再ログイン後、PATHの末尾に/var/lib/snapd/snap/binが追加されます。
これにより、Snapでインストールした実行ファイルにPATHが通るようになります。

echo $PATH
/home/stopendy/.local/bin:/home/stopendy/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/var/lib/snapd/snap/bin

なお、PATHの追加は、/etc/profile.d/snapd.shにて行われていました。

Slackのインストール

Snapでパッケージをインストールする際は、以下の流れで進めます。

パッケージを探す
Confinementを確認する
インストールする

パッケージを探す

snap findコマンドでパッケージを部分一致検索できます。

snap find slack
# Name   Version  Publisher  Notes  Summary
# slack  4.25.1   slack✓     -      Team communication for the 21st century.
# (以下略)

Publisherがslack✓と記載されている通り、チェックマークがついています。
これはパッケージメンテナがSnapの運営元によって公式であると確認済みであることを示しています (※)。
(※) snap find --helpより

パッケージは、snapcraftのWEBサイト上でも検索できます。
https://snapcraft.io/slack

Confinementを確認する

オンラインリポジトリ上のSnapのConfinementを確認するには、snap info --verboseコマンドを使います。

snap info --verbose slack
#   confinement:       strict
# (一部のみ抜粋)

Confinementは、Snap上で動作するアプリケーションがシステムに対してどの程度アクセス権限を持つかを表します。
Confinementの値によってはインストール手順が若干変わってくるので、ここで確認しておく必要があります。

ConfinementはSnapパッケージがビルドされた時点で決まっています。
したがって、私達ユーザーが選ぶことはできません。

Confinementは3つの値を取りえます。
私達が使うパッケージは、通常strictかclassicのいずれかです。³, ⁴

strict
- 最も一般的なconfinement
- アプリケーションからシステムへのアクセスを適切に制限する
- アクセス先によっては、ユーザー操作を求める (カメラなど)⁵
- 許可されないアクセスは拒否する
classic
- アプリケーションからシステムへのアクセスを無条件で許可する
- classicのパッケージをインストールする前に#初期設定が必要
- sudo snap install --classicでインストールする
devmode
- 開発者向けのモード
- 許可されないアクセスはログ出力するが、実際には許可される
- アプリが必要とする権限の洗い出しに使えそう
- sudo snap install --devmodeでインストールする

インストールする (strict confinementの場合)

以下のコマンドでSlackをインストールします。
Slackパッケージのconfinementはstrictなので、特にオプション指定は不要です。

sudo snap install slack

その他の基本コマンド

インストール済みのSnapパッケージを一覧表示します。

snap list
# Name   Version  Rev  Tracking       Publisher  Notes
# slack  4.25.1   61   latest/stable  slack✓     -
# (一部抜粋)

パッケージを更新するコマンドです。

sudo snap refresh

Snapパッケージを削除するコマンドも記載します。

デフォルトでは、snap restoreによって復元するためのデータを保管します。
この場合はsnap remove後もsnap listでパッケージが表示されます。
--purgeオプションを指定することで、復元用のデータを残さずに削除します。

# sudo snap remove --purge slack

(参考) Snapを使う理由

2022年3月1日以降、SlackはFedora公式リポジトリで配布されなくなりました。

slack.com - System requirements for using Slack

slack_system_requirements

SlackをFedora Linux上で動作させる公式の手段は主に2つです。

RPMファイルを公式サイトからダウンロードしてインストールする
Snap版のSlackをインストールする

1のRPMは、Slackのリポジトリ情報を含みません。
したがって、今後Slackをバージョンアップしたいときには都度RPMファイルをダウンロードしてインストールする必要が出てきます。
これではあまりに不便です。

そこで、2のSnap版が出てきます。
Snap版であればオンラインリポジトリにSlackが配布されているので、sudo snap refresh slackコマンド1つでSlackをバージョンアップできます。

Fedora上でSlackを使いたい場合には、Snapを使うのが正攻法だと思います。

管理が面倒になるので、DNF以外のパッケージマネージャーを使うことには多少なりとも抵抗を覚えるかもしれません。
しかし、FedoraからSlack公式のリポジトリを使うにはSnapしか現状なさそうなので、私は割り切りました。

(参考) classic confinementのパッケージインストール

classicの場合の手順についても触れておきます。
今回はVS Codeをモデルにします。

VS CodeはFedoraのリポジトリで提供されるので、わざわざSnapでインストールする必要はありません。
ここでVS Codeをインストールしているのは、あくまで例示のためです。

Confinementの確認

VS Codeのconfinementは、2022年5月現在classicです。

snap info code --verbose
# publisher: Visual Studio Code (vscode✓)
#   confinement: classic
# (一部抜粋)

初期設定

Classic confinementのパッケージをインストールするには、/snapにシンボリックリンクを作成しておく必要があります。⁶

sudo ln -s /var/lib/snapd/snap /snap

シンボリックリンクを作成せずにインストールしようとすると、以下のようなエラーが出ます。

sudo snap install --classic code
# error: cannot install "code": classic confinement requires snaps under /snap or symlink from /snap
#        to /var/lib/snapd/snap

インストール

インストールの際は--classicオプションを付与します。

sudo snap install code --classic

--classicオプションを付与しないと、以下のエラーが出ます。

sudo snap install code
# error: This revision of snap "code" was published using classic confinement and thus may perform
#   arbitrary system changes outside of the security sandbox that snaps are usually confined to,
#   which may put your system at risk.

#   If you understand and want to proceed repeat the command including --classic.

まとめ

Snapによって、FedoraにSlackを導入する手順を紹介しました。

Linux PC関連まとめ

endy-tech.hatenablog.jp

snapclaft.io - About Snaps ↩
snapclaft.io - Installing snapd ↩
snapclaft.io - Snap confinement ↩
snapclaft.io - Snap install modes ↩
snapclaft.io - Supported interfaces → 表の “AUTO-CONNECT” 列を参照↩
snapclaft.io - Installing snap on Fedora ↩

2022-05-01

GNS3で踏みがちなトラブルと回避方法

Network GNS3

お伝えしたいこと

GNS3は幾度もリリースされ、今ではかなり安定して動作します。

しかし、それでもGNS3を使っていると現実のネットワーク機器では考えられないようなトラブルに見舞われることがあります。
VMが起動しなかったり、ケーブル直結なのにARPが通らなかったり...。

本記事では、GNS3を使っている時に踏みがちなトラブルと回避方法を紹介します。

お伝えしたいこと
文字化け
GNS3 GUI上の操作は電源を切ってから
仮想マシンをグループに所属させないこと
セキュリティソフトに要注意
まとめ

文字化け

GNS3において、日本語 (※2バイト文字) は全力で避けてください。
GNS3上のマシン名はもちろんのこと、GNS3のバックエンドで動作しているVirtualBoxやQEMU上のVM名やファイルパスも含めてです。
VMだけでなく、仮想ディスクやISOファイルのファイル名、ファイルパスも気をつけてください。

GNS3が発行する命令に日本語が混ざると、文字化けしてエラーになります。
結果として、仮想マシンの起動/停止/追加/削除が一切できなくなります。

参考情報として、GNS3が各種連携ソフトに命令を送るイメージを下表に示します。
以下のnameに日本語が混ざると不具合の原因になります。

仮想化エンジン	コマンドイメージ
VMware Workstation Player	`vmrun [options...] name`
VirtualBox	`VBoxManage [options...] name`
Docker	`docker [options...] name`
QEMU	`qemu-system-x86_64 [options...] name`

GNS3 GUI上の操作は電源を切ってから

GNS3 GUI上の操作とは、以下のようなものを指します。

GNS3上のケーブル配線
GNS3のノードを右クリックしてConfigureからの設定変更

もちろん、コンソール接続や電源OFF操作などは問題ありません。

これらの操作を行うと、本来通るはずの通信が通らなくなることがあります。
結果として、ケーブルで直結されたLinuxからARPを出してもL2スイッチ上でMACアドレステーブルを学習しない...なんてホラーが起こりえます。
「VACL設定したっけ...？」と頭を悩ませるより先に、まずはGNS3観点で疑いましょう。

この事象から復旧するには、以下のいずれかの操作が必要です。

操作箇所に隣接する全てのVMの電源OFF/ON
操作箇所に隣接する全てのVMの削除/再作成
GNS3の再起動
ホストマシンのOS再起動

面倒ですが、ホストマシンのOS再起動が最も確実です。

仮想マシンをグループに所属させないこと

VirtualBoxは、仮想マシンを右クリックしてグループに追加できます。
...が、この機能を使ったときGNS3が正しく動作しないことがあります。
あまり仮想マシンをグループに追加しないほうが良いと思います。

具体例としては、以下の操作を行った時にGNS3 Projectを開けなくなりました。
結果として、GNS3 Projectを作り直すことになりました...。

VirtualBox VMをVirtualBox上でグループに追加する
GNS3上でUse as a linked base VMを有効化する
GNS3 Projectを保存して、GNS3を一旦終了する
保存したGNS3 Projectを開き直す

セキュリティソフトに要注意

GNS3は内部的に様々な実行ファイルを実行し、またlocalhostに対してTCP/UDP通信を行います。

GNS3をWindowsで動かしているとき、Windows ファイアウォールがしばしばこのような通信をブロックします。
結果として、 GNS3上ではケーブルが直結しているのに何故か通信が通らない といったことになります。
原因は、GNS3上の通信に利用されているUDP Tunnel通信をブロックしているためです。

Windows ファイアウォールであれば、設定にもよりますが通信をブロックしたときにポップアップが出ると思います。
そこで通信を許可するための操作を行えば問題ありません。

ここで誤って「拒否」を選択してしまった場合はWindows Firewallに拒否ルールが追加されてしまいます。
その場合は、Windows ファイアウォールの規則を編集し、該当の拒否ルールを削除するようにしてください。
アプリケーションにGNS3やDynamipsが含まれていれば、それが問題のルールだと思います。

まとめ

GNS3周りの主なトラブルと回避方法を紹介しました。
皆様の時間節約につながれば幸いです。

2022-05-01

GNS3とlibvirtの仮想ネットワークをブリッジ接続する

Network GNS3

お伝えしたいこと

GNS3上に追加した仮想マシンをlibvirtの仮想ネットワークに接続する方法を紹介します。

仮想マシンは、必ずしもQEMU上で動作している必要はありません。
例えば、VPCSのような仮想マシンではないノードも含めてlibvirtの仮想ネットワークに接続し、DHCPでIPアドレスを付与したり、ホストマシンと通信させることが可能です。

libvirtネットワークに接続することで、ホストマシンからVMへのSSHや、VMからインターネットへのアクセスが可能となります。

お伝えしたいこと
前提条件
(参考) 前提知識
- libvirtの仮想ネットワーク
- GNS3のCloud node
手順
Cloud nodeの便利な使い方
まとめ

前提条件

本記事の手順は、GNS3とlibvirtベースのKVM環境のセットアップが完了していることを前提としています。
セットアップがこれからの方は、それぞれ以下のリンクを参照してください。

KVMの初期設定、及びvirsh, virt-installによるVM作成
- 特に(参考) 仮想NICの設定変更を参照
GNS3のインストール手順
- Fedora
- その他のLinux (簡易手順)

KVM環境について補足すると、仮想ネットワークが作成済みであることが一番重要です。
仮想ネットワークの構成については、以下のコマンドで確認できます。

仮想ネットワークが作成済みで、NATやDHCP、IPアドレス範囲が適切に設定されていることをご確認ください。

virsh net-list
#  Name        State    Autostart   Persistent
# ----------------------------------------------
#  default     active   yes         yes

virsh net-dumpxml default
# <network>
#   <name>default</name>
#   <uuid>b130cf72-a5eb-4414-9fd8-7d1182f2b50b</uuid>
#   <forward mode='nat'>
#     <nat>
#       <port start='1024' end='65535'/>
#     </nat>
#   </forward>
#   <bridge name='virbr0' stp='on' delay='0'/>
#   <mac address='52:54:00:96:e6:67'/>
#   <ip address='192.168.122.1' netmask='255.255.255.0'>
#     <dhcp>
#       <range start='192.168.122.101' end='192.168.122.254'/>
#     </dhcp>
#   </ip>
# </network>

(参考) 前提知識

本ブログで実施する手順について、前提知識となる情報をこちらのセクションで紹介します。
既にご存知の方は読み飛ばしても結構です。

#libvirtの仮想ネットワーク
#GNS3のCloud node

libvirtの仮想ネットワーク

libvirtの仮想ネットワークは、VirtualBoxでいうところのホストオンリーとNAT相当の機能を持ちます。

libvirtの仮想ネットワークとVMを接続することで、VMから以下の通信ができるようになります。

ホストマシンとの通信 (SSH, HTTPS, SCP, ...)
libvirt組み込みのDHCP/DNSサーバの利用
ホストマシン外部への通信 (インターネット通信など)
仮想ネットワークを介した他VMとの通信

GNS3のCloud node

今回は、GNS3のCloud nodeを使ってlibvirtネットワークとの接続を行います。

Cloud Nodeとは、いわゆるブリッジ接続を提供する機能のことです。
GNS3上で以下のようにCloud Nodeを追加して配線することで、ホストマシン上のNICとブリッジ接続できます。

gns3_cloud

Cloudと聞くと「AWSなどのクラウドサービスと接続する機能？」と思われるかもしれませんが、実際には単なるブリッジ接続のことです。
ブリッジ接続とは、「ホストマシンのNICとL2スイッチ越しに接続された状況」を仮想的に実現する機能です。
もちろん、ホストマシンのNICが複数存在する場合は「どのNICとブリッジ接続するか」を設定することができます。

仮にCloud nodeがホストマシンのEth0とブリッジ接続するよう構成したと仮定します。
この時、論理的には以下のような構成になります。

bridge_nw_diagram

手順

本セクションで、GNS3上で動作しているVMをlibvirtの仮想ネットワークと接続するための手順を紹介します。
前述の通り、GNS3のCloud nodeを使用します。

virbrインターフェース番号を調べる

libvirtの仮想ネットワークは、ホストマシン上ではvirbrX (※Xには0以上の数字が入る) というインターフェース名で表現されます。
Cloud nodeでブリッジ設定を行うために、まずはこのインターフェース名を調べておく必要があります。

まず、目的の仮想ネットワーク名を調べます。
今回はdefaultという仮想ネットワーク名が対象だったとします。
(※) gns3という名前で、GNS3検証環境用の仮想ネットワークを作るのも良いと思います。それにより、既存のKVM 仮想マシンが持つIPアドレスとの重複を気にせず、より自由にIPアドレスを割り当てられるようになります

virsh net-list

#  Name        State    Autostart   Persistent
# ----------------------------------------------
#  default     active   yes         yes

続いて、defaultに対応するインターフェース名を確認します。
以下の情報より、virbr0であることがわかりました。

以降のセクションでvirbr0に対するブリッジを設定します。
インターフェース番号が異なる方は読み替えてください。

virsh net-info default

# Name:           default
# UUID:           b130cf72-a5eb-4414-9fd8-7d1182f2b50b
# Active:         yes
# Persistent:     yes
# Autostart:      yes
# Bridge:         virbr0

(参考) GNS3上でCloud Nodeを使用する

GNS3の初期設定なしでCloud nodeを使うための手順を紹介します。
初期設定したほうが便利なので、こちらの手順は参考程度にご覧ください。

まず、GNS3を起動します。
そして、End devicesセクションからCloud nodeを追加します。
また、Cloud nodeと接続するための仮想マシンももう一台追加しておきます。

use_default_cloud1

cloudをダブルクリックして、設定画面を開きます。
Show special Ethernet interfacesにチェックを入れて、ドロップダウンリストからvirbr0を選択してAddから追加します。
OKを選択して設定画面を閉じます。

use_default_cloud2

VMからcloudのvirbr0に対して配線します。
これでVMをvirbr0にブリッジ接続したことになります。

use_default_cloud3

ここで設定としては一旦完了です。
以下で正しくネットワークが構成されていることを確認します。

今回の環境では、virbr0は以下の構成になっているとします。
(※) 仮想ネットワークの定義は、#前提条件に記載したvirsh net-dumpxmlを参照してください

NAT有効 (インターネット接続性あり)
NWアドレスは192.168.122.0/24
DHCP有効 (192.168.122.101-254)

VMを起動してIPアドレス設定や疎通性を確認します。
VMではDHCPが有効化されているため、仮想ネットワークからIPアドレスが割り振られました。
また、インターネット通信が可能であることも確認できました。
curlのオプションは、HTTP応答ステータスコードのみを表示するよう出力を整形するためのものです。

ip address show ens3

# 2: ens3
#     inet 192.168.122.250/24
# (一部のみ抜粋)

curl -so /dev/null -w '%{http_code}\n' https://www.google.co.jp

# 200

以降のセクションでは、Cloud nodeの設定を保存して使いまわすための手順を紹介します。

Cloud Nodeの登録

まず、GNS3の設定画面を開きます。
(※) Edit > Preferences、またはCtrl+Shift+P

Cloud nodesの画面でNewを選択してCloud nodeを追加します。

add_cloud1

作成するノードの名前を聞かれるので、わかりやすい名前を設定しましょう。
今回はホストからのログインやインターネット通信に使う「管理用ネットワーク」という意味を込めてManagement networkとしました。

add_cloud2

Cloud Nodeの編集

作成したCloud nodeを更に編集します。
以下の画面のようにEditを選択し、更に編集しましょう。

edit_cloud1

Ethernet interfaces

Ethernet interfacesでは、virbr0のみをブリッジ先として登録しておきます。
他のインターフェースは配線の際に邪魔になるので、除外しておきましょう。

操作方法としては以下のようになります。

Show special Ethernet interfacesにチェックを入れる
ドロップダウンリストからvirbrXを選択する
Addを選択する

edit_cloud2

Misc.

Misc.タブでは、お好みに合わせて枠で囲んだ箇所を中心に設定します。

ネットワーク名はmgmt_NW{0}という名前をつけました。

アイコンはAffinity Circle Greenのcloudに変更しました。
他のアイコンと区別しやすいように、管理用ネットワークのアイコンや配線を緑色に統一しようという思想です。

edit_cloud3

こちらで設定は完了です。
OKを選択して設定画面を閉じてください。

登録したNodeを使う

登録したCloud nodeをドラッグ&ドロップして追加すれば、保存した設定のCloud nodeを直ちに使うことができます。
アイコンがわかりやすくて便利だと思います。

Cloud nodeの便利な使い方

Cloud nodeの使い方について、便利なテクニックをいくつか補足します。

L2スイッチに接続して使う

GNS3上で、Cloud nodeには1本しか配線できません。
したがって、複数のVMと配線したい時は間に組み込みのL2スイッチを配置するのが定石です。

私の環境では、前述の通りに作成したCloud nodeとセットで使うためのL2スイッチをカスタマイズして作成しました。
動作はデフォルトのcloudと全く同じなのですが、見やすさのためにノード名とアイコンのみカスタマイズしました。
これも管理ネットワークを緑色に統一するためです。

L2スイッチを追加するには、GNS3の設定画面のBuilt-in > Ethernet switchesから設定してください。

設定内容を以下に示します。
Default name formatとSymbolのみ編集しました。
SymbolはAffinity Circle Greenのswitchです。

edit_l2_switch

配線の色も変更する

GNS3上でケーブルを右クリックすると、ケーブルの色や太さを変更することができます。
ケーブル本数が増えるとどうしても見づらくなってしまうので、管理用途とサービス用途でケーブルの色を変えることで対策できると便利です。
下図に例を示します。

green_cables

複数のCloud nodeを追加しても良い

Cloud nodeに接続するホストが増えてくると、だんだんと配線がつらくなってくると思います。
例えば上記の構成図において、更に上にもう一台L3SW2が増えた場合はどうでしょうか？
一番下のmgmt_SW1から配線しようとすると、ケーブルが重なって見づらくなってしまいます。

そんなときは、同じCloud nodeをもう一つ追加して配線しちゃいましょう。
こういった配線でも、全てのL3SWとServerは問題なく管理ネットワークと接続できます。

multiple_clouds

まとめ

GNS3のCloud nodeを使って、libvirtの仮想ネットワークとVMを接続する手順を紹介しました。

今回の手順により、VMへの管理アクセス、VMからのインターネット接続、そしてVM間通信が全て可能となります。
しかしあれこれ繋いでしまうと広大なL2ネットワークになってしまうので、ほどほどに。
virbrとのブリッジ接続は、主に管理用のネットワークに使うと良いと思います。

もちろん、物理ネットワーク機器とGNS3上のVMをブリッジ接続するためにCloud nodeを利用するのも良い使い方です。
その場合は、eth0などの物理NICとブリッジ接続するようCloud nodeを設定します。
これが一番王道的なブリッジ接続の使い方ですね。

2022-05-01

GNS3・QEMU上でvEOSを起動する

Network GNS3

お伝えしたいこと

Arista vEOSをGNS3上で起動するためのセットアップ手順を紹介します。
Arista vEOSとは、Arista社が提供するL3SWの仮想アプライアンス (VM版) です。

今回は仮想化ドライバにQEMUを使います。
QEMUは、GNS3をLinux上で動かしている方に向いています。

お伝えしたいこと
Arista vEOSのダウンロード
- (参考) AbootとAboot-serial
- (参考) vEOSの推奨バージョンの選び方
vEOSをGNS3に登録する
vEOSの起動
(参考) Arista vEOSへのログイン
(参考) ZTPとは
(参考) ZTPを無効化する方法
(任意) ZTPを予め無効化しておく
まとめ
参考サイト

Arista vEOSのダウンロード

Arista Software Downloadのページからダウンロードします。
(※) URLの通り、トップページからSupport > Software DownloadのリンクでSoftware Downloadページにアクセスできます

このページにアクセスするには、Arista社にユーザー登録する必要があります。
vEOSを利用するだけであれば、Arista社から製品を購入していなくてもアカウント登録できます。
アカウント登録完了から実際にログインできるまで、数十分ほどラグがあったと思います。

ログインできたら下の方へスクロールし、vEOS-lab配下の以下2ファイルをダウンロードしてください。

Aboot-veos-serial-x.x.x.iso (最新版を選択)
vEOS64-lab-x.xx.xM.vmdk (Mがつく中で最新版を選択)

download_veos

(参考) AbootとAboot-serial

AbootはvEOSのBootloaderです。
Aboot-veosはシリアルコンソール非対応版、Aboot-veos-serialはシリアルコンソール対応版です。

vEOSをGNS3上で動かす場合はシリアルコンソールに対応していたほうが便利なので、Aboot-veos-serialを使いましょう。

(参考) vEOSの推奨バージョンの選び方

Arista Software DownloadのRecommended Releasesタブに記載がありますが、Arista vEOSの推奨バージョンはMがつく中での最新版です。

MはMaintenance Releaseという意味であり、いわゆる安定版です。
基本的にはM付きの最新版を選ぶのが無難です。

Fというフラグがついたバイナリもありますが、これはFeatureの略です。
最新版の機能を追加したリリースであることを意味しています。
どうしても試したい機能が最新版でリリースされたときのみ、最新版のF付きリリースを試しても良いかもしれません。

vEOSをGNS3に登録する

手順の大半はGNS3・QEMU上でLinuxを起動すると同様です。
したがって、今回はややシンプルに手順を説明します。

詳細が気になった方は、上記記事をご確認ください。

(参考) vEOSの動作要件

CloudEOS and vEOS Router - Using the vEOS Router on KVM and ESXiによると、vEOSの動作要件は以下のとおりです。

項目	推奨値
vCPUコア数	最低2コア、最大16コア
RAMサイズ	最低4GiB
ディスクサイズ	最低8GiB
仮想NIC数	最大8まで

仮想ディスクファイルの格納

#Arista vEOSのダウンロードでダウンロードした2ファイルを~/GNS3/images/QEMU/配下に格納してください。
これらのファイルは、現在のユーザーが読み書きできる必要があります。
(正確には、gns3serverプロセスが読み書きできる必要があります)

ls -l ~/GNS3/images/QEMU/Aboot-veos-serial*.iso ~/GNS3/images/QEMU/vEOS64-lab*.vmdk
# -rw-r--r--. 1 endy endy   6291456 Apr 29 12:06 /home/endy/GNS3/images/QEMU/Aboot-veos-serial-8.0.1.iso
# -rw-r--r--. 1 endy endy 473235456 Apr 29 12:07 /home/endy/GNS3/images/QEMU/vEOS64-lab-4.26.5M.vmdk

GNS3にQEMU 仮想マシンとして登録する

本セクションでは、準備した仮想ディスクファイルをGNS3に登録します。

まずはGNS3を起動し、Edit > Preferences (Ctrl+Shift+P) から設定画面を開きます。

左のメニューからQEMU VMsを選択し、NewボタンからQEMUで再生する仮想マシンを新規登録します。

create_qemu_vm1

わかりやすい仮想マシン名を入力します。
今回はvEOSとします。

register_veos1

QEMUコマンドのパスを指定します。
今回は/usr/bin/qemu-kvmとします。

RAMサイズはvEOSの動作要件に合わせて4096 MiBとします。

register_veos2

コンソールタイプを選択します。
シリアルコンソールが便利なので、telnetを選択します。

register_veos3

セットするディスクファイルを選択します。
ここではAboot-veos-serial-x.x.x.isoを選択します。
vEOS64-lab-x.xx.xM.vmdkは、後ほどVMの編集画面でセットします。

register_veos4

QEMU 仮想マシンをカスタマイズする

前セクションで登録した仮想マシンを更にカスタマイズします。
作成した仮想マシンを選択し、Editから更に設定変更します。

edit_veos1

以降のセクションでは、変更した箇所をピンクの枠で囲みます。

General settings

アイコンはL3SWに近い印象のswitch_multilayerを選択しました。
CPUコア数は、ホストマシンのスペックに応じてご検討ください。

edit_veos2

HDD

Disk interfaceはvirtioを選択します。

また、ディスクファイルは以下のようにセットしてください (※)。
ディスクファイルは~/GNS3/images/QEMU/配下に格納されています。
(※) CloudEOS and vEOS Router - Launching vEOS in LinuxBridge ModeによるとISOファイルをHDCに、ディスクファイル (qcow2)をHDAにセットしていますが、これでは動きません。Abootを先に起動し、Abootからディスクファイル内のEOSを起動するのが本来の起動順序なので、Abootの方が起動の優先順位を高くする必要があります。LinuxQuestions.org - IDE master/slaveの情報も踏まえ、起動デバイスであるAbootをPrimary Masterに配置するのが良いでしょう

接続先	ディスクファイル
HDA (Primary Master)	`Aboot-veos-serial-x.x.x.iso`
HDB (Primary Slave)	`vEOS64-lab-x.xx.xM.vmdk`

edit_veos3

CD/DVD

CD/DVDは特にいじりません。

edit_veos4

Network

Arista vEOSを含め、多くのNW機器の仮想アプライアンスは先頭ポートがManagement、2ポート目以降がサービスポートという扱いになります。
Arista vEOSの場合、ポートアサインは下表のようになります。
(※) ポートアサインは実機にログインして確認しました

VMのNIC番号	vEOS上のinterface#
0	Management1
1	Ethernet1
2	Ethernet2
3	Ethernet3
4	Ethernet4
5	Ethernet5
6	Ethernet6
7	Ethernet7

GNS3上も上記のような表示名で見せるために、下図のような設定としました。
Ma1のような省略表記にした理由は、トポロジ上のNIC番号は短い表記の方が扱いやすいためです。

NIC数は動作要件に合わせて8に、性能向上のためにドライバはvirtioにしました。

edit_veos5

Advanced

Advancedは特にいじりません。

edit_veos6

Usage

最低限のコメントのみ書いておきました。

edit_veos7

vEOSの起動

登録したvEOSをGNS3上で起動します。

SwitchのカテゴリからvEOSをドラッグ&ドロップで追加します。

launch_veos1

vEOSのアイコンを右クリックし、Startを選択して起動します。

launch_veos2

vEOSのアイコンをダブルクリックしてシリアルコンソール接続します。
ターミナルが起動しない場合は、GNS3・QEMU上でLinuxを起動する - #Console applicationsを参考にしつつ、GNS3が既定で呼び出すコンソールアプリケーションを設定してください。

(参考) Arista vEOSへのログイン

起動には数分かかります。

大量のsyslogメッセージが見えてきた頃にEnterキーを押すとログインプロンプトが出てきます。

adminユーザーでログインします。
パスワードは不要です。

ログイン後、以下のコマンドを実行してZTP (※) を停止します。
ZTPを停止しないとstartup-configを生成できないためです。

zerotouch cancel

zerotouch cancelを実行すると、vEOSが再起動します。
起動してきたら再びログインし、以下のコマンドを実行します。

enable
copy running-config startup-config

これでZTPが恒久的に停止します。

(参考) ZTPとは

ZTPとは、Zero Touch Provisioningの略語です。
LinuxでいうPXE Bootと似たような概念です。

ZTPを利用すれば、Aristaの管理ポートを接続して電源投入するだけでコンフィグ投入が自動的に完了します。
ZTPの原理は、専用のZTP用サーバからDHCPでIPアドレスを受け取り、startup-configかスクリプトをダウンロードしてセットアップを行うというものです。

(参考) ZTPを無効化する方法

参考: YouTube - Networking Institute - Implementing Zero Touch Provisioning(ZTP) on Arista Switches
(※) 無料ユーザーではArista公式情報から詳細な情報を得られませんでした。Networking Instituteは、非公式ながらAristaの情報について正確かつ詳細に解説しているので、今回こちらを情報源とさせていただきました

Arista EOSの起動時、以下の2つの条件を満たせばZTPが開始されます。
(※) zerotouch cancelという例外パターンもありますが、この後説明します

/mnt/flash/startup-configが存在しないこと
/mnt/flash/zerotouch-configにDISABLE=Trueと書かれていないこと

初期状態のArista EOSは、上記のどちらのファイルも存在しないためZTPを開始する条件が揃っています。

ZTPを停止する方法は大きく分けて2つあります。

zerotouch cancelを実行し、再起動後にcopy running-config startup-configを実行する
zerotouch disableを実行する

zerotouch cancelを実行すると、直後にEOSが再起動します。
そしてZTPが無効化された状態でEOSが起動します。

zerotouch cancelによるZTPの無効化は一時的なものです。
copy running-config startup-configによって/mnt/flash/startup-configを生成すれば、ZTPの無効化が永続的なものとなります。
startup-config生成前に再び再起動すると、ZTPが有効化されて起動してきます。

zerotouch disableによるZTPの有効化は永続的なものです。
このコマンドの実行により/mnt/flash/zerotouch-configにDISABLE=Trueが書き込まれます。
これにより、startup-configの有無に関わらずZTPが永続的に無効化されます。

(任意) ZTPを予め無効化しておく

ZTPを使わない場合、毎回zerotouch cancelを実行するのは面倒だと思います。
そこで、本セクションでは予めZTPを無効化した上でテンプレート化するための手順を紹介します。

まず、~/GNS3/images/QEMU/配下にあるvEOSのvmdkファイルをコピーしておきます。

cd ~/GNS3/images/QEMU/
cp -pi vEOS64-lab-4.26.5M.vmdk vEOS64-lab-4.26.5M_zerotouch_disable.vmdk

続いて、GNS3を起動して設定画面を開きます (Ctrl+Shift+P)。
QEMU VMsセクションにて、作成済みのvEOSの設定をコピーします。
新しいVMの名前を求められるので、vEOS (ZTP Disabled)としておきます。

copy_veos_vm_settings

続いてEditからvEOS (ZTP Disabled)の設定をカスタマイズします。

edit_veos_ztp_disabled1

General settingsタブで、Default name formatを{name}-{0}からvEOS-{0}に変更します。

edit_veos_ztp_disabled2

HDDタブで、HDBに先ほどコピー作成したvmdkファイルをセットします。
(※) vEOS64-lab-x.xx.xM_zerotouch_disable.vmdk

edit_veos_ztp_disabled3

Advancedタブで、Use as a linked base VMのチェックを外します。
これにより、GNS3上にVMを追加した際のVMクローン処理が無効化され、VMテンプレートを直接書き換えることができます。

edit_veos_ztp_disabled4

作成したvEOS (ZTP Disabled)をGNS3上で起動します。

launch_veos2

起動したvEOSにシリアルコンソールで接続し、adminユーザーでログインします。
そして以下のコマンドを実行することでZTPを恒久的に無効化します。

zerotouch disable

vEOSの再起動後、再びadminユーザーでログインします。
そして、以下のコマンドによってOSをシャットダウンします。

enable
bash
sudo shutdown -h now

vEOSをGNS3上で右クリックして削除します。
これによってvEOS (ZTP Disabled)はGNS3のトポロジ上からは消えますが、実際にはZTPが無効化された設定込のデータが~/GNS3/images/QEMU/vEOS64-lab-x.xx.xM_zerotouch_disable.vmdkに残っています。

delete_veos_on_gns3

最後に、vEOS (ZTP Disabled)の設定を開き、AdvancedタブからUse as a linked base VMを再び有効化します。

edit_veos_ztp_disabled5

以上の操作により、ZTPが無効化されたvEOSテンプレートを作成できました。

まとめ

Arista vEOSをGNS3上にQEMU VMとして追加する手順を紹介しました。
前回記事のLinuxやVPCSと組み合わせれば、vEOSを使った一通りのハンズオンができると思います。

参考サイト

ネットワークチェンジニアとして - Arista vEOSの基本的な使い方

Arista vEOSのダウンロード方法について、本ブログよりも更に丁寧に解説されています。
またGNS3ではありませんが、ESXiへのvEOS登録手順が解説されています。

vEOSのダウンロードとセットアップ手順を調べる際、大いに参考にさせていただきました。

記事内のリンクにvEOSでよく使いそうなMLAGやVXLAN、EVPNの解説もあります。
こちらは、GNS3セットアップ後の検証を行う上で大変役に立ちます。

Fedoraの変更点シリーズ

お伝えしたいこと

Fedoraの変更点シリーズ

お伝えしたいこと

公式情報の見方

Release Notes & Changes

Python 3.11

Bugs

その他

Kickstartのオプション

まとめ

Fedoraの変更点シリーズ

お伝えしたいこと

公式情報の見方

Release Notes & Changes

remove-retired-packagesコマンドがインストール可能に

/etc/sysconfig/network-scripts/ifcfg-* がデフォルト無効に

Bugs

Fedora36にアップデートした後SELinuxの不具合が出る

まとめ

お伝えしたいこと

Snapとは

Snapdのインストール

Slackのインストール

パッケージを探す

Confinementを確認する

インストールする (strict confinementの場合)

その他の基本コマンド

(参考) Snapを使う理由

(参考) classic confinementのパッケージインストール

Confinementの確認

初期設定

インストール

まとめ

Linux PC関連まとめ

お伝えしたいこと

文字化け

GNS3 GUI上の操作は電源を切ってから

仮想マシンをグループに所属させないこと

セキュリティソフトに要注意

まとめ

お伝えしたいこと

前提条件

(参考) 前提知識

libvirtの仮想ネットワーク

GNS3のCloud node

手順

virbrインターフェース番号を調べる

(参考) GNS3上でCloud Nodeを使用する

Cloud Nodeの登録

Cloud Nodeの編集

Ethernet interfaces

Misc.

登録したNodeを使う

Cloud nodeの便利な使い方

L2スイッチに接続して使う

配線の色も変更する

複数のCloud nodeを追加しても良い

まとめ

お伝えしたいこと

Arista vEOSのダウンロード

(参考) AbootとAboot-serial

(参考) vEOSの推奨バージョンの選び方

vEOSをGNS3に登録する

(参考) vEOSの動作要件

仮想ディスクファイルの格納

GNS3にQEMU仮想マシンとして登録する

QEMU仮想マシンをカスタマイズする

General settings

HDD

CD/DVD

Network

Advanced

Usage

vEOSの起動

(参考) Arista vEOSへのログイン

(参考) ZTPとは

(参考) ZTPを無効化する方法

(任意) ZTPを予め無効化しておく

まとめ

GNS3にQEMU 仮想マシンとして登録する

QEMU 仮想マシンをカスタマイズする