トップ 最新 追記

2010-08-07 [長年日記]

_ tarアーカイブにファイルを追加する

あるいは保管目的のログファイルの整理ポリシーを変えましたの話。

結論

.tar.gz -> .gzs.tar

にします。

before
複数のログファイルを tar でまとめて gzip などで固める
after
それぞれのログファイルを gzip などで縮めて tar で固める

背景

保管するログファイルの扱いに困っていました。いや、実際には困っていたというよりはなんとなくあんまりうまくないなぁという程度の感覚でやっていたわけですが。

複数のファイルを保管目的でバックアップする場合、多くはディスク容量の節約をするため tar + gzip などの方法で圧縮していると思います。しかし

この方法はけっこう贅沢なディスクの使い方だ

ということに気がつきました。

問題

多くの、そして古い Un*x の教科書的なドキュメントにはバックアップに tar + gzip を利用する方法が書かれています。しかしこの方法では

tar + gzip を実行するタイミングまではログは生のサイズのまま

なのです。

例えば「月1回ログをまとめて圧縮する」というスケジュールにすると1ヶ月間はログは生のサイズのままです。けっこうな大きさになります。

しかしこの1ヶ月という期間の設定はよくあるパターンかなと思います。あとで DVD などに退避させる際にはこれくらいの期間で置いてあると何かと使い勝手がよいです。

個人では 1TB がヨユーで買えてしまうこのご時世ですが、お仕事的には経費が掛けられないものすごく厳しい状況が続いていますので、生ログのサイズのままハードディスクに置いておくのはできるだけやりたくありません。

試行

そこで

tar.gz のアーカイブにログファイルを append できたら便利じゃね?

と思いつきました。でも結論から言うとどうもこれはできないらしい。まぁ普通に考えてかなり無駄というか無茶な処理ですよね。tar はなぜ失敗したのか分からないけど失敗、cpio の場合は圧縮と append は同時にできねーよ、とはっきり怒ってくれます。

そこで、

rotate と同じ要領で先に gzip しといて tar にまとめりゃいいのか

と気づきました。

解決

何を言ってるか分からないかもしれないのでテストスクリプトを書きました。

  1. まずダミーのファイルを作って途中までをそれぞれgzipで圧縮してtarアーカイブを作る
  2. その段階でのアーカイブの中身を表示
  3. 残りのファイルをgzip圧縮してtarballにappend
  4. アーカイブの中身を表示

しています。ちゃんと追加されている様子が分かります。

これで、

  1. アーカイブファイルの名前を年月などから自動決定する
  2. そのファイルがすでにあればそこに append なければ新規作成

するスクリプトに仕立て上げれば全自動でディスクを節約するアーカイブのできあがりでしょうか。

これなら時期を見て DVD などに退避させる際にも対象のファイルはすでに圧縮してアーカイブ済みなので、えっちらおっちら圧縮する手間と時間も削減できます。

一石二鳥。

Tags: Sysadmin

2010-08-08 [長年日記]

_ svnsync試してみた

svnsync は subversion repository の replication ツール。Subversion 1.4 から使える。よくバックアップって紹介されたりするけどバックアップと replication はなんか違うような気がする。RAID とバックアップが違うのと同じ感じかなぁ。

目的は忘れました

なんでこんなことをしようと思っていたか忘れました。なんかでも以下のようなことを考えていたような。

  1. Capistrano は rsync による deploy もできるけど repository から取ってくるのがやっぱ王道?
  2. でも普段の commit 作業はローカルのサーバの方が速いし快適だし
  3. svnsync 使えばいいの?

実際にやってみた

意外に準備が面倒。

  1. sync 先を svnadmin で作る
  2. sync 先の repository を手作業で sync 先として準備(後述)
  3. sync 先の repository を svnsync init DEST SRC で準備

※ sync 元の repository へは当然 read only アクセスしかできなくても問題ない。

ここまでくれば

svnsync sync

で ok.

2 の手作業っていうのは pre-revprop-change フックの作成のことで、素の repository を例に取るとこんな感じになる。

REPOSITORY/
|-- README.txt
|-- conf/
|-- db/
|-- format
|-- hooks/
|   |-- post-commit.tmpl
|   |-- post-lock.tmpl
|   |-- post-revprop-change.tmpl
|   |-- post-unlock.tmpl
|   |-- pre-commit.tmpl
|   |-- pre-lock.tmpl
|   |-- pre-revprop-change*      <-- これ
|   |-- pre-revprop-change.tmpl
|   |-- pre-unlock.tmpl
|   `-- start-commit.tmpl
`-- locks/

内容は

#! /bin/sh
exit 0

で、いいらしいんだけどこのことは残念ながら svnbook には書いてないんだよなー。hook がありさえすればいいっていうのはナゼか、とかも分からない。「そういうもの」として書かれていてなんか気持ち悪い。

一部だけsyncしてみた

あと、できるんじゃないかと思ったけど

  • 一部だけ sync もできる
    • svnなのでURLに詳細なパスを指定すればよいだけ
  • ただし revision は全部コピーされる
    • sync 対象以外の path は空 commit のような扱いになる(repository の db の中身を見るとすぐ分かる)

ということなので、でっかい repository を全部 replication しなくちゃいけないわけじゃないです。目的別に replica を作ってうまく使えるかも。

※ Subversion 1.5+ だと partial mirror は許可しないって書いてありました

忘れ物

自動化するには svn の repository の中の hooks の中の

post-commit

スクリプトに実行ビット立てて

svnsync sync URL

を叩いてやる必要があります。


2010-08-10 [長年日記]

_ OSX で Google Calendar と同期できる何か

要求

OSX 10.4 で Google Calendar をブラウザを使わずに利用したい

正確には iCal のカレンダーを共有したい、だったんだけど、関係する人みんなの見れるサーバが必要だけど、それだったら Google Calendar 使った方がいいんじゃないの?ということでそっちの流れに。

選択肢

OSX 10.5 以降は標準で iCal が Google Calendar と同期できるらしいんだけど、10.4 では標準ではできないらしい。10.4 で現実的なのは

  1. Thunderbird + Lightning + Provider for Google Calendar
  2. iCal + GCalDaemon

くらいっぽい。

自分が使っているのが Lightning だったので 1 の方法をオススメした。

Thunderbird + Lightning + Provider for Google Calendar

Provider for Google Calendar を入れると「新規カレンダー」を作成する際に「ネットワーク上のサーバに保存する」の中に「Google カレンダー」という選択肢ができるので、そこに ICAL フォーマットのカレンダーアドレスを追加すれば ok.

public な calendar でも認証を要求されるみたい。まぁそのくらい我慢しろということで。

iCal + GCalDaemon

Tape » iCalとGoogleカレンダーの同期(OSX10.4の場合)

から辿った方法で実現できるらしいんだけど、今回は試してない。


2010-08-17 [長年日記]

_ rst2odt.py 用の stylesheet を作る

まずは Rakefile を作る

先日の準備からサクッと一ヶ月以上経過してようやく作業を開始。まずは作業の流れを整理する。

  1. styles.xml をいじる
  2. styles.xml を含むファイルを styles.odt という名前で zip アーカイブに仕立て直す
  3. styles.odt を --stylesheet に与えて rst2odt.py で reST ファイルから .odt ファイルを生成
  4. できあがった .odt ファイルを(Macなので)open を使って OOo で開く

これを気に入ったスタイルができあがるまで延々くり返す。

同じ作業を延々くり返す…。

Rakefile を書きましょう。

今回は初めてまともに file タスクを作った。これを使うと変更があったときにだけ生成や変換が行われるようになる。task タスクだと毎回愚直に実行される。

cf. Rake

ここまでできた

wtnabe's rst2odt_stylesheet at master - GitHub

この日記を書いている段階で

  • ページを A4 に
  • フォントを IPAex に
    • IPAex は日本語を monospace で欧文を proportional で表現してくれるので細かくフォント指定せずにそのまま書き連ねるのに向いている
  • 日本語では不自然なイタリックを除去
  • 箇条書きの記号を大人しく

できた。

また styles.xml じゃなくて command line argument --table-border-thickness で border-width を設定。

諦めたのは

  • table cell の padding 調整
  • 見出しに prefix を付ける。

辺り。

table の border もそうなんだけど、table-cell への style を指定する方法がないみたい。table-cell は一つ一つに名前が付いて細かく style を指定するから stylesheet としてデフォルトを当てるのは無理っていう設計なのかな。

見出しの prefix はこれは恐らく個人的な要望で、どういうことかというと、見出しって普通文字を大きくしてボールドにして…とかやるんだけど、日本語の「普通の文書」だとこの見出しってあんまり大きくしない方がバランスいいと思う。なんだけど、やっぱちょっと目立ちにくい。そこでいつもやってるのは

行頭にそれっぽい記号を入れる

方法。これで文字サイズを極端に変えずに見出しとしての attention を維持しようという考え。

で、その prefix の挿入を自動でできないかと思ったんだけど、とりあえず CSS の

h1:before {
  content: '■ '
}

みたいなことはできないっぽいので手で入れることにして逃げました。そこにこだわって時間掛けても仕方ない。

あとは地の文だけ(table 内のテキストなどは対象外)にインデントが設定できればほぼ満足かなぁ。

良い副作用

[2010-10-23 追記]

この方法で .odt を作ったら思わぬ副作用があった。できあがったファイルを OOo で開いて PDF にエクスポートするとちゃんとアウトラインを保持した PDF を作ることができる。

当たり前っちゃ当たり前なんだけど、これはなかなか感動的。そんなに長い文章を書くことは多くないけど、やっぱり構造が見やすいのは良い。とても良い。

注意とか疑問まとめ

  • table の border を stylesheet で指定する方法はない。コマンドラインオプションで与える。
  • list の indent は Emacs の rst-mode が正しくサポートできていない。上の階層から 3文字下げるとちゃんとレベルが下がるが、rst-mode は 2文字下げで止まってしまう。
  • indent を含む list の変換が微妙。
* 上のレベル
   * 次のレベル

これは OK

 * 上のレベル
    * 次のレベル

これは NG

違いは行頭の空白。reST では bullet の前に space は置かない方が良いらしい。ただし indent がない場合は行頭に空白があってもなくてもよい。

うーん難しいわ。特に Trac の Wiki と併用していると混乱必死。Trac も基本的に reST で書くようにしちゃえばいいのかなぁ。

関連エントリ

心の叫び

Twitter / wtnabe: table の border は styleshee ...


2010-08-18 [長年日記]

_ GMail経由で別なドメインのメールを使う際に分かったこと

とりあえず吐き出しメモ。

GMail

  1. GMail を通じて受信する方法が2つあるっぽい
    • 「Forward」は Forward のタイミングでフィルタを走らせて細かい制御ができるらしいけど、とりあえず全「Import」の方針でアカウントを追加
  2. GMail を通じて送信する方法も2つあるっぽい
    • GMail の smtp を使う方法と使いたいアドレスのオリジナルの smtp を使う方法。使いたいアドレスのオリジナルの smtp サーバの方から送信するには、そのサーバが SMTP-Auth 対応と TLS か SSL 接続が必須
  3. SMTP-Auth に対応していない smtp サーバを指定することはできないので、その場合は必然的に GMail の smtp サーバを使う
    • その際は Sendar に GMail のアドレスが出てしまうので、どうしても表に出したくない GMail アドレスは使わないが吉。新規にそれ用のアカウントを取るべし。
  4. 使いたいアドレスの smtp サーバから送信した場合に Sendar に GMail のアドレスが出ないのかどうかは未確認
  5. outgoing encoding は default にしておくと日本語のメールはちゃんと iso-2022-jp で出て行くらしい

Mail.app

  1. iPad標準のMail.appはAPOP非対応らしい。iOS 4 とか試してないんだけど、たぶんみんな似たようなもんだろう。APOPはダメ。
    • 海外ではもう保護したければ SSL だろってことなのかな?
  2. GMail を経由して別なアドレスを使いたい場合はアカウントの追加時に「GMail」を選んじゃダメ
    • 「その他」から「メールアカウント」を追加して必要な設定を行う。その際、アドレスを , 区切りで複数設定することができるので、先頭に使いたい GMail 以外のアドレスを設定しておくと、デフォルトでそのアドレスが From にセットされる。
  3. Mail.app ならデフォルトで Bcc に自分を入れるとかできて、ブラウザから使うより快適

cf. iPadでgmailのIMAPを使用したとき、送信者がgmailアカウントになる問題 メモのある生活


2010-08-21 [長年日記]

_ GeohashのグリッドをGoogle Maps上に再現するツール書いた

一ヶ月ほど前に Geohash を知って以来とても興味深く思っていたんだけど、ふと「グリッド」に自由が利かなくて不便な気もして、とりあえず直感的に目視できるツールが欲しくなったので作ってみた。

できること

  • Geohash を与えるとそれを Google Maps 上に展開する
  • 現在の Geohash と Map の Zoom level を表示
  • Map を scroll させるとちゃんと Geohash のグリッドが追随する
  • 上の情報を Fragment ID と同期しているので URL を人に渡せる
  • ついでに Geocoding も

必要なもの

  1. davetroy's geohash-js at master - GitHub から geohash.js
  2. Rake
    • 上の geohash.js の取得や初期値などの反映に必要。ただし手で書いてもらってもよい。

入手

gist: 541945 - Geohash Visualizer- GitHub

から git clone か download でどうぞ。

すぐに動かしたい人向け

Geohashエリア確認ツール

に置きました。iPhone でも試せるサイズにしてあります。

感想

Rake むずい。でも便利。

じゃなくて。

Geohash は面白いんだけど、例えば「金沢駅西エリア」を人間の意図通りに一つの Hash 文字列で表現するのはちょっと難しい。(四つ合わせると金沢駅周辺を表現することはできる。)こうなると文字列の前方一致だけで包含関係を表せるという Geohash のメリットはちょっと微妙なんじゃないかと感じている。「○○周辺」みたいなボカした表現にせざるを得ないのかなぁ。カーナビならそれでもいいんだよな。

参考

複数のGeohashでどのようなエリアを作れるか確認できるツールを書いた

本日のツッコミ(全3件) [ツッコミを入れる]

_ hikaruworld [Geohash便利ですよね。アルゴリズムも難しくないし。 ちなみにGeoHexってのもあります。]

_ wtnabe [GeoHex の方は先に知っていたのですが、いちばんの難点はビジュアル表現かなと思っています。シミュレーションゲーマ..]

_ まこと [google map api v3対応の確認ツールを作成しました。 zoom levelが指定できなかったり、スク..]


2010-08-27 [長年日記]

_ tag を打つ

git で tag を打って push しようとしたんだけど、tag の打ち方が分かってなくて、自分が svn 脳になっていたのが分かった話。

git

基本的には git の tag 打ちは

git tag -a TAGNAME

かな? で、

git tag

git tag -l

ってやると打った tag の確認ができる。そう、確認できるってことを分かってなかった。確認してればハマる必要なかったんだけど、自分はここで

commit できねぇ

と思ってしまった。必要ないのに。

commit できなきゃ push できないじゃーんと思っていたが、そんなことはなかった。

git push --tags

すれば作った tag を push できた。

svn

svn には tag も branch もない。自分はこの思い切りの良さ、きらいじゃないんだけど、git の開発をするに至った Linus にはとてもバカバカしいものに見えているようで、かなり辛辣な批判をしている。

Linus曰く「Subversionは史上最も無意味なプロジェクト」 - スラッシュドット・ジャパン

まぁとにかく tag も branch もない。あるのは cp だけ。つまり、その時点のディレクトリツリーの snapshot を取る機能だけ。で、それを commit する。

cvs

cvs の tag はどうだったっけと思って調べたらやはり cvs の tag も commit 不要だった。

cvs tag [-b] TAG

※ cvs の場合はファイル単位で tag を打てるし、割とそういう文化だったんだけど、そこは省略しておく。

で、確認の方法はすっかり忘れていたんだけど、

cvs stat -v

でイケた。

cvs --help status
Usage: cvs status [-vlR] [files...]
	-v	Verbose format; includes tag information for the file

これで tag が打てていることを確認できる。