Apacheのmod_rewriteとBフラグ

PHP のプログラムを Docker コンテナで動かそうとして、Apache の mod_rewrite の設定でちょっと苦労したのでメモ。

主題は PHP じゃないので、プログラムは簡単な例にしておく。クエリーパラメータ name を受け取って、挨拶を返すだけのプログラムだ。

<?php
$name = $_GET["name"];
echo "Hello, " . $name . "!" . PHP_EOL;
?>

Docker イメージは php:8.2-apache を使う。

takatoh@apostrophe:myphpapp$ docker run -d --rm -p 80:80 -v .:/var/www/html php:8.2-apache

これで localhost:80 で待ち受けているはず。curl コマンドで試してみる。

takatoh@apostrophe:myphpapp$ curl http://localhost/hello.php?name=Andy
Hello, Andy!

期待通りだ。

つぎに、PHP プログラムに渡すパラメータ name を、クエリーパラメータではなく、パスの一部にしたい。つまり、http://localhost/hello/Andy という URL でアクセスしたい。

そこで、つぎのような .htaccess ファイルを書いた。

RewriteEngine on
RewriteRule ^hello/(.*)\$ hello.php?name=\$1

それから、Apache で上の .htaccess が有効になるように Dockerfile を書いた。デフォルトでは mod_rewrite 自体が有効になってないんだそうだ。

FROM php:8.2-apache
RUN a2enmod rewrite
RUN sed -ri -e 's!AllowOverride None!AllowOverride FileInfo!g' /etc/apache2/apache2.conf

mod_rewrite を有効にして、なおかつ、.htaccess ファイルでルールを設定するのを許可している。これを元に Docker イメージをビルド。

takatoh@apostrophe:myphpapp$ docker build -t myphpapp:1 .

コンテナを起動する。

takatoh@apostrophe:myphpapp$ docker run -d --rm -p 80:80 -v .:/var/www/html myphpapp:1

さっきと同じように curl で試してみよう。

takatoh@apostrophe:myphpapp$ curl http://localhost/hello/Andy
Hello, Andy!

うまくいった!もちろんクエリーパラーメータで渡すのでも期待通りに動く。

takatoh@apostrophe:myphpapp$ curl http://localhost/hello.php?name=Andy
Hello, Andy!

ところが、パス形式のパラーメータ部分(Andy の部分)に空白文字を使うとうまく動いてくれない(curl で URLエンコードする方法がわからなかったので、空白文字の代わりにエンコードした %20 を使っている)。

takatoh@apostrophe:myphpapp$ curl http://localhost/hello/Andy%20Weir
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p>
<hr>
<address>Apache/2.4.57 (Debian) Server at localhost Port 80</address>
</body></html>

クエリーパラメータ形式では大丈夫。

takatoh@apostrophe:myphpapp$ curl http://localhost/hello.php?name=Andy%20Weir
Hello, Andy Weir!

ブラウザでも試したけど同じ結果。さて、困った。

結論を先に書くと、RewiterRule の最後に B フラグをつければ解決する。Apache の公式ドキュメントにはちゃんと書いてある。が、参考にした日本語の解説ページの中には書いてあるページはなかった。探し方が悪いのかもしれないけど。

ともかく、.htaccess ファイルをつぎのように書き換えた。

RewriteEngine on
RewriteRule ^hello/(.*)\$ hello.php?name=\$1 [B]

再度試してみる。

takatoh@apostrophe:myphpapp$ curl http://localhost/hello/Andy%20Weir
Hello, Andy Weir!

OK!!!

一件落着。

後々のために、Apache のドキュメントから解説を引用しておこう(DeepL 翻訳)。

[B] フラグは、変換を適用する前に英数字以外の文字をエスケープするよう RewriteRule に指示します。

mod_rewrite は URL をマッピングする前にエスケープを解除しなければならないので、 後方参照は適用される時点でエスケープされません。B フラグを使うと、後方参照中の英数字以外の文字がエスケープされます

‘x & y/z’という検索語が与えられた場合、ブラウザはそれを’x%20%26%20y%2Fz’としてエンコードし、リクエストを’search/x%20%26%20y%2Fz’とします。Bフラグがない場合、このリライトルールは’search.php?term=x & y/z’にマップされますが、これは有効なURLではないため、search.php?term=x%20&y%2Fz=としてエンコードされ、意図されたものではありません。

この同じルールにBフラグを設定すると、パラメータは出力URLに渡される前に再エンコードされ、結果として/search.php?term=x%20%26%20%y%2Fzに正しくマッピングされます

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.
(以下略)

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

これで完了。

2つのGitリポジトリを統合する

別々に作った2つの Git リポジトリを統合する方法。違う方法もあると思うけど、調べた結果この方法でできた、ってことで記録しておく。

前提として:

  • 既存の2つのリポジトリ、repo_arepo_b を、新しく作った repo_combined に統合する
  • いずれも Python のプロジェクトで、Poetry を使ってる

まずは新しいプロジェクトを作る。

takatoh@apostrophe:w$ poetry new repo_combined

ディレクトリに移動して、Git の初期化と最初のコミット。このコミットには Poetry がデフォルトで作ってくれるファイルしかない。

takatoh@apostrophe:w$ cd repo_combined
takatoh@apostrophe:repo_combined$ git init
Initialized empty Git repository in /home/takatoh/w/repo_combined/.git/
takatoh@apostrophe:repo_combined$ git add .
takatoh@apostrophe:repo_combined$ git commit -m "First commit."
takatoh@apostrophe:repo_combined$ git branch -M main

リポジトリ repo_a をリモートブランチに取り込む。

takatoh@apostrophe:repo_combined$ git remote add -f repo_a https://github.com/takatoh/repo_a.git

これで、repo_combined の中には main ブランチと、全く繋がりのない repo_a/main が存在する状態になる。で、その repo_a/mainmain にマージする。

takatoh@apostrophe:repo_combined$ git merge repo_a/main
fatal: refusing to merge unrelated histories

……が、失敗した。mainrepo_a/main は全く別もので繋がりがないのでマージできない。マージするには --allow-unrelated-histories オプションをつけてやる。

takatoh@apostrophe:repo_combined$ git merge --allow-unrelated-histories repo_a/main
CONFLICT (add/add): Merge conflict in pyproject.toml
Auto-merging pyproject.toml
Automatic merge failed; fix conflicts and then commit the result.

pyproject.toml にコンフリクトが発生したので、解消してやる。

takatoh@apostrophe:repo_combined$ code pyproject.toml
takatoh@apostrophe:repo_combined$ git add pyproject.toml
takatoh@apostrophe:repo_combined$ git commit -m "Merge repository 'repo_a/main'."

これで repo_a/main のマージが完了。根元が別のコミットツリーが合流するという、ちょっと不思議な感じのするツリーが出来上がる。

つぎは repo_b。これも同じようにすればいい。

takatoh@apostrophe:repo_combined$ git remote add -f repo_b https://github.com/takatoh/repo_b.git

リモートブランチ repo_b/main に取り込んだら、main にマージ(--allow-unrelated-histories をつけて)。

takatoh@apostrophe:repo_combined$ git merge --allow-unrelated-histories repo_b/main
CONFLICT (add/add): Merge conflict in pyproject.toml
Auto-merging pyproject.toml
CONFLICT (add/add): Merge conflict in poetry.lock
Auto-merging poetry.lock
CONFLICT (add/add): Merge conflict in .gitignore
Auto-merging .gitignore
Automatic merge failed; fix conflicts and then commit the result.

当然のようにコンフリクトが発生する(今度はファイル3つ)ので解消してやる。

poetry.lock のコンフリクトを解消するのは厄介だけど、そもそもこのファイルは人間が編集するようなものじゃないので、あとで poetry install で作り直せばすむ。ここでは内容の整合は無視して、とにかくコンフリクトを解消してやればいい。

takatoh@apostrophe:repo_combined$ git add .gitignore
takatoh@apostrophe:repo_combined$ git add pyproject.toml
takatoh@apostrophe:repo_combined$ git add poetry.lock
takatoh@apostrophe:repo_combined$ git commit -m "Merge repository 'repo_b/main'."

で、poetry.lock をいったん削除してから poetry install

takatoh@apostrophe:repo_combined$ git rm poetry.lock
rm 'poetry.lock'
takatoh@apostrophe:repo_combined$ poetry install
takatoh@apostrophe:repo_combined$ git add poetry.lock
takatoh@apostrophe:repo_combined$ git commit -m "poetry.lock: Re-generate."

これでめでたく完了。

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分ぐらい無駄にした。

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

新しいWindows11マシン

メインじゃないほうの Windows マシンを新しくした。

本当は今年の後半まで待ちたかったんだけど(主に経済的な理由で)、Bluetooth のキーボードとマウスを認識してくれなくなってしまったので、前倒しして買い替えた。

届いたのは火曜日。今日やっと最低限のセットアップだけして、この記事を書いてる。アプリも Office と Dropbox しかインストールしてない。

ほかにやってるのは Ubuntu 22.04 LTS のダウンロード(まさに今ダウンロード中)。

なんとも内容のない記事だけど、いいんだ。書かないと今月ひとつも記事がないことにもなりかねないから。あ、でも Ubuntu のインストールをすればネタができるか。

Rocky Linuxをインストールしてみた

ローカルネットワーク上でサーバにしてた古いPCが空いたので、CentOS の代替のひとつ、Rocky Linux をインストールしてみた。

Rocky Linux の公式サイトはここ。

最新のバージョンは 8.5 で、EOL は 2029/3/31 となってる。ダウンロードページからはいくつかの種類の ISO イメージがダウンロードできるけど、DVD 版をダウンロードした。

ダウンロードした ISO イメージは USBメモリに焼いておく(この作業は Windows で)。

USB メモリから起動するとメニューが表示されるので、「Install Rocky Linux 8」を選択。インストーラは GUI で、日本語に対応してるし、マウスも使えるし、Ubuntu Server のインストールよりもやりやすい。基本的にはインストーラの指示に沿って進めていけばOK。主なところを書き出すと次の通り:

  • キーボード: 日本語
  • 言語サポート: 日本語
  • 時刻と日付: アジア/東京
  • rootのパスワード
  • ユーサーの作成: takatohを作成した
  • ソフトウェアの選択: サーバ(GUI使用)
  • Windowsファイルサーバーを追加
  • インストール先: 内蔵HDD
  • ストレージの設定: 自動設定
  • KDUMP: 有効(デフォルトのまま)
  • ホスト名: wplj

これでインストールを開始。しばらく時間がかかる。

インストールが終了したら再起動。初期セットアップの画面になるけどライセンスに同意すればいいだけ。

あらためてインストール時に作ったユーザー takatoh でログインすると、今度はユーザーの初期設定がはじまる。これもいくつか設定するだけで「使用する準備が完了しました。」となる。

別のマシンから ssh でログインできることも確認した。Samba もインストールされてるけど有効にはなってなかった。これは共有フォルダの設定とかが必要だし、そういうもんだろう。OS のインストール時についでにインストールできるだけでも楽だ。

というわけで、本格的に使うにはもっと手を入れる必要があるけど、インストール自体は簡単にできることがわかった。使ってみるかな。

Let’s EncryptとcertbotとDockerを使ってwebアプリをSSL化する

Let’s Encrypt はフリーで利用できる認証局だ。

今回はこの Let’s Encrypt を利用して、既存の web アプリを SSL 化(つまり、https://〜でアクセスできるように)してみた。

Let’s Encrypt を利用するには certbot というツールをインストールして、サーバ証明書の発行や更新ができる。だけど、webアプリやwebサーバは Docker のコンテナ上で動かしているので、せっかくだから certbot も Docker でできないかと調べてみたら、ちゃんとやり方があった。certbot は Docker Hub にイメージが公開されている。

以下、ウチのwebアプリはこのやり方でできたよ、という記録。

前提

  • 既存のwebアプリ(http://webapp.panicblanket.com/)をSSL化する
  • webアプリ、webサーバ(Nginx)は Docker コンテナ上で動いている
  • Docker と docker-compose がインストール済み

付け加えると、webアプリの / (ルート)は他のページへリダイレクトされている。ここが最初よくわからなかったところだ。

certbot を使うには、対象のサーバの / に Let’s Encrypt からアクセスできるようにしておく必要がある。というのも certbot はサーバ認証のために一時的なファイルを作って、Let’s Encrypt からアクセスできるのを確認することでサーバの存在を確認しているらしいからだ。だけど、webアプリでは他のページにリダイレクトしているので、うまく行かないんじゃないかと思っていた。

結論からいうと、webアプリのリバースプロキシになっているwebサーバをいったん停めて、認証取得用に別のwebサーバをたてることで対処することができた。

手順

大まかな手順は次の通り:

  1. 認証取得用の設定ファイルを書く
  2. 既存webアプリのリバースプロキシになってるwebサーバを停める
  3. certbot の Dockerコンテナを使って認証取得
  4. 既存のwebサーバの設定ファイルをSSL対応にして再起動

認証取得用の設定ファイル

Docker、というか docker-compose を使うので docker-compose.yml ファイルを書く。

ersion: "3"

services:
  nginx:
    image: nginx:1.19.2-alpine
    ports:
      - 80:80
    volumes:
      - ./conf.d:/etc/nginx/conf.d
      - ./html:/var/www/html
      - /etc/letsencrypt:/etc/letsencrypt
      - /var/lib/letsencrypt:/var/lib/letsencrypt

  certbot:
    image: certbot/certbot:latest
    volumes:
      - ./html:/var/www/html
      - /etc/letsencrypt:/etc/letsencrypt
      - /var/lib/letsencrypt:/var/lib/letsencrypt
    command: ["--version"]

Nginx と certbot のイメージを利用する。この Nginx は認証取得のための一時的なものだ。

で、その Nginx の設定ファイルはこう:

server {
    listen      80;
    listen      [::]:80;

    server_name webapp.panicblanket.com;

    root        /var/www/html;
}

80番ポートで待ち受けるだけ。このファイルを、docker-compose.yml ファイルからみて ./conf.d/webapp.panicblanket.com.conf に保存する。ドキュメントルートはディレクトリを作っておけば、何もなくて構わない。

認証取得

取得する前に既存のwebサーバを停めておくこと。

次に、認証用のwebサーバだけ起動する。

$ docker-compose up -d nginx

webサーバが起動したら、certbot を使って認証取得する。

$ docker-compose run --rm certbot certonly --webroot -w /var/www/html -d webapp.panicblanket.com

これで証明書が /etc/letsencrypt 以下に保存される。

確認できたら Nginx も停める。

$ docker-compose down

webアプリとサーバの設定、再起動

証明書が取得できたので、それを利用して https://〜 でアクセスできるように設定ファイルを書き換える。

まずは、Nginx のバーチャルホストの設定ファイル。

upstream webapp {
    server webapp:9000;
}

server {
    listen      80;
    listen      [::]:80;

    server_name webapp.panicblanket.com;

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen      443 ssl http2;
    listen      [::]:443 ssl http2;

    server_name webapp.panicblanket.com;

    ssl_certificate     /etc/letsencrypt/live/webapp.panicblanket.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/webapp.panicblanket.com/privkey.pem;
    ssl_session_timeout 1d;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_tickets off;

    ssl_protocols TLSv1.3 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;

    access_log /var/log/nginx/webapp.panicblanket.com.access.log main;
    error_log  /var/log/nginx/webapp.panicblanket.com.error.log warn;

    keepalive_timeout     60;
    proxy_connect_timeout 60;
    proxy_read_timeout    60;
    proxy_send_timeout    60;

    location / {
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Host  $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_pass       http://webapp;
    }
}

80番ポートにアクセスしてきたらすべて https://~ にリダイレクトしている。

あと、docker-compose.yml(の該当部分)。

  httpserver:
    image: nginx:1.18.0
    container_name: httpserver
    restart: always
    ports:
      - 80:80
      - 443:443
    volumes:
      - /home/takatoh/docker-environment/nginx/etc:/etc/nginx/conf.d
      - /home/takatoh/docker-environment/nginx/log:/var/log/nginx
      - /etc/letsencrypt:/etc/letsencrypt

443番ポートと /etc/letsencrypt を追加。

これでコンテナを再起動すればOK。

$ docker-compose restart webapp httpserver

参考にしたページ