Raspberry Pi の Ubuntu で pip install 時に ModuleNotFoundError: No module named '_ctypes' というエラーが出るとき

結論

（Raspberry Pi が、というわけではなく）以下のようにパッケージをインストールします。

$ sudo apt install -y build-essential libbz2-dev libdb-dev libreadline-dev libffi-dev libgdbm-dev liblzma-dev libncursesw5-dev libsqlite3-dev libssl-dev zlib1g-dev uuid-dev tk-dev

参考

Python の公式ドキュメントが参考になります。

64bit Ubuntu を入れた Raspberry Pi に Mackerel (mackerel-agent) をインストールする方法

前提

• Raspberry Pi 4B (8GB)
• Ubuntu 20.04 (64bit)

結論

deb ファイルをダウンロードし、dpkg コマンドでインストールする。インストール完了後に設定ファイルである /etc/mackerel-agent/mackerel-agent.conf に APIキー を書き込んで、mackerel-agent を再起動する。

Docker コンテナを起ち上げた後、とあるサブネットのクライアントから別のサブネットの特定のサーバに対してだけ突然 SSH ができなくなり ping も通らなくなったとき

理由

• 異なるサブネットから SSH して Docker コンテナを起ち上げたから

前提

• 他のサーバには問題ない
• 本当に「突然」のように感じた
• サーバは Raspberry Pi である
• エラーログとしては以下のような感じです

$ systemctl status docker.service
● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2021-01-15 10:51:08 JST; 3s ago
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
    Process: 4804 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock >
   Main PID: 4804 (code=exited, status=1/FAILURE)

 1月 15 10:51:08 hogehost systemd[1]: docker.service: Scheduled restart job, restart counter is a>
 1月 15 10:51:08 hogehost systemd[1]: Stopped Docker Application Container Engine.
 1月 15 10:51:08 hogehost systemd[1]: docker.service: Start request repeated too quickly.
 1月 15 10:51:08 hogehost systemd[1]: docker.service: Failed with result 'exit-code'.
 1月 15 10:51:08 hogehost systemd[1]: Failed to start Docker Application Container Engine.

結論

Docker (Docker Compose) で立ち上げたコンテナがポートを専有していた*1。 おそらくこちらです。

github.com

解決方法

当該サーバに SSH できるクライアントから入って*2、コンテナを止める*3。

それでもダメなようならば、Docker を一度アンインストールしてインストールし直す（こちらの方が確実かと思います）。再インストールの方法は公式ページに従います.

docs.docker.com

アンインストールは以下のとおりです。

$ sudo apt-get purge docker-ce docker-ce-cli containerd.io
$ sudo rm -rf /var/lib/docker 

再インストールは以下のとおりです。

$ sudo apt install -y docker-ce docker-ce-cli containerd.io

感想

初めてのことだったのでルータの設定やファイアウォールの設定などをひっくり返して小一時間悩みました。とはいえ「突然」に起きたことだったので、まさか Docker のコンテナが原因であるとは思っておらず、手探りの中で原因を探しました。

ただ、直前の動作はたしかに $ docker-compose up でした。

補足

ウェブを検索すると /lib/systemd/system/docker.service を編集する方法が見つかりますが、まずは再インストールから試すのが手かと思います。

*1:可能性が高い。ルーティング？

*2:止める原因を作ったマシンからは SSH できないようです

*3:最悪、最小限構成で物理で繋いで止める

SSH でログインした後にシェルのプロンプト表示までの時間が長い場合の対処法の一つ

結論

受ける側の SSHd の設定ファイル、/etc/ssh/sshd_config において、UsePAM を no に指定します*1。

具体例

/etc/ssh/sshd_config の中ほどに UsePAM を指定する箇所があります。

gyazo.com

ここの UsePAM yes を UsePAM no に変更します。

変更した後は sshd を再起動します。以下は Ubuntu の例です。

$ sudo service sshd restart

補足

Raspberry Pi などで OS に MicroSD のような遅いストレージを使っている際に、ログイン時のシェルの処理が多すぎてシェルが出るまでに 2分 近くかかることがありました。

ログイン自体には成功しており、対応方法として上記のようにしました。

*1:デフォルトは yes

Docker Compose で MySQL 8 のコンテナを作るときに、自由にスクリプトを実行して環境を作る方法

結論

コンテナ側の /docker-entrypoint-initdb.d 配下に実行したいスクリプトを置きます。するとコンテナ作成時にそれらのスクリプトをファイル名の順番で実行してくれます。

コンテナ作成時にホスト側の適当なディレクトリにスクリプトファイルを詰め込み、そのディレクトリをコンテナ側の /docker-entrypoint-initdb.d と共有しましょう（ボリュームとして割り当てましょう）。

Docker Compose での具体例

docker-compose.yml で書くと以下のような感じになります。