10.6のiCloud同期で大はまり...

取りあえずiPhoneと自宅の環境はiCloudなので問題ないのだけれど、会社のiMacがどうしてもLion以上に出来ない。
出力機の関係でApple Talkが切り捨てられた10.6もきつかったけど、Rosettaがなくなった10.7には現時点ではどうしても上げられない。

まぁ、プライベートな情報だし、会社のMacに入れておかなくても良さそうなもんだが、仕事上メールを多用するに当たっていちいちiPhoneのアドレス帳で調べながら作業するのも効率が悪いので"アドレスブック"のデータも同期しようと思い立つ。

"も"って言うのは、実はスケジュールだけは何時でも確認したかったのでiCloudに移行したあとすぐにiCalだけはiCloudと同期が取れるようにセットアップしてあったのだ。

iCal(Snow Leopard)のiCloud同期は意外と簡単で、iCloudに接続してるLion Macの"~/Liblary/Calenders/xxxxxx.caldav/"以下にある"info.plist"ファイルから接続しているサーバー情報の記述

<key>PrincipalURL</key>
<string>https://p[xx]-caldav.icloud.com:443/[xxxxxxx]/principal/</string>

の部分を探しだし、iCalの環境設定から"CalDAV"アカウントを追加するだけでiCloud上のデータを読み込むようになる。

（ちなみに"[xx]"の部分は数字、"[xxxxxxx]"はユーザーIDになっていてこれも数字。）

で、本題の"アドレスブック"の同期も、基本的には同じ要領で同期させるんだけど、これがなかなか一筋縄ではいかなかった。

"アドレスブック"の同期情報はiCoud同期しているMacの "~/Library/Application Support/AddressBook/Sources/" 以下の "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" といった長い英数字が羅列したフォルダ内にある "Configuration.plist" というファイルを参照した。

後半の方にある"principalInfo"というkeyの後に記述があって、

<key>DAV::principal-URL</key>
<string>https://[Account]%40mac.com@p[xx]-contacts.icloud.com/[xxxxxxx]/principal/</string>

※"iCal"と同様、"[xx]"の部分は数字、"[xxxxxxx]"はユーザーIDになっていてこれも数字。
の部分がサーバー情報。

"iCal"の情報と比べてわかるように、"アドレスブック"はURLの前に、"@"で区切ってアカウントを記述しているのだが、この"iCloud"のアカウントの記述方法が一つ目のポイントで、"アカウント"と"サーバー名"の区切り文字に"@"を利用している為、"Apple ID"のメールアドレスに含まれる"@"をそのまま記述できず、英字記号を16進数で表した"%40"で表記している。

で、実際のセットアップ時もこの表記方法が必要で、"アドレスブック"の環境設定から"CardDAV"のアカウントを追加する際"ユーザー名"欄には

＜アカウント＞%40me.com：＜パスワード＞

の形式で、"@"を"%40"にし、コロン（：）で区切ってパスワードの入力も必要になる。
（なぜか、その下の"パスワード"欄にも再度入力が必要。）

もう一つセットアップのポイントは、正常にセットアップされても"404エラー"が表示されること。w
逆に、失敗する場合は長い間接続トライしていて、「接続出来ません」のメッセージになる。

取りあえず接続出来て認証が通れば、アドレスブックに"CardDAV"アカウントとしてiCloudがセットアップ出来ます。

一番はまったのはこの後で、問題なくリアルタイムに同期しているのだけれど、同期する度にどんどんアドレスの件数が増えていく...。(T_T)
全部ではないのだが、特定のアドレスだけが同期する度倍増していってしまうのだ。

350件ほどしかないアドレス帳が数分後には1,000件ほどにまで膨れあがっていくのは、放置していられないので、ググって調べてみると同様の事例が報告されている。

どうやらプロフィール画像の部分に画像が張り付いているデータを同期すると2重同期していくとのこと。
これは画像を削除する以外対策が無いようだったので、せっせと（といっても数件だけだけど）画像を消し込んでいったんだけど、これがまた上手くいかない。

リアルタイムに同期している為、1件分のプロフィール編集している間にどんどん同期が進んでいく。せっかく消した画像がiCoudからまた画像入りのデータに差し替えられる。
といった状況で、まったく進んでいかない。(T_T)

結局、"CardDAV"アカウントを削除してローカルデータを消去。
自宅のデスクトップにリモート接続してオリジナルアドレスデータから完全に画像を消去してiCloud同期。

その後再度会社のアドレスブックに"CardDAV"アカウントを追加し直して全てのアドレスブックが正常に同期するようになりました。

大した作業でもないはずなのに、なんだか妙に疲れた...。（′Д`）

VMwareゲストのフラグメンテーション

サーバーも仮想化技術が進んだお陰で、保守や引っ越しなどが格段に楽になった今日この頃。

今週末は調子の悪くなったサーバーの引っ越し作業にすったもんだして、二晩連チャンの徹夜作業になってしまった。

木曜日の夜の作業で、サーバーを別のサーバーへそっくり引っ越す作業だったのだが、4GBのデータを移動させるのに通常であれば2〜3時間程度で終わるはずなのに朝（8時間経過）になっても半分も取り出せない。

結局、クライアントのサーバーを日中止めるわけにも行かないので、作業を中断しグダグダのサーバーのまま再度運用再開。orz

実質"300MB/時間"程度しかデータの読み出しが出来ていない状態。(T_T)
ビットレート換算だと680Kbps程度か？　10Mbps帯域保証のネットワーク回線でのコピーが680Kbpsってどういう事？?

で、原因を突き詰めていってどうも怪しいのは"VMware"の仮想ボリュームという結論に。
大半のWebサーバーはParallelsの仮想化ソフトで管理しているのだが、いくつかのサーバで"VMware Server"を利用して仮想サーバーを構築している。

無償のソフトウェアを使っておいて文句言う筋合いじゃないのだろうけれど、特にSQLなどのデータベースが頻繁に読み書きするWebサイトを"VMware Server"上に構築すると、時間と共にレスポンスが段々悪くなってくるみたいだ。

どうやら細かな読み書きが多発するコンテンツは"VMware"ゲストの仮想ボリューム（.vmdkファイル）がかなり重度なフラグメンテーションを起こすらしい。

このフラグメンテーションが進んでいくと、CPUもメモリも十分余裕があっても、HDDの応答待ちだけでかなり時間がかかるようになってくる。
結局サーバーがグダグダなのは、サーバーリソースなどの問題ではなく、"WMware"の仮想環境にあったわけでした。

ただ、容量が変動する仮想ディスクでなく、固定の容量で構築していればこのような酷い状態にはならないようで、構築時にしくじっていたという事実も判明。

いずれにしても中身を抜かないと再構築も行えないので、翌日の晩にリベンジの引っ越し作業を敢行。

まずはHDDの読み出し速度を正常化させないと仕事にならないのでホストへ"ssh"でログインした後メンテナンスコマンド（-d）で仮想ディスクのデフラグを実行。

# vmware-vdiskmanager -d [ゲストOS名].vmdk

20GBほどの仮想ボリュームは15分ほどでデフラグ完了。（早!!）

早速マイグレーションでコンテンツの引っ越しも実行。
「うん、普通に転送速度が出るようになった。これなら3時間もあれば全ての作業は完了できる。後はマイグレーション完了後にDNSを書き換えて新しいIPへ振るだけ...。」
の、予定だったのだが前日の徹夜がたたって、うたた寝...。ww

気付いたときには、すでに5時近くになっている。
慌ててDNS書き換えたものの、2時間ほど経ってもレコードのキャッシュを書き換えてくれないDNSもチラホラ...。（自宅のフレッツ光-NTTPCもそうだった）

しょうが無く、古いIP側のhttpdも動かして"vhost.conf"にProxy転送設定を書き込んで強制的に新しいIPへ転送する事に。

ProxyPass / http://[新しいIP]/
ProxyPassReverse / http://[新しいIP]/

久しぶりに冷や汗ものもサーバー引っ越し作業となりました。
その後、娘の運動会会場へ出向きテントの下で爆睡してしまいました。orz

【追記：備忘録】
デフラグ前に使用する"vmware server 2.0"用コマンドライン

・ゲスト一覧取得
# vmware-vim-cmd vmsvc/getallvms

・ゲストOS起動
# vmware-vim-cmd vmsvc/power.on [VM id]

・ゲストOS停止
# vmware-vim-cmd vmsvc/power.off [VM id]

・ゲストOS再起動
# vmware-vim-cmd vmsvc/power.reboot [VM id]

・ゲストOSサスペンド
# vmware-vim-cmd vmsvc/power.suspend [VM id]

CV スロージェット再調整、他

夏の間あまりの暑さにサボりっぱなしだったバイクの洗車を敢行。
早起きして涼しいうちに済ますつもりが、前日の深酒がたたって早起きできず、結局火が高くなってからの作業開始。

ホイールなど、細かい所まで念入りに洗おうと思っていたんだけど、とても9月の中旬とは思えない日差しが暑すぎて断念。

そのかわり、夏場突然の雨に降られたりして思いっきり汚れていたサドルバッグを洗濯することにして、定番の"WIKI"サドルソープで思いっきり丸洗い。
雨染みなども全て濡らしてしまえば消えてしまいます。w

サドルソープはトリートメント成分も入っているので、丹念にすすぎ洗いせず陰干しでしっかり乾燥させます。
しっかり乾燥させないとカビが生えるんですよね...。（′Д`）

サドルバックを陰干ししている間、これまたこびり付いた汚れ（カビ？）が落ちなくなってしまったラバーグリップを新調して交換。

イメチェンしても良かったんだけど、このクラシカルな樽形グリップがタンクデザインともマッチしていると思っているので同じ物を交換です。
ちょっと太めだけど、以外と手が痺れないのは肉厚なラバーのお陰かもしれない。

また、前回思い切って番手を上げたせいで、思いっきり濃いめに振ってしまった燃調を見直し、スロージェットを#50 → #48へ落とす作業を行い、ミクスチャーのセッティングの為に市内を一回り。

30kmほど走り込んできた後ミクスチャーを徐々に開けていき3回転手前から回転数が落ち始めるのを確認。
これからもっと乾燥が進んで気温が下がっていく事を考慮して2.5回転戻しでセット。
意外といい位置でセットできたので、今年の冬はこれでいってみます。

夕食後、十分乾いた（ように見える）サドルバックのメンテナンス。w
さすがにサドルソープにトリートメント成分が入っていても水洗いしたレザーはごわごわ。

ここ最近のスキンケアは"ラナパー"レザートリートメントだけ。
これはベタつかないし、撥水効果も兼ねてくれるのでメンテナンスがちょー楽ちん。
バックスキン出なければ、ほとんどのレザーに使えるのでかなりお薦めです。