2012年9月27日木曜日

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"アカウントを追加し直して全てのアドレスブックが正常に同期するようになりました。

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




2012年9月22日土曜日

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]

2012年9月16日日曜日

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

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

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

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

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

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

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

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

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

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

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




2012年9月10日月曜日

CVキャブ スロージェット#50

先日手配したのスロージェットの交換作業。

ずっと薄い状態のまま夏を乗り切ったCVキャブ。
ここ最近朝晩の涼しい時間帯の始動時にとうとう"クシャミ"をするようになった。

秋になって空気が乾燥しだすと人間もノドをやられて風邪引いたりするけど、キャブも気温が下がって乾燥してくると空気の密度が高くなって混合気が薄くなり、クシャミなどの不調を訴え出す。w

適正に燃調が出来ていれば問題ないんだけど、今までがとにかく薄かったのでいつ来るかと心配していたのだ。

冬場の不調は、エアクリをハイフロー化してから。
ショートなドラッグパイプの頃は、#45 → #48とスロージェットを上げてみた物のいまいち症状が改善されず、今年の車検後はずっとノーマルの#42のままだった。

現在装着しているマフラーは"ブラスマフラー"なので、以前とは条件がかなり違うんだろうけど、以前試した#48がまったく効果が無かったので今回は思い切って#50, #52を手配していた。

実際いろんな情報調べてみても、「#50までは必要ない」との意見が多数なのだが、物は試しに今回は#50を装着。

かなり濃いめになるだろうと、ミクスチャーを2.5回転戻しでセットし、20〜30kmほど流してきた後再調整してみたのだが、開けるどころか締め込んでいくと回転数が上がってくる。orz

やっぱりちょっと上げすぎた感じ。(´・ω・`)ショボーン

現在1.5回転戻しでセットしてみたけれど、まだ締め込めそうな雰囲気だったので、ジェットは#48へ落とす予定です。(今日はもうかまっている時間が無かったのです)

今月末にはロングランが控えているので、それまでに燃調決めて燃費の確認をしておかなければなりませぬ。

満タンで何キロ走れるのかわからんようでは、給油計画も立てられないしね。


2012年9月4日火曜日

Macで使えるリカバリーソフトの"PhotoRec"を試してみた

月曜朝イチ、制作部のスタッフが突然Skypeで救助要請を送ってきた。

「iMacのデスクトップに置いておいた校了間近のデータが無いんですぅ....。"Data"っていうフォルダにまとめて置いておいたんですが、どうもゴミ箱に入れて消しちゃったみたいで...。(涙)」

との事。orz

あまり望みは無いが、本当にゴミ箱からにしてしまったのなら出来るだけ現状保存しないと空きスペースにデータが書き込まれたら全て終わりだ。

そうでなくても今のMacはシステムログなど、様々なログを取りまくっているので、起動しているだけでもリスクが高まっていく。

すぐシャットダウンしてもらっておいて、リカバリーソフトを探してみたところメジャー所では、

など、各社から8,000円〜10,000円位でラインナップされている。
"お試し版"が提供されてて、購入前に復旧できるか確認できたりする商品もあったりする。

ファイル名まで復元してくれる高機能なもの(データレスキュー3)まであるけれど、如何せんソフト購入する予算申請している暇も無いし、取りあえずフリーで使える物を探してオープンソースのマルチプラットフォームな"PhotoRec"というソフトウェアにたどり着いた。

データのリカバリーであれば"PhotoRec"だけで良いみたいだけど、パーティーション丸ごと復旧できる"TestDisk"というソフトと一緒に同胞されている。
早速ダウンロードしてアーカイブを解凍すると以下のファイル郡が現れる。


当然復旧したいiMacにソフトをコピーするわけにはいかないので、余っていた160GBのHDDを空にしてそこに解凍されたファイル郡をフォルダごとコピーして、USBの外付けHDDとしてiMacに接続。(当然復旧したファイルも格納する場所にもします)

ちなみにこのソフトにGUIはありません。(でもメニュー選択していくだけなので、特に難しいわけでも無いです。)
起動方法は、"ターミナル.app"を立ち上げた後"photorec"のあるディレクトリまで移動して

$ sudo ./photorec (Return) 
Password:(管理者パスワード入力)

で起動させるか、外付けHDDの"testdisk-6.14-WIP"を開き、中にある"photorec"を直接マウスでダブルクリックしても良いです。

但し、マウスのダブルクリック起動の場合ユーザー権限で起動してしまうため起動ボリューム(Macintosh HD = /dev/disk0)がリカバリー対象になりません。


起動ボリュームを検索対象にする為にはroot権限で実行しなくてはならないため、下段に現れている [ sudo ] メニューに"→"キーでカーソルを合わせ、"Return"キーを押します。

すると、"root権限(sudo)"パスワードの入力を求められるので、管理者のパスワードを入力。
これでやっと起動ボリューム(/dev/disk0)がリカバリー対象として選択出来るようになります。(同じ容量のボリュームが/dev/disk# と /dev/rdisk#で2つずつリストされるが、/dev/disk#の方を選択すれば良いです)


後は、 [ Proceed ] にカーソルを合わせ"Return"し、デバイス内のパーティーション選択画面に進む。(ちなみに、各画面で出現する [ Proceed ] は次へ進む、 [ Quit ] は「前へ戻る」になってます。)


この段階で下段に現れる [ Options ] , [ File Opt ] で詳細な動作や、復旧するファイル(拡張子)を選択する事が出来ます。

 [ Options ] では"破損ファイル"の扱いや、"動作モード"の変更が出来る様だけど、特に復旧が優位になるわけではなさそうなのでデフォルトのまま変更せず。w

逆に無駄ファイルを復旧させない為に [ File Opt ] で復旧させるファイルタイプ(拡張子)だけを選択。


今回はターゲットが限定されているので
  • PhotoShopデータ(.psd)
  • PDFデータ(.pdf)
  • 画像データ(.ps/.jpg/.png/.tiff/.gifなど)
  • テキストデータ(.txt)
  • アーカイブデータ(.zip/.sitなど)
に的を絞って検索。ちなみに今回のリカバリーで一番重要な"Adobe Illustrator"データの".ai"がリストに無いけれど、".pdf"を選択する事で一緒に検索してくれるみたいです。
 スペースバーで「選択/解除」操作、"s"キーで「全選択/全解除」、"b"キーで選択条件保存。

検索条件が設定出来たら"Return"で [ File Opt ] を抜け、検索するパーティーションを選び [ Search ] にカーソルを合わせ"Return"してファイルシステムの選択画面へ。


今回のターゲットボリュームはMacの"HFS+"なので [ Other ] にカーソルを合わせ"Return"して復旧データの保存場所選択画面へ。


ここは少し"UNIX/Linux"系の流儀に従って操作。
".."にカーソルを合わせて"Return"で一つ上の階層に移動、別のボリュームに移動するには"/"まで登ってから"Volumes"ディレクトリに入って、別のHDD名に入っていく。
目的のディレクトリにたどり着いたら"."(カレントディレクトリ)に合わせ"c"キーを押すとリカバリー作業がスタート。


ここで1つ疑問なのが、Windowsなどの操作マニュアルを見ると"保存場所"指定の前に、検索範囲(Free=空き領域 or Whole=ボリューム全体)の指定が出来るはずなんだけど、今回使用したバージョン(?)では選択肢が出てこない...。orz

もしかしたらファイルシステム(HFS+)のせいかもしれないのだが、実際ゴミ箱を消去してしまったファイルのリカバリーなので、"Free"が選択出来ればかなり早く検索が終わると思われるのだが、ボリューム全体が検索対象になってしまった為1TBのMacintosh HDで5時間ほどかかった。

リカバリーされたファイルは数千近く。w(詳しくは見忘れたけど、イラレデータが800ちょい、フォトショデータが200ちょっとぐらいで、大半は画像とテキストだったと思う)

当然カタログファイルに従って復旧されているわけでは無いので、階層もファイル名も復元はされません。記号のように連番の振られたファイルが整然と並べられてるだけ。
後は地道に1ファイルごとの内容確認となりますが、後は制作担当者に任せてお終い。w

こんな事態に備えて「リカバリーソフト」の1本くらい常備しておいても悪くないとは思うんだけど、1万円だしてリカバリーソフト買うくらいなら1万円で外付けHDD買って"タイムマシーン"を有効にした方がかなり幸せになれる事間違いなし。w

余談だけど、OS9までは神アプリだった"Norton Utilities"は"OS X"のファイルシステムになってから徐々にフェードアウトしてしまったんだけど、昔は良くお世話になったものです。

【追記】
どうしてもファイル名や階層などまで復元してくれる事を望むなら市販リカバリーソフトを購入するしかないようです。
スタッフの悪戦苦闘ぶりを見ると、やはり大量のファイルの中から必要なデータを探すのはかなり大変そうです...。
(^_^;