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のアイコンが出るようになる。

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でもそのまま動作する。

ArchLinux * Nginx * php-fpm * MariaDB * WordPress

慣れている人にとっては常識レベルなのだろうけれど、つまずきどころ満載だったので、メモ。

Nginxのインストール

# pacman -S nginx

PHP / php-fpmのインストール

# pacman -S php-fpm

MariaDBのインストール

“MySQL”と認識している人も多いだろうけれども、 現在は圧倒的にMySQLよりMariaDBが一般的である。

MySQL自体は継続しているが、MySQLを提供しているディストリビューションは非常に少なく、 そもそもアプリケーションが想定しているデータベースもMySQLよりMariaDBのほうが一般的だ。

MariaDBはMySQL5.5から派生したコミュニティベースのデータベースである。

# pacman -S mariadb

有効化する前に 初期設定を行う。

# mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql

そしてセキュアな設定を行う。 (省略しても構わない)

# mysql_secure_installation

リモートホストからのアクセスを拒絶しておく。 /etc/mysql/my.cnfskip-networkingをアンコメントすればOK。この状態でもローカルホストからは接続できる。

これでMariaDBを起動・有効化できる。

PHPの設定

PHPのモジュールが無効になっているので有効にしておく。 これがなければデータベースに接続できず、500 Internal Server Errorになる。

/etc/php/php.iniを編集する。bz2, mysqli, pdo_mysqlを有効にする必要がある。

これをしていないとWordPressの初期設定でデータベース設定後に500エラーになることになり困惑することになる。

これでphp-fpmを起動・有効化できる。

Nginxの設定

まずはサーバー設定を書いておく。 設定を書かない場合、WordPressにアクセス自体できない。

どこに何を書くかという解説はしない(Nginxについて説明をはじめると長い)ので、それを理解しているという前提で進める。 もしろん、コピペでなく値は合わせること。

最低限だとこんな感じ。

server {
  listen 80;
  listen [::]:80;
  server_name blog.example.com;
  root /srv/http/blog/example.com;

  access_log /var/log/nginx/blog-example.log;

          location / {
               index  index.html index.htm index.php;
          }
          location ~ \.php$ {
               fastcgi_index  index.php;
               include        fastcgi.conf;
          }

}

公式の設定から引用するとこんな感じ。

server {
  listen 80;
  listen [::]:80;
  server_name blog.example.com;
  root /srv/http/blog/example.com;


  location / {
    try_files $uri $uri/ /index.php?$args;
  }

  rewrite /wp-admin$ $scheme://$host$uri/ permanent;

  location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires 24h;
    log_not_found off;
  }

  location ~ \.php$ {
    try_files $uri =404;
    
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#   fastcgi_intercept_errors on;
    fastcgi_pass php;
  }

}

公式の場合サイト別ではなく上流で次のような設定も必要になる。

upstream php {
  server unix:/run/php-fpm/php-fpm.sock;
}

php-fpmのソケットファイルが間違っている場合、502 Bad Gatewayになる。

WordPressのインストール

「公式パッケージはあるけどWordPress公式からインストールしたほうがいいよ」というのがArchの姿勢。

$ cd /srv/http
$ wget https://wordpress.org/latest.tar.gz
$ tar xvzf latest.tar.gz
$ sudo chown -R http:http wordpress
$ mv wordpress blog/example.com

パーミッションが間違っていると403 Forbiddenになる。 これは主に所有者で、Nginxプロセスの所有にする必要がある。 現在のArch LinuxではNginxプロセスはhttp:httpで動作する。

起動と有効化

# systemctl start nginx
# systemctl enable nginx
# systemctl start mariadb
# systemctl enable mariadb
# systemctl start php-fpm
# systemctl enable php-fpm

php-fpmが起動されていない場合は502 Bad Gateway、MariaDBが起動されていない場合は500 Internal Server Errorになる。

別のWordPressから移行する

WordPressのファイル側にもファイルがあるらしい(どうも画像データはこっちらしい)ので、MySQLのエクスポートと同時にファイルもとっておく必要がある。

取得したファイルはWordPressインストールの代わりに展開し、パーミッション(所有者)を変更する。 パーミッションの変更は忘れがち。

SiteGuardでログインアドレスを変更している場合は、この機能がApacheに依存しているためログインできなくなってしまうので、wp_content/plugins/site-guardを削除しておく。あるいは、エクスポート前にこの機能を無効にしておいてもいい。 ログインページをNginx上で変更したい場合は他のプラグインを仕様する必要がある。私の場合は“Login Rebuilder”を利用した。

従来が第三者サービスなどによって提供されていたWordPressで、データベース名やユーザー名が好ましくない場合、あるいは複数サイトをインストールするために指定したい場合はwp_config.phpも編集。

データベースをインポートする前にデータベースを用意しておく。

# mysql
> create database <database_name>
> create user '<username>'@'localhost'
> grant all privileges on <database_name>.* to '<username>'@'localhost' identified by '<password>'
> quit

そしてインポート

# mysql <database_name> < wordpress_database_file.sql

そんなわけでブログ引っ越し完了

ブログはXdomainの付属サービスから自サーバーに移動した。

これによりパフォーマンスが改善し、またスマートフォンでの閲覧において広告がでなくなった。

パフォーマンスは最善ではない。これはこのサーバーでWordPressだけが動いているわけではないため、リソースをWordPressに大量に割くことができないからだ。 必要ならば将来的にWordPressを独立したサーバーにしてパフォーマンスを向上させたり(Kasanagi導入が妥当だろう)、リソースを増強してパフォーマンスチューニングを行うかもしれない。

現状ではこのChienomiのほうのデイリーPVは1500から6000程度である。 特に広告などを出して収益があるわけでもないので、今のところあまり考えていない。 そうね、ヒューマンユニークがデイリー1500を越えるか、月間1000円以上の広告収入が発生するようなことがあれば考えようかな。

いずれ広告を出す可能性があるにせよ、それはChienomi側で選定しコントロールした話であり、プロバイダー広告が出るのは(広告を出さないというポリシーに基づく)ユーザービリティ的にもパフォーマンス的にもデメリットしかないので、Chienomiがそれなりにアクセスがあることを踏まえて対応した。

AURにfcitx-mozc-neologd-utを上げました

fcitx-mozc-neologd-ut/mozc-neologd-utをメンテナンスされていた方がut2に移行したため、 これらのパッケージがAURからなくなっていた。

そこで、私がAURにputしておいた

これらに関してはupstreamの作者の方(utuhiro氏)がAnterogos使いであるため、 PKGBUILDが標準で用意されている。 私がアップロードしたものはこれを調整したものとなっている。

行った調整は主に次のようなものだ。

  • メンテナの表示を私に
  • pkgnamefcitx-mozc-neologd-utを先に
  • 本体アーカイブをインターネットから取得するように
  • 本体アーカイブのチェックサムの追加
  • makedependsqt5-baseを追加(mozcが要求する)

手法はおおよそ先人に近いもの(fc2 blog))だが、次のような点が違う

  • ダウンロードはupstreamから行っている
  • makedependsなどの調整を行った