去る１１月２０日付で FreeBSD 14.0-RELEASE がリリースされたとのアナウンスがありました。私の場合は 11/18 にとある日本の ftp サーバに置いてあるのをたまたま知りましたので、そのまま落としてきてリリースノートと見比べながらフムフムとうなづきながらとりあえず VMware に入れてみました。インストーラの動きは微妙に異なりますがほぼ同じ動きをするように見受けられました。大きな違いがあれば何か書いてみようと思っていましたが、使ってるフォントがちょっと異なるかな程度とメッセージの出力が少々異なるかなくらい程度なので特筆することもないことからスクリーンショットを取っただけでデスクトップのフォルダの肥やしになっています 🙂
そこで、13.2 のマシンを 14.0 にアップデートしてみることにしました。OS は特に問題なくアップデートできたのですが、そのうえで走っているポーツの再コンパイルにてこずってしまいましたので、そのあたりのお話も書けたらと思っています。ただ、相当てこずったのでスクリーンショットをとることをしていません。文字だけになりますので悪しからず 🙂
simplest virtual machine
まず最初に選んだマシンはナンチャッテ証明書を管理しているマシンで、特別なソフトウェアは動いていませんので、krb5 さんで行ってみることにしました。まず一番最初なので、krb5 さんを完全停止の状態で VMware のスナップショットを作って不測の事態に備えます。まずは OS のバージョンの確認です。13.2 のパッチレベル 5 が入っています。
running freebsd-update
マニュアルに従って、13.2 から 14.0 にアップデートするコマンドを入力します。
インストールされているコンポーネントの確認があります。
インストールしたコンポーネントに間違いがなければ先に進みます。
パッチファイルを落としてきてパッチを適用してゆきます。
merging customization
自動でパッチの適用ができない部分は人手でやるように指示が出てきます。
以前の 13 でのマイナーアップデートと同様に変更される部分が >>>>>>> や <<<<<<< に挟まれているので、違いを確認しながらどうなってほしいのかを入力してゆきます。
この場合 /etc/group ファイルで pokemon さんは wheel グループに残ってほしいわけです。
root ユーザにはパスワードがセットされていますので、同じパスワードを使いたいわけです。
が、よく見るとシェルが csh から sh に変わっています。この辺りに注意してマージしてゆきます。
家庭内のデバイスは直接外部の NTP サービスにアクセスできないようにしています。
ですのでそのあたりを考慮してマージしてゆきます。
kerberos も使えるようにしています。
変更されるファイルのリストが出力され、アップデートの実行を促されます。この時点で OS には何の変更もされていません。すべては別のディレクトリ内に準備されています。
Ready to Go になったファイルを移動して、ここから先はシステムに変更が加えられます。
first install pass
最初の実行では、カーネルファイルがインストールされました。新しいカーネルでブートしてきます。
再起動後、再度バージョンを確認してみます。今度は running カーネルも 14.0 になりました。
second install pass
次に 14.0 のカーネルで動くバイナリファイルをインストールします。
ちょっとエラーになったようですが大きな問題には見えないのでそのまま進みます。後で必要に応じて対応できるようにエラーはメモしておきましょう。
updating ports on FreeBSD 14
再度バージョンを確認しておきます。全て 14.0-RELEASE になりました。パッチの適用の部分に時間がかかりましたが、このマシンで１時間弱でここまで来れました。物理マシン２台と仮想マシン６台があるのですが、死ぬかと思ったのが i386 プロセッサの dhcp さんでした。パッチの実行部分まで準備して、外でひとしきり Ingress の CF を作ってポイントをゲットして帰ってきてどうなっているかのぞき込んでみると、パッチファイル 30000 番台をまだ実行中でした (T T)。
ここからは portmaster コマンドで全てのポーツを再コンパイルして再インストールしなおします。が、ここからがトラブルの始まりでした。まず最初に引っ掛かったのが、python でした。デフォルトの python は 3.9 のままなので再コンパイルだけで OK かと思ったのですが、python39 のコンポーネントのいくつかがエラーで再インストールできません。ポーツツリーが古いままなのが問題かと思い portsnap で最新にしようとすると portsnap は 14-RELEASE から消えてなくなっています。リリースノートに書かれていたので知ってはいたのですが、トラブってるときにそれが顕在化したので慌てました 🙂 git コマンドがその置き換えということだったので、git だけを再コンパイルしようと思ったのですが、コンパイルに必要な gcc が 13.0 API のままだったので使えず、仕方がないので pkg install git でパッケージでお茶を濁しました 🙂 これでポーツツリーも最新になったので大丈夫かと思いきや、同じエラーが出てきて先に進めません。そこで次に試したのは python39 を python310 に置き換えることでした。まぁ、そのうちにデフォルトの python も 3.9 から 3.10 に変わるからまぁいいか。。。という安易な理由です。そこで、3.10 でも python のコンポーネントを同じにするために pkg info -o py39-xxx でポーツのディレクトリを取得して後で portmaster に喰わせて py310-xxx をインストールしてやろうと思いました。が、ここでまたはまります。/etc/make.conf で python310 を使うと書いたつもりが、make コマンドはどうやっても python39 を使おうとします。そこで、/etc/make.conf 関係をよーく眺めてみると、このようにかいていました。
DEFAULT_VERSIONS+=python3=3.10
もしかしてバグか？と思って、/usr/ports/Mk/bsd.default-versions.mk で指定されているバージョンを 3.9 から 3.10 に変更して再コンパイル/再インストールしました。krb5 さんは何とかなったのですが、他のマシンでも同じ間抜けをしてしまい、python39 を python310 とパラでインストールして途中で止まってしまいました。そこでまずはこの問題を解決しようと思い /usr/ports/Mk/bsd.default-versions.mk を眺めていると、phthon3 のバージョンを指定しているのではなく、python のバージョンを指定していました。ですのでよい子の皆さんはこのように書いて無駄な時間を使わないようにしましょう 🙂
DEFAULT_VERSIONS+=python=3.10
これを見つけるのに何日もかかってしまったので、間抜け加減に嫌気がさして VMware のスナップショットで元に戻してしばらくアップデートから遠ざかってしまいました 🙁 Ingress でしこたま CF を稼いで気分が良くなったので、再度アップデートに着手。krb5 さんは特に何かをサービスしているわけではないので、ディスクが小さなシステムです。その割に 4 CPU のシステムにしていて、大きなコンパイルプロセスが4パラで走るのでスワップが全然足りない状況になってしまいました。OS 自体も最小のディスク構成だったので、VMware で仮の一時ディスクを追加して /usr/ports を別ファイルシステムにして、仮のスワップも追加して余裕のある状態で何とか全てのポーツを再コンパイルして全ての VMware 上のサーバのアップデートが完了しました。
the oldest 64bit physical machine
次に着手したのが非常に古い64 bit マシンの esxi さんです。因みにこれは VMware ESXi ではなく、単なる FreeBSD のマシン名です。VMware は esxi02 という名前です。これもまた死にそうになってしまいました。とにかく古いマシンなので、コンパイルが遅いのです。仕方がないので、VMware の 64bit マシンでコンパイルした gcc12 や cmake-core などから pkg create コマンドでパッケージを作ってそれを esxi で pkg install でインストールしてズルしてしまいました。それでもそれら以外は何とか自力で再インストールして、13.2 -> 14.0 のアップデートを完了することができました。当然すべてのポーツを 14.0 API で動くようにしてから再度 freebsd-update install 実行して 13.0 API のライブラリを削除する必要があります。
the oldest machine which has 32bit processor
頭が真っ白になりかけたのが i386 の最古のマシンです。何をするにも時間がかかります 🙂 15,6 年前のパソコンですから当然と言えば当然なのですが、アーキテクチャが異なるので、他のマシンで作ったパッケージを使うことができません。これも python39 の再インストールが失敗するマシンで、python310 に変更しました。その後、大きなポーツを pkg upgrade で 13.0 API から 14.0 API にズルして変更しようとすると、依存関係でデフォルトの python39 が入れられて、python310 とコンフリクトがあるということで真っ白になってしまいました。依存関係のあるポーツを削除してから大きなポーツを pkg upgrade して、それから他のポーツをコンパイル/インストールして何とかアップデートが完了しました。この dhcp さんだけで１週間程度時間をかけてしまいました。
この dhcp さんですが、私のメールサーバとして使っています。つまり、sendmail や imap が動いていたわけです。アップデートが完了してハタと気づいたのですが、メールが届いていない？これもリリースノートに書かれていたので知ってはいたのですが、python39 騒動で MTA がデフォルトでは dma ( DragonFly Mail Agent ) になってしまっていたことを忘れていました。そこで、/etc/mail/mailer.conf を dma から sendmail に書き換えてメール環境も OK となりました。
会社で使っていた FreeBSD は M$ Azure DC への移行に関連してそれまで使用していた 32 bit OS から 64 bit OS に変えた 10.0-RELEASE あたりからアップデートを繰り返して使っていたので、メジャーアップデートも何度も行ってきました。でも、今回の 13.2 -> 14.0 はてこずってしまいました。これからアップデートを行おうとされている方は余裕を持ったスケジュールと、完璧なバックアップを取ってから行ことを強くお勧めいたします 🙂 リリースノートをよくお読みいただけるとわかるのですが、freebsd-update コマンドではメジャーバージョンを変えたアップデートの場合、ロールバックをサポートしていません。つまり、自分で取ったバックアップが元へ戻すための唯一の方法となります。加えて、ブートローダの更新も必要になる場合があります。VMware のお勧めのハードウェア構成では BIOS を使っていますし、古い実機２台も EFI をサポートしていないものなので、BIOS マシンしかありません。リリースノートによると、更新が必要となる条件は ZFS を root に使用している EFI マシンということです。
さくらインターネットのレンタルサーバーとの出会い
私にとって FreeBSD と言って思い出すのが、このサイトをホスティングしてもらっているレンタルサーバのサービスです。当初ブログを公開するときに考えたのは自宅のインターネット回線からの公開を考えていました。回線のキャパからすると、ニッチなサイトの1つや2つ問題ないわ。。と考えていました。たぶんパソコン１台に VMware ESXi 入れて、本番とテスト用のワードプレスと共有の mariadb のサーバー立てて、管理用に cacti か zabbix の snmp マネージャ位かと思って居ました。で、考えました。新しいパソコンを購入して自宅で運用するとすると、電気代も馬鹿になりません。電気代は時間が経てば増える一方ですがパソコンは逆に償却で安くなってゆきます。大体会社では５年経つとパソコンも新品と交換してくれます。そこで、このセットを５年使うとして、なんだかんだで３０万円と仮定すると、月額に換算すると５０００円程度と計算できます。そこでまた考えたのです。毎月５千円で自宅でサイトを公開するよりも安くサーバーの間借りができないかなと。そこでレンタルサーバーを調べ始めたのですが、まぁ、たくさんの数のサービスがあることを知るわけです。私もとある会社でネットワーク管理者をしていたことから、以下の選択基準を満たすサーバーを使用するための総額の月額を調べてみようと調査を始めたわけです。
まぁ、会社で IT をしていると２つの側面を持って仕事をするようになります。一般ユーザの利便性と IT サービスの安定性。これらのことから一般ユーザには Windows クライアントを、Active Directory などの Windows サービス以外のIT サービスには Linux を選んでしまうわけです。
会社のネットワークを思い起こすと、データセンターが止まって問題が起こったことよりも、オフィスで停電になったり、ケーブルを切ったりするような問題の方がはるかに多かったわけです。どのデータセンターでも短期的な障害を乗り越えるだけの設備は当然備えているわけで、違いは障害をどれくらい乗り越え続けられるかということにつきます。
どのようなサイトにしようかと考えたときに、仕事の続き感覚で英語のグローバルなサイトにするか、心機一転、日本語で日本ローカルなサイトにするかの選択をしなければなりませんでした。これはアフィリエイトの仕組みとも関係があるのですが、簡単にグローバルにアフィリエイトを行うには google adsense がやりやすい。国内のアフィリエイトサイトを見てみると国内のサービスばかりの取り扱いがメインとなっているように見えますし、海外のアフィリエイトサイトを使うには敷居が高い。
私の自宅は大阪にありますので、大阪のデータセンターでホスティングしてくれるサービスを選びたいわけです。
まぁ、Linux カーネルベースの OS だとオペレーション的にも安定性的にも許容範囲と思っていたところに、昔から使っていた FreeBSD が使えるのは非常にうれしい。。加えて大阪でホスティングしてくれるさくらのレンタルサーバーが最有力候補に。さくらインターネットと言えば北海道で起こった大地震に起因する長時間停電を乗り切ったことが今でも記憶に新しい。私は現在スタンダードプランを使わせてもらっていますが、実は最安プランではありません。最安プランは月額換算で１２８円の超格安。今どき缶コーヒーを自販機で買っても１４０円します。でも残念ながらこのプラン、ワードプレスが使えません。我々 WEB 初心者としてはワードプレスは必須の機能。このことからスタンダードプランを選びました。adsense や affiliate に関係なく、純粋にブログとして１年以上使っていますが、全く問題なく快適に使わせてもらっています。サーバー本体のレンタル料と SSL 証明書の料金、これら２つで月額７００円弱。私は月払いにしているのと、有料の SSL 証明書を使いましたが、無料の SSL 証明書を使用することで、月額５００円台で。さらに３年一括にすることにより、４００円台とお得にワードプレスを使うことができます。
コメント