えんでぃの技術ブログ

えんでぃの技術ブログ

ネットワークエンジニアの視点で、IT系のお役立ち情報を提供する技術ブログです。

Fedora39の変更点

fedora_logo

Fedoraの変更点シリーズ

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

Fedoraの変更点シリーズ

お伝えしたいこと

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

公式情報の見方

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

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

fedora_change_sets

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

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

Release Notes & Changes

Bashプロンプトに色がついた

Fedora 38以前ではBashプロンプトには色がついていませんでしたが、Fedora 39以降では色がつくようになりました。
また、直前のコマンドのExit Statusが0以外の場合にプロンプト文字列として表示されるようになりました。

↓従来のプロンプト

monochrome-bash-prompt

Fedora 39以降のプロンプト

colored-bash-prompt

なお、この色付けはログインシェルに対してしか適用されません。

具体的には、SSHでログインした場合には適用されません。
SSHでログインしたあと、更に手動でbashコマンドを実行すると適用されます。

login_to_colorize_bash

PROMPT_COLOR変数にカラーコードを入れることで、任意の色に変更できる作りになっています。
カラーコードの書き方はbash:tip_colors_and_formattingが参考になります。
以下の例では35がPurple、96がLight Syan、33がYellow、1がBold (太字) という意味になります。

prompt_color_to_customize

SSHログイン時も反映したい場合は、以下のスクリプト~/.bashrcに追記します。
sourceコマンドの後にPROMPT_COLORを変更してもしっかり反映される作りになっています。

source /etc/profile.d/bash-color-prompt.sh
# PROMPT_COLOR=33

Bashプロンプト色付けの詳細

今回の変更は、Fedora39以降に初期インストールされているbash-color-promptというRPMパッケージによって導入されました。

rpm -ql bash-color-prompt、またはdnf repoquery -l bash-color-promptによってインストールされたファイル群を確認すると、/etc/profile.d/bash-color-prompt.shというシェルスクリプトが追加されていることがわかります。
シェルスクリプトの中身を見てみましょう。

if [ "$PS1" = "[\u@\h \W]\\$ " -a "${TERM: -5}" = "color" -o -n "${prompt_color_force}" ]; then
    PS1='\[\e[${PROMPT_COLOR:-32}m\]\u@\h\[\e[0m\]:\[\e[${PROMPT_COLOR:-32}m\]\w\[\e[0;31m\]${?#0}\[\e[0m\]\$ '
fi

ちょっと読むのが辛いかもしれませんが、最初のif文は以下の意味です。

  • PS1変数が初期値かつ、TERM変数がcolorで終わる場合 (手元の環境ではTERM=xterm-256colorでした)
  • または、prompt_color_force変数が空ではない場合

そして条件にマッチしたとき、PS1を書き換えています。
PS1はBashの中で特殊な意味を持つ変数であり、この変数を書き換えることでプロンプト文字列を変更できます。
(参考) Bash Reference Manual - Controlling the Prompt

以上より、Bashにログインしたときに特定の条件を満たしていればプロンプトがカスタマイズされることがわかりました。

上記スクリプト/etc/profile.d/配下に書かれているので、「bashログイン時」のみに実行されます。
そのためSSHログイン時も含めてbash起動時もプロンプト文字列を変更したい場合には、~/.bashrcをカスタマイズする必要がありました。

KickstartDNS関連のオプションが追加された

Kickstartで以下のオプションを追加で使えるようになりました。
いずれもネットワークインターフェースに紐づけて設定するDNS関連のオプションです。

オプション名 意味
--ipv4-dns-search
  • NetworkManagerのipv4.dns-searchに相当
  • 通信の宛先にDNSショートネームを指定した場合に
    自動補完するドメイン名を指定する
  • IPv4に対してのみ有効
--ipv6-dns-search
  • 同上
  • ただしIPv6に対してのみ有効
--ipv4-ignore-auto-dns
  • DHCPによるDNSサーバ自動設定を無効化する
  • IPv4に対してのみ有効
--ipv6-ignore-auto-dns
  • 同上
  • ただしIPv6に対してのみ有効

EFIファイルシステムの最小サイズが200 MiBから500 MiBに拡張

マザーボードファームウェアBIOSではなくUEFIを使っている方に該当します。
ESP (EFI System Partition) という先頭に作られるパーティションのサイズが最小200 MiBから500 MiBに引き上げられました。
ファームウェア更新時に必要な空き容量が近い将来引き上げられることが背景にあります。

ESPの最大サイズは従来の600 MiBのまま変更ありません。
また、BIOSをお使いの方には影響ありません。

NetworkManager-initscripts-ifcfg-rhパッケージはFedora 41以降提供されない

この変更はNetworkManagerをGUInmclinmtuiなどで操作している方には影響ありません。
RHEL6時代まで続いたnetwork-scripts形式の設定ファイルを編集して運用している方に影響があります。

NetworkManager-initscripts-ifcfg-rhパッケージについて、詳細はFedora36の変更点 - /etc/sysconfig/network-scripts/ifcfg-* がデフォルト無効にを参照してください。

Python 3.12

Fedora 38ではPython 3.11系でしたが、Fedora 39系ではPython 3.12系が提供されるようになります。

Fedoraはリリースのたびに最新のPythonバージョンに追従することが基本ポリシーのようです。
(おそらく他の言語も同様ですが、Python以外はチェックしていません)

Bugs

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

まとめ

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

Fedora38の変更点

fedora_logo

Fedoraの変更点シリーズ

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

Fedoraの変更点シリーズ

お伝えしたいこと

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

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

以上。

Fedora37の変更点

fedora_logo

Fedoraの変更点シリーズ

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

Fedoraの変更点シリーズ

お伝えしたいこと

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

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

公式情報の見方

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

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

fedora_change_sets

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

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

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の更新点をまとめました。

Fedora36の変更点

fedora_logo

Fedoraの変更点シリーズ

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

Fedoraの変更点シリーズ

お伝えしたいこと

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

公式情報の見方

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

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

fedora_change_sets

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

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

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 reloadsystemctl restart NetworkManager.serviceなどで設定を再読込する運用をしている方がいれば、今回の変更は重要なものになります。
少数派だと思いますが...。

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

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

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のデフォルト値は以下のように変遷しました。1

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

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

keyfile Pluginは、NetworkManagerRPMファイルに必ず同梱されます。
一方で、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の不具合が出る

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

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

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

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

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

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

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

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

dnf list installed *selinux*

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

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

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

まとめ

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

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

お伝えしたいこと

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

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

Snapとは

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

Snapdのインストール

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

sudo dnf install snapd

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

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でパッケージをインストールする際は、以下の流れで進めます。

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

パッケージを探す

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

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

Publisherslack✓と記載されている通り、チェックマークがついています。
これはパッケージメンテナが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のいずれかです。3, 4

  • strict
    • 最も一般的なconfinement
    • アプリケーションからシステムへのアクセスを適切に制限する
    • アクセス先によっては、ユーザー操作を求める (カメラなど)5
    • 許可されないアクセスは拒否する
  • 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つです。

  1. RPMファイルを公式サイトからダウンロードしてインストールする
  2. 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 CodeFedoraリポジトリで提供されるので、わざわざSnapでインストールする必要はありません。
ここでVS Codeをインストールしているのは、あくまで例示のためです。

Confinementの確認

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

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

初期設定

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

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

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

お伝えしたいこと

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

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

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

文字化け

GNS3において、日本語 (※2バイト文字) は全力で避けてください。
GNS3上のマシン名はもちろんのこと、GNS3のバックエンドで動作しているVirtualBoxQEMU上の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 VMVirtualBox上でグループに追加する
  • 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周りの主なトラブルと回避方法を紹介しました。
皆様の時間節約につながれば幸いです。

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

お伝えしたいこと

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

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

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

前提条件

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

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

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

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の仮想ネットワーク

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上で動作しているVMlibvirtの仮想ネットワークと接続するための手順を紹介します。
前述の通り、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に対して配線します。
これでVMvirbr0にブリッジ接続したことになります。

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 Greencloudに変更しました。
他のアイコンと区別しやすいように、管理用ネットワークのアイコンや配線を緑色に統一しようという思想です。

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 formatSymbolのみ編集しました。
SymbolはAffinity Circle Greenswitchです。

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を設定します。
これが一番王道的なブリッジ接続の使い方ですね。