rita.karing.jpに関する技術情報 486機でVine Linux 6.1
rita.karing.jpに関する技術情報 486機でVine Linux 4.1
rita.karing.jpに関する技術情報
2022-03-31
|
1. 概要 2. ハードウェア 3. インストール 4. kernel configuration 5. 諸設定 6. 動作状況 7. GRUB boot floppy 8. 保守 9. まとめ |
|
九年ぶりにメインサーバ・rita.karing.jp(www.karing.jp)のOSをアップデートしました。OSよりもハードウェアの更新（486機の廃棄）こそが合理的判断と思われますが、Linux kernelの486対応はいつ終了してもおかしくない状況であり、「いっそ最後まで付き合おうか」という気持ちになりました。新OSであるGentooも486対応を謳っており、ハードルはそんなに高くないと背中を押されました。
本稿の目的は、486機(HITACHI FLORA 3010CT)にGentoo(kernel 5.15.26)をインストールし、当ネットワークのメインサーバ・ルータとして実運用することです。まず、当該のハードウェアについて概観します。次にインストールを実行、続いてkernelの設定・リビルドについて検証し、その後、実運用における諸設定と動作状況について言及します。最後に周辺のトピックスとして、現代の環境下でのGRUBを用いたBoot floppyの作成と保守（ハードウェアの交換）について考察し、まとめとなります。
実機での作業以外の実行環境は、Fedora Core 34 KDE(kernel 5.16.11-100.fc34.x86_64)で、仮想環境はQEMU(5.2.0-9.fc34.x86_64)です。
本稿の対象機体はHITACHI FLORA 3010CTです。本機はバッテリーレスのノートPCという現在には存在しない狭義のラップトップ機です。HITACHI的にはノート型ではなくブック型と分類しているようです。SCSI内蔵でそのSCSIコネクタはPC98用とも言えるアンフェノールハーフピッチという特殊性、また、RTCのバッテリーには現在一般的なコイン電池ではなく、MacのPRAM用として知られるER3Sの類似品ER3Aが使われているなど、まだPC/ATのスタンダードが固まる以前の機体であることが伺われます。スペック的には、486DX4 RAM32MBは発売当時（1994年頃）は十分にハイスペックであったと思われますが、2002年の購入当時では2,980円の堂々たるジャンクでした。購入当時はそれなりの美品でしたが、いつだったか異常発熱したことがあり、その熱でディスプレーの表面が溶け、画像のような姿になってしまいました。
| CPU | Intel 486DX4/75MHz |
| RAM | 32MB |
| HDD | FUJITSU MHV2040AH 40GB |
| on board video | WD90Cxx |
| LCD | 9.8inch TFT 256color |
| on board sound | ESS688 |
| on board SCSI | aha1510 (no pcmcia) |
| SCSI DVD-RAM | Panasonic LF-D200 |
| pcmcia | Vadem VGｰ468 |
| ethernet PC card | Fujitsu FMV-J182A |
| ethernet PC card | Toshiba Advanced Network 10/100 |
| hostname | rita.karing.jp, azami |
以前は、SCSIスキャナやSCSI HDDなども接続していましたが、実際に使用することはマレだったため引っ越しの際に整理しました。
FROLA 3010CTは当LANのメインサーバとして実稼働しており、簡単には停めることができないため、検証用として、COMPAQ DESKPRO XE4100を用いています。DESKPRO XE4100は、BIOS設定ツールをフロッピーディスクから読み込んで利用するという変則的な仕様ですが、それ以外はPC/AT標準の素直な機体です。なお、このBIOS設定ツール上ではマウスが使用でき、マウスが使えるのは何もUEFIだけではないと教えてくれます。
| CPU | Intel 486DX4/100MHz |
| RAM | 32MB |
| HDD | SEAGATE ST380011A 80GB |
| on board video | COMPAQ AVGA VRAM 1MB |
| DVD-RAM | MATSHITA DVD-RAM 9590 |
| on board sound | Windows Sound System |
| SCSI | adaptec aha1510A |
| ethernet card | 3Com 3c509TP |
| ISA modem | Microcom V34.ES II |
| hostname | sumire |
今回の作業では、QEMUのエミュレーション精度は十分に向上したので検証用の実機はもう不要かもしれないと思い始めました。次回は仮想環境だけで実験・検証の予定です、次回があればですが…。
仮想環境(QEMU)を実行しているのはnvmeをルートデバイスに持つ当LAN随一のハイスペックマシン。nvmeからは起動できないので起動専用のUSBメモリを筐体内に装備しています。
| CPU | Intel Core i5 3570K 3.40GHz |
| RAM | 2GBx4 8GB |
| nvme | Intel SSD 760p M.2 PCIEx4 256GB |
| on board video | Intel IvyBridge GT2 [HD Graphics 4000] |
| DVD-ROM | HL-DT-ST DVDRAM GH24NS95 |
| on board sound | Realtek High Definition Audio |
| on board ethernet card | Intel(R) 82579V Gigabit Network |
| USB card reader | Realtek USB 3.0 Card Reader |
| OS | Fedora Core 34 KDE |
| hostname | sazanka |
インストールは実機ではなく、仮想マシン(QEMU)上で行い、GentooのインストールされたHDDを交換するという形でOSを更新しました。ここで用いたGentooのインストール用isoイメージはISAオンリーな環境では動作しません。仮にインストールイメージが動作したとして、486機上では現実的な速度でemerge（リビルド）が実行できないので選択肢は他にありません。同様の作業は二年ほど前（kernel 5.4.28の頃）に一度実行しており、その時のシステムが単純にはアップデートできなかったため、今回、最初からやり直すことになりました。
まず、Gentooのサイトから下記の二つをダウンロードします。日付の部分は適当に最新のものとして下さい。
install-x86-minimal-20220207T170556Z.iso
stage3-i486-openrc-20220207T170556Z.tar.xz
続いて、対象のHDDを変換ケーブルなどでUSBディスクとしてホスト機に接続し、パーティションを切り、ext4でフォーマットします。ここからは、40GBのIDE HDD（44pin 2.5inch）が/dev/sdcとして認識されているものとして例示していきます。パーティションの設定では/boot用の第一パーティションは500MB以下にする必要があります。いわゆる500MBの壁です。ですので、第一パーティションは384MBで切り、残り全てをroot用の第2パーティションとします。swapはswapファイルで対応しています。
# fdisk /dev/sdc
# mkfs.ext4 /dev/sdc1
# mkfs.ext4 /dev/sdc2
フォーマットが終わったら、root用のパーティション(/dev/sdc2)にstage3をコピーします。
# mount /dev/sdc2 /mnt
# cp stage3-i486-openrc-20220207T170556Z.tar.xz /mnt
# umount /mnt
Gentoo側の準備が整ったら仮想環境(QEMU)の準備をします。重要なのはネットワークの設定で、仮想環境からインターネット接続するには仮想環境だけでなくホスト機側の設定も必要です。まず、QEMUに実行させるネットワーク用のスクリプトを作成します。
#!/bin/sh
ip address add 192.168.3.1/24 dev $1
ip link set $1 up
このスクリプトでホスト機にQEMUと接続できる仮想ネットワークインターフェイス(tap0)が作成され、この例では、192.168.3.1/24のIPアドレスが与えられています。仮想環境側のNICにこのネットワーク(192.168.3.0/24)に接続可能なIPを設定すれば両端末間で通信ができるようになります。QEMUはi386ではデフォルトでintel e1000をエミュレートするのでNICの認識自体はとくに問題なく自動で行われます。'-boot d'でcdromから起動します。
# qemu-system-i386 -enable-kvm -m 512 -drive file=/dev/sdc,format=raw \
-boot d -cdrom install-x86-minimal-20220207T170556Z.iso -net tap,script=qemu-ifup -net nic
livecd ~ # _
なお、このインストーラはデフォルトでは1024x768のフレームバッファで動作しますが、縦の解像度が800くらいだとデスクトップに収まりきらないので、その場合は起動時のプロンプトからgentoo-nofbで起動するのが得策です。
シェルにたどり着いたらネットワークインターフェイスにIPアドレスを付与します。
livecd ~ # ip address add 192.168.3.5/24 dev enp0s3
livecd ~ # ip link set enp0s3 up
livecd ~ # ping -c 3 192.168.3.1
ホスト機にpingが通ればデフォルトゲートウエイを設定します。
livecd ~ # ip route add default via 192.168.3.1
あとはネームサーバの設定をして仮想環境側のネットワーク設定は終了です。ネームサーバの設定は個別なものなので自己解決してもらうとして、もしわからなければ、
livecd ~ # echo "nameserver 8.8.8.8" >/etc/resolv.conf
とでもしておきます。次にホスト機側の設定で、IPマスカレードで仮想環境側から来たパケットをインターネットに中継するようにします。下記のeno1はホスト機のデフォルトゲートウェイがあるネットワークインターフェイスです。ip_forwardに1を書き込んで中継を開始し、仮想環境から適当なところへpingを撃って応答があればネットワークの設定は完了です。
host ~ # iptables -t nat -A POSTROUTING -o eno1 -s 192.168.3.0/24 -j MASQUERADE
host ~ # echo 1 > /proc/sys/net/ipv4/ip_forward
livecd ~ # ping -c 3 www.yahoo.co.jp
ここまでくれば、Gentooのインストールマニュアルに沿って作業を進めていくだけです。/dev/sdc2をmountし、そこにstage3のアーカイブを展開、ベースシステムとしての環境を構築（/procのmountなど）した後、chrootして作業を続行します。
livecd ~ # mount /dev/sda2 /mnt/gentoo
livecd ~ # cd /mnt/gentoo
livecd ~ # tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner
以下、当環境に特有な設定はコンパイルオプションの設定くらいです。アーキテクチャは当然、486、また、この機体ではGUIを使わないのでGUI関連はすべて外しています。
*** /mnt/gentoo/etc/portage/make.conf ***
COMMON_FLAGS="-O2 -march=i486"
USE="sasl -ipv6 ibm firmware dlz mbox -X -gnome -kde -qt3 -qt4 -qt5 -selinux"
上記二行以外はデフォルトのままです。profileは[1]です。
ネットワークを介したシステムのアップデートが完了するとkernelの構築がありますが、そこでは必要最低限の設定で済ませ、最適化の追求はシステムの構築が終了した後、改めて行います。ここでの、とりあえずのkernel設定は、cpuをi486にすること(CONFIG_M486=y)、ISAバスの有効化(CONFIG_ISA_BUS=y, CONFIG_ISA_DMA_API=y, CONFIG_ISA=y)、libataのLegacy PATA対応（CONFIG_ATA_SFF=y, CONFIG_ATA_BMDMA=y, CONFIG_PATA_LEGACY=y)、SCSIデイスクドライバの有効化(CONFIG_BLK_DEV_SD=y)、ext2およびext4への対応(CONFIG_EXT2_FS=y, CONFIG_EXT4_FS=y)です。すべてkernel組み込みにします。この簡易設定はinitrd(initramfs)なしで起動することが最大の目的です。最近のinitrd(initramfs)はかなり大きく、32MBの環境では使用できないのでinitrd(initramfs)は作成しません。
kernelの構築後、ネットワークやsyslog、その他のシステム設定があり、grubをemergeしてブートの設定が終了すればインストーラでの作業は終了です。一旦、QEMUをshutdownし、本番の仮想環境で再起動します。
本番の仮想環境では、インストーラとは違い、486機を再現するため、-cpu 486 -M isapcを付加します。起動ドライブは、'c'ドライブ(/dev/sdc)、nicはne2k_isaとなります。ne2k_isaはNE2000互換のethernet cardで「modprobe ne io=0x300」でeth0が見えるようになるはずです。
# qemu-system-i386 -enable-kvm -m 512 -cpu 486 -M isapc \
-drive file=/dev/sdc,format=raw -boot c -net tap,script=qemu-ifup -net nic,model=ne2k_isa
ネットワークの設定は済んでいるものとして、これから必要なものを追加していきます。大概なものはすでに入っているので追加するのは一般的なサーバ群とツール群で大した数にはなりません。サーバ群としては、named, dhcp, apache, postfix, dovecot, nfs-utils, ntp, xinetd, netkit-telnetd、ツール郡としては、at, ed, ethtool, hdparm, inotify-tools, multipath-tools, pcmciautils, stunnel, sudo, udftools, whois, wol などです。
これらの追加中にemergeが通らなかったパッケージが二つあります、apache-toolsとdhcpです。どちらも単純な変数の付加設定のみで解決可能です。
apache-toolsはapacheのemerge時に依存するパッケージとして登場します。また、apache-toolsのエラーは、厳密には、apache-toolsの問題ではなく、aprが不正なライブラリを提供しているためmakeに失敗するということのようでした。なので、aprの方に不正を修正する環境変数を付してemergeし直し、再度、apacheをemergeします。
# ap_cv_atomic_builtins=no emerge --ask dev-libs/apr
dhcpは依存するパッケージがないので下記のようにLDFLAGSを付加するだけで問題解決します。
# LDFLAGS="-latomic" emerge --ask net-misc/dhcp
dhcpのこのエラーは2年前の導入試験時にも存在し、それがこうして放置されたままなのはどれだけこの環境が特殊なのかということを思い知らされます。
これで、パッケージのインストールは終了です。アップデートやパッケージの追加インストールなどを486の実機で行うのは現実的でないので、それらの作業が必要な場合はHDDを実機から外し、仮想環境で同様の作業を行うことになります。
今回の新OS導入における最大の難関はkernelの設定・リビルドでした。第一に旧来のGDドライバ(/dev/hd?)が廃止になったためディスクドライバはlibata(/dev/sd?)を使用せざるをえず、果たして最新のドライバがどこまでLegacyなデバイスをフォローしているのかまったく未知数であること、また、肥大化するkernelをどこまで小さくできるかはRAM32MBの環境下では実運用の可否に大きく影響するためです。
libataについては前述した設定で問題なく動作するのですが、GentooのインストーラがISAオンリーな環境で動作しないのはlibataのLegacy対応に難があるからだと推測され、設定の難易度が高いことを思わされます。2年前の導入試験時のkernelは5.4.28で、当時はまだGDドライバがkernelに含まれていたので/dev/hdaでしたが、今回は/dev/sdaになり、導入試験時のシステムを上手く継続できなかった一つの原因となりました。
kernelの最適化は新しい機能は基本的に全て無効化、タイプはサーバー、tick 100Hz、あとは単純に不用な機能を外していくだけです。ただ、その数が膨大で、おそらく不用なはずだが確信がない、確信を得るためには調べる労力を費やさなくてはならない、みたいな項目が無数にあり、とにかく疲弊します。なので、詳細は省き、実際の.configファイルを提示するだけにします。
gentooのkernelには、gentooのシステムを考慮した設定項目が存在します。これを外さないと無効化できない項目（cgroupなど）があるので、これを外して最適化を追求したkernelとgentooのツール(portage, emerge)を使用する場合のkernelの二つを作成し、使い分けることにしました。実運用はgentoo非対応kernelで、gentoo対応kernelは仮想環境でアップデートなどを行うときに使用します。
config-5.15.26-gentoo (gentoo対応)
config-5.15.26-karing (gentoo非対応)
kernelの大きさは、gentoo対応で2577kB、最軽量版では2339kBになっています。ちなみに前OS（Vine Linux 6.5)で運用していたkernelは3.4.98で1261kB、4.4.52で1529kBで、Gentoo導入試験時の5.4.28はgentoo対応で2970kBでした。486の環境下ではkernelの新機能はほぼ無意味なので新しいkernelを使わなくてもいいのではないかとも思うのですが、3.4.98では最新のext4を読めなかったりするのでそうもいかないようです。
このサーバの最大の使命は、ADSL(Yahoo! BB)ルータとして当LANのゲートウェイとなることです。次に、インターネットにおけるローエンド環境での各種サーバの運用実証例となることです。ルータとしての設定はとくに特別なことはしておらず、iptablesによるIPマスカレードとフィルタリングだけです。フィルタリングは、以前はもっと細かく実施していたのですが、フィルタリングを細かく調整するよりも外部からのアクセスはできるだけ大きく制限し、できるだけシンプルに穴を開けるという方針に変えました。
#!/bin/sh
iptables -A INPUT -i ex1 -p tcp --dport 1024: -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i ex1 -p udp --dport 1024: -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i ex1 -p tcp --dport 25 -j ACCEPT #smtp
iptables -A INPUT -i ex1 -p tcp --dport 80 -j ACCEPT #http
iptables -A INPUT -p icmp -m limit --limit 1/s -j ACCEPT #icmp
iptables -A INPUT -i ex1 -p udp --dport 123 -j ACCEPT #ntp
iptables -P INPUT DROP
iptables -t nat -A POSTROUTING -o ex1 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
さて、上記の’ex0, ex1’は見慣れないインターフェイス名だと思いますが、これはudevで別名を与えているためです。これまではそんなことはなかったのですが、今回はpcmciaの二枚のネットワークカードの認識順がなぜか一意に定まらない（つまり、どちらがeth0でどちらがeth1になるのかわからない）のでMACアドレスで特定の別名を与えることにしました。
*** /etc/udev/rules.d/50-network.rules ***
#for rita.karing.jp, pcmcia network card name configuration
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:40:b4:81:3b:62", NAME="ex0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:10:a4:04:ba:ad", NAME="ex1"
同一のHDDを複数の環境で動作させるため、ネットワークの設定は、仮想環境、実験機、実機、動作している環境に合わせて個別に設定されるように独自のネットワークスクリプトで対応しています。Gentoo謹製の方法でも可能なのかもしれませんが、学習コストがどれくらいかかるのか見当がつかなかったので自己流で行きました。ex0があれば実機、cpuのフラグにpseがあれば仮想環境、その他が実験機となっています。
動作しているサーバは、apache2, postfix, dovecot, nfsd, ntpd, telnetd です。前OSでは運用されていた named, dhcpd, sshd, proftpdは外しました。proftpdは昨今の利用状況を鑑み廃止です。named, dhcpdはバックアップサーバの担当とし、sshdは停止の上、ローカルなリモートログインはsshからtelnetに変えました。セキュリティの観点から外部ネットワークからのログインは基本的に遮断し、必要な時だけCGIによる操作でsshdを起動させ、外部からのログインを可能にしています。
telnetdは通常はinetd(xinetd)から起動されますが、inetd(xinetd)の管理するサービスがtelnetd一つだけだとリソースの節約にならないのでtelnetdは単独で動作させています。しかし、単独で起動させた場合、一つのログインセッションが終了するとそのtelnetdも終了してしまうので何らかの再起動プロセスが必要です。普段ならテキトウにシェルスクリプトでループさせるところですが、ここでリソース喰らいのシェルスクリプトを使っては本末転倒なので、inittabの設定でrespwanさせることにしました。これなら軽快です。欠点は、この場合、使用できるtelnetdは一つだけになり、telnetから複数のログインはできないことです。以下、/etc/inittab 一部抜粋、c2が当該の設定です。
# TERMINALS
#x1:12345:respawn:/sbin/agetty 38400 console linux
c1:12345:respawn:/sbin/agetty --noclear 38400 tty1 linux
c2:345:respawn:/usr/sbin/telnetd -debug 23
#c2:2345:respawn:/sbin/agetty 38400 tty2 linux
#c3:2345:respawn:/sbin/agetty 38400 tty3 linux
apacheはsuexecを外しています。利用者は一人しかいないのでsuexecは無用の長物と判断しました。
postfixはこれまでsmtpsやサブミッションポート(587)からのリレー（認証からのメール送信）に対応していましたが、技術的な検証の意味しかなかったので非対応にしました。現在の環境ではどこにいてもメールを出す方法はいくらでもあり、様々なリスクをとってまでこのサーバのsmtpを外部から利用可能にする理由もないと思います。
また、nfsdがなにかの拍子にメモリ不足で起動に失敗(unable to allocate nfsd_file_hashtbl)することがあり、/proc/sys/vm/min_free_kbytesを調整してみたりしたのですが、あまり効果は感じられず、それよりもnfsdの起動順をできるだけ早くすることで改善しました。起動順をopenrcに任せるとnfsの前にapacheとdovecotを先に起動させてしまうので、この二つは最後にlocal.dから起動させています。それでも失敗するときは失敗するのですが、何回か再起動すれば成功し、これまでのところ、一旦、成功すれば、その後、問題を出したことはないのでそのまま様子見ということになっています。
ここまで、アップデート等はHDDを別機に移して仮想環境(QEMU)上で行うとしてきましたが、前述の方法ではネットワークが不通になってしまうことがたまにあります。ダウンロードの最中に同一の場所で引っかかるので何か明確な理由があるように見えるものの今のところ原因不明です。この問題はQEMUのネットワークをUser mode networkにすることで回避できます。それなら最初からそうすればいいのでは？という話になりますが、実機のエミュレーションという観点からはTap networkの方が扱いやすいので問題が生じたときのみUser modeということにしています。
# qemu-system-i386 -enable-kvm -cpu 486 -M isapc -m 512 \
-drive file=/dev/sdc,format=raw -boot c -nic user,hostfwd=tcp::5555-:23
-nic以下がUser modeの設定です。userはuser modeであること、hostfwdはホスト機のTCP5555番ポートを仮想環境の23番ポート(telnet)にポートフォワーディングすることを指定しています。つまり、ホスト機の5555番ポートに接続すると仮想環境のtelnetに繋がります。ただし、QEMUの設定は非常に柔軟で同じ設定をするのに何通りもの記述法があったりするので設定法の混交・交錯には注意が必要です。上記で起動し、ネットワークデバイス(eth0, etc.)をdhcpクライアント(dhcpcd, dhclient, etc.)で設定すればあとはQEMUがすべて適当にやってくれます。
また、QEMUでのemergeの実行が異常に遅いときがあります。これは、emergeの実行に合わせてkworker/0:0-ata_sffがCPUリソースを食いつぶすようになるからです。原因は不明です。kworker/0:0-ata_sffはISAのPATAで、ディスクドライバをPCIのPATAにすればこの異常動作を回避できます。エミュレーションの精度は落ちますが、PCIのある環境でemergeを実行しても現実的な問題はとくに生じないので気長に待てないときはPCIに対応した環境で作業しています。PCI対応のQEMUでは、-M isapcははずし、nicのmodelはne2k_isaは使えないようなので指定せず、デフォルトのe1000を使用しています。
# qemu-system-i386 -enable-kvm -m 512 -drive file=/dev/sdc,format=raw -boot c \
-net tap,script=qemu-ifup -net nic
config-5.15.26-pci（gentoo, PCI対応）
この486機のルータとしてのスループットは最大500kB/s(4Mbps)ほどで、当LANのADSLはおよそ300kB/s(2.4Mbps)なのでなんとかこの486機がボトルネックになることだけは避けられているという状況です。以下が当LANの概観図です。SIM Free Routerからのドコモ回線は緊急用で20kB/s程度しか出ませんが、月額約500円で常時接続の運用が可能なのはけっこう気に入っています。主回線であるADSLはブリッジ接続になっており、rita.karing.jpには直接グローバルIPが割り当てられています。つまり、当LANに入ってくるほぼ全てのパケットはこの486機を通過していることになります。
起動時間（ブート開始からログインプロンプトが表示されるまで）は9分前後で、前OSでは8分弱でした。現OSでは起動させるサービス数が明確に減っているのに起動時間が増えた最大の原因はopenrcがサービスの起動順を自己解決しているためで、この処理が486機にとって相当の重荷になっています。
以下は、freeの出力です。概ね、前OSと同じような感じです。現OSでは、前OSでは動作していた named, dhcp, sshd, proftpdを停めているのでもう少し余裕があってもいいような気がしますが、kernel肥大化の影響か、なかなかそうはいかないようです。
| total | used | free | shared | buff/cache | available | |
| Mem: | 26772 | 11220 | 1744 | 4 | 13808 | 5296 |
| Swap: | 65532 | 9306 | 56228 |
次にpsと/proc/cpuinfoです。約70プロセスが動いています。今、手元のFedoraでは250でした。プロセス数にしてFedoraの30%弱ですが、スペック差から見れば普通に百倍単位のオーダーなので一つ一つのプロセスの重みには格段の差があります。一番メモリを消費しているのはapacheで起動数を2~3にしたいのですが、設定を変えてもなかなか減らないので難儀しています。bogomips: 36.86は現在のマシンから見れば誤差でしかありません。
azami ~ # ps ax -o comm,size,user
COMMAND SIZE USER
init 300 root
kthreadd 0 root
kworker/0:0H-kb 0 root
mm_percpu_wq 0 root
ksoftirqd/0 0 root
kdevtmpfs 0 root
inet_frag_wq 0 root
oom_reaper 0 root
writeback 0 root
kcompactd0 0 root
kblockd 0 root
ata_sff 0 root
kswapd0 0 root
scsi_eh_0 0 root
scsi_tmf_0 0 root
pccardd 0 root
pccardd 0 root
kstrp 0 root
jbd2/sda2-8 0 root
ext4-rsv-conver 0 root
kworker/0:1H-kb 0 root
systemd-udevd 484 root
kworker/0:2 0 root
jbd2/sda1-8 0 root
ext4-rsv-conver 0 root
syslogd 304 root
crond 1248 root
dhclient 1100 root
rpcbind 320 root
rpc.statd 332 nobody
rpciod 0 root
kworker/u3:0-xp 0 root
xprtiod 0 root
rpc.idmapd 364 root
rpc.mountd 420 root
kworker/u3:1-xp 0 root
lockd 0 root
nfsd 0 root
nfsd 0 root
nfsd 0 root
nfsd 0 root
nfsd 0 root
nfsd 0 root
nfsd 0 root
nfsd 0 root
ntpd 1268 root
master 396 root
pickup 400 postfix
qmgr 504 postfix
dovecot 448 root
anvil 320 dovecot
log 452 root
config 1264 root
apache2 1216 root
apache2 1216 apache
agetty 312 root
telnetd 340 root
login 472 root
bash 900 root
kworker/u2:0-ev 0 root
nfsiod 0 root
NFSv4 callback 0 root
kworker/0:0-eve 0 root
stats 332 dovecot
kworker/u2:1-ev 0 root
apache2 1216 apache
apache2 1328 apache
ps 972 root
|
azami ~ # cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 4
model : 8
model name : 486 DX/4
stepping : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme cpuid
bugs : itlb_multihit
bogomips : 36.86
clflush size : 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:
 |
体感的な使用感としては少しモッサリするようになりましたが、高負荷をかけるとまったく反応しなくなるみたいなことは今のところなくなりました。ただ、lessは明らかに重くなりました。lessは多用するコマンドなのでもっと軽いページャーを探そうかなと思っています。
今回のOSアップデートにおける最大の不安はデイスクドライバの変更でした。最大値においては、新旧、差はないような気がしますが、新ドライバ（libata legacy対応）は計測値にバラつきが多く、その分、遅いように思います。
azami ~ # hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 12 MB in 2.07 seconds = 5.80 MB/sec
Timing buffered disk reads: 6 MB in 3.61 seconds = 1.66 MB/sec
このサーバの主用途はインターネットと当LANをつなぐルータとしての役割で、パケットの出入りから推測すると概ね2/3がそのために稼働しており、残り1/3のリソースで各サーバが稼働している感じになります。そして問題は、各サーバのリソースの99%はスパムやボットや不正アクセスで消費されているということです。外部の利用者がほとんどいない個人のサーバでは統計的にそうなってしまうのは仕方がないことなのかもしれませんが、それらの無駄なリソース消費がなければ namedもdhcpもsshdも運用できたのにと思わなくもなく、こういう日常の悪意が、事実上、放置されていることにいささかの憤りを憶えます。
最近ではフロッピーデイスクなどは見かけることさえなくなってしまいましたが、486機を利用する上でフロッピーディスクを活用できるかどうかはその利便性を大きく左右します…と言いたいところですが、現代の環境下では1.44MBは小さすぎて何の役にも立たないのが実情です。起動ディスクとしての役割は普遍ですが、HDD交換が前提の運用ではその価値も低下します。とはいえ、486機を運用する上でフロッピーディスクからの起動について考察しないのはある種の不備みたいなものなので、ここではGRUBによる起動ディスクを作成します。
前回（486機でVine 6.1）作成のブートディスクは、kernelをフロッピーディスク上に保持していましたが、今回のkernel-5.15.26は2.5MB程度あり、フロッピーディスク内に収めることは不可能で別のメディア上にあるkernelで起動するという動作になります。前回使用したliloはファイルシステムが読めないためこの動作には不向きでここではブートローダはGRUBを選択します。
GRUBのマニュアル的には
# mke2fs /dev/fd0
# mount -t ext2 /dev/fd0 /mnt
# mkdir /mnt/boot
# grub-install --boot-directory=/mnt/boot /dev/fd0
# umount /mnt
上記で作成するみたいに書いてあったりしますが、少なくとも現在のGentooでは上記の方法では作成できません。最大の原因は単純にフロッピーディスクの容量不足です。現在では起動メディアはUSBメモリが前提になっており、容量の制限などは意識されておらず、デフォルトではその容量は12MBぐらいになります。ただし、その容量の大半はthemeやfontなど起動には直接関与しない部分で、grubの起動イメージは2MB弱になります。2MB弱では1.44MBのフロッピーディスクには入らないわけですが、モジュール化されたgrubの起動イメージはその大半が不用であり、最小構成では500kB弱で起動ディスクの作成が可能です。下記がその最小構成です。
# grub-install --allow-floppy --force --install-modules="ext2 linux ls part_msdos" \
--locales=ja --themes=none --fonts=ascii.pf2 \
--boot-directory=/mnt/boot /dev/fd0
「--allow-floppy」は起動メディアがフロッピーディスクであることを指定します。前述のように現在のgrub-installはデフォルトとして起動メディアをUSBメモリと想定しているためフロッピーディスクでは必須です。また、起動ディスクを作成する場合、動作中のシステムに二つの/bootが存在するような状況になるのでgrub-installは警告を出して終了することがあります。「--force」はこれを避けるためのオプションです。そして、「--install-modules="ext2 linux ls part_msdos"」が本項の核心で最小構成のモジュール群を指定しています。厳密には利用可能なデバイスを表示するだけの'ls'はいらないのですが、コマンドラインではないと不便です。'part_msdos'でパーティションを読み、'ext2'でファイルシステムを読み、'linux'でlinux kernelを読み込みます。これで単純にbootできます。「--locales=ja --themes=none --fonts=ascii.pf2」はなくてもいいはずなのですが、指定しないとデフォルト設定が使われて容量をオーバーします。
作成されたブートディスクで起動してみます。「-boot a」でフロッピーディスクから起動します。
# qemu-system-i386 -enable-kvm -m 512 -cpu 486 -M isapc \
-drive file=/dev/sdc,format=raw -boot a --drive file=/dev/fd0,if=floppy,format=raw
grubが起動したらコマンドラインから必要なモジュールを読み込ませ、順次、機能を拡張し、ブートの準備を進めていきます。また、コマンドラインではbashのような補完が効きます（Tabの押下）。lsでは利用可能なデバイスが表示されます。知らないシステムでもこれでだいたいの見当がつきます。最後、bootで起動します。
grub> insmod part_msdos
grub> ls
(fd0) (hd0,msdos2) (hd0,msdos1)
grub> set root=(hd0,msdos2)
grub> insmod ext2
grub> linux (hd0,msdos1)/vmlinuz-5.15.26.gentoo root=/dev/sda2
grub> boot
この一連のコマンドをバッチファイル化したものがgrub.cfgであり、ブートメディアの/boot/grub/に存在すれば、grubが読み込んで実行、起動することになります。フロッピーディスクをumountする前に以下のようにgrub.cfgを作っておけばコマンドラインは表示されず、システムはすぐにブートします。
# echo "insmod part_msdos
set root=(hd0,msdos2)
insmod ext2
linux (hd0,msdos1)/vmlinuz-5.15.26.gentoo root=/dev/sda2
" >/mnt/boot/grub.cfg
プロンプトやメニュー表示にしたい場合はそう書けばそうなります。以下はメニュー表示の例です。
# echo "
menuentry '5.15.26-karing' --id 0 {
insmod part_msdos
insmod ext2
insmod linux
set root=(hd0,msdos2)
linux (hd0,msdos1)/vmlinuz-5.15.26-karing.1 root=/dev/sda2
}
menuentry '5.15.26-gentoo' --id 1 {
insmod part_msdos
insmod ext2
insmod linux
set root=(hd0,msdos2)
linux (hd0,msdos1)/vmlinuz-5.15.26-gentoo.4 root=/dev/sda2
}
" >/mnt/boot/grub/grub.cfg
ここまでの作業は、ISAオンリーな486機（もしくはその仮想環境）で動作するGentoo上で行ってきましたが、本稿におけるもう一つの実行環境、Fedora Core 34(x86_64)から行う場合はアーキテクチャ横断な作業になるのでそれに対応するオプションが増え、いくつか名称も変わります。
# grub2-install --force --allow-floppy --install-modules="ext2 linux ls part_msdos" \
--locales=ja --themes=none --fonts=ascii.pf2 \
--target=i386-pc --boot-directory=/mnt/boot /dev/fd0
まず、Fedoraでは、grubではなく、grub2となっています。さらに、64bitな環境で32bitのものを作成するのでその旨を指示する「--target=i386-pc」のオプションを付加します。また、Gentooで作成したブートディスクでは、grubのファイル群はすべて/boot/grub/以下に配置されていましたが、Fedoraでは/boot/grub2/以下に配置されています。
今回のブートディスクの作成では、さすがに現代の環境でフロッピーディスクを使っている人はいないようで、めぼしい情報がなく、ほとんど自己解決になってしまったのですが、一番苦労したのはそこではなく、一番苦労したのはまともなフロッピーディスクを探すことでした。手持ちのフロッピーディスクの2/3がダメになっており、残りはXE4100のBOISディスクなどの重要なものが大半で実験に試用できるディスクが一、二枚しかなく、これもいつIOエラーを出すのかとハラハラしながら使っていました。なんとか無事に検証は終わりましたが、この後、ストックを探すのか、やっぱり今更なのか悩みます。
今さら、486機を保守する意味もないのですが、壊れても交換できる物は交換することを考えました。この機体で交換可能な主なハードウェアはPCMCIAのネットワークカードとHDDです。PCMCIAのネットワークカードは諸々の事情でスペアが潤沢にあり、将来的に困ることはおそらくないのですが、問題はHDDです。手元に残っているIDE 44pin 2.5inchは3台しかなく、それもジャンクとして拾ってきたものばかりなので信頼性は皆無です。昨今では正規品として購入することは困難で、プレミアをつけてまで入手するのかとなると否定的な結論にしかならず、本項では他の方法を探りました。それは、他メディアのIDE変換(44pin 2.5inch)です。
検証したメディアは、SDカード、CFカード、mSATAです。結果から言うと、CFカードのみ使用可能でした。CFカードは純粋なATAなのでたぶん行けるだろうと予想はしていましたが、CFカードは他のメディアに比較し流通量が少なく割高なので（SDカード 10円/GB、CFカード 100円/GB、mSATA 20円/GB）、できるだけ他の選択肢を取りたかったということです。
SDカードのIDE変換は486機のBIOSからHDDと認識されず、mSATAのIDE変換はHDDと認識はされるもののパーティションテーブルが読めず、使用できないという結果になりました。とりあえずHDDとして認識されているのならばBIOSからパーティションテーブルが見えなくともGRUBからは見えるかもしれない、ということで前項の試行錯誤に至ったわけですが、結局、パーティションテーブルはGRUBからも見えませんでした。まだ、kernelからは見えるという可能性は残っていますが、現在のkernelはフロッピーディスクには収まりきらず、HDDから起動できなければ起動できないFROLA 3010CTでは手詰まりとなりました。なお、SSDや通常のSATAをIDE変換した場合もmSATAと同じ結果でした。
ISAオンリーな486機のBIOSではHDDはCHSのみの対応で昨今のストレージデバイスは旧来のCHSをサポートしていない、というような齟齬が生じていると思われ、これもPCIがある環境ならば改善されているのではないかと推測しています。また、SDカードのIDE変換をUSB接続した場合も同様にパーティションテーブルが読めません。それでも書き込むことはできるのですが、その新たに書き込んだパーティションが有効なのはkernelがそのパーティションテーブルを記憶している間だけで、何らかのアクションでそれが破棄されると再びパーティションテーブルが読めなくなってしまいます。そのSDカードもSDカードリーダーではちゃんと読めるのでやはりIDE変換にのみ難があるようです。
唯一使用可能だったCFカードのIDE変換の性能はどれくらいかと言えば、1MB/sがなかなか出ず、残念ながらHDDの半分程度でした。HDDはジャンクとして入手したものばかりなので信頼性が低く、他メディアのIDE変換が使用可能ならば多少性能で劣っても信頼性と入手性でIDE変換を使おうかとも考えていたのですが、この性能差ではHDDを採用せざるを得ませんでした。
ここ何年かの懸案であった新OSへの更新がなんとか終わりました。486機非対応のVineを無理矢理インストールしてみた前回、前々回に比べ、さすが486公式対応のGentooは簡単でした。ただ、作法や方言に慣れていないので、@worldって何？なんでそこでそんな単語を使うん？？？みたいなことがよくあり、楽は楽でしたが、意外に疲れました。運用に関しては色々シンプルにしたので少し楽になりました。まだ、新しくなったlogの構成や癖がわかっていないので現在は経験の蓄積待ちといったところです。
前OSは九年間も使い続けたわけですが、Vine Linux 6.x - kernel-3.4.98くらいがおそらく486機の限界だったのではないかと思います。Vine 6.5では最終的にkernel 4.xに移行し、それに合わせkernelのアップデートの検討はしたものの4.xのメリットが見当たらず、結局、3.4.98を最後まで使い続けることになりました。新OSもそれなりに動作はしていますが、それは様々な工夫と妥協の結果であり、技術的検証という無駄を実行する余裕がまだあった前OSとは多少の差があると思っています。
さて、今後どこまで行けるかですが、今現在はルータとしてのスループットが主回線であるADSLを上回っているためすべてのパケットを486機に通すなどという酔狂ができていますが、ADSL回線の廃止にともないより高速な回線が導入された場合、少なくともこの486機はルータの任からは外されることになるでしょう。それ以上どうするかは未定ですが、大きなターニングポイントになるのは確実です。また、kernelの486対応が終了した場合はその最終版で一年間の運用を行い、486機での運用を終了したいと考えています。いずれにせよ、そう遠くない未来の話であり、それまで無事に動き続けてほしいものです。
2022-03-31 よしのぶ