Matsup's blog

web ページで「二重の取り消し線」を書きたい！

2023-11-30T23:16:00.008+09:00

今回はちょっと趣きが違う投稿をしよう。

　今回のお題はタイトルにあるように，web ページ上の文章の一部に「二重取り消し線」をつけるやり方，である。

　二重ではない取り消し線は，以前なら

<s>...</s>

のように書いていた。でも，最近は css を使うので，web ページのヘッダー部にスタイルを記載するか，

<span style="XXXX">....</span>

のように「span」として記載するか，になる（と思っている）。ちなみに

<div style="XXXX">....</div>

だと前後に改行が入るので，文章の途中なら「span」の方がいいと思う。

　さて，本題の「二重取消線」だが，まず，取り消し線はスタイルとして，

<span style="text-decoration:line-through;">XXXX</span>

としてすると「取り消し線」が引かれる。
　◯ 取り消し線の例です

しかし，これはまだ二重になっていない。二重にするには，

<span style="text-decoration:line-through double;">XXXX</span>

とする。他のパターンも含めて例を示そう。
　◯ 二重取り消し線の例です：double
　◯ ダッシュ取り消し線の例です：dashed
　◯ 点線の取り消し線の例です：dotted
　◯ 波線の取り消し線の例です：wavy
　◯ 普通の取り消し線の例です：solid

さらに以下のようにすると色もつけられる。

<span style="text-decoration:line-through double red;">XXXX</span>

とする。「#XXXXXX」形式の色の指定もできるみたい。
　◯ 赤色の二重取り消し線の例です：double red
　◯ 青色の二重取り消し線の例です：double blue
　◯ 緑色の二重取り消し線の例です：double green
　◯ ピンク？の二重取り消し線の例です：double #FF2288
　◯ ピンク？の波線の取り消し線の例です：wavy #FF2288

お試しあれ

FreeBSD で「libssl.so.11」がないからアプリが実行できない，と言われた

2023-10-17T23:41:00.005+09:00

2023年10月15日に FreeBSD 上のアプリケーションのアップデートをしていたら，急に多くのアプリケーションが動かなくなった。その顛末を書こう。

　きっかけは FreeBSD 上で portupgrade をしたことに始まる。このパターンは結構多い。今回は，実はアップデート自体には全く問題はなかった。しかし，その後，急に多くのアプリが動かなくなった。吐き出すエラーは

ld-elf.so.1: /usr/local/lib/libssl.so.11: version XXXXXX required by YYYYYY not found

という感じのもの（ここで XXXXXX や YYYYYY はバージョンやこのライブラリを使ってるアプリやら別のライブラリやら）

これが1個や2個ならいいが，サーバーによってはルート権限で実行もできなくてほとほと困ってしまった。

ちょっと調べると，この「libssl.so.11」は「openssl-1.1.1w」でインストールされるものだった。これは，FreeBSD では「/usr/ports/security/openssl111/」でインストールできる。実は少し前までは「openssl」といえばこのバージョンだったが，ちょっと前にデフォルトバージョンが「3.0.x」に変わっていた。そのため，openssl をアップデートした際に，v.1.1.1w から v.3.0.x に上がってしまい，ライブラリが libssl.so.12 になっていた。結果として openssl-1.1.1w でインストールされた libssl.so.11 を使ってるアプリケーションソフトでエラーが起こったみたい。

そこで，どのアプリが libssl.so.11 を使っているかをチェックしてみた。それには以下のようにする。

# pkg shlib -qR libssl.so.11
libevent-2.1.12
librtmp-2.4.20190330
rtmpdump-2.4.20190330
python27-2.7.18_2
p5-Net-SSLeay-1.92
w3m-0.5.3.20230129
..........

しかし，これでは libssl.so のバージョンがわからない。そこで，以下のようにすると libssl.so のバージョンもわかる。

# find /usr/local/bin -type f | xargs -n1 file -F ' ' | grep 'ELF.*dynamically' | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep libssl.so
/usr/local/bin/gdcmgendir libssl.so.11
/usr/local/bin/lynx libssl.so.11
/usr/local/bin/gdcmpap3 libssl.so.11
/usr/local/bin/gnmanalyse libssl.so.11
..........

検索するディレクトリとしては，この「/usr/local/bin/」以外に「/usr/bin/」や「/usr/sbin/」，「/usr/local/sbin/」などもあるが，ports からインストールした openssl を使っているのは，「/usr/local/bin/」と「/usr/local/sbin/」だけだった。他は「libssl.so.111」となっていて，FreeBSD のシステムからのライブラリを使っているみたいだった。

今回は ports からインストールした openssl のバージョンと，その依存関係にあるアプリケーションの指定する openssl のバージョンが違っていたのが問題だった。その根本的な解決は，以下のようにアプリケーションを強制的に作り直さないと仕方ない。ここでは「libssl.so.11 (openssl-1.1.1w) に依存しているアプリを強制的にアップデート（再インストールになるかな？）している。

# portmaster -f `pkg shlib -qR libssl.so.11`

あるいは

# portupgrade -f `pkg shlib -qR libssl.so.11`

とする。どちらを使うかは好みだが，「portupgrade」を使う場合には，「export BATCH=yes」としておくと，いちいち config の設定をしなくていいから楽チンかもしれない。「portmaster」なら「-DG」のオプションを付けるといいかも。

アップデートはある程度時間がかかるが，基本的には放置すればいいはず…。

FreeBSD で zfs ファイルシステムに M.2 NVMe SSD を追加した

2023-10-09T13:45:00.003+09:00

2023年9月に FreeBSD で使用している「zfs」に M.2 NVMe 接続の SSD を追加した。その件についてメモを兼ねて書いておこう。

　1個前の投稿で，zfs ファイルシステムのアップグレードの話を書いた。 zfs ファイルシステムのアップグレードは，実は今回の M.2 NVMe 接続の SSD を追加の際に必要になったので行ったのだった。一部重複する内容もあるが，あまり気にしないでおこう。

　SSD の追加が必要になった理由は，使用している 2.5 inch の SSD の容量が心もとなくなってきたから，である。 Note PC をサーバーとして使い，そのストレージに 1TB の 2.5 inch SSD を使っているが，写真やらを大量に置いていると徐々に SSD の容量を圧迫してきた。実質 920GB ほどの領域で，空きが 180GB 程度になっていた。これはちょっと心もとない。ということで，ストレージを増やすことにした。

　今使ってる Note PC には空いている NVMe のスロットがあるので，新たに NVMe の SSD を追加することにした。そうすると 2.5 inch SSD は特に何もしなくていい。特に「zfs」を使ってるので拡張も簡単やし…。そこで 1TB の M.2 NVMe SSD を買って追加することにしたのだった。

M.2 NVMe 接続の SSD の追加

　具体的な（物理的な）M.2 NVMe 接続の SSD の追加についてはここでは書かないでおこう。写真とか撮ってないし…。 NVMe SSD は思ったよりも小さい印象がある。2.5 inch SSD よりも小さい（細長く薄っぺらい）印象がある。

zfs について

　zfs に関しては前回の投稿を見てほしいが，複数のデバイス（複数の HDD や複数の SSD など）をストレージに使う際に，見た目は全体として1個のファイルシステムとして（全体を1個のプール (pool)として）扱えるところが便利である。言い換えると「プール」という大きな HDD が1個あるような感じであり，その中に物理的なデバイスを追加して，複数の（1個でもいいが）HDD や SSD で1個のプールを構成している。今回も M.2 NVMe SSD を追加して，それを既存のプールに追加するだけだった。

　まずは現時点での状況の確認。プールのリストを調べるために「zpool list」を使うと，

# zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zroot   920G   741G   179G        -         -    50%    80%  1.00x    ONLINE  -

ここで「zroot」というのがプールの名前。使用できる容量が 920GB に対して，741GB を使用して，結果として 179GB の空きスペースしかない。容量の 80% を使っている。さすがにこれはちょっと厳しい。

　次に zroot プールの状況を「zpool status」コマンドで把握した。

# zpool status zroot
  pool: zroot
   state: ONLINE
   config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          ada0p4    ONLINE       0     0     0

errors: No known data errors

問題はない（というか，ここで zfs のアップグレードが必要だったので前回の投稿を書いたんだけどね）。

M.2 NVMe をプールに追加する

　どんな物理デバイスが接続されているかを「geom disk list」コマンドで見てみると…，

# geom disk list
Geom name: nvd0
Providers:
1. Name: nvd0
   Mediasize: 1000204886016 (932G)
   Sectorsize: 512
   Mode: r0w0e0
   descr: CT1000P1SSD8
   lunid: ......（よくわからないけど，念のため隠しておいた）
   ident: ......（よくわからないけど，念のため隠しておいた）
   rotationrate: 0
   fwsectors: 0
   fwheads: 0

Geom name: ada0
Providers:
1. Name: ada0
   Mediasize: 1000204886016 (932G)
   Sectorsize: 512
   Mode: r2w2e3
   descr: Samsung SSD 860 EVO 1TB
   lunid: ......（よくわからないけど，念のため隠しておいた）
   ident: ......（よくわからないけど，念のため隠しておいた）
   rotationrate: 0
   fwsectors: 63
   fwheads: 16

となった。ここで「nvd0」が NVMe に接続された1個目の（0番の）デバイスを意味し，「ada0」はシリアル ATA（SATA）に接続されている0番のデバイスを示している。ちなみに USB 接続すると「da0」のようになる。ちゃんと NVMe SSD も認識されている。

　各デバイスには適度にパーティションを切らないといけない。 NVMe SSD はまだ何もないので，まずはパーティションを切ろう（作ろう）。今回 NVMe SSD は1個の大きな zfs パーティションのみとしてみた。

# gpart delete -i 1 nvd0
# gpart delete -i 2 nvd0
# gpart add -t freebsd-zfs nvd0

実はこの「nvd0」と認識されているデバイス（SSD）は他で一度使ったものなので，2個のパーティションが存在していた。そこで，まずその2個のパーティションを「削除」している。その後，「zfs パーティション」を「追加」した。「gpart show nvd0」コマンドで結果を見ると，

# gpart show nvd0
=>        34  1953525101  nvd0  GPT  (932G)
          34  1953525101     1  freebsd-zfs  (932G)

となった。ちゃんとパーティションが作られている。

　ここで，「nvd0」(NVMe 接続の SSD) に boot 領域（freebsd-boot や efi 領域）を追加してはいけない。最初からつけてある「ada0」（SATA 接続の 2.5 inch SSD）というデバイスに boot 領域（パーティション）があるので，そことけんかするみたいで，起動時にうまく起動しない時があった。注意が必要。

　次に「nvd0」のパーティション 1 にファイルシステムを構築する。特にファイルシステムの種類を指定はしていないが，パーティションを作る時に zfs を指定してるのでこれでいいみたい。

# newfs -U /dev/nvd0p1
/dev/nvd0p1: 953869.7MB (1953525096 sectors) block size 32768, fragment size 4096
        using 1526 cylinder groups of 625.22MB, 20007 blks, 80128 inodes.
        with soft updates
super-block backups (for fsck_ffs -b #) at:
 192, 1280640, 2561088, 3841536, 5121984, 6402432, 7682880, 8963328, 10243776, 11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912, 20487360, 21767808, 23048256, 24328704, 25609152, 26889600, 28170048, 29450496, 30730944,
........

この数字はかなりたくさん出てくる。ここでは省略したけど…。

　あとはこれを「zroot」という名前のプールに追加するだけである。まずは以下で（「-n」オプションをつけて）ドライランさせて，エラーが起きないかを確認しておく。ドライランは，ほぼ同じ動作をするけど，最後の書き込みをしないんだっけ？

# zpool add -n zroot nvd0p1

　エラーがなければ実際に「nvd0p1」パーティションを「zroot」プールに追加しよう。

# zpool add zroot nvd0p1

結果は「zpool list」コマンドと「zpool status zroot」コマンドで見ると，

# zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zroot  1.80T   741G  1.08T        -         -    24%    40%  1.00x    ONLINE  -

# zpool status zroot
  pool: zroot
 state: ONLINE
config:
        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          ada0p4    ONLINE       0     0     0
          nvd0p1    ONLINE       0     0     0

となり，ちゃんと「zroot」プールに「nvd0」のパーティション 1 が追加され，プール全体のサイズも大きくなっている。

結果の確認

　最終的なパーティションの構成は「gpart show」コマンドで見ると，

# gpart show
=>        34  1953525101  nvd0  GPT  (932G)
          34  1953525101     1  freebsd-zfs  (932G)

=>        40  1953525088  ada0  GPT  (932G)
          40      409600     1  efi  (200M)
      409640        1024     2  freebsd-boot  (512K)
      410664         984        - free -  (492K)
      411648    20971520     3  freebsd-swap  (10G)
    21383168  1932140544     4  freebsd-zfs  (921G)
  1953523712        1416        - free -  (708K)

となっている。

　より具体的なプールの内容については「zfs list」というコマンドを使う。以下は M.2 NVMe SSD (1TB) を追加した後の結果である。

# zfs list
NAME                                           USED  AVAIL     REFER  MOUNTPOINT
zroot                                          741G  1.02T       88K  /zroot
zroot/ROOT                                    60.5G  1.02T       88K  none
zroot/ROOT/default                            60.5G  1.02T     15.4G  /
zroot/ezjail                                   604G  1.02T      136K  /usr/jails
zroot/ezjail/basejail                         2.72G  1.02T     1.93G  /usr/jails/basejail
zroot/ezjail/jail                              601G  1.02T      601G  /usr/jails/jail
zroot/ezjail/newjail                          28.5M  1.02T     26.4M  /usr/jails/newjail
zroot/tmp                                      672K  1.02T      672K  /tmp
zroot/usr                                     76.2G  1.02T       88K  /usr
zroot/usr/home                                55.3G  1.02T     55.3G  /usr/home
zroot/usr/ports                               19.5G  1.02T     19.5G  /usr/ports
zroot/usr/src                                 1.43G  1.02T     1.43G  /usr/src
zroot/var                                      580M  1.02T       88K  /var
zroot/var/audit                                 88K  1.02T       88K  /var/audit
zroot/var/crash                                 88K  1.02T       88K  /var/crash
zroot/var/log                                 3.65M  1.02T     3.65M  /var/log
zroot/var/mail                                 575M  1.02T      575M  /var/mail
zroot/var/tmp                                  132K  1.02T      132K  /var/tmp

ここで「zroot」プールの中に沢山のスライスがあるが，それらはシステムが勝手に作ってるみたい（私は何もしていない）。これを見ると，web site を入れている jail システムの newjail が 600GB も使っている…。写真とか動画を載せすぎやなぁ…。

ちなみに「df」コマンドでは以下のように見える。

# df -h
Filesystem               Size    Used   Avail Capacity  Mounted on
zroot/ROOT/default       1.0T     15G    1.0T     1%    /
devfs                    1.0K    1.0K      0B   100%    /dev
/dev/da0p2               1.8T    729G    931G    44%    /San2TBSSD
zroot/tmp                1.0T    672K    1.0T     0%    /tmp
zroot/usr/home           1.1T     55G    1.0T     5%    /usr/home
zroot                    1.0T     88K    1.0T     0%    /zroot
zroot/var/log            1.0T    3.7M    1.0T     0%    /var/log
zroot/ezjail             1.0T    136K    1.0T     0%    /usr/jails
zroot/usr/src            1.0T    1.4G    1.0T     0%    /usr/src
zroot/var/crash          1.0T     88K    1.0T     0%    /var/crash
zroot/var/mail           1.0T    576M    1.0T     0%    /var/mail
zroot/usr/ports          1.0T     19G    1.0T     2%    /usr/ports
zroot/var/audit          1.0T     88K    1.0T     0%    /var/audit
zroot/var/tmp            1.0T    132K    1.0T     0%    /var/tmp
zroot/ezjail/jippo       1.6T    601G    1.0T    36%    /usr/jails/jippo
zroot/ezjail/basejail    1.0T    1.9G    1.0T     0%    /usr/jails/basejail
zroot/ezjail/newjail     1.0T     26M    1.0T     0%    /usr/jails/newjail
/usr/jails/basejail      1.0T    1.9G    1.0T     0%    /usr/jails/jippo/basejail
devfs                    1.0K    1.0K      0B   100%    /usr/jails/jippo/dev
fdescfs                  1.0K    1.0K      0B   100%    /usr/jails/jippo/dev/fd
procfs                   4.0K    4.0K      0B   100%    /usr/jails/jippo/proc

　これで無事にサーバーのストレージの容量を増やすことができた。

FreeBSD で zfs をアップグレードした際に efi boot 領域を作り直した

2023-10-09T10:55:00.007+09:00

2023年9月に FreeBSD で使用している「zfs」に M.2 NVMe 接続の SSD を追加した。その際，「zfs」ファイルシステムのアップグレードが必要であり，かつ元からあった 2.5 inch SSD の efi boot 領域を作り直さないといけなかった。その件についてメモを兼ねて書いておこう。

　そもそも，なぜ zfs のアップグレードが必要になったというと，使用している 2.5 inch の SSD の容量が心もとなくなってきたから，だった。現在，当該の FreeBSD は L社の Note PC に入っているが，HDD は遅いので SSD に置き換えている。その際，1TB の 2.5 inch SSD を入れたのだが，web サーバーに写真やらを大量に置いていると徐々に SSD の容量を圧迫してきた。実質 920GB ほどの領域で，空きが 180GB 程度になっていた。さすがにこれはちょっと心もとない。ということで，ストレージを増やすことにした。

　ストレージを増やすには，一つの手段として 2.5 inch SSD をより大きな容量のものに変更する，という手が考えられる。しかし，それだと新しい SSD にシステムを入れ直して，データも移動させないといけない。それは手間がかかる。一方，現在使っている Note PC には空いている NVMe のスロットがある。それなら新たに NVMe の SSD を追加することもできる。 M.2 NVMe を追加するなら 2.5 inch SSD は特に何もしなくていいことになる。データの移動もさせなくてもいい。そこで 1TB の M.2 NVMe SSD を買って追加することにした。（M.2 NVMe SSD の追加の話は次の投稿で書くことにする）

　ところで，現在 FreeBSD を入れているサーバーは，ファイルシステムとして「zfs」を使っている。これはもともと Oracle 社の Solaris 用に開発されたものみたい。 zfs の便利な点は，複数のデバイス（複数の HDD や複数の SSD など）をストレージに使う際に，見た目は全体として1個のファイルシステムとして扱える点が挙げられる。そのため，どんな物理デバイスがどのように使われているか，をあまり意識しなくていい。デバイスを追加する際にも，いちいちスライスを切り直したりしなくてもいい。また，既存のシステムのデバイスを交換する際にも，物理的にデバイスを接続した後の処理がシステムを止めずにできる。デメリットとしては，ファイルシステムの管理用にある程度 CPU の能力を使う点が挙げられるが…。

　今回は既存のシステムに M.2 NVMe SSD を追加するだけなので，zfs の利点を活かせることになる。そこで，まずは現時点での状況を確認してみることにした。 zfs では物理的に異なる HDD や SSD の代わりに「プール（pool）」という概念がストレージの単位として使われる。言い換えると「プール」という大きな HDD が1個あるような感じである。そのため，まず「プール」を1個作り，その中にデバイスを追加して，複数の（1個でもいいが）HDD や SSD で1個のプールを構成する。

　zfs の状況を把握するにはいくつか有用なコマンドがあるが，まずはどんなプールがあるかを調べるには「zpool list」を使う。

# zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zroot   920G   741G   179G        -         -    50%    80%  1.00x    ONLINE  -

ここで「zroot」というのがプールの名前であり，「zroot」という大きな HDD が1個あるイメージである。使用できる容量が 920GB に対して，741GB を使用して，結果として 179GB の空きスペースがある。つまり，容量の 80% を使ってしまっている。これはそろそろストレージを拡張しないといけないことを示している。

　zroot プールの状況を把握するには「zpool status」コマンドを使う（これは zfs のアップグレード後のもの）。

# zpool status zroot
  pool: zroot
   state: ONLINE
   config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          ada0p4    ONLINE       0     0     0

errors: No known data errors

ここでは「zroot」プールに，「ada0p4」が使われている。この「ada0p4」は，「ada0」デバイスのパーティション 4番を意味している。「ada0」デバイスは SATA 接続のデバイスを意味し，ここでは 2.5 inch SSD をつないでいる。また「ada0p4」の「p4」は「4番目のパーティション」を意味している。パーティションについては後で書こう。

この「zpool status」コマンドを使った結果が，今回は以下のようになった。

# zpool status zroot
  pool: zroot
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
        The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          ada0p4    ONLINE       0     0     0

errors: No known data errors

問題がない場合の結果（上記の結果）と比べると「status」と「action」なる項目が増えてる…。そこを読むと，どうやら「zfs をアップグレードせよ」と書いてある。

　そこで zfs をアップグレードしてみたのが今回のお話のメイン。

zfs のアップグレード

　zfs をアップグレードするには

# zpool upgrade -a

または

# zpool upgrade zroot

を使う。結果は，

# zpool upgrade -a
This system supports ZFS pool feature flags.

Enabled the following features on 'zroot':
  large_dnode
  userobj_accounting
  encryption
  project_quota
  spacemap_v2
  allocation_classes
  resilver_defer
  bookmark_v2
  redaction_bookmarks
  redacted_datasets
  bookmark_written
  log_spacemap
  livelist
  device_rebuild
  zstd_compress
  draid

Pool 'zroot' has the bootfs property set, you might need to update
the boot code. See gptzfsboot(8) and loader.efi(8) for details.

どうやらアップグレードは正常に終わったけど，まだ「boot code のアップデートが必要」みたい。

boot code のアップデート

　boot code のアップデートについて調べると，まずは UEFI から起動しているのか，昔からの BIOS を使っているのか，で多少異なるみたいだった。そこでまずは使われている物理デバイス（ここでは 2.5 inch SATA 接続 SSD）のパーティションがどうなっているかを見てみる。そのためには「gpart show」コマンドを使う。

# gpart show
=>        40  1953525088  ada0  GPT  (932G)
          40      409600     1  efi  (200M)
      409640        1024     2  freebsd-boot  (512K)
      410664         984        - free -  (492K)
      411648    20971520     3  freebsd-swap  (10G)
    21383168  1932140544     4  freebsd-zfs  (921G)
  1953523712        1416        - free -  (708K)

ここで左端の数字はパーティションの先頭のセクター番号を表し，左から2番目の数字が各パーティションの容量，「ada0」の下にある3番目の数字がパーティション番号を示している。ここではパーティション 1 が UEFI 起動に使われる efi 領域で，パーティション 2 に boot 領域 (freebsd-boot 領域) がある。パーティション 3 はスワップ領域で，パーティション 4 が zfs のデータ領域となっている。「- free -」となっている所は，サイズの都合で何にも使われていない「隙間」である。
　ここでは efi 領域があるので，このシステムでは UEFI 起動に対応している。ちなみに UEFI は「Unified Extensible Firmware Interface」のことらしい。 GUID Partition Table (GPT) と呼ばれる種類のパーティションで使えるらしい。

　boot code のアップデートは，まず以下の「gpart bootcode」コマンドを実行する。

# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0
partcode written to ada0p2
bootcode written to ada0

ここでは「ada0」デバイスのパーティション 2 番に boot code を書き込んでいるみたい。

　さらに efi パーティションのコードも更新しないといけないらしい。手順は，efi 領域のパーティション 2 をマウントして，boot code をコピーしてからアンマウントするみたい。というのでやってみたが，以下のように「エラー」がでてしまった。

# mount -t msdosfs /dev/ada0p1 /mnt
# cp -p /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
overwrite /mnt/EFI/BOOT/BOOTX64.efi? (y/n [n]) y
cp: /boot/loader.efi: Input/output error
[1]    58508 exit 1     cp -i -p /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
# umount /mnt

これは何？と思い，いろいろやってみたが，どうも 512 バイト以上は書き込めない状態になっているみたいだった。 efi 領域は 200 MB も取ってあるのに？？？

　そこで，下記のように efi パーティションを一度消してから作り直し，その後で boot code をコピーにしてみた。

# gpart delete -i 1 ada0
# gpart add -t efi -b 40 -s 409600 ada0
# newfs_msdos -F 32 -c 1 -L EFISYS /dev/ada0p1
/dev/ada0p1: 403266 sectors in 403266 FAT32 clusters (512 bytes/cluster)
BytesPerSec=512 SecPerClust=1 ResSectors=32 FATs=2 Media=0xf0 SecPerTrack=63 Heads=16 HiddenSecs=0 HugeSectors=409600 FATsecs=3151 RootCluster=2 FSInfo=1 Backup=2

まずは efi パーティションを削除し，「gpart show」コマンドで見た結果と同じサイズでパーティション 1 に efi パーティションを作る。そして最後に efi パーティションに msdos ファイルシステムを構築している。パーティションを作ってもファイルシステムを構築しないとストレージとしては使えないのが注意点である。またサイズは「409600」よりも「409560」の方が余分な「隙間」ができなくていいらしいが，ここでは既存のものを置き換えるので「409600」としている。

それから以下のように boot code をコピーしたらうまくいった。

# mount -t msdosfs /dev/ada0p1 /mnt
# mkdir /mnt/efi
# mkdir /mnt/efi/boot
# cp /boot/loader.efi /mnt/efi/boot/BOOTx64.efi
# echo "BOOTx64.efi" > /mnt/efi/boot/startup.nsh
# chmod 755 /mnt/efi/boot/startup.nsh
# umount /mnt

まずパーティション 1 (efi パーティション) をマウントし，そこに「/efi/boot/」というディレクトリを作っている。そこに「/boot/loader.efi」をコピーして「BOOTx64.efi」という名前にしている。さらに同じディレクトリに「startup.nsh」なるファイル（中身は BOOTx64.efi だけ）を置き，実行可能としてある。 startup.nsh はほんとに必要かどうかわからないが，既存のシステムに存在していたので作っておいた。

最後に

　これで「zfs」ファイルシステムのアップグレードができた。ちゃんと再起動できることも確認しておいた。そこで，次に Note PC に M.2 NVMe 接続の SSD を追加してみた（次回へ）

GNSS (GPS) データから距離を求める

2023-05-24T20:13:00.010+09:00

ここ数回続けて GNSS (GPS) 関連の投稿をしている。今回は GNSS (GPS) のデータから距離を求める話を書こう。

　距離については，以前 GPS 経路データから求めた距離の誤差についてというのを書いた。その時は六甲全山縦走路の距離に関して，GNSS (GPS) で得られた経路の距離の誤差について考えたものだった。今回は，距離の求め方について書こうと思う。ま，ほとんどどっかのサイトの受け売りやけどね。

　地図上の距離を求めるには定規で測って縮尺を考えて距離を出す，というのも考えられるが，GNSS (GPS) で経路を記録していると，緯度＋経度，という情報が得られる。そこで，2点間の緯度と経度の情報を使って距離を求める，というのが今回のお話し。

緯度の経度について

　まず，距離を求める前に緯度と経度の話を書こう。
緯度は英語で「Latitude」，経度は「Longitude」と言う。なので，計算スクリプトで lat やら Lat やらとあれば「緯度」を示し，lng や Lng, 場合によっては lon や Lon とあれば「経度」を表していると考えて欲しい。ちなみに「高度」は「Altitude」が使われることが多い（と思う）。

　緯度と言えば「北緯 35度25分50秒」，経度と言えば「東経 135度15分44秒」みたいなのを思い浮かべるかもしれないが，分，秒を用いると計算がややこしくなる。そこで，ここではこれ以降，緯度，経度は「度」で表し，細かいところは小数で表すことにしよう。つまり「北緯 35.430556，東経 135.262222」みたいに表すことにする。

　また，測地系としては「WGS84」を用いる。測地系は，地球上の場所の座標であり，いわゆる緯度，経度である。しかし，その基準をどうとるか（地球をどんな楕円体で近似するか，原点をどこにとるか）などで異なるみたい（それ以上はわかっていないかも…）。今使われているのは GRS80 と呼ばれるもの（1980年に決められたもの。多分，微妙な補正が入ってる思うけど）である。しかし，GPS 業界では WGS84 が用いられている。GRS80 と WGS84 の違いは，扁平率の微妙な違いみたい。どちらも，楕円体の長半径は 6,378,137 m なのだが，扁平率が GRS80 は 1/298.257 222 101 なのに対して，WGS84の扁平率は 1/298.257 223 563 らしい。分母の小数点以下4桁目からが違っている。微妙やなぁ…。具体的に短半径を書くと，GRS80 が 6,356,752.314 140 m なのに対し，WGS84 が 6,356,752.314 245 m となる。こんな微妙な違いなので，実用上は同じとして問題ない。なお，昔の（2002年4月1日以前の）日本の測地系は，日本独自の日本測地系（旧日本測地系、Tokyo Datum）というものが使われていたので，古い資料を見る際には注意が必要である。

　座標を表す場合，緯度と経度の順が違う場合がある。地理院地図では「緯度」が先みたいだが，私はあまり細かいことは気にしていない。基本的に日本国内の位置情報を考えているので，100 を越えていたら経度（東経）で，20〜40 ぐらいなら緯度（北緯）と思っている。計算のスクリプトを書く際には，どちらを先にするかを決めておかないといけないけどね。当然，逆の順に入力された際の処理を加えておくのがよさげである。

ヒュベニの公式

　まずはヒュベニの公式を書こう。原理のようなものに関しては，ネット上で検索してみてほしい。一応，Perl のスクリプトを書いておこう。

    my $long_r = 6378137.000;     # [m] 長半径 GRS80 と WGS84 で共通
#    my $short_r = 6356752.314140; # [m] 短半径 GRS80
    my $short_r = 6356752.314245; # [m] 短半径 WGS84
    my $rishin = sqrt(($long_r**2 - $short_r**2)/$long_r**2); # 第一離心率
    my $a_e_2 = $long_r*(1-$rishin**2);  # a(1-e^2)
    my $pi = 3.14159265358979;    # Pi

    $lat0 = $lat0*$pi/180;  # in radian
    $lng0 = $lng0*$pi/180;  # in radian
    $lat1 = $lat1*$pi/180;  # in radian
    $lng1 = $lng1*$pi/180;  # in radian

    my $d_lat = $lat1 - $lat0;
    my $d_lng = $lng1 - $lng0;
    my $ave_lat = ($lat1+$lat0)/2;

    my $W = sqrt(1-$rishin**2*sin($ave_lat)*sin($ave_lat));
    my $N = $long_r/$W;
    my $M = $a_e_2/$W/$W/$W;

    my $dist = ($d_lat*$M)**2 + ($d_lng*$N*cos($ave_lat))**2; # square of distance
    $dist = sqrt($dist);

　ここで，$lat0, $lng0 が始点の位置座標であり，$lat1, $lng1 が終点の座標である。それをラジアンに変換して計算に用いている。最後の $dist が求める2点間の距離となっている。

測地線航海算法

　次に測地線航海算法について書こう。これも比較的簡単に距離が求められるものである。ただし，計算に tan, arccos (acos) と arctan (atan) を用いるので，Perl の場合は事前に Math モジュールを読み込んでおかないといけない。

use Math::Trig qw/tan atan acos/;

　距離を求める部分を以下に書いておこう。

    my $long_r = 6378137.000;     # [m] 長半径 GRS80 と WGS84 で共通
#    my $short_r = 6356752.314140; # [m] 短半径 GRS80
    my $short_r = 6356752.314245; # [m] 短半径 WGS84
    my $pi = 3.14159265358979;    # Pi
# 扁平率
    my $FF = ($long_r - $short_r)/$long_r;
# 度(deg) → radian
    $lat0 = $lat0*$pi/180;  # in radian
    $lng0 = $lng0*$pi/180;  # in radian
    $LAT1 = $LAT1*$pi/180;  # in radian
    $LNG1 = $LNG1*$pi/180;  # in radian
# 化成精度（phi）
    my $phi0 = atan($short_r/$long_r * tan($lat0));
    my $Phi1 = atan($short_r/$long_r * tan($LAT1));
# 球面上の距離 (len)
    my $XX = acos( sin($phi0)*sin($Phi1) + cos($phi0)*cos($Phi1) * cos($lng0 - $LNG1) );
# 距離補正量 (delta_rho)
    my $delta_rho = $FF/8 * ( (sin($XX) - $XX) * (sin($phi0)+sin($Phi1))**2 / cos($XX/2)**2
                  - (sin($XX) + $XX) * (sin($phi0) - sin($Phi1))**2 / sin($XX/2)**2);
# 測地線距離 (m)
    my $dist = $long_r * ($XX + $delta_rho);

　最後の行の $dist が求める2点間の距離である。ここで $LAT1, $LNG1 のように大文字を使っているが，これは単にパッと見て $lat0, $lng1 と区別しやすいようにしただけで，それ以上の意味はない。

ヒュベニの公式と航海算法の比較

　ここで，上記の2つの方法を地理院の提供している距離計算のページの結果と比べてみよう。地理院のページを使う際には，測地系は「GRS80」とし，「十進法度単位」を選んでおこう。

(1) 長距離の場合（1000 km 程度）

　まずは南北方向の場合を見るために，千葉県銚子市のポートタワー付近と，北海道稚内の国道の終点との距離を見てみよう。ここでは，念のために測地系として GRS80 と WGS84 の両方の結果を書いている。

銚子 (35.740961,140.862912) -- 稚内 (45.417198,141.676276)
    地理院：1076.697201 km
WGS84
  ヒュベニ：1076.70987537832 km  相対誤差：0.001177 %
  航海算法：1076.69573094928 km  相対誤差：-0.000136 %
---------------------------------------------------------
GRS80
  ヒュベニ：1076.70987536532 km  相対誤差：0.001177 %
  航海算法：1076.69573093629 km  相対誤差：-0.000136 %

上記の結果を見ると，まず，GRS80 と WGS84 は実用上は全く差がないことがわかる。ここには書いていないが，他にもいろいろ比較したが，GRS80 と WGS84 の間にほぼ差はなかった。そこで，これ以降は WGS84 の結果のみを記載しよう。また，ヒュベニの公式と航海算法にも大差ないが，どちらかというと航海算法の方が誤差が少ないことがわかる（地理院のページの計算に比べて，やけどね）。どうも距離が長い（100 km より十分長い？）と，航海算法の方が精度がいいみたい。

　次に東西方向のケースとして，銚子と対馬の間の距離を見てみよう。

銚子 (35.740961,140.862912) -- 対馬 (34.202710,129.287673)
    地理院：1070.069226 km
  ヒュベニ：1070.73123142042 km  相対誤差：0.061865 %
  航海算法：1070.06913218936 km  相対誤差：-8e-06 %

　ここでは航海算法の方はほぼ誤差なしだが，ヒュベニの公式の方は誤差が少し増えている。南北方向（銚子--稚内）だとあまり差がなかったのに，東西方向（銚子--対馬）で差が出るのは，ヒュベニの公式は距離が長くなると，東西方向の方がより誤差が大きいことを示している。

　ここでは2例しか示していないが，原理的に距離が長いと，南北，東西に関わらず，ヒュベニの公式よりも航海算法の方が精度がいいみたい。

(2) 中距離の場合（10 km 〜 100 km 程度）

　次に条件を変えて，10 km 〜 100 km 程度の距離の場合を見てみよう。まずは南北方向。ここでは上記の東京都庁付近から，宇都宮の東武宇都宮駅前までの距離を計算させている。

東京都庁--東武宇都宮駅
     地理院：98.126294 km
   ヒュベニ：98.126361841262 km   相対誤差：6.9e-05 %
   航海算法：98.1261650663422 km  相対誤差：-0.000131 %

これを見るとヒュベニの公式と航海算法の間にあまり差はない（細かい違いはあるが，実用上は差がないレベル，という意味）。

次に東西方向として，東京都庁から甲州市塩山駅前までの距離を見てみる。

東京都庁--甲州市塩山駅
     地理院：86.658714 km
   ヒュベニ：86.659057410539 km   相対誤差：0.000396 %
   航海算法：86.6587135069539 km  相対誤差：0 %

ここでもヒュベニの公式と航海算法にはあまり差がない。多少航海算法の方がよさげではあるが…。

念のために少し距離を短くしたものも示そう。

東京都庁--さいたま県庁
    地理院：18.983221 km
  ヒュベニ：18.9832215547376 km  相対誤差：2e-06 %
  航海算法：18.983195965596 km   相対誤差：-0.000131 %

(3) 短距離の場合（100 m 以下程度）

　次に極端に条件を変えて，100 m 以下程度の距離の場合を見てみよう。まずは南北方向。ここでは上記の東京都庁付近の data（35.68944,139.691670）を用い，緯度の数字の小数点以下4桁目をいじって2点を作っている。

東京都庁付近 南北方向（35.68944 <-> 35.68964）
    地理院：0.022191 km (22 m)
  ヒュベニ：0.0221906511971943 km  相対誤差：-0.001571 %
  航海算法：0.0221908520376506 km  相対誤差：-0.000666 %

次に東西方向。今度は経度の数値の小数点以下4桁目をいじっている。

東京都庁付近 東西方向（139.691670 <-> 139.691770）
    地理院：0.0090516 km (9 m)
  ヒュベニ：0.00905158702795335 km  相対誤差：-0.000143 %
  航海算法：0.00905143839182423 km  相対誤差：-0.001785 %

　この場合，ヒュベニの公式と航海算法の間に大差はないように見える。

　もう一桁距離を近づけてみると，以下のようになった。

東京都庁付近 南北方向（35.68944 <-> 35.68946）
    地理院：0.0022191 km (2.2 m)
  ヒュベニ：0.0022190650867564 km  相対誤差：-0.001573 %
  航海算法：0.00221993984116535 km  相対誤差：0.037846 %

# 東京都庁付近　東西方向（139.691670 <-> 139.691690）
    地理院：0.0018103 km (1.8 m)
  ヒュベニ：0.00181031740559067 km  相対誤差：0.000961 %
  航海算法：0.0018082906698376 km  相対誤差：-0.110994 %

　これを見ると，極端に短距離の場合は，ヒュベニの公式の方が航海算法よりも精度がよさそうな感じに見える。まぁ，2 m 程度となると，使っている GNSS (GPS) ロガーの精度よりよくなるので，そこまで必要なのか？という気もするが…。

ということで，今回のまとめとしては，たかだか2例ずつしか示せていないし，あくまで地理院のサイトの計算が正しいとしての結果だが，
　(1) 長距離（100km 以上など）では，航海算法の方が精度がよさそう。
　(2) 極端な短距離（100m 以下など）では，ヒュベニの公式の方が精度が良さそう。
ということになった。

　考えてみれば，航海算法は遠くの港に行くための計算なので，あまり短距離は使わないから，長距離で精度がいいのは正しいことかもしれない。しかし，私は登山で歩いた際の GNSS (GPS) のログから距離を出したいので，その場合はヒュベニの公式を使おうかな？と思ってる。

SparkFun GNSS NEO-M9N + OpenLog Artemis で構成した GNSS ロガーのログ

2023-05-23T21:18:00.014+09:00

前回の投稿で，SparkFun 製の GNSS NEO-M9N ユニットと SparkFun 製の OpenLog Artemis で作った GNSS ロガーのことを書いた。今回のその GNSS ログについて書こうと思う。

　SparkFun 製 OpenLog Artemis は，Microcontroller の Apollo 3 Blue MCU を持つ Artemis Module で構成されたログ記録用のユニットである。それに SparkFun 製の GPS Breakout - NEO-M9N, U.FL (Qwiic) という GNSS ユニット，LiPo バッテリーを組み合わせると簡単に GNSS ロガーができる。SW をつなげる以外はほぼコネクタをつなげるだけ，でできる。

　その場合の GNSS のログは，OpenLog Artemis にプログラムされている形式で記録される。以下にその例を示そう。

rtcDate,rtcTime,aX,aY,aZ,gX,gY,gZ,mX,mY,mZ,imu_degC,gps_Date,gps_Time,gps_Lat,gps_Long,gps_Alt,gps_SIV,gps_FixType,gps_GroundSpeed,gps_Heading,gps_pDOP,output_Hz,
01/01/2000,00:10:25.74,326.66,-913.57,-221.19,0.18,0.60,-0.25,-3.60,-5.10,-16.95,35.70,05/16/2023,05:58:15.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
01/01/2000,00:10:26.74,330.08,-923.34,-224.61,0.47,0.60,3.05,-3.30,-3.75,-18.90,35.46,05/16/2023,05:58:16.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
01/01/2000,00:10:27.75,326.66,-936.04,-217.29,-1.44,1.17,0.04,-4.20,-5.85,-13.05,35.46,05/16/2023,05:58:17.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
01/01/2000,00:10:28.75,330.57,-926.27,-238.77,-0.29,-1.0,-0.70,-2.85,-4.05,-15.15,35.46,05/16/2023,05:58:18.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
01/01/2000,00:10:29.76,330.08,-916.50,-208.50,0.27,-1.14,-0.30,-5.40,-4.35,-16.50,35.41,05/16/2023,05:58:19.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
01/01/2000,00:10:30.76,330.57,-923.34,-209.96,-1.18,1.53,-0.24,-4.20,-4.80,-15.90,35.70,05/16/2023,05:58:20.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
....
01/01/2000,00:37:46.67,320.80,-581.05,-425.29,-12.73,-6.39,-8.52,-23.55,6.45,-9.60,39.63,05/16/2023,06:25:37.000,348934290,1355106946,144510,0,0,0,25642680,9999,0.984,
01/01/2000,00:37:47.68,96.19,-470.70,-528.81,7.64,-4.62,-11.46,-20.70,9.0,-7.50,39.15,05/16/2023,06:25:38.000,348934290,1355106946,144510,0,0,0,25642680,9999,0.985,
01/01/2000,00:37:48.69,259.28,-1590.33,-871.58,-7.19,-3.47,-32.61,-24.0,14.25,-12.45,39.39,05/16/2023,06:25:39.000,348934290,1355106946,144510,0,0,0,25642680,9999,0.985,
01/01/2000,00:37:49.69,217.29,-411.13,-810.06,-6.67,21.91,39.07,-32.55,23.40,-10.35,39.24,05/16/2023,06:25:40.000,348934290,1355106946,144510,0,0,0,25642680,9999,0.985,
01/01/2000,00:37:50.70,490.72,-383.30,-527.83,10.15,1.86,14.40,-36.45,22.95,-18.30,39.48,05/16/2023,06:25:41.000,349718091,1358144528,145559,4,2,2749,25642680,258,0.985,
01/01/2000,00:37:51.71,259.77,-958.01,-951.66,-42.80,8.94,6.55,-43.95,24.0,-18.30,39.29,05/16/2023,06:25:42.000,349718458,1358144645,140839,7,3,1830,14312410,261,0.985,
01/01/2000,00:37:52.71,272.46,-431.15,-659.18,30.15,-22.78,-44.46,-37.65,23.85,-22.05,39.48,05/16/2023,06:25:43.000,349718704,1358143742,135256,7,3,1194,14318840,261,0.985,
01/01/2000,00:37:53.72,159.67,-394.53,-519.04,4.99,20.63,9.93,-33.45,21.75,-25.80,39.39,05/16/2023,06:25:44.000,349719339,1358143424,121481,9,3,890,13825742,240,0.985,
01/01/2000,00:37:54.73,-4.39,-623.05,-746.09,-17.57,28.05,82.57,-47.70,23.10,-20.70,39.39,05/16/2023,06:25:45.000,349719530,1358143564,118751,12,3,484,13825742,176,0.985,
01/01/2000,00:37:55.73,195.31,-1654.79,-700.20,5.57,-47.44,-106.35,-36.0,26.55,-22.20,39.48,05/16/2023,06:25:46.000,349719732,1358143546,113840,13,3,879,16785064,167,0.985,
01/01/2000,00:37:56.74,434.57,-520.02,-1026.86,-32.24,-12.02,4.37,-43.35,22.65,-19.50,39.29,05/16/2023,06:25:47.000,349719762,1358143542,110599,13,3,1022,17545512,167,0.985,

　このケースでは，OpenLog Artemis (IMU ユニット付）の IMU ユニットの「加速度，ジャイロスコープ，方位磁場」の値も記録されている。データはテキストファイルで micro SD カードに記録される。データは CSV 形式（コンマで区切られたデータ）で記録されている。最初の行に各データの名前が記されており，最初の２個は RTC (Real Time Clock) のデータ（日付と時刻）である。次に加速度のデータ (aX, aY, aZ)，ジャイロスコープのデータ (gX, gY, gZ)，磁場のデータ (mX, mY, mZ)，温度のデータ (imu_degC) が並んでいる。それ以降は GNSS 関連のデータとなっている。

　GNSS (GPS) のデータは，順に，日付，時刻，Latitude (緯度)，Longitude (経度)，Altitude (高度)，SIV (Satellite in View)，FixType (衛星捕捉状態)，水平速度，方位，pDOP (Position Dilution of Precision), 出力レート (Hz) である。

各データの単位は https://github.com/sparkfun/OpenLog_Artemis/blob/main/SENSOR_UNITS.md に記載がある。
(1) 日付と時刻は UTC (Coordinated Universal Time，協定世界時) であり，JST (Japan Standard Time, 日本標準時) にするには 9時間 (32,400 秒) を足さないといけない。
(2) Latitude と Longitude は 10^-7 倍すると通常の緯度，経度になる。例えば Longitude = 1358144528 なら，東経 135.8144528 度を意味する。
(3) Altitude は mm 単位なので 10^-3 を掛けると m 単位になる。
(4) SIV は捕捉している衛星の数であり多い方が位置の精度が高くなる。
(5) FixType は 0 - 5 の数字であり，0:No detection, 1:Dead Reckoning Only (推測航法のみ), 2:2D, 3:3D, 4:GNSS + Dead Reckoning, 5:Time Only となっているらしい。この中では「3:3D」がいいような気がする。
(6) 速度は mm/s 単位なので 10^-3 を掛けると m/s 単位になる。
(7) 方位は 10^-5 を掛けたものが北を 0 度する角度（単位は度）である。右回りに測るので，東が 90 度，南が 180 度，西が 270 度となる。
(8) pDOP は位置の精度を示す指標であり，記録された値に 10^-2 を掛けたものが pDOP の値となる。この数値は小さい方が位置の精度がより良いことを示す。得られたデータの最初の方は pDOP = 9999 (*10^-2) が並んでいる。そこでは SIV = 0, FixType = 0, 速度 0 mm/s となっている。これは SW を入れた直後は衛星を捕捉できてないことを意味し，位置情報にはほぼ意味がないことを示している。 Wikipedia によると，通常は pDOP は 1 以上の数字であり，1〜2 なら位置の精度が Excellent，2〜5 なら Good，5〜10 なら Moderate，11〜20 で Fair，20 以上で Poor らしい。上記の例だと　最後の3行は pDOP = 1.76, 1.67, 1.67 となっていて，位置精度が Excellent ということを示している。
(9) 出力レートは，記録の出力の頻度であり，この例だと1個のデータを記録するのに 1.015 秒なしは 1.016 秒かかってることを示している（はず）。

　ちなみに ICM ユニット（ICM-20948 IMU）のデータの単位は，加速度がミリg（g は重力加速度），ジャイロスコープは度/秒 (deg/sec)，方位磁場は μT (micro Tesla)，温度は ℃ (摂氏) である。

後は，この「1秒ごとのデータ」を適度に間引けば GNSS のログとして使えることになる。

SparkFun GNSS NEO-M9N と SparkFun OpenLog Artemis で GNSS ロガーを作った（ほぼ線をつないだだけやけど…）

2023-05-17T22:14:00.057+09:00

久々の投稿の気がするが，まぁ，気にしないでおこう。

　今回は GNSS ロガーを組み上げた，というお話し。組み上げたと言っても，Qwiic というシステムのケーブルでつないだだけ，という工作ともなんとも言えない話になっている。ま，一応，いろいろとあるので備忘録を兼ねて書いておこうと思ったのが今回の投稿。

　まず，GNSS ロガーについてだが，これは GPS ロガーとほぼ同義語として使ってる。 GPS というのはアメリカが開発した衛星測位システムであり，同様の衛星測位システムとして，ヨーロッパの Galileo，ロシアの GLONASS，中国の北斗 (BeiDou) や，日本のみちびき (QZSS) などがあり，その総称として GNSS (Global Navigation Satellite System) が使われているので，ここでは GNSS ロガーと記載している。

　これまでも登山の行動経路の記録のために GPS ユニットや GNSS ユニットと SparkFun 製 OpenLog（シリアル通信上に流れてきたデータを単純に記録し続けるユニット）を組み合わせたお手製の GNSS ロガーを作ってきた。
・Gms-g9 を使った GNSS ロガーに挑戦してみた
・GNSS ロガー (Gms-g9 使用) の2号機を作る
・ランニングエレクトロニクス社製 Gms-g9 基板使用 GNSS ロガー 3号機の製作
など…。

　しかし，それらも徐々にヘタってきた。GNSS ユニットがヘタったというよりは，基板のはんだ付けやら，基板用のミニスイッチなどがヘタってきた感じで，うまくログを記録できないケースも出てきた。そこで新しくなにかできないか？と思っていた時に見つけたのが SparkFun 製 OpenLog Artemis と SparkFun 製の GPS Breakout - NEO-M9N, U.FL (Qwiic) だった（NEO-M9N Breakout board は，Chip Antenna がついたものや，SMA コネクターのものもある）。

　この OpenLog Artemis と NEO-M9N board は Qwiic という接続システムを搭載しており，Qwiic 専用のケーブル（50mm，100mm，など）を使えば，はんだ付けなしでコントローラーとセンサー類を接続できる。そこで，今回はこれを使って GNSS ロガーを作ってみた。

OpenLog Artemis

　OpenLog Artemis は，Artemis Module という ARM 製 Cortex-M4 Processor を持つ Microcontroller の Apollo 3 Blue MCU で構成され，Qwiic で接続されたセンサー類からのデータを Micro SD カードに記録できるモジュールである。Bluetooth 5 も搭載している（今のところ日本の無線基準認証を受けておらず，技適マークが付いていない。そのため Bluetooth を使うと法律違反になるかもしれないので注意が必要）。ボード上の回路は 3.3V で駆動されているため省電力タイプとなっている。電源としては 3.3V 〜 6.5V で動作可能であり，LiPo バッテリー（リチウムポリマーバッテリー）で駆動できるのみならず，LiPo バッテリーの充電もできる仕様となっており，OpenLog Artemis があれば，携帯したり，移動する機器につけた状態で種々のセンサー類のログを取ることができるすぐれものである。USB Type-C コネクターで LiPo バッテリーの充電や，コンピューターとつないで制御も可能となっている。

　また 9軸 (9 DoF = Degree of Freedom) の IMU ユニット (ICM-20948 のチップ) がついている（IMU ユニットなしのものもある）。ICM-20948 は 3軸の加速度センサー，3軸のジャイロセンサー，3軸の磁気方位センサー，さらに温度センサーもついている。そのため模型飛行機などにつけておくと，飛行データを記録することもできる。

　なお，今は SparkFun DataLogger IoT - 9DoF という製品もあるのだが，ちょっと大きいみたい。ただ，コントローラーとして無線 LAN のついた ESP32-WROOM-32E Module を使っているので，日本国内の認証が取れているという安心感はあるが…。

OpenLog Artemis の使い方は OpenLog Artemis Hookup Guide を見れば書いてあるが，かいつまんで書いておくと，
(1) 電源が供給されれば Processor がオンとなり，記録を始める。必要なら「PSWC」端子にスイッチを接続して，電源のオン／オフができる。

(2) micro SD card は FAT32 と exFAT に対応している（Firmware のバージョンによるが）。

(3) Firmware Update は AFU (Artemis Firmware Uploader) を使い，最新版の Firmware の binary file を Artemis にアップロードする。V2.3 以降だと「NoPowerLossProtection」とあるものの方が使いやすいかもしれない。

(4) Artemis モジュールの設定は「Terminal」系ソフトで可能である。Hookup Guide には，Tera Term や Real Term，Cool Term が紹介されているが，Windows の PuTTY や Mac のターミナルソフトでも接続可能である。いずれの場合も「OpenLog Artemis をオン」にしておかないといけない。具体的には PSWC 端子に SW を付けた場合に，SW がオフだと Artemis は反応しない。

Windows の PuTTY でつなぐ場合は OpenLog Artemis がオンの状態で「Serial」通信を選び，ボーレートを 115200 とし，適当な COM ポートを指定して接続する。COM ポートは，私の経験では COM3 や COM6 が多かった気がする。

Mac の場合は OpenLog Artemis がオンの状態でターミナルソフトを起動し

> la /dev/tty.*| grep usb

として接続した OpenLog Artemis のデバイス番号を取得する。デバイス番号は

/dev/tty.usbserial-1470

のようなものになる。デバイス番号がわかれば，

> screen /dev/tty.usbserial-1470 115200

として screen コマンドで OpenLog Artemis と接続する。

(5) 接続されると，デバイス情報を表示した後，センサーのログを表示し始める。その時に「何かキーを押す」と「メニュー」に移行する。
（以下のようなメッセージが表示されれば，接続できている）

Artemis OpenLog v2.5
Finding the next available log file.
This could take a long time if the SD card contains many existing log files.
Logging to: dataLog00001.TXT
Finding the next available log file.
This could take a long time if the SD card contains many existing log files.
Logging to: serialLog00000.TXT
SD card online
Data logging online
Serial logging online
IMU online
Identifying Qwiic Muxes...
Identifying Qwiic Devices...
Autodetect complete
GPS-ublox online at address 0x42
gps_Date,gps_Time,gps_Lat,gps_Long,gps_Alt,gps_SIV,gps_FixType,gps_GroundSpeed,gps_Heading,gps_pDOP,output_Hz,
Print GPS Timestamp / not yet implemented
08/02/2020,00:00:01.000,0,0,0,0,0,0,0,9999,2.13,
Print GPS Timestamp / not yet implemented
08/02/2020,00:00:01.300,0,0,0,0,0,0,0,9999,2.56,
.........

ここで「何かのキーを押す」と，以下のようなメニューが現れる。以下は Firmware バージョンが v2.5 のものである。

Menu: Main Menu
1) Configure Terminal Output            <-- ターミナル出力設定
2) Configure Time Stamp                 <-- 時刻表示設定
3) Configure IMU Logging                <-- IMU (Inertial Measurement Unit) 設定
4) Configure Serial Logging             <-- シリアルログ設定
5) Configure Analog Logging             <-- アナログログ設定
6) Detect / Configure Attached Devices  <-- 接続デバイス設定
7) Configure Power Options              <-- 電源オプション設定
h) Print Sensor Helper Text (and return to logging)
s) SD Card File Transfer
r) Reset all settings to default
q) Quit: Close log files and power down
x) Return to logging

1) ターミナル出力設定メニューは以下の通り

Menu: Configure Terminal Output
1) Log to microSD: Enabled                       <-- Enabled で SD カードがあれば記録される
2) Log to Terminal: Enabled                      <-- ターミナル側にログを吐き出す
3) Set Serial Terminal Baud Rate: 115200 bps     <-- 9600 なら 115200 に変更すると早くなる
4) Set Log Rate in Hz: 1.0                       <-- 10 Hz から 1.0 Hz に変更した
5) Set Log Rate in seconds between readings: 1.0
6) Enable maximum logging: Disabled
7) Output Actual Hertz: Enabled
8) Output Column Titles: Enabled
9) Output Measurement Count: Disabled
10) Open New Log Files After (s): 0 (Never)
11) Frequent log file access timestamps: Disabled
12) Use pin 11 to trigger logging: No
13) Logging is triggered when the signal on pin 11 is: Falling
14) Use TX and RX pins for Terminal: Disabled
15) Use Pin 11 to control fast/slow logging: No
17) Use RTC to control fast/slow logging: No
x) Exit

2) 時刻設定メニューは以下の通り

Menu: Configure Time Stamp
Current date/time: 05/16/2023, 00:37:51.78
1) Log Date: Enabled               <-- 日付の記録
2) Log Time: Enabled               <-- 時刻の記録
3) Set RTC to compiler macro time
4) Manually set RTC date           <-- 最初は日付を手入力した
5) Toggle date style: mm/dd/yyyy   <-- mm/dd/yyyy と dd/mm/yyyy の切替えみたい
6) Manually set RTC time           <-- 最初は時刻を手入力した
7) Toggle time style: 24 hour
8) Synchronize RTC to GPS          <-- GPS (GNSS) ユニットがあれば，GPS で取得した時刻を使う
9) Local offset from UTC: 9.00     <-- 0 から変更 (JST は UTC より「9時間進んでいる」)
10) Log Microseconds: Disabled
x) Exit

3) IMU 設定

Menu: Configure IMU
1) Sensor Logging: Enabled           <-- All センサーの ON/OFF
2) Accelerometer Logging: Enabled    <-- 加速度センサーの ON/OFF
3) Gyro Logging: Enabled             <-- ジャイロセンサーの ON/OFF
4) Magnotometer Logging: Enabled     <-- 磁気センサーの ON/OFF
5) Temperature Logging: Enabled      <-- 温度センサーの ON/OFF （温度のみ ON にしてみた(2022/4/30)）
6) Accelerometer Full Scale: +/- 2g  <-- 加速度センサーのフルスケール
7) Accelerometer Digital Low Pass Filter: Disabled  (Bandwidth is 1209 Hz (3dB) 1248 Hz (Nyquist))
9) Gyro Full Scale: +/- 250dps
10) Gyro Digital Low Pass Filter: Disabled  (Bandwidth is 12106 Hz (3dB) 12316 Hz (Nyquist))
12) Digital Motion Processor (DMP): Disabled
x) Exit

4) シリアルログ設定

Menu: Configure Serial Logging
1) Log serial data: Enabled, analog logging on RX/A13 pin disabled
2) Output serial data to TX pin: Disabled
3) zmodem start delay: 20 seconds
4) Set serial baud rate: 9600 bps
5) Add RTC timestamp when token is received: Disabled
6) Timestamp token: 10 (Decimal) = Line Feed
x) Exit

5) アナログログ設定

Menu: Configure Analog Logging
1) Log analog pin 11 (2V Max): Disabled
2) Log analog pin 12 (TX) (2V Max): Disabled
3) Log analog pin 13 (RX) (2V Max): Disabled
4) Log analog pin 32 (2V Max): Disabled
5) Log output type: Calculated Voltage
6) Log VIN (battery) voltage (6V Max): Disabled
x) Exit

6) 接続デバイス設定

Menu: Configure Attached Devices
1) u-blox GPS Receiver (0x42)                   <-- u-blox の GNSS が接続されている時のみでてくる
2) Configure Qwiic Settings                     <-- Qwiic の設定へ
3) Detect Bio Sensor Pulse Oximeter: Disabled   <-- パルスオキシメーターがあれば有効化できる
x) Exit

6-1) uBlox GPS 受信機設定（接続されている時のみ）

Menu: Configure uBlox GPS Receiver
1) Sensor Logging: Enabled
2) Log GPS Date: Enabled
3) Log GPS Time: Enabled
4) Log Longitude/Latitude: Enabled
5) Log Altitude: Enabled
6) Log Altitude Mean Sea Level: Disabled
7) Log Satellites In View: Enabled
8) Log Fix Type: Enabled
9) Log Carrier Solution: Disabled
10) Log Ground Speed: Enabled
11) Log Heading of Motion: Enabled
12) Log Position Dilution of Precision (pDOP): Enabled
13) Log Interval Time Of Week (iTOW): Disabled
14) Set I2C Interface Speed (u-blox modules have pullups built in. Remove *all* I2C pullups to achieve 400kHz): 100000
15) Use autoPVT: No
16) Reset GNSS to factory defaults
x) Exit

6-2) Qwiic 設定

Menu: Configure Qwiic Bus
1) Turn off bus power between readings (>2s): No
2) Set Max Qwiic Bus Speed: 100000 Hz
3) Set minimum Qwiic bus power up delay: 250 ms
4) Qwiic bus pull-ups (internal to the Artemis): 1.5k
x) Exit

7) 電源オプション設定

Menu: Configure Power Options
1) Turn off Qwiic bus power between readings (>2s): No
2) Use pin 32 to Stop Logging: No
3) Power LED During Sleep: Enabled
4) Low Battery Voltage Detection: Disabled
5) Low Battery Threshold (V): 3.40
6) VIN measurement correction factor: 1.470
7) Serial Tx and Rx pins during sleep are: Disabled
x) Exit

GNSS Breakout NEO-M9N

　SparkFun 製の GPS (GNSS) Breakout NEO-M9N は「u-blox 製の GNSS モジュール NEO-M9N チップ」を搭載した GNSS ボードである。NEO-M9N チップは（多くの他の GNSS チップと同様に）外部に GNSS 用のアンテナが必要である。SparkFun 製の NEO-M9N Breakout board は，Antenna 接続用 U.FL コネクタが付いたもの，GNSS 用の Chip Antenna が付いたもの，Antenna 接続用 SMA コネクタが付いたもの，の３種類ある。左の写真は左から順に U.FL コネクタタイプ，Chip Antenna タイプ，SMA コネクタタイプのものである。

　U.FL コネクターはあまり馴染みがないかもしれないが，使ってみると意外としっかりつながっている。SMA コネクターは大きくてしっかりしてそうだが，振動を与えるとネジが緩むみたいで，気づくとよく緩んでいて思ったよりも安心感に欠ける。また Chip Antenna タイプは Pulse 製の W3011 という型番の Chip Antenna が付けてある。また，U.FL コネクタタイプ，SMA コネクタタイプは，アクティブアンテナに対応している。そのためアンテナに電源を供給できるようになっている。しかしアンテナとして Passive アンテナを使うと，その電源供給が悪さをしてアンテナに過剰に電流が流れてアンテナが発熱してしまう。設定ソフトで電源をオフにできると思うのだが，いまいちどこで設定すればいいのかわからなかった。そこで仕方なく Passive アンテナ用の NEO-M9N ボードでは，アンテナへの電源供給ラインに入れてある「コイル」(回路図上の FB1) を外しておいた。「コイル FB1」は，U.FL コネクタタイプのボードを上から（部品のある面）見た時に，u-blox のチップと U.FL コネクタの間にある黒い小さなもの，である。

　今回，NEO-M9N ボードは U.FL タイプを3枚，Chip Antenna タイプを1枚，SMA タイプを1枚の合計5枚用意した。その全てに OpenLog Artemis を使っているので，実は結構な出費だったかもしれない…ははは。 U.FL タイプのものは，1個は Active アンテナ用とし，残りの2個は Passive アンテナ用として，アンテナへの電源供給ラインのコイルを外しておいた（最終的に3個ともコイルを外してしまった…(2023/11/23)）。

　また，OpenLog Artemis と NEO-M9N ボードは Qwiic ケーブルで接続し，OpenLog Artemis ボードに LiPo バッテリーをつなぎ，ON/OFF 用のスイッチを付けた。工作としてはそれだけであり，ほぼコネクタをつないだだけ，という感じになった。まぁ，コイル（チップ部品）を外したり，適当なプラスチックケースに穴を開けたりしているので，ただ単にコネクタをつないだだけじゃないんだけどね。

（下の写真：左：U.FL タイプと OpenLog Artemis を Qwiic ケーブルで繋いだもの，右：Chip Antenna タイプと OpenLog Artemis をつないだもの)
　

　Active アンテナをつないだ U.FL コネクタタイプと SMA コネクタタイプの合計2枚は，プリント基板に適当な穴をあけ，そこにボードをネジ止めしている。 U.FL コネクタタイプは，U.FL コネクタに SMA との変換用のラインをつないで，SMA コネクタを持つ Active アンテナをつないでいる。 Active アンテナの2セットは，透明な樹脂のケースに入れ，ケースを出てすぐに90度曲げるための SMA コネクタを付けている。

（左の写真：SMA タイプの NEO-M9N ボード + Active アンテナ）

　（上の写真：左 = SMA タイプの NEO-M9N ボード + Active アンテナ，右 = U.FL タイプの NEO-M9N ボード＋Active アンテナ）

　Passive アンテナをつないだ U.FL コネクタタイプ2枚と Chip Antenna タイプ，の合計3枚の NEO-M9N ボードは，OpenLog Artemis と2段重ねにしてみた。そのために OpenLog Artemis の四隅の穴に M3 (5mm長) のビス＋スプリングワッシャを入れ，その下に穴にネジを切ってある六角形の樹脂の柱（長さ 10mm）を付けた。そのうちの1本だけを使って NEO-M9N ボードにネジ止めしてある。また LiPo バッテリーを固定するのに幅広の大きめの「輪ゴム」を使っている。ちょっと不格好だが…。

　Passive アンテナは SparkFun GNSS Chip Antenna Evaluation Board のものを使った。 1号機には TE 1565-1585MHz Puck Single Band Antenna を，2号機には Molex RHCP LDS-MID GPS Antenna 146216 (Molex Cube) を使った。しかし，2号機の Molex Cube Antenna を壊してしまい，Molex Flexible GNSS Antenna - U.FL (Adhesive) に替えた。性能のほどはまだチェックできていない…。（下の写真のさらに下に「使ってみての感想」を追記した）

（左下の写真：左から順に Gms-G9 を使ったもの，1号機：U.FL タイプ，2号機：U.FL タイプ，3号機：チップアンテナタイプ）

（下の写真：OpenLog Artemis と NEO-M9N ボードを2段重ねにしたもの）

　
（下の写真：Molex Flexible GPS/GNSS Antenna をつけてみた）

使ってみての感想 (2023/11/23)

　この投稿を書いてから半年ほど経つので，どのタイプがいいかを書いておこう。

　結論から言うと「Passive アンテナをつないだ U.FL コネクタタイプの NEO-M9N ボード」が一番調子がいい。アンテナは SparkFun GNSS Chip Antenna Evaluation Board の TE Puck（TE 1565-1585MHz Puck Single Band Antenna）を使ったものが調子がいい。

　アンテナの性能としては，アクティブアンテナの方が受信面積が大きいし，受信してすぐに信号を増幅するからいいに違いない，と思っていたのだが，やはり大きすぎて持ち運びにくい。また，それなりに電力を食うのでバッテリーのもちを考えると passive アンテナの方が有利となる。また SMA コネクタはネジ式なので固く締めたつもりでもすぐにコネクターが緩んでしまい，信号が GNSS ボードに送られなくなる。その点 U.FL コネクタは「カチッ」とハマるので調子がいい。となると，U.FL コネクターを持つ GNSS ボードに passive アンテナを付けるのがよい，というのが私の結論となった。

　passive アンテナとしては SparkFun GNSS Chip Antenna Evaluation Board のものをバラして使った。まずは TE Puck と記載の TE 1565-1585MHz Puck Single Band Antenna「TE 1513634-1」と Molex Cube と記載の Molex Cube (part No.1462160001)（Molex Antenna Guide の中の「RHCP LDS-MID GPS Antenna (146216)」）を使ったが，Molex Cube を壊してしまい（四角のアンテナ部を剥がしてしまった），仕方なく小型の「PulseLarsen W3011」を使ってみた。これは Chip Antenna が付いた NEO-M9N ボードについているアンテナと同じものである。その結果，U.FL コネクタタイプの GNSS ボードに TE Puck と W3011 のアンテナを繋いだもの1個ずつ（それぞれ1号機と2号機と呼んでいる）と，W3011 チップアンテナが固定されている GNSS ボード（3号機）の，合計3個の passive アンテナ使った GNSS ボードを使用した。

　3個の passive アンテナだが，使ってみると TE Puck 以外の2個（つまり W3011 がついた2個）はなかなか GNSS を受信しない感じだった。受信しても経路を示す点のばらつきが大きく，とても使い物になる感じがしなかった。きっと私の登山スタイルだと持ち歩く際の保持の仕方がテキトーすぎて，アンテナに効率よく電波が入らなかったせいだと思う。結果的に私の登山スタイルでは，せっかく3個も持って歩いているのに，実際に使えるのは TE Puck アンテナをつけたものだけ，となってしまった。active アンテナのやつはでかすぎてそれはそれで持ちにくかったし…。

　仕方ないので SparkFun GNSS Chip Antenna Evaluation Board をもう1個買い，U.FL コネクタタイプの GNSS ボードの2個目（2号機）のアンテナも W3011 から TE Puck アンテナに換えてみた。すると2号機の GNSS ログは1号機と似たものになった。いやぁ，よかった。さらに3個目の U.FL コネクタタイプの GNSS ボード（当初4号機と呼んでいた）のコイルを外し，アンテナを Molex Cube と記載の Molex Cube (part No.1462160001)（Molex Antenna Guide の中の「RHCP LDS-MID GPS Antenna (146216)」）にしてみた（これを新しく3号機と呼ぶことにし，チップアンテナタイプの GNSS ボードを4号機と呼ぶことにした）。すると，新3号機のログは1号機や2号機と遜色ないものとなった。

　この結果を見る限りでは，結局アンテナは電波を受信する面積が大きい方がよい，という結論になった。これで U.FL コネクタで passive アンテナをつないだ 1号機から3号機までが使用に耐えるものになった。これなら簡単にはログが取れないという状況にはならないはず，である。いやぁ，よかったよかった。しばらくはこの3機体制でいけそうである。

記録されるログについては次の投稿に書こう。

FreeBSD で Python のデフォルトバージョンを変えたら py-gobject3 がうまくアップデートできなかった話

2023-03-28T10:11:00.002+09:00

久々に書き込んでいる気がする…。
　今回は FreeBSD で Python のデフォルトバージョンを変えた時のトラブルの話を書こう。

　何をしたかと言うと，FreeBSD 上のアプリケーションとしていろいろあるのだが，Python もインストールされている。 Python は Python 自体を使いたいというよりは，他のアプリケーションとの依存関係で勝手にインストールされる。ついこの間まで，なぜかうちの FreeBSD の python の default version は 3.8 に指定してあった。もう 3.11 が出てるのにね。でも，まぁ，現時点では 3.9 がまだ FreeBSD 上でのデフォルトとなってるから，そこまでひどくはないと思うけど…。ちなみに default version が 3.8 から 3.9 になったのは 2022/6/26 なんだけどね (現在は 2023/3 末)。

　なぜ急に default version をあげようと思ったかというと，ふと /usr/ports/UPDATING で python で検索したら，2022/6/26 に python の default version を 3.8 から 3.9 にした，と書いてあったから。そこで，その 2022/6/26 の記載に従って処理をしてみた。
概略は，

(1) /etc/make.conf で python のデフォルトを指定してあったのをコメントアウトした。
(2) root 権限で以下を実行した。

  # portmaster -o lang/python39 python38
  # REINSTALL="$(pkg info -o "*py38*" | awk '{printf "%s ", $2}')"
  # pkg delete -f "*py38*"
  # portmaster $REINSTALL
  # REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py39 | cut -d : -f 1 | sort -u)
  # portmaster $REBUILD
  # REBUILD2=$(pkg list | grep python-38 | xargs pkg which | awk '{print $6}' | sort -u)
  # portmaster $REBUILD2

(3) 最後に "pkg remove python38" を実行して，/usr/local/lib/python3.8/ ディレクトリになにか残ってたら手動で消す。
というもの。

　で，エラーが起こったのは（まぁ，当然といえば当然だが）(2) の実行時。その中でも「portmaster $REINSTALL」ってのを実行中にエラーがでた。これは，直前で python 3.8 で作られたアプリケーションを消し，それらを python 3.9 で（デフォルトで）作り直す，というコマンド。それが最後まで実行されなかった。見ると途中に「ERROR」という文字が見える。 portmaster というコマンドは，複数のアプリケーションのアップデートを順にやってくれるが，どれかのアップデートでエラーが起こると，その先は実行してくれない。今回見ていると，どうも「/usr/ports/devel/py-gobject3/」というアプリケーションのアップデート時にエラーを吐いていた。エラーメッセージ（一部）はこんなんやった。

ERROR: Unhandled python OSError. This is probably not a Meson bug, but an issue with your build environment.
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
===>  Script "configure" failed unexpectedly.
Please report the problem to desktop@FreeBSD.org [maintainer] and attach the
"/var/ports/usr/ports/devel/py-gobject3/work-py39/pygobject-3.42.2/_build/meson-logs/meson-log.txt"
including the output of the failure of your make command. Also, it might be
a good idea to provide an overview of all packages installed on your system
(e.g. a /usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

　見ると，「/usr/ports/devel/py-gobject3/」という文字列が目に入った。つまり「py-gobject3」のアップデートに失敗している。そこで，とりあえず環境変数「$REINSTALL」の中身を「echo $REINSTALL」として表示させ，py-gobject3 以外を portmaster でアップデートするとうまくいった。しかし，その後のプロセスで py-gobject3 を使うみたいで再びエラーがでた。

　仕方ないのでネットワークのお世話になり，検索をかけると，https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238254 というページにたどり着いた。読んでみると，どうも「/usr/ports/devel/gobject-introspection/」をインストールしなおせ，と書いてある。「pkg info -aI」として調べると，確かに「gobject-introspection-1.76.1,1」がインストールされていた。

　そこで「/usr/ports/devel/gobject-introspection/」（gobject-introspection-1.76.1,1）をインストールし直してから (make install として，重複してるとエラーがでたら make deinstall install clean とした)，「py-gobject3」を portmaster でアップデートしたらうまくいった。何がおかしいのかよくわからないが，時々起こる似たような現象がおこる。何かのサブルーチンが最新になってなかった，ということみたいやけど，それ以上はいいことにしてしまった…。

FreeBSD で libxml2 のアップデートしたら，多くのアプリケーションが動かなくなった

2022-03-26T17:35:00.014+09:00

2022年3月26日に FreeBSD 上のアプリケーションのアップデートをしていたら，急に多くのアプリケーションが動かなくなった。その顛末を書こう（まだ終わってないけど…）

　ことの起こりは FreeBSD 上で portupgrade をしたことに始まる。まぁ，ホントは他のアプリケーションのアップデートができない，といわれてごそごそやっていたのだが…。そのごそごそやっている時にメモを残しているのだが，そこで新しく emcas でファイルを作ろうと思った。そしたらいきなり

ld-elf.so.1: /usr/local/lib/libxml2.so.2: version LIBXML2_2.4.30 required by /usr/local/bin/emacs not defined

と言われてしまった。

その時点での libxml2 のバージョンは

% pkg info -aI | grep libxml2
libxml2-2.9.13                 XML parser library for GNOME
py38-libxml2-2.9.13            Python interface for XML parser library for GNOME
py38-lxml-4.8.0                Pythonic binding for the libxml2 and libxslt libraries

だった。「libxml2」自体のバージョンは「2.9.13」だった。説明を見る限りでは，この libxml2 は GNOME 上で XML のテキストファイルの解析（解釈？）をするものみたい。なので，GNOME 上で動きそうなアプリケーションではかなり影響を受けそうな感じだった。私の場合はそれが emacs だった。

　さすがに普段使っているエディターが使えないのはつらい。「vi」も多少使えるようになってきたが，それでもやはり使い慣れた方がいい。そこで，いろいろ調べてみた。

　libxml2 自体は「/usr/local/lib/ 」の下にある。

% ll /usr/local/lib/libxml2*
lrwxr-xr-x 1 root wheel      17  3月 26 16:46 /usr/local/lib/libxml2.so -> libxml2.so.2.9.13*
lrwxr-xr-x 1 root wheel      17  3月 26 16:46 /usr/local/lib/libxml2.so.2 -> libxml2.so.2.9.13*
-rwxr-xr-x 1 root wheel 1657544  3月 26 16:46 /usr/local/lib/libxml2.so.2.9.13*

libxml2 のバージョン「2.4.30」がない，というので，Symbolic link で libxml2.so.2.4.30 を強引に作ってみたがだめだった。

　次に，textproc/libxml2/ をインストール（make install）し直してみた。最後にすでにインストールされているのと被っているというエラーが出るが，それはいつものように「make deinstall」してから「make install」すればよい。当然インストールされるのは最新バージョンの「2.9.13」。で，emacs を起動しようとすると，やっぱり

ld-elf.so.1: /usr/local/lib/libxml2.so.2: version LIBXML2_2.4.30 required by /usr/local/bin/emacs not defined

とでる。

　ネット上で検索すると，どうやら過去にもバージョン「2.7.8」辺りでも似たようなことがあったみたい。その際の解決方法は

ports が更新されるはずだから待て

だった。まぁ，そのうち Maintainer の人が直してくれるとは思うけどねぇ。こんな時は自分でも FreeBSD に貢献できれば，と思うが，これが技術が伴わない…。

　それで仕方なくやったのが緊急避難的な「portdowngrade」作戦。「portdowngrade」は，まず

# cd /usr/ports/ports-mgmt/portdowngrade/
# make install clean

で downgrade 用のアプリケーションをインストールしないといけない。
その後で

# portdowngrade textproc/libxml2

とすると downgrade 可能なバージョンの情報を教えてくれる。

# portdowngrade textproc/libxml2
Choose a revision from this list and run /usr/local/sbin/portdowngrade textproc/libxml2 revision
------------------------------------------------------------------------
r565061 | tcberner | 2021-02-13 05:27:37 +0900 (土, 13  2月 2021) | 9 lines

textproc/libxml2: rename VALID option to VALIDATION

- The option name could under some circumctances lead to issues
  with the VALID_CATEGOIRES variable of the ports framework.
- Simply rename the option, to something similar.

PR:             252933
Submitted by:   andrew@tao11.riddles.org.uk

------------------------------------------------------------------------
r556670 | tcberner | 2020-12-01 03:45:04 +0900 (火, 01 12月 2020) | 9 lines

textproc/libxml2: ship patches via files/ due to gitlab
............

ここで赤く色を付けた「r565061」とか「r556670」が downgrade での管理上の番号みたい。今回は直前のものでいいので最初の「r565061」までバージョンを下げることにした。

# portdowngrade textproc/libxml2 r565061

すると

# portdowngrade textproc/libxml2 r565061
A    libxml2/files
A    libxml2/Makefile
A    libxml2/distinfo
A    libxml2/files/LICENSE.TRIO
A    libxml2/files/patch-CVE-2019-20388
A    libxml2/files/patch-CVE-2020-24977
A    libxml2/files/patch-CVE-2020-7595
A    libxml2/files/patch-Makefile.in
A    libxml2/files/patch-Python-39-support
A    libxml2/files/patch-config.h.in
A    libxml2/files/patch-configure
A    libxml2/files/patch-libxml-2.0-uninstalled.pc.in
A    libxml2/files/patch-libxml-2.0.pc.in
A    libxml2/files/patch-python_Makefile.in
A    libxml2/files/patch-python_libxml.c
A    libxml2/files/patch-python_tests_Makefile.in
A    libxml2/files/patch-uri.c
A    libxml2/files/patch-xml2Conf.sh.in
A    libxml2/pkg-descr
A    libxml2/pkg-plist
Checked out revision 565061.
You should be done-- now cd into libxml2 and you can run
# make deinstall install clean

Please note that portdowngrade no longer modifies the ports tree; the
checked out port is at
/root/libxml2

と出てきた。

　current directory に「libxml2」というディレクトリが作られ，その中に移動してから

# make deinstall install clean

とするように，と書いてある。

　そこで書いてあるようにやってみた。すると無事に libxml2 のバージョンを下げることができた。

# make deinstall install clean
===>  Deinstalling for libxml2
===>   Deinstalling libxml2-2.9.13
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        libxml2: 2.9.13

Number of packages to be removed: 1

The operation will free 12 MiB.
[1/1] Deinstalling libxml2-2.9.13...
[1/1] Deleting files for libxml2-2.9.13: 100%
（ここで config がはいった）
===>  libxml2-2.9.10_3 has known vulnerabilities:
libxml2-2.9.10_3 is vulnerable:
  libxml2 -- Possible denial of service
  CVE: CVE-2021-3541
  WWW: https://vuxml.FreeBSD.org/freebsd/524bd03a-bb75-11eb-bf35-080027f515ea.html

1 problem(s) in 1 installed package(s) found.
=> Please update your ports tree and try again.
=> Note: Vulnerable ports are marked as such even if there is no update available.
=> If you wish to ignore this vulnerability rebuild with 'make DISABLE_VULNERABILITIES=yes'
*** Error code 1

Stop.
make[1]: stopped in /root/libxml2
*** Error code 1

Stop.
make: stopped in /root/libxml2

どうやらバージョン「2.9.10_3」は脆弱性があるので今回のバージョン「2.9.13」へのアップデートが行われたみたい。しかし，今回は脆弱性があってもバージョンを下げたいので，「DISABLE_VULNERABILITIES=yes」のオプションをつけて作業した。

# make DISABLE_VULNERABILITIES=yes deinstall install clean

すると，うまくバージョン「2.9.13」をバージョン「2.9.10_3」に下げることができた。そして emacs もうまく動いた。

もしバージョンを固定したければ

# pkg lock libxml2-2.9.10_3

とすればいいみたい。ちなみに，ロックを解除するのは

# pkg unlock libxml2-2.9.10_3

　とりあえずこれで emacs は使えるようになった。よかったよかった。
原因は「libxml2」の最新バージョンにある，ということもわかった。本来は脆弱性に対処した最新バージョン 2.9.13 でエラーが無くなるのがよいのだが，数日（1〜2週間？）はこれで乗り切ろうと思っている。
===================================================
（追記）その後いろいろいじっているが，わかったことが一つある。
一度 emacs を deinstall してから再インストールしようとした。そしたら「x11/libxkbcommon」がないと怒られた。

実は「libxkbcommon」も一度 deinstall して再インストールしようとしてだめと言われていた。仕方ないので「x11/libxkbcommon」の再インストールに挑戦してみた。その時に言われたのが「libxml2」のバージョン 2.4.30 がない，というメッセージだった。そこで，まず「libxml2」をダウングレードして「x11/libxkbcommon」をインストールしてみた。するとうまくインストールできた。

すると今度は emacs を再インストールする時に「libxml2」の 2.9.13 がないと言われた。そこで「libxml2」をアップデートしてから emacs を再インストールするとうまくいった。もしや問題は「libxkbcommon」にあるのか？？
うーん，わからん…。

Android スマホを，Mac アドレスフィルタリングしている Wi-Fi につないだ話

2022-03-17T12:40:00.001+09:00

とある場所での Wi-Fi の接続で Mac アドレスフィルタリングがかかっている。そこに新しく買った Android スマホをつなごうと思ってもうまくいかなかった。なんどやっても，Mac アドレスを調べ直しても同じだった。

と，ふとスマホの今つないでいる Wi-Fi の設定の「詳細設定」を見ると「ランダム MAC を使用（デフォルト）」という項目が目に入った。そこをタップすると「ランダム MAC を使用（デフォルト）」と「デバイスの MAC を使用」というのが選べるようになっていた。そこで「デバイスの MAC を使用」を選ぶと Wi-Fi につながった…。

最近は Mac アドレスは簡単に変更できるので，Mac アドレスフィルタリングは意味がないという話になっている。しかし，ちょっと前に設定されている Wi-Fi だとそれが残っていたりする。今回はそこでひっかかった。Mac アドレスを登録してもらう時に Mac アドレスフィルタリングはもういらないからやめてほしい，といえばよかったか…

FreeBSD で print/tex-luatex/ と japanese/tex-ptex/ のアップデートがうまくできなかった件

2022-02-23T16:39:00.005+09:00

つい最近（2022/2/18 付）で，FreeBSD 上で ports を使った gdal のアップデートがうまくできなかった件について書いた。その時は，最終的には gdal を一度 pkg delete してインストールし直すとうまくいったのだが，今回も同じだった，というお話。

　現在，個人的な web site 用に FreeBSD を運用している。今のバージョンは「FreeBSD 12.2-RELEASE-p7」となっている。そろそろ 12.3 とかに上げないといけないかなぁ，と思っているところ。それはさておき，今回も前回の gdal の件と同じく，ports 経由で portmaster を使ってアプリのアップデートをしようとした。すると，うまくアップデートできないものがあった。

それが

・tex-luatex-0.80.0_24 
・ja-tex-ptex-3.6_1

だった。

　実は，他にも print/texlive-full とか print/tex-dvipdfmx もエラーが出たのだが，各 ports に移動してから「make install」としたら，重複したアプリがあるから一度「make deinstall」してインストールし直せ（make install），と出たので，その通りにしたらちゃんと最新アプリをインストールできた。しかし，luatex と ja-tex-ptex はそれでもだめだった。

　luatex の方のエラーは

! LaTeX Error: LaTeX requires the e-TeX primitives and additional
               functionality available in the engines:
               - pdfTeX v1.40
               - XeTeX v0.99992
               - LuaTeX v0.95
               - e-(u)pTeX mid-2012
               or later.
<argument> ...eak - e-(u)pTeX mid-2012\MessageBreak or later}

みたいに言われた。e-TeX primitives やその他の関数のバージョンがあってない？でも，いまいち理由がわからなかった。

　ja-tex-ptex の方のエラーは

......
\font\JT1/gt/m/n/10=tgoth10
\font\JT1/gt/m/n/12=tgoth10 at 12.0pt
407302 words of font info for 44 preloaded fonts
929 hyphenation exceptions
Hyphenation trie of length 6075 has 181 ops out of 35111
  181 for language 0
  No pages of output.
  Transcript written on platex.log.
  fmtutil [INFO]: log file copied to: /usr/ports/japanese/tex-ptex/work/stage/usr/local/share/texmf-var/web2c/eptex/platex.log
  fmtutil [ERROR]: running `eptex -ini   -jobname=platex -progname=platex *platex.ini </dev/null' return status: 1
  fmtutil [ERROR]: returning error due to option --strict
  fmtutil [INFO]: not selected formats: 2
  fmtutil [INFO]: failed to build: 1 (eptex/platex)
  fmtutil [INFO]: total formats: 3
  fmtutil [INFO]: exiting with status 1
  *** Error code 1

みたいに言われた。何が悪いのか，いまいちわからなかった。

　そこで，数日待って ports が更新されないか待ってみたり，rehash してみたり，mktexlsr で TeX のディレクトリ情報を更新したりしたが，どれもうまくいかなかった。

仕方ないので，いざとなれば TeX が動いてなくても問題のないマシン上で，一度 tex-luatex を pkg delete してみた。実際には

　# pkg delete -f tex-luatex-0.80.0_24

としてみた。ここで「-f」オプションがないと，tex-luatex に依存している他のアプリもいくつか消そうとしたので，念のためにつけておいた。「-f」オプションがあればターゲットとなるアプリのみを削除してくれるので。

　その後，「/usr/ports/print/tex-luatex/」に移動し，念のために「# make clean」を実行したのち，「# make install clean」を実行した。すると，無事にインストールすることができた。

　luatex でうまくいったので，ja-tex-ptex でも同じ作戦を使うと，これまたうまくインストールできた。たぶん，なにかの依存関係で整合性がとれてなかったんだと思うが，どこがどうまずかったのかは残念ながらわからなかった。でも，まぁ，うまくインストールできたからいいことにしよう，おー！！

Mac mini Late2104 の SSD (NVMe M.2) 交換の覚書き

2022-02-22T00:23:00.014+09:00

1個前の投稿で書いた，Mac mini Late2014 に入れいていた NVMe M.2 2280 の SSD の入替えだが，一段落したので，備忘録を兼ねてうまく行った時の手順を書いておこう。

　ちなみに，SSD は ADATA の XPG GAMMIX S11 を Crucial の CT1000P1SSD8（P1 シリーズの 1TB モデル）へ，また別の Mac mini Late2014 で P1 シリーズの 1TB（CT1000P1SSD8）から CT1000P2SSD8（P2 シリーズの 1TB モデル）に入れ替えた。どちらも今のところ（2022/2/23 現在）うまく動いている。現時点での OS のバージョンは macOS Moterey (ver. 12.2.1) である。

(1) SSD の差し替え
　まず SSD を入れ替える。その際，気をつけないと SSD 締め付け用のネジがやられる。実は今回ネジがやられてしまった…。仕方ないので，テキトーに動かないように厚紙を挟んでごまかしている…，いいのか？？
（これについては，後日直径 2mm の長めのネジを使い，無駄にナットを使って長さを調整して解決した）

(2) SSD のフォーマットのためにマシンを起動する
　新しい SSD をセットしたら，まずはフォーマットしないといけない。その後の復元作業を考えるとマシンの電源投入時は以下のようにするのがよい。
・電源投入時に「option + command + R」で起動

こうすると，フォーマット用のディスクユーティリティの他，OS のインストールソフトも最新バージョンのものをインターネットからダウンロードしてくれる。実は今回，深く考えずに「command + R」つきで起動し，OS のインストールをしようとしたら，なんと Yosemite（ver. 10.10）をインストールしようとした。そのせいか OS X ユーティリティも SSD を認識してくれなかったし…。やはりこの辺りのソフトは最新のものがいいみたい。

しかし，「command + R」で起動した場合にどのバージョンの OS になるかは，どうやって決まってるんやろ？どうも，機種とか場合によるみたいやけど，実はわかっていない…，ははは。

(3) 「macOS 復旧のユーティリティウインドウ」でディスクユーティリティを起動
　option + commnad + R の起動後に出てくる画面は，Apple のサイト「ディスクユーティリティで Mac を修復する方法」によると「macOS 復旧のユーティリティウインドウ」というみたい。以前は「OS X ユーティリティ」という名前だった。その画面で，ディスクユーティリティーを選び，「続ける」をクリックすると SSD をフォーマットすることができる。

ディスクユーティリティー起動後に SSD 名（製品の型番，CT1000P2SSD8 のような番号）が見えていない場合は，
・「メニューバー」→「表示」→「すべてのデバイスを表示」
とすると，SSD 名，コンテナ名なども表示してくれる。

　2022年2月時点では，SSD の場合には「フォーマットはAPFS」，「パーティションマップは GUID」を使うのがいいみたい。 Apple のディスクユーティリティで SSD や HDD のフォーマットをさせるには「消去」を使う。フォーマットする，という文言はなかったように思う。なんともわかりにくい…。
　APFS フォーマットと GUID パーティションを選んで，適度なストレージ名をつけて，「消去」をクリックするとフォーマットが始まる。フォーマットが完了したら，ディスクユーティリティーを終了（Quit）しておく。

(4) Time Machine による復元（最近はその前に OS のインストールが必要みたい…）
　「macOS 復旧のユーティリティウインドウ」に戻ったら，次に「Time Machine」で復元を行う。復元は，復元元と，復元先を選んで復元を行うが，この場合って復元先は指定できたっけ？忘れてしまった…。

　今回，最新の OS 用の macOS 復旧ユーティリティの Time Machine を使って復元しよとすると，Time Machine による復元の際に「Mac OS をインストールしてからじゃないとだめ」みたいに言われてしまった。以前はそんなこと言われなかったのに…。
　仕方ないので「macOS 復旧のユーティリティウインドウ」に戻り（強制的に戻らされた），「macOS Monterey を再インストール」を選んだ（2022/2 時点なので Monterey だった）。

　OS のインストールには 1 ～ 2 時間かかったような気がする。気づいたら終わっていた。そして，自動で再起動されていた。起動後，いきなり Time Machine から復元するか，と聞いてきた。その際，最新のバックアップじゃない復元ポイントが提示されたことがあった。その時には，その場での復元を諦め，一度仮の管理アカウントを作ってログインしてから，「アプリケーション」→「ユーティリティ」→「移行アシスタント」を実行させ，そこで Time Machine から復元を選ぶといいみたい。

　復元時に管理者用のアカウントについては，パスワードの設定を求められる。一般のアカウントは，複雑なデフォルトのパスワードが表示されていて，最初のログインの時に全一般アカウントはそのデフォルトパスワードでログインしてからパスワードを各自設定し直せ，ということだった。

　これでなんとか無事に Mac mini が復活した。最近 SSD の具合が気になっていたから，これでうまくいくといいなぁ…。

Mac mini Late2104 の SSD (NVMe M.2) の入替えで苦労した話

2022-02-21T23:33:00.009+09:00

NVMe M.2 2280 の SSD（ADATA 製 XPG GAMMIX S11）の入った Mac mini (Late2014) の OS-X のバージョンを Big Sur（バージョン 11）から Monterey（バージョン 12）にアップデートしようと思ったのだが，Apple と互換性のない SSD ではアップデートできません，と言われて困ってしまった，というお話。

　実はうちにはもう一台 Mac mini (Late2014) があるのだが，そちらではちゃんとアップデートできていた。なぜ？と思ったのだが，2台目の方は Crucial の CT1000P1SSD8（P1 シリーズの 1TB モデル）を使っている。なので，まずは SSD のメーカーの違いか？と思った。世の中のコンピューターは Windows でないと動かないサードパーティ製のパーツも多い。Macintosh で動いても，管理用のソフトが働かない，とかもよくあるし…。

　そこで考えたのが SSD の交換。ネットで探すと Crucial の P1 シリーズはもう廃版になっていて，P2 シリーズになっているみたい。しかし，値段は P1 を買った時よりもかなり安くなっている。 SSD も永久に使えるわけじゃない（ということになっている）ので，ここらで更新してもいいかな？と思い，ネットで CT1000P2SSD8をポチッとしてみた。これは CT1000P1SSD8 の後継の P2 シリーズの 1TB モデル。それを使って1台目の Mac mini の SSD を入れ替えてみた。入れ替え自体は道具もあるし，もともと自分で入れたのであっと言う間だった。また，データはもともと付いていた HDD をバックアップ用として Time Machine でバックアップしてある。

　そして Mac mini を起動すると，まずは「起動ディスクがない」ということで，通常でも「Command + R」を押した状態で起動した時と同じように，ディスクユーティリティーやら Time Machine やらの選択画面になった。ここまでは予定通り。

　問題はここからだった…。
まずは，ディスクユーティリティーで SSD のフォーマットを行った。フォーマットは APFS（大文字小文字の区別なしで暗号化もなしにした）にし，パーティションマップは GUID にしておいた。フォーマットはこれまでは「Mac OS拡張（ジャーナリング）」を選んでいたが，新しい OS-X の場合，SSD なら APFS がいいとどこかに書いてあったので…。

　ディスクユーティリティーを「終了」して，次に Time Machine からの復元をしてみた。 Time Machine からの復元は，復元元と復元先を選んで復元を始めればいい。ただし，数百 GB ある場合は数時間はかかると思っていないといけない。今回はデータは少なめのはずだったが，それでも5時間とか出てきた。仕方ないのでしばし放置しておいた…。

　そして何時間か経った後に見てみると Mac mini の電源がオフになっていた。おや？普通は Time Machine で復元すると勝手に起動しているはずなのだが…。よくわからないが，とりあえずスイッチを入れてみよう，と思い，メインスイッチを ON にしてみた。するとリンゴマークが出てきて，プログレスバー（進捗を示すバー）がするすると右に動いていった。そこで，しばし他のことをしていると…，Mac mini がおとなしい。普通ならログイン画面になるはずなのに…？スクリーンセーバーが起動した？いや，画面は真っ暗のままやし…。どうも勝手に電源が落ちたみたい。

　仕方ないのでもう一度スイッチを入れてみた。そしてプログレスバーを見てみると，半分を過ぎた辺りで画面が暗くなった。おかしいな，と思って見るとやはり電源が落ちていた。もう一度やってみても同じだった。起動画面のプログレスバーが半分を過ぎた辺り\ で電源が落ちていた。

　…困った。とりあえず原因を探ろうと思ったが，何をすればいいのやら…。そういえば，職場に Crucial CT1000P1SSD8 を入れたマシンがあった，と思い出した。さらに P2 は P1 よりも起動時に消費する電流の最大値が 1.7 A から 2.5 A に上がっていたので\\ ，Mac mini の SSD の電源の力不足かな？と思った。そこで，新しく買った P2 とその P1 を入替えて（当然データはクローンコピーした），P1 を Mac mini Late2014 に入れてみた。（註：結果的には電流値は関係なかった…）

　これでうまくいくはず，と思ったが…。
やはりほぼ同じ症状だった。うーん，何が悪いんやろ？ADATA の XPG 君は Windows に一度つけたものを持ってきたのが悪いのかなぁ？？フォーマットが ex-FAT という Windows でも見れるフォーマットなのか？と思ったけど，そんなことなさげやし…。ちなみに ex-FAT でフォーマットすると，Time Machine でバックアップできないらし。

　仕方ないので CT1000P1SSD8 に Mac OS-X を入れ直してみた。Command+R 起動の際に Mac OS の再インストールというのがあったのでやってみると，macOS 10.15 の Catalina まで戻されてしまった…（option + Command + R とするといい，と最新 OS をインストールできる，と後で知った…，はぁ…）。そこからアカウントを作り最低限の設定をしてから，まずは OS-X のアップデートをしてみた。すると今回はうまくいった。無事に，一気に「Monterey（バージョン 12）」にアップデートすることができた。そして，コツ\ コツとデータをコピーした。

　その後，バージョン 12.2.1 にアップデートしたのだが，その状態で Time Machine にバックアップして，そこから ADATA の XPG にシステムを復元してみた。XPG GAMMIX S11 も，APFS，GUID でフォーマットしたら，Mac mini でも普通に使うことができた。ただ\ ，今回のバックアップでは「フォーマットしたてのカラの SSD に Time Machine から直接復元できない」から「移行アシスタントを使え」と言われてしまった。新しい OS やと，OS 自体はバックアップされないのかな？？仕方ないので，一度 OS を入れ直してから\ ，移行アシスタントで復元したら無事に新しいシステムに復元できた。

ちなみに CT1000P2SSD8 もちゃんと Mac mini Late2014 で使えている。定格の電流値が原因じゃなかった。これで一安心やわ。
しかし，結局何が悪かったんやろ？最初から option + Command + R でやっておけばよかったとかかなぁ？？

FreeBSD で graphics/gdal/ のアップデートがうまくできなかった件

2022-02-18T11:42:00.008+09:00

現在，個人的な web site 用に FreeBSD を運用している。今のバージョンは「FreeBSD 12.2-RELEASE-p7」となっている。

そこで，ports 経由でアプリケーションを管理しているが，portmaster でアプリのアップデートをしようとすると「gdal-3.3.3_2」のアップデートでエラーがでた，という話。

　まずは，いつものように「# portsnap fetch update」で ports を最新にし，それから「portmaster -aDG --no-confirm」でアプリケーションをアップデートしようとした。すると，なぜか「gdal-3.3.3_2」から「gdal-3.4.1」へのアップデートでエラーがでた。
エラーメッセージは以下のような感じだった。

......
c++ -Wl,-rpath,/usr/local/lib -L/usr/local/lib -fstack-protector-strong  ogr2ogr_bin.o  -L/usr/ports/graphics/gdal/work/gdal-3.4.1 -lgdal -o ogr2ogr
c++ -Wl,-rpath,/usr/local/lib -L/usr/local/lib -fstack-protector-strong  ogrtindex.o  -L/usr/ports/graphics/gdal/work/gdal-3.4.1 -lgdal -o ogrtindex
ld: error: undefined symbol: OGRSpatialReference::GetCoordinateEpoch() const
>>> referenced by ogrinfo.cpp:303
>>>               ogrinfo.o:(ReportOnLayer(OGRLayer*, char const*, char const*, OGRGeometry*, bool, bool, char**, bool, bool, bool, char const*)::$_0::operator()(OGRSpatialReference const*) const)
c++: error: linker command failed with exit code 1 (use -v to see invocation)
c++ -Wl,-rpath,/usr/local/lib -L/usr/local/lib -fstack-protector-strong  gdalbuildvrt_bin.o  -L/usr/ports/graphics/gdal/work/gdal-3.4.1 -lgdal -o gdalbuildvrt

gmake[2]: *** [GNUmakefile:161: ogrinfo] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: Leaving directory '/usr/ports/graphics/gdal/work/gdal-3.4.1/apps'
gmake[1]: *** [GNUmakefile:123: apps-target] Error 2
gmake[1]: Leaving directory '/usr/ports/graphics/gdal/work/gdal-3.4.1'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/gdal
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20220207-36392-1xmou4g env UPGRADE_TOOL=portupgrade UPGRADE_PORT=gdal-3.3.3_2 UPGRADE_PORT_VER=3.3.3_2 make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
        ! graphics/gdal (gdal-3.3.3_2)  (unknown build error)

　こんな時によくやる作戦として，(1)「portupgrade -a」を使ってみる，(2)「make install」を使ってみる，というのを実行している。しかし，今回はどちらの作戦もだめだった。そこで gdal の ports「/usr/ports/graphics/gdal/」の work ファイルのエラーが起こった箇所を見たりしてみた。どうもエラーは「ld: error: undefined symbol: OGRSpatialReference::GetCoordinateEpoch() const」とあるように「OGRSpatialReference::GetCoordinateEpoch()」が定義されていない，ということみたいだった。この「GetCoordinateEpoch()」は，/usr/ports/graphics/gdal/work/gdal-3.4.1/apps/ の中の「ogrinfo.cpp」で参照されているみたいだった。そこで，GetCoordinateEpoch() が定義されてそうなヘッダーファイルを調べて ogrinfo.cpp に書き加えてみたりしたが，どうもうまくいかなかった。

　なかなかうまくいかない，と2ヶ月ほどうだうだしていたのだが，ふと「undefined symbol: OGRSpatialReference::GetCoordinateEpoch() const」と検索してみた。すると FreeBSD Bugzilla の Bug 261432 - graphics/gdal: gdal-3.4.1 fails to build on 12.3-stable という項目にたどり着いた。

　それによると，どうも API として新しいものを使っているのに，アップデートではそれがうまく反映されない，ということみたいだった。なので，「pkg delete -f gdal」して，re-install しろ，と書いてあった。

　そこで以下のようにすると，嘘のように簡単にエラーがなくなった…。

# pkg delete -f gdal
# cd /usr/ports/graphics/gdal/
# make install clean

delete してからインストールが失敗すると困るかもなぁ，と思っていつもはやらない作戦がよかったとは…，やられた。

Mac mini (late2014) に入れた SSD (Crucial) の Firmware アップデート

2022-02-06T21:16:00.014+09:00

今，Mac mini (late2014) を使っている。結構古いマシンなのだが，ストレージを SSD (NVMExpress) にするとそれなりに使えている。現在，Crucial の CT1000P1SSD8 という P1 シリーズの 1TB のものを入れている。なかなかに調子よく使ってる。これはインターフェースが NVMe (PCIe Gen 3 x4) というもので，基本的にボード上の PCIバスに直結して使うタイプのもの。コネクタおよび大きさは M.2 (2280) と表現される（幅が 22mm で，長さが 80mm だったかな？）この SSD に替えてから，ストレージへのアクセス速度が向上して，以前あったようなストレージへのアクセスでの待ち時間のストレスがほぼなくなった。

ちなみに Mac mini (late2014) に SSD をインストールする方法については「せきねさん家」の中の以下の記事を参考にした。
　・Mac mini 2014にPCIe接続のApple純正ではないNVMe M.2 SSDを増設する（準備編：PCIeスロット取り付け）
　・Mac mini 2014にPCIe接続のApple純正ではないNVMe M.2 SSDを増設する（取付編：変換アダプター）
　・Mac mini 2014にPCIe接続のApple純正ではないNVMe M.2 SSDを増設する（インストール・フォーマット編）

　今回はその Crucial の SSD の Firmware のアップデートを行った。これも独自に調べたわけじゃなくて，Macでサムスン製SSDのファームウェアをUSBメモリやSDカードで更新する（NVMe/SATA両対応）を参考にした。「せきねさん家」には感謝に耐えない…。

　Macでサムスン製SSDのファームウェアをUSBメモリやSDカードで更新する（NVMe/SATA両対応）では，サムスン製の SSD の Firmware のアップデートについて述べられているが，そのポイントは，
　(1) アップデーターの ISO イメージが配布されている（Windows か Mac か，という区別はないらしい）。
　(2) USB メモリを使う。
あたりかな？
　Macでサムスン製SSDのファームウェアをUSBメモリやSDカードで更新する（NVMe/SATA両対応）の中で Crucial も Firmware のアップデータの ISO イメージが配布されているのでいけるのではないか？と書いてあったので，さっそく試してみた，というのが今回のお話。
結果としては「うまくいった」。Mac mini (late2014) に入れた Crucial の NVMe M.2 の Crucial 製 SSD のアップデートがうまくできた。いやぁ，よかったよかった。

　で，「せきねさん家」の記事を見ればできるのだが，一応どうやったかの手順だけ箇条書きにしておこう（備忘録，という感じかな）。

(0) 念のために SSD をバックアップしておく（Time Machine）

(1) システム情報の「NVMExpress」で現在のSSDのリビジョンを確認
　　今回は「P3CR010」だった。

(2) ネットで該当する SSD の最新のリビジョンを調べて，より新しいものがあれば ISO イメージをダウンロード
　　Crucial なら ISO イメージなので，USB メモリを使ってアップデートが可能

(3) USB メモリを接続して初期化する（当然，中身は消える）
　　ディスクユーティリティーアプリで，USB メモリの初期化を行う。
　　　・フォーマット：「MS-DOS（FAT）」を選択
　　　・方式：「方式」欄が出た場合は「マスター・ブート・レコード」を選択
　　上記を選択して「消去」ボタンをクリック

(4) USB メモリの接続解除する（物理的にはつないだまま）
　　ディスクユーティリティー上でマウントを解除
　　（USB メモリ自体ではなく，1個下の「ボリューム」を接続解除する。

(5) USB メモリのデバイス名をメモしておく
　　　ディスクユーティリティーのUSB メモリの情報で，disk4 とあれば「/dev/disk4」がデバイス名
　　ターミナルで下記のようなコマンドでもわかる。
　　　# diskutil list
　　その際，USB メモリの容量を確認しておく。異なるデバイスを指定すると大変なことになる。

(6) スーパーユーザー権限で，以下のコマンドを実行して，ISO イメージを USB メモリに書き込む。
　　　# dd if=./Desktop/Crucial_P1_P3CR013.iso of=/dev/disk4
　　ここで，ISO イメージはデスクトップにおいていた。
　　→ このディスクは読めません，と出れば正常 → 無視しておく。

(7) Mac mini の電源を落とし，OPTION キーを押しながら再起動
　　→ 作成した USB メモリを指定して起動させると，勝手に作業してアップデートが終わって，その後勝手に電源がオフになる。

(8) 電源をオンにして起動 → システム情報でリビジョンの確認をしておく。
　　今回のリビジョンは「P3CR013」になっていた。

Android スマホの LINE アプリの占領しているメモリを多少減らしてみた

2021-10-20T23:30:00.235+09:00

　Android のスマホを使っている。それもどちらかというと安物のスマホを使っている。安物の安物たる所以は，一つにはメインの CPU の速度が遅い。かつ，カメラの性能が低い，さらにメモリ容量（PC でいうハードディスク相当やから，ストレージという方がいいか）が少ない，というのがある。最近は画像でもなんでも溜め込むので，それなりに大きな容量を持ったスマホも多いが，私のスマホは 32 GB しかない。それでもちょっと前までは 16 GB とかいうのもよくあったので，多少はましだけど…。ただ，Android スマホは micro SD カードを使えるので，カメラアプリで撮った写真は当然 SD カードに保存するように設定しているが，つい最近ストレージが 29 GB を越えた，とスマホに怒られた。特にアプリを増やしているわけではないのに，なんでかなぁ？と思って，スマホの設定にある「ストレージ」の中を見てみた。

ちなみに，右のスクリーンショットがその設定画面。画像をタップすると少しだけ大きな画像が見れる。

　ストレージは設定画面の下の方にある。見てみると，32 GB のうち，何バイト使ってるかがわかる。表示してる画像はメモリをましにしてからやから 24 GB 程度やけど，これが 29 GB もあった。それはさすがにまずいよなぁ。そこで，さらに「内部共有ストレージ」ってとこをタップすると，使用している容量の一覧が出てくる。見てみると，「その他のアプリ」の 12 GB と「システム」の 10 GB がかなり幅をきかせてるみたい。そもそものシステムが 10GB って，32 GB のシステムにしてはでかくないかね？

　　　

で，「その他のアプリ」ってのを見るとメモリの使用順に並んでいて，トップが「LINE」だった。それも処理をする前は容量が「5.7 GB」もあった。他のは 1 GB ないぐらいやのになんで LINE だけそんなにでかいの？？？そこで，LINE アプリの詳細を見ると，アプリ自体は 300 MB ない大きさやのに，ユーザーデータとキャッシュが多すぎ…。特にユーザーデータ。ただ，この「設定」-「ストレージ」から入った画面でユーザーデータを削除しようとすると，登録情報とか全部消されそうなので，キャッシュしか消せなかった。

　　　

　仕方ないので，LINE アプリの中で消せないかどうかを見てみた。 LINE アプリの中の設定に行くと，「写真と動画」というのがあるので見てみたけど，そこでは送信する写真の画質の設定と，投稿された写真や動画を自動でダウンロードするか，自動で再生するか，ぐらいしか設定できなかった。

　そこで「トーク」の中を見ると，少し下の方になるが「トークルーム内の写真などを削除」というのがあった。これはいけるかも？と思ってタップすると，「有効期限が切れた写真や動画，ファイル，ボイスメッセージは，削除すると確認できなくなります。削除しますか？」と聞かれる。写真などは一週間しか有効期限がないし，有効期限が切れるとサムネイルは見れるけど中身を拡大してみたりはできないので，削除してもいいや，と思って削除してみた。すると，なんと LINE アプリが使用していたメモリが 5.7 GB から 1.6 GB に減った。
　なんてこった。こんなに溜め込んでたんや。というか，期限がきれたら余計なものは捨ててくれればいいのに…。ただ，このデータがキャッシュにあったのか，ユーザーデータの中にあるかはわからなかった。というか，そこを見る前に余計なファイルを消してしまったので…。

　ちなみに，「すべてのトーク履歴を削除」とするとトークの内容が全部消えるのでやめておいた方がよさげである。

　　

六甲全山縦走・勝手にレベルを決めてみた（その２）

2020-11-19T21:14:00.010+09:00

以前（2016/12），勝手に六甲全山縦走の達成レベルを決めてみた。そこでは，いろいろな状況での六甲全山縦走の達成状況から，レベル0からレベル7とマイスター級というのを決めてみた。そのレベル設定はあくまで勝手に決めたことなので，なんの権威もないし，そのレベルになったからと言って賞品も賞状も何もない。また，そこでは，時間として12時間以内に達成したらレベル5としていたが，それ以上の時間設定は怪我やトラブルのもとと思ってレベル判定には加えていなかった。しかし，最近，トレランスタイルでの六甲全山縦走で多少早く宝塚に到達できるようになったので，レベルを加えてみようかな，と考えた，というのが今回のお題。

　でも，レベル7の上にレベル8とかを作るのは，怪我やトラブルのもとなので，違う名前をつけようと思った。で，以下のようなレベルを考えてみた。あえてディスるような感じの名前にしているのは，無理して怪我やトラブルに巻き込まれないようにしてほしい，という願望が入っている。しかし，個人的には敬意を表しているつもりである。
　いずれにせよ，早く宝塚に到達するのはそれなりの危険があるので，無理をしてはいけない。達成しても自己満足しかないので…。

おかしな人：11時間以内での六甲全山縦走達成
　まずは11時間以内で六甲全山縦走達成のレベルである。これは「おかしな人」レベルだと思っている。普通の人は12時間以内でも結構たいへんなのに，それを1時間も縮めている。この辺りから普通の人の感覚ではおかしな人と言っていいと思う（本人はそんなことは思わない，というのは十分にわかっている）。

変人：10時間以内での六甲全山縦走達成
　10時間を切っての六甲全山縦走達成は，これまた普通の人の感覚だともう完全におかしい。おかしな人を越えて「変人」と呼んでもいいレベルだと思う（あくまで普通の人の感覚で，です）。

変態：9時間以内での六甲全山縦走達成
　9時間を切ると，もうおかしいを通り越して苦しみを楽しんでるとしか思えないので「変態」級と呼んでいいと思う。 9時間切るには須磨から摩耶山まで5時間ちょっと，それ以降を4時間切るぐらいでいかないと到達できない。それって普通の人からするとどうかしている。あえてそれを達成しようと考える時点で変態と言っても過言ではない

ど変態：8時間以内での六甲全山縦走達成
　8時間を切ると変態の一段階上になるので「ど変態」としておいた。ここまでくるとそれなりの脚力が必要になるし，ほぼ8時間走り続ける感じになってくると思う。やっぱりおかしい…。

頂人：7時間以内での六甲全山縦走達成
　ここまでくるとさすがにレベル名にも敬意を表したくなる。最初はここに「超人」をいれようと思ったが，超人はもう一段上にしようと思ったので，同じ読みになる「頂人」にしてみた。鳥人でもいいのだが，それだと空を飛びそうだし…。他にも，蝶人，長人，挑人，兆人，町人…，いろいろ考えたが，頂きを越えていくので頂人にしてみた。岳人だとどこかの雑誌になってしまうし…。

超人：6時間以内での六甲全山縦走達成
　6時間以内なら，もう超人でいいと思って超人にしておいた。これ以上はもう超人でも神でもなんでもいいや，と思ったから。ま，これ以上はレベル付けしてもあまり意味なさげだし…。

　ちなみに，私はこの間「変人」を卒業して，「変態」に仲間入りした。思ったとおりこのレベル名だと昇格しても全然うれしくはないが，それなりに達成感はあったので，よしとしておこう。

ports からインストールした qt5-gui のアップデート時のトラブルについて

2019-10-06T18:24:00.000+09:00

これは 2019年9月〜10月に起こったことについて書いている（言い換えると，時間が経ったら根本的に解決してると期待している）。

　事の発端は，FreeBSD の ports からインストールしたアプリケーションソフトである「qt5-gui」をアップデートしようとしたことにある。いつものように ports ツリーのアップデートを行い，アップデートすべきアプリケーションをアップデートしようとすると，この「qt5-gui」もアップデートの対象となっていた。

　この「qt5-gui」は，Qtというクロスプラットフォームの GUI ツールキットらしい。GUI なので FreeBSD や Linux など異なるプラットフォームでの graphical user interface 用のいろいろな便利なアプリケーションみたい。読み方は「キュート」らしい。「qt5」はバージョン5かな？そのコアとなるルーチンが「qt5-gui」らしい。

　今回はその「qt5-gui」をアップデートしようとすると，以下のようなエラーが発生してアップデートできなかった。

.....
/usr/include/dev/evdev/input.h:232:8: note: previous definition is here
struct ff_rumble_effect {
       ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:444:8: error: redefinition of 'ff_effect'
struct ff_effect {
       ^
/usr/include/dev/evdev/input.h:253:8: note: previous definition is here
struct ff_effect {
       ^
13 errors generated.
*** [.obj/qevdevtouchhandler.o] Error code 1
.....

　なんかディレクトリの指定が違うぞ，みたいにも見えるがいまいち何を言いたいのかがわからなかった。このエラーは何度アップデート作業をしても起こるし，1週間ほど待って ports ツリーをアップデートしても改善されなかった。 portmaster 以外に，make install としてインストールしなおしてもうまくいかなかった。

　そこで，ネットで調べると以下のような英文のサイトを見つけた。
FreeBSD Bugzilla – Bug 240964　x11-toolkits/qt5-gui: 5.13.0 fails to build

　そこには以下のような解決策が書かれていた。

It builds if I remove in 

src/platformsupport/input/evdevtouch/qevdevtouchhandler.cpp:

     52 #ifdef Q_OS_FREEBSD
     53 #include 
     54 #else
     55 #include 
     56 #endif
     57

　どうやら，qevdevtouchhandler.cppというファイルの 52行目から56行目を消せ，ということみたいだった。じゃあ qevdevtouchhandler.cpp を探せばいいのだが，それがどこにあるかがちょっとわかりにくかった。当初「src/」とあるので「/usr/src/」などを見たが「qevdevtouchhandler.cpp」のようなファイルはなかった。そもそも「platformsupport/」なるディレクトリがなかった。

　しばし途方に暮れたが，なにかのタイミングで以下の場所にあるのがわかった。

　まず「/usr/ports/x11-toolkits/qt5-gui/」のディレクトリに行き，「# make install」としてインストール作業を行う。その途中でエラーが起こって止まるが，その状態にしておく。それにより，作業用に作られた「/usr/ports/x11-toolkits/qt5-gui/work/」というディレクトリが残された状態になる。

　そこで，その中の「qtbase-everywhere-src-5.13.0/src/platformsupport/input/evdevtouch/」の中に「qevdevtouchhandler.cpp」が存在する。フルパスで書くと以下のようになる…，長い…。

/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.13.0/src/platformsupport/input/evdevtouch/qevdevtouchhandler.cpp

　その「qevdevtouchhandler.cpp」の中の下記の行を消してから，インストール（あるいはアップデート）を行うとうまくいった。

     L.52 #ifdef Q_OS_FREEBSD
     L.53 #include 
     L.54 #else
     L.55 #include 
     L.56 #endif

　早く根本的に直してくれないかなぁ…。そうしないとアップデートの度に「qevdevtouchhandler.cpp」を書き換えないといけない…。

OpenLayers のバージョンが 5.3.0 になったら，うまく動かない…

2019-07-24T21:43:00.000+09:00

以前，OpenLayers 3 を使ってみよう（その0：はじめに：地理院地図を表示）として，OpenLayers のメジャーバージョンが 3 の頃の話を書いている。参考にしてみて欲しい。

　以前，2014年9月から OpenLayers 3 を使ってみよう（その0：はじめに：地理院地図を表示）として，ちょこちょこと OpenLayers 3 の使い方について書いてきた。 2017年1月にはその OpenLayers 3 の最新バージョンが 3.20.1 になっていた。それが，2017年2月に入ってしばらくすると，OpenLayers のバージョンが 4.0.1 にあがっていた。 2019年7月の現時点だと，かなりバージョンが上がってるかなぁ？と思ったら，やっぱりかなり上がって，バージョンは 5.3.0 になっていた。

　以前，OpenLayers のバージョンが 4.0.1 になっていたにも書いたが，OpenLayers はバージョン番号の付け方を Semantic Versioning（セマンティックバージョニング）に従ってつけるようになっている。その時はメジャーバージョンが 4 に上がったので，後方互換性がある程度失われていた。それが，メジャーバージョンが 5 になったということは，当然以前のままのスクリプトでは動かない可能性が高い。そこで，少しだけ OpenLayers 5.3.0 がどうなっているのかを見てみた，というのが，今回のお話し。

　で，さっそくOpenLayers のサイトに行ってみると，なんかすごく変わっている感じがした…。「感じがした」というのは，すぐにはなにがどう変わったのかがイマイチわからなかった。

　そこで，まずはDocsの中のquick startを見てみた。すると，「map」の指定の仕方とかが変わっていた…。なんか，結構見直さないといけないなぁ，と思ったのだが，その次に見たtutorialsやら，Examplesを見たら，何がなんやらわからなくなってしまった…。

　そこに謎のキーワード「import 文」が並んでいた。例えば，

import Map from '../src/ol/Map.js';
import View from '../src/ol/View.js';
import {Draw, Modify, Snap} from '../src/ol/interaction.js';
import {Tile as TileLayer, Vector as VectorLayer} from '../src/ol/layer.js';
import {OSM, Vector as VectorSource} from '../src/ol/source.js';
import {Circle as CircleStyle, Fill, Stroke, Style} from '../src/ol/style.js';

のように書いてある。 JavaScript に import ってあったっけ？と思って調べてみたら，どうやら比較的最近（2015年頃？）追加されたらしい。しばらく興味が登山・スポーツに移っていたので，完全に世の中に乗り遅れてしまっていた（もともと全然乗れてないけど…）。

　じゃあ，普通に使えるのか，と思って，Github の openlayers エントリーから 5.3.0 の master.zip をダウンロードしてみた。で，それを使ってサンプルページを，と思ったが，これがうまくいかない…。 Firefox で「ツール」-「ウェブ開発」-「ウェブコンソール」として，コンソールを表示させて見てみると，

TypeError: Error resolving module specifier: ol/Map.js

のようなエラーが出てくる。

　どうやら「Map.js」がどこにあるのかわからない感じだった。だいたい「ol」はディレクトリ？じゃあ，ルートディレクトリはどこにあるの？という感じだった。そこで，具体的に Map.js があるディレクトリを相対指定してみたが，今度は Map.js などが呼び出している他のルーチンがないと言うし…。

　困った…。
OpenLayers がバージョン 5 になって，ここまで変貌を遂げるとは…。しかし，なんでquick startとtutorialsで，書いてあるサンプルが全然違うの？？？

　同じような疑問を持つ人はいるみたいで，「I need a Openlayers 5 complete without NodeJS!」というのがあった。まだドキュメントもちゃんと整理できていないような気がする…。

　仕方ないので，とりあえずいろいろ見てみた。すると，tutorialsの中のBuilding an OpenLayers Applicationに「Node」を使えみたいに書いてあった。どうやら，「import」文は「Node」の文が念頭に置かれているみたいだった。さらに，どこかにモジュールハンドラの「Parcel」を推奨する，みたいに書いてあった。うーん，Parcel ってなに？

　かつ，何故かわからないが以前と同じような「OpenLayers」のフルセット（v5.3.0.zip）もあるみたいだった。それは最新版のdownloadのページにリンクがあった。この zip ファイルを解凍すると，以前のバージョンのような「ol.js」が入っていた。

　ということで，どうやら，2019/7 時点では，以下の2個の異なる種類の OpenLayers 5.3.0 が存在しているみたい。

(1) Node (Parcel) の import文を使うバージョン？（Github の openlayers）… ES module 版？
(2) 以前からある OpenLayers と同じフルセット（v5.3.0.zip）

　今後，OpenLayers は Node 上でないと使えなくなるのだろうか…？？でも，きっとこの変更はメジャーバージョンが「5」になった時（v 5.0.0 ?）の時に変わっていたはず。それが v 5.3.0 になっても2種類あるということは，今後のこの2種類の OpenLayers が存在し続けるのだろうか？？そもそも全員が「Node」を使うということもないと思うので，apache や nginx を使う場合はやはり「(2) フルセット」を使わないといけないような気がする…。現在，v 6.0.0 のベータ版が作られているようなので，今後どうなるかが，が気になるところである。

　他にも困った点が存在している。それは，API document の記載である。これは OpenLayers のマニュアルみたいなものであり，様々な Class などの定義や，そこで使える Function などについての記載がある。その記載が少し違っている。というか，Class 等の名前の付け方が変わっている。以前なら「ol.format.KML」とされていたものが「ol/format/KML~KML」と記載されている。使う際にも ES module 版なら，JavaScript の先頭に以下を書かないと読み込まれない。

import KML from 'ol/format/KML';

　さらに，以下のように「KML」という名前だけでよい。

var kml = new KML();

　しかし，フルセットで使う際には「ol.format.KML()」でないといけないので，その変換が必要になる。（最後にリストを載せておく）

　とりあえず，v 5.3.0 の時点で，apache 等でフルセットの OpenLayers を使う時の注意点を書いておこう。

(1) ネットから OpenLayers のフルセット（v5.3.0.zip）をダウンロードする。
(2) <link rel="stylesheet" href="OpenLayers_directory/css/ol.css" type="text/css">
    <script src="OpenLayers_directory/build/ol.js" type="text/javascript"></script>
　のようにして，web ページの header パートに css と javascript のファイルを読み込む。
(3) サンプルを使う場合には，サンプルの JavaScript の中の「import」文をすべて消す。
(4) 同じくサンプルを使う際には，
　　const raster = new TileLayer({
　　　source: new OSM()
　　});
　のような文の「TileLayer」や「OSM」をAPI document で調べて，「ol.layer.Tile」，「ol.source.OSM」のように以前からある形式に置き換える。

　OpenLayers 3 の頃からどのように記載が変わったかは，次回以降に書くことにしよう。

　変換が必要なものは，API document の中で，「ol/Feature~Feature」のように「~」付きで記載されているもの（だと思う）。ざっと並べると（全てではないかもしれない）

ol/AssertionError ～ AssertionError
ol/Collection ～ Collection
ol/Disposable ～ Disposable
ol/Feature ～ Feature
ol/Geolocation ～ Geolocation
ol/Graticule ～ Graticule
ol/ImageBase ～ ImageBase
ol/ImageTile ～ ImageTile
ol/Image ～ ImageWrapper
ol/Kinetic ～ Kinetic
ol/MapBrowserEvent ～ MapBrowserEvent
ol/MapEvent ～ MapEvent
ol/Map ～ Map
ol/Object ～ BaseObject
ol/Observable ～ Observable
ol/Overlay ～ Overlay
ol/PluggableMap ～ PluggableMap
ol/Tile ～ Tile
ol/VectorTile ～ VectorTile
ol/View ～ View
ol/WebGLMap ～ WebGLMap
ol/control/Attribution ～ Attribution
ol/control/Control ～ Control
ol/control/FullScreen ～ FullScreen
ol/control/MousePosition ～ MousePosition
ol/control/OverviewMap ～ OverviewMap
ol/control/Rotate ～ Rotate
ol/control/ScaleLine ～ ScaleLine
ol/control/ZoomSlider ～ ZoomSlider
ol/control/ZoomToExtent ～ ZoomToExtent
ol/control/Zoom ～ Zoom
ol/events/Event ～ Event
ol/events/Target ～ Target
ol/format/EsriJSON ～ EsriJSON
ol/format/Feature ～ FeatureFormat
ol/format/GML2 ～ GML2
ol/format/GML32 ～ GML32
ol/format/GML3 ～ GML3
ol/format/GMLBase ～ GMLBase
ol/format/GPX ～ GPX
ol/format/GeoJSON ～ GeoJSON
ol/format/IGC ～ IGC
ol/format/JSONFeature ～ JSONFeature
ol/format/KML ～ KML
ol/format/MVT ～ MVT
ol/format/OSMXML ～ OSMXML
ol/format/Polyline ～ Polyline
ol/format/TextFeature ～ TextFeature
ol/format/TopoJSON ～ TopoJSON
ol/format/WFS ～ WFS
ol/format/WKT ～ WKT
ol/format/WMSCapabilities ～ WMSCapabilities
ol/format/WMSGetFeatureInfo ～ WMSGetFeatureInfo
ol/format/WMTSCapabilities ～ WMTSCapabilities
ol/format/XMLFeature ～ XMLFeature
ol/format/XML ～ XML
ol/format/filter/Bbox ～ Bbox
ol/format/filter/ComparisonBinary ～ ComparisonBinary
ol/format/filter/Comparison ～ Comparison
ol/format/filter/Contains ～ Contains
ol/format/filter/During ～ During
ol/format/filter/EqualTo ～ EqualTo
ol/format/filter/Filter ～ Filter
ol/format/filter/GreaterThanOrEqualTo ～ GreaterThanOrEqualTo
ol/format/filter/GreaterThan ～ GreaterThan
ol/format/filter/Intersects ～ Intersects
ol/format/filter/IsBetween ～ IsBetween
ol/format/filter/IsLike ～ IsLike
ol/format/filter/IsNull ～ IsNull
ol/format/filter/LessThanOrEqualTo ～ LessThanOrEqualTo
ol/format/filter/LessThan ～ LessThan
ol/format/filter/LogicalNary ～ LogicalNary
ol/format/filter/NotEqualTo ～ NotEqualTo
ol/format/filter/Not ～ Not
ol/format/filter/Or ～ Or
ol/format/filter/Spatial ～ Spatial
ol/format/filter/Within ～ Within
ol/geom/Circle ～ Circle
ol/geom/GeometryCollection ～ GeometryCollection
ol/geom/Geometry ～ Geometry
ol/geom/LineString ～ LineString
ol/geom/LinearRing ～ LinearRing
ol/geom/MultiLineString ～ MultiLineString
ol/geom/MultiPoint ～ MultiPoint
ol/geom/MultiPolygon ～ MultiPolygon
ol/geom/Point ～ Point
ol/geom/Polygon ～ Polygon
ol/geom/SimpleGeometry ～ SimpleGeometry
ol/interaction/DoubleClickZoom ～ DoubleClickZoom
ol/interaction/DragAndDrop ～ DragAndDrop
ol/interaction/DragAndDrop ～ DragAndDropEvent
ol/interaction/DragBox ～ DragBox
ol/interaction/DragBox ～ DragBoxEvent
ol/interaction/DragPan ～ DragPan
ol/interaction/DragRotateAndZoom ～ DragRotateAndZoom
ol/interaction/DragRotate ～ DragRotate
ol/interaction/DragZoom ～ DragZoom
ol/interaction/Draw ～ Draw
ol/interaction/Draw ～ DrawEvent
ol/interaction/Extent ～ ExtentInteraction
ol/interaction/Extent ～ ExtentInteractionEvent
ol/interaction/Interaction ～ Interaction
ol/interaction/KeyboardPan ～ KeyboardPan
ol/interaction/KeyboardZoom ～ KeyboardZoom
ol/interaction/Modify ～ Modify
ol/interaction/MouseWheelZoom ～ MouseWheelZoom
ol/interaction/PinchRotate ～ PinchRotate
ol/interaction/PinchZoom ～ PinchZoom
ol/interaction/Pointer ～ PointerInteraction
ol/interaction/Select ～ Select
ol/interaction/Select ～ SelectEvent
ol/interaction/Snap ～ Snap
ol/interaction/Translate ～ Translate
ol/layer/Base ～ BaseLayer
ol/layer/Group ～ LayerGroup
ol/layer/Heatmap ～ Heatmap
ol/layer/Image ～ ImageLayer
ol/layer/Layer ～ Layer
ol/layer/Tile ～ TileLayer
ol/layer/VectorTile ～ VectorTileLayer
ol/layer/Vector ～ VectorLayer
ol/proj/Projection ～ Projection
ol/render/Event ～ RenderEvent
ol/render/Feature ～ RenderFeature
ol/render/VectorContext ～ VectorContext
ol/render/canvas/Immediate ～ CanvasImmediateRenderer
ol/render/webgl/Immediate ～ WebGLImmediateRenderer
ol/renderer/Layer ～ LayerRenderer
ol/renderer/Map ～ MapRenderer
ol/renderer/canvas/ImageLayer ～ CanvasImageLayerRenderer
ol/renderer/canvas/IntermediateCanvas ～ IntermediateCanvasRenderer
ol/renderer/canvas/Layer ～ CanvasLayerRenderer
ol/renderer/canvas/Map ～ CanvasMapRenderer
ol/renderer/canvas/TileLayer ～ CanvasTileLayerRenderer
ol/renderer/canvas/VectorLayer ～ CanvasVectorLayerRenderer
ol/renderer/canvas/VectorTileLayer ～ CanvasVectorTileLayerRenderer
ol/renderer/webgl/ImageLayer ～ WebGLImageLayerRenderer
ol/renderer/webgl/Layer ～ WebGLLayerRenderer
ol/renderer/webgl/Map ～ WebGLMapRenderer
ol/renderer/webgl/TileLayer ～ WebGLTileLayerRenderer
ol/renderer/webgl/VectorLayer ～ WebGLVectorLayerRenderer
ol/source/BingMaps ～ BingMaps
ol/source/CartoDB ～ CartoDB
ol/source/Cluster ～ Cluster
ol/source/ImageArcGISRest ～ ImageArcGISRest
ol/source/ImageCanvas ～ ImageCanvasSource
ol/source/ImageMapGuide ～ ImageMapGuide
ol/source/ImageStatic ～ Static
ol/source/ImageWMS ～ ImageWMS
ol/source/Image ～ ImageSource
ol/source/Image ～ ImageSourceEvent
ol/source/OSM ～ OSM
ol/source/Raster ～ RasterSource
ol/source/Raster ～ RasterSourceEvent
ol/source/Source ～ Source
ol/source/Stamen ～ Stamen
ol/source/TileArcGISRest ～ TileArcGISRest
ol/source/TileDebug ～ TileDebug
ol/source/TileImage ～ TileImage
ol/source/TileJSON ～ TileJSON
ol/source/TileWMS ～ TileWMS
ol/source/Tile ～ TileSource
ol/source/UTFGrid ～ UTFGrid
ol/source/UrlTile ～ UrlTile
ol/source/VectorTile ～ VectorTile
ol/source/Vector ～ VectorSource
ol/source/WMTS ～ WMTS
ol/source/XYZ ～ XYZ
ol/source/Zoomify ～ Zoomify
ol/structs/LRUCache ～ LRUCache
ol/style/AtlasManager ～ AtlasManager
ol/style/Circle ～ CircleStyle
ol/style/Fill ～ Fill
ol/style/IconImageCache ～ IconImageCache
ol/style/Icon ～ Icon
ol/style/Image ～ ImageStyle
ol/style/RegularShape ～ RegularShape
ol/style/Stroke ～ Stroke
ol/style/Style ～ Style
ol/style/Text ～ Text
ol/tilegrid/TileGrid ～ TileGrid
ol/tilegrid/WMTS ～ WMTSTileGrid
ol/webgl/Context ～ WebGLContext

FreeBSD に Perl の MaxMind::DB::Readers::XS モジュールをいれてみた

2019-03-10T18:16:00.000+09:00

前回 Perl モジュールの GeoIP2 を使う (on FreeBSD) として，GeoIP2 の使い方のメモを書いておいた。ところが，Perl の GeoIP2 モジュールを使うと，IP アドレスから住所情報を得るのが非常に遅い。複数件検索をかけると，日が暮れるんじゃないか？と思うぐらい遅い。そのことについて書こう。

　きっかけは，前回も書いたが，FreeBSD の ports ツリーから，「Geo::IP」用のエントリーが削除されたことに始まる。 Geo-IP は MaxMind 社のデータベースを使うためのモジュールで，これまで無料で使える精度のあまり高くない「GeoLite」データベースを使うのに利用していた。しかし，MaxMind 社がデータベースの構造を変えたみたいで，今後は「GeoIP2」を使え，というメッセージが出てきたので「GeoIP2」を使ってみた。それ自体はいいのだが，なにせデータの読み出しが遅い。ほんとに複数件の IP アドレスの住所情報を調べると，無限に時間がかかる感じがした。

　これをネットで調べると，どうも「MaxMind::DB::Readers::XS」を使うといいと出てくる。前回も書いたが，GeoIP2 をインストールすると，下記のようなものが一緒にインストールされる。

・GeoIP2
・GeoIP2::Database::Reader
・GeoIP2::Model::City
・/usr/local/lib/libmaxminddb.so

などがインストールされ，さらに

MaxMind::DB::Reader

がインストールされる。

　この，最後の，「MaxMind::DB::Reader」が実際にデータベースから情報を取出している。この「MaxMind::DB::Reader」を見ると，さらに「MaxMind::DB::Reader::PP」を読み出している。ここの「PP」は，PurePerl を意味し，Perl のルーチンのみで書かれている。そのため読み出しが非常に遅くなっているみたい。しかし，「MaxMind::DB::Reader」では「MaxMind::DB::Reader::PP」の代わりに「MaxMind::DB::Reader::XS」というのがあれば，そちらを優先的に読み込む，と書いてある。

　そこで，FreeBSD の ports を探してみると，ちゃんとあった。

/usr/ports/net/p5-MaxMind-DB-Reader-XS/

当初，meta::cpan からインストールしないといけない，と思って探したのだが，なかなか見つからなくて，困ってしまった。 GeoIP2 というのが入ってないので，わからなかったみたい。 MaxMind というキーワードで探すとすぐに見つかった。

　で，インストールすると，「MaxMind-DB-Reader-XS」は下記のディレクトリにインストールされていた。

/usr/local/lib/perl5/site_perl/mach/5.28/auto/MaxMind/DB/Reader/XS/XS.so
/usr/local/lib/perl5/site_perl/mach/5.28/MaxMind/DB/Reader/XS.pm
/usr/local/lib/perl5/site_perl/man/man3/MaxMind::DB::Reader::XS.3

ここで，XS.so は外部ライブラリで，これを使うから速いみたい。

　ちなみに「MaxMind-DB-Reader-PP」は下記にインストールされている。

/usr/local/lib/perl5/site_perl/MaxMind/DB/Reader/PP.pm

他にも「/usr/local/lib/perl5/site_perl/MaxMind/DB/」の下にいくつかインストールされていた。

Perl モジュールの GeoIP2 を使う (on FreeBSD)

2019-03-10T17:47:00.000+09:00

今回は，GeoIP2 を使った話を書こうと思う。

　きっかけは，FreeBSD の ports ツリーから，「Geo::IP」用のエントリーが削除されたことに始まる。確か「/usr/ports/net/p5-Geo-IP」だったかな？ Geo-IP は MaxMind 社のデータベースを使うためのモジュールで，これまで無料で使える精度のあまり高くない「GeoLite」データベースを使うのに利用していた。しかし，MaxMind 社がデータベースの構造を変えたみたいで，今後は「GeoIP2」を使え，というメッセージが出てきた。そこで，「GeoIP2」を使うべく，下記の perl モジュールをインストールしてみた。

/usr/ports/net/p5-GeoIP2/

　すると，インストールは簡単にできた。問題は使い方。これがわかるのに意外と手間取ってしまった。

　まず，ports から GeoIP2 をインストールすると，

・GeoIP2
・GeoIP2::Database::Reader
・GeoIP2::Model::City

などがインストールされ，さらに

/usr/local/lib/libmaxminddb.so

がインストールされる。
　さらに，これら以外に

MaxMind::DB::Reader

というモジュールがインストールされる。

　使い方やどのような関数が使えるか，は，「meta::cpan」の中の GeoIP2 のページ

https://metacpan.org/pod/GeoIP2::Database::Reader

と，そこからリンクが張ってある以下のような場所などに書いてある。

・https://metacpan.org/pod/GeoIP2::Model::City
・https://metacpan.org/pod/GeoIP2::Record::City
・https://metacpan.org/pod/GeoIP2::Record::Country
・https://metacpan.org/pod/GeoIP2::Record::Continent
・https://metacpan.org/pod/GeoIP2::Record::Location

　ここから，以下のようにすれば GeoIP2 を perl のスクリプトで使うことができる。

(1) スクリプトの中で，GeoIP2 の使用の宣言を行う

use GeoIP2::Database::Reader;

ここでは読み取りようのモジュールを読み込んでいる。

(2) 必要なデータベースをダウンロードしておく。

https://dev.maxmind.com/geoip/geoip2/geolite2

ここでは，無料の GeoLite2 をダウンロードしてみた。

(3) 読み取り用の変数の定義

my $reader = GeoIP2::Database::Reader->new(
    file    => 'xxxxxx/GeoIP2/GeoLite2-City/GeoLite2-City.mmdb',
    locales => [ 'ja', 'en', ]
    );

ここでは，$reader という変数を用意し，データベースファイルと言語を指定している。

(4) データの取得

if ($remote_address !~ /^192\.168\./) {
    my $record = $reader->city(ip => $remote_address);

    my $Latitude = $record->location()->latitude();
    my $Longitude = $record->location()->longitude();
    my $Country_Code = $record->continent()->name();
    my $Country = Encode::encode('utf8',$record->country()->name());
    my $Region = Encode::encode('utf8',$record->continent()->name());
    my $City = Encode::encode('utf8',$record->city()->name());
}

ここでは，IP アドレスから情報を得ている。そのために，IP を指定し，その情報を $record 変数に入れている。そこから，適度な関数を用いて，いろいろな値を読み出している。
　注意点として，ローカル用の IP アドレスだとエラーとなることがある点である。そのため，最初に if 文でローカル IP を避けている。

　データ構造が変わったため，読み出しの関数も微妙に変わっている。その情報が得られれば，GeoIP2 を使うのは難しくはない。

　しかし，FreeBSD で GeoIP2 をインストールすると，読み出しルーチンとして PurePerl のものしかインストールされない。これがとても遅くて，それが Geo-IP からなかなか GeoIP2 に移行できなかった理由だった。その辺りについては，次のエントリーに書こう。

FreeBSD を 12.0-RELEASE に上げたら，ssh でログインできなくなって困った件

2019-03-10T16:29:00.001+09:00

久しぶりに書き込むような気がするが，それは置いておいて，今回の話題について書こう。

　今回は FreeBSD の OS のバージョンを 11.2-RELEASE から 12.0-RELEASE に上げた，というお話。 12.0-RELEASE に上げる事自体はうまくいったのだが，その後，ssh でリモートからログインできなくなってしまった。そのことに着いて書こうと思う。

　始まりは FreeBSD の stable バージョンが 12.0-RELEASE になっていることに気づいたことから始まる。基本的に OS のバージョンは最新のものの方がいいと思っている。ただし，メジャーバージョンが上がるとトラブルも多いので，すぐにはアップグレードしない，というのが平民の考え方なのだが，12.0-RELEASE になってからはかなり時間が経っているので，今回はいいかなぁ？と思ってアップグレードしてみた。

　そこで，いつものように freebsd-update を使って，バージョンを上げてみた。まずは，下記の2個のコマンドでカーネルのアップグレードを行った。いつものように結構時間がかかる。

# freebsd-update upgrade -r 12.0-RELEASE
# /usr/sbin/freebsd-update install

それから，再起動して，もう一度

# /usr/sbin/freebsd-update install

でその他のソフトウェアのアップグレードを行う。
　その後に，pkg のアップグレードのために，「pkg」アプリ自体をアップグレードしてから，パッケージを作り直す。

# pkg-static install -f pkg
# pkg upgrade -y

というのが，いつもの手順。

　しかし，今回は，再起動後にリモートで (ssh で) ログインできなくなってしまった。 jail 環境へのログインはできるのに，host 環境へはログインできなかった。そこで，仕方なくコンソールの前に座って，直接ログインして作業することにした。

　まずは，etc/hosts.allow の書き換えで間違えたのか？と思ったので，hosts.allow の ssh の行を全て許可してみた。しかし，ログインできない。
次に，カーネル等のアップグレードで ipfw の設定が不適切になったのか，とも思ったが，「ipfw -a list」とするとちゃんと ssh のポートにアクセスされているのわかった（パケット数が増えたので）。となると，sshd の問題しか考えられない。

　そこで，/etc/ssh/sshd_config を見直してみた。少なくとも読み取りポートやらは以前の設定のままで，おかしいとは思われなかった。普段の ssh のログインには RSA 認証を使ってパスワード認証は許可してないのだが，認証の問題か？と思ったので，パスワード認証を復活させたみた。設定を書き換えて，ssh を再起動するとやっと問題が見えてきた。

# service sshd restart

　まず，ssh のサービスが起動していなかった。なんとも衝撃的だった。ssh が起動してないなんて…。でも，ssh が起動していない，というのは設定にミスがあるから，のはず。事実，起動させようとすると，以下のようなエラーが出た。

sshd_config line 30: Bad SSH2 cipher spec 'aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,arcfour'.

こんな行書いたっけ？と思って，設定を見てみると，確かに書いてあった。

# Ciphers and keying
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,arcfour
MACs hmac-sha1,hmac-ripemd160

どうやら，この「Cipherの指定項目」が不適切みたいだった。ネットでゴソゴソ調べてみると，以前からある「cbc，ssh1，64bit」を含む「Cipher」は指定するな，というもの以外に，「arcfor」を含むものも指定してはいけない，とどっかに書いてあった。以下に書いてあった：https://ja.wikipedia.org/wiki/RC4

　そこで，Cipher の行を「Ciphers aes128-ctr,aes192-ctr,aes256-ctr」としてみた。すると上記のエラーメッセージはでなくなった。しかし，今度は以下のようなエラーメッセージが出てきた。

/etc/ssh/sshd_config line 32: Bad SSH2 mac spec 'hmac-sha1,hmac-ripemd160'.

上記の Cipher の行のすぐ下の「MACs」という行も不適切みたい。これもネットでゴソゴソ調べてみたが，いまいちこれにしなさい，という記述が見つけられなかった。で，めんどくさいので，行全部をコメントアウトしてみた。そしたらうまく ssh が起動できた。どうも，security 上のリスクがあるので，「Cipher」と「MACs」の制限が厳しくなったみたい。

　最終的に sshd_config の Ciphers と MACs の部分は以下のようにして，sshd を再起動するとうまくログインすることができた。

# Ciphers and keying
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
#MACs hmac-sha1,hmac-ripemd160

しかし，こんな設定いつの間に入れたんやろ？全然記憶にない…。どっかの段階で入れた方がいいというのをどっかで聞いて入れたのかも…。

　その後，「pkg upgrade -y」としたのだが，その時に多くのアプリケーションソフトが消されてしまった。そのためにいくつかを入れ直さないといけなかった。

FreeBSD で nginx に挑戦してみた（その４：https 化と Digest 認証）

2018-09-26T23:46:00.001+09:00

前回，FreeBSD で nginx に挑戦してみた（その３）として，FreeBSD 上の nginx 設定の location コンテキストと，nginx で CGI を使うための方法について書いた。今回は，https 化 (ssl モジュール)と Digest 認証について書いていこう。

http_ssl モジュールと https

https 化を行うには，まず nginx のインストール時に http_ssl モジュールを組み込まないといけない。そのためには

--with-http_ssl_module

オプションをつけてインストールしないといけない。 FreeBSD で /usr/ports/www/nginx/ からインストールする際には「HTTP_SSL」オプションをつけておかないといけない。

　そして，以下のように設定ファイル（ /usr/local/etc/nginx/nginx.conf ）に記載する必要がある。下記の設定の青色の辺りがその設定部分である。設定ファイル自体は前回示した CGI を使う場合の設定ファイルに https 化の部分（ server ディレクティブ）を追加している。そのため，通常の 80 番ポートへのリクエストを受信する server ディレクティブも残してある。

（nginx 設定ファイル：https の例）
user www www;
worker_processes  2;
error_log  /var/log/nginx/error.log error;
pid        /var/run/nginx.pid;
# ==================================================================
events {
    worker_connections  500;
    use                 kqueue;
}
# ==================================================================
http {
    server_tokens      off;
    include            mime.types;
    default_type       application/octet-stream;
    charset            UTF-8;
    sendfile           on;
    tcp_nopush         on;
    keepalive_timeout  75;
    gzip               on;

    root   /usr/local/www/data;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log         /var/log/nginx/access.log  main;
    error_page  401              /401.html;
    error_page  403 404          /404.html;
    error_page  500 502 503 504  /50x.html;
    # ---------------------------------------------------------
    server {
        listen       80 default_server;
        server_name  www.xxxxx.com yyy.xxxxx.com zzz.xxxxx.com;
        location / {
             index  index.html /index.html;
        }
        location ~ \.cgi$ {
            include        fastcgi_params;
            fastcgi_pass   unix:/var/run/fcgiwrap/fcgiwrap.socket;
            fastcgi_index  index.cgi;
            fastcgi_param  SCRIPT_FILENAME  /usr/local/www/data$fastcgi_script_name;
        }
    }
    # ---------------------------------------------------------
    server {
        listen               443 ssl http2 default_server;
        server_name          www.xxxxx.com yyy.xxxxx.com zzz.xxxxx.com;
        ssl_certificate      /usr/local/etc/letsencrypt/live/www.xxxxx.com/fullchain.pem;
        ssl_certificate_key  /usr/local/etc/letsencrypt/live/www.xxxxx.com/privkey.pem;

        access_log /var/log/nginx/https_xxxxxx_access.log main;
        error_log  /var/log/nginx/https_xxxxxx_error.log error;

        location ~ /\.ht {
            deny all;
        }

        location ~ \.cgi$ {
            include        fastcgi_params;
            fastcgi_pass   unix:/var/run/fcgiwrap/fcgiwrap.socket;
            fastcgi_index  index.cgi;
            fastcgi_param  SCRIPT_FILENAME  /usr/local/www/data$fastcgi_script_name;
        }
        location / {
            index  index.html index.cgi /index.html;
        }
    }
}

・まず，listen ディレクティブに「443 ssl http2 default_server;」と記載している。これは通常の https 受信ポートである「443番ポート」を受信し，SSL モードを用いた通信を行い，HTTP/2 接続を行うことを意味する。さらに「default_server」にも指定している。最低限「443 ssl」があれば https での受信は問題なく行われる。http2 と default_server は付加的につけている。

・server_name ディレクティブは，80番ポートの場合と同じなので，ここでは説明しない（FreeBSD で nginx に挑戦してみた（その２：nginx の設定と初起動）を見てほしい）。

その次の2個のディレクティブが重要である。
・ssl_certificate ディレクティブと ssl_certificate_key ディレクティブが SSL モードに必須のサーバーの証明書であり，今回は Let's Encrypt による PEM 形式の認証ファイルを指定している。 Let's Encrypt についてはMyDNS と Let's Encrypt を使って，FreeBSD 上の apache24 を https 化してみた（その3）を見てみて欲しい。
　ここでは，「/usr/local/etc/letsencrypt/live/www.xxxxx.com/」（www.xxxxx.com は server_name ディレクティブで指定したいずれかのサーバー名）にある「fullchain.pem」と「privkey.pem」を指定している。

・他にも，80番ポートとは別にアクセスログとエラーログを記載するために，それぞれファイル名を指定している。

・その他に「location ~ /\.ht」と書かれた location ディレクティブがあるが，これは「.htaccess」を無効にするためのおまじないである。

Digest 認証

　nginx の公式サイトには，Basic 認証のモジュールの説明はあるが，Digest 認証の説明はない。 nginx では Digest 認証はサードパーティー製モジュールとして存在してる。そのため nginx-http-auth-digest をインストールしないといけない。 FreeBSD の /usr/ports/www/nginx/ からインストールする場合には「HTTP_AUTH_DIGEST」オプションをつけてインストールすれば組み込まれる。

　下記に設定ファイル（/usr/local/etc/nginx/nginx.conf ）の例を書いておこう。今回も青色の部分が上に書いた設定ファイルからの変更点である。

（nginx 設定ファイル：Digest 認証の例）
user www www;
worker_processes  2;
load_module /usr/local/libexec/nginx/ngx_http_auth_digest_module.so;
error_log  /var/log/nginx/error.log error;
pid        /var/run/nginx.pid;
# ==================================================================
events {
    worker_connections  500;
    use                 kqueue;
}
# ==================================================================
http {
    server_tokens      off;
    include            mime.types;
    default_type       application/octet-stream;
    charset            UTF-8;
    sendfile           on;
    tcp_nopush         on;
    keepalive_timeout  75;
    gzip               on;

    root   /usr/local/www/data;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log         /var/log/nginx/access.log  main;
    error_page  401              /401.html;
    error_page  403 404          /404.html;
    error_page  500 502 503 504  /50x.html;
    # ---------------------------------------------------------
    server {
        listen       80 default_server;
        server_name  www.xxxxx.com yyy.xxxxx.com zzz.xxxxx.com;
        location / {
             index  index.html /index.html;
        }
        location ~ \.cgi$ {
            include        fastcgi_params;
            fastcgi_pass   unix:/var/run/fcgiwrap/fcgiwrap.socket;
            fastcgi_index  index.cgi;
            fastcgi_param  SCRIPT_FILENAME  /usr/local/www/data$fastcgi_script_name;
        }
    }
    # ---------------------------------------------------------
    server {
        listen               443 ssl http2 default_server;
        server_name          www.xxxxx.com yyy.xxxxx.com zzz.xxxxx.com;
        ssl_certificate      /usr/local/etc/letsencrypt/live/www.xxxxx.com/fullchain.pem;
        ssl_certificate_key  /usr/local/etc/letsencrypt/live/www.xxxxx.com/privkey.pem;

        auth_digest_shm_size  10m; # default 4m, auth_digest 用のメモリ
        auth_digest_expires 10s; # default 10 s，一度認証に成功したものの再利用時間
        auth_digest_replays 1024;  # default 20 times，一度認証に成功したものの再利用回数上限
        auth_digest_evasion_time 60s; # default 300s，auth_digest_maxtries で指定した回数だけ失敗した時の不能時間
        auth_digest_maxtries 50; # default 5 times，evasion になるまでの失敗数

        client_max_body_size 200m;

        access_log /var/log/nginx/https_xxxxxx_access.log main;
        error_log  /var/log/nginx/https_xxxxxx_error.log error;

        location ~ /\.ht {
            deny all;
        }

        location ~ ^/punipuni/cgi-bin {
            index          index.html index.cgi /index.html;
            auth_digest    'Secret Zone';
            auth_digest_user_file /usr/local/.htdigest;
            include        fastcgi_params;
            fastcgi_pass   unix:/var/run/fcgiwrap/fcgiwrap.socket;
            fastcgi_index  index.cgi;
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        }
        location ~ \.cgi$ {
            include        fastcgi_params;
            fastcgi_pass   unix:/var/run/fcgiwrap/fcgiwrap.socket;
            fastcgi_index  index.cgi;
            fastcgi_param  SCRIPT_FILENAME  /usr/local/www/data$fastcgi_script_name;
        }
        location ~ ^/punipuni {
            auth_digest 'Secret Zone';
            auth_digest_user_file /usr/local/.htdigest;
        }
        location / {
            index  index.html index.cgi /index.html;
        }
    }
}

　ここでも上から順に新しい項目について説明していこう。

・load_module ディレクティブでは「ngx_http_auth_digest_module.so」を読み込ませている。これは「ngx_http_auth_digest_module」が「動的モジュール」のため，インストールはされたが（モジュールは作られたが）設定ファイルで読み込まないと起動時に読み込まれないから，である。

・「443 ssl」と書かれた server ディレクティブの中にある auth_digest_shm_size, auth_digest_expires, auth_digest_replays, auth_digest_evasion_time, auth_digest_maxtries や，下の方にある location ディレクティブの中にある auth_digest, auth_digest_user_file は，いずれも nginx-http-auth-digest の下の方に説明があるので，詳しくはそちらを見て欲しい。

これらは auth_digest_shm_size 以外は，すべて server のコンテキストと location のコンテキストに記載ができる。 auth_digest_shm_size だけは server のコンテキストしか記載が許されていない。

「443 ssl」と書かれた server ディレクティブの中にある auth_digest_shm_size, auth_digest_expires, auth_digest_replays, auth_digest_evasion_time, auth_digest_maxtries はそれぞれコメントに書いておいたが，
・auth_digest_shm_size は，auth_digest 用のメモリであり，デフォルト値は 4m (4MB) である。
・auth_digest_expires は，一度認証に成功したものの再利用時間であり，デフォルト値は 10 秒である。
・auth_digest_replays は，一度成功したものの再利用回数上限であり，デフォルト値は 20 回である。

順序が逆になるが，
・auth_digest_maxtries は，evasion モード（回避モード）になるまでに許される失敗の回数であり，デフォルト値は5回である。
・auth_digest_evasion_time は，evasion モード（回避モード）になった時の接続不能時間であり，デフォルト値は 300 秒である。
evasion（回避）モードに入ると，auth_digest_evasion_time で指定される時間は Digest 認証に挑戦させてくれず，サーバーが止まったように見えてしまう。これが頻繁に起こると，接続に異常に長い時間がかかる，という状態に陥る。
　それを避けるには，auth_digest_replays の値を大きな値にすればいいみたい。なので，ここでは 1024 に設定してある。

下の方にある location ディレクティブの中にある auth_digest と auth_digest_user_file はそれぞれ下記のような意味がある。
・auth_digest は Digest 認証の ON/OFF を示し，ON にしたければ「realm（分野）値」を記載し，OFF にしたければ「off」と書けばよい。
・auth_digest_user_file は，Digest 認証のユーザー名とパスワードが入ったファイル名であり，そのファイルは web で通常アクセスされないディレクトリに置くのがよい。

　最後に，client_max_body_size ディレクティブは，クライアントからのリクエスト時のパケットのサイズの上限を決めている。デフォルト値は 1m (1 MB) である。通常は 1 MB で問題ないと思うが，ファイルのアップロードをさせたい時にはそれなりに大きな値が欲しい。ここでは 100m (100 MB) に設定している。

　今回は https 化の設定と，Digest 認証について書いてみた。一度お試しあれ。

FreeBSD で nginx に挑戦してみた（その３：location コンテキストと CGI）

2018-09-20T06:00:00.000+09:00

前回，FreeBSD で nginx に挑戦してみた（その２）として，FreeBSD 上の nginx の主な設定と起動の方法について書いた。今回は，location コンテキストと CGI について書いていこう。

location コンテキスト

まず location コンテキストの公式の説明は下記を見て欲しい。
　・location コンテキスト：Module ngx_http_core_module の location 項目

location コンテキストは，nginx.conf（それ自体が main コンテキストとなっている）の中の http コンテキストの中の server コンテキストの中に置かれるコンテキストである（言葉で書くとややこしいなぁ…）。前回を見て欲しいが，nginx.conf では，http コンテキストで web サーバーとしての設定を記載する。その中には，複数の（仮想）サーバー（バーチャルホスト）を列挙することができ，（仮想）サーバー1個ごとに1つの server コンテキストを記載する。 server コンテキストの中では，どのポート宛のものに応答するかや，どのサーバー名宛のリクエストに応答するか，などを記載するが，その server に対するリクエスト URI（ server 中の特定のディレクトリや特定の拡張子を持つファイルへのアクセス等を記載）にどのように応答するか，を記載するのが location コンテキストである。そのため location コンテキストは通常は server コンテキスト中に複数（多数）存在することになる。

　以下に location コンテキストのパターンを書こう（公式ドキュメントの location 項目の記載をそのまま手コピーしただけだが…）

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /documents/ {
    [ configuration C ]
}

location ^~ /images/ {
    [ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E ]
}

　location コンテキストは，第1パラメーターとして「一致条件（(修飾子+)URI）」を必要とする。リクエスト URI がこの一致条件に合致すれば，その location コンテキストの内容が適用される。

　一致条件には大きく分けて2種類あり，「接頭辞文字列」(prefix string) と「正規表現」がある。修飾子が「~」あるいは「~*」の場合は正規表現とみなされ，それ以外の修飾子（「=」，「^~」，(なし)）の場合は接頭辞文字列とみなされる。

正規表現の場合，修飾子「~*」は大文字小文字を区別せず，「~」の場合は大文字小文字を区別する正規表現として，合致するかどうかが判断される。

「=」修飾子の接頭辞文字列の場合は，リクエスト URI と完全に一致した時に合致したとみなされる（完全一致）。
他の接頭辞文字列の場合，リクエスト URI の先頭から接頭辞文字列に一致していれば，後ろには何が続いても合致するとみなされる（前方一致）。

　nginx では，要求された URI に対して，複数ある location コンテキストの一致条件を検索する。

(1) 一番優先度が高いのが「=」修飾子を持つ接頭辞文字列の場合であり，
　　記載順に検索して最初に一致した「=」接頭辞文字列の場合の location コンテキストの設定が適用される。

(2) 次にその他の接頭辞文字列条件を「すべて」検索し，「最も長く一致する」接頭辞文字列の場合を「記憶」しておく。
　　ここで最も長く一致する接頭辞文字列が「^~」修飾子を持つ場合は，その location コンテキストの設定が適用される。

(3) その次に正規表現で合致するものを，記載順（上から順）に調べていき，
　　最初に一致した正規表現を持つ location コンテキストの設定が適用される。

(4) 正規表現で合致するものがなければ，接頭辞文字列で
　　一番長く一致した location コンテキストの設定が適用される。

　上記の表の例だと，「/」のみのリクエストなら，設定「A」が適用される。「/index.html」なら設定「B」になる。「/documents/document.html」なら設定「C」になり，「/images/1.gif」なら「D」，「/documents/1.jpg」なら「E」が適用される。

　この判定条件がわかっていないと，nginx の設定をしてもうまく動作しない，ということになってしまう。

nginx における CGI

　nginx で CGI を使うには，(1) nginx に FCGI モジュールを組み込み，(2) fcgiwrap アプリを用いればよい。この場合，nginx と fcgiwrap の間のやりとりは unix domain socket を通じて行う。ちまたでは，fcgiwrap の他に spawn-fcgi も必要と書いてあることがあるが，unix domain socket を使う場合にはいらないみたい。

　nginx 自体は CGI を使うためのモジュールはもっていない。その代わり FastCGI (FCGI) のモジュールが公式にサポートされている。 nginx で fcgi を使うには，インストール時に fcgi モジュールを組み込んでおかないといけないが，FreeBSD の /usr/ports/www/nginx/ からインストールした場合には，make config の際に fcgi モジュールを選ぶ選択肢はなかったので，最初から組み込まれるようになっているような気がする。そのため，今回は特に何かをしないといけない，ということはなかった。

　fcgiwrap は cgi を fcgi で使えるようにするものであり，ほとんどの場合，cgi のスクリプトをそのまま実行してくれる。 FreeBSD では /usr/ports/www/fcgiwrap/ からインストールできる。インストール後，/etc/rc.conf に以下を追加した。

fcgiwrap_enable="YES"
fcgiwrap_user="www"
fcgiwrap_socket_owner="www"
fcgiwrap_socket="unix:/var/run/fcgiwrap/fcgiwrap.socket"

　ここで user と socket_owner を共に www にしている。これは nginx と fcgiwrap の間で socket をやり取りする際に，同じ user，owner でなければうまくいかなかったから，である。最後の行が unix domain socket を使う，と宣言してるようなもの，だと思っている（実はわかってない…）

　rc.conf の中に /var/run/fcgiwrap/ というディレクトリが出てくるので，念のために「/var/run/fcgiwrap/」を作り，permission を 777 にしておいた。

後は，以下のようにして起動すれば準備できあがり，である。

# service fcgiwrap start

CGI を使うための nginx の設定

　以下に CGI を使うための nginx.conf の簡単な例を載せよう。前回書いた設定ファイルの例と違う部分に色を付けてみた。赤い部分は，fcgi とは直接関係はなく，青い部分が fcgi に関連している。説明は設定例の下で書こう。

（nginx 設定ファイル：CGI を使う例）
user www www;
worker_processes  2;
error_log  /var/log/nginx/error.log error;
pid        /var/run/nginx.pid;
# ==================================================================
events {
    worker_connections  500;
    use                 kqueue;
}
# ==================================================================
http {
    server_tokens      off;
    include            mime.types;
    default_type       application/octet-stream;
    charset            UTF-8;
    sendfile           on;
    tcp_nopush         on;
    keepalive_timeout  75;
    gzip               on;

    root   /usr/local/www/data;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log         /var/log/nginx/access.log  main;
    error_page  401              /401.html;
    error_page  403 404          /404.html;
    error_page  500 502 503 504  /50x.html;
    # ---------------------------------------------------------
    server {
        listen       80 default_server;
        server_name  www.xxxxx.com yyy.xxxxx.com zzz.xxxxx.com;
        location / {
             index  index.html /index.html;
        }
        location ~ \.cgi$ {
            include        fastcgi_params;
            fastcgi_pass   unix:/var/run/fcgiwrap/fcgiwrap.socket;
            fastcgi_index  index.cgi;
            fastcgi_param  SCRIPT_FILENAME  /usr/local/www/data$fastcgi_script_name;
        }
    }
}

まずは，fcgi に関連する青い部分について書こう。と言っても，あまり説明するところはないが…。

最初に，location コンテキストの一致条件は「正規表現」で与えられ，リクエスト URI が「.cgi」で終わっている場合に適用される。それ以外は一個上の「/」を「接頭辞文字列」として持つ location コンテキストの設定が適用される。

次に「fastcgi_params」を読み込んで (include) いる。これは FreeBSD の場合 /usr/local/etc/nginx/ の下にインストール時に入れられていた fcgi の設定ファイルみたい。今回はいじってないので，中身は書かないでおこう。

・fastcgi_pass ディレクティブは，nginx と fcgi モジュール間の通信のルートを示していて，ここでは fcgiwrap の設定と同じ unix domain socket を指定している。unix domain socket 以外には IP + port 番号で指定することもできる。location のコンテキストと，location コンテキスト中の if ディレクティブに記載できる。

・fastcgi_index ディレクティブは，cgi (fcgi) のリクエスト URI がスラッシュで終わっている場合のデフォルトのファイルのファイル名である。location のコンテキストと，location コンテキスト中の if ディレクティブに記載できる。

・fastcgi_param ディレクティブは，第一パラメーターに指定したい「パラメーター名」を書き，第２パラメーターに「値」を書く。今回の例では「SCRIPT_FILENAME」を指定している。具体的には，FCGI は必ず「/usr/local/www/data」の下にあり，リクエスト URI が，例えば「/info/」なら，「/usr/local/www/data/info/index.cgi」となる（直前の「fcgi_index」と組み合わせている）。リクエスト URI が「/cgi/hello.cgi」なら「/usr/local/www/data/cgi/hello.cgi」が「SCRIPT_FILENAME」に入れられる。http，server，location のコンテキストに記載できる。

赤い部分は前回書いた設定ファイルの例と違う部分であり，「root」は，全仮想サーバーに共通で「/usr/local/www/data」に置くという指示である。

・error_page ディレクティブは，エラー番号ごとに表示するファイルを指定している。省略するとデフォルトのエラーメッセージが web ページ上に表示されるが，nginx のデフォルトの場合にエラーページに「nginx」と出るので，それが出ないようにページを作っている。また，403 エラーの時には 404 と同じエラーページを表示するようにしている。http，server，location のコンテキストと，location コンテキスト中の if ディレクティブに記載できる。

　私の場合は，これで cgi を動かすことができた。特にトラブルはなかったように思う。

次回は https 化と Digest 認証について記載しよう。
FreeBSD で nginx に挑戦してみた（その４）に続く

FreeBSD で nginx に挑戦してみた（その２：nginx の設定と初起動）

2018-09-15T01:08:00.003+09:00

前回，FreeBSD で nginx に挑戦してみた（その１）として，FreeBSD に nginx をインストールする話を書いた。今回は，設定について書いていこう。

nginx の設定ファイルの場所と起動方法

　nginx の設定ファイルは，FreeBSD の場合は，

/usr/local/etc/nginx/

の下に置かれる。ここにほぼすべての設定を書くイメージになるが，メインとなる設定は

/usr/local/etc/nginx/nginx.conf

である。

　その設定ファイルの前に，FreeBSD での起動方法について書いておこう。
FreeBSD では，まず /etc/rc.conf に以下を書かないといけない。

nginx_enable="YES"

これがないと，下記の起動コマンドを入れても起動してくれない。
　逆に，これを書いておくと，FreeBSD の起動時に nginx を自動で起動してくれる。

　起動や停止は，以下のように打てばよい。

　起動：service nginx start
　停止：service nginx stop
再起動：service nginx restart
再読込：service nginx reload

nginx 設定ファイルの構成要素：ディレクティブとコンテキスト

　さて，いよいよ nginx の設定ファイルの内容について書こう。これが結構量が多い。ここでの話は Beginner’s Guide の中の「Configuration File’s Structure」に書いてある。

　まず，設定ファイル（/usr/local/etc/nginx/nginx.conf）の構成要素について書こう。
設定ファイルには，いろんな設定項目と指定する値を書き並べる。この設定項目を表す単語をディレクティブ（命令）と呼ぶ。各ディレクティブは，値のみを持つ場合とブロック（{と}で囲まれている）を持つ場合がある。値のみを持つ場合を「シンプルディレクティブ」と呼ぶ。シンプルディレクティブはセミコロン(;)で終端する。

（シンプルディレクティブの例）
    include            mime.types;

ブロックを取る場合を「ブロックディレクティブ」と呼ぶ。しかし，ブロックディレクティブは多くの場合（私がみた限りは全部そうなのだが…），中にさらにディレクティブを書き並べて，階層構造を作っている。このような階層構造になっているブロックディレクティブのことを「コンテキスト」と呼ぶらしい。

（コンテキストの例）
    location / {
        root /data/www;
    }

nginx 設定ファイルの構造

　設定ファイル (nginx.conf) は，それ自体がコンテキストであり，「main コンテキスト」と呼ばれる。 main コンテキストは以下のような構造を取る。

(main コンテキストの構造)
シンプルディレクティブ
シンプルディレクティブ
・・・

events{
　（events の設定：接続処理関連）
}

http{
　（http の設定：web サーバーの設定）
}

mail{
　（mail の設定：mail サーバーの設定）
}

stream{
　（stream の設定：TCP/UDP 関連の設定）
}

　ここの先頭に並ぶシンプルディレクティブは，nginx 全体の設定（主にcore モジュールの設定かな？）を行っている。また，events コンテキストは，接続処理関連のディレクティブを入れる場所みたいである。 http コンテキストは，サーバーの設定を書くコンテキストであり，ほとんどの設定はこの中に書かれると言ってもいいぐらいである。 mail コンテキストと stream コンテキストについては，まだ全然わかっていないので，今回は書かないつもりである。それぞれの項目については，それぞれ以下のページに詳しいことが書いてある。
　・シンプルディレクティブ：Core functionality
　・events コンテキスト：Core functionality の events 項目
　・http コンテキスト：Module ngx_http_core_module の http 項目
　・mail コンテキスト：Module ngx_mail_core_module の mail 項目
　・stream コンテキスト：Module ngx_stream_core_module の stream 項目

特定のディレクティブの内容を知りたい時は，以下のリストからたどると簡単に説明にたどり着くことができる（英語だけど…）。
　Alphabetical index of directives：ディレクティブをアルファベット順に並べたリスト（サードパーティ製を除く）

ちなみにこんなリストもある。
　Alphabetical index of variables：変数をアルファベット順に並べたリスト（サードパーティ製を除く）

次に http コンテキストの概略を示そう。

http コンテキストの構造

　http コンテキストは，web サーバーとしての設定を行う。構造としては，下記のような構造をとる。

http {
（サーバー共通の設定）

　server {
　　（仮想サーバー1に共通の設定）
　　location {
　　　（locationの設定）
　　}
　　location {
　　　（location 2の設定）
　　}
　　・・・・・（必要ならもっと続く…）
　} # server

　server {
　　（仮想サーバー2に共通の設定）
　　location {
　　　（locationの設定）
　　}
　　location {
　　　（location 2の設定）
　　}
　　・・・・・（必要ならもっと続く…）
　} # server

　・・・・・（必要ならもっと続く…）
} # http

　http コンテキストは，web サーバーの設定を記述する場所であり，先頭にサーバー全体に共通する設定を記載する。その後に server コンテキストとして，複数設定可能なサーバー（仮想サーバーを含む）の設定を記載する。本来の web サーバーも仮想 web サーバーも特に区別はなく，ある意味すべてが仮想サーバーと考えるみたい。後で記載する server_name ディレクティブに記載したサーバー名がそのサーバーの名前なので， server_name ディレクティブに本来持つ URL を記載すればそれが通常のサーバーとなる（みたい）。（仮想）サーバーが複数ある時には，この server コンテキストが複数並ぶことになる。 server コンテキストは，ポート番号ごと，仮想サーバーごとに必要となる。

　server コンテキストの中では，各仮想サーバーの設定を記載する先頭には仮想サーバー全体の設定を記載し，その他に複数の location コンテキストが並ぶ。この location コンテキストは，仮想サーバー内の特定のディレクトリや特定のファイル，あるいは特定の拡張子を持つファイルに対する処理を記載する。 location コンテキストの記載は，いろんなことをさせようとすると，とても多くなったりする。

　・server コンテキスト：Module ngx_http_core_module の server 項目
　・location コンテキスト：Module ngx_http_core_module の location 項目

　location コンテキストについては次回以降に記載しよう。

nginx 設定ファイル：シンプルな例

　これまでは，一般的な設定ファイルの定義や構造の話だったが，一度具体例を示しておこう。以下が比較的シンプルな nginx の設定ファイルである。

（nginx 設定ファイルのシンプルな例）
user www www;
worker_processes  2;  # cpu has 4 cores
error_log  /var/log/nginx/error.log error;
pid        /var/run/nginx.pid;
# ==================================================================
events {
    worker_connections  500;
    use                 kqueue;
}
# ==================================================================
http {
    server_tokens      off;
    include            mime.types;
    default_type       application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log         /var/log/nginx/access.log  main;
    charset            UTF-8;
    sendfile           on;
    tcp_nopush         on;
    keepalive_timeout  75;
    gzip               on;
    # ---------------------------------------------------------
    server {
        listen       80 default_server;
        server_name  www.xxxxx.com yyy.xxxxx.com zzz.xxxxx.com;
        location / {
            root   /usr/local/www/data;
            index  index.html /index.html;
        }
    }
}

　かなり多くの項目があるが，困ったことにこれでもシンプルな方である…。
ちなみに，公式サイトには「完全な」サンプルが載っている。
https://www.nginx.com/resources/wiki/start/topics/examples/full/

　今回の例を上から少し説明しておこう。項目の先頭にある各ディレクティブ名は，公式サイトの記載ページ（英語）へのリンクをつけている。

・user ディレクティブは web サーバープロセスのオーナーアカウントとグループである。ここではアカウント名もグループ名も「www」としている。グループ名は省略することが可能である。記載できるのは main コンテキストのみである。

・worker_processes ディレクティブは，nginx で起動するプロセス数であり，CPU のコア数やハードディスクの数などで決まるが，よく使われるのが CPU のコア数と同じにする作戦である。コアが4個なら4とするらしい。数字が少々大きくても特に問題はないみたい。「auto」という選択肢もある。記載できるのは main コンテキストのみである。

・error_log ディレクティブは，エラーログを記載するファイル名を指定する。2個めのパラメーターはログレベルを表し，debug, info, notice, warn, error, crit, alert, emerg の値を取りうる。この中では debug が一番情報が多いが，その分多くのファイルサイズを必要とする。「error」レベルなら，エラーがあった場合にログに記載される。「info」なら，なにかあるごとに記載される感じがする。このパラメーターは省略可能であり，省略するとデフォルトの「error」レベルとなる。 main，http，mail，stream，server，location のコンテキストに記載できる（どこにでも書ける感じ）。

・pid ディレクティブは「pid」(process ID) を記載するファイル名を指定する。記載できるのは main コンテキストのみである。

・worker_connections ディレクティブは，一つの worker_process に一度に接続できる接続数の最大値である。この数が接続の上限を決めることになる。記載できるのは events コンテキストのみである。

・use ディレクティブは，接続方法を指定する。通常は一番効率のいい接続方法を自動で選ぶので，記載の必然性はないみたい。FreeBSD なら「kqueue」，Linux なら「epoll」がいいらしい。記載できるのは events コンテキストのみである。

・server_tokens ディレクティブは，web サーバーとしてクライアントに送り返す server response header フィールドに「nginx」の文字列や，ビルド番号を記載するかどうかを指定する。「on」なら nginx を記載，「off」なら記載しない。「build」ならビルド番号も記載するみたい。コマーシャル版なら「string」として特定の文字列を記載することも可能みたい。 http，server，location のコンテキストに記載できる。

・include ディレクティブは，他のファイルを読み込みたい時に記載する。ここでは「mime type」を記載したファイルを読み込むことを指示している。ワイルドカードで指定することもできるらしい。どのコンテキストにも記載可能である。

（include の例）
    include mime.types;
    include vhosts/*.conf;

・default_type ディレクティブは，デフォルトの MIME タイプを記載する。types ディレクティブに記載した中から選べるが，普通は mime.types ファイルを読み込み，その中にある MIME タイプを選択する。http，server，location のコンテキストに記載できる。

・log_format ディレクティブは，ログに記載する項目を指定する。ここでは，「main」という名称でログの記載項目を定義している。指定をしなくても「combined」という名称で定義されたものが予め定義されているらしい。

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

記載できるのは http コンテキストのみである。

・access_log ディレクティブは，アクセスログのファイル名と，log_format ディレクティブで定義したログフォーマットの定義名を記載する。 http，server，location のコンテキストと，location コンテキスト中の if ディレクティブに記載できる。

・charset ディレクティブは，web サーバーとしてのレスポンスの Content-Type”response header フィールドに出力する character set を指定する。http，server，location のコンテキストと，location コンテキスト中の if ディレクティブに記載できる。

・sendfile ディレクティブは，「sendfile()」API を使用するかどうか，を指示する。 sendfile()を使うとカーネル空間内でファイルの読込みと送信が完了するため、効率良くファイルをクライアントに送信できるらしい…。よくわからん…。FreeBSD では使うといいみたい。Linux でも意味はあるかもしれないが，記載がないのでよくわからない…。デフォルトでは off である。 http，server，location のコンテキストと，location コンテキスト中の if ディレクティブに記載できる。

・tcp_nopush ディレクティブは，FreeBSD なら TCP_NOPUSH ソケットを使うかどうかを指定する。Linux なら TCP_CORK ソケットを使うかどうかの指定になる。これは sendfile ディレクティブが on になっている時のみ有効となる。http，server，location のコンテキストに記載できる。

・keepalive_timeout ディレクティブは，クライアント keep-alive 接続のサーバー側でのアクティブ時間を指定する。ゼロなら keep-alive 接続は無効になる。http，server，location のコンテキストに記載できる。

・gzip ディレクティブは，サーバーとしての応答の際に gzip で圧縮するかどうかを指定する。 http，server，location のコンテキストと，location コンテキスト中の if ディレクティブに記載できる。

・listen ディレクティブは，サーバーとして受け取る IP アドレスやポート番号を指定する。

（listen の例）
listen 127.0.0.1:8000;
listen 127.0.0.1;
listen 8000;
listen *:8000;
listen localhost:8000;
listen unix:/var/run/nginx.sock;

最後の例は UNIX-domain sockets を受け取る指定である（実はあまりわかってない…）。
2番目以降のオプションに「ssl」をつけると，https 接続を指定することになる。「http2」オプションをつけると，HTTP/2 接続を受け付ける。「default_server」を指定すると，なにかあった際にはその仮想サーバー名で接続しようとする。省略すると最初に定義された仮想サーバーがデフォルトサーバーとなる。default_server は同じポート番号に対して1個のみ指定できる。
このディレクティブはオプションも多いので，listen を読んでみてほしい。記載できるのは server コンテキストのみである。

・server_name ディレクティブは，仮想サーバーとしてサーバー名を指定する。これがなければサーバーマシンが本来持っているサーバー名を持つサイトを意味する。記載できるのは server コンテキストのみである。

・root ディレクティブは，そのコンテキストに対するルート PATH を指定する。例えば，

    location /i/ {
        root /data/w3;
    }

とあれば，“/i/top.gif”というリクエストに対して，「/data/w3/i/top.gif」を返す。パスは「$document_root」や「$realpath_root」などの変数で指定も可能である。 http，server，location のコンテキストと，location コンテキスト中の if ディレクティブに記載できる。

・index ディレクティブは，リクエストが「/」で終わっている時に，index として与えるファイル名を指定する。今回の例なら，まずは index.html を探し，なければルートディレクトリの index.html を指定することになる。 http，server，location のコンテキストに記載できる。

nginx を起動してみよう

　他の設定ファイルは，とりあえずいじらなくてもいい。となれば，「service nginx start」として起動してみよう。

（起動の成功例）
# service nginx start
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Starting nginx.

このようになれば，うまく起動できている。

# cat /var/run/nginx.pid

として，process ID を表示できるはずである。

　アクセスしてみると，以下のようなものが表示されるはずである（最後の test9 という文字列は私が加えたもの）。

　再起動させると以下のようになる。設定ファルのチェックをしてからプロセスを止め，もう一度設定ファルをチェックしてから起動し直している。 2回目の設定ファルのチェックは本来必要ないが，起動時（再起動じゃない時）の手順をそのまま使っているから起動直前のチェックが入っていると思う。

（再起動の例）
# service nginx restart
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Stopping nginx.
Waiting for PIDS: 75655.
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Starting nginx.

　うまく行かなかった時は，下記のような感じになる。ここでは，わざと設定ファイルの「user」ディレクティブを「XXXuser」とすることでエラーを吐かせている。

（起動の失敗例）
# service nginx start
Performing sanity check on nginx configuration:
nginx: [emerg] unknown directive "XXXuser" in /usr/local/etc/nginx/nginx.conf:3
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
Starting nginx.
nginx: [emerg] unknown directive "XXXuser" in /usr/local/etc/nginx/nginx.conf:3
/usr/local/etc/rc.d/nginx: WARNING: failed to start nginx
[1]    75632 exit 1     service nginx start

次回は location コンテキストと nginx で cgi を使う場合について記載しよう。

FreeBSD で nginx に挑戦してみた（その３）に続く