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 コマンドが使えるようになった。

モニタなしでUbuntu Serverを起動する

新しい PC に Ubuntu Server をインストールしてから、もう3週間以上も経ってしまった。モニタなしで起動させるのにだいぶ苦労したけど、なんとか解決した。

どういうことかというと、インストールが問題なく終わって別の PC から SSH で接続できるのを確認したあと、もう必要ないと思ってモニタとキーボードを外して電源を入れても OS が起動しないのだ。

モニタを繋いでいれば1分もかからないくらいでちゃんと起動するのに、モニタなしだとダメ(キーボードはなくても大丈夫だった)。たっぷり5分は待ってみても SSH で接続できないし、ping も返ってこない。この状態でモニタを接続すると、起動プロセスのログ(っていうのか?)が流れて、やがてログイン待ち画面になる。どうもモニタが繋がってないせいで起動プロセスの何処かで止まってるみたいに見える。

ググってみると、GRUB っていうブートローダの設定を変えたらモニタなしでも起動できた、というブログ記事をいくつか見つけた。ただ、Ubuntu のバージョンが古かったり Raspberry Pi での話だったりして、Ubuntu Server 20.04 でも同じなのかわからなかった。とはいえ、ほかに手がかりもないので試してみた。でもダメ。そうこうしてるあいだに(週末しか作業ができなかったとはいえ)3週間以上も時間が過ぎてしまった。

で、今日見つけた情報でやっと解決したわけだ。それがこれ、Ubuntu 日本語フォーラムのページ。

このページを参考にして GRUB の設定を変更したらうまく行った。

GRUB の設定は /etc/default/grub ファイルを編集して行う。結果として次のようにした。

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="nomodeset"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

もとのファイルと diff を取るとこう(.orig がついてるのがもとのファイルのコピー)。

takatoh@navanax:~$ diff /etc/default/grub.orig /etc/default/grub
11c11
< GRUB_CMDLINE_LINUX=""
---
> GRUB_CMDLINE_LINUX="nomodeset"

/etc/default/grub ファイルを修正したら、これを反映するために sudo update-grub コマンドを実行する。

takatoh@navanax:~$ sudo update-grub

で、再起動する。

これでモニタなしでも起動するようになった。

いやー、時間がかかった。というか、モニタなしで使うことも多いであろう Server 版なのになんでモニタなしで起動できない設定になってるの?今まで使ってた Desktop 版(16.04 や 18.04)はモニタなしでもそのままでちゃんと起動してるのに。