Monthly Archives: 10月 2013

FreeBSD 10.0-BETA2にfreebsd-upgradeしたらpkgngが吹き飛んだ件について

Pocket

 

FreeBSD 10.0は、ALPHAからBETA1まで怒涛のアップデートが続いたと思ったら、BETA2でいきなり足踏みがあった。
これは、freebsd-update(8)にバグがあったためで、結果として以下の問題があったようだ。

①freebsd-updateでFreeBSD 10.0-BETA1へのアップグレードができない
②FreeBSD 10.0-BETA1でfreebsd-updateを使えない。

それが2013/10/29(日本時間)に解決された。
各OSバージョンでいったんfreebsd-updateし、最新の状態にしてから10.0-BETA2に更新すればよい。
詳細は以下。
Multiple freebsd-update bugs break upgrading to FreeBSD 10.0

油断してるとpkgngが死ぬ

もう一つ。
今回のfreebsd-updateでは、freebsd-update installを3回求められた。
あまり記憶がないのだが、前からこうだったかな..。

ただこの3回目のinstallが曲者である。
メッセージ(後述)を見ると分かるが、古いライブラリを削除するもののようだ(make delete-old-libsのようなもの)。
したがって、ports, pkgでインストールしたソフトウェアは動かなくなる可能性がある。
恐ろしいのは、pkgコマンド(pkgng)も対象であるということだ。

告白すると、「面倒くせえ。そんなもん、後でゆっくりアップグレードするわい」と進めたら、pkgが死んでその他のソフトウェアもアップグレードできなくなって頭を抱えました。はい。

さて以下に正しい手順を示す。

アップグレード例(FreeBSD 10.0-BETA1からBETA2へ)

ではまず現状の確認。
upgradeすると失敗する。
情報通りですな。

そこでupgradeではなく、いったんupdateするとfreebsd-updateが更新される。

フレッシュなfreebsd-updateで改めてアップグレード。
今度は問題なし。

あとは指定されるままにinstall, reboot,もう一回installをすると以下のメッセージが。

ここで迂闊に3回目のfreebsd-updateをすると、先述の通り面倒なことになる。
pkgコマンドですべてのソフトウェアを強制再インストールする。
man pkg-installしてもそれっぽいのが無かったので、以下のようにした。

freebsd-update installをもう一回して終了。

freebsd-updateの修正

以上、なのだが。
今回のfreebsd-updateバグ回避方法にはもうひとつ、freebsd-updateそのものを更新する方法がある。
その方法も試したので以下に示す。
(正直に言うと、ERRATAの「Perform one of the following:」を読み飛ばし、freebsd-updateにパッチ当てるという余計な手間をかけた。悔しいので手順を示す)

とはいえ、freebsd-updateの修正とOSアップデート手順は先述URLに丁寧に書かれている。
英語ではあるけれども、鍛えられたFreeBSDソルジャーなら屁でもない。
が、どこかに有用と感じてくれる人がいるかもしれない。
以下は10.0-BETA1から10.0-BETA2にアップグレードした例。

必要なものはsrc。
gpgもあるといいけど、まあ要らない。

srcの展開

srcのある人はスキップしてよい。
bsdconfigやら、DVDイメージ、DVDから展開する。
以下はDVDから展開する例(実際は仮想マシンからディスクイメージ読んでるだけなんですけどね)。

 

gnupgのインストール

これも、まあ本気のサーバ管理をしている人以外は不要じゃないかな。
以下はpkgでインストールする例。
意外にたくさんのお友達を連れてきた。

 

パッチの入手と適用

gnupgのない人は拡張子.ascのダウンロードは不要。

gpgでファイルの確認。
gpgが無ければスキップしてよい。

なんかWARNINGでてるけどまあいいでしょ。

パッチ適用

 

freebsd-updateのコンパイルとインストール

10.0-BETA1のみ以下を実行

freebsd-updateの修正は以上で完了。
改めてfreebsd-updateを実行すればよい。

以上

No tags for this post.

お手軽ミラーユーティリティcpdup

Pocket

rsyncの悩み

ディレクトリの同期とくればrsyncが定番でありオンリーワンと言えよう。

ただこのrsync、久しぶりに使うとコマンド書式を忘れてて苦労するのですよ。
「確かオプションは-avzだったかな」「リモートホストの指定方法はなんだっけ・・・」とmanとしばらく格闘するわけですな。

ディレクトリ指定の複雑さ

加えてディレクトリの指定の仕方も理解しにくい。

例えば、二つのディレクトリを同期させたいとき。
rsync -avz dirA dirBを実行すると、こんなことが起こる(確かこうだった…。スラッシュがあるかないかで違ったかも)。

  • dirBがないとき
    →dirBが作られる。
  • すでにdirBがあるとき
    →dirB/dirAが作られる。

前者をイメージしていたのに、後者のパターンにゲンナリすることがよくある。
そこで使えるのがcpdupである。

お手軽ミラーユーティリティcpdup

cpdupはファイルシステムのミラーを作るユーティリティである。
「ファイルシステムの」と書いたのは、ハードリンク、ソフトリンク、デバイス、パーミッションなども面倒見てくれるからである。

リモートホストと同期させる場合のプロトコルにはsshが使われる。
また、リモートホストにもインストールが必要。

rsyncの代替にはならないけれども、手軽で、わかりやすいインタフェースを持つ。

manはこちら。
http://linux.die.net/man/1/cpdup

cpdupのインストール

FreeBSDだと、portsならsysutils/cpdup。pkgでもOK。
Linuxでもパッケージから手に入るでしょう。
リモートと同期させる場合には、リモートホストにもcpdup入れておくこと。

cpdup書式

書式は以下の通り。
オプションは一部。全部見たいならmanでどうぞ。

通常的に使うオプションは、「-C -vv -d -I]でよいと思う。


cpdup実行例

まず手元にファイルを含むディレクトリを作る。
下記の例ではtestDirディレクトリに、a, b, c, d, e, fというファイルを作った。

典型例

ではこれをcpdupしてみよう。
リモートの192.168.154.241にコピーする。
基本の「-C -vv -d -I」で。
出力がとても分かりやすい。

 

ターゲットにすでにディレクトリがあってもOK.

そこでもう一度同じコマンドを実行してみる。
何もコピーされない。
これがもしrsyncだと、testDir/testDirが作られることになる。

 

ターゲットのファイルを削除するときは確認あり。

では手元の./testDir/aを削除してもう一度。
ターゲットのtestDir/aを削除するか、聞いてくれる。

 

-i0で削除時の確認を抑制

今度は手元の./testDir/bを削除し、-i0を付けてみる。
確認なくターゲットのbを削除している。

 

-oでターゲットの削除を抑制

さらに手元の./testDir/cを削除し、-oを付けてみる。
ターゲットのcの削除はされない。

 

メッセージの抑制

メッセージ表示のオプションをすべて外してみる。
出力がかなり減った。

さらに-qを付けてみる。
出力が一切ない。

 

たいへん結構。ではスピードは?

rsyncとどれくらい違うか、実験してみた。

FreeBSD 9.2-RELEASEのソースをミラーリングしてみた。
5696のディレクトリに52315のファイルがあり、サイズは800MBである。

ハードウェアのスペックは割愛。
Windows上のVMがソース、古いDELLマシンがターゲットなので…。

rsyncには-avzを、cpdupには-C -vv -d -Iを与えた。

結果。

rsyncは6分。

cpdupは30分。
…30分!?

ま、まあ、スピードの点では、cpdupはまったく話にならないですな…。
(転送量を見るとcpdupの方はspeedupがあまり効いてないように見えるなあ。)

ミラーリングとは言っても、初回のフルコピーだから、差分コピーだとまた違った結果が得られるかもしれない。
ただちょっとここまで差があると試す気にもなりまへん。

まとめ

cpdupはちょっとしたミラーリングの時に使うには、手軽で書式もわかりやすいので有用、いっぽう、気合い入れてやるミラーリングはrsyncで、って事でいいんじゃないでしょうかね。

No tags for this post.

らくらく構築、CalDAVサーバBaikal

Pocket

カレンダーサーバのBaikalを試してみたので記す。

ここでのカレンダーサーバとは、Googleカレンダーのようなものですな。
「だったらそんなのGoogleカレンダーでいいじゃないか」というのは仰るとおりだが、そもそも環境の都合上、Googleカレンダーへの接続ができないとか、PRISM以降、オンラインサービスを信用ならない向きには有用なサービスであります。

カレンダーサーバの選択

とはいえ、カレンダーサーバ(以降、CalDAVサーバ)を選ぶにも、かなりの数が作られている。
Wikipedia(英語版)で調べてみると、各種CalDAVサーバが一覧にされた比較表が出てくる。
これを参考に選んでみよう。

http://en.wikipedia.org/wiki/Comparison_of_CalDAV_and_CardDAV_implementations

いろいろ眺めてみて、かつ、少しかじってみて、Baikalを選んだ。
いずれのCalDavサーバも機能は一長一短なので、構築がとっても楽だったBaikalに決めた。

Baikalとは。

SabreDAVをベースにしたCalDAV, CardDAVサーバである。
オフィシャルサイトはこちら
しかしこのサイトにはドキュメントがまったくないので、GitHubのこちらを勧める。
RequirementはPHP5.3以降にSQLite3、php-pdo。データベースにはMySQLも利用できる。
WebDAVサーバも必要だが、apache, nginx, lighttpd等、どれでもいいでしょう。
さっそくインストールしてみる。

Baikalのインストール

これはなんでもない。
FreeBSDならpkgngにあるのでそれで。portsならwww/baikal 。
依存も少なめで非常にいい。

インストールが終わると以下のメッセージが表示される。

上記メッセージに沿って進める。

 

httpサーバの設定

FreeBSDだと/usr/local/www/baikalにインストールされる。
それぞれのhttpサーバでbaikalのインストールされたディレクトリを公開する。
ただし公開するのはbaikalのhtmlディレクトリ。
/usr/local/www/baikal/html/である。

私の場合、/usr/local/www/dataがhttpサーバのドキュメントRootだった。
webサーバでaliasの設定をすべきだが、面倒なので横着してsymlink張った。

 

Baikalのセットアップ

インストール時メッセージに沿う。
SpecificフォルダにENABLE_INSTALLというファイルを作る。

その後、ブラウザで接続。
http://<baikalサーバ>/baikal/admin へ。
うまくすれば以下の画面になるはず。

baikal01

データベースセットアップ。
SQLiteならそのまま進む。
baikal02
baikal03

一通りの設定が終わったのでダッシュボードへ。
baikal04

終わったらSpecific/ENABLE_INSTALLを削除すること。

ユーザ、カレンダの追加

上記からの流れでdashboardに移動しているはず。
メニューバーのユーザ管理をクリックしていけばユーザ、カレンダー追加ができる。

baikal05

baikal06
ここでのパスワードは、あとあとカレンダーへアクセスするときに必要になるもの。

ユーザを作ったら、カレンダーをクリック。

baikal07

カレンダーが出来ていますね。
baikal08

 

カレンダーへのアクセス

CalDAVに対応しているならなんでもいい。
ここのClient Implementationsにズラリと並んでいるどれでもOK.
iOS, Androidだって、よりどりみどり。

ここでは、ThunderbirdのLightningからアクセスする例を示す。

lightning

CalDAVを選び、アドレスに以下を入れる。

たとえば、http://192.168.154.241/baikal/cal.php/calendars/doe/default

以上。

No tags for this post.

nginxとlighttpdで悩んでlighttpd + php5 + fastcgiのインストールと設定へ

Pocket

apacheは吊るしのFreeBSD pkgでphpを使えない。

10.0-BETA1にして曲がりなりにもpkgが普通に使えるようになって、あまりの便利さに感動し、追加ソフトウェアはすべてpkgにしようと決めたのだが。

apacheとphpでいきなり壁に当たりました。
apacheをpkgでインストールすると、phpのモジュールが付いてこないのである。
phpモジュールが欲しいなら、apacheをportsからインストールしないといけない。

もちろん、pkgngはportsと一緒に使えるよう考えて作られている。
apacheだけportsからインストールしたって何の問題もない。
ただ、あの巨大な/usr/portsディレクトリをメンテしていくのが億劫なわけですよ。

ならばよろしいapacheはもう捨てよう。
たぶんまた、吊るしのpkgで使えないソフトウェアが出てくると思うが、その時はその時考えよう。

nginx, lighttpdのどちらがよいか。

apacheの代替といってすぐに思い浮かぶのはnginxとlighttpdである。

“nginx lighttpd comparison”などとググってみると、いくつかのもまとめがヒットする。

http://www.wikivs.com/wiki/Lighttpd_vs_nginx
http://wiki.dreamhost.com/Web_Server_Performance_Comparison

軽く速く柔軟な設定が可能という点では同じだが、概観したところnginx優勢のようである。

また、lighttpdには品質面で気になる点もある。
どうも長い間放置されているメモリリークがあるようだ。

ただlighttpdの設定のほうが分かりやすい、というのは皆の認めるところらしい。
メモリリークは心配だが、さっさとhttpサーバを設定したいのでlighttpdを選択。

以下、lighttpdでphpを、fastcgiで動かす。
環境はFreeBSD 10.0-BETA1。pkgngでインストール。
設定方法は他OSでも参考になる部分があるかも。

lighttpd, php5のインストール

pkgでインストール。
簡単。
lighttpdは依存も少ない。

 

php5のバージョン確認

lighttpdを扱う前に、phpを確認する。
fastcgi対応かどうか。

“php5″でインストールされたのは5.4.20
/usr/local/bin/php-cgiを確認すると、特に指定や追加のインストールの必要なくfastcgi対応であることが分かる。

 

lighttpdのファイル配置

lighttpdとしてインストールされたファイルを確認する。

設定ファイル
/usr/local/etc/lighttpd下に。

ドキュメントルート
初期状態では/usr/local/www/dataだが、ディレクトリは自分で作る必要がある。

lighttpdのログファイル
初期状態では/var/log/lighttpd下に。

ファイルを確認したら、lighttpdの設定に移る。

lighttpdの設定

流れとしては、

  1. lighttpd.confで全体の設定を、
  2. modules.confで読み込むモジュールの設定を、
  3. conf.d/下の*.confで各モジュールの設定を行う。

fastcgiを使うなら、
lighttpd.confで設定ののち、
modules.confでfastcgiのモジュールを読み込む指定をし、
conf.d/fastcgi.confでphpの指定をする、となる。

なお、php.iniにも一部変更が必要。

lighttpdオフィシャルのチュートリアルはここ
以下、/usr/local/etc/lighttpd下にある設定ファイルに手を加えていく。

lighttpd.confの修正

lighttpd.conf.sampleから変えたのは以下の3行だけ。

コメント行、空行を除いたlighttpd.confは以下の通り。
include “modules.conf”と指定がある通り、ここでmoduleを読み込んでいる。

 

modules.conf

lighttpd.confで指定されたmodules.confの設定。
どんなmoduleを読み込むか。
以下の行を有効にしただけ。
つまりfastcgiを有効に。
そのほかにも興味深そうなmoduleはあるがミニマルスタートが原則。

コメント行、空行を除いたlighttpd.confは以下の通り。

 

conf.d/fastcgi.conf

fastcgiの設定。
phpをどう実行するかを指定できる。

ローカルのphp-cgiでもよいし、ローカルホストの別webサーバ(apacheとか)でもよいし、はたまた別ホストのwebサーバでもよい。
詳細はこちら

ここでは、ローカルの/usr/local/bin/php-cgiを使う。
fastcgi対応のphpである。

ローカルなのでIPアドレスやTCP/IPポートの指定は不要で、UNIXドメインソケットして使うファイルを指定すればよい。
最終的に以下の行を追加

コメント行、空行を除いたlighttpd.confは以下の通り。

以上でlighttpdの設定は完了

php.iniの設定

lighttpdのドキュメントを見ると以下のように書いてあるので、php.iniを修正する。

If you want to use PATH_INFO and PHP_SELF in you PHP scripts you have to configure php and lighttpd. The php.ini needs the option:
cgi.fix_pathinfo = 1

FreeBSDだとphp.iniは/usr/local/etcに置かれるべきもの。
初期状態ではphp.iniが無いので、sampleからコピーする。
sampleにはphp.ini-developmentとphp.ini-productionの二つがある。
developmentの方を選んだ。

以下の行のコメントを外す。

 

起動確認

/usr/local/www/dataを作り、”It works!”とでも書いたindex.htmlを作る。

FreeBSDなら/etc/rc.confに以下の行を追加。

 

起動。

 

ログに異常もなし。

 

ブラウザでつないで、index.htmlが表示されればOK。

No tags for this post.

[FreeBSD] pkg -j でjailの「外から」pkgng操作を。

Pocket

サマリ

pkg -jを使うと、ホストからjail内のpkgを操作できる。
しかし、あらかじめjail内にpkgのインストールが必要。

pkg -j

pkgのmanを見ると以下の記載が。

つまり、-jに続けてjail名あるいはjail idを指定すれば、ホストから当該jail内のpkgを操作できる、ということである。
これはさっそく試さねばなるまい。
qjailを使ってexmaple02というjailを作った。

 

さっそく試してみるが…?

まったく反応がない。

いろいろ試した結果、jailにはpkgがあらかじめインストールされていなければならないのであった。

jailでpkgのインストール

仕方なくjailのコンソールに接続し、pkgをインストール。
現時点ではpkgの公式リポジトリがないので、こちらの通りに進める。

もう一度ホストからpkgを実行。
今度は問題なく進んだ。

 

jailの外からpkg -jでpkg操作

ではjailの外からインストールを。

-jオプションを付けるだけで、まったく同じように使える。
infoで一覧も得られるし、auditでセキュリティチェックもできる。upgradeもできそうだ。

こいつは便利でございますな。

 

 

 

 

 

 

 

No tags for this post.

10.0-BETA1でezjailが息してない→qjailに乗り換えた。

Pocket

 

せっかく覚えたezjailが息してない

jailの設定ファイルが、rc.conf,/etc/rc.d/jailからjail.confに変わる。

https://twitter.com/m_bird/status/386369822751076352

そのせいか10.0-BETA1にしたら、ezjail使うたび怒られるようになった。
具体的にはezjail-adminでjailをうまく起動できない。
ezjail覚えたばっかなのに…。

「手動でなんとかしろよ」とエラーメッセージが出るのだが、jailの仕組みはとても複雑で、jail.confの書式も良くわからないしsampleもない。
「rc.d, rc.confをそのままコピー&ペーストしたらいいんだよ」とは言うのだけど、そもそもrc.d, rc.confを自分で書くのが嫌でezjail使ってたのに。

しょうがないんで、あんまり深く追いかけずに別のラッパーであるqjailを試した。

なかなか独特のテイストが感じられるのだが、思ったより手軽で、ドキュメントも(時にはウンザリするくらい)充実している。
もちろんjail.confにも安心対応。

数十個ものjailを作ることも出来たり、一度作成したjailをテンプレートにする機能もあったりして驚く。

ググった感触でいうとあんまり人気ないみたいだけど、結構いい。
細けえ事はどうでもいいからjailを使わせろという諸兄にはおすすめである。

qjailのインストール

2013/10/18時点で2.2と3.2がある。
jail.confに対応しているのは3.2。

話は前後するが、qjail3.2のman qjail(8)から抜粋すると;

This version of qjail has been converted from using the legacy rc.d
rc.conf method of jail definition as used in all pervious versions of
qjail, to using the jail(8) jail.conf method which became available in
9.1-RELEASE.

よって3.2をインストール。
なお、以下でqjailをインストールするFreeBSDは10.0-BETA1でございますので、pkgngを使います。

 

qjailでの初期設定

まずはjailのひな形、ベース環境を作る。
qjail installでよい。
ひな形取得先のftpサーバを変更するならオプションで指定する。
書式は以下。

 

RELEASE以外でのqjail install

しかし、ftpサーバからダウンロードできるのはRELEASEのみ。
BETA, RC, ALPHA, STABLE等々だとダメ。
回避方法は二つ。

①なんでもいいのでRELEASEで作っておいてアップグレードする
②ダウンロードしたディスクイメージを使う。

今回は②にした。
①はman qjail参照。
②をもう少し細かく書くと、ディスクイメージをマウントし、base.txzなどのある「ディレクトリ」をqjail install -fに続けて指定する。

「ディレクトリ」とわざわざ書いたのは、cdで行けるところ、というのを強調したかったから。
ディスクイメージの直接指定はできないし、ftpサーバのディレクトリ指定もダメ。
ガッカリ。

(追記)RELEASE以外でのqjail install

「RELEASE以外」というのは、実はRELEASE-p2といったような、パッチレベルが0以外の場合も該当する。
つまりfreebsd-updateでパッチを当てた状態でqjail installすると失敗する。
これは、qjailは自ホストのOSバージョンをもとにディレクトリを移動するから。
OSバージョンが10.1-RELEASE-p16だったら、ftpサーバの10.1-RELEASE-p16などを見に行ってしまう。
しかし、ftpサーバはパッチレベルごとにはディレクトリが作られないので、参照先がなく失敗する。

ところで、ここでのOSバージョンとは、具体的には環境変数UNAME_rである。
ということは、qjail installのときだけUNAME_rを変更すればパッチレベルが変わっていようがよいのである。
以下、10.1-RELEASE-p16で実行した例。

追記ここまで

ダウンロードしたディスクイメージからqjail install

仕方がないので淡々と進める。
10.0-BETA1のイメージダウンロードして、ローカルでマウント。

/mntにマウントしたとすると、/mnt/usr/freebsd-dist/が目的の場所。

qjail install -fで実行。
終わったらマウントも外そう。

 

qjailの構成

/usr/jailsにいくつかのディレクトリが生まれる。
また、設定ファイルが/usr/local/etc/に格納される。

/usr/jails下は以下の通り。

sharedfs:
OSの実行ファイル、ライブラリ。全Jailで共有される。

template:
OS configuration fileがある。設定変えようと思ったらここかな。

archive:
初期状態では空。
qjail archiveコマンドで作成されるアーカイブが格納される。

flavors:
flavorですな。defaultとssh-defaultの二つがある。

そのほか、/usr/local/etc/下に以下のようなファイル、ディレクトリがたくさん出来る。
jailを作ると今度はこのディレクトリの下にjail名でファイルができる。
global, local, vnetの意味が、想像はできるもののよく分からない。

 

jailの作成

書式。代表的なもののみ。

-fと-aは一緒に使えない。

実際に作ってみる。
あっさりと出来上がる。
あっさりしすぎて逆に不安なくらい。

気がつくと、/etc/jail.confが生まれている!

jail起動…の前に、qjail listで確認。

qjail list

作成済みのjailはqjail listで確認できる。

最初のカラムのSTAはStatusの略。

JIDはjail IDのこと。そのほかは見たまま。

qjail start

qjail startでjailを起動。
qjail listの表示も変わり、ネットワークインタフェースへのaliasも実行してくれている。

 

qjail consoleでjailの中へ

qjail consoleでコンソールにアクセスできる。

特に何もしていないけど、/etc/localtimeと/etc/resolv.confは作ってくれた。wall_cmos_clockはなかった。

 

qjail stopで止めて、archiveでアーカイブ、deleteで削除完了

単純にstopしてdeleteするのは面白くないから、deleteの前にarchiveしてみた。
/usr/jails/archiveの下に<jail名>@日付秒.tarというファイルが出来ている。
また、deleteしてもjail.confには記載が残っているようだ。

 

qjail restoreでarchive済みのjailを復活可能ッ!

ためしにrestoreしてみたら何事もなかったかのように復活して驚いた。
これはスナップショット的に使えますね。

 

qjail、便利だよね?

ご覧の通り、qjailはjailをマクロなレベルで扱うことに長けているようで、とても便利に感じる。
qjailにはほかにもqjail configというコマンドがあり、既存のjailの設定(たとえばIPアドレスとか)を変えたりできるし、jailのOSアップデートも手軽にできるようだ。
そのあたりはまた試すとして、しばらくjailはqjailでメンテしようと思った。

 

No tags for this post.

[FreeBSD][メモ] svnliteってなんだ?

Pocket

FreeBSD 10.0でsvnliteというのが生まれた。
これが何なのか、調べたので。

svnliteってなに?

端的に言って、cvsup, csupの代わり。
以前、FreeBSDのsrcアップデートにはcsupを使っていたけれども、FreeBSDの公式リポジトリがCVSからSubversionに移行したのでそれに伴う処置。

だからして、FreeBSDソースコードのチェックアウトに使われるもの。あるいはコミットにも。
そんなわけで、通常のsvnと違い後述のような性質を持ち、プラグインを多用する場合のsvn用途には使わない方がよい。

svnliteの特徴

  • ライブラリはすべてスタティックでリンクされる。
  • インストール直後からすぐに使えるし、単体で動く。しかし機能制限はあって:
  • python/perl等のプラグインやAPIのサポートがない。つまり:
  • python/perlに依存しないのでコンパイルはすぐに終わるし,
  • python, perlのバージョンアップに影響を受けない。
  • 注: subversionの依存は凄まじく、普通にインストールすると沢山のお友達を連れてくる都合上、/usr/local配下で238Mバイト消費。
  • デフォルトでは”svnlite”としてインストールされる。”svn”ではない。だから:
  • subversionを別にインストールしても安心。
  • make.confでWITH_SVNとすると、svnとしてインストールされる。
  • make.confでWITHOUT_SVNLITEとすると、svnliteは無効に。

詳細は以下。
http://svnweb.freebsd.org/base?view=revision&revision=251886
あるいは下記から始まる熱い議論。
http://lists.freebsd.org/pipermail/svn-src-all/2013-June/070250.html

FreeBSD 10.0-BETA1では1.8.1相当。

 

似たものにsvnupがあるが、2013年6月の時点で問題がありベースシステムへのマージは見送り。(問題にはコアダンプも含まれる…)

No tags for this post.

[FreeBSD]freebsd-updateするならfreebsd-versionを使おう

Pocket

 

freebsd-version(1)

10.0-BETA1で、freebsd-versionというFreeBSDのパッチレベルを教えてくれるコマンドが生まれた。
便利なコマンドなのでメモ。

FreeBSDには、freebsd-updateというバイナリアップデートコマンドがある。
make buildworld, buildkernelしなくても、必要なファイルだけを更新してくれる優れもののコマンド。
セキュリティ更新があった場合や、アップグレードにとても便利なのだが、困ったことが一つ。

あるセキュリティ更新が、カーネルに影響せず、ユーザランドのファイルのみ対象だった場合。
仮にここで9.2-RELEASEのユーザランド、たとえばbindにのみ更新があり9.2-RELEASE-p1になったとする。

そのFreeBSDのパッチレベルを確認しようとunameコマンドを使っても、返ってくるのは9.2-RELEASEである。
つまりunameはカーネルしか見ていない。
これでは本当にfreebsd-updateが完了したか不安になる。

カーネルを再コンパイルすればきちんと9.2-RELEASE-p1と返してくれるようになるが、これでは何のためのfreebsd-updateなのか分からなくなる。

今回のfreebsd-versionは、このfreebsd-updateの困ったことを解決してくれるコマンドである。

使い方

freebsd-updateは10.0-BETA1で入ったもの。
/binの下にある。
ご覧の通りシェルスクリプトである。

freebsd-versionに-kオプションを与えると、カーネルのパッチレベルを返す。
uname -rと同じように見えるが、以下の点で違う。
freebsd-updateなどでパッチを適用し、リブートして「いない」状態であっても、新しいカーネルのパッチレベルを返してくれる。
リブートするまえに確認できるから便利ですな。

オプションなし、あるいは-uオプションを付けると、ユーザランドのパッチレベルを返してくれる。

-kuとつけると、最初にカーネルのバージョン、次にユーザランドのバージョンを返してくれる。

以下が実行例だが、ユーザランドに更新のない10.0-BETA1だけに違いが分からない…。

 

詳細はman freebsd-version。
環境変数ROOTでpathを与えると、freebsd-versionはそこを基準にしてカーネルやユーザランドのパッチレベルを教えてくれる例など載っているので。

 

uname -U, uname -K

と、この記事をまとめた後(この記事は予約投稿なのです)に、HEADに修正が入った
unameに新しいオプションが追加される。-Uと-K。

-Uがユーザランドの、-Kがカーネルのバージョンを返す。
HEADだから11.0に入るのかな。
しかしそうなるとfreebsd-versionの立場は…。と思ったけど、コミット理由に「important for jail/chroot environments」と書いてありますな。

 

 

 

No tags for this post.

FreeBSD 10.0-BETA1でportsやミラーサイトに頼らずpkgngを使うには(2013/10/15現在)

Pocket

 

FreeBSD 10.0もBETA1がリリースされた。
ウホッとばかり突撃して、pkg_*の無いのに仰け反り、それなのにpkgではインストールのしようが無い現状に絶望した日本のFreeBSDユーザの方(絶対に少ねえ)に捧げます。

改めて背景を。
10.0からは、従来のパッケージ管理システムであるpkg_*に代わり、pkgngが登場する。
しかし。
2013/10/15現在、いまだ公式のpkgng向けPACKAGESITEが用意されていないのである。
なぜ、というのはここでも触れたとおり。
となれば、現時点ではportsからしか各種ソフトウェアをインストール出来ない。
うわ面倒くせえ。

PACKAGESITEは、さすがに10.0-RELEASEのときまでには準備がなされるはずであるが、現時点で外部のミラーサイトを参照せずにpkgngを使う方法を示す。

(追記:2013/11/7)
公式のpkgngが公開されている。詳しくは以下を。
http://april.fool.jp/blogs/?p=2357
(追記ここまで)

その名もpkg-test.freebsd.org。しかし。

実は、ゆくゆくオフィシャルなPACKAGESITEになる予定のサーバはもうある。
それがpkg-test.freebsd.orgである。

じゃ、これをPACKAGESITEに指定すればいいじゃないか。
しかしですね、ブラウザでpkg-test.freebsd.orgに繋ごうとすると分かるが、No address recordとなるわけですよ。

というのも、pkg-test.freebsd.orgはDNS上、AレコードではなくSRVレコードだそうであり、かつRFCに沿ってないからだという、もうほんといい加減にせえよ…。
詳細は下記を。
Where is pkg repository for 9.2-RELEASE (amd64)?

よろしい。ではIPアドレス直打ちでどうだということで、まっさらのFreeBSD 10.0-BETA1でpkgngを使う方法を示す。

さいしょの一歩(pkgコマンドのインストール)

何はともあれ、まずはpkgコマンドそのものをインストールしなければならない。
pkgと叩けばいいのだが、さっそくこれですよ。

そこで、環境変数PACKAGESITEに以下のアドレスを与えてpkgコマンドを実行。
下記の例ではhttp://96.47.72.120/pkg-test-freebsd:10:x86:64/latestである。
96.47.72.120はpkg-test.freebsd.orgのIPアドレス
i386だったら、http://96.47.72.120/pkg-test-freebsd:10:x86:32/latestにしてね。

もちろん、pkg-test.freebsd.orgが参照しているpkg1.nyi.freebsd.orgでもOK。

これでpkgコマンドがインストールされた。
つぎはpkgコマンドの設定。

pkgの設定

/usr/local/etc/pkg.confというファイルが出来ているはず。
ここのPACKAGESITEを確認。
ちなみに書式はYAML。
以下のようになっているはず。

今後のことを考えて、以下のように書き換えておきましょう。

オフィシャルのPACKAGESITE(きっとpkg.freebsd.orgになるはず)が準備出来たら、ここはすぐに書き換えること。

なお、/etc/make.confへのWITH_PKGNG= yesは要りません。
必要なのはFreeBSD 10.0より前のバージョン。
FreeBSD HandBookより

To ensure that the FreeBSD Ports Collection registers new software with pkgng, and not the traditional packages format, FreeBSD versions earlier than 10.X require this line in /etc/make.conf

そうしたらpkg updateしておしまい。

pkg updateとpkgのインストール

2013/10/15の時点で約21000のパッケージがあるようですな。
念のためpkg upgrade。

まあ何もないよね。

試しにいくつかパッケージをインストールしてみましょう。

パッケージも新しく、pkg auditで確認しても脆弱性の報告はない。

というわけで、いろいろ問題はあるけれど、pkg-test.freebsd.orgは現時点で十分使えるということでございます。

 

 

 

 

No tags for this post.

FreeBSD 10インストーラからのzfs on rootを試してみたよー

Pocket

 

FreeBSD 10.0-RELEASEから、インストールの際にファイルシステムとしてZFSが選べるようになる。
システムの置かれるファイルシステムをZFSにする、ということは、今までも出来ないことはなかったけど、そりゃもう面倒な手順を経る必要があった。
それがインストールの時の選択ひとつで出来るようになったというのは、けっこうすごいこと。

また、システムをZFSに置けると、まずパーティションの切り方に悩まなくて済む。
あとで/varが足らないとか/usr/localがとかそういったことが無くなる。

そのうえで、システムまるごとzfsのアドバンテージを満喫できる。
まるまるスナップショット取れたりするからね。

ただ、2012/10/10現在、いまだテスト中のところであり、10.0-BETA1あたりに入るかも、という状態。(2013/10/15追記; 10.0-BETA1に入ってました)
そんな状態で試してみた顛末を記す。

なお一次情報は以下の通り。

 

インストーラでのzfs on rootを試す

前提:FreeBSD 10.0-ALPHA5, zfsbootonly.2013-10-09.isoをvirtualboxで試しています。
注意: 先述の通りテストの真っ最中なので、下記の内容が変わる可能性は十分にあります。

Allan Jude氏のページからインストーラをダウンロードする。
通常通り起動し、10.0になっても相変わらず愛想のかけらもないメニューを選択して進むと、以下の通りフォーマットのところでZFSが選べる。

 

menu001

ZFSを選ぶとこのように。

menu002

使うディスクを選び、進む。

menu003

あとは通常通り。

 

unameはこの通り。

 

カーネルモジュールがこのように組み込まれている。

 

 

ディスクの内容はこのように。

 

No tags for this post.