スポンサードリンク

2014年08月11日

GoogleのGmailの表示が全部Bold(太字)になってしまう不具合を確認

Windows8.1(pro 64bit/Surface pro 3)のChromeで確認している不具合?と思われる現象です。
Chromeはバージョン 37.0.2062.68 beta-m (64-bit)
で動いています。
また、Chromeのログインを使っており、ユーザーは会社のものと個人のものと2つ併用しています。

で、会社のアカウントは新しいアカウントなのかバグっておらず、
古い・・・昔からずっと使っているアカウント側がこのバグをくらってます。

さっそくですが、
chrome-extension://caclkomlalccbpcdllchkeecicepbmbm/options.html
を見てみましょう。

・ユーザ1(バグってない)
キャプチャ.JPG

・ユーザ2(バグってる)
キャプチャ2.JPG

なんと、この「どうやってもそこイジれねえだろww」って場所が太字になっているではないですか。
このユーザ2のGmailが全部太字になってて見難いんです。
全部です。メール読むときも書くときも。
IEだとどちらのユーザでもこの状態にはならないので、高dpi(解像度)かな・・・の対応でなんか変な不具合があるんじゃないかなー。

しかもこのユーザ2でF12を押してデベロッパーツールを表示させると、
この太字がデベロッパーツールが出ているときだけ治るというわけわからん状態。
明らかにChrome側の挙動でバグっているくさいのです。
(といっても、Gmail画面でF12押しても治らないですけど)

これはフォントどうこうとかいう問題ではないみたいで・・・
FireFoxで全部太字になる問題があったとか、海外の質問掲示板で見ましたけど。
Chromeはあんまりなくて。

IEが今のところSurface Pro 3だと一番綺麗に文字が表示されるっぽいです。
でもIEを使う気が起きない・・・Chromeのログインで全部設定がひっぱってこれるので楽なんです。
IEに移行する気が起きないなあ・・・。
何かのきっかけでIEに戻るかもしれませんが、ChromeがリリースされてからずっとChromeですのでね。
火狐は使いません。あれはツール使いたい時専用です。メインじゃない。
posted by hinata_hisa at 17:36 | 東京 ☀ | Comment(0) | IT関係 | このブログの読者になる | 更新情報をチェックする

2014年08月08日

Amazon RDSにElastic-IPは紐づけられない(はず)

You do not have permission to access the specified resource.jpg

「You do not have permission to access the specified resource」

なんなんでしょうかこのエラー?
これは、RDSにElastic-IPをAttachしようとすると出るエラーです。

RDSをインターネット経由でつなぎたい場合は、Publicly Accessibleの設定をYes(On)にして使えば、
ちゃんとグローバルIP(Public DNS)が割り当てられるので、そのIPアドレスで使えます。

なのでE-IPはいらないです。IPを固定したい場合があるかもしれませんが、基本的にPublic DNSの名前で利用するものだという認識です。

■追記
RDSはAWS側が冗長化してくれているので、ELBと同じで裏に何台かいるんだと思います。
そのエンドポイント的な部分がCNAMEみたいに1つ割り当てられているので、基本的に名前でしか使えないという動きなんだと思います。
これはAWSの技術的な仕様なのかなと。
RDSにE-IPをつけたいというのは、ELBにE-IPをつけたいと言っているのに似てるかな。
ELBの仕様がわかっていたら「それは無理ですよ・・・」と、なると思います。

上記、どこか間違いがあったらお手数ですがご指摘いただけると幸いです。
タグ:AWS
posted by hinata_hisa at 19:17 | 東京 ☁ | Comment(0) | IT関係 | このブログの読者になる | 更新情報をチェックする

2014年08月07日

Surface Pro 3(Windows 8.1)のタッチキーボードを無効にする方法

タッチキーボードを無効にする方法です。
1.サービスを無効にする
2.ツールバーからタッチキーボードの表示を消す

1.サービスを無効にする
Touch Keyboard and Handwriting Panel Service
というサービスが裏で動いているので、これを無効にします。

TouchKeybord.jpg

やり方は、検索(Windowsキー+Cで現れる一番上)から「ローカルサービスの表示」を起動させ、
上記サービスを停止したあと、右クリック⇒プロパティ⇒スタートアップの種類を「無効」に変更します。

スタートアップの種類を「手動」にしていても「トリガー実行」と記載されている通り、
タッチキーボードが必要なタイミングで勝手にサービスが起動してきてしまうので、無効にするのが一番です。

2.ツールバーからタッチキーボードの表示を消す
上記作業を実施すると、デスクトップ画面の右下にあるタッチキーボードのアイコンが無駄になります。
押しても何の反応もしなくなります。
なので、こいつを消してしまいましょう。

キャプチャ.JPG

これは、画面一番下のタスクバー上で右クリックし、プロパティ⇒ツールバータブの選択⇒一覧から「タッチ キーボード」のチェックを外す
で消えます。

これでタッチキーボードがまるで全く無いかのごとき運用が可能です。

まあ、正直タッチキーボードって、キーボードの凹凸が全くないのでめちゃくちゃ打ちにくいですし、Surfaceを本体だけで運用することって、まずないと思うので切っていていいと思います。
私はロジクール信者なので、

 

この2つを1つのUnifyingレシーバーで運用しています(USBポートが1つしかないので)。
ちなみに、マウスを2,136円で購入してすぐにAmazonが2,012円まで値下げしてきて凹んでいます(´・ω・`)
キーボードは5,081円でした。
前までこれの前身の750を使っていたので(現在は750r)慣れているこれにしました。
値段もちょっと安くなったかなと思います。
posted by hinata_hisa at 11:15 | 東京 ☀ | Comment(0) | IT関係 | このブログの読者になる | 更新情報をチェックする

2014年01月12日

AWS認定ソリューションアーキテクトアソシエイトレベルに合格しました

2014年1月11日に試験を受けて、AWS認定ソリューションアーキテクトアソシエイトレベルに合格したので、そのためにやったことをメモレベルで記載しておきます。

■ながれ
2013年12月20日に申込み。
年末から勉強開始、2014年1月11日に試験を受けて合格。

■業務経験
Amazon EC2は4年。VPCは1年程度。
自分で3回ほどVPCの環境を設定資料に沿って設定するくらいはしたことがありますが、メインはずっとEC2でした。
ELBはSSL証明書含めて設定したことがあります。

反対に言うと、S3を単体で使ったこともありません。
IAMもほとんど知りませんし、他は全然ダメな状態でした。

■以下のものを参考にした
・製品一覧
http://aws.amazon.com/jp/products/
暇があったらぼけーっと眺めていました。
「何それ聞いたことないぞ」というサービスが無いようにしていました。

・AWS クラウドサービス活用資料集
http://aws.amazon.com/jp/aws-jp-introduction/
トレーニング資料⇒Amazon VPCトレーニング⇒トレーニング資料
 ⇒http://adsj-contents.s3.amazonaws.com/training/vpc-training/Partner_Training_VPC-%E9%85%8D%E5%B8%83%E7%94%A8_ver4.0.pdf
これは物凄く勉強になるので単純にAWSを基礎から整理したい方は是非ですね。
ただ、このページ全部読んでいるだけでかなりの労力なので、全部は読みませんでした。

・AWS 認定ソリューションアーキテクト – アソシエイト レベル試験に合格する方法
http://dev.classmethod.jp/etc/how-to-get-a-certification-aws-architect-associate-level/
参考になりました。ただ
AWSにおける静的コンテンツ配信パターンカタログ(アンチパターン含む)
http://dev.classmethod.jp/cloud/aws/static-contents-delivery-patterns/
こっちの方が実戦的で面白かったです。

・AWS アーキテクチャセンター
http://aws.amazon.com/jp/architecture/
ここも重要だと思ってみていました。
1:AWS クラウド アーキテクチャのベストプラクティスに関する白書(日本語)
2:AWS での耐障害性のあるアプリケーション構築に関する白書(日本語)
3:災害復旧目的での AWS の使用白書(日本語)
この3つはしっかり読みました。

・クラウドデザインパターン#2 CDP 画像・動画配信編
http://www.slideshare.net/AmazonWebServicesJapan/aws-summit-2012-2-cdp
これらなどのデザインパターンも結構重要だと思ってかなり目を通していました。
ベストプラクティスの知識はちゃんとつけておきましょう。

・クラウドデザインパターン#3 CDP Eコマース編 (EC-CUBE)
http://www.slideshare.net/AmazonWebServicesJapan/aws-summit-2012-3-cdp-e-eccube
などなど。

「AWS認定ソリューションアーキテクトアソシエイトレベルに合格しました」の続きを読む
タグ:AWS
posted by hinata_hisa at 14:04 | 東京 ☀ | Comment(0) | IT関係 | このブログの読者になる | 更新情報をチェックする

2013年11月02日

Windows Server 2008のタスクスケジューラをこねくりまわす

こんなアホなことを真剣に考えているサーバ運用者も俺くらいじゃないかと思ったので記念にメモっておきます。

■前提
Windowsのタスクスケジューラってのは、
「いついつにこれ実行しろよ」
っていうやつです。

で、サーバ運用っていろいろあるので、これを駆使して戦います。
特にAWSのようなクラウド環境だと、シャットダウンしておかないとお金が取られるので、
できるだけシャットダウンしておきたいんです。
シャットダウンはサーバ内部からやらないと、
AWSのStopコマンドだとサービスの停止などが不完全になる可能性が高く、
よってサーバ内部からのタスクスケジューラを利用してのシャットダウンが一番安全ではあります。

■シャットダウンスケジュールを2つ用意する効率の良いイレギュラー対応
例えば、毎日24時にシャットダウンしているサーバがあります。
このサーバの利用者から「毎週金曜日だけは21時停止で良い」と言われたとします。

さて、このときは、既存のタスクスケジューラにある
A)毎日24時にサーバをシャットダウンするスケジュール
を編集する必要はありません。ここに、
B)毎週金曜日は21時にサーバをシャットダウンするスケジュール
を追加すれば、上の通りになります。

というのも、Bのタスクが実行された後にAが実行されたとしても、
既にサーバはシャットダウンされているので問題ないのです。

では反対に、毎日24時にシャットダウンしているサーバがあり
このサーバの利用者から「毎週金曜日だけは25時停止が良い」と言われたとします。

うーむ。ならどうしようか?この場合は、
C)毎日1時(25時)にサーバをシャットダウンするスケジュール
D)毎週金曜日"以外"は24時にサーバをシャットダウンするスケジュール
という設定が可能なので、これでいけます!

■毎月の最終金曜日だけなんとかしてくれの場合
これは、もう少し複雑です。上の例を引き続き使うと、
例えば、毎日24時にシャットダウンしているサーバがあります。
このサーバの利用者から「毎週金曜日だけは21時停止で良い」と言われたとします。
に加えて、「"毎月最終週"の金曜日だけは18時停止で良い」と言われたとします。

さてどう設定しましょうか。クイズですね、もう。

このときは、既存のタスクスケジューラにある
A)毎日24時にサーバをシャットダウンするスケジュール
はもちろん生かしておいて、
B)毎週金曜日は21時にサーバをシャットダウンするスケジュール
ももちろん生かしておきます。そこに加えて
E)毎月の最終金曜日は18時にサーバをシャットダウンするスケジュール
を加えればOKです。

20131102-33550.jpg

うん、実はこんな設定までできるんだよねえ。
がしかし、これでも難しいのが以下のパターン。

例えば、毎日24時にシャットダウンしているサーバがあります。
このサーバの利用者から「毎週金曜日だけは21時停止で良い」と言われたとします。
に加えて、「"毎月最終週"の金曜日だけは25時停止が良い」と言われたとします。

いやいやいやいや・・・考えてみましょう。

A)毎日24時にサーバをシャットダウンするスケジュール
はもちろん生かしておいて、
B)毎週金曜日は21時にサーバをシャットダウンするスケジュール
ここまではOK。当たり前だ。

で、さらに・・・ここに何を加えたらいいんだ?

F)毎月の最終土曜日は1時(これで金曜25時)にサーバをシャットダウンするスケジュール

を加えても駄目。
だって「B」において、金曜日の21時にシャットダウンされてしまってるのです。
Aでも24時に落とされてしまうので・・・あーあーあー

うーん。考えた結果・・・

G)毎週金曜日"以外"(つまりは毎週の日月火水木土)は24時にサーバをシャットダウンするスケジュール
これで金曜日以外はOK。残りは金曜日の話。
で、金曜日は場合わけすると、

◎第5週まである場合
第1金曜日:21時
第2金曜日:21時
第3金曜日:21時
第4金曜日:21時
第5金曜日:25時

◎第4週までしかない場合
第1金曜日:21時
第2金曜日:21時
第3金曜日:21時
第4金曜日:25時

のどちらかのパターンしかない!ってわけで、不完全だけども
G)毎週金曜日"以外"(つまりは毎週の日月火水木土)は24時にサーバをシャットダウンするスケジュール
に加えて
H)毎週土曜日の1時(金曜日の25時)にサーバをシャットダウンするスケジュール
を設定。これで
「月末じゃない毎週金曜日の21時から25時までは不要なお金がかかるけど運用はまわるしOK」
なところまで持ってこれました。

さて、ここに
I)毎月の第1,2,3の金曜日は21時にサーバをシャットダウンするスケジュール
を追加します。
そうすると、「◎第4週までしかない場合」パターンでは問題ない運用になって、
「◎第5週まである場合」では第4週目だけが21時から25時まで少々無駄になる、というだけで済みます。
なお、「I」に第4まで加えたら「◎第4週までしかない場合」パターンでアウトになるので
これではいけませんね。運用が回らないのは駄目なんです、はい。

もうこれでいいじゃん!!

・・・

駄目です。
「Windows Server 2008のタスクスケジューラをこねくりまわす」の続きを読む
posted by hinata_hisa at 04:11 | 東京 ☁ | Comment(0) | IT関係 | このブログの読者になる | 更新情報をチェックする

2013年09月02日

【AWS】ftpの接続が「150 Opening ASCII mode data connection for file list」で停止する

備忘のため記載しておきます。

発生した問題は表題の通り、
「ftpの接続が「150 Opening ASCII mode data connection for file list」で停止する」
という問題です。
よくある話といえばよくある話です。

調査してみたら以下のことがわかりました。

1:ffftpでもコマンドプロンプトからのftpでも同じエラーが出る
2:cmdからのftpだとopenはできるがlsコマンドを打つと上記の場所で停止してそのまま帰ってこない
3:PASVモードだと何故かつながる
4:ACTIVEモードだとつながらない

また前提として、
・クライアントはAWSのアカウントNo.1
・ftpサーバはAWSのアカウントNo.2
と、AWSのアカウントを跨いでいました。
また、それぞれinstanceで存在しており、EC2及びVPCを利用しています。

で、IPは
クライアント:192.168.128.1(アカウント1に所属)
ftpサーバ:172.23.1.250(アカウント2に所属)
とします。

さて、AWSはVPCにあるNACLのブラックリストを除けば基本的にホワイトリストである
Security Groupしか利用しないと思います。
で、ここを確認してみたのですが・・・確認したときは、
192.168.128.1⇒172.23.1.250
においては、outboundはデフォルトの0.0.0.0/0のALL Trafic。
そしてinboundについては、特に意識してませんでした。

で、172.23.1.250側のinboundですけども、これは
192.168.128.1/32に対してTCPのALL portを許可。
うーん、問題なさそう。

次に、それぞれのwindows firewallを確認。
どちらも完全にOFF。
うーん、関係なさそう。

しょうがないので
192.168.128.1のinboundに
172.23.1.250/32でTCP ALL portを解放してみました。
じゃあOKに。

つまり、
「ftpのactive接続はinboudが必要」
ということがここでやっとわかった気がしました。
なんとPASVはoutboundしかいらない!!

ここで
http://www.infraexpert.com/study/tcpip20.html
http://www.infraexpert.com/study/acl12.htm
ここのサイトをみてみました。

ここのActiveモードの説明を見てびっくり。
まず、制御用のコントロールコネクションとデータ転送用のデータコネクションにわけられるんですけど、

Activeだと
【コントロール】
client → ftpサーバ
【データ】
client  ftpサーバ

ってなってます。やはり、これクライアント側のinboundだわ。
ここのコネクションの確立はサーバ側からなんです。知らなかった!
ってことは、サーバ側のoutboudの話でもあります。

PASVだと
【コントロール】
client → ftpサーバ
【データ】
client  ftpサーバ

どっちも→だ!!!
つまり、クライアント側のoutboundだけの話で完結します。

よって、この問題の解決策は以下の通りです。

■問題
前提として、AWSのアカウント1とアカウント2のそれぞれのInstance同士でftpで疎通しようとしている。
そのときにはどのようにftpに対するSecurity Groupを設定すればいいか?

■解決策
1:Activeの場合
この場合は、ftp clinet→ftp serverの接続に加えてftp clinet←ftp serverも必要になる。
つまり、ftp clinetのinbound/outboundとftp serverのinbound/outboundどちらも設定が必要。
・ftpクライアント:192.168.128.1(アカウント1に所属)
・ftpサーバ:172.23.1.250(アカウント2に所属)
とした場合、192.168.128.1では、172.23.1.250/32に対してinbound/outboundとも全port(1024番以上)の解放が必要。
172.23.1.250では、192.168.128.1/32に対してinbound21番/outbound20番portの解放が必要。
(※どちらもoutboundはデフォルトで全部解放されているので、inboundを追加しないといけない)

2:Passiveの場合
この場合は、ftp clinet→ftp serverの接続のみになる。
つまり、ftp clinetのoutboundとftp serverのinboundだけのシンプルな話になる。同じく
・ftpクライアント:192.168.128.1(アカウント1に所属)
・ftpサーバ:172.23.1.250(アカウント2に所属)
とした場合、192.168.128.1では、172.23.1.250/32に対してoutboundで1024番以上の全portの解放が必要。
同様に172.23.1.250では、192.168.128.1/32に対してinboundで1024番以上の全portの解放が必要。
(※outboundはデフォルトで全部解放されているため特に意識せずとも良いことが大半。inbound側を意識するのはサーバ側は当然なので、ここを設定してあげればいい。1024番以上については仕様⇒greater than 1023)

・細かい話
1023"より"でかいなので1024"以上"であってます

※クライアントとサーバのアカウントが別々にわかれていなくても良いんですけど、アカウントが一緒の場合は同じセキュリティグループに属させてしまうことが多いので、多分この問題には当たらないと思います

※追記
以下の知恵袋最強すぎる・・・。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1118264251

>・アクティブFTP
>・データコネクションは、サーバ側の20番から、クライアント側の1024以上の任意のポートに接続される。
>・クライアント側で、FTPサーバからのコネクションに対応できるよう1024以上のポートを開放しておかないといけない(開けるポートは複数あり、それはFTPサーバの仕様により異なり、固定するにはそれなりの知識が必要)
>・サーバ側は、21番の受けと、20番からの発信のみを許可するればよいので、サーバ側のセキュリティが上がる。
>・クライアント側は、不特定のポートを常に開放する必要があるので、セキュリティレベルが下がる。

関連記事:Amazon Web ServicesのEC2上にFTPサイトを構築する時に注意するポイント IISの場合

posted by hinata_hisa at 21:08 | 東京 ☀ | Comment(0) | IT関係 | このブログの読者になる | 更新情報をチェックする

2013年07月17日

"エセクラウド"は撲滅されるべき。本当のパブリッククラウドを使え!

2010年の3月頃からAWS(Amazon Web Services)が提供しているAmazonEC2(Amazon Elastic Compute Cloud)を業務で使用し続けている私からIT業界に苦言。

今では皆さんが当たり前のように口にするようになった「クラウド」ですが、
その本当の意味での"パブリック"クラウドのパイオニア的存在は間違いなくAWSです。

さて、「本当の意味って何?」という話になると思います。
本当の意味とは「NISTの定義を守っているか」です。

特に以下の4つ、

・On-demand self-service: 必要にあわせて自動的(=提供者側の人による仲介作業なし)にサーバーやストレージを利用できる。
・Broad network access: いろいろなプラットフォーム(携帯電話、ラップトップ、PDAなど)から、ネットワークを通じて使える。
・Resource pooling: マルチテナントモデルで提供され、一般的にはサーバーやストレージがどこにあるかはわからない。
・Rapid elasticity: すばやく(時には自動的に)、スケールアウト・スケールインできる。

これらを守れているか?という点は非常に大きい。

昨今、日本で跋扈しているのは、これらが一切守られていないクラウドサービスです。
「"エセクラウド"は撲滅されるべき。本当のパブリッククラウドを使え!」の続きを読む
posted by hinata_hisa at 14:36 | 東京 ☀ | Comment(0) | IT関係 | このブログの読者になる | 更新情報をチェックする

2013年02月07日

Seesaaブログの投稿用メールアドレス宛にメールがエラーで送れない問題が解決

設定> 詳細設定> メール投稿設定
で「投稿用メールアドレス」を設定して、そのアドレスをコピペして
メールを送ると何故か宛先エラーに!

Gmailだと

エラー
[To] フィールドのアドレス「〜〜〜〜@​b​l​o​g​.​s​e​e​s​a​a​.​j​p」が認識されませんでした。すべてのアドレスの形式が正しいことを確認してください。

何故だ!?
サンダーバードからだと送れるけどGmailからだと駄目!
何故?

と色々てんやわんや。

結果、「ノーブレークスペース」問題!

参考:http://colo-ri.jp/develop/2012/05/url-zero-space-broblem.html

まず、これがメールアドレス設定の画面で、↓

20130207-143305.jpg

ここの「投稿用メールアドレス」部分に記載されている青色文字になっているところ。
ここをコピー(Ctrl+C)すると、上にある「ノーブレークスペース」が混じってしまいます

確認するには、ChromeブラウザのURL入力部分に入れてみてください。
こんななります。

20130207-143327.jpg

凄まじいぼこぼこ感

そんなわけで、ここをコピーしないようにして、
手で全部打つか、メールアドレスをクリックするとmailtoでメーラーが立ち上がりますので、
そこの宛先を保存するのが良いでしょう。

これ不具合として直して欲しいなあ。
ぱっと見でわからんですよね、ほんとに。
Gmailが宛先の場合のみノーブレークスペースを自動排除してくれても良いよー。
posted by hinata_hisa at 14:41 | 東京 ☀ | Comment(0) | IT関係 | このブログの読者になる | 更新情報をチェックする

2012年10月26日

GOM PLAYERでFLV形式の動画が再生されない場合の対応

以下の不具合は2013年2月末のアップデートで修正された模様です。

OSをWindows7 64bitにしてからGOM PLAYERでFLV形式の動画が再生されず困っていました。
うーん・・・公式に書いてあることをやっても再生されず・・・。

と、そこでふと思いついてやってみたらドンぴしゃで再生されました。

1:F5キーを押して環境設定を表示
2:「フィルタ」を選択
3:下段の「ソースフィルタの使用設定」からFlash Videoの項目を確認
4:これの、チェックを外す
GOM_FLV.png

とすると、再生されます。

逆転の発想!!
GOMのデフォルトの推奨設定がむしろダメ。
ってわけで、これで再生できました!
posted by hinata_hisa at 23:46 | 東京 ☁ | Comment(0) | IT関係 | このブログの読者になる | 更新情報をチェックする

2012年06月21日

【SVN】「No such revision xxxxx」リポジトリの特定リビジョンが消えたときの復旧方法

20120621-202511.jpg

ぐああああああ!!
Subversionで管理しているリポジトリの特定のリビジョンがピンポイントで壊れました。
これを復旧しなくてはいけません!

■復旧しない場合に起こる悲劇
1:エラーが出ているリポジトリパス以下は二度と参照できない
 ⇒もしrootでこのエラーが出たら全てのリポジトリが見られないという罠
2:svnadmin dumpで出力するSVNdumpが途中で1つ飛ぶので、dump入れなおすと途中から前の状態とリビジョンがズレだす(可能性)

■発生の経緯
1:HDDに不良セクタができる⇒このとき既にSVNでは上記のエラー
2:CHKDSKを実行する
3:問題のリビジョンの物理ファイルが消えてしまう
4:復旧せな ← 今ココ

20120621-202603.jpg

rev55844が消えてしまっているの図。

■復旧手段
まず準備するもの:リビジョンが壊れる前のバックアップ⇒svn_dumpとします
簡単にいうと、この場合55844が消えているので、
昔の綺麗な状態でバックアップ(svn_dump)からloadして復旧⇒最近コミットされたリビジョンを差分で追加
で回復できます。
そのためには、svn_dumpにどこまでのリビジョンが入っているか調べる必要があるので、まずはどこかにloadして、どこまで綺麗なリビジョンが残っているか確認してみましょう。

私の場合は56000まで残っていました。
あとはコマンド打つだけです。

■コマンド(windowsです)
rem 変数設定。MAXは現在の最大リビジョンを設定
set backuppath="C:\tracwork\recover"
set MAXrev="57000"

rem サービスの停止
net stop TracLightning
net stop Hudson
net stop MySQL

rem バックアップしながらtestリポジトリを消す
move C:\TracLight\projects\svn\test C:\TracLight\projects\svn\test_bk

rem ロックされていたらmoveでrenameされないのでここで確認
pause

rem rev56001以降のdmpをtest_bkから出力する(56000まではバックアップされている)
svnadmin dump C:\TracLight\projects\svn\test_bk -r 56001:%MAXrev% --incremental > %backuppath%\dump_from_56001

rem プロジェクト復活
svnadmin create --fs-type=fsfs C:\TracLight\projects\svn\test

rem dmpimport
svnadmin load C:\TracLight\projects\svn\test < %backuppath%\svn_dump
rem これでリビジョン56000まで入る

rem dmpimport2
svnadmin load C:\TracLight\projects\svn\test < %backuppath%\dump_from_56001
rem これでリビジョン56001から入る

rem hooksの復旧
xcopy /c /s /e /q /h /i /k /r /y C:\TracLight\projects\svn\test_bk\hooks C:\TracLight\projects\svn\test\hooks

rem サービスの起動
net start MySQL
net start TracLightning
net start Hudson

これで消えたリビジョンは復旧できます。
作業中はLAN線を抜きましょう。途中でコミットされたらやり直しです。
作業後は確認も忘れずに。
posted by hinata_hisa at 21:23 | 東京 ☀ | Comment(0) | IT関係 | このブログの読者になる | 更新情報をチェックする