なにこれ?

公式の Production Guide は Ubuntu Server 16.04LTS を前提に書かれているので

18.04LTS の際の差分をメモしておく

Mastodon Production Guide

https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md

で、違いは?

実は一つだけ。

1
`apt -y install imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev file git-core g++ libprotobuf-dev protobuf-compiler pkg-config nodejs gcc autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev nginx redis-server redis-tools postgresql postgresql-contrib letsencrypt yarn libidn11-dev libicu-dev

の中にある、 libgdbm3 が Ubuntu 18.04LTS にはありません。 libgdbm5 がありますが、標準でインストール済みなので

特にインストールする必要はありませんでした。

これ以外は、全て Production Guide の手順通りでインストールできました。

環境

  • 元サーバー:非 Docker で稼働中の Mastodon サーバー
  • 新サーバー:Docker 及び docker-compose インストール済みのサーバー
  • 作業 PC:作業を行う PC です。SSH と SCP があるとよいです。

移行の大枠

考え方としては、DB と .env.production ファイルを移行すれば OK。

ただし、Redis のデータを移行しないと Sidekiq のジョブのカウントが 0 に戻って少し悲しい。

移行手順

(元サーバー)から .env.production を取得する

そのままなので詳細は割愛。新サーバーにコピーしておく。

(新サーバー)docker-compose.yml の準備

https://github.com/tootsuite/mastodon/blob/master/docker-compose.yml を取得して、変更を加える

この変更は docker-compose up を行う前に実施する(postgres の初回起動時に初期化が行われるため)

docker-compose.ymlの抜粋

1
2
3
4
5
6
7
8
9
10
11
db:
restart: always
image: postgres:11 # 9だったが11にした
networks:
- internal_network
environment: # この部分追加
POSTGRES_USER: root # 元サーバーと合わせると楽
POSTGRES_PASSWORD: rootpwd # パスワードは変えて下さい
POSTGRES_INITDB_ARGS: "--encoding=UTF-8"
healthcheck:
test: ["CMD", "pg_isready", "-U", "root"] # postgresになっているので修正

(新サーバー) .env.production の修正

DB サーバー、REDIS サーバーの接続先が変更になるので修正する。

.env.production

1
2
3
4
5
6
7
8
REDIS_HOST=redis     # docker-compose上の名前が解決できるのでこれでOK
REDIS_PORT=6379

DB_HOST=db # docker-compose上の名前が解決できるのでこれでOK
DB_USER=root # 上で設定した内容に合わせる
DB_PASS=rootpwd # 上で設定した内容に合わせる
DB_NAME=mastodon_db # あとで作成するDB名に合わせる
DB_PORT=5432

redis

データ移行を行わなくても問題ないが、行うのであれば、元サーバーを停止した状態で

redis のデータファイルをコピーすれば OK。

PostgreSQL

これが一番移行が面倒。新サーバーで docker-compose up -d を実行して一度全て起動させる。

  • (元サーバー)サービスを停止する。

データロスがちょっとあっても良いのであれば止めなくても問題はない(と思われる)

  • (元サーバー) DB バックアップの取得

元サーバーで、以下を実行。(DB が別サーバーであれば、 -h 等を追加して下さい)

pg_dump --dbname=<元のDB名> > mastodon.sql

  • (作業 PC)バックアップを docker コンテナに転送する

一番簡単なのは、PostgreSQL コンテナのデータ領域にファイルを投げ込んでしまうこと

特に変更していなければ、docker-compose.ymlがあるディレクトリ/postgres に SQL ファイルをコピーすればよい

  • (新サーバー)データベース等の作成
1
2
3
4
`docker-compose exec db bash
# psql
root=# create database mastodon_db;
root=# \q
  • (新サーバー)(オプション) ダンプファイルの修正

元サーバーでの DB ユーザー名が新サーバーと異なる場合、ダンプファイルを修正する。

1
2
`# cd /var/lib/postgresql/data
# cat mastodon.sql | sed s/元サーバーでのユーザー名/新サーバーのユーザー名/ > mast.sql
  • (新サーバー)ダンプの取込
1
2
3
4
`# cd /var/lib/postgresql/data
root=# \c mastodon_db
mastodon_db=# \i mast.sql
(インポートの表示が大量にでる)

Web / streaming / Sidekiq

これらは特にデータを持たないので特段の対応は不要。

終わり

ここまで来たら、正常に動くはずです。おつかれさまでした。

ディスク容量節約のために、転送したバックアップファイルを削除するとよいでしょう。

蛇足 1 docker ps すると unhealthy と表示される件

ちなみに web と streaming の healthcheck の wget のパラメタが

--proxy off (proxy と off の間がスペース) の場合、 --proxy=off にしないと、docker ps した際に

status: unhealthy となってしまう。(v2.8.0 以降であれば修正済み)

https://github.com/tootsuite/mastodon/pull/10553/files

1
2
3
healthcheck:
test: ["CMD-SHELL", "wget -q --spider --header 'x-forwarded-proto: https' --proxy=off localhost:3000/api/v1/instance || exit 1"]

蛇足 2 SideKiq のスレッド数の変更

docker-compose.yml の command 行を変更すれば可能。

1
2
3
environment:
DB_POOL: 20 # DBコネクションプール
command: bundle exec sidekiq -c 20 # -c 20 で20スレッド

蛇足 3 PostgreSQL のパラメタ変更

公式イメージを使用しているのでパラメタの変更には conf の上書きが… 不要です!

1
2
3
4
5
6
$ docker-compose exec db psql

root=# ALTER SYSTEM SET shared_buffers = "384MB";
ALTER SYSTEM
root=# ALTER SYSTEM SET max_connections = 100;
ALTER SYSTEM

pgtune を使用すると ALTER SYSTEM の形で適切と思われるパラメタを表示してくれます。

なお、ALTER SYSTEM を行うと、 postgresql.auto.conf ファイルに設定内容が書き込まれて、永続化されます。

https://www.postgresql.jp/document/11/html/sql-altersystem.html

PostgreSQL の起動中に変更ができないパラメタは、次回起動時から有効になります。
PostgreSQL を再起動するまでは、PgHero の表示は前の値のままですのでご注意下さい。

まえがき

docker-compose down を実行した際にデフォルトでは SIGTERM が送信され、

10 秒以内にプロセスが終了しないと、 SIGKILL を送信するようになっている。

大抵のコンテナは 10 秒以内に終了できるが、DBMS 等のシャットダウンが必要なコンテナは

タイムアウトが発生して SIGKILL されてしまう可能性がある。

そこで、このタイムアウトを変更する方法をメモしておく

docker-compose.yml での指定

docker-compose.yml に stop_grace_period を追加する。

https://docs.docker.com/compose/compose-file/#stop_grace_period

1
2
3
4
5
6
version: '3'
services:
db:
restart: always
image: postgres:11
stop_grace_period: 1m # ここ!

さいしょに

本記事はただの学習記録です。

環境

  • Ubuntu 18.04.1 LTS
  • node.js v10.14.1

失敗編

この記事の内容を実行してみたかっただけ

https://qiita.com/SatoTakumi/items/c9de7ff27e5b70508066

必要なライブラリ

1
`sudo apt install libavahi-compat-libdnssd-dev

蛇足

もし、 apt install がエラーになった場合は、 /etc/apt/source.list が以下のようになっているか確認して下さい。

標準では、 main だけになっているはずです。

1
2
3
`deb http://archive.ubuntu.com/ubuntu bionic main universe multiverse
deb http://archive.ubuntu.com/ubuntu bionic-security main universe multiverse
deb http://archive.ubuntu.com/ubuntu bionic-updates main universe multiverse

コードを実行してみると・・・ 動かない(その 1)

Error: get key failed from google

API の返り値が変わってしまった為に、google-tts-api ライブラリがエラーを吐いている模様。

原因は以下の Qiita に詳しく書いてありました。

https://qiita.com/ezmscrap/items/24b3a9a8548da0ab9ff5

google-tts-api の新しいバージョンでは対応済みのようなので、 package.json の以下の行を書き換えてバージョンアップさせます。

1
2
3
4
`# 20行目付近
"google-tts-api": "0.0.2",

"google-tts-api": "0.0.4",

コードを実行してみると・・・ 動かない(その 2)

Web ブラウザから、 http://<host>:8091/google-home-notifier?text=Hello+Google+Home

を実行してみると、(大量の WARNING はとりあえず無視して)

1
`Error: connect ECONNREFUSED 192.168.1.20:8009

これは割と単純で、Google Home の IP アドレスが分かっていない時に起きる。

example.js の先頭に var ip = '192.168.1.20'; // default IP というところがあるので

それを書き換える。

なお、Google Home の IP アドレスは、Google Home アプリの設定画面の一番下に表示されている。

これを直せばとりあえず動くはず。

蛇足:

すぐ上に Google Home のデバイス名が設定されているが、これは間違っていても IP アドレスが正しければ動く。

(とりあえず初版)

IP アドレスが固定なのはさすがに酷い

対応その 1

そもそも、README に書いてある通りの事をやっていなかった。

https://github.com/noelportugal/google-home-notifier#after-npm-install

・・・やっても効果はなく、しかも npm で入れたものに対して修正かけるのは反則なのでは・・・

原理から考えてみる

Google Home アプリは普通に自動的に Google Home を発見できるので、何かのプロトコルで探索できるはず。

というか、普通に example.js が mDNS を呼んでいるのでこれで見つかるはず。

でも、先にググってみたら既に Qiita にお書きになってる人がいらっしゃいました。

https://qiita.com/tinoue@github/items/ecb8b6211bee686a75e8

要するに、example.js の devicename に書く値が・・・というよりもう探索の仕方が(今となっては)正しくない。

example.js のコードでは、現状実質 IP アドレスベースで動かすしかない。

コード書いてみる

https://github.com/yakumo-saki/google-home-notify-simple

ご注意

  • Azure Blob Storage は S3 互換ではありません
  • Multipart-upload には対応できません。(要するに Mastodon には使えません)

はじめに

移行の動機は以下の通り

  • Mastodon の運用に使っている Minio(自鯖)が存在しているがクラウドに出したくなった
  • 普通に考えると Wasabi あたりに移行するところだが、Azure の無料枠があったので Azure Blob Storage をバックエンドにしたかった

設計

  • Azule Blob Storage は S3 API でアクセスできないので、ゲートウェイを設置する必要がある。
  • Minio を Azure gateway モードで動かすことで実現できる。

事前作業

minio のセットアップ

https://az.minio.io/ に従うと、Azure 上に VM を立てて、その上で Minio を動かす手順になっていますが、

そんなことをしたら課金額が大変な事になってしまうので、VPS で動かすことにします。

https://docs.min.io/docs/minio-gateway-for-azure.html こちらの手順では Docker を使っていますが、

Minio はそもそもバイナリ 1 個なので docker にする必要もないので、直接いれることにします。

・バイナリをダウンロード ( wget https://dl.min.io/server/minio/release/linux-amd64/minio )

・実行権限付与 ( chmod +x minio )

Azure Blob Container 側の設定

ポータルから実施した。
IAM でストレージ管理者権限をつけておくこと
ストレージの作成と、コンテナの作成はポータルが十分にわかりやすいので省略。

移行作業

minio を停止

バックアップ中にファイルが増えるとそのファイルを転送するのが困難なので停止。

Minio 自体を止めるとバックアップできないのでここは悩みどころ。外部からのアクセスは停止しつつ、

内部 IP にたいしてバックアップするようにして回避したが、よく考えれば書込アクセスを停止すればよいので、

HTTP PUT,POST,PATCH,UPDATE あたりを拒否すればよかったのではないかとも思う。

バックアップ

mc mirror を使った (mc = minio client)

Azure に転送

転送方法は複数考えられる。

Azure Blob Storage が S3 互換のストレージからのデータコピーが可能なのでそれを使う(今回未使用)

Microsoft Azure Storage Explorer を使う https://azure.microsoft.com/ja-jp/features/storage-explorer/

AzCopy を使う

今回は Azure Storage Explorer を使用した。

ここでの注意点は、兎にも角にも、azcopy を裏で使うツールを使うこと。Azure Storage Explorer を使用すると GUI で

操作できて楽だが、必ずメニューの Preview -> Use Azcopy for improved upload and download にチェックを入れること

(起動時に、黄色いバーで有効にするか聞いてくるのでそこで Enable ボタン を押しても可能)

Mastodon 設定変更

(本筋と関係ない手順です)

env.productionで、AWS_ACCESS_KEY_ID =ストレージ名、AWS_SECRET_ACCESS_KEY =キー をセットする。

Minio 再開

転送完了後、minio を再開する。

アクセスポリシー設定

minio client をダウンロードしておく

1
2
3
4
5
# azuregw は自分の好きな名前で良い
mc config host add azuregw http://[server] storage名 キー

# azure blob storageを使う場合、download以外の値を指定すると Not implementedになる
mc policy --recursive download azuregw/コンテナ名/

トラブル事例

権限がつかない

ストレージ管理者権限が IAM についていない場合にこうなりました。

MinIO へのアクセスが minio/ にリダイレクトされる

アクセスポリシーが設定されていないので認証が必要 →minio ブラウザにリダイレクトされる。

やりたいこと

  • MotionEyeOS で撮影しているカメラ画像をストリーミングで再生させたかった。

結論

omxplayer --live --orientation 90 http://10.0.0.111:8084

omxplayer

Raspberry Pi OS lite ではデフォルトでは入っていないので apt install omxplayer でインストール。

–live

これがないと最初の画像を表示してそのままほとんど更新されなくなるので必須。

–orientation 90

90 度倒して表示する。カメラ画像が縦長なのでこうしている。普通の向きであれば不要。

http〜

ストリーミング URL。MotionEyeOS であれば、設定の Stream URL をクリックすると取得できる。まぁ、IPアドレス:8084 なわけですが。

背景

ラズパイ ZERO W の miniHDMI 端子に 7 インチ HDMI ディスプレイ(1024x600)を接続している。
ただし、これは HDMI 出力なので omxplayer が使えるが、そうでない場合は上記の通りになると思われる。

環境

  • FreeNAS 11.2 Stable
  • Hyper-V on Windows Server 2019
1
2
2022/03/11 追記
この手順は TrueNAS Scale には適用できません

目的

VM で FreeNAS を動かしているので、できるだけ再起動なしで増設・サイズ変更を認識させる。

本項では、以下の 3 パターンについて扱う

  • ディスク増設
  • ディスク容量変更(パーティションあり時。Web UI で作った場合はこちら)
  • ディスク容量変更(ディスク全体を使用時。zfs プールをコマンドラインで作成した場合)

ディスク増設

Web 画面の shell から、以下のコマンドを叩くだけ。

これで disk 一覧に追加したディスクが表示される。

なお、ZFS プールを作るのであればディスク全体を使用した方が後々楽です。(蛇足 1 参照)

1
camcontrol rescan all

ディスク容量変更(パーティションありの場合)

FreeNAS の Web UI から作ったプールの場合はこの手順です。

zpool コマンドを直接叩いて、ディスク全体をプールにした場合は別の手順です。しばらく下まで飛ばして下さい。

ディスク容量の変更を OS に認識させる

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# diskinfo -v /dev/da1        # 実行前の容量確認
/dev/da4
512 # sectorsize
55834574848 # mediasize in bytes (52G) # ここ
109051904 # mediasize in sectors
(略)

# camcontrol readcap da4 -h # 容量が変化してるか確認

# camcontrol reprobe da4 # 容量を再認識させる

# diskinfo -v /dev/da4 # 実行後の容量確認


これで、容量が 表示 できる。これで新しい容量が見えるはず。

da4 の部分は、 /dev/da4 の/dev/を省略したもの。

1
camcontrol reprobe da4

zfs パーティションのサイズ変更

必要であれば、zfs pool のサイズを変更します。 というより普通に Web からやっていれば必須です。

1
2
3
4
5
# 容量確認
# zpool list

NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
minio 47.5G 556K 47.5G - - 0% 0% 1.00x ONLINE /mnt

FreeNAS で zfs pool を作ると、パーティションを切って作っているようなので、パーティションサイズを拡張します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# gpart show da4

=> 40 109051824 da4 GPT (52G)
40 88 - free - (44K)
128 4194304 1 freebsd-swap (2.0G)
4194432 100663128 2 freebsd-zfs (48G)
104857560 4194304 - free - (2.0G) # この空き容量が増設分

もし、ここで、 [CORRUPT] の表示があった場合は

# gpart repair da4

# gpart resize -i 2 da4 # -i の 2は、パーティション番号。 gpart show の時の数字です。
da4p2 resized

# gpart show da4
=> 40 109051824 da4 GPT (52G)
40 88 - free - (44K)
128 4194304 1 freebsd-swap (2.0G)
4194432 104857432 2 freebsd-zfs (50G) # 48G -> 50Gになった
# free の部分がなくなった #

ZFS に容量変更を認識させる

先に書いておきますが、ここで容量が変更されても、Web 画面には反映されません。

どうやったら反映されるんでしょう。。実用上は問題ないはずですが、監視系に問題が起きるかもしれません。

追記: TrueNAS 12.0U6 ではWeb画面にも反映されるようになったようです。(手元の環境で確認)

zpool online する

この方法では、マウント解除は発生しません。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# zpool status minio
pool: minio
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
minio ONLINE 0 0 0
gptid/db00a183-f2d5-11e9-82df-00155d001e61 ONLINE 0 0 0

該当するディスクのgptid/xxxxxxx の前に、 /dev/ を追加して実行します。
daNpM 形式の場合も同じです。

# zpool online -e minio /dev/gptid/db00a183-f2d5-11e9-82df-00155d001e61

# zpool list minio
Freeが増えたことを確認

ここで容量が増えればそれで完了です。

(ダメな場合のみ) import/export する方法

注意: 一時的に ZFS pool がマウント解除されます。

1
2
3
4
# zpool set autoexpand=on minio
# zpool export minio
(ここでpoolがマウント解除される)
# zpool import minio

(念のため) マウントポイント確認

export/import した場合に限るかわかりませんが、マウントポイントが変更されてしまい共有として指定できなくなりました。

念のために確認します。

1
2
3
4
5
6
7
8
# zfs get mountpoint minio
NAME PROPERTY VALUE SOURCE
minio mountpoint /minio default

【NG】 /mnt/minio でなければWebから共有に指定できない

# zfs set mountpoint=/mnt/minio minio
=> 即時反映される

ディスク容量変更(パーティションなしの場合)

自力で zpool コマンドを叩いて、ディスク全体を使用した場合の手順です。

ディスク容量の変化を認識させる

1
2
3
4
5
6
7
8
9
# zpool list
(元の容量を確認)

# camcontrol rescan all
# zpool online -e <poolname> <devicename>
例) zpool online -e s3 /dev/da5

# zpool list
(容量が変化したことをを確認)

蛇足 1

FreeNAS の GUI から新しいディスクを追加して、pool を作成すると必ず Swap が 2GB ほど取られてしまうので、

十分な Swap or メモリが確保できているのであれば、Shell から自分で zpool コマンドを使って pool を作った方が

無駄がなくて良い。 手動で pool を作る → export →Web UI から import で OK。

ディスク全体を割り当てれば、コマンド 3 つでサイズ変更に対応できるので楽である。(swap 領域、使わないなら無駄になるし)

蛇足 2

調査したけど使わなかったコマンドです。

reopen

1
2
3
4
5
# zpool status minio
# zpool set autoexpand=on minio
# zpool reopen minio

=> 効果なし

GPT パーティションにラベルを付ける

1
2
3
4
5
6
7
8
9
# gpart modify -i 2 -l minio_ssd1 da4
da4p2 modified

# gpart show -l da4 # da4 は省略してもよい。全部表示される

=> 40 109051824 da4 GPT (52G)
40 88 - free - (44K)
128 4194304 1 (null) (2.0G)
4194432 104857432 2 minio_ssd1 (50G) # ラベルがついた

蛇足の蛇足

このエラーが解決できずにハマりました。表示上/dev/ が省略されているので、

コマンドの引数でも省略可能だと思い込んでいた。というオチでした。

1
2
# zpool online -e minio gptid/183-f2d5-11e9-82df-00155d001e61
cannot expand gptid/183-f2d5-11e9-82df-00155d001e61: no such device in pool

捕捉

Proxmox VE 7.0 + TrueNAS 12.0U6 の環境では、VirtIOのディスクを拡張子した際に dmesg に以下の出力がされてリサイズがされたかのように思えるが、これはディスク全体のサイズが変わった。と言ってるだけのようで、パーティションは拡大されていない。

1
2
GEOM_PART: ada1 was automatically resized.
Use `gpart commit ada1` to save changes or `gpart undo ada1` to revert them.

環境

Ruby 2.2 (Windows x64)

Bundler 1.12.5

前提

  • 本番環境のサーバーはインターネット接続不可
  • 開発用に使ってる PC はインターネット接続可

手順

開発機で、使用する gem を全てダウンロードさせる。

1
2
3
4
5
6
7
8
9
## 開発機上で実行する

> cd railsアプリケーションのパス

rem とりあえず普通にbundle install
bundle install

rem これで、 vendor/cache に使用するgemファイルが全部キャッシュされる
bundle package --all

開発機上の vendor/cache 内のファイルを何らかの方法で、サーバー上の vendor/cache にコピーする

#ここが一番問題という説もある。USB メモリ使うなり、共有サーバー使うなりでなんとかする

1
2
3
4
<code class="language-bat:サーバー上で実行する">cd railsアプリケーションのパス

rem --pathは普通不要な気がするが念のため
bundle install --path vendor/bundle --local

これで、サーバー機がインターネットに接続されていなくても Rails アプリを起動できるはず。

その他

bundle install 中の、Native Extension のコンパイルが cygwin のエラーでコケた場合は

とりあえず、Windows を再起動してもう一度やってみるとうまく行く事が多い。

1
make.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0

雑記

Windows 上で bundle install をオンラインでやろうとすると cacert.pem がどうしたとか

色々と面倒な部分があるのでデプロイはこれで良いんじゃないかという気がする。

gem をダウンロードしてこない分、高速にデプロイできるというメリットもある。

参考にした URL

Bundler めも

https://gist.github.com/kozy4324/5719555

bundle package で gem をアプリケーションに含める
http://qiita.com/ryo0301/items/e6c8dad0e8d66ab33ab7

Windows 上の Ruby で SSL 接続時に certificate verify failed が出る場合の対処http://qiita.com/whiteleaf7@github/items/4504b208ad2eec1f9357

前書き

  • Linux はサーバーとしては使っている
  • Linux を VM としては入れているが、物理 PC に入れるのはほぼ初めて
  • CPU は Intel Core i5 6500 / GPU 等追加なし
  • ディストリは Linux Mint 20

何を書くのか

  • インストール直後に確認すべき項目を列挙する
  • 設定値メモ
  • ソフトウェア類は別記事 /entries/MYb57TjGERPde4B8

確認(設定項目)

インストール前に、そもそも Windows でいうところのスタートメニューの形が気に入らないとか

その辺を Live USB で確認する。GUI のルックアンドフィールが気に入らないのはまだ何とかなるが

基本的な好みが合わないのはどうにもならない気がする。

Ubuntu, Kubuntu, Linux Mint, MX Linux, Elementary OS あたりは試してもよさそう。

debian (Ubuntu) ベースか、RHEL(CentOS, Fedora)ベースだとアプリケーションのパッケージが

用意されているので楽かもしれない。

ディスプレイ設定

ここが一番トラブる。

  • 4K 等の HiDPI のディスプレイを使用している場合に顕著。
  • Linux の GUI 環境では(2020/06 時点)、ディスプレイ毎のスケーリングというものはなく、システム全体のスケーリングしかない。
  • 要するに 4K ディスプレイ(高解像度なノート PC のディスプレイも)と普通の FullHD のディスプレイを繋ぐいで、4K 側に合わせると、FullHD なディスプレイにはめちゃくちゃデカい UI が表示される事になる。
  • と言うのが原則。なんとかする方法は下記。
  • HiDPI という設定とは別に、分数スケーリング という設定があり、これはディスプレイごとに設定可能。
  • この設定で、フル HD ディスプレイ側を 100% に設定することで、サイズ調整が可能。
  • 少なくともこれを書いた 2020/07/03 時点では、GUI から設定すると分数スケーリングしたモニタの表示品質がひどいことになる。下の xrandr を使った方法だとうまく行くので、それで回避できる。

コマンドラインでの設定

~~

これは古い手順。

GUI から設定できない。というのが間違っていて、普通に GUI から設定できた。(上記分数スケーリングの話)

おそらく、設定内容は xrandr コマンドを使うのと同じなのだけれども、標準の作法に則っておけば

スリープ後でもちゃんと反映されるので、理由がないのであれば GUI で設定することをおすすめする。

~~

他のディストリビューションではできないものもあったので、残しておく。

うちでの設定は、以下。メインの 4K ディスプレイの左にサブのフル HD ディスプレイがある。という構成。

GUI で HiDPI に設定している。(これだけだとフル HD のモニタの表示が2倍x2倍サイズになっている)

このままではフル HD のモニタが使い物にならないので、追加で設定をする。

この構成は、GUI から設定できないのでターミナルから以下のコマンドで設定した。

1
xrandr --fb 7680x2160 --output DP-1 --pos 3840x0 --panning 3840x0+3840+0 --output HDMI-2 --pos 0x0 --scale 2x2

考え方は、

  • xrandr をパラメタなしで実行すると今の設定が表示される。
  • fb で全部のディスプレイをつなげた解像度を特定。フル HD のモニタも4 K とみなして計算する。
  • 今回は横に並べた形なので、横 3840 が2枚で 7680、縦は普通に 2160 をそのまま
  • --output から次の –output の前までが1モニタの設定。
  • 最初に書いたモニタがプライマリ扱い。
  • HDMI-2 はフル HD モニタがつながっている。 左側にあるので pos 0x0
  • scale 2x2 で HiDPI で表示されているものを縮小して表示するようにする
  • DP-1 は 4K モニタの設定。左側にフル HD モニタがあるので、その分 --pos--panningで右側を表示させる。
xrandr 設定の自動適用

システム設定 → 自動起動させるアプリケーション を開いて

  • 一番上にある Cinnamon Settings Daemon - xrandr を無効にする
  • +ボタンを押して、xrandr コマンドを追加する
  • ただし、これをやると外部モニタを接続した場合等に問題が起きるらしいので、最初のやつは無効にしないで、実行遅延時間を1秒とかにして、xrandr を実行したほうが良いかもしれない。

マウスカーソル

マウスカーソルは、 https://www.gnome-look.org/ 等からダウンロードできる。

zip 形式でダウンロードできるので ~/.icons に展開して、システム設定 → テーマ で設定可能。

  • HiDPI 環境で特に顕著だけれども、マウスカーソルが小さくなる。
  • Mint ならマウスの設定でマウスカーソルのサイズを変えられるが、大抵の場合、効かない。(DMZ-White (初期設定なのに!), DMZ-Black は効かない。Adwaita は効く。)

mozc 周り

表示が小さすぎるのをなおす

HiDPI にすると mozc の候補ウィンドウの文字がとても小さい。

これは、タスクトレイにあるかな漢字インジケータの右クリック → 現在の入力メソッドの設定

外観 タブ内のフォントサイズをとりあえず 26 に変更。これで変換候補の文字が大きくなって見やすくなる。

キーバインド

個人的な好みで、mac と同じように、変換/無変換でかな漢字変換の ON/OFF をしたいので、

タスクトレイにあるかな漢字インジケータの右クリック → 現在の入力メソッドの設定

全体の設定 タブの Show advanced option にチェックを入れて、

入力メソッドをオンに を 変換(Henkan)、入力メソッドをオフに を 無変換(Muhenkan) に設定する。

これで ON・OFF 切り替えはできるようになるが、mozc のキーバインドの変換、無変換に割り当てられている

ショートカットをすべて削除しておかないと、変換モードが唐突に直接入力になってしまったりするので

mozc の設定で、無変換・変換キーに割り当てられているショートカットをすべて削除する。

テーマ類

ウィンドウ枠等の色とか、見た目とか。ただの好み。

システム設定 → テーマ から設定可能。

テーマ

McOS_MJV_Cinnamon_2.0

https://github.com/paullinuxthemer/McOS-Mint-Cinnamon-Edition

テーマは ~/.themes に展開して入れれば選択可能になる

Mint-Y-Dark-BB

https://github.com/smurphos/Window_Borders_Mint_19/

このテーマを入れると入る。標準のテーマのボタンを大きくしただけ。

アイコン

Numix

sudo add-apt-repository ppa:numix/ppa -y &amp;&amp; sudo apt update &amp;&amp; sudo apt install -y numix-icon-theme-circle

テーマは ~/.icons に展開して入れれば選択可能になる

コントロール部分

Mint-Y-Darker-Red 標準で入っている

マウスポインター

adwaita 標準で入っている

デスクトップ

Silk、追加と削除からインストール可能

アプレット

  • System monitor を追加。(Graphical Hardware monitor ではない)

グラフィックドライバの変更

注意:これをやってもそれほど高速化するわけではない。(チラツキだけは治ったが…)

念の為、これをやる前に UEFI/BIOS の設定で、内蔵ビデオ用のメモリ割り当てが 32MB になってたら

もっと増やしてテストすることをおすすめする。

なお、私は上記をやらずに、Quadro K620 (ヤフオク価格 4000 円)を買ってしまったので

これ以上はわからない。

Skylake、Kabylake は標準のグラフィックドライバだと性能がイマイチなのと、マウスカーソルの点滅

がどうしても気になったのでドライバを古いものに変更した。

https://qiita.com/haruakio/items/8baca591c3d913eafca7

要約:

/usr/share/X11/xorg.conf.d/20-intel.conf に以下の内容のファイルを作る

1
2
3
4
5
6
7
`Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "sna"
Option "TearFree" "true"
Option "DRI" "3"
EndSection

なお、この変更を行うと、 xrandr コマンドに指定する出力ポート名が DP-1 から DP1 というように

ハイフンなしの名前に変更されるので注意。 xrandrに関してはそこだけ変更すれば OK。

なお、ログイン画面は盛大に表示が乱れるが、ログインしてしまえば問題ないので見なかったことにした。

カーネル

デスクトップ向けに調整されたカーネル。

メモリの使い方がかなり変わる印象。 Buffer があまり使われなくなって、Cache に回る感じ。

XanMod

https://xanmod.org/

Liquorix Kernel

https://liquorix.net/

前提

  • はんだ付けしません(ビニールテープは使います)
  • 抵抗とかでてきません
  • 一番高いパーツは Raspberry Pi です

動機

我が家のサーバーがなんとなく不調で、不定期にフリーズする。

# まずそれをなんとかしろという話もあるけれども

しかも、カーネルパニックでもないようで、フリーズした時は一切の表示がなくなってしまう。

これでは大事な録画に失敗しかねないと言う事で遠隔からリブートを可能にする為の機器を作ることにした。

# ちゃんとしたサーバー買ってくれば、BMC とか IPMI とかがあるのでこんなことしなくても良いんですけどね

材料

Amazon へのリンクを張っておきますが、ご参考程度です。これじゃないとダメではないです。

  • 特に、ジャンパーワイヤはそれっぽければ何でもよいと思います。

Raspberry Pi を除けば、1000 円でお釣りが来る感じです。

(ただし、中国発送なので到着までそれなりに時間かかります)

Amazon で調べてみると、ジャンパーワイヤはメスメス・オスオス・オスメスのセット品もあるみたいです。

その他:

  • ダイソー 小物入れ(ケース扱いなのでなくても良い)
  • テスター(お安いので十分)
  • ケースを加工する道具類(ピンバイス・やすり等)

作り方

リレーモジュールには、リレーが二つ付いていますが、一つしか使いません。

以下の物理ピン番号は、同一機能の別のピンを使用しても問題ない  です。

接続はとても簡単な、メスーメス ジャンパーワイヤを使用して繋いでいます。

  • モジュールの JD-VCC と VCC を繋いでいるジャンパをハズします。
  • Pi の 5V ピン(物理ピン番号 2) => モジュールの JD-VCC に接続
  • Pi の 3V ピン(物理ピン番号 1) => モジュールの VCC(JD-VCC の隣の方) に接続
  • Pi の GPIO ピン(物理ピン番号 12) => モジュールの IN1 に接続
  • Pi の GND(物理ピン番号 14) => モジュールの GND(IN1 の隣にある方)に接続
  • 動作確認する
  • モジュールの COM1 => PC のマザーボードの電源ピン(+-どちらでも OK)
  • モジュールの NO1 => PC のマザーボードの電源ピン(残った方)

モジュールから電源ピンへの接続は

モジュールオス-オスメス-メス と繋ぐことで半田付けを回避できます。

メスメスの片方を切り落として、皮膜を剥けばオスオスを使う必要はないのですが。

動作確認

Raspberry Pi 上から、以下のようにコマンドを叩きます。

1
2
3
4
5
6
7
8
9
10
11
<code class="language-bash">GPIO_NO=17    # ピン番号について。を参照
echo ${GPIO_NO} > /sys/class/gpio/export
sleep 0.05
echo out > /sys/class/gpio/gpio${GPIO_NO}/direction
# ここでリレーモジュールのランプが付くはず。
# ランプがついている状態は、 COM1-NO1 間が繋がった状態になる。
# 逆に言うと、ランプが消えている状態(通常状態)では COM1-NC1 間が繋がっている
# 気になるならテスターで要チェックです。

# これでリレーモジュールのランプが消える。
echo ${GPIO_NO} > /sys/class/gpio/unexport

実稼働

とりあえず SSH で

とりあえず、Raspberry Pi に SSH でログインして、上記をよしなに書き換えたスクリプトを実行することで、

対象の PC の電源 OFF/ON を実行できます。

スクリプトは、こちらで公開しています。簡単なスクリプトなので解説不要だと思いますが、

引数に short / long を付けて実行すると電源ボタンを普通押し/長押し させることができます。

https://github.com/yakumo-saki/raspberrypi-powerweb/tree/master/scripts

Web アプリにしておきたい

しかし、万が一出先でサーバーがフリーズした場合、スマホから VPN 接続して ssh、コマンドを叩く。というのは

いくら何でも面倒です。と言うことで、これを Web 化しようと考えました。

適当な部分が多いですが公開しています

https://github.com/yakumo-saki/raspberrypi-powerweb

# 本当は、Zabbix で監視しているので自動で復旧させようと思ったのですが、物理的なメンテナンス中に
# 電源入れられたりすると嫌だなぁということであえて手動にしています。

ピン番号について

gpio readall の出力です。Pi 3 と出ているとおり、Raspberry Pi 3 での出力です。

動作確認中で使用する GPIO_NO はこの表の BCM 欄 の値です。

物理ピン番号でも 、GPIO. n の値でもありません。(かなりハマりました)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
` +-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| | | 3.3v | | | 1 || 2 | | | 5v | | |
| 2 | 8 | SDA.1 | IN | 1 | 3 || 4 | | | 5v | | |
| 3 | 9 | SCL.1 | IN | 1 | 5 || 6 | | | 0v | | |
| 4 | 7 | GPIO. 7 | IN | 1 | 7 || 8 | 0 | IN | TxD | 15 | 14 |
| | | 0v | | | 9 || 10 | 1 | IN | RxD | 16 | 15 |
| 17 | 0 | GPIO. 0 | IN | 0 | 11 || 12 | 0 | IN | GPIO. 1 | 1 | 18 |
| 27 | 2 | GPIO. 2 | IN | 0 | 13 || 14 | | | 0v | | |
| 22 | 3 | GPIO. 3 | IN | 0 | 15 || 16 | 0 | IN | GPIO. 4 | 4 | 23 |
| | | 3.3v | | | 17 || 18 | 0 | IN | GPIO. 5 | 5 | 24 |
| 10 | 12 | MOSI | IN | 0 | 19 || 20 | | | 0v | | |
| 9 | 13 | MISO | IN | 0 | 21 || 22 | 0 | IN | GPIO. 6 | 6 | 25 |
| 11 | 14 | SCLK | IN | 0 | 23 || 24 | 1 | IN | CE0 | 10 | 8 |
| | | 0v | | | 25 || 26 | 1 | IN | CE1 | 11 | 7 |
| 0 | 30 | SDA.0 | IN | 1 | 27 || 28 | 1 | IN | SCL.0 | 31 | 1 |
| 5 | 21 | GPIO.21 | IN | 1 | 29 || 30 | | | 0v | | |
| 6 | 22 | GPIO.22 | IN | 1 | 31 || 32 | 0 | IN | GPIO.26 | 26 | 12 |
| 13 | 23 | GPIO.23 | IN | 0 | 33 || 34 | | | 0v | | |
| 19 | 24 | GPIO.24 | IN | 0 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 |
| 26 | 25 | GPIO.25 | IN | 0 | 37 || 38 | 0 | IN | GPIO.28 | 28 | 20 |
| | | 0v | | | 39 || 40 | 0 | IN | GPIO.29 | 29 | 21 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+

蛇足(困ったことなど)

GPIO 準備待ち?

スクリプト上で GPIO ピンを有効にした直後に direction を設定しようとすると、失敗する  ことがあるので、

sleep 0.05 で少しだけ待機する必要があります。内部的な処理が間に合わない  のでしょう。

export 直後、GPIO = LOW になる件

最初は、動作開始時(RaspberryPi 起動時)に、使用する GPIO ピンを export して、後は、値の変更だけで制御しようと考えていました。

しかし、GPIO ピンを export した瞬間に GPIO 出力=LOW(0) となる仕様(?)のようで

そのままいくと、対象の PC が起動中に、RaspberryPi を再起動すると、PC の電源が落ちてしまう羽目になります。

# ピンによっては HIGH で開始されるピンもある。という記述を見かけたのですが、どのピンも

# export した直後は LOW になってしまいました。

仕方ないので、export / unexport を行って制御しています。 unexport された GPIO ピンは、未接続状態に

なるので一切電気は流れない・・・そうです。論理を反転させる回路を組めば、LOW/HIGH を逆転できるのでしょうが、

それをすると、半田ごての出番になってしまうので、ソフトウェア側でなんとかしました。

今後のアップデートが必要なこと

PC 本体の電源ボタンが効かなくなる

残念ながら、PCケースの電源ボタンはどこにも配線されなくなります。これは割と困るので、今後どうにかしたいと思います。電源ボタン分岐ケーブル買ってくれば OK なんですけどね。

http://ponpokotarou.blog.fc2.com/blog-entry-53.html

あ、、、よく考えればこれで十分だった。そのうち記事をアップデートするか追加します。

リモートから電源スイッチを押しても、シャットダウンしたタイミングがわからない

Web アプリから Ping を打って生死確認できるようにしてありますが、Ping 応答しない=電源 OFF とは限りません。(もしかしたら、シャットダウン中にフリーズしているかも。電源長押し  が失敗しているかも)

なので、マザーボードの電源 LED への配線を GPIO に入力して、電源状態を把握できるようにした方が良い気がしてきました。これは単純に GPIO を読むだけで済むはずなので  実装したい感じです。

参考にしたサイト

これらを読んだらこの記事いらないかも。

リモートで PC の電源スイッチ操作(eject じゃなくて Raspberry Pi でな

http://unsui.hatenablog.com/entry/2014/09/11/225211

怪しいリレーモジュールを買ってみた

http://yaplog.jp/kazuikazui/archive/459

ツール・ラボ 第 24 回 Raspberry Pi の GPIO を制御する(コマンド編)

https://tool-lab.com/make/raspberrypi-startup-24/