前提

この文書は、OS X LionとOS X Lion serverという環境を前提としています。

前置き

OS X Lion をKerberos認証を使ってXgridに参加させるには、以下の条件が揃っている必要があります。

なお、この文書ではOpen Directory MasterとXgridコントローラの設定方法は説明していません。この2つはすでに適切に行われているとします。つまり上述のa、bは完了しているという事です。

要約

この文書は、Open Directory MasterでありXgrid コントローラであるOS X Lion Serverで動いているvforce107があり、ここにスタンドアローンのseed-mbp01というOS X Lion端末をvforce107のXgridに参加させようという話です。以下の作業手順はすべてseed-mbp01で行います。作業はローカル管理者アカウントで実施しています。

認証バインドをする

システム環境設定「ユーザとグループ」の「ログインオプション」を開きます。

ネットワークアカウントサーバの「接続」ボタンをクリックします。ポップアップメニューからサーバを選択して、OKボタンを押し、インストラクションに従って接続を完了します。

正しく接続が行われると、ネットワークアカウントサーバ名が緑色のマークとともに表示されます。その横の「編集...」ボタンをクリックします。シートの中の「ディレクトリユーティリティを開く...」をクリックして、ディレクトリユーティリティを呼び出します。

LDAPv3を選択して、リストの下の「鉛筆」ボタンをクリックします。
上図のようにシートが開いていない場合は「オプションを表示（上図では「オプションを隠す」になっている）」の横の三角マークをクリックします。そして「編集..」ボタンをクリックします。

「セキュリティ」タブを開き、「接続時に認証を使用」にチェックを入れます。そして下の「バインド...」ボタンをクリックします。

サーバ名またはIPアドレスにOpen Directory MasterサーバのFQDNが正しく入っていることを確認してください。

コンピュータIDは今参加させようとしてるコンピュータの名前です。この名前を使ってコンピュータ認証が行われますので、バインド後にコンピュータ名をシステム環境設定の「共有」で変更しないようにしてください。ディレクトリ管理者のアカウント名とパスワードを入力して「OK」ボタンをクリックします。

識別名とこのコンピュータのパスワードが自動的に設定されます。このパスワードを使ってKerberosチケットをシステムが入手してくれるというわけです。「OK」ボタンをクリックしてから、ディレクトリユーティリティを終了します。

Xgrid設定をする

システム環境設定の「共有」で「Xgrid共有」を設定します。

認証方法として「シングル・サイン・オン」を選択します。

「構成...」ボタンをクリックして、特定のコントローラにXgridコントローラのホスト名を入れます。それからタスクの受け入れを選択します。

「完了」ボタンをクリックして「Xgrid共有」にチェックを入れます。

しばらく（30秒くらい？）待つと、エージェントとしてコントローラに登録されます。

「Mac OS X Server v10.6：OS X Lion または Lion Server 用のソフトウェア・アップデートをホストする」というAppleのKbase記事があります。この文書はそのKbaseの記事を拡張するものです。

このAppleのKbase記事は、クライアントととしてOS X Lionが増えていて、しかしながら何らかの事情でMac OS X Server 10.6でソフトウェアアップデートサービスを提供する場合に大変参考になります。しかしOS X Lion用のソフトウェアを利用したいときに、このAppleのKbase記事のとおりに変更しただけでは上手く行かない場合があります。

OS X Lion Serverにアップグレードするとき失敗する

Mac OS X Server 10.6をOS X Lion Serverにアップグレードするとき、アップグレードを今まさにしようとしているサーバが、Mac OS X Server 10.6でホストされているソフトウェアアップデートサーバを向いているとき、アップグレードに必要なServer Essentialをソフトウェアアップデートサーバからダウンロードできないため、アップグレード処理がキャンセルされます。先のKbaseに従ってOS X Lion向けのアップデータを提供するようにしているにもかかわらず、です。

これは実に単純な理由でおきています。アップグレード前のサーバは当然まだ10.6ですから、ソフトウェアアップデートサーバからMac OS X 10.6または10.5向けのものしかダウンロード出来ないのです。そのためOS X Lion Server用のServer Essentialを見つける事はできません。

AppleのKbase記事の解説

記事の中のステップ5でファイル「/etc/swupd/swupd.conf」を編集しています。ここで編集しているのはmod_rewriteのルールの変更です。編集後のmod_rewriteディレクティブ全体を以下に引用します。

<IfModule mod_rewrite.c>
　RewriteEngine On
　RewriteCond %{HTTP_USER_AGENT} Darwin/9
　RewriteRule ^/index\.sucatalog$ /index-leopard.merged-1.sucatalog
　RewriteCond %{HTTP_USER_AGENT} Darwin/10
　RewriteRule ^/index\.sucatalog$ /index-leopard-snowleopard.merged-1.sucatalog
　RewriteCond %{HTTP_USER_AGENT} Darwin/11
　RewriteRule ^/index\.sucatalog$ /index-lion-snowleopard-leopard.merged-1.sucatalog
</IfModule>

mod_rewriteはルールを上から順番に適用していきますが、まずRewriteCondの行で該当する部分があるところまでスキップします。Darwin/10がMac OS X 10.6、Darwin/11がOS X Lionです。このソフトウェアアップデートサーバにアクセスしてきたとき、HTTP_USER_AGENTの中に、Darwin/10が含まれていたとき、リクエストファイル /index.sucatalog を /index-leopard-snowleopard.merged-1.sucatalog に書き換えてアクセスさせます。このファイルにはファイル名の通り、Mac OS X 10.5とMac OS X 10.6のものしか含まれていません。その次のRewriteCondは該当しませんが、最後の行のRewriteRuleでは、評価対象が、/index.sucatalogではもはやありませんので、無視されます。結果としてHTTP_USER_AGENTがDarwin/10の場合、OS X Lion用のソフトウェアのカタログが記載された index-lion-snowleopard-leopard.merged-1.sucatalog を得る事はありません。これがOS X Lion Serverへのアップグレードに失敗する理由です。

Darwin/10、Mac OS X 10.6でもLion用のソフトウェアカタログを渡すために、index-lion-snowleopard-leopard.merged-1.sucatalog にしておけばいいわけですが、Mac OS X 10.6で運用している端末にLionのアップデータを含むものを渡してもしょうがないですし、やや乱暴な対応ともおもうので、ちゃんとmod_rewriteを利用した形で対応してみます。

HTTP_USER_AGENTの中にDarwin/10が含まれていたら、という判定なのでもう一つ判定文をいれてみたらどうか。そもそもMac OS X 10.6でOS X Lion インストーラが動いた時だけの問題ですからね。ルールを追加したディレクティブは以下の通りです。追記したところをハイライトしています。

このようにルールを追加したところ、サイトローカルなアップデートサーバを利用してMac OS X Server 10.6からLionへのアップグレードを速やかに行う事ができるようになりました。

余談

OS X Lion Server でソフトウエアアップデートサービスを提供していても、同じ理由でMac OS X Server 10.6からOS X Lionへのアップグレードは失敗します。OS X Lion Serverでソフトウエアアップデートサービスを提供している場合も、mod_rewriteルールを追加して対処することが可能です。

使い方

制限

改訂履歴

1.1

1.2

使い方

$ /path/to/vcard2csv.sh /path/to/vcard.vcf > /path/to/out.csv

BUG

• 行頭に,があるべきではないが、そういう細かいことを気にしてはいけません。
• vCardにURLが含まれている場合、意図しない結果になることに気がついているが、放置している。
• 単純に1コンタクト情報を1行のcsvに変換しているだけなので、カラムの一貫性は最初から考慮していない。

古来よりUNIXシステムには定期的にシステムをメンテナンスする仕組みを備えています。コンピュータは24/7で動いているし、人間よりも決まったことを決まった時間に行うことがとても得意です。管理者が定期的にしなければならないことは、スクリプト化できますから、これをスケジュール化しておけばOKということで、そもそも基本的なことはシステム（OS）に組み込まれています。なので、あんまり人間が手をかける必要は実はなかったりします。物足りなかったり、「俺っちは、こういうことをしてほしいんだよう」という向きは、この仕組みを利用すれば、あとはシステムが忘れずにやってくれます。

しかし、最近24/7で動かないUNIXシステムが巷に溢れましたねぇ。Mac OS Xとか言う奴です。大体人間が寝てる時間に、寝てることが多いようです。その結果、ログファイルがGBを越えていたりするわけです。

定期的なself maintenance

このself maintenaceは伝統的に、毎日午前3時15分。毎週月曜日の午前5時30分。毎月1日の午前3時15分に実行されています。あと、logファイルのローテーションは深夜0時。なぜ、この時間なのかは不勉強なので知りません（誰か教えて）が、要するにシステムの利用が少ないタイミングだろうなとは思います。昔は今日の様に世界中からひっきりなしにアクセスされるなんてことは想定されてなかったはずの時代ですからね。

で、Mac OS Xもこの時間でself maintenance が行われています。が、Mac OS Xをつかっているかたの大多数は、こうした時間、Mac を終了させているか、スリープさせているのではないかと。結果的に、systemのself maintenaceはつかわれないまま。そしてオーナーである人間が、がんばってメンテナンスをしたりする訳です。まぁ、コンピュータいぢりはそれが楽しいというのもありますがね。

とはいえ、せっかくなので、この仕組みをつかいましょう。

時間を変える

self maintenance が実行される時間に、コンピュータが動いていればよいのですが、その時間にコンピュータを起動させておくよりは、ご自身の活動時間にあわせて実行時間を変更させた方がいい。self maintenance が実行されるときに負荷なんて、無視出来るほど今となっては小さい。それよりも確実に使っている時間を指定する。例えば普段、仕事を始めた15分後とか。そんな感じで。

修正するファイルは次の3つ。

毎日のもの、毎月のもの、毎週の物ということ。これらのファイルをProperty List Editor.appなどで編集して、時間を書き換えます。24時制ね。

このファイルは、rootというシステムユーザしか書き換え出来ないので、一旦デスクトップにコピーして、それを編集して、元の物と入れ替えるってことをします。で、さらに、このファイルの所有者とグループ、アクセス権が変わってしまうので、システムがこのファイルを無視する様になります。なので、これを修正するために、

$ sudo chown 0:0 /System/Library/LaunchDaemons/com.apple.periodic-*

ってしておく必要があります。どうしてもコマンドラインはヤダという方は、ディスクユーティリティで、アクセス権の修正を実行してください。直してくれます。

それから、ログファイルの更新のタイミングね。/var/log/system.logと/var/log/wtmpというファイルだけなんだけど。これらは、/etc/newsyslog.confに設定があります。

これも、

/var/log/system.log 640 7 * @T00 J

/var/log/wtmp 644 3 * @01T05 B

を

/var/log/system.log 640 7 * @T12 J

/var/log/wtmp 644 3 * @01T12 B

って、書き換えると、正午にログファイルを更新してくれるようになります。/etc/newsyslog.confは所有者もread-onlyなファイルなんだけど、所詮テキストファイルなんで、適当な方法で書き換えは可能です。共有マシンではなく、個人マシンなのでその辺は深く考えなくていいしね。

で、self maintenance って何してるのか？それは、/etc/periodic の中にいろいろありますが、それはまたの機会に。

defaults write com.apple.iTunes StoreActivationMode -int 1

インストールとフォーマット

フォーマット実行！！てか開始。すぐにはさせてくれない。まずはファイルシステムを選択。ここはもちろん、HFS +。次にサイズを決める。そんなもんMAXでいきます。これって、あれっぽいわ。でもあれってつい最近までMAX 2TBだったんだよね。現行バージョンはさすがにその制限は取れましたが。今やディスク1基で2TBだからなぁ。

ボリュームの名前をつけます。命名は大事だ。
いちおー確認。Ready for formatって感じ？

ここでこんなアラートが！ちょっとどきどきしたけど、なんのことはない。フォーマット実行でDrobo Sが再起動。いきなり接続を切られたシステムがお怒りに。う〜ん。所作が乱暴だ。というかフォーマットしてないし、マウントもしてないのだが。なんでこんなんでるのやら。。。。あ。注意してなかったけど、Drobo Sが再起動したのでその先にぶら下がっているディスクとの接続がきられたかも？それにしても乱暴だ。
ともかくフォーマット実行中。数分間ぢっと待つ。たしかに大体5分かな。計ってないけど。

フォーマット終了すると同時に（笑）。めっちゃ不安になるやんけ。

Reopenすると、何事もなく処理が終わってました。いいのか、そんなんで。「大丈夫だ、問題ない」
そして「新しいバージョンのDrobo Dashboardあるよ」って。。。あたらしいバージョンだったらクラッシュしなかったかも。。。分かんないけど。で、ここで0.5TBハードディスクを追加。一呼吸置いてDroboがディスクを認識して取り込む。そしてスクリーンに追加されたことが表示される。なんかWindowsみたい。。。

ともかく一瞬で容量が1.78TBから2.24TBにふえました。これイイ！。
内訳は、こんな感じ。

さてこのストレージFinderからはこんな具合。最初から18TBの単一ボリュームとして見えている。ここがいいんだよね。ほんとに足りなくなったらディスクを足していけばよいわけだ。このinfoではまだ何もファイル類を置いていないのだが、すでに2GB消費していることになっている。これを引くと確かに空きは16TBで最初の設定通りだ。

というわけで、TimeMachineボリュームをこのDroboにDump。1日と8時間くらいかかるらしい（笑）。まぁ、待ってみよう。結果はまた追記するということで。今見たら残り1日と1時間だった。

Advanced Setting

Advanced-Dataで現在の実際のボリューム消費量がわかる。またディスクの状態も把握出来る。

家鯖に繋いでいるのでいつも画面を見ているわけにはいかない。

よし、テストだ。えーーーー。そうきたか（笑）。