ごまめの遠足。

RAID引っ越し工事

寄り道が過ぎた結果、電器屋の閉店時間に間に合わずOSを買い損ねる(バカ)。とりあえずFS専用機からRAIDHDDだけ取り出す。

ただし、マザーの取説を見た限りでは、ミラーを構築したドライブは、必ず中身が消えることになっている(それはGigabyteも?)。バックアップを取りたいところだが、手持ちのHDDの全空き容量を合わせても足りないので、ここは素直に新しいHDDでミラーを作ってコピーする、が正解かもしれない。

…本当は、1TBほとんど使い切るまでに手を打っておかないといけないことのような気がするが(苦笑)、BDドライブが使えなかったんだから致し方ない!?

ところで、仕立てようとしているPCケースはネジ穴位置が限られているので、鎌平と5"-3.5"変換マウンタを同時に装着するのが難しい。というか一方が固定できない。FSPCのスクリューレスにも往生したが(そんな特殊な物をつけるなということ!?)、いざ引っ越してみるとこっちのケースも手強い。

鎌平とマウンタのネジ穴を重ねて共用すれば解決しそうだが、どっちのネジ穴もバリを作ってくれているので重ねにくい。サイドパネル開けたまま5インチベイを睨んで名案が浮かぶのを待つ(笑)。

2010/08/08 00:43 | カテゴリー：ただの日記, 計算機とか | コメント（0）

BDR-205

山鉾巡行で、山によっては(いわゆる)幕にレプリカを使っていることをTV中継で知ってしまった。本物は町家でずっと飾っているんだって。

いや、まあ山に巻かれているのがあくまでも「本物」と考えるべきかもしれない。

メインPCのBDドライブが急に書けなくなったので(BDREを試すのを思いつくまでに、Rを2枚も没にしてしまった)、現メインPCをFS専用として予備機を常用機にする計画を思いつく。

いくらGF8800GT*SLIほどではないとはいえ、HD5770*CrossFireは、普段使い&スタンバイ+復帰を繰り返す機器としては少々気になる構成である。

幸いなことに? 現メインPCのトラブルの原因を追及する勢いで買っちゃったASUSの790XマザーとPhenomII745があったりするので、それで使うことを前提に、あえてPioneerのベージュを購入。LGがやたら安いのは有名だが、よく見たら今使っていて焼けなくなっているドライブと同じ型番だった(あとで確認したら、実は1桁違いの後継機だった)のでちょっと考え込んだ次第。まあ高価いのには相応の理由がある…と信じたい。それに、白系なら、いざとなれば塗れるから。

あとは(ちゃんと動く)メモリとケースの調達が課題。無期限待機中のMTV2000搭載PCと入れ換える気力があれば。

ちなみに、ドライブが壊れたのではなくOSが悪さをしでかしている可能性もゼロではない、とフォローしておく。実はあらゆる可能性を潰すべくBDドライブクリーナも購入したが、クリーニングには再生が必要とされるそのディスク、HDCPが働いて再生できなかった。今日びHDCP非対応のDVIモニタは、既に滅亡していることになっているようだ。

2010/07/17 20:07 | カテゴリー：Windows, 計算機とか | コメント（0）

clamdのログ

Fedora10でビルドしたclamdだが、先週対策にしたにもかかわらず、やっぱり回ったログの方に引き続き記録されている。

ので、もっと露骨に、prerotateにstop、postrotateにstartのスクリプトを置いた。logrotate.statusのclamdのところの日付を先週日曜に変更して、コマンドからlogrotate /etc/logrotate.d/clamdを実行してみた限りでは、clamd.logの方が更新されているようだ。しかしどうしてcronの時にうまく動いてくれんのか!?

やっぱりclamd自身のログ管理とケンカしているように思われるので、roglotateの方は切っちゃう。clamdの設定では、1MBで切れるようにはなっているが、そうやって落としていった世代をどうするかまでの設定は見当たらない。自動で消していってくれんとしたらあまり意味がないけどなあ(cron.weeklyで消す手はあるけど)。

2010/07/09 22:50 | カテゴリー：Fedora, 計算機とか | コメント（0）

clamdのログ

Fedora10のclamdのログがローテートしない件について。

いや古いclamd.logは日付がついて、新しくclamd.logができることはできるが、その後も日付がついた方が伸びていってclamd.logはサイズゼロのままという現象。手動でclamdをrestartしないと直らない。これでは何のためのcron.dailyなのかわからない。

logrotate -dvをかけてみたところ「1048576バイトより小さいからローテートする必要がない」とか「sharedscripts以下のスクリプトは実行する必要がない」みたいなメッセージが出て、コレや!? と。そのわりにファイル名だけ変えてきているのが妙に中途半端な処理(仕様!?)である。

結局、問題はそれだけにとどまらず、最終的に下記のような内容になった。

/var/log/clamd.log {
    size=0
    missingok
    notifempty
    create 644 clamav clamav
    dateext
    weekly
    rotate 4
    postrotate
    /etc/rc.d/init.d/clamd restart > /dev/null || :
    endscript
}

size=0を書かないとローテートしない。postrotate以下も実行されない。

dateextを書かないと.1～.4の通番になる。

weeklyを書かないと毎日回る。

rotate 4を書かないと、ローテートしない(1世代扱い)。

postrotateでclamdの再起動をしないと、改名したログファイルの方を掴みっぱなし。これはclamdの方にも原因がありそう?

状況的に、どういうわけかclamdのログだけ/etc/logrotate.confの設定が読まれていないとしか思えない。うちのFedora8では、特に何も考えなくても回っているけどねえ。

追記

日曜日にcron.weeklyが動いたけど、結局ダメでした(汗)。ふりだしにもどる。

2010/06/29 23:48 | カテゴリー：Fedora, 計算機とか | コメント（0）

Visio2007 v. Acrobat9Pro

そういえばWindows7に変えてからやったことがなかったので気づかなかったが、Visio2007からPDFmakerが動かせない。正確には、メニューバーのAcrobatのいずれのメニューを選択しても反応がない。Windows7だからダメなのか64ビットだからダメなのか、変なセキュリティソフトのせいなのか!?

少なくともアドビサイトでは、Acrobat9はWindows7で問題なしと言っているが、レイヤを保持してくれないならわざわざ高価なProを使う意味がない(印刷でAdobePDFを選択すれば、PDFを作ることはできるけどレイヤは統合される)。

Visioを修復したりAcrobatを修復したり、管理者で実行したり、Visio2010を検討したり(オイ)、で、結局ふと思いついたのが、VSDファイルを右クリックしてPDFを作成するという方法。何やら変な注釈がついてきて取り除く必要はあるが、一応レイヤは保持してくれる。当面はこれでいくか。

2010/06/23 22:15 | カテゴリー：Windows, 計算機とか | コメント（0）