昨日は久しぶりの出張で、名古屋のオフィスへ出かけてきました。昨年ジョインした東京の IT サポータが大阪や名古屋のオフィスに行ったことがないと情けないことを言っていたので、それぞれの上司間の話し合いで2日間名古屋、大阪と案内することにしました。名古屋へ向かう新幹線では目を覚まそうとスタバのお世話になりましたが、瞼は重たいままで待ち合わ場所に向かいました。その日のうちに名古屋から大阪へ向かい、晩飯を一緒に食べて、翌日は大阪で一日情報交換を兼ねて一緒に仕事を行きました。まぁ、日本人ではないので、へっ？と思うことが随所にありましたし、あちらも同じようにへっ？と思う部分があったと思います。ただ目的はより良い IT 環境を提供することにあるので、協力関係は築けるはずです。。
ポーツ
では、同じことをポーツでやってみましょう？まずポーツツリーを作ります。ポーツツリーをコピーするには portsnap コマンドを使います。
まず /var/db/portsnap ディレクトリにフェッチします。
フェッチしてきたものを /usr/ports へ展開します。
因みに一旦 /usr/port へ展開した次からはフェッチの後は update を行います。つまり、/var/db/portsnap と /usr/ports の差分だけを適用します。
では改めて pkg コマンドで古いポーツを探してみましょう。
たくさんありました。では、これらのポーツをデフォルトのコンパイルオプションでコンパイルしてアップデートしてゆきましょう。この時にデフォルトのオプションをそのまま受け入れることを宣言しておきます。
コンパイルオプション
portupgrade コマンドで古いポーツをコンパイルして新しいバージョンに置き換えます。
ソースコードがダウンロードされ、/usr/ports/distfiles ディレクトリに保存されます。
一つだけ失敗したようです。もう一度同じことをしてみます。
別のエラーが出てきたので対処してみます。エラーの内容は open-vm-tools と open-vm-tools-nox11 が競合するというものです。現在インストールされているのは nox11 です。新たにインストールしようとしているのはどうも X11 版です。これに加えてもう一つメッセージが出ています。名前が open-vm-tools-nox11 は open-vm-tools に変わったとも書かれています。
これでもいいのですが、基本 GUI は使わないので、nox11 版としてコンパイルしてみます。そのために何をすればよいかというと、まず /usr/ports/emulators/open-vm-tools ディレクトリの Makefile を眺めてみます。と、FLAVOR が nox11 の時は LIBNOTIFY と X11 オプションを外すと書かれています。どうもこれのようです。
ではそのオプションを /etc/make.conf に入れてみます。
nox11 の名前はポーツ名からなくなりましたが、コンパイルオプションで X11 関係を外しましたので、コンパイル後は nox11 版の vmware tools になったはずです。
確認してみましょう？
インターネット時代
libX11 ライブラリは使用されていないのでこれでよさげです。実はコンパイルの途中でファイルシステムがフルになってしまい、途中で止まってしまいました。コンパイル作業に必要なツールを入れたことも一因ですし、ソースコードを落としてきたことも一因です、ドキュメントを入れたことも響いていると思われます。open-vm-tools のドキュメントは TeX のソースをコンパイルして可読書式のファイルを作ります。そのための TeX 一式がとても大きいようです。当然のことながら対処としてはファイルシステムを大きくするか、ドキュメントを入れないようにするかの選択を行います。ドキュメントを読むことはシステム管理の基本なので重要なのですが、ネット時代のシステム管理であると考えると、ドキュメントはどこででも読むことができます。ですので、ファイルシステムを大きくする方法は別の機会にお話しするとして、ドキュメントを入れないオプションを付け加えて入れたいソフトウェアを入れなおします。過去記事より、インストールしたのは pdksh py38-speedtest-cli samba413 portmaster portupgrade unix2dos sudo bash open-vm-tools-nox11 だけでした。ドキュメントを入れないオプションを付け加えてポーツから入れなおします。また脱線してしまいますが、4.2BSD を使い始めたときはいかにして TeX のソースをプリンタで印刷するかという課題に最初に取り組みます。知り合いの大学の先生にお願いして TeX のソースコードを MT でもらってきて、ファイルに展開してそれを何日もかけてコンパイルして TeX が出来上がります。その出来上がった TeX でマニュアルをコンパイルして dvi フォーマットのファイルに変換して、それをさらに dvips でポストスクリプトに変換して、これをポストスクリプトプリンタに出力して紙のマニュアルを作った記憶があります。勿論 dvips もソースコードからのコンパイルです。数十年前の記憶なので間違っていたらごめんなさい m(_ _)m 元に戻ります。例えば、bash のコンパイルしなおしはこのようにします。
これは bash の例ですが、pdksh を入れなおすときは気を付けましょう。自分の足元を壊すことになるので、コンソールから root で行います。その前にどのパッケージにもドキュメントがありますので、アプリケーションごとに調べるのは面倒なので、いったん入れたものを全て削除して、ポーツから入れなおします。忘れないうちにドキュメント不要のオプションを入れておきます。
make config
あっ、そう言えば /etc/make.conf ファイルはいきなり出てきたように思います。これが何かというと、make を実行するときのコンフィグレーションオプションを指定できるファイルです。bash でオプションを指定してみましょう。明示的に make config を行うことでオプションを変更することができます。
こんな感じです。
[x] とチェックマークが入っているオプションが定義されているオプションです。デフォルトで DOCS オプションは定義されている模様。/etc/make.conf を元に戻してもう一度やってみます。Ctrl-C で終了して /etc/make.conf を元に戻します。
また横道にそれてしまいますが、画面がもっときれいでなきゃいやだといわれる向きには、TERM 変数を xterm にしてみると見目麗しき状態になります。
というのも、xterm は vt220 をベースにしていると記述がありますので、基本 vt100 でもまともに動くと思います。ですので、設定ファイルで TERM を xterm にして、Tera Term で terminal id を vt220 にすると完全に動くはずです。
元に戻ります。そして make config を実行します。
外したいオプションが外れました。因みにここで OK を押してオプションを保存すると、その保存した内容は、このように保存されます。個々の options ファイルは /etc/make.conf よりも優先度が高くなります。
現状では /etc/make.conf で統一できますので、このファイルは消しておきます。準備完了ですので、インストールしたパッケージを全て消しましょう。自分の足元で動いている pdksh まで消えてしまいますので、/tmp/cmd ファイルを編集して pdksh を削除しないようにしてから /tmp/CMD をシェルに喰わせてやります。勿論各 pkg コマンドを手でタイプして実行しても構いません。めんどくさくなければですが 🙂
予定通りに削除できました。
では、パッケージでインストールしたアプリケーションをポーツでコンパイルして入れてゆきます。簡単なスクリプトを書いて、実行します。たぶん時間がかかります。乞うご期待！
おやすみなさい ZzZ
さて、状況はというと、コンパイルは完了したようです。
最後に pdksh をコンソールで root ユーザで行います。
最後にパッケージインストール時に修正したバグなどの対応も残っていることを確認します。と、調べようとすると、起動スクリプトの数が異なっていまして、バグ対応したアプリもなくなっていました。たぶん、依存関係から必要なくなったものと推測します。
確認
とりあえず再起動して期待通りに動くかどうかを確かめてみましょう。
再起動すると、nmbd がマスタブラウザになったといっています。samba413 は OK のようです。ログインできたので、ksh も大丈夫のようです。
vmtools 関係も OK そうです。
dbus daemon も OK です。
最後に avahi 関係も起動させましょう。
bash も入りましたし、ディスクの使用量も半分程度に収まりました。めでたしめでたし 🙂
総括
２回に分けで FreeBSD のメンテナンスに関して書いてみましたが、ポーツのほうがはるかに柔軟な運用ができます。では、どういう場合にポーツを使うのか？例えば、php として利用可能なバージョンとして、7.4、8.0、8.1 が使えます。apache 2.4 をパッケージで入れてその依存関係で php が入った場合、デフォルトの 8.0 が入ってしまいます。他のアプリケーションとの関係で php を 7.4 にしておきたいというような場合に困ってしまいます。そのような場合はポーツを使って /etc/make.conf ファイルに明示的に php のバージョンはこれ！と書いておくと、どのアプリケーションもそのバージョンを使ってコンフィグレーションできます。
あるいは、デフォルトのコンフィグレーションオプションで作成されている全ての必要とするアプリケーションが期待通りに動くのであればパッケージベースのメンテナンスがお勧めです。そうではなく、特殊なコンフィグレーションオプションが必要な場合や、標準オプションで期待通りに動かない場合、あるいは、ソフト自身にバグがあると思える時に、/etc/make.conf を作ったり、ソースコードを変更してからコンパイルしたりする必要がある場合はポーツベースのメンテナンスをお勧めします。因みに大昔のパッケージの samba では M$ ドメインへのジョインに問題があり、オプションを変えてコンパイルしていた記憶があります。他にも、radius の認証に ldap を加えたりなど、ポーツを使う場面は多々あると思います。
最後に、ポーツとパッケージで同じタイミングでメンテナンスした結果を比較してみたいと思います。まずポーツでインストール後、pkg autoremove で不要なアプリケーションを削除しました。
pkg version を両方のサーバで実行し、そのファイルを比較すると、こんな感じになります。
一部 X11 関係のライブラリがあったりなかったりアプリケーションの名前が変わったりと、微妙な違いがあるようです。もしかすると、ポーツの方は DOCS オプションを外して、全てコンパイルしなおしたのでそれが響いた可能性はあります。が、名前こそ変われ、インストールしたアプリケーションは同じバージョンかつ最新バージョンにアップデートできましたので、目的はいずれの方法でも達成できると思います。
名古屋から大阪へ移動してその帰りは久しぶりに大阪市内を散歩して帰ることができました。見慣れた景色なのですが、なんだか変わったような変わってないような景色にウキウキしながらケータイカメラでバシャバシャ写真を撮りながら散歩していました。ここの景色こんなにきれいだったかなぁ。。。
以下広告
コメント