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)はモニタなしでもそのままでちゃんと起動してるのに。

Ubuntu Server 20.04.1 LTSのインストール

ローカルネットワークのサーバ OS 一新計画、その第一弾。新しく購入した PC に Ubuntu Server 20.04.1 LTS をインストール。

今回は先日作った USB メモリのインストールメディアからインストールした。今までは DVD を使ってたけど特に変わったことはない。もっと前から USB メモリにしときゃよかった。

Ubuntu Server のインストールは初めて。インストーラが GUI じゃないけど、基本的には Desktop 版と同じような手順。ただ一点、デフォルトでは LVM(後述)が有効になってて、使えるディスクスペースが小さい。なので LVM を無効にしてインストールをやり直した。

  • 言語の選択肢に日本語がないので「English」を選択
  • Guided storage configuration の画面で「Set up this disk as LVM group」のチェックを外す
  • ユーザー名とホスト名入力
  • 途中で OpenSSH をインストールできる
  • SSH のキーを GitHub から取得できる
  • Featured Server Snaps の画面でいろいろ追加インストールできるようだけど Docker だけ選択

ほかはデフォルトのまま。最後にリブートして終了。

LVM

LVM というのは Logical Volume Manager の略で、日本語でいうと「論理ボリュームマネージャー」。複数の物理ボリューム(HDDやSSD)をまとめてひとつの論理ボリュームを作る機能だ。本格的なサーバなんかを運用するときには、あとからディスクを追加しても LVM があれば既存の論理ボリュームを大きくすることができたりするらしいので、そういうのには便利なんだろう。だけど個人で使うだけのサーバでは不要と言っていい機能だ。なしでいいと思う。↓ここの記事が参考になった。

ローカルネットワークのサーバを置き換えるんだけど、古いRailsアプリはどうすりゃいいんだ……

置き換え用にと新しく買ったサーバ用の PC が明日届く、とメールがきた。まあ、届いたからって平日なのですぐに作業できるわけでもないんだけど……

それはさておき。現状でローカルネットワークで運用してるサーバ3台を順繰りに押し出すように置き換えていって、最後に押し出される一番古い PC は万が一のときの予備にまわす。この際だからサーバは全部 Ubuntu Server 20.04 に統一しようと、すでにインストールメディアの準備は済んでいる。

で、さて。その一番古いサーバでもいくつかの web アプリを動かしているんだけど、そのひとつがだいぶ前に Ruby on Rails で作ったものなんだ。なんと Rails 4.1.4。ちなみに OS やなんかのバージョンは次の通り:

  • Ubuntu 16.04
  • Ruby 2.3.1
  • Ruby on Rails 4.1.4
  • unicorn 5.4.1

これを最新の Ubuntu 20.04 の環境に置き換えようとしてるんだけど……

とにかく、開発用マシン(Ubuntu 20.04,Ruby 2.7.1)で動かせるかどうか試してみたら、案の定ダメだった。アプリを動かすどころか bundle install の途中でコケる。どうも json とか therubyracer の gem をインストールするところでうまく行かないみたいだ。なら DockerHub にある Ubuntu 公式イメージの一番古いバージョン 16.04 の上でならどうか、と試してみたけどやっぱりダメ。

新しい OS のサーバに移行するのに合わせてアプリもバージョンアップしなきゃな、とは思ってたんだけど、開発環境で動作させられないんじゃそれも難しい。どうすりゃいいんだか…… 

USBメモリにUbuntuのインストールメディアを作る

CentOS 8 の開発終了のニュースを受けて、ローカルネットワークのサーバ OS を置き換える計画をしてる。Ubuntu をインストールして使ってるサーバもバージョンが 16.04 で EOL が今年の4月と迫っている。そういうわけなので、この際まとめて Ubuntu 20.04 LTS に置き換えようと考えた。

今日はその準備としてインストール用メディアを作る。これまではダウンロードした ISO イメージを DVD-R に焼いてたんだけど、サーバにしてる PC は DVD ドライブついてないし(インストール時には外付けドライブを繋いだ)、せっかくなので USB メモリのインストールメディアを作ってみることにした。

作業環境は次の通り:

  • 作業用マシン:Windows 10
  • インストール用USBメモリ作成:Rufus

Rufus (ルーファス) ってのは起動可能な USB フラッシュドライブを作るソフト。↓ここからダウンロードした。

同様のソフトはほかにもあるようだけど、下調べした感じではこれが一番使いやすそうだった。メニューも日本語だし。バージョンは 3.13。

USB メモリは余ってた 16GB のもの。インストール用メディアとしてはもっと容量が小さくてもよさそうだけど、余ってるんだからそれを使う。

あと、肝心の OS は、Ubuntu Server 20.04.1 LTS。https://jp.ubuntu.com/download からダウンロードした ISO イメージを用意した。

さあ、始めよう。Rufus はインストールの必要はなく、ダウンロードしたファイルをダブルクリックして実行すればいい。

書き込み先(デバイス)と書き込む ISO イメージ(ブートの種類)の設定をしたところがこの画面。デバイスが「回復(G:) [16 GB]」ってなってるのは Windows の回復ドライブに使ってた USB メモリだから。ISO イメージは「選択」ボタンをクリックしてファイルを選択した。他はデフォルトのまま。

これで「スタート」をクリックすると

と表示されて追加のファイルをダウンロードするらしい。「はい」をクリック。

これもこのまま「OK」。

最終確認。問題なければ「OK」をクリックして書き込み開始。2分ほどで終わって↓の画面になる。

状態が「準備完了」になってるけど、これで書き込み終了してる。

試しに作ったばかりの USB メディアから PC を起動してみたら、ちゃんと Ubuntu のインストーラが起動した。

というわけで今日の任務完了。

Docker上のMediaWikiにファイルをアップロードする

公式の Docker イメージを使って立てた MediaWiki だけど、ファイルをアップロードするにはやっぱりひと手間必要だった。なので、そのメモ。

MediaWiki にはファイルをアップロードする機能があるけど、デフォルトでは無効になっている。有効にするには MediaWiki と PHP 自体の設定ファイルを修正する必要がある。

  • LocalSettings.php – MediaWiki の設定ファイル
  • php.ini – PHP 自体の設定ファイル

どこをどう修正すればいいかはマニュアルに書いてある。

LocalSettings.php

LocalSettings.php ファイルは、MediaWiki をセットアップしたときにホストにダウンロードして、Docker コンテナには volume としてマウントしてあるので、ホスト側のファイルを編集すればいい。

$wgEnableUploads = true;

$wgEnableUploads に true を設定。

php.ini

で、問題はこっち。php.ini ファイルは MediaWiki の公式 Docker イメージに含まれてるものをそのまま使ったので、ホスト側にはない。なので、まずはコンテナの中で編集して、動作が変わるかどうか確認することにした。

takatoh@wplj $ docker exec -it wiki bash
root@bd8268684983:/var/www/html# php -i | grep php.ini
Configuration File (php.ini) Path => /usr/local/etc/php

php.ini ファイルの場所は php -i コマンドで確認できる(と MediaWiki のマニュアルに書いてある)。このコマンドの出力は結構な量を吐くので grep で php.ini にヒットする行だけ抜き出した。ともあれ、/usr/local/etc/php にあることがわかった。

ところが、そこに php.ini ファイルはなかった。

root@bd8268684983:/var/www/html# cd /usr/local/etc/php
root@bd8268684983:/usr/local/etc/php# ls
conf.d  php.ini-development  php.ini-production

そういうものなのかと疑問に思いながらも、ひとまずは php.ini-production ファイルの中身を見てみようとしても less コマンドがない。

root@bd8268684983:/usr/local/etc/php# less php.ini-production
bash: less: command not found

当然のように vim もない。cat はあったので中身は見れたけど編集はできない。

といわけで、方針を変更してファイルをホスト側にコピーして編集し、LocalSettings.php ファイルと同様にコンテナにマウントすることにした。ファイルをホスト側にコピーするのは次の通り:

takatoh@wplj $ docker exec -it wiki cat /usr/local/etc/php/php.ini-production > php.ini

cat コマンドをコンテナ側で実行して、ホスト側の php.ini ファイルへリダイレクトしている。

で、その php.ini ファイルを編集。3行続けて載せたけど、ファイル中では別々のところにある。

file_uploads = On
post_max_size = 16M
upload_max_filesize = 8M

file_uploads は元から On になってた。post_max_size と upload_max_filesize はそれぞれ 8M2M だったのを大きくした。

docker-compose.yml

編集した php.ini ファイルを LocalSettings.php ファイルと同じディレクトリに配置したら、コンテナにマウントすべく docker-compose.yml を修正。

  wiki:
    image: mediawiki:1.35.0
    container_name: wiki
    restart: always
    depends_on:
      - mysql
    volumes:
      - /home/takatoh/var/wiki/images:/var/www/html/images
      - /home/takatoh/var/wiki/LocalSettings.php:/var/www/html/LocalSettings.php
      - /home/takatoh/var/wiki/php.ini:/usr/local/etc/php/php.ini
    ports:
      - 9090:80

これでOK。

最後にコンテナを起動しなおしたら、無事、ファイルをアップロードできるようになった。

JavaScript: アロー関数で再帰

あけおめ、ことよろ。

正月早々、奇妙なものを見つけた。元記事は去年(というか昨日)のもので、タイトルの通りなんだけど、こんなのだった。

> const fibonacci = ((fb = n => n > 1 ? n * fb(n - 1) : 1) => fb)();

どう見ても階乗を求める関数なのに名前が fibonacci っておかしいだろ、というのは置いといて。確かに期待通りに動作する。

> fibonacci(5);
120 

元記事の説明によると:

  • アロー関数 n => n > 1 ? n * fb(n - 1) : 1 を変数 fb に代入し
  • その代入した関数を即時関数によって関数 fb として返すように
  • 代入(fibonacci)する

となってて、まあその通りではある。でも、その即時関数っていうのが単に引数をそのまま返してるだけなんだから、それ、いらねんじゃね?

というわけで即時関数なしでやってみると、やっぱり、ちゃんと期待通りに動作するじゃん。

> const fact = n => n > 1 ? n * fact(n - 1) : 1;
undefined
> fact(5);
120 

と、ここまで書いて気がついた。上では即時関数が云々と書いたけど、要するにその即時関数の引数であるアロー関数を変数 fb に代入してそれを呼び出してるだけだ。即時関数は何の関係もない。元記事の筆者がどこでネタを仕入れたのか知らないけど、不必要にトリッキーなだけだ。それとも以前のバージョンの JavaScript ではこう書かなきゃできなかったのかな。

ちなみに確認したのは Node v14.15.3。

takatoh@montana: takatoh > node -v
v14.15.3

というわけで、元記事から得たものといえば、関数呼び出しの引数部分に代入式が書けることか。使うかな、これ。

あ、あと、ブログのネタにはなった。

ReactのuseState、useEffectにハマる

……いや、React というより Fetch API のせいなのかもしれない。

ここのところで React で web アプリを作ってる。例によって自分で使うためだけのもの。

JSON を返す API を2つバックエンドに置いて、両方から取ってきたデータを合わせて表示する Collections コンポーネントを書いてたんだけど、いい書き方がわからずにハマった。

Collections コンポーネントは次のように動作する(のを期待している)。

  • 一方のAPIからコレクションのリストを取得する
  • リスト中のコレクションそれぞれについて、もう一方のAPIから詳細を取得する
  • 2つのAPIから取得したデータを合わせて、コレクションのリストとしてテーブル表示する

コレクションというのは、プログラミングにおけるデータ構造のことじゃなくて買い集めたコレクション(CDとかDVDみたいな)のこと。renderCollections 関数でレンダリングしているテーブルの行のうち、collection.id と collection.buy_date が一方のAPIから取得したデータ、collection.title と collection.brand がもう一方のAPIから取得したデータだ。

import React, { useState, useEffect } from 'react';
import Table from '@material-ui/core/Table';
import TableBody from '@material-ui/core/TableBody';
import TableCell from '@material-ui/core/TableCell';
import TableContainer from '@material-ui/core/TableContainer';
import TableHead from '@material-ui/core/TableHead';
import TableRow from '@material-ui/core/TableRow';
import Paper from '@material-ui/core/Paper';


const Collections = (props) => {
  const perPage = 10;
  const [collections, setCollections] = useState([]);
  const [currentPage, setPage] = useState(0);

  const page = props.query.page ? parseInt(props.query.page) : 1;
  useEffect(
    () => {
      setPage(page);
      const offset = perPage * (page - 1);
      let colls = [];
      const fetchProduct = async (coll) => {
        const result = await fetch(`${props.api2Endpoint}/products/${coll.product_id}`)
          .then(response => response.json())
          .then(data => data["products"][0]);
        colls = [...colls, {...coll, title: result.title, brand: result.brand.name}];
        setCollections(colls);
      };
      const fetchData = async () => {
        const result = await fetch(`${props.api1Endpoint}/collections?limit=${perPage}&offset=${offset}`, { mode: "cors" })
          .then(response => response.json())
          .then(data => data["collections"]);
        for (const c of result) {
          fetchProduct(c);
        }
      };
      fetchData();
    },
    []
  );

  return (
    <div>
      <h2>Collections</h2>
      <TableContainer component={ Paper }>
        <Table aria-label="collection table">
          <TableHead>
            <TableRow>
              <TableCell>ID</TableCell>
              <TableCell>Title</TableCell>
              <TableCell>Brand</TableCell>
              <TableCell>Buy date</TableCell>
            </TableRow>
          </TableHead>
          <TableBody>
            { renderCollections(collections) }
          </TableBody>
        </Table>
      </TableContainer>
    </div>
  );
}

const renderCollections = (collections) => {
  return (
    collections.map(collection => (
      <TableRow key={ collection.id }>
        <TableCell>{ collection.id }</TableCell>
        <TableCell>{ collection.title }</TableCell>
        <TableCell>{ collection.brand }</TableCell>
        <TableCell>{ collection.buy_date }</TableCell>
      </TableRow>
    ))
  );
}


export default Collections;

いろいろググりながらなんとか書いた上のコードで一応動くようにはなった。けど、表示されるコレクションの順番が不定になってしまう。APIからリストを取得した段階では ID 順に並んでいるのは確認したので、たぶん、個々の詳細データを取得する fetchProduct 関数内でリスト(変数 collections)を更新するタイミングのせいだ。つまり、ループの中で使ってる fetch 関数が非同期なせいだ(たぶん)。

あぁ、JavaScript ってこういうところがなんかやりづらいんだよなぁ。

なんかいい書き方はないものか。あとからソートすればいいのはわかるんだけど。

CentOS8終了

今頃気づいたんだけど、CentOS 8 が開発を終了するんだと。今月8日付のブログで発表されてる。

日本語のニュースやブログ:

今後、プロジェクトは CentOS Stream の開発に注力し、CentOS 8 は2021年末でサポートを終了とのこと。

ウチのローカルネットでは CentOS 8 のサーバを1台運用してるけど、まだ1年ちょっとしか経ってない。CentOS Stream は Red Hat Enterprise Linux(RHEL)と Fedora の中間に位置する、RHEL の開発ブランチという位置づけなので、今までの CentOS のかわりというわけにはいかない。さくらインターネットで借りてる VPS が CentOS なので慣れるためもあって運用してたけど、もう Ubuntu に統一するかな。

なお、CentOS 7 のサポートは2024年6月30日まで。