Subversion 1.5への移行
Subversionの1.5より前のバージョンでは、内部ではリビジョン毎に同一ディレクトリにファイルが作成されるため、リビジョン数が大きくなるとかなり不安な状態になってしまう。*1
しかし、バージョン1.5からはshardingという仕組みが導入され、1000リビジョン毎に一階層深いディレクトリにファイルが作られるようになったので多い日も安心。
Improved support for large deployments on FSFS, via sharding
1.5では他にも新しい機能がいくつか追加されており、特にマージ関連の機能追加(Merge tracking)がうれしいのでバージョンアップしたいのだが、古いバージョンのクライアントが混在した場合にどうなるかが不安なので調べてみた。
検証に使用したのは以下のバージョン。
$ svn --version svn, バージョン 1.5.3 (r33570) コンパイル日時: Oct 11 2008, 19:03:46
$ svn --version svn, バージョン 1.4.2 (r22196) コンパイル日時: Mar 14 2007, 20:55:55
それぞれMacPortsとCentOS 5.2での最新パッケージ。
Merge trackingを試してみよう
旧バージョンでの検証の前に、とりあえず新機能のMerge trackingを試してみよう。
サンプルとして svn://svn-server/trunk に rails のプロジェクトを作ってみた。
ブランチ作成
[~] $ svn copy svn://svn-server/trunk svn://svn-server/branches/first-test
trunkの作業コピーで適当なコントローラを作成
[~/trunk] $ ./script/generate controller -c login [~/trunk] $ svn ci
first-testの作業コピーで適当なコントローラを作成
[~/first-test] $ ./script/generate controller -c profile [~/first-test] $ svn ci
first-testの作業コピーにtrunkをマージ
[~/first-test] $ svn merge svn://svn-server/trunk --- r2 から r4 までを '.' にマージしています: A test/functional/login_controller_test.rb A app/helpers/login_helper.rb A app/controllers/login_controller.rb A app/views/login
おぉ！
さらにtrunkの作業コピーで適当なコントローラを作成
[~/trunk] $ ./script/generate controller -c message [~/trunk] $ svn ci
もう一度first-testの作業コピーにtrunkをマージ
[~/first-test] $ svn merge svn://svn-server/trunk --- r5 から r6 までを '.' にマージしています: A test/functional/message_controller_test.rb A app/helpers/message_helper.rb A app/controllers/message_controller.rb A app/views/message
おおぉ！
手動でリビジョンを指定したり記録したりする必要がないぞ！
マージしたリビジョンはsvn:mergeinfoプロパティに記録されていた
[~/first-test] $ svn propget svn:mergeinfo /trunk:2-6
最後にfirst-testブランチからtrunkへのマージ
$ svn merge --reintegrate svn://svn-server/branches/first-test --- リポジトリ URL 間の差分を '.' にマージしています: A test/functional/profile_controller_test.rb A app/helpers/profile_helper.rb A app/controllers/profile_controller.rb A app/views/profile U .
やったー
ただし、ブランチを作成してからtrunkにマージするまでの間にどちらかでディレクトリの移動(名前変更)又はコピーが行われていると、最後のマージで失敗してしまう。
[~/trunk] $ svn merge --reintegrate svn://svn-server/branches/first-test svn: Cannot reintegrate from 'svn://svn-server/branches/first-test' yet: Some revisions have been merged under it that have not been merged into the reintegration target; merge them first, then retry.
その場合は以前と同じ方法でマージを行えば問題ない
[~/trunk] $ svn merge svn://svn-server/trunk@11 svn://svn-server/branches/first-test@11 .
古いバージョンでのマージ
ブランチ作成
[1.5:~] $ svn copy svn://svn-server/trunk svn://svn-server/branches/second-test
trunkの作業コピーで適当なコントローラを作成
[1.5:~/trunk] $ ./script/generate controller -c star [1.5:~/trunk] $ svn ci
second-testの作業コピーで適当なコントローラを作成
[1.5:~/second-test] $ ./script/generate controller -c bookmark [1.5:~/second-test] $ svn ci
1.4クライアントでsecond-testの作業コピーにtrunkをマージ
[1.4:~/second-test] $ svn merge -r 17:19 svn://svn-server/trunk A test/functional/star_controller_test.rb A app/helpers/star_helper.rb A app/controllers/star_controller.rb A app/views/star
trunkの作業コピーへさらに適当なコントローラを追加
[1.5:~/trunk] $ ./script/generate controller -c anond [1.5:~/trunk] $ svn ci
1.5クライアントでsecond-testの作業コピーにtrunkをマージ
[1.5:~/second-test] $ svn merge svn://localhost/trunk --- r17 から r21 までを '.' にマージしています: A test/functional/anond_controller_test.rb A test/functional/star_controller_test.rb A app/helpers/star_helper.rb A app/helpers/anond_helper.rb A app/controllers/anond_controller.rb A app/controllers/star_controller.rb A app/views/star A app/views/anond
重複してマージが行われてしまった。ファイルに一切変更がなければよきに計らってくれるみたいだけど、何らかの変更があると
--- r17 から r22 までを '.' にマージしています:
A test/functional/anond_controller_test.rb
A test/functional/star_controller_test.rb
A app/helpers/star_helper.rb
A app/helpers/anond_helper.rb
A app/controllers/anond_controller.rb
'app/controllers/star_controller.rb' で競合が見つかりました。
選択: 延期 (p), 全差分 (df), 編集 (e),
ヘルプでその他のオプションを表示 (h) : p
C app/controllers/star_controller.rb
'app/views/star' を飛ばしました
A app/views/anond衝突する。
マージ作業を古いクライアントと混じりながら行う事は考慮されていないようだ。
まとめ
- Merge trackingは便利
- ブランチ作るならクライアントも1.5にした方が良い
- 1.4以前でマージをすると不幸になる
*1:FSFSの場合
AutoRun
手元で確認したものでは、
- インターネット上からウィルスの本体をダウンロード(AutoRunで実行されるのはダウンローダ)
- 本体を実行
- (多分)本体が
- 各ドライブにAutoRunの設定をする
- 作成するファイルは読み取り専用隠しファイルのシステム属性
- 隠しファイルを表示しないようにレジストリの設定を変更
- ウィルスとしての本来の動作を行う(キーロガー?)
こういった事を行っているらしい。
作られる autorun.inf ファイルの中身はこんな感じ。
実際は所々にアンチウィルス避けと思われるランダムな文字列が含まれてた。
[Autorun] open=virus.com ;shell\open=Open(&0) shell\open\Command=virus.com shell\open\Default=1 ;shell\explore=Manager(&X) shell\explore\Command=virus.com
Windows XPの場合、この状態ではドライブアイコンをダブルクリックしても、コンテキストメニューから開こうとしてもウィルスが実行されてしまうので、安全にドライブを開くには、ドライブ認識時のダイアログでフォルダを開いてファイルを表示するを選ぶか、エクスプローラのフォルダツリーからドライブを選択するかしないといけない*1。
そんな変わった操作を完璧に行うのは大変なので、レジストリでAutoRunを無効にしてしまった方が良いと思う。
亜種だらけでアンチウィルスソフトもあまり役に立たないようなので。
HDL-F300をシャットダウンするスクリプト
眠りの浅くなったIO DATAのLANDISK HDL-F300を確実に寝かしつけるため、シャットダウンするスクリプトを書いてみた。
require 'net/http' require 'uri' HOST = '127.0.0.1' PASSWORD = 'yourpassword' Net::HTTP.version_1_2 Net::HTTP.start(HOST, 80) do |http| http.post('/gate/shutdown_set.cgi', ['adminpasshtm=' + URI.encode(PASSWORD), 'skipv=', 'submitbtn=OK'].join('&')) end
電源をONにするためには本体のボタンを押さなければならないので、やり方としてはなんと言うかすごく…、エコ？
追記(2008/11/27) ファームウェア 1.02 以上ではこのスクリプトは機能しなくなった
I-O DATA LAN接続ハードディスク 「LANDISK」 300GB HDL-F300
- 出版社/メーカー: アイ・オー・データ
- 発売日: 2006/03/20
- メディア: Personal Computers
- クリック: 5回
- この商品を含むブログ (3件) を見る
Time Capsuleを買った
Time Capsuleの500GBを買った。
どうやら量販店にはまだ入荷していないみたいなので、ポイントを諦めApple Store渋谷で購入。35,800円。定価。
箱を入れてくれたリンゴマーク付きの袋が、背負うのでなければとても持ちづらい。これがAppleのおもてなしかっ！
箱の中身は、Time Capsule本体と電源ケーブル、あとは説明書等の冊子とAirMac ユーティリティインストール用ディスクのみ。LANケーブルは付いていないのであわせて買いたい。
底面はゴムのような素材になっていた。見えづらいけどアップルロゴ入り。
自宅のネットワークはルータと無線LANのアクセスポイントが別の機器になっているので、アクセスポイントを取り外してTime Capsuleを接続する。
AirMac ユーティリティをインストールし起動して選択肢を選んでいくだけで設定が終わる。Mac用なので、AP側をWPA-AESに設定したらつながらなくて*1頭を抱えるという事も無かった*2。とても簡単。
2008/11/12 追記
以前使用していたiBookはWPA-AESに対応していなかったらしいけど、現在のMacBookは対応している(WPA2 パーソナル)。非対応機器があるのでなければTime Capsule側はWPA/WPA2 パーソナルではなくWPA2 パーソナルに設定すべき。
Time Capsule自体もPPPoEを喋れるけど、WANポートからルータに接続して、ブリッジの無線LANアクセスポイントとして使う設定でも使えた。
Time Machineのバックアップは、初回は時間がかかると書いてあったので、初回のみ有線で行う事に。バックアップ対象は約100万ファイルの46GB。大体5-6分に1GBのペースで転送されている。netstatで見ると、TCPのポート548番を使って転送しているみたいだ。/etc/servicesによれば548番は「AFP over TCP」。AFP…。
バックアップは36GBくらいまで済んだ所で完了してしまった。残りの10GBは何のファイルだろうと思ったら、少なくとも5GBはVMwareの仮想マシンだった。ディスクイメージファイルが巨大だからだろうか。仮想マシンを起動する度に数GBのファイルが更新されるので、バックアップされたらされたで場所を取って困るけど。
その後の1時間毎のバックアップは数MB程度の転送なのですぐに終わる。ラップトップの場合、電源につながっていないとバックアップはしないそうだ。
仕様に
シリアルATAサーバグレードハードディスクドライブ
と書いてあったので静音性無視のマッチョなドライブが載っているのかと心配していたけど、ディスクアクセス時に多少カラカラ音がする以外は静か。空気の出入り口が見当たらないのでファンレスじゃないかと思う。本体を触ると結構温かいので夏場が心配。
追記: 分解写真を探してみたら、ファンは付いていた。
Time Capsule自体は静かだけど、Windowsファイル共有絡みのブロードキャストパケットを定期的に投げているため、I-O DATAのLANDISKがスリープに入ってもすぐ起きるようになってしまった*3。LANDISKはファンが回るので結構うるさい。なんてこった。
Apple Time Capsule 500GB MB276J/A
- 出版社/メーカー: アップル
- 発売日: 2008/02/29
- メディア: Personal Computers
- 購入: 2人 クリック: 141回
- この商品を含むブログ (28件) を見る
Cookieの内容で認可を行うApacheモジュール
調べ事をしていたらmod_auth_hmacと似た事が実現できるモジュール(リリースはmod_auth_hmacよりずっと前!)をたまたま見つけたので、これはひとつまとめておかねばと思い、Cookieの内容で認可を行うApacheモジュールを探してまとめてみた。
そのつもりは無かったのに、なぜか開発者は日本人が多いような。
- mod_auth_cookie
- mod_auth_cookie_fu
- Apache 2.0.x
- ライセンス: MIT
- モジュールは認可のみ行う
- mod_auth_hmacより高機能
- mod_auth_form
- Apache 1.3.x
- ライセンス: 未定
- モジュールのみで認証と認可が可能
- 認証部分は通常htpasswdを使用するが独自に実装する事も可能
- mod_cookieauth
- Apache 1.3.x / 2.0.x
- ライセンス: 独自
- モジュールは認可のみ行う
一応mod_auth_hmacについても
Google Analyticsはじめました
こういうレイアウトGIGAZINEぽくね？ぽくね？
それはさておき、最近セキュリティホール memo メーリングリストでも話題のGoogle Analyticsを導入してみました。3ヶ月くらい前に。
レポートを見ると
- セッション
- 平日が多く土日(休日)が少ない
- 時間帯では16-17時がピーク
- OSとブラウザ
- 参照元
- 検索キーワード上位
- sqlインジェクション 対策
- hdd 処分
- php セッション管理
- それぞれ現在Google検索での表示位置は9位,6位,14位
という事なのだそうだ。
要するに、仕事で調べ事をしていてここに辿り着く人が多いようだ。
そして、かなり希有な"読者"の方は大体フィード経由で読んでおられるようで、全文配信にしてリンクをはてな記法じゃなくしている*2甲斐があったというもの。
なお、未だに検索して辿り着く人がいるMySQL Connector/ODBC(MyODBC)のSQLインジェクション等については書きたい事があるものの、都合により書けないため、使用を検討されている方には先立って十分な調査をお願いしたいわけですが、直帰率が95.74%なので多分ここは見ないと思う。
