/etc/cron.dに置くファイルは、どんなファイル名でもよいわけじゃない

Ubuntu 22.04（に限らないとおもいますが）を使っていて、これまで/etc/crontabに入れていた内容を、/etc/cron.dの下に移すことにしました。cronを使う場合に、昔から/etc/crontabを編集していましたが、今ではcrontabを編集するのではなく、/etc/cron.dの下に置くのがお勧めなようです。

 

それでファイルを/etc/cron.dの下に置いたのですが、動いているような気がしません。Webを検索してみると、動かない場合の対処方法などの情報が見つかるのですが、そこに書いてあることを確認しても、どうも違うようです。そして調べているうちに「Debian系のcronで気をつけること」という情報が見つかりました。それによると、ファイル名は何でも良い訳ではなく、英数字とアンダーバーとハイフンしか使えないようです。自分が置いたファイル名を確認すると、ピリオドを使っていました。これが動かなかった原因で、ファイル名を修正したら動くようになりました。 

ファイル名が不適切だった場合、syslogに何かメッセージが残っていれば失敗に気付けたと思いますが、何も出ていなかったので苦労しました。

シェルスクリプトに「dry run」機能を持たせる方法

ちょっと複雑な機能を持つシェルスクリプトを作成する場合、いきなり実行させて大失敗になるのは問題です。場合によっては、スクリプト自身を書き換えてデバッグ情報を出力させて動作を確認し、うまくいくことが確認されたら、デバッグ情報を出力している箇所を削除したりコメントアウトしたりして対処するという方法が考えられます。しかしこの方法では、デバッグするたびにスクリプトの書き換えを伴うので、デバッグに関係ない箇所まで書き換えてしまう可能性があり、あまりスマートではありません。

 

シェルスクリプトでデバッグをおこなう際のテクニックはいろいろあり、Webを検索すれば「シェルスクリプトのデバッグ」のような情報がみつかります。ここで注意しておきたいのは、何度実行しても差し支えないようなコマンドなら気にする事もないのですが、システムに永続的な影響を及ぼすようなコマンド（ファイルを作成したり、削除したりするなど）を実行する場合は、気軽に何度も実行できないという事です。どのようなコマンドが実行されようとしているのかを確認する仕組みが必要になります。このような機能を「dry run」と呼ぶことがあります。

例えば、単純な例にはなりますが、foobarコマンドを実行しようとするスクリプトがあるとしましょう。このコマンドを実行してしまうとシステムに永続的な変更が加えられてしまうので、デバッグ中に気軽に実行するわけにはいきません。しかし思わぬバグが潜んでいるかもしれませんから、シェルスクリプトの中で本当にfoobarコマンドを呼び出しているのか確認しておきたいところです。このような場合に手っ取り早い方法は、コマンドの前にechoをつけておくことです。「foobar」ではなく「echo foobar」としておけば、コマンドが実行されてしまうことは防げます。

デバッグが済み、シェルスクリプトが完成したと「思った」ら、そのechoを削除すれば万々歳かもしれません。ところが不運なことに、思わぬバグが発見され、再びechoを入れなければならない事態に陥ったとしましょう。デバッグが済めば再びechoを削除できますが、もう今後一切バグが発見されないという保証はありません。その度にechoを入れたり外したりするのは、あまり良い方法ではありません。

 

このような問題を解決する方法として、変数名はなんでも良いのですが、「DRYRUN=echo」のような定義をすることです。そして「echo foobar」とする代わりに「$DRYRUN foobar」とするのです。もし変数が定義されていなければ、$DRYRUNは空ですから、「$DRYRUN foobar」は「foobar」になります。もし変数が定義されていれば、「$DRYRUN foobar」は「echo foobar」になります。こうすることで、変数定義をするか否かだけに注意すればよいので、スクリプトを書き換える際の手間が減ります。さらに変数定義をシェルスクリプトの外部からコントロールしたり、他の方法もありますが、うまく制御することで、シェルスクリプトの書き換え自体を無くすことも可能です。

上述したテクニックがあれば万事解決かと言うと、実はそうでもありません。例えば、awkやsedで、もしくはpythonでも何でも良いのですが、コマンド列を生成し、それをシェルに渡すことで何らかの処理をおこなう場合、単純に「DRYRUN=echo」という定義があっても、あまり役に立たないのです。

 

具体的に、つぎのような場合を考えましょう。パイプの前段のawkで何らかのコマンド列を生成し、それを後段のシェルで実行させようとしています。

awk '何らかのawkスクリプト' | sh

 

ここでawkの処理が万全なら良いのですが、もし不具合があったとすると、いきなりシェルで実行させるのは憚られます。そこで確認のために、以下のようにしたいところです。

awk '何らかのawkスクリプト' | cat

 

もし問題ない事が確認できたら、catをshに変更して、実際に実行をするというのが意図です。しかしそのためにシェルスクリプトを書き換えるのは、スマートではないわけです。この問題を解決するために「DRYRUN=cat」と定義してみましょう。そしてシェルスクリプトでは次のように記述します。こうすることで、もしDRYRUNという変数が定義されていれば「${DRYRUN:-sh}」はcatになります。もしDRYRUNという変数が定義されていなければ、「${DRYRUN:-sh}」はshになります。これで問題は解決できそうな気がします。若干アクロバット的かもしれませんが。

 awk '何らかのawkスクリプト' | ${DRYRUN:-sh}

 

ここで最初の問題に戻ります。「DRYRUN=echo」だった筈の定義を「DRYRUN=cat」に変更してしまった訳ですから、「$DRYRUN foobar」が「echo foobar」ではなく「cat foobar」になってしまいます。これでは最初の問題が解決できません。ここで変数名を別にするという解決策もあるかもしれませんが、アクロバット的ですが、「${DRYRUN:+echo} foobar」でも良いのではないかと思います。こうすればDRYRUNという変数の中身が何であろうと、「echo foobar」になってくれます。

/self/proc/mountstats

CentOS 7.4でGangliaを利用しています。Pythonでスクリプトを組むとグラフ表示できるメトリックを追加できるので、NFS操作で使われるRPCに関する情報をファイル「/proc/self/mountstats」から取得してみました。

作成したPythonスクリプトをGangliaの所定のディレクトリに配置して動かしてみました。ごころがログ「/var/log/messages」に次のようなエラーが記録されます。

centos74 /usr/sbin/gmond: [PYTHON] Can't call the metric handler function for [get_delta] in the python module [nfsiostat].

このエラーメッセージだけでは、何か問題があるのだろう、ということはわかりますが、何が悪いのか分かりません。そこで設定ファイル「/etc/ganglia/gmond.conf」でプロパティ「debug_level」に設定値「1」を指定して再起動したら、より詳しい情報が記録されました。それによるとファイル「/proc/self/mountstats」を読もうとして「許可がありません」というエラーになっています。特殊ファイルシステム「/proc」において、「self」というのは自プロセスの事である筈なので、許可がなくて読めないというのは解せません。

念のために確認してみました。するとプロセスの所有者が「ganglia」で、ファイルの所有者が「root」でした。なぜプロセスとファイルの所有者が異なるのかわかりませんが、「許可がありません」というエラーになることはわかります。

[root@centos74 ~]# ps auxww | grep gmond

ganglia   1237  0.3  0.5 291312 10588 ?        Ssl  15:32   0:04 /usr/sbin/gmond

[root@centos74 ~]# ls -l /proc/1237/mountstats 

-r--------. 1 root root 0 Jan 28 15:33 /proc/1237/mountstats

[root@centos74 ~]# ls -ld /proc/1237

dr-xr-xr-x. 9 ganglia ganglia 0 Jan 28 15:32 /proc/1237

デーモンプロセス「/usr/sbin/gmond」を起動するのは管理者「root」だとおもいます。しかしプロセスの所有者が「ganglia」になっているということは、起動後の何らかのタイミングで所有者を変更したのでしょう。ところがファイル「/proc/1237/mountstats」 の所有者が「root」のままになっている（「ganglia」に変更されていない）のが原因だろうと思います。何故かディレクトリ「/proc/1237」は所有者「ganglia」になっているのですが・・・

yumの後継dnfがCentOS7.4で動作しない（CentOS7.9なら動く）

2020年12月8日にCentOSの方針転換が発表され騒ぎになっています（CentOSが開発方針を変更ーー「CentOS 8」は2021年終了、今後は「CentOS Stream」に注力）。気になりますが、発表が唐突ですし、反発も大きいので、別の方向性が示されるかもしれません。今後の動向に注意しようと思います。

それはさておき、CentOS7で使われていたコマンド「yum」は、CentOS8では「dnf」に置き換わることになっています。yumがPython3に対応できないことが理由です。CentOS7ではyumを使い続けることになっていますが、dnfをインストールすることも可能です。そこでCentOS7.4の環境にインストールしてみました。ところが実行するとエラーで動きません。

Traceback (most recent call last):

  File "/usr/bin/dnf", line 57, in <module>

    from dnf.cli import main

  File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 30, in <module>

    import dnf.base

  File "/usr/lib/python2.7/site-packages/dnf/base.py", line 29, in <module>

    import libdnf.transaction

  File "/usr/lib64/python2.7/site-packages/libdnf/__init__.py", line 3, in <module>

    from . import conf

  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 17, in <module>

    _conf = swig_import_helper()

  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 16, in swig_import_helper

    return importlib.import_module('_conf')

  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module

    __import__(name)

ImportError: No module named _conf

何が悪いのか分かりません。別の環境で試してみようと考えて、VirtualBox上にCentOS7.9を準備して、動かしてみました。すると、全く問題ありません。

CentOS7.4とCentOS7.9の中で何かが違うのでしょう。Webを検索してみたら「Centos Extras DNF incompatible with versions less than EL7.6 #827」という情報を見つけました。その解決策は次のようにすると書かれていました。

After installing/updating some related packages, resolved the "ImportError: No module named _conf" issue for me.

yum update python*

yum install dnf-data dnf-plugins-core libdnf-devel libdnf python2-dnf-plugin-migrate dnf-automatic

dnf is now working on a CentOS 7.5 box. Some packages might be unnecessary, but you have to try for yourself...

これで本当に解決するなら、それはそれで良いのですが、何故これで解決になるのか理解できません。なにしろ何が問題の原因なのか把握できていないからです。

状況を調査するため、エラー出力で指摘されているファイル「/usr/lib64/python2.7/importlib/__init__.py」にデバッグ情報を出力するロジックを加えてみました。するとCentOS7.4とCentOS7.9とでは結果が違います。

CentOS7.4では以下のようになりました。

('>>>', 'libdnf._conf')

('>>>', '_conf')

CentOS7.4では以下のようになりました。

('>>>', 'libdnf._conf')

('>>>', 'libdnf._module')

('>>>', 'libdnf._repo')

('>>>', 'libdnf._transaction')

('>>>', 'libdnf._utils')

('>>>', 'libdnf._smartcols')

更に、ファイル「/usr/lib64/python2.7/importlib/__init__.py」にデバッグ情報を出力するロジックを加えて状況を確認すると、次のことが分かりました。

1. CentOS7.4の場合、ファイル「/usr/lib64/python2.7/site-packages/libdnf/conf.py」の14行目で呼ばれたのが最初の行に相当し、2番目は16行目が呼び出し元のようです。
2. どうやら初回呼び出しで例外が起きているようですが、その詳細情報がわかりません。それを取得するロジックを加えてみると、「ImportError('/lib64/libmodulemd.so.1: undefined symbol: g_log_structured_standard'」であることがわかりました。

ちなみにファイル「/usr/lib64/python2.7/site-packages/libdnf/conf.py」の14行目とか16行目というのは、以下のようになっています。

    13          try:

    14              return importlib.import_module(mname)

    15          except ImportError:

    16              return importlib.import_module('_conf')

コマンド「ldd -r /lib64/libmodulemd.so.1」で確認しても、やはり同様のエラーになります。

undefined symbol: g_log_structured_standard     (/lib64/libmodulemd.so.1)

        linux-vdso.so.1 =>  (0x00007fffbf9b8000)

        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007fa9b63d0000)

        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fa9b60be000)

        libyaml-0.so.2 => /lib64/libyaml-0.so.2 (0x00007fa9b5e9e000)

        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa9b5c88000)

        libc.so.6 => /lib64/libc.so.6 (0x00007fa9b58ba000)

        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fa9b5658000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa9b543c000)

        libffi.so.6 => /lib64/libffi.so.6 (0x00007fa9b5234000)

        /lib64/ld-linux-x86-64.so.2 (0x00007fa9b6881000)

だいぶ状況が理解出来てきたので、あらためてWebを検索すると「ローカルで動いてたpuppeteerがCentos7で動かにゃい」という情報が見つかりました。

この問題はパッケージ「glib2」を更新すれば良いようです。現状を確認してみると、CentOS7.4では「glib2.x86_64  2.50.3-3.el7  @anaconda」、CentOS7.9では「glib2.x86_64  2.56.1-7.el7  @anaconda」でした。CentOS7.4でコマンド「yum update glib2」を実行すると「glib2.x86_64  2.56.1-8.el7  @updates」になりました。

以上の処置をすませて、コマンド「dnf」を実行してみると、無事に動作してくれました。

xfs_bmapで出力されるブロックは何処にあるのか

VirtualBox上にCentOS 7.4をインストールしています。ファイルシステムはXFSですが、LVMも使われているようです。

[root@centos74 xfs]# df -T -t xfs

Filesystem              Type 1K-blocks    Used Available Use% Mounted on

/dev/mapper/centos-root xfs   30385668 4715672  25669996  16% /

/dev/sda1               xfs    1038336  183468    854868  18% /boot

任意のファイルを作成し、コマンド「xfs_bmap」を実行すると、そのファイルの実体が置かれているブロック位置がわかりますが、これは具体的に何処なのでしょうか。

[root@centos74 xfs]# cat date.txt 

Fri Dec  4 09:54:58 JST 2020

[root@centos74 xfs]# xfs_bmap -v date.txt 

date.txt:

 EXT: FILE-OFFSET      BLOCK-RANGE        AG AG-OFFSET        TOTAL

   0: [0..7]:          30936616..30936623  2 (536104..536111)     8

コマンド「dd」を使って確認してみると、BLOCK-RANGEで表示されたのが実体のあるブロック位置という事のようです。

[root@centos74 xfs]# dd if=/dev/mapper/centos-root bs=512 count=1 skip=30936616 | strings

1+0 records in

1+0 records out

512 bytes (512 B) copied, 8.8025e-05 s, 5.8 MB/s

Fri Dec  4 09:54:58 JST 2020

ひとまず納得できましたが、LVMの論理ボリューム「centos-root」は、HDD上（VirtualBoxで実験しているので、仮想ディスクですが）にあるパーティションのひとつの中に構成されています。

[root@centos74 xfs]# fdisk -l /dev/sda

Disk /dev/sda: 34.4 GB, 34359738368 bytes, 67108864 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: dos

Disk identifier: 0x000017ce

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *        2048     2099199     1048576   83  Linux

/dev/sda2         2099200    67108863    32504832   8e  Linux LVM

論理ボリューム「centos-root」から見たブロック位置は、パーティション「/dev/sda2」やHDD「/dev/sda」から見て、どのブロック位置になるのでしょうか。

LVMの構成情報はディレクトリ「/etc/lvm/backup」にあります。テキスト形式になっており、次のような情報が得られます。

# Generated by LVM2 version 2.02.171(2)-RHEL7 (2017-05-03): Mon Dec  7 10:05:56 2020

（略）

centos {

（略）

        physical_volumes {

                pv0 {

                        id = "NcNMF2-iNcr-jMVY-379Q-orOj-PHfL-DZU3BN"

                        device = "/dev/sda2"    # Hint only

（略）

                        pe_start = 2048

                        pe_count = 7935 # 30.9961 Gigabytes

                }

        }

        logical_volumes {

                swap {

                        id = "fWmF2u-VxqX-06BN-IZnx-e8FQ-NM6Y-THhGZk"

（略）

                        segment1 {

                                start_extent = 0

                                extent_count = 512      # 2 Gigabytes

（略）

                        }

                }

                root {

                        id = "qzxis0-iY72-OMfH-3psn-HV05-TDxi-c3VEF8"

（略）

                        segment1 {

                                start_extent = 0

                                extent_count = 7422     # 28.9922 Gigabytes

（略）

                        }

                }

        }

}

ここから次のことがわかります。

1. 論理ボリューム「centos-root」は、論理ボリューム「centos-swap」の後ろに置かれている。
2. 物理ボリューム「pv0」は、デバイス「/dev/sda2」の相対位置「2048」から始まる（pe_start = 2048）。

以上より次の計算をおこないます。

1. 論理ボリューム「centos-swap」は「extent_count = 512」なので、512バイトブロック単位に換算すると、4194304（= 512 * 8192）となります。
2. 物理ボリューム「pv0」は、パーティション「/dev/sda2」の先頭から2048離れた位置から始まっていることに注意が必要です。
3. 論理ボリューム「centos-root」にあるファイル「date.txt」のブロック位置「30936616」は、パーティション「/dev/sda2」から見るとブロック位置「35132968」（= 30936616 + 512 * 8192 + 2048）になるはずです。

この計算結果を確かめてみました。

[root@centos74 xfs]# dd if=/dev/sda2 bs=512 count=1 skip=35132968 | strings -tx

1+0 records in

1+0 records out

512 bytes (512 B) copied, 0.0211708 s, 24.2 kB/s

      0 Fri Dec  4 09:54:58 JST 2020

考え方は合っているようです。同じように考えれば、HDD「/dev/sda」から見たブロック位置も求められるでしょう。

SSHを鍵認証する場合の鍵作成の方針とは？

SSHで鍵認証を利用する際に必要となる秘密鍵・公開鍵は、どのような方針で作成するものなのでしょうか？ssh-keygenで鍵を作成するわけですが、コマンドを打てば鍵が出来てしまいますが、それがSSH鍵認証で想定している方針に合致しているとも限らないわけです。

ssh-keygenで作成した公開鍵は、以下のような形をしています。右端にあるのはコメントでオプションで変更することができますが、デフォルトでは鍵を作成したユーザ名が入ります。

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABErI+RbZ foo@bar.com

このデフォルトで与えられるコメントを考えると、鍵は「ユーザ（とホスト）」を単位に作成されるものと考えるのが基本なのかと思います。SSH鍵認証の入門レベルの説明としては、それで構わないと思います。しかし現実の環境において、多数のサーバを扱う管理者であれば、どうなってしまうのでしょうか。サーバが何十台もあったとしても、各サーバでssh-keygenを用いて鍵を作成することは可能でしょう（サーバ上に秘密鍵を置くことの是非はあるかもしれませんが）。作成された公開鍵を全サーバに配置していく作業は（できるかもしれませんが）大変です。さらに作業が大変か否かという実務的な問題だけではなく、各サーバに秘密鍵が置かれていることがセキュリティ的に妥当といえるのかという問題もあるでしょう。

このような問題はssh-agentとssh-addを利用することで解決できそうです。「エージェント転送」を使えば、クライアントマシンだけに秘密鍵を置いておけば、その他のサーバに秘密鍵を置く必要がなくなるようです。

管理者が使用しているクライアントマシンで鍵を作成しておけば、全サーバでは鍵を作成しなくて良くなるのですから、これで疑問は解消したと言えるのでしょうか。つまり鍵は「個人」を特定するものなのでしょうか。

それでは管理者が複数のマシンをクライアントとして利用している場合には、どうなるのでしょうか。鍵が「個人」を特定するのであれば、同一管理者が使用する全クライアントマシンでは、秘密鍵を使いまわすことになります。それでも構わないのかもしれませんが、そのような運用を認めると、複数の管理者で秘密鍵を使いまわすことに繋がる恐れもないとは言えません。

運用次第で何とでもなるという話ではなく、SSH鍵管理の発想とは何だったのかという事を知りたいと思います。

Ganglia Monitoring Systemにおけるpythonメトリックのname属性

マシン環境をモニターするためのOSSとして「Ganglia Monitoring System」があります。標準的な構成を何も変更しないでインストールして利用しても構いませんが、独自にメトリックを作成してマシン環境を参照する事もできます。独自メトリックを自作するにはpythonを使用しますが、作成の仕方のコツを掴めば、作るのはそれほど難しくありません。

メトリックの処理はpythonで組みますが、メトリックの構成を規定するためにディスクリプタを初期化時に返す必要があります。その中には属性「name」があり、これが作成しているメトリックの名前となります。その名前規約として認められる文字長や文字種が明白に定義されている訳ではないようなので、時として問題が起きる場合があります。

名前に半角の英数字を使っているだけなら、別に問題は起きないと思います。また、記号類として、下線文字やハイフンを使う程度なら、差し支えないでしょう。

しかしながら記号類として「/」を使おうとしたら、問題が起きました。属性「name」で指定された文字列は、内部的にはRRDデータベースのファイル名として使われるようです。このために属性「name」において文字「/」が使われると、RRDデータベースのファイル名においてパス名が狂ってしまうようです。

他にも属性「name」に文字「%」が使われるのも、問題を起こす原因となり得るようです。GangliaのWebインターフェイスでは、属性「name」の情報がURLの中に現れます。その時に文字「%」があり、その文字の直後にある2文字が「16進数」を表す文字にマッチしてしまうと、URLエンコードにより別の文字として扱われてしまいます。

これ以外にも問題となる文字があるのか、もうこれだけなのかは、分かりません。しかも、今回問題となった文字が、Gangliaの内部構造の変更により、将来的には問題とならない可能性もあります。OSSはドキュメント類の不備をソースコードを参照する事で補う場合があるので、問題があれば調査して原因を突き止めることは（原理的には）可能です。しかし問題が本来どうあるべきかを知ることは容易ではないでしょう。OSSを利用する際には、そのような事も意識する必要があるのではないかと思います。

2020年1月号の日経Linux（Win7→Ubuntu）

普段は購入しないのですが、「日経Linux」（2020年1月号）を買ってみました。別冊付録「Linuxカーネルが基礎からわかる本」に興味があったからです。

本誌の特集は「サポ切れWin7→Linux引っ越し完全手順」です。2020年1月14日にWindows7のサポートが終了することはマイクロソフトからのアナウンスがあるとおりです。しかしサポートが切れるか否かに関わらず、Windowsが入っていたPCをLinuxに入れ換えることを勧める記事は、よく見かけます。

記事では、以降の流れを次のように説明しています（22頁）。

1. まずはUbuntuの捜査官を確認
2. PCにUbuntuをインストールする
3. データを外部に退避して復元
4. Office文書の引っ越し先を準備
5. Windowsの定番アプリを代替する
6. Linux独特の操作の作法を知る
7. Windowsの便利機能を代替する

この手順が妥当か否かは問題ではないでしょう。もしWindowsが入っていたマシン（Win7か別の何かに依らず）をLinux（Ubuntuであろうと他のディストリビューションであろうと）に移行するのであれば、細部はともかく、このような手順になろうかと思います。

考えてみたいことは、WindowsからLinuxに移行した人（および移行しようと考えている人）は、Linuxに何を求めているのかということです。Windows7はマイクロソフトの商品（だから有料）だが、Linuxはフリー（なので無料）だから、オトクに使える、と思っているだけなのでしょうか。

例えば乗用車は、 トヨタでも日産でも、はたまたホンダでもマツダでも、操作は同じだから、パソコンだってWindowsだろうがLinuxだろうが同じだろう、くらいに考えていないでしょうか。微妙に違うところはあっても、基本的に同じだろうと考えていないでしょうか。

問題となるのは、どの程度の違いであれば許容できるのか、という点だと思います。

一例として、オフィス製品としてMicrosoft Officeの代替としてLibreOfficeが候補にあがります。見た目は似ていますし、操作も似ています。しかし全く同じかというと、そうではないし、全然違うのかというと、そうでもありません。僕自身はMicrosoft Officeを使うのを止め、10年位前からLibreOfficeを使っており、特に不便は感じていません。ただし、Microsoft Officeと同じように使えることを「期待」してLibreOfficeを使うのであれば、「期待外れ」になるだろうとは考えています。LibreOfficeはMicrosoft Officeと互換性のある機能「も」ありますが、基本的には別の操作性を持ったオフィス製品です。

WindowsからLinuxへ移行することは否定しませんが、移行するなら、このような「違い」についても意識しておく必要があるだろうと思います。

VirtualBoxではkdumpが動かないのか

つい先日、VirtualBox上にCentOS7の環境を作りkdumpが動作するか確認しました。するとCentOS 7.0～7.6まで（症状が多少違うところもありますが）全て失敗したので、CentOSでkdumpが動かないものだと判断してしまいました。

しかしWeb上で見つけた情報「カーネルクラッシュダンプの基本や取り方など」によると、CentOS 7.6でkdumpが動いているようです。それならばVirtualBoxで動かないのは、CentOSの問題ではなく、VirtualBoxの問題ということになります。

試しにVMware Workstation Player上にCentOS7の環境を作って、kdumpの実験をしてみました。するとkdumpが動くのです。やはりCentOSの問題ではなく、VirtualBoxの問題だったのでしょう。しかし未だに疑問なのは、VirtualBoxでkdumpできないのは、僕だけなのか、世間一般でそうなのかという事です。VirtualBoxの既知のバグで動かないのであれば、将来のバージョンで動くようになるかもしれません。しかし、何か設定をすることでkdumpできるようにするTipsがあるのであれば、ぜひ知りたいと思います。

それにしても、何が問題なのか情報がないと、調査の糸口も掴めません。CentOSは、旧いOSのように起動時にメッセージがズラズラと出てこないので、何が悪いのか判断する情報が得られないのです。昔は起動時に長々とメッセージがコンソールに流れていましたが、一般受けしないので出さなくする傾向にあるのだと思います。

なんとか情報が得られないかと調べていたら、GRUB2のブートメニューで編集モードに入り、パラメータを変えれば良いようです。パラメータ「rhgb quiet」の指定を消せば昔のOSのように起動ログが出てくるようになります。また更に詳しい情報が必要ならパラメータ「loglevel=7 systemd.log_level=debug」を指定すれば、もっと詳しく情報が出てきます。

この指定をおこなってVirtualBoxでkdumpを起動しようとしたところ、2nd kernelの起動ログが出る前にVirtualBox自体が落ちてしまいました。そもそも2nd kernelに制御が渡っていないようです。

カーネルがパニックしても再起動がかからない

Linuxにおいて、コマンドラインから意図的にカーネル・パニックを発生させる方法があります。Webを検索すれば情報はすぐに見つかると思います（例えば「sysrqキーでパニックさせる」がそうです）。Linuxであれば、Ubuntuであろうが、openSUSEであろうが、CentOSだろうが、ディストリビューションを選ばないと思っていました。ところがそうでもないようです。

発端はCentOS 7.4でした。カーネルがパニックを起こしたら自動的に再起動するような設定にした筈なのに、実際にパニックを起こしているようであるのに、再起動しないのです。その時点で、マシンへのpingは通りませんし、コンソール画面には何も映っていません。もう電源を手動で落とすしかない状態です。

実際に運用中の環境で「パニックの実験」は出来ませんから、VirtualBox上にCentOS 7.4の最低限の環境を作って試してみました。するとやはり再起動しないのです。現象は再現したと言えるのかもしれませんが、もしかすると何か手順を間違えているのかもしれません。そこで、VirutalBox上で動作するように準備しているUbuntu 18.04やopenSUSE 13.1で試してみました。するとどちらもカーネルがパニックすると再起動します。手順に誤りは無いと判断して良いでしょう。

Webには「CentOS7.0でカーネルパニックを発生させてみる」という情報があるのです。CentOS 7.0なら再起動して、CentOS 7.4では再起動しないというのも不思議な話です。そこでVirtualBox上にCentOS 7.0から7.5までの各環境を準備して、再起動されるか否かを実験してみました。その結果、驚いたことに再起動したと言えるのはCentOS 7.1だけでした。

• VirtualBoxがダイアログを出し、仮想マシンが落ちてしまう（CentOS 7.0、CentOS 7.2、CentOS 7.3）
• 画面が固まり、再起動しない（CentOS 7.4、CentOS 7.5）

CentOS 7.4で再起動されない現象は確認できましたが、運用上の理由から再起動して欲しいのです。システムパラメータに何か関係しそうな設定があるのかもしれないと考えてCentOS 7.3とCentOS 7.4を比較してみましたが、それらしい設定はなさそうです。

解決策が見出せないまま手詰まりかと思ったのですが、ふと「kdumpが再起動を邪魔しているのではないか」と思いつきました。カーネルがパニックするとkdumpでクラッシュダンプを取得することになるので、kdumpが居なければ再起動できるのではないかと考えたのです。そこで確認してみるとCentOS 7.0以降の全バージョンでkdumpサービスが動いていました。

コマンドラインから「systemctl stop kdump」でサービスを止めて、当初の手順でカーネル・パニックを起こしてみると、なんとCentOS7.4でも再起動しました。やはりkdumpが邪魔していたのでしょう。

openSUSE 13.1は未だに入手可能と理解しても良い？

NetBSDのpkgsrcにあるLinuxエミュレーション環境では、openSUSE 13.1が（未だに）使われています。このバージョンは「2016年2月3日にサポートを終了している」と公式にアナウンスされており、ISOイメージが入手できなくなっています。

しかし過去のバージョンを入手したいと希望する声は少なくないようで、openSUSEの公式サイトにあるフォーラムで「Is it necessary openssl-devel RPM for OpenSuSE 12.3 ?」と問い合わせているのが確認できます。その回答の中で、「ftp5.gwdg.de」というサイトを紹介しているものがあります。

gwdg.deというのはドイツのサイトだと思いますが、openSUSEのミラーのリストにも出てくるサイトです。ここにはopenSUSE 13.1のISOイメージも置いてあります。これを入手しておけば、openSUSE 13.1の環境を準備することは可能です。

ただし気になるのは、過去のバージョンを保持しているのが、何故このサイトだけ（のように思われる）なのかという事です。また将来に亘って入手可能と考えておいて良いのかということも気になります。

NetBSDのエミュレーション環境でLinux版firefox 67.0.4は動かなかった

dynabook SS SX/15AにNetBSD/i386を入れ、MATEデスクトップ環境を利用しています。使用しているアプリケーションはpkgsrcから入れました。もう1年以上も更新していなかったので、6月上旬にpkg_rolling-replaceを使って全更新をおこなおうと試みたのですが、いろいろなトラブルに見舞われ環境が崩壊してしまいました。pkg_rolling-replaceは諦めてpkginで何とか全更新を仕上げましたが、まだ崩壊前と同等になったとは言えません。

最優先で復活させたいのがfirefoxです。

pkgin search firefoxで確認すると、firefox 66.0.1の言語パックがあるのに、本体が存在しないという不思議な状態になっています。

• firefox-l10n-66.0.1  Language packs for www/firefox (version 66)
• firefox36-l10n-3.6.28  Language packs for www/firefox36 (version 3.6.x)
• firefox45-45.9.0nb18  Web browser with support for extensions (version 45)
• firefox45-l10n-45.9.0  Language packs for www/firefox (version 45)
• firefox52-52.9.0nb12  Web browser with support for extensions (version 52)
• firefox52-l10n-52.9.0  Language packs for www/firefox (version 52)
• firefox60-l10n-60.6.1  Language packs for www/firefox60 (version 60)

pkgsrcから自前でビルドすれば良いのかもしれませんが、どうも面白くありません。例えばLibreOfficeはLinux用のRPMを展開しただけ（+α）ですから、Firefoxも同じように出来ないのでしょうか。Mozillaのサイトに行けば、Linuxのディストリビューションとは無関係のバイナリが置いてあります。これを、NetBSDのLinuxエミュレーション環境で動かせることが出来れば、文句なしです。

そこで実験してみました。LibreOffice6が導入済みなので、Linuxエミュレーション環境も出来ています。openSUSE 13.1相当というのが旧いとは思いますが、仕方ありません。Mozillaのサイトから拾ってきた「firefox-67.0.4.tar.bz2」を/usr/pkg/optに展開しました。展開するとfirefoxというディレクトリができますが、firefox-67.0.4に変えておきました。

 ここで共有ライブラリの参照状況を確認してみます。

# /usr/pkg/emul/linux/usr/bin/ldd  /usr/pkg/opt/firefox-67.0.4/firefox
        libpthread.so.0 => /lib/libpthread.so.0 (0xbbab9000)
        libdl.so.2 => /lib/libdl.so.2 (0xbbab4000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xbb9c7000)
        libm.so.6 => /lib/libm.so.6 (0xbb982000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xbb965000)
        libc.so.6 => /lib/libc.so.6 (0xbb7ee000)
        /lib/ld-linux.so.2 (0xbbadd000)

not foundが出ていないので、もしかしたら動作するかと思いましたが、動かしてみると不足している共有ライブラリがあるようです。メッセージに出てきたら、RPMを追加し、また動かしてみるという作業を続けました。その結果、以下のRPMを追加しました。

1. libatk-bridge-2_0-0-2.12.1-2.5.i586.rpm
2. libatomic1-4.8.1_20130909-3.2.1.i586.rpm
3. libatspi0-2.12.0-2.5.i586.rpm
4. libcairo-gobject2-1.15.2-3.2.i586.rpm
5. libgtk-3-0-3.12.2-1.110.i586.rpm

この状態でfirefoxを動かしてみると、動かない訳ではないのですが、まだ何か問題があるようです。

# /usr/pkg/opt/firefox-67.0.4/firefox --version
Mozilla Firefox 67.0.4
# /usr/pkg/opt/firefox-67.0.4/firefox --help
Usage: /usr/pkg/opt/firefox-67.0.4/firefox [ options ... ] [URL]
       where options include:

X11 options
  --display=DISPLAY  X display to use
  --sync             Make X calls synchronous
  --g-fatal-warnings Make all warnings fatal

Firefox options
  -h or --help       Print this message.
  -v or --version    Print Firefox version.
  -P <profile>       Start with <profile>.
  --profile <path>   Start with profile at <path>.
  --migration        Start with migration wizard.
  --ProfileManager   Start with ProfileManager.
  --no-remote        Do not accept or send remote commands; implies
                     --new-instance.
  --new-instance     Open new instance, not a new window in running instance.
  --UILocale <locale> Start with <locale> resources as UI Locale.
  --safe-mode        Disables extensions and themes for this session.
  --allow-downgrade  Allows downgrading a profile.
  -MOZ_LOG=<modules> Treated as MOZ_LOG=<modules> environment variable, overrides it.
  -MOZ_LOG_FILE=<file> Treated as MOZ_LOG_FILE=<file> environment variable, overrides it.
                     If MOZ_LOG_FILE is not specified as an argument or as an environment variable,
                     logging will be written to stdout.
  --headless         Run without a GUI.
  --save-recordings  Save recordings for all content processes to a directory.
ExceptionHandler::GenerateDump cloned child ExceptionHandler::WaitForContinueSignal waiting for continue signal...
2288
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
[ 6100.7246708] sorry, pid 2122 was killed: orphaned traced process
[1]   Killed                  /usr/pkg/opt/firefox-67.0.4/firefox --help

あと一歩という感じなので、なんとか解決させたいところです。しかし、あと一歩だと思って調査を続けていったら、ゴールは無限の彼方という可能性もないわけではありません。ここは一端撤退しようかと思います。

NetBSDのLinuxエミュレーションは何故openSUSE 13.1なのか

NetBSDのLinuxエミュレーションのために利用できるディストリビューションとしてpkgsrcにあるのは、openSUSE 13.1です。

% cat /usr/pkg/emul/linux/etc/os-release
NAME=openSUSE
VERSION="13.1 (Bottle)"
VERSION_ID="13.1"
PRETTY_NAME="openSUSE 13.1 (Bottle) (i586)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:13.1"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"

何故SUSEなのか、という疑問もありますが、（それは良いとしても）何故openSUSE 13.1なのかという疑問があります。openSUSEの最新版は15.2であり、13.1のサポートは2016年に終了しています。そのためなのか、公式サイトからは既に13.1が消えています。NetBSDのLinuxエミュレーションで不具合が起きた場合に、本物のopenSUSE 13.1の環境を準備して比較することは、問題解決のために役立つ手法です。ところがopenSUSE 13.1が入手できなくなっているので、この手法が使えません。

NetBSD のLinuxエミュレーション環境は、Linuxカーネル3.11.6に相当するようです。pkgsrcに用意されているopenSUSE 13.1は、ユーザの利便性のために提供されているだけであり、自分で環境を整えていけるのであれば、FedoraでもUbuntuでも何でも好きなディストリビューションを入れることが可能ということなのでしょうか。

% uname -r
8.99.43
% sysctl -a | grep linux
emul.linux.kern.ostype = Linux
emul.linux.kern.osrelease = 3.11.6
emul.linux.kern.osversion = #1 SMP PREEMPT Thu Oct 24 16:23:02 UTC 2013
emul.linux.enabled = 1

NetBSDでLinux版Firefox 67.0.4を使いたい

dynabook SS SX/15AにNetBSD/i386を入れて、MATEデスクトップ環境を構築しようとしています。WebブラウザはFirefoxを利用したいのですが、出来れば自前でビルドしないで済ませたいところです。

pkginを利用して出来合いのバイナリパッケージを使おうと思ったのですが、中途半端なファイルしか利用できません。Language packsがあっても本体がなければ意味がありません。

1. firefox-l10n-66.0.1  Language packs for www/firefox (version 66)
2. firefox36-l10n-3.6.28  Language packs for www/firefox36 (version 3.6.x)
3. firefox45-45.9.0nb18  Web browser with support for extensions (version 45)
4. firefox45-l10n-45.9.0  Language packs for www/firefox (version 45)
5. firefox52-52.9.0nb12  Web browser with support for extensions (version 52)
6. firefox52-l10n-52.9.0  Language packs for www/firefox (version 52)
7. firefox60-l10n-60.6.1  Language packs for www/firefox60 (version 60)

Firefoxを自前でビルドしようとすると、rustが必要になります。rustはFirefox並（以上？）に大きなパッケージなので、ビルドに時間もかかりますし、ディスクが溢れる懸念もあります。なんとかバイナリを入れて終わりにできないでしょうか。

ふと考えてみると、LibreOfficeは（原理的には）ソースから自前でビルドすることも出来るはずなのに、NetBSDのLinuxエミュレーションを利用し、Linux版LibreOfficeのRPMを利用して済ませています。同じことがFirefox（やThunderbird）でも出来ないでしょうか。

Mozillaの公式サイトには、RPMを使わずに導入するためのファイルが置いてあります。使うためには、必要な動作条件を満たすように環境を整えなければなりませんが、これが利用できないでしょうか。

詳しい動作確認はMATEデスクトップ環境のトラブルを解決してからにしようと思いますが、試しに展開して動かしてみました。

まず共有ライブラリの状況をみると、問題はなさそうです。

# /usr/pkg/emul/linux/usr/bin/ldd /usr/pkg/opt/firefox-67.0.4/firefox
        libpthread.so.0 => /lib/libpthread.so.0 (0xbbab9000)
        libdl.so.2 => /lib/libdl.so.2 (0xbbab4000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xbb9c7000)
        libm.so.6 => /lib/libm.so.6 (0xbb982000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xbb965000)
        libc.so.6 => /lib/libc.so.6 (0xbb7ee000)
        /lib/ld-linux.so.2 (0xbbadd000)

もしかしたら動くかもしれないと期待しましたが、駄目でした。まだ不足する共有ライブラリがあるようです。

# /usr/pkg/opt/firefox-67.0.4/firefox
/usr/pkg/opt/firefox-67.0.4/firefox: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

misc/libreoffice6-bin-6.2.2

dynabook SS SX/15上でNetBSD/i386を利用しています。pkg_rolling-replaceによるパッケージの全更新に失敗してしまい、利用環境が崩壊したので、復旧しています。ひとまずMATEデスクトップ環境が回復し、日本語入力には（Mozcを捨て）KKCで出来るようになりました。次はLibreOfficeを復旧させます。

pkgsrcにはLinuxエミュレーション環境で動作するLibreOfficeがあります。以前はLibreOffice5系だけでした。pkgsrcでインストールされるバージョンがLibreOfficeのバージョンアップに追いつかないので、小細工をして最新（の一歩手前）をインストールして利用していました。

ところが現在はLibreOffice5系の他にLibreOffice6系もあるようです。今回はLibreOffice6系を、pkginで導入しました。

libreoffice6-bin-6.2.2 Integrated office productivity suite (binary pkg)

pkgsrcから自前でビルドしたところで、ここにあるのはLinuxエミュレーション環境用のバイナリなのでコンパイルが始まるわけではありません。しかし若干のビルド処理はあります。それに比べればpkginならば、展開するだけで終わりのバイナリパッケージになっているので、より一層素早く導入作業が完了します。

導入後に起動してみたところ、問題もなく使えるようになりました。以前には日本語入力が出来ずに苦労しましたが、その問題もありませんでした。これは、以前苦労して設定した環境が残っているせいなのか、既に今は問題が無いようになっているのか、理由は分かりません。また日本語入力がKKCです。問題もなく、日本語入力ができることを確認しました。

次はFirefoxやThunderbirdを入れようかと考えています。

Emacsの初期化ファイルとinit-loader.el

Emacsの環境を初期設定するファイルは、僕がEmacsを使い始めた頃は.emacsでしたが、現在は.emacs.d/init.elが使われる傾向にあるようです。過去との互換性のために以前のものでも構わないようですが、今風のファイルに移行していくようにした方が望ましいのかもしれません。

昔はNEmacsだとか、Muleとか、派生したバージョンを使うこともありましたが、今となっては本家のGNU emacsしか利用しなくなっています。ただしOSや文字コードなどの扱いには、個々の環境に合わせる必要があります。今となっては使わなくなった設定を整理し、今後のことも考えて、使いやすくしておこうと考えています。

どんなOSでEmacsを使っているかと思うと、結局は次のような環境だけでした。

1. FreeBSD
2. NetBSD
3. Windows10 WSL上のUbuntu
4. （VirtualBox上のCentOSなど）

古いEmacsのことは想定せず、最新か最新に近いEmacsで使えれば良いと思っています。ただしOSや環境に依存して、利用するアプリケーションの有無が違う可能性があるので、それに対処しておきたいとは思っています。つまり入っていないアプリケーションの設定があるが故にinit.elが止まってしまうのは困るということです。

Webを検索すれば、Emacsでinit.elを構成する話題が数多く見つかりますが、そこで言及されるものとしてinit-loader.elがあります。OSの/etc/init.dで見かけるファイル群のように、機能ごとに初期設定ファイルを分割し、ファイル名の先頭に番号を付加することで順番を制御しようとするようです。支持する人がいる反面、必要性に疑問を呈する立場も見受けられます。

いったいどのようなものか調べてみて、僕としては次のような感想を持ちました。

1. 機能ごとに初期設定ファイルを分割するというのは悪くないと思う。
2. 実行順序を制御するため、ファイル名に番号を付加することにも抵抗はない。
3. 亜流が多くて、どれを使えば良いのかわからない状態なのは困る。
4. Emacsのパッケージ制御でインストールできるようだが、標準的なパッケージのリポジトリには入っておらず、追加的なリポジトリを設定しておく必要があるのは、ちょっと困る。
5. 環境依存の制御もできるらしいが、Mac、LinuxやWindowsの対応しかなく、BSD系OSが含まれていないのは、不満を感じる。

このように良し悪し拮抗しています。あえて使うほどのこともなさそうですが、あればあったで便利そうではあるので、ものは試し（これも経験だと思って）使ってみようかと思います。

Tera termの終焉とRLogin

*BSDやLinuxなどにWindowsからリモート・ログインするためには、昔からTera termを利用していました。オリジナルのTera termは1990年代に登場しました。当時はVT382エミュレーションができて、かつ実用に耐えるフリーの端末ソフトが他には見当たらなかったので、あっという間に広まった記憶があります。

その後オリジナルの開発が止まりましたが、別のチームによってメンテナンスが再開され、それ以来ずっとTera termを利用し続けてきました。

昔はU*IXの文字コードは日本語EUCを使うことが多かったと思いますが、最近ではUTF-8が使われているようです。Tera termでもUTF-8は利用できることになっていますが、僕自身はEUCで環境を整えているのでUTF-8を利用したことはありませんでした。

Linuxを利用する必要が出てきて、UTF-8のロケールで利用しなければならなくなりましたが、何故か文字が化けてしまいます。Webで調べてみた限りでは、端末設定で送受信の文字コードを「UTF-8」にすれば良いだけらしいのですが、上手くいきませんでした。

さらに調べてみると、Tera termではUTF-8の取り扱いに問題があるような情報も散見されました。もし不具合があってUTF-8の使用に耐えられないのであれば、もっと騒ぎになっていそうなものですが、世間ではTera termでもUTF-8で運用できているようです。僕の環境では文字化けしてしまうので、何か設定があるのでしょうが、残念ながら見つけられませんでした。

困ったことになったと思っていたら、偶然RLoginという端末エミュレータを見つけました。試しに使ってみたところ、何の苦もなくUTF-8のロケールの環境で利用できました。

Tera termの大きなアドバンテージはVT382とかVT520などの、それほどメジャーではない端末をサポートしていることです。RLoginではVT100しかサポートしないようですが、実際問題としてはそれで十分でしょう。各種VT端末のエミュレーションを実際に必要とするのはOpenVMSを利用する時ぐらいではないかと思います。

長年に亘りTera termを利用してきましたが、今後はRLoginに移行していくことになりそうです。しかしOpenVMSを利用することがありますから、その時にはTera termを使うことになるでしょう。

Lubuntuならインストールできた

dynabook SS SX/15AにNetBSD/i386をインストールしようとして、あえなく失敗してしまいました。あまり考えにくいことですが、dynabookでは何か問題があってWindows以外のOSがインストールできないのでしょうか。それともNetBSDに何か問題があるのでしょうか。

この疑問を解決する簡単な方法は、NetBSD以外のOSをインストールしてみることです。そこでLubuntu 16.04を入れてみたところ、あっさりとインストールできてしまいました。電源を入れれば問題なく起動できます。

そういう訳で、dynabookの問題ではなく、NetBSDをインストールする手順（何かの前提）に問題がありそうです。この解決は厄介ですが、解決できさえすればNetBSDが動作するだろうと期待できるので、希望でもあります。

PC-BSDはamd64専用だった

Windows Vistaが入っているノートPCをBSD系OSに入れ換えようと考えており、PC-BSDを第一候補として考えていました。しかしPC-BSDは9.2以降ではamd64専用になっていました。

PC-BSD USERS HANDBOOKの「2.1.1 Minimum System Requirements」には次のように書かれています。「PC-BSD 9.1 USERS HANDBOOK」では「Pentium II or higer」となっていますが、「PC-BSD 9.2 USERS HANDBOOK」になると「64-bit processor」に変わっています。

ノートPCで使われているのは「Intel Core U1400」という32bitプロセッサなので、PC-BSDを使いたければ2012年12月18日リリースのPC-BSD9.1を選ぶことになり、最新のセキュリティ対策に追従できなくなります。したがってPC-BSDは選択肢から落ち、FreeBSDにデスクトップ環境を付け加えることになりそうです。

Linux系を常用とする気持ちはありませんが、FreeBSDでデスクトップ環境を構築する参考にしてみたいとは考えています。Linuxには選択に困るほどのディストリビューションがあるので迷ってしまいますが、Ubuntuを使ってみようかと思います。デスクトップ環境にLXDEを採用したLubuntuというものがあるそうです。NetBSDでもLXDEを使ってみたことがありますし、FreeBSDにもLXDEを使おうかと考えているので、これが良さそうです。また来月リリースされるというWindows10の機能追加ではUbuntuをベースとしたLinuxサブシステムが導入されるそうなので、Ubuntuに慣れておくといろいろと都合が良さそうです。