Manjaro Linux, Arch Linux共にDiscordがCommunityパッケージに

AURからなくなったDiscordの行方

先日の記事でDiscordがAURから削除され、Snappyを利用するように変更されたということを記事にしたが、2018-08-13 MANJAROのstable updateでcommunityパッケージに追加された

もう少し解説

ManjaroのリポジトリはArchとは独立しており、そのパッケージングポリシーも少し違う。 一方でArchのユーザー投稿リポジトリであるAURのパッケージのほとんどが利用できる程度には互換性がある。

原則として、AURにはArchの公式パッケージとして存在するものは投稿できないし、AURのパッケージがArchのパッケージになる場合、AURから削除される。 一方、Manjaroにおいてはもっと広く、「多くの一般ユーザーが欲しがるパッケージ」が公式パッケージに加わっているため、AURと重複するパッケージというのが存在している。これは時々トラブルの元になる。 例えば公式パッケージから削除されたときにAURパッケージがインストールされてしまうなどだ。

今回のAURからの削除は、重複するパッケージを設置しないというArchのポリシーに基づき、Snappyによってインストールすることを推奨するものかと推察された。 これに対しManjaroがAURから削除されたパッケージを「必要としている」と判断して独自にDiscordをパッケージングしたという理解だ。 だが、実際にはArchのほうもcommunityパッケージとしてDiscordが追加された

extraではなく、サポートの手厚いcommunityパッケージというのは驚きだが、これは「LinuxerにとってコミュニケーションツールはDiscordが標準となっている」ということでもあるのだろう。

やはりSnappy版よりもフォントレンダリングをはじめ全体的に良いので、よかったと思う。 ちなみに、Discord自体、最近debパッケージだけでなくバイナリパッケージも配布している。

Manjaro/Arch Linux, DiscordがAURから消滅 Snappy利用に …Snappy?

重要な追記

新しい記事に状況の更新が書かれている

あらまし

Manjaro Linuxの2019-08-07のツイートによれば

We are happy to announce the availability of @discordapp @ManjaroLinux. Read more about it on our forums: https://t.co/XbuhEJCFUC https://t.co/MH7Pjhn6EH

というわけで、なんかDiscordの扱いが変わったらしい。

というわけでAURを見てみると…AURからDiscordがなくなっている! Extra行きでもない!!

で、フォーラムを見てみると「Snappy使えよ」ということになっている。

Snappy?

Sanppy

SnappyについてはWikipediaに既に記事がある

Snappyとはカノニカルが設計・開発したソフトウェアデプロイメントシステムかつパッケージ管理システムであり、元々はUbuntu Phoneオペレーティングシステム用に設計・開発された。

a-ha?

ちゃんとArchwikiにも記事がある。 そして、snapcraftのサイトにManjaroについての記述がある

が、どれも後述するようにちょっと微妙である。

簡単に言えば、パッケージがライブラリとか全部含めてSquashFSにしてあるのでディストリビューションごとの調整とかいらないよ、という話である。

はっきりいってしまえば、いわゆるポータブルアプリである。 こういうの、前からちょいちょいあった。そして、いろんな意味で微妙なのである。

一番の理由は容量をえらいとる、というのがある。 管理がばらつくとか、制御しづらいとか、パッケージの信頼性が担保しにくいとか、他にも理由はたくさんある。

インストール

必要なのはcommunityパッケージのsnapd

$ sudo pacman -S snapd

snapdをenableしろと言っているが、snapdが必要なのはパッケージ操作時のみ。

$ sudo systemctl start snapd

Discordをインストール。結構長い。

$ sudo snap install discord

パッケージ操作はもうしないのでsnapdは止めてしまって良い

$ sudo systemctl stop snapd
$ sudo systemctl stop snapd.socket

起動と感触

Snappyを使って起動する。snapdは必要ない。

$ snap run discord

起動すると、フォント選択とフォントレンダリングに少し違和感があること、カーソルが異なるものになってしまうことが気になる。 あと、Cinnamon上でアプリケーションアイコンが表示されない(systrayには表示される。これは.desktopファイルの設定によらず改善しない)。

また、アプリケーションアイコンのコンテキストメニュー(通称デスクトップメニュー)に機能しない “New Window” がある。

使えないわけではないけど、やっぱりいまいちだ…

(2019-08-12 追記)

システムを再起動したところ

  • アイコンは出るようになった
  • discordコマンドで実行できるようになっている (/var/lib/snapd/snap/bin/discordを呼んでいる)
  • カーソルとフォントは相変わらず
  • .desktopメニューに“New Window”があるのは相変わらず。[Desktop Action]は定義されてないけれど
  • systrayのDiscordアイコンクリック時に“Top Secret Control Panel”が出る。これは右クリックの挙動で、クリック時はwindow activateされるのが正しいはず

Snappyについて

Manjaroの場合AURにDiscordがあったので、それを前提にするのであれば大幅な後退であるというのが基本的な印象だ。

しかし、それはちょっと傲慢過ぎる。

Arch LinuxやManjaro Linuxの場合、ほとんどのソフトウェアはAURにあり、そのいずれも(Launchpadと比べても)クオリティが高く調整が行き届いている。 だが、現実には依然としてバイナリのみの配布となっていて、Ubuntu向けdebパッケージのみが配布されているケースはかなり多い。Discordもそうである。

このようなソフトウェアの存在のために現実的にはUbuntuパッケージが使えるUbuntu系列のディストリビューション、AURで調整されているArch系列のディストリビューションぐらいしか選べないという状況が出来上がる。せいぜいがFedora。 実際にopenSUSE, Mageia, Sabayon Linux, PCLinuxOSを使っていたときは使えるソフトウェアに著しい制限がかかる状況であった。

そうした状況は健全とはいい難いため、そのようななんらかのポリシーによって限定的なパッケージでバイナリ配布されるソフトウェア1が広くディストリビューションを限定せずに利用できる、という意味ではSnappyによってサポートされるというのは悪い話ではない。

だが、Snappyに統一されるべきかというと、ちょっと首肯は難しい。 Snapcraftがどれだけメンテナンスされるか、きちんとチェックされるかというところで、やはり信頼感はかなり差がある。Launchpadが結構ひどく、AURがほとんどのパッケージはちゃんとしていることを考えるとやはりAURで欲しい。クオリティ的にもSnappyがいまいちであることを考えるとSnappyを理由にAURからドロップするのは結構残念な気持ちになる。

余談だが、Ubuntu向けdebパッケージで提供されるっていうのは結構扱いにくい。debパッケージはちょっと特殊なので、PKGBUILDを書いてリアッセンブルするのが割と手間なのだ。specを変換するだけのRPMのほうがずっと楽だろう…と私は思うのだが、なぜかAURのパッケージ群はRPMがあるソフトウェアでも大抵debをリアッセンブルしているので、ひょっとしたらこれは私の認識が正しくないのかもしれない。


  1. 「バイナリ配布だから限定的なパッケージである」という理解は間違っている。例えばFirefoxはLinux向け完パケバイナリが存在し、ポータブルアプリとして実行可能である。↩︎

最小限の環境を作る「フォントえらび」

私は基本、4台のコンピュータを運用している。これはまんま「3部屋+携行」なのだが、それぞれの最終システムインストール日を見ると

  • ThinStation P720 (2019-01)
  • FM2A88X (2017-12)
  • Z400 Workstation (2019-07)
  • ThinkPad X1 Carbon 5thGen (2018-06)

である。ちなみに、これはjournalctlすれば分かる。

システムセットアップ時に悩ましいのがフォントだ。 ここではManjaroを前提にして語るが、日本語フォント関連のパッケージは“font japanese”で検索すると62ほどあり、うち公式パッケージは源ノ角ゴシック、源ノ明朝、IPAフォント、花園明朝、さざなみフォントである。

フォント関連のAURパッケージはあまりメンテナンスされないことが多く、多くのフォントを維持するのはかなり厳しい。インストール時間もかかるので入れるのもしんどい。 ひとつにまとめて、それを/usr/local/share/fontsなどに入れて運用する方法もあるのだが、商用フォントの除外という手間もあるし、OS側(/usr/share/fonts)との兼ね合いもディストリビューションが違ったりすると特に発生しがちなので割と難しい。

なにより、「フォントの数」と「画面の総ピクセル数」は ものすっごく 反応速度に影響するのだ。遅い遅いと思っていたマシンをまっさらにして1366*768なディスプレイをつないだら爆速になったりしている。 だから、メインマシン(もしくはフォントを使うようなアートワーク作業をするマシン)だけにフォントを積んで、他はessentialに運用したい。

ここでは私の経験に基づいてよいと判断したessentialを紹介するが、好みによることはご了承いただきたい。

先に結論

% trizen -S adobe-source-han-sans-jp-fonts adobe-source-han-serif-jp-fonts ttf-cica ttf-ume
  • 商用フォント顔負けのクオリティで出せる源ノ角ゴシック、源ノ明朝
  • zsh-theme-powerlevel9kpowerlineを入れた場合に必要になるpowerlineシンボルなどまでカバーし、日本語コーディングフォントを必要する場合に有用なCica
  • MS日本語フォントにメトリック互換の梅フォント

という構成である。

好みのちょい足し

もう少し意味を補強すると、IPAフォントがあるとLibreofficeで文書をやりとりするようなケースでは有効である。 IPAフォントは公式パッケージなのでインストールしてもいいかもしれない。

さらにいえば、コーディングフォントは日本語フォントである必要はなかったりする。 私が様々なコーディングフォントで様々なコードや文章を書いた経験で言えば、長時間使っていて快適性が高かったコーディングフォントは

  • Hermit
  • Input Mono
  • Fira Mono
  • Meslo
  • Camingo Code
  • Roboto Mono

だった。

あと、私は個人的にMiguも好きなので、

% trizen -S otf-ipafont ttf-migu otf-hermit

好みのちょい盛り

ひょっとしたらスタイリッシュな欧文フォントがないことが不満かもしれない。 定番としてはSenとかだったと思うのだけれど、今SenはGoogle Fontsから外れてしまった。 Overlockも定番。これは個人的には静凛さんのチャット欄がOverlockなので馴染みがある。

ManjaroのロゴフォントであるComfortaaは最近のManjaroはデフォルトで入っていたりする。

あと、Joseffin Sansも好き。

かっこいいSerifフォントが欲しい、とかいうと特に定番はないので、GoogleでSerifカテゴリを選択して探していただくのがよかろう。 Serifフォントに関しては私は商用のHumanist Slab 712を使っていたりするし。 どうしてもお勧めというのであれば、MartelとかCormorant Garamondとか、Abhaya Libreとかだろうか。

そして個人的には源ノ角ゴシックも良いが、やっぱりモトヤフォントが好きだ。 それにこのラインナップでは丸ゴシックがない。

そこで小杉ゴシック小杉丸ゴシックだ。 小杉ゴシックは元「モトヤ Lシーダ W3等幅」、小杉丸ゴシックは「モトヤ Lマルベリ W3等幅」のリネームである。 これらはApache Lisence 2.0でAndroidに載っていたフォントだ。

好みの盛り盛り

ドキュメントを書く上で使いやすいフォントに欠けるので、源暎フォントを追加している。 ただし、これはドキュメント生成、つまりPandocを使う端末のみ。

あと、本文フォントは「源暎ラテミン」よりも「元陽逆アンチック」のほうが人気があるので、それも入れておく

セットアップ

言葉はいらないよな?

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
    <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
        <its:translateRule translate="no" selector="/fontconfig/*[not(self::description)]"/>
    </its:rules>

    <description>Re-define sans-serif, serif and monospace.</description>
    <match target="pattern">
        <test qual="any" name="family">
            <string>sans-serif</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Joseffin Sans</string>
            <string>MotoyaLCedar</string>
            <string>Source Han Sans JP</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>serif</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Overlock</string>
            <string>GenEi Koburi Mincho</string>
            <string>Source Han Serif JP</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>monospace</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Hermit</string>
            <string>Cica</string>
            <string>Migu 1M</string>
        </edit>
        -->
    </match>
</fontconfig>
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
    <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
        <its:translateRule translate="no" selector="/fontconfig/*[not(self::description)]"/>
    </its:rules>

    <description>Substitude popular Japanese fonts</description>

    <match target="pattern">
        <test qual="any" name="family">
            <string>MS Pゴシック</string>
        </test>
        <test qual="any" name="family">
            <string>MS PGothic</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Ume P Gothic S5</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>MS P明朝</string>
        </test>
        <test qual="any" name="family">
            <string>MS PMincho</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Ume P Mincho</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>MS明朝</string>
        </test>
        <test qual="any" name="family">
            <string>MS Mincho</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Ume Mincho</string>
        </edit>
    </match>
</fontconfig>

【Manjaro/Arch Linux注意】Yaourtは廃止になりました

すごくニュースだと思うんだけれど、全然話題になっていないけれど。

AURヘルパーである YaourtはAURからなくなりました

もう随分長いこと「非推奨」とされてきたのだけれど、ついになくなった、というかたち。

AURヘルパーの中ではYaourtが最も親しまれてきたし、最も有名だった。 「Yaourtを使う」というのが当たり前になってもいた。

けれど、近年はセキュリティ上の問題があり、メンテナンスされていないことからobsolateになっていた。 で、今ついにAURからなくなった、ということ。

これに伴って、CommunityパッケージになっていたManjaroでもYaourtは廃止に。

今後はyayなり、Trizenなりを使っていくことになる。

そのうち「Yaourtを野良ビルドして使う」みたいな記事が出てきそうだけれども、 危険なのでやめましょう

Archwikiでは2019-05-20現在、日本語版はそのままであるものの、英語版はYaourtに関する記述自体が削除されている。

systemd-nspawnでManjaro LinuxからArch Linuxする

systemd nspawn

なんかSystemdを毛嫌いする人が多いのだけど、結構使いやすくて便利な機能が多いので、私は好きだ。Xサーバーみたいだと思う。

systemd-nspawnはcrgoupsを利用したLinuxコンテナである。 LXCよりもずっとシンプルな実装で、かつ簡単に使うことができる。 全然知られていないけど。

とりあえずArchする

Manjaroにもarch-install-scriptsがあるためpacstrapできたりする。 なので、初回インストール前には

# pacman -S arch-install-scripts

とやっておく。

そしたらコンテナを作る。 こちらは新規コンテナを作るときにやる作業。

# pacstrap -i -c ~/Container base base-devel

Arch Linuxをインストールしたことのある人ならわかると思うのだけど、 最低限baseがないと機能しない。そして、AURを利用する場合はbase-develも含んでおかないといけない。

あとはログインする。 これは、起動時に実行するもの。

# systemd-nspawn -b -D ~/Container

これでコンテナを起動することができる。終了する場合、コンテナ上で電源を切る。 終了は少し時間がかかる。

# poweroff

LXCと違って自動的にブリッジインターフェイスもセットアップされ、起動しただけでネットワークがちゃんと機能する状態になる。 LXCと比べても随分と話が早い。

ManjaroだとArchを構築するのは簡単だし、もちろんArchやAnterogosでも簡単だけど、そうでないディストリビューションがどうやってコンテナ上にOSをインストールするか、については各々調べて欲しい。 私はArchが使えれば満足なので、コンテナ上で他のディストリビューションを使おうとは思わないし、現状、Manjaro以外をホストにしようとも思わないからだ。

おまけ。この環境からPowerlevel9kするために

ちょっとつまずいたのでおまけ。 標準ロケールがen_US.utf8になっているため、Powerlevel9kのPowerline記号が出ない。

そこで、/etc/locale.genを編集してja_JP.UTF-8 UTF-8をアンコメントし、

# locale-gen

そして、/etc/locale.confを編集してLANGja_JP.UTF-8にしてから

# localectl set-locale LANG=ja_JP.UTF-8

これでちゃんとPowerlevel9kのアイコンが出るようになる。

(Manjaro Linux) KDE PlasmaでXFce4通知が使われる

先日のAdaptaのアップデートからManjaro XFce4からインストールした環境で使用しているKDE Plasma上で通知が黒背景黒文字になるという問題が発生していた。

KDE Plasmaの通知を設定しても全く改善されないためどうしたものかと非常に困っていたのだが、 よく見てみるとKDE Plasmaの通知ではなく、XFce4 Notifyになっていた。

そこでxfce4-notifydを止めたいと考えたのだが…

xfce4-notifydはsystemdユーザーユニットとして存在していて、/usr/lib以下にコマンド本体がある。 だからsystemctl --user stop xfce4-notifydで一応止まるように見える。 (場合によってはkillする必要がある)

ところが、ここでnotify-sendするとふたたび起き上がってきてしまう。

これを止めるジェントルな方法を模索したのだが、見つからなかったので、仕方なく/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.serviceを削除(というか外へ移動)した。 これは恐らく意図以上の影響を及ぼすだろうが、とりあえず当面の問題は解消できた。

Arch / Manjaro open-iscsiのサービスユニット名が変更

Manjaro Linux Stable Update 2018-10-25でopen-iscsiのサービスユニットがopen-iscsi.serviceからiscsi.serviceに変更になった。 これはArch Linux側でも行われた変更である。

結果的に、open-iscsiに依存しているユニットが正常に起動できなくなった(特に自作したサイトローカルユニットは)。 それに加え、従来open-iscsi.serviceをenableにしていた場合でも起動されなくなった。

必要な対応は以下の通り。

まず、open-iscsi.serviceという名前を用意する場合

  • /usr/lib/systemd/system/iscsi.serviceAlias=open-iscsi.serviceを書いておいた上でenableする
  • または/usr/lib/systemd/system/open-iscsi.service -> /usr/lib/systemd/system/iscsi.serviceというシンボリックリンクを用意する

iscsi.serviceという名前に合わせる場合

  • 他のユニットでopen-iscsi.serviceとなっている箇所を全てiscsi.serviceに修正する
  • 必要ならばiscsi.serviceをenableする

これはイニシエータの話だけれども、ターゲット側もopen-iscsid.serviceからiscsid.serviceに変更されているので同様である。

AMD APU (A10-7870K Godavari) * Radeon VCE * AMDGPU * VA-API * ffmpeg

理屈としては解説してきたものの、実際にVA-APIでVCEを叩いたことがなかったのでやってみた。 ついでなので、qsvやnvenc、あるいはlibx264などでも応用できるウェブカメラとスクリーンキャスティングの話もしておく。

基本的な手順は単純で、AMDGPU(事実上現在唯一となったAMDビデオドライバ)を選択した上で、 VA-APIを有効にし、VA-API経由でエンコーディングを行う。

注意点としては古くなったプロプライエタリドライバ(Catalyst)ではなく、AMDGPUドライバーを使用することと、 MESA VAドライバを使用することである。

RadeonはVA-API/VDPAUの両方をサポートしており、NvidiaのようにVDPAUドライバをインストールし、VA VDPAUアダプタを使用するという方法(libva-dvpau-driver)も成立してしまう。 しかし、この場合は動作しなくなるので、必ずMESA VAドライバ(libva-mesa-driver)を使用する必要がある。

その上で基本はこんな感じ。 (Arch/ManjaroのffmpegはVA-APIを含んでいるのでffmpeg云々の話はない)

$ ffmpeg -vaapi_device /dev/dri/renderD128 -i source.avi -vf 'format=nv12,hwupload' -c:v h264_vaapi -qp 24 -c:a copy outfile.mp4

ffmpeg上でのVA-APIは公式にドキュメントがある

ソースファイルがビデオアクセラレーションが効くのであればUVDをVA-API経由で叩いてデコードすることもできる。

$ ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i source.avi -vf 'format=nv12,hwupload' -c:v h264_vaapi -qp 24 -c:a copy outfile.mp4

ところがこれではうまくいかなかった。 一件成功しているように見えるのだが、フレームの全くないビデオファイルが出来上がってしまい再生できない。

多分、新しいRadeonだとそんなことはないのだろうと思うけれども、Godavari(2015年)のR7グラフィックスでは問題があったため、-profile 578を指定すると解決した。

$ ffmpeg -vaapi_device /dev/dri/renderD128 -i source.avi -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -bf 0 -qp 24 -c:a copy outfile.mp4

ウェブカムからキャプチャする場合はエンコードのみ、入力はv4l2:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f v4l2 -i /dev/video0 -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -qp 24 outfile.mp4

さらにマイクをPulseAudio経由で拾う場合。音声は192k AAC:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f v4l2 -i /dev/video0 -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

X11のスクリーンキャスティング 音声つき。 A10-7870Kだとh264_vaapiは34fpsくらいなので、60fpsはフレーム落ちばかりになる。30fpsも無理で24fpsがドロップしない限界。 ultrafastにした場合は30fpsは可能だけれど60fpsは無理。

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 24 -video_size 1920x1080 -i $DISPLAY -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

ultrafastで30fps:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 30 -video_size 1920x1080 -i $DISPLAY -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -preset ultrafast -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

なお、-video_size-iよりも先に指定することが必須である。基本的にffmpegはオプションは順番に厳しい。

300×300のウィンドウを左上から200×200のオフセットで録画する場合

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 30 -video_size 300x300 -i $DISPLAY+200,200 -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -preset ultrafast -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

-video_sizeの指定方法は色々あって、公式ドキュメントで解説されている。 なので、-video_size 1920x1080ならば-video_size hd1080とも書ける。

録画領域を表示するには-show_region 1

$ ffmpeg -show_region 1 -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 30 -video_size hd1080 -i $DISPLAY -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -preset ultrafast -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

NVENCだとmkvにもできるので音声はFLACやOpusで撮ることもできるのだけど、AMDGPU VA-APIはmp4だけ

使ってみた感想としては、QSVと違ってCPUがあくのは良いけれど、R7の速度自体がCPUと大差ない(libx264でやったのと同程度)であるため、ちょっと微妙かもしれない。 A10でもスクリーンキャスティングしながら配信みたいなことができるというメリットはあるけれども。

Linux: 特定のアドレスに到達しないことを明示する (route/ipコマンド)

open-iscsiを用いたiSCSIイニシエータの場合、iSCSIターゲットが複数のIPアドレスを持っているとMultipathによってその全てのアドレスで接続しようとする。

だが、例えば192.168.1.0/24に属するコンピュータで、192.168.1.0/24, 192.168.2.0/24の両方に属しているNASを使おうとすると、192.168.2.0/24に対する経路がなければタイムアウトするまでひどく待たされることになる。 デフォルトゲートウェイ経由で192.168.2.0/24に対するパケットを投げ続けるためだ。

そこで、このコンピュータは192.168.2.0/24には通じていないことを明示して、即座に失敗させたい。

これはネットワークマネージャの設定では行うことができない。 コマンドで行う必要がある。

routeコマンドに関してはManpageに書いてあるのでわかりやすい。

# route add 192.168.2.0 netmask 255.255.255.0 reject

だが、Arch Linux系列のディストリビューションで標準採用されるipコマンド (iproute2) のほうは1Manpageがものすごく読みにくい上に日本語訳もされていないのでちょっと大変だ。 ipコマンドの場合は次のようにする。

# ip route add prohibit 192.168.2.0/24

これにより192.168.2.0/24に対する接続はそもそも禁止されることになる。

% ping 192.168.2.64
Do you want to ping broadcast? Then -b. If not, check your local firewall rules.
% telnet 192.168.2.64
Trying 192.168.2.64...
telnet: Unable to connect to remote host: 許可がありません

  1. そもそもrouteやifconfigなどを使わず、iproute2(ip)を使うということをどれくらいの人が知っているのだろう? arp, ifconfig, iwconfig, nameif, netstat, route を兼ねる仕組みになっており、Manjaro Linuxではこれらのコマンドは標準では入っていない。 digやnslookupも含まれておらず、getentを使用する。

【注意】 Arch/Manjaro 最新 open-iscsi パッケージにバグ

Arch / Manjaro Linux の最新 open-iscsi パッケージをインストールすると、 libopeniscsiusr.so.0.1.0 というライブラリが欠如しているためにiSCSIが動作しなくなる。

システム構成の中核部に採用している場合はシステムが利用できなくなるため要注意。

有志がAURのgitバージョンからビルドした2.0.876-2をアップロードしており、このパッケージはManjaroでもそのまま動作する。