TestDiskでHFS+の外付けディスクのパーティションを救おうとして失敗

こういうの得意じゃないんだよなぁ。

  • Macでフォーマットした外付けHDDのパーティションテーブルが飛んだっぽい
  • 普通に接続してもパーティションを認識できない

TestDisk - CGSecurity

を教えてもらったが、UBCD の TestDisk では USB 接続の外付けディスクは見えない（UBCD なので当たり前かもしれない）。

  1. バラして繋いでみると TestDisk からパーティション自体は見える
  2. 復旧しようと試みたが APM ( Apple Partition Map ) は対応してないし、pdisk 使えと言われる
  3. pdisk なんて知らないし、泣きながら調べる
  4. NetBSD 辺りが由来の partition 操作ツール
  5. 言われるがまま操作してみる
  6. なんとか作業終わる
  7. Mac に繋ぐとパーティションそのものは認識できたような気がするが結局 mount できない
  8. 強制的に mount しようとしてもやはりダメ

詰み orz

本当は

他に十分な容量のあるディスクがあれば

  • Mac 以外で mount を試みる
  • とりあえず dd でコピーしてあれこれ試みる

という手があったんだけど、残念ながら手持ちに十分な余裕がなかったのでこんな結末に…。時間などモロモロの判断で結局再フォーマットして使うことになった。無念。

バックアップ用のハードディスクだったらしいけど、バックアップにするなら通電させておいた方がいいと思うよ。自分も以前「電気入れたらバックアップディスクが壊れて数年分の思い出が飛んだ」ことあるから。

それはともかく、Intel GUID なパーティションなら TestDisk 単体で復旧できるみたいなので、今後はまだ少しマシになるかもしんないな。というか

  1. 飛ぶと困る HDD は必ず冗長化
  2. 常に予備の大きめのディスクを確保

だよな、やっぱ。

うっ。私物ノートのディスクは十分な冗長化がなされていないな。まずいまずい。いずれ自宅サーバをでかいのに換装して丸ごとぶちこむか、重要なデータはそもそも残さないようにした方がいいな。テキストデータについてはもう少し頑張ればなんとか実現できそうな気がするなぁ。

久しぶりにPartty!を実験

Partty!.org

は tty を共有するサービス。アプリをインストールして立ち上げると、それ以降の tty の様子を全世界に配信してしまう tty 版の Ustream である1。

サービス開始はいつだったか覚えてないけどそんな最近の話じゃない。なんだけど、最近になってこれを思い出したのでどの程度使えそうかもう一度実験してみた。で、分かったこと。

  • CLI の様子は Win/Mac ともに問題なく配信可能
  • screen も使えて、window 切り替えも問題なく動く
  • Emacs も使えた
  • screen/Emacs ともに window 分割は NG（手元の機械も正しく描画できない）

また、

  • Windows +cmd.exe では irb や python など独自の interactive shell は NG

だった。実は今回はこれがちょっと痛いんだけど、Windows 以外では問題なく使えるし、tty にこだわるなら Windows なんか使ってないで Un*x にすればいいじゃんという気もする。もしかして PowerShell v2 ならまた違うのかもしれないけど、そこまでは実験してない。誰かやって。

利用ポート

Flash による公開セッションの閲覧partty.org:[80, 7776, 7777]
tty の状態の送信partty.org:2750
telnet による共有partty.org:7777

となっているので、特に 2750 への送信が切られてると意味がありませんし、ただの閲覧でも 7776, 7777 が開いている必要があります。くくくく。意外にハードルが高い。

なお、通信の様子は

$ sudo ngrep -d en1 dst partty.org

で確認できます。さっさと思い出してやればよかった2。

なんだなぁ。やっぱ screen -X 最強か？ でもそうするとネットワーク越しに宗教戦争だしな。

  1. それ以外にも telnet 経由で文字通り tty を共有することも可能 ↩

  2. -d en は自分の使っているデバイスを正しく書くこと ↩

豪華披露宴…

なぜだろう。

昭和の匂いがするのは。

まぁでもだからいいのかもしれませんが。

イマドキ珍しい、やたらと段取り、手続きのしっかりした人たちだなぁと思いました。

tDiary を port forward 越しに使うと一部おかしい

※ 長いんでまた日付を未来にずらしてしまう作戦。

とりあえず日記に書いちゃえメソッド。2.1.4 で確認。

具体的には tdiary.rb の base_url メソッドでの URL の組み立て方の問題と、それの適用範囲の問題。

def base_url
  return '' unless @cgi.script_name
  if @cgi.https?
    port = (@cgi.server_port == 443) ? '' : ':' + @cgi.server_port.to_s
    "https://#{ @cgi.server_name }#{ port }#{File::dirname(@cgi.script_name)}/"
  else
    port = (@cgi.server_port == 80) ? '' : ':' + @cgi.server_port.to_s
    "http://#{ @cgi.server_name }#{ port }#{File::dirname(@cgi.script_name)}/"
  end.sub(%r|/+$|, '/')
end

別段おかしなところはなさそうに見えるんだけど、port forward してると期待通りに動かない。

例えば localhost 8080 からサーバの 80 に飛ばしているとき、サーバでは 80 に繋がっているわけだから、8080 は無視されてしまう。これを基準に URL を組み立てている RSS auto-discovery や image プラグインは http:// localhost/hogefuga/ へのリンクを生成してしまう。しかし実際にはそこには何もない。通常のリンクは相対で生成しているので、ほんとに一部だけでおかしなことになっている。

対応としてはヘッダの Host フィールドを使う。http:// からの絶対 URI はどうしても必要でなければ極力使わないってだけでずいぶん話は簡単になると思うけど、RSS はそうもいかないし。ただ逆に port forward した URI が RSS に埋め込まれても困る、という別な問題もあったりする。だから

  • base_url は Host を利用できるなら利用し、できない場合は上の処理
    • そのうえで、極力使わない
  • makerss.rb 独自か、あるいは日記の設置 URI という値を用意して、そこに正規の絶対 URI を保存する

って感じで対処するのがいいんだろか。

ちなみに今回自分がどうしたかというと、

@options['image.url']

を設定して http:// からの URI が生成されないようにして回避した。RSS とかその辺は気にしてないものなので無視。

あ。

自画自賛で思いついたけど、日記の設置 URI って値はあったら嬉しいかも。例えば permalink もこれを使うようにできればいい。

なんでかっていうと、このサイトは現在 aligach.net だけれども、www.aligach.net でもアクセスでき、そっちでアクセスしちゃうと TrackBack の送信先とかも www 付きのものになっちゃう。でも複数の URL でアクセスできるってことと permalink が複数あるってのは意味が違うと思うんだよな。できれば permalink は常に aligach.net になってほしい。

そういうときに便利かなと。

テクニカルエンジニア（情報セキュリティ）創設予定とな

新試験「テクニカルエンジニア(情報セキュリティ)」とは? （MYCOM PCWEB IPAX 2005 - 今語られるスーパークリエータの開発のきっかけ(2) ）

ほほう。

来年創設予定。ほほう。

情報セキュリティアドミニストレータは受けてから気づいたけど、基本的にシステムがいじれなくても勉強すれば通る。少なくともサーバ管理のスキルは必要ない。もちろんいじれた方が理解は早いし正確な理解にたどりつきやすいのは間違いないけど、概念と法律の知識の比重が高いので、これはいかんなぁと思っていた。1今度はこれを技術寄りに振ると。データベースの話が多くなるのは昨今の事情を反映してってことなんでしょうな。アクセスコントロールって意味ではこれは基本中の基本なので別に不思議じゃないんだけど、データベースだけクローズアップされるとちょっと違和感を覚えるな。

記事中にもあるけど、確かにベンダー非依存を目指すのは難しそう。陳腐化させずに全部 Linux Box で作ってくださいって話になったらそれはかなり邪魔くさいというか、現実的じゃない。もちろん全部 Linux Box で自前で組むという選択もあるだろうけど、現実的には組み込み機器を適切に配置してシステムを構築する。それはコストと実現されるもののバランスのうえで判断されるものであり、この過程で機器、ベンダーに対して得手不得手が出てくるのも半ば当然の話だ。（全部ソフトでいく場合もそう。）

取るなら試行錯誤のスタート直後の方が楽か？ :-)

  1. いやいや、ユーザー側にこういう知識を持った人間が必要という意味では十分機能する可能性は高いし、「上」を説得するためには法律などの枠組みはとても重要ですよ。 ↩

プロパティ別 CSS

CSS記述規則「プロパティ別整理法」の提案

労作だなぁ。

alternative stylesheet を考えるときや、media 別に CSS を分けるなんて場合はこういう書き方せにゃならんのですよね、実際のところ。つまり、幅広いプラットフォームを考慮して CSS を書くときは「表現でセレクタを串刺しにする」ような書き方ができなきゃならんのです。逆に言うとグラフィカルな最新ブラウザしか考えないなら分ける必要はないんじゃないかと。

最近は blog ツールなどの方で HTML ごと表現をごっそり入れ替えるのが楽になったから、あえてそういう書き方をする必要もなくなってきましたけどね。簡単なところでは「印刷向けページ」を別に生成することなく、CSS だけで自分のページを印刷向けに仕上げてみると、このプロパティ別整理の有効性が分かると思います。少なくともテキストブラウザや音声ブラウザを動かしてみるよりははるかに簡単に確認できます。

※ 実際には私はプロパティ別には整理してないですけど、考え方は比較的近いです。

lily 文字化け

組み合わせによる模様。デフォルトの

データsjis
出力utf8

だとダメだが、

データeuc
出力sjis

の場合は問題なく変換されて表示できた。なんでダメな状態をアーカイブするかなぁ。。

ひょっとして、uconv は 1.8 標準じゃないのかな？ ……（調査中）……。やっぱり。なんでこの状態で配布してるのにドキュメントに書いてねーんだ！ くそー。オレがバカだから動かないのかと思っちまったじゃねーか。

よーし、今度からヒマみて flavour 作ろっと。

※ どっか部品で utf8 依存で書かれている部分がある模様。とにかく uconv 必須ってことですな、これは。それかデータから何から全部 utf8 で書け、と。

ck 0.9.4 でついに jis 表示可能に

28日に出ていた。気づかなかった。

資料整理

ローカルのマシンでとっ散らかってる情報を説教講座や自宅サーバなんかに追い出しながら整理。すっかり手元のマシンは作業スペースとしての役割が強くなってきた。まだまだあまりに古いファイル群をどうするか問題はあるが、徐々に使いやすい環境にしていこう。

スラドで初 ID 書き込み

してみた。ボチボチ？

最近、blog だのなんだのと興味深い Web 上の動きを眺めたり考えたりしていたら、2ch とスラドの違いについても少し興味が湧きはじめた。長いこと気にならなかったことに今さら興味が湧くってのも面白い。

日記が Wiki ならドバドバ書き始めちゃうところだけど、そういうわけにもいかないから小出しにしていこう。

（この頃は Web 日記そのものに不慣れであれこれ試行錯誤していたのだなぁ。「ページ」という完成品の単位が自分の意識の中にあり、自分が調べものをしているときにサイト内検索のない日記が引っ掛かかって難儀した経験が多々あり、Web 日記そのものにあまりいいイメージがなかった。）

About

例によって個人のなんちゃらです