Linux Mint に Docker をインストール

Docker 公式のおすすめに従って、Docker Desktop for Linux をインストールすることにした。

Linux Mint は Ubuntu がベースなので、Ubuntu のページを参考にする。

Docker は KVM を使うので、さきに KVM を有効にする。プロセッサは Intel だから、kvm_intelも有効にする。

takatoh@apostrophe:~$ modprobe kvm
takatoh@apostrophe:~$ modprobe kvm_intel

何も出力がないのはうまく行ったってことか。もし失敗したら kvm-ok コマンドで確認しろと書いてあるのでやってみる。

akatoh@apostrophe:~$ kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

大丈夫らしい。kvm モジュールが有効になってるかどうかは、つぎのようにしてチェックできる。

takatoh@apostrophe:~$ lsmod | grep kvm
kvm_intel 487424 0
kvm 1404928 1 kvm_intel
irqbypass 12288 1 kvm

これも大丈夫そうだ。

KVM デバイス(/dev/kvm)に対するアクセス権をつける。

takatoh@apostrophe:~$ sudo usermod -aG kvm $USER

さて、ここまではどのディストリビューションでも同様だけど、ここからは Ubuntu 特有の部分。

Docker の apt リポジトリを登録するが、その前に下準備。

takatoh@apostrophe:~$ sudo apt-get update
takatoh@apostrophe:~$ sudo apt-get install ca-certificates curl
takatoh@apostrophe:~$ sudo install -m 0755 -d /etc/apt/keyrings
takatoh@apostrophe:~$ sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
takatoh@apostrophe:~$ sudo chmod a+r /etc/apt/keyrings/docker.asc

で、リポジトリを登録。

takatoh@apostrophe:~$ echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

登録したら、apt-get update

takatoh@apostrophe:~$ sudo apt-get update
ヒット:1 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu noble InRelease
無視:2 http://ftp.jaist.ac.jp/pub/Linux/linuxmint/packages wilma InRelease
ヒット:3 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu noble-updates InRelease
ヒット:4 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu noble-backports InRelease
ヒット:5 http://ftp.jaist.ac.jp/pub/Linux/linuxmint/packages wilma Release
ヒット:6 https://packages.microsoft.com/repos/code stable InRelease
無視:8 https://download.docker.com/linux/ubuntu wilma InRelease
ヒット:9 http://security.ubuntu.com/ubuntu noble-security InRelease
エラー:10 https://download.docker.com/linux/ubuntu wilma Release
404 Not Found [IP: 2600:9000:26a6:a600:3:db06:4200:93a1 443]
パッケージリストを読み込んでいます... 完了
E: リポジトリ https://download.docker.com/linux/ubuntu wilma Release には Release ファイルがありません。
N: このようなリポジトリから更新を安全に行うことができないので、デフォルトでは更新が無効になっています。
N: リポジトリの作成とユーザ設定の詳細は、apt-secure(8) man ページを参照してください。

何やらエラーになった。リポジトリがおかしいようだけど……よく見ると、wilma とある。wilma は Linux Mint 22 のコードネームで、Ubuntu 24.04 は noble のはずだ。/etc/os-release ファイルがつぎのようになっている。

takatoh@apostrophe:~$ cat /etc/os-release
NAME="Linux Mint"
VERSION="22 (Wilma)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 22"
VERSION_ID="22"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=wilma
UBUNTU_CODENAME=noble

つまり、リポジトリを登録するときに、$VERSION_CODENAME じゃなくて $UBUNTU_CODENAME を参照する必要があったってこと。今回はやり直す代わりに、直接ファイルを編集した。

takatoh@apostrophe:~$ sudo vim /etc/apt/sources.list.d/docker.list

今度は大丈夫のはず。

takatoh@apostrophe:~$ sudo apt-get update
ヒット:1 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu noble InRelease
ヒット:2 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu noble-updates InRelease
無視:3 http://ftp.jaist.ac.jp/pub/Linux/linuxmint/packages wilma InRelease
ヒット:4 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu noble-backports InRelease
ヒット:5 http://ftp.jaist.ac.jp/pub/Linux/linuxmint/packages wilma Release
取得:6 https://download.docker.com/linux/ubuntu noble InRelease [48.8 kB]
ヒット:7 https://packages.microsoft.com/repos/code stable InRelease
ヒット:8 http://security.ubuntu.com/ubuntu noble-security InRelease
取得:10 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages [15.3 kB]
64.2 kB を 2秒 で取得しました (39.8 kB/s)
パッケージリストを読み込んでいます... 完了

あとは Docker (とその関連パッケージ)を apt-get install でインストール。

takatoh@apostrophe:~$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています... 完了
状態情報を読み取っています... 完了
以下の追加パッケージがインストールされます:
docker-ce-rootless-extras libslirp0 pigz slirp4netns
提案パッケージ:
aufs-tools cgroupfs-mount | cgroup-lite
以下のパッケージが新たにインストールされます:
containerd.io docker-buildx-plugin docker-ce docker-ce-cli
docker-ce-rootless-extras docker-compose-plugin libslirp0 pigz slirp4netns
アップグレード: 0 個、新規インストール: 9 個、削除: 0 個、保留: 55 個。
123 MB のアーカイブを取得する必要があります。
この操作後に追加で 441 MB のディスク容量が消費されます。
続行しますか? [Y/n] y
取得:1 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu noble/universe amd64 pigz amd64 2.8-1 [65.6 kB]
取得:2 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu noble/main amd64 libslirp0 amd64 4.7.0-1ubuntu3 [63.8 kB]
取得:3 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu noble/universe amd64 slirp4netns amd64 1.2.1-1build2 [34.9 kB]
取得:4 https://download.docker.com/linux/ubuntu noble/stable amd64 containerd.io amd64 1.7.22-1 [29.5 MB]
取得:5 https://download.docker.com/linux/ubuntu noble/stable amd64 docker-buildx-plugin amd64 0.17.1-1~ubuntu.24.04~noble [30.3 MB]
取得:6 https://download.docker.com/linux/ubuntu noble/stable amd64 docker-ce-cli amd64 5:27.3.1-1~ubuntu.24.04~noble [15.0 MB]
取得:7 https://download.docker.com/linux/ubuntu noble/stable amd64 docker-ce amd64 5:27.3.1-1~ubuntu.24.04~noble [25.6 MB]
取得:8 https://download.docker.com/linux/ubuntu noble/stable amd64 docker-ce-rootless-extras amd64 5:27.3.1-1~ubuntu.24.04~noble [9,588 kB]
取得:9 https://download.docker.com/linux/ubuntu noble/stable amd64 docker-compose-plugin amd64 2.29.7-1~ubuntu.24.04~noble [12.7 MB]
123 MB を 2秒 で取得しました (70.1 MB/s)
以前に未選択のパッケージ pigz を選択しています。
(データベースを読み込んでいます ... 現在 545486 個のファイルとディレクトリがインストールされています。)
.../0-pigz_2.8-1_amd64.deb を展開する準備をしています ...
pigz (2.8-1) を展開しています...
以前に未選択のパッケージ containerd.io を選択しています。
.../1-containerd.io_1.7.22-1_amd64.deb を展開する準備をしています ...
containerd.io (1.7.22-1) を展開しています...
以前に未選択のパッケージ docker-buildx-plugin を選択しています。
.../2-docker-buildx-plugin_0.17.1-1~ubuntu.24.04~noble_amd64.deb を展開する準備をしています ...
docker-buildx-plugin (0.17.1-1~ubuntu.24.04~noble) を展開しています...
以前に未選択のパッケージ docker-ce-cli を選択しています。
.../3-docker-ce-cli_5%3a27.3.1-1~ubuntu.24.04~noble_amd64.deb を展開する準備をしています ...
docker-ce-cli (5:27.3.1-1~ubuntu.24.04~noble) を展開しています...
以前に未選択のパッケージ docker-ce を選択しています。
.../4-docker-ce_5%3a27.3.1-1~ubuntu.24.04~noble_amd64.deb を展開する準備をしています ...
docker-ce (5:27.3.1-1~ubuntu.24.04~noble) を展開しています...
以前に未選択のパッケージ docker-ce-rootless-extras を選択しています。
.../5-docker-ce-rootless-extras_5%3a27.3.1-1~ubuntu.24.04~noble_amd64.deb を展開する準備をしています ...
docker-ce-rootless-extras (5:27.3.1-1~ubuntu.24.04~noble) を展開しています...
以前に未選択のパッケージ docker-compose-plugin を選択しています。
.../6-docker-compose-plugin_2.29.7-1~ubuntu.24.04~noble_amd64.deb を展開する準備をしています ...
docker-compose-plugin (2.29.7-1~ubuntu.24.04~noble) を展開しています...
以前に未選択のパッケージ libslirp0:amd64 を選択しています。
.../7-libslirp0_4.7.0-1ubuntu3_amd64.deb を展開する準備をしています ...
libslirp0:amd64 (4.7.0-1ubuntu3) を展開しています...
以前に未選択のパッケージ slirp4netns を選択しています。
.../8-slirp4netns_1.2.1-1build2_amd64.deb を展開する準備をしています ...
slirp4netns (1.2.1-1build2) を展開しています...
docker-buildx-plugin (0.17.1-1~ubuntu.24.04~noble) を設定しています ...
containerd.io (1.7.22-1) を設定しています ...
docker-compose-plugin (2.29.7-1~ubuntu.24.04~noble) を設定しています ...
docker-ce-cli (5:27.3.1-1~ubuntu.24.04~noble) を設定しています ...
libslirp0:amd64 (4.7.0-1ubuntu3) を設定しています ...
pigz (2.8-1) を設定しています ...
docker-ce-rootless-extras (5:27.3.1-1~ubuntu.24.04~noble) を設定しています ...
slirp4netns (1.2.1-1build2) を設定しています ...
docker-ce (5:27.3.1-1~ubuntu.24.04~noble) を設定しています ...
man-db (2.12.0-4build2) のトリガを処理しています ...
libc-bin (2.39-0ubuntu8.3) のトリガを処理しています ...

これで完了。hello-world イメージを実行してみる。

takatoh@apostrophe:~$ sudo docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/get-started/

問題なさそうだ。

バージョンの確認をしておく。つぎの通り。

takatoh@apostrophe:~$ docker --version
Docker version 27.3.1, build ce12230
takatoh@apostrophe:~$ docker version
Client: Docker Engine - Community
Version: 27.3.1
API version: 1.47
Go version: go1.22.7
Git commit: ce12230
Built: Fri Sep 20 11:40:59 2024
OS/Arch: linux/amd64
Context: default

Server: Docker Engine - Community
Engine:
Version: 27.3.1
API version: 1.47 (minimum version 1.24)
Go version: go1.22.7
Git commit: 41ca978
Built: Fri Sep 20 11:40:59 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.22
GitCommit: 7f7fdf5fed64eb6a7caf99b3e12efcf9d60e311c
runc:
Version: 1.1.14
GitCommit: v1.1.14-0-g2c9f560
docker-init:
Version: 0.19.0
GitCommit: de40ad0
takatoh@apostrophe:~$ docker compose version
Docker Compose version v2.29.7

Dockerコンテナ上のMediaWikiをアップグレードする

つい先日(4日前)に最新版のDocker公式のコンテナイメージ 1.41.0 がリリースされているのを見つけたので、ローカルネットワークで運用している MediaWiki をアップグレードした。これまでのバージョンは 1.35.0。

まずは、データベースのバックアップをとる。データベースもMariaDBのDockerコンテナだ。

takatoh@unclemeat:~$ docker exec -it mywiki-db mysqldump -hlocalhost -P3306 -uroot -prootpass mywiki > mywiki.sql

mywiki-db がデータベースのコンテナ。このコンテナの中で mysqldump コマンドを実行して、mywiki.sql ファイルに書き込んでいる。mysqldump-h オプションはホスト、-P はポート、-u はユーザ、-p はパスワード。-p と引数のあいだに空白を入れるとどういうわけかうまく行かない。

バックアップをとったら、いったんコンテナを止める。

takatoh@unclemeat:~$ cd docker-configuration
takatoh@unclemeat:~/docker-configuration$ docker compose down

docker-compose.yml ファイルを書き換える。MediaWiki イメージのバージョンを1.35.0から1.41.0に書き換えるだけだ。

version: "3"

services:

  mywiki:
    image: mediawiki:1.41.0
    container_name: mywiki
    restart: always
    depends_on:
      - mywiki-db
    volumes:
      - "${CONTAINER_ENV_DIR}/mywiki/images:/var/www/html/images"
      - "${CONTAINER_ENV_DIR}/mywiki/LocalSettings.php:/var/www/html/LocalSettings.php"
      - "${CONTAINER_ENV_DIR}/mywiki/php.ini-production:/usr/local/etc/php/php.ini"
      - "${CONTAINER_ENV_DIR}/mywiki/extensions/YouTube:/var/www/html/extensions/YouTube"
    ports:
      - 9090:80

  mywiki-db:
    image: mariadb:10.5.6-focal
    container_name: mywiki-db
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: mywiki
      MYSQL_USER: wikiuser
      MYSQL_PASSWORD: wikipass
    volumes:
      - "${CONTAINER_ENV_DIR}/mywiki/db:/var/lib/mysql"
    ports:
      - 8836:3306

書き換えが終わったら、コンテナを起動する。

takatoh@unclemeat:~/docker-configuration$ docker compose up -d

問題なく起動したけど、ブラウザでアクセスするとエラーが出ていた。データベースのテーブルにカラムが見つからないらしい。MediaWiki のアップブレードでデータベースのスキーマも更新する必要があるようだ。↓このページが参考になった。

MediaWiki のディレクトリで更新スクリプトを実行すればいいようだ。MediaWiki は Dockerコンテナで動いているので、コンテナの中で実行する。

takatoh@unclemeat:~/docker-configuration$ docker exec -it mywiki bash
root@a423a4fe2c67:/var/www/html# php maintenance/run.php update.php
MediaWiki 1.41.0 Updater

Your composer.lock file is up to date with current dependencies!
Going to run database updates for bsl_wiki
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with --quick) ...0
...collations up-to-date.
(以下略)

無事、更新スクリプトが終了したら、念のためコンテナを再起動する。で、改めてブラウザでアクセスすると、今度はエラーなくページが表示された。

これで完了。

iPadからローカルネットワーク上のWebサーバにアクセスする

メモ。あとでもう少し丁寧に書くつもり。

Squidのインストールと設定

apt でインストール。

takatoh@wplj:~$ sudo apt install -y squid

設定ファイルは /etc/squid/squid.conf だけど、/etc/squid/conf.d/*.conf を読み込むようになってるので、直接編集せずに /etc/squid/conf.d/panicblanket.conf ファイルを作る。

acl lan src 192.168.2.0/24
http_access allow lan

できたら Squid を再起動。

takatoh@wplj:~$ sudo systemctl restart squid

プロキシ用のポートを開く

Squid のデフォルトのまま。3128番のポートを開く。

takatoh@wplj:~$ sudo ufw allow 3128
Rule added
Rule added (v6)

iPadの設定

Wi-Fi の設定の一番下にある「プロキシを構成」をタップ。「手動」にチェックを入れて、サーバの IP アドレスとポート番号を入力。保存すれば OK。

これで iPad からローカルネットワーク上の Web サーバにアクセスできるようになった。

Ubuntu Server 22.04にSambaサーバをたてる(Dockerなしで)

Docker で Samba サーバをたてるのは諦めた。Ubuntu の上で直接 Samba サーバを動かすことにする。

まずはお決まりの apt update から。

takatoh@wplj:~$ sudo apt update

Samba サーバのインストール。

takatoh@wplj:~$ sudo apt install -y samba

設定ファイルを編集(バックアップをとってから)。

takatoh@wplj:~$ sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.orig
takatoh@wplj:~$ sudo vim /etc/samba/smb.conf

ワークグループの名前を変更したほか、ユーザー認証なしでアクセスできる public と takatoh のみアクセスできる restricted の2つの共有フォルダを作った。

もとの設定ファイルとの差分:

takatoh@wplj:~$ diff /etc/samba/smb.conf.orig /etc/samba/smb.conf
29c29
<    workgroup = WORKGROUP
---
>    workgroup = PANICBLANKET
241a242,257
> 
> [public]
>     path = /mnt/data/samba
>     writable = yes
>     force create mode = 0644
>     force directory mode = 0755
>     guest ok = yes
>     guest only = yes
> 
> [restricted]
>     path = /mnt/data/samba_takatoh
>     writable = yes
>     force create mode = 0644
>     force directory mode = 0755
>     valid users = takatoh
>     force user = takatoh

コメントを除く全体はこう:

[global]
   workgroup = PANICBLANKET
   server string = %h server (Samba, Ubuntu)
   log file = /var/log/samba/log.%m
   max log size = 1000
   logging = file
   panic action = /usr/share/samba/panic-action %d
   server role = standalone server
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no

[public]
    path = /mnt/data/samba
    writable = yes
    force create mode = 0644
    force directory mode = 0755
    guest ok = yes
    guest only = yes

[restricted]
    path = /mnt/data/samba_takatoh
    writable = yes
    force create mode = 0644
    force directory mode = 0755
    valid users = takatoh
    force user = takatoh

で、共有用のディレクトリを作る。

takatoh@wplj:~$ sudo mkdir -p /mnt/data/samba
takatoh@wplj:~$ sudo chown nobody:nogroup /mnt/data/samba
takatoh@wplj:~$ sudo mkdir -p /mnt/data/samba_takatoh
takatoh@wplj:~$ sudo chown takatoh:takatoh /mnt/data/samba_takatoh

結果としてこうなった。

takatoh@wplj:~$ ls -l /mnt/data
total 8
drwxr-xr-x 2 nobody  nogroup 4096 May  6 18:13 samba
drwxr-xr-x 3 takatoh takatoh 4096 May  6 18:13 samba_takatoh

そして、smbd をリスタート。

takatoh@wplj:~$ sudo systemctl restart smbd

Samba にユーザーを作る。pdbedit コマンド。

takatoh@wplj:~$ sudo pdbedit -a takatoh
new password:
retype new password:
Unix username:        takatoh
NT username:          
Account Flags:        [U          ]
User SID:             S-1-5-21-3828460484-3255695466-1925772709-1000
Primary Group SID:    S-1-5-21-3828460484-3255695466-1925772709-513
Full Name:            takatoh
Home Directory:       \\WPLJ\takatoh
HomeDir Drive:        
Logon Script:         
Profile Path:         \\WPLJ\takatoh\profile
Domain:               WPLJ
Account desc:         
Workstations:         
Munged dial:          
Logon time:           0
Logoff time:          Thu, 07 Feb 2036 00:06:39 JST
Kickoff time:         Thu, 07 Feb 2036 00:06:39 JST
Password last set:    Fri, 06 May 2022 18:12:32 JST
Password can change:  Fri, 06 May 2022 18:12:32 JST
Password must change: never
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

これでOK。Windows マシンからアクセスしてみると、ちゃんと \\wplj\public には認証無しで読み書きできる。\\wplj\restricted にはユーザー名とパスワードを要求され、正しく入力すれば読み書きできる。

無事完了。

[追記]

Samba のインストールと設定に際して、ファイアウォール関連は何もしていない。設定は次のようになっている。

takatoh@wplj:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
137                        ALLOW       Anywhere                  
138                        ALLOW       Anywhere                  
139                        ALLOW       Anywhere                  
445                        ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)             
137 (v6)                   ALLOW       Anywhere (v6)             
138 (v6)                   ALLOW       Anywhere (v6)             
139 (v6)                   ALLOW       Anywhere (v6)             
445 (v6)                   ALLOW       Anywhere (v6)

Docker を使ってやってたときには何が悪かったのか、結局よくわからない。

DockerでSambaサーバをたてたけど外部からつながらない

昨日・今日といろいろ調べながら作業をしたけど、何が悪いのかわからない。もう Docker を使うのは諦めて、Ubuntu に直接 Samba サーバをインストールすることにしようと思うが、記録だけ残しておく。あ、「外部」ってのはローカルネットワーク上の別の PC のこと。

環境

ホストはこの間インストールした Ubuntu Server 22.04 だ。マシン自体は古いけど、いま Samba サーバになってるマシン(これは CentOS 7)はもっと古いので、これを置きかえるつもり。

  • Ubuntu Server 22.04 LTS
  • Docker version 20.10.14, build a224086349
  • docker-compose version 1.29.2, build unknown
  • dperson/samba (Samba の Docker イメージ)

Docker と docker-compose は Ubuntu のインストール時に一緒にインストールしたもの。Samba には公式の Docker イメージがないらしく、ググるとこの dperson/samba がよく使われてるようなのでこれにした。

Samba サーバをたてる

あちこちのページを参考にして、docker-compose.yml ファイルはこうした。

version: "3"

services:

  samba:
    image: dperson/samba
    container_name: samba
    restart: always
    ports:
      - "137:137"
      - "138:138"
      - "139:139"
      - "445:445"
    volumes:
      - "/mnt/data/samba:/mnt/public"
    command: [
      "-r",
      "-S",
      "-w", "PANICBLANKET",
      "-s", "public;/mnt/public;yes;no;yes;all"
    ]

これで Docker コンテナを起動してやる。

takatoh@wplj:~$ docker-compose up -d
Creating network "takatoh_default" with the default driver
Creating samba ... done
takatoh@wplj:~$ docker-compose ps
Name              Command                State                  Ports           
--------------------------------------------------------------------------------
samba   /sbin/tini -- /usr/bin/sam    Up (healthy)   0.0.0.0:137->137/tcp,:::137
        ...                                          ->137/tcp, 137/udp, 0.0.0.0
                                                     :138->138/tcp,:::138->138/t
                                                     cp, 138/udp, 0.0.0.0:139->1
                                                     39/tcp,:::139->139/tcp, 0.0
                                                     .0.0:445->445/tcp,:::445->4
                                                     45/tcp

次に、外部から接続できるようにホスト側のファイアウォールを設定する。Samba に関連するポートは、137、138、139、445 だ。ufw コマンドで接続を許可する。

akatoh@wplj:~$ sudo ufw allow 137
Rule added
Rule added (v6)
takatoh@wplj:~$ sudo ufw allow 138
Rule added
Rule added (v6)
takatoh@wplj:~$ sudo ufw allow 139
Rule added
Rule added (v6)
takatoh@wplj:~$ sudo ufw allow 445
Rule added
Rule added (v6)

そして、ファイアウォールを有効化。

takatoh@wplj:~$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

次のような状態になった。

akatoh@wplj:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
137                        ALLOW       Anywhere                  
138                        ALLOW       Anywhere                  
139                        ALLOW       Anywhere                  
445                        ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)             
137 (v6)                   ALLOW       Anywhere (v6)             
138 (v6)                   ALLOW       Anywhere (v6)             
139 (v6)                   ALLOW       Anywhere (v6)             
445 (v6)                   ALLOW       Anywhere (v6)

これで完了(のはず)。

Windows から接続テスト

Samba サーバは出来上がったはずなので、Windows マシンから接続できるかテストしてみたところ、つながらない。共有フォルダどころか、コンピュータ(ホスト名は wplj)さえも見つからないと言われる。困った。

ネットワークの確認

Samba サーバをたてた wplj とは別の Ubuntu マシン(ホスト名は apostrophe)から、ネットワーク越しに接続できるのかを確認してみた。

まずは ping

takatoh@apostrophe:~$ ping wplj
PING wplj (192.168.2.12) 56(84) バイトのデータ
64 バイト応答 送信元 wplj (192.168.2.12): icmp_seq=1 ttl=64 時間=0.619ミリ秒
64 バイト応答 送信元 wplj (192.168.2.12): icmp_seq=2 ttl=64 時間=0.538ミリ秒
64 バイト応答 送信元 wplj (192.168.2.12): icmp_seq=3 ttl=64 時間=1.15ミリ秒
64 バイト応答 送信元 wplj (192.168.2.12): icmp_seq=4 ttl=64 時間=0.694ミリ秒
^C
--- wplj ping 統計 ---
送信パケット数 4, 受信パケット数 4, パケット損失 0%, 時間 3057ミリ秒
rtt 最小/平均/最大/mdev = 0.538/0.750/1.150/0.237ミリ秒

OK。そりゃそうだ、SSH で接続できてんだから。

なら、ポートが使えるかどうかを確認する nc コマンド。繋がるのがわかっている 22 番ポート(SSH)で試してみるとこうなる。

takatoh@apostrophe:~$ nc -vz wplj 22
Connection to wplj 22 port [tcp/ssh] succeeded!

では、Samba の使っている(はず)のポートではどうか。

akatoh@apostrophe:~$ nc -vz -u wplj 137
takatoh@apostrophe:~$ nc -vz -u wplj 138
takatoh@apostrophe:~$ nc -vz wplj 139
nc: connect to wplj port 139 (tcp) failed: Connection refused
takatoh@apostrophe:~$ nc -vz wplj 445
nc: connect to wplj port 445 (tcp) failed: Connection refused

137 番と 138 番で -u オプションを指定してるのは udp だから。何も出力されてないのは、接続できないからだ。tcp をつかう 139 番と 445 番は「失敗した」と明快に出力されてる。

一方のサーバ(wplj)側ではどうだろう。ss コマンドを使う。

takatoh@wplj:~$ ss -natu
Netid State  Recv-Q Send-Q                      Local Address:Port Peer Address:Port                                   Process                                  
udp   UNCONN 0      0                           127.0.0.53%lo:53        0.0.0.0:*                                                                               
udp   UNCONN 0      0                     192.168.2.12%enp1s0:68        0.0.0.0:*                                                                               
udp   UNCONN 0      0      [fe80::cad3:ffff:fe9d:2f5f]%enp1s0:546          [::]:*                                                                               
tcp   LISTEN 0      4096                        127.0.0.53%lo:53        0.0.0.0:*                                                                               
tcp   LISTEN 0      128                               0.0.0.0:22        0.0.0.0:*                                                                               
tcp   ESTAB  0      0                            192.168.2.12:22   192.168.2.14:58570                                                                           
tcp   LISTEN 0      128                                  [::]:22           [::]:*

Status の UNCONNLISTEN はそれぞれ udp、tcp の待受状態を表す。一つだけある ESTAB はつながっていることを表していて、これは SSH(22番ポート)だ。見事に Samba 関連のポートがない。

[追記]

いまためしたら、Samba のコンテナが起動してなかった。起動した上で ss コマンドを試すとこうなった。

takatoh@wplj:~$ ss -natu
Netid State  Recv-Q Send-Q                      Local Address:Port Peer Address:Port                                   Process                                  
udp   UNCONN 0      0                           127.0.0.53%lo:53        0.0.0.0:*                                                                               
udp   UNCONN 0      0                     192.168.2.12%enp1s0:68        0.0.0.0:*                                                                               
udp   UNCONN 0      0      [fe80::cad3:ffff:fe9d:2f5f]%enp1s0:546          [::]:*                                                                               
tcp   LISTEN 0      4096                              0.0.0.0:137       0.0.0.0:*                                                                               
tcp   LISTEN 0      4096                              0.0.0.0:138       0.0.0.0:*                                                                               
tcp   LISTEN 0      4096                              0.0.0.0:139       0.0.0.0:*                                                                               
tcp   LISTEN 0      4096                        127.0.0.53%lo:53        0.0.0.0:*                                                                               
tcp   LISTEN 0      128                               0.0.0.0:22        0.0.0.0:*                                                                               
tcp   LISTEN 0      4096                              0.0.0.0:445       0.0.0.0:*                                                                               
tcp   ESTAB  0      0                            192.168.2.12:22   192.168.2.14:58570                                                                           
tcp   LISTEN 0      4096                                 [::]:137          [::]:*                                                                               
tcp   LISTEN 0      4096                                 [::]:138          [::]:*                                                                               
tcp   LISTEN 0      4096                                 [::]:139          [::]:*                                                                               
tcp   LISTEN 0      128                                  [::]:22           [::]:*                                                                               
tcp   LISTEN 0      4096                                 [::]:445          [::]:*

Samba 関連のポートを待受けるようになった。けど、やっぱり他のコンピュータからはつながらない。

takatoh@apostrophe:~$ nc -u -vz wplj 137
takatoh@apostrophe:~$ nc -u -vz wplj 138
takatoh@apostrophe:~$ nc -vz wplj 139
nc: connect to wplj port 139 (tcp) failed: Connection timed out
takatoh@apostrophe:~$ nc -vz wplj 445
nc: connect to wplj port 445 (tcp) failed: Connection timed out

[追記ここまで]

まとめ

というわけで、どうやら Docker でたてた Samba のせいじゃなく、コンピュータ間で通信できてないように見える。SSH は問題なくつながってるのに何が違うんだ?

Ubuntu Server 22.04 LTSのインストール

先日リリースされたばかりの Ubuntu Server 22.04 LTS をインストールしてみた。インストール先は Rocky Linux をインストールしたまま使いみちを考えてなかった PC だ。これを、いまバックアップサーバになってる CentOS 7 のサーバと置き換えることにする。Windows PC からもアクセスするので Samba を入れる必要があるけど、それはまた今度。今日は Ubuntu のインストールだけ。

といっても、去年 Ubuntu Server 20.04 LTS をインストールしたときとやることは変わらないので、手順については以前の記事のリンクを置いておく。

違うところといえば、Featured Server Snaps の選択のところで docker のほかに aws-cli も選択してインストールしたことくらい。20.04 のときはなかった(か、気が付かなかった)。

というわけで、インストールは無事終了した。

だけどひとつだけやらかした。そういえば去年も同じところで引っかかったんだ。何かというと、インストール時に作ったユーザのパスワードだ。

日本語配列のキーボードを使ってるんだけど、Ubuntu Server のインストーラには日本語キーボードの選択肢がない。というか 20.04 LTS の時にはなかったんで今回も言語選択のところで English を選んだ(もしかしたら Japanese もあったのかもしれない。ないと思っていたので確認しなかった)。日本語と英語のキーボードだと、アルファベットや数字はいいけど、記号の配列が違うんだ。で、パスワードに記号を使ってしまうと、入力したつもりの文字と実際に入力された文字が違うことになる。

これが問題になるのは SSH でほかの PC から接続して sudo コマンドを使ったとき。「ほかの PC」ってのは Windows か Ubuntu Desktop で、日本語配列のキーボードが問題なく使えてる。でも、SSH 接続した先の Ubuntu Server で sudo コマンドにパスワードを要求されて入力すると、正しいパスワードを入力してるのにエラーになる。なぜかというと、Ubuntu Server 側には正しい(言い換えると、意図したとおりの)パスワードが設定されてないからだ。今回もこれで30分ぐらい無駄にした。

英語配列のキーボード、ひとつ買っとこうかな。

古いRailsアプリをDockerコンテナに乗せた

もう1年も前になるけどこんな記事を書いた。

ローカルネットワークのサーバ置き換えに際して、古いサーバ(Ubuntu 16.04 LTS)で動かしていた Rails アプリが、新しいサーバ(Ubuntu 20.04 LTS)上で動かせなくてどうしよう……っていう記事だ。

あれから1年も過ぎてしまったけど、今年に入ってから週末ごとにちまちまと作業をして、なんとか新しいサーバの Dockerコンテナで動かせるまでになった。

ベースにした Docker イメージは、Ruby の公式イメージのうち一番古いバージョン、2.6.9。とにかく Ruby の公式 Docker イメージをベースにしたコンテナで動かせることを目標にした。

Rails は 5.0.7.2まで上げた。これだって今となっては古いバージョン(RubyGems.org を見ると2019/3/13リリース)だけど、ローカルネットワークでしか使ってない web アプリなのでひとまず妥協する。

作業は開発用メインマシン(Ubuntu 20.04 LTS)の rbenv で Ruby そのもののバージョンも変えながらやった。作業を始めた時点では Rails 4.1.4 で、最後のコミットはなんと 2016/3/3 だった。6年近くもメンテしてなかったってことだよ。アプリを使う分には不自由してなかったからだけど、だからってほったらかしだとこうやって後になってツケが来るんだよな。Rails にさわるもの6年ぶりってわけで、少しずつバージョンを上げるたびに出るエラー(主に依存関係)で苦労した。これからはもう少し面倒を見て、追いつくようにしよう。

さて、そういうわけで、動かしていたアプリがなくなって、めでたく古いサーバが空いた。春になれば Ubuntu 22.04 LTS もリリースされるだろうから、そのテスト用にしようかな。

AWS CLIでAmazon S3のバケットにファイルをアップロードする

AWS CLI は AWS の各サービスをコマンドラインから使えるツールだ。Amazon S3 をデータのバックアップ用に使おうと思って試してみた。

インストールと設定

AWS の Web ページからダウンロードする。↓のページから。

ダウンロードした awscliv2.zip を解凍する。

takatoh@apostrophe:~$ unzip awscliv2.zip

できた aws ディレクトリにあるインストールスクリプトを実行。

takatoh@apostrophe:~$ sudo aws/install
You can now run: /usr/local/bin/aws --version

メッセージにあるとおりコマンド名は aws だ。バージョンを確認してみよう。

takatoh@apostrophe:~$ aws --version
aws-cli/2.4.4 Python/3.8.8 Linux/5.4.0-91-generic exe/x86_64.ubuntu.20 prompt/off

続いて設定。aws configure コマンドを実行。

takatoh@apostrophe:~$ aws configure
AWS Access Key ID [None]: XXXXXXXXXXXXXXXXXXXX
AWS Secret Access Key [None]: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Default region name [None]: us-west-2
Default output format [None]: json

AWS Access Key ID と AWS Secret Access Key はあらかじめ取得しておくこと。

S3にファイルをアップロード

aws s3 cp コマンドを利用する。今回はテスト用の panicblanket-test というバケットにファイルをアップロードする。

takatoh@apostrophe:~$ aws s3 cp sample.zip s3://panicblanket-test/sample.zip

ディレクトリごとアップロードするには aws s3 sync コマンドが便利。バックアップ用途にはこちらがいいだろう。

takatoh@apostrophe:~$ aws s3 sync sample s3://panicblanket-test/sample
upload: sample/sample-1.zip to s3://panicblanket-test/sample/sample-1.zip
upload: sample/sample-2.zip to s3://panicblanket-test/sample/sample-2.zip

sample ディレクトリにあった2つのファイルがアップロードされた。

あとはシェルスクリプトを書いて定期的に事項するようにしておけば良さそうだ。

SQLite3のデータベースファイルからSQLにダンプする

たいしたネタじゃないけど、ときどき必要になる割にいつも調べてる気がするのでメモしておく。

SQLite3 のデータベースは1つのファイルになってる。このデータベースの中身を SQL にダンプするには sqlite3 コマンドをつかって、次の2通りのやり方がある。

対話的インターフェイスでダンプする方法

データベースを開くと、コマンド入力待ち状態になる。

takatoh@wplj:db$ sqlite3 production.sqlite3
SQLite version 3.11.0 2016-02-15 17:29:24
Enter ".help" for usage hints.
sqlite>

ここで .dump コマンドでダンプすることができるけど、このままだと画面に出力されてしまうので、先に .output コマンドで出力先をファイルに変更しておく。

sqlite> .output ./dump.sql

これでカレントディレクトリの dump.sql ファイルに出力されるようになる。そしたら .dump コマンド。

sqlite> .dump

引数なしだとデータベース内のすべてのテーブルをダンプする。特定のテーブルだけをダンプするには、そのテーブル名を引数に与えればいい。

終わったら .exit

sqlite> .exit

コマンドラインから直接ダンプする方法

パイプを使って sqlite3 コマンドにダンプを指示する .dump コマンドを流し込んでやればいい。デフォルトでは標準出力に書き出すので、ファイルにリダイレクトする。

takatoh@wplj:db$ echo '.dump' | sqlite3 production.sqlite3 > dump2.sql

定期的にバックアップするような場合にはこっちのほうが便利。

Ubuntu Serverの一般ユーザでdockerを実行できるようにする

先日インストールした Ubuntu Server だけど、インストール時に Docker も一緒にインストールしたのに、一般ユーザでは使えない。なら docker グループにユーザを追加すればいいんだろう、と思って次のようにしたら docker なんてグループはないと怒られた。

takatoh@navanax:~$ sudo usermod -a -G docker takatoh

グループ作ってくれてないのか……

で、ググったら↓のページを見つけた。

docker グループがなければ作ってやればいいらしい。

takatoh@navanax:~$ sudo addgroup --system docker
Adding group `docker' (GID 117) ...
Done.
takatoh@navanax:~$ sudo adduser takatoh docker
Adding user `takatoh' to group `docker' ...
Done.

これで一般ユーザでも docker コマンドと docker-compose コマンドが使えるようになった。