東京電力の計画停電はまだまだ続くようです。
家庭では停電のために冷蔵庫の心配の他さまざまな苦労に悩まされているようです。企業では事業に大きな影響が出ていることがマスコミでも報道されています。
この計画停電でパソコンもいろいろ問題が発生しているようです。普及率の高いノートパソコンにはバッテリがあるので基本的には問題がないはずです。しかし私の家のあるパソコンのほとんどはバッテリが機能していないため停電となればただちに（今年の流行語大賞候補？）使い物にならなくなってしまいます。このため停電地域の人の中には新品のバッテリを買い求めた人も多いのではないのでしょうか？
運良く直ちに機能停止しなかったノートパソコンをネットにつなごうとすると通信機器がやはり停電のために通信できない状況となっているようです。パソコンは汎用的な使い方ができるものですが今時にはネット無しでは価値が半減または全滅してしまいます。
どうもパソコン本体だけでなく周辺機器も含めてバッテリ駆動が必要のようです。しかし周辺機器にバッテリ駆動をうたうものはほとんどないようです。小さな家庭用発動発電機でも用意しなければならないようです。
今後も計画停電がずっと続くようです。きっと家庭用の発動発電機もきっと売上を伸ばしていると思います。しかし排気ガスや騒音などから発動発電機を使えない家庭も数多く存在すると思います。やはりこのような問題のないバッテリで駆動できる周辺装置が欲しいところです。
私は計画停電が続けば企業も停電に対応した機器の需要を見越して製品化されることを期待しているところです。私の住んでいる地域では計画停電はありませんが、今後私が住んでいる地域でも何らかの発電所での事故によって計画停電が行われる可能性も当然あります。計画停電については決して他人事のように考えていません。
今回の東京電力の計画停電を観察してみると3時間ずつの停電をグループごとに行っているようです。このことから停電に備えるバッテリの持続時間は3時間が一つの目安になるのでしょうか。
このように考えるとパソコン環境だけでなく冷蔵庫などの家電製品も3時間を目安に停電に備えるバッテリがあれば思ってしまいます。
このような計画停電が永遠に続くとは思いませんが、原子力発電所のように一箇所で大きな発電を行うことが今後も行われるのであれば事故により計画停電の危険性は未来永劫に続くものと思われます。
2011年3月30日水曜日
2011年3月29日火曜日
7月の地デジ完全移行は
3月11日の東北大震災からテレビ番組は数日間に渡って特別番組を放送していました。大震災のことも大変気になるところですがだんだんと通常番組へと戻って来ています。しかし戻って来ないものがあります。それは地デジ化の案内です。
私の家ではまだアナログテレビを使用しています。嫌がらせのように画面の上下が黒い帯となり、そして年末年始ごろからは常時地デジ移行の案内が表示されるようになっていました。またテレビ番組の冒頭には画面の片隅に地デジ化のマスコットが表示されて地デジ化の案内をこれでもかとしていました。
このまま地デジ化の案内が過激化してゆくのだろうと思っていましたが地デジ化の案内がぱったりと無くなってしまったのです。一体どうしたのでしょうか？
もしや今年7月の完全移行を断念したのでは？と思って総務省や地デジ化に関係するホームページを確認しましたが予定変更の案内を見つけることができませんでした。
関東地域では東京タワーから東京スカイツリーへ電波塔を切替えるのも来年のことということでアンテナの再調整や共同受信アンテナの受信エリアの変更もあることからもともと今年7月の完全実施が本当のことなのか私自身はかなり疑っていました。
なんとなく今回の大震災のこともあり地デジ完全移行は延期されてしまうのでしょうか？
私の家ではまだアナログテレビを使用しています。嫌がらせのように画面の上下が黒い帯となり、そして年末年始ごろからは常時地デジ移行の案内が表示されるようになっていました。またテレビ番組の冒頭には画面の片隅に地デジ化のマスコットが表示されて地デジ化の案内をこれでもかとしていました。
このまま地デジ化の案内が過激化してゆくのだろうと思っていましたが地デジ化の案内がぱったりと無くなってしまったのです。一体どうしたのでしょうか？
もしや今年7月の完全移行を断念したのでは？と思って総務省や地デジ化に関係するホームページを確認しましたが予定変更の案内を見つけることができませんでした。
関東地域では東京タワーから東京スカイツリーへ電波塔を切替えるのも来年のことということでアンテナの再調整や共同受信アンテナの受信エリアの変更もあることからもともと今年7月の完全実施が本当のことなのか私自身はかなり疑っていました。
なんとなく今回の大震災のこともあり地デジ完全移行は延期されてしまうのでしょうか？
2011年3月26日土曜日
いまさらながら canna をインストール
先日ハードディスクを交換したウェブサーバー（システムは FreeBSD ）には大昔に canna をインストールしてあることを思い出しました。そこで canna-server が生きているのか確認してみました。今でもひっそりと稼働していました。
長い間放置したままでしたが、この cannaserver を活用してデスクトップパソコンとして活用している Debian Lenny や Squeeze の canna を使ってみようと思ったわけです。この共通の cannaserver にどんどん学習させておけばパソコンが異なっていてもいつも同じ学習状況で使えるので便利だと思ったためです。
早速 Debian Lenny や Squeeze へ cannna をインストールしてみました。uim-anthy がもともとインストールされていることもあって uim-canna をインストールしてみました。
インストールには依存関係から uim-canna の他 canna 本体のインストールが自動的に行われました。
インストールが終了しても canna の設定が反映されていない状況でした。そこで一度ログアウトとログインを行ってみました。するとちゃんと uim の設定項目に canna の設定項目が表示されるようになりました。
ここで cannaserver を設定する項目を発見して設定してみることとしました。localhost から webserver へ切替えるために webserver と記述してみました。しかしどうも webserver の cannaserver へ接続していないようでした。どうも設定方法が間違っているようでしたが具体的な設定事例をインターネット上で発見することができなくて困ってしまいました。
しばらく探しても見当たらなかったので外部の cannaserver へ接続することは宿題として後日解決するように努力することとしました。
最初に予定していた cannaserver の接続ができなかったこともあり uim-canna の動作状況を確かめてみることとしました。
kinput2 を使っていたときと違っていて変換の仕方が違っていました。全角スペースなどの変態的な変換（頭に＠を付加する方法）が無くなっていて単純に必要とするキーを押しただけで入力できるようになっていました。意外と便利になっていることに驚きでした。
ただ kinput2 の時のような変換ができないことで困ったことは辞書登録などでした。これもインターネット上の情報を探し回ってようやく発見できました。uim のツールバーで日本語辞書ツールのボタンを追加させた後、この「日本語辞書ツール」ボタンを押して「辞書の編集」画面を出して辞書を編集するようになっていました。辞書は anthy 用と canna 用が独立して存在しているので注意が必要でした。anthy で登録していた文字を次々と cannna の辞書へ登録しました。anthy と canna の辞書を一括して変換してくれるツールが無いようなのでポツリポツリと辞書登録しなければならなかったのが少々辛かったです。
$ ps ax | grep canna
809 ?? Ss 0:00.51 /usr/local/sbin/cannaserver -u bin -inet
長い間放置したままでしたが、この cannaserver を活用してデスクトップパソコンとして活用している Debian Lenny や Squeeze の canna を使ってみようと思ったわけです。この共通の cannaserver にどんどん学習させておけばパソコンが異なっていてもいつも同じ学習状況で使えるので便利だと思ったためです。
早速 Debian Lenny や Squeeze へ cannna をインストールしてみました。uim-anthy がもともとインストールされていることもあって uim-canna をインストールしてみました。
# aptitude install uim-canna
インストールには依存関係から uim-canna の他 canna 本体のインストールが自動的に行われました。
インストールが終了しても canna の設定が反映されていない状況でした。そこで一度ログアウトとログインを行ってみました。するとちゃんと uim の設定項目に canna の設定項目が表示されるようになりました。
ここで cannaserver を設定する項目を発見して設定してみることとしました。localhost から webserver へ切替えるために webserver と記述してみました。しかしどうも webserver の cannaserver へ接続していないようでした。どうも設定方法が間違っているようでしたが具体的な設定事例をインターネット上で発見することができなくて困ってしまいました。
しばらく探しても見当たらなかったので外部の cannaserver へ接続することは宿題として後日解決するように努力することとしました。
最初に予定していた cannaserver の接続ができなかったこともあり uim-canna の動作状況を確かめてみることとしました。
kinput2 を使っていたときと違っていて変換の仕方が違っていました。全角スペースなどの変態的な変換（頭に＠を付加する方法）が無くなっていて単純に必要とするキーを押しただけで入力できるようになっていました。意外と便利になっていることに驚きでした。
ただ kinput2 の時のような変換ができないことで困ったことは辞書登録などでした。これもインターネット上の情報を探し回ってようやく発見できました。uim のツールバーで日本語辞書ツールのボタンを追加させた後、この「日本語辞書ツール」ボタンを押して「辞書の編集」画面を出して辞書を編集するようになっていました。辞書は anthy 用と canna 用が独立して存在しているので注意が必要でした。anthy で登録していた文字を次々と cannna の辞書へ登録しました。anthy と canna の辞書を一括して変換してくれるツールが無いようなのでポツリポツリと辞書登録しなければならなかったのが少々辛かったです。
2011年3月24日木曜日
覚えられないものもスクリプトへ
先日紹介した FreeBSD のハードディスクのコピースクリプト dump & restore がなかなか人気があるようでアクセスが上昇していて少し上機嫌なこのごろです。アクセスどうもありがとうございます。
面倒な作業を便利にするスクリプトですが、今回は少し指向の変わったスクリプトについて紹介します。
今まではコマンドを入力する手間を省いたり、間違え防止のためにスクリプトを作成するというアプローチでした。初老を迎えようとして記憶力が怪しくなっている年頃の私にはとても便利です
今回はこんな記憶力だけではとても覚えられないネットワークの mac アドレスを取り扱ったものです。
さてどんなスクリプトかと言えば停止しているサーバーやパソコンに向かってマジックパケットを送りつけて起動させるものです。このマジックパケットを送り出すソフトウェアは Debian でも標準パッケージの中に用意されているほどポピュラーものですが、このコマンドと一緒に打ち込まなければならない mac アドレスも一緒に記述したスクリプトです。
省エネや環境問題もあり通常稼働させている必要のないサーバー類は wake up on LAN 機能を使って起動させては使用しています。もちろん使用終了とともにシャットダウン（停止）させて省エネを実現しています。
まずこのサーバーやパソコンの wakeup 機能を動作させるマジックパケットを送り出すソフトウェアを事前にインストールしておきます。
Debian Linux の場合 wakeonlan のパッケージをインストールしておきます。
スクリプト紹介
ファイル名：wakeup.server.sh
コマンドに後ろの部分に起動させたいサーバーの mac アドレスを入力します。
ファイル名はパソコンやサーバーの名前を入れた方が解りやすくなるとおもいます。
Debian Linux の場合 通常のユーザーからそのままこのスクリプトを実行できます。自分自身のユーザーディレクトリに ~/bin のディレクトリを作成して その中にこのスクリプトを保存しておくとスクリプト名だけでスクリプトを実行させることができます。
しかし私のように初老だけでなく若者でもインターフェースカードの mac アドレスはそう簡単に覚えていられないものもあります。私のようにいつも休止中のサーバーを複数抱えている人にとってはとても便利なものだと思います。
面倒な作業を便利にするスクリプトですが、今回は少し指向の変わったスクリプトについて紹介します。
今まではコマンドを入力する手間を省いたり、間違え防止のためにスクリプトを作成するというアプローチでした。初老を迎えようとして記憶力が怪しくなっている年頃の私にはとても便利です
今回はこんな記憶力だけではとても覚えられないネットワークの mac アドレスを取り扱ったものです。
さてどんなスクリプトかと言えば停止しているサーバーやパソコンに向かってマジックパケットを送りつけて起動させるものです。このマジックパケットを送り出すソフトウェアは Debian でも標準パッケージの中に用意されているほどポピュラーものですが、このコマンドと一緒に打ち込まなければならない mac アドレスも一緒に記述したスクリプトです。
省エネや環境問題もあり通常稼働させている必要のないサーバー類は wake up on LAN 機能を使って起動させては使用しています。もちろん使用終了とともにシャットダウン（停止）させて省エネを実現しています。
まずこのサーバーやパソコンの wakeup 機能を動作させるマジックパケットを送り出すソフトウェアを事前にインストールしておきます。
Debian Linux の場合 wakeonlan のパッケージをインストールしておきます。
スクリプト紹介
ファイル名：wakeup.server.sh
#!/bin/sh
/usr/bin/wakeonlan 00:10:ab:cd:ef:12
コマンドに後ろの部分に起動させたいサーバーの mac アドレスを入力します。
ファイル名はパソコンやサーバーの名前を入れた方が解りやすくなるとおもいます。
Debian Linux の場合 通常のユーザーからそのままこのスクリプトを実行できます。自分自身のユーザーディレクトリに ~/bin のディレクトリを作成して その中にこのスクリプトを保存しておくとスクリプト名だけでスクリプトを実行させることができます。
スクリプト名の例
wakeup.pc1.sh
wakeup.file-pc.sh
wakeup.http-pc.sh
しかし私のように初老だけでなく若者でもインターフェースカードの mac アドレスはそう簡単に覚えていられないものもあります。私のようにいつも休止中のサーバーを複数抱えている人にとってはとても便利なものだと思います。
2011年3月23日水曜日
Puppy Linux でも日本規格の無線LANへ対応
以前から放置していた Puppy Linux 4.3.1 の無線LANで 1ch から 11ch までしか通信できないという問題をようやく解決出来ました。何だかすっきりした感じです。
さて方法は一つ前の投稿で紹介した Debian Squeeze の無線LANの対策とほぼ同様のものです。確認のために仮想端末上で dmesg の中から cfg80211 の文字列を抽出してみると確かに US 規格となっていました。
ただ Puppy Linux と Debian Squeeze では /etc 以下のファイルの構成が異なっていますのでそれに対応する方法で行いました。
さて具体的には次の通りです。
編集するファイルは /etc/modprobe.conf です。最終行に次の一行を追加します。これは Debian Squeeze と同じものです。
編集が終了したところでシステムを再起動させます。
再起動したところで仮想端末から cfg80211 の設定内容を確認してみます。これで JP の規格に切り替わっていたら一応成功です。
念のために無線LANの設定を行ってみて 12ch か 13ch で通信できれば日本規格へ変更終了となります。この画像は実際に 13ch の無線LANアクセスポイントへ接続を試みようとしている時のものです。
以前の US 規格の時には 12ch や 13ch のアクセスポイントが表示すらされない状況でした。ちゃんと表示されて選択することもできました。
以前から気になっていた部分だけに問題解決が出来てうれしかったです。写真では Puppy Linux 4.3.1 std がインストールされている IBM ThinkPad 235 で確認しましたが、この他 ThinkPad X22 の Puppy Linux 4.3.1 smp でも同様に確認することができました。
さて方法は一つ前の投稿で紹介した Debian Squeeze の無線LANの対策とほぼ同様のものです。確認のために仮想端末上で dmesg の中から cfg80211 の文字列を抽出してみると確かに US 規格となっていました。
# dmesg | grep cfg80211
ただ Puppy Linux と Debian Squeeze では /etc 以下のファイルの構成が異なっていますのでそれに対応する方法で行いました。
さて具体的には次の通りです。
編集するファイルは /etc/modprobe.conf です。最終行に次の一行を追加します。これは Debian Squeeze と同じものです。
options cfg80211 ieee80211_regdom=JP
編集が終了したところでシステムを再起動させます。
再起動したところで仮想端末から cfg80211 の設定内容を確認してみます。これで JP の規格に切り替わっていたら一応成功です。
# dmesg | grep cfg80211
念のために無線LANの設定を行ってみて 12ch か 13ch で通信できれば日本規格へ変更終了となります。この画像は実際に 13ch の無線LANアクセスポイントへ接続を試みようとしている時のものです。
以前の US 規格の時には 12ch や 13ch のアクセスポイントが表示すらされない状況でした。ちゃんと表示されて選択することもできました。
以前から気になっていた部分だけに問題解決が出来てうれしかったです。写真では Puppy Linux 4.3.1 std がインストールされている IBM ThinkPad 235 で確認しましたが、この他 ThinkPad X22 の Puppy Linux 4.3.1 smp でも同様に確認することができました。
2011年3月22日火曜日
Debian Squeeze の無線LANを日本規格へ対応
アップグレードした ThinkPad A30 の Debian Squeeze の無線LAN (Wireless LAN) の日本規格へ対応させることができました。
現在はアメリカやカナダなどの無線LAN規格の 1ch から 11ch までしか対応していませんでした。これを日本の無線LAN規格の 1ch から 14ch までに対応させるものです。これで困っている読者さんは参考にしてみてください。
無線LANの環境が入っているパソコンで Debian Squeeze を立ち上げます。仮想端末で次のコマンドを入力して dmesg から cfg80211 が記述されている部分を抽出してみます。
この cfg80211 の国の識別を日本へ変更します。方法はモジュール・オプションで行います。
/etc/modprobe.d/ の中に options のファイルが存在するか確認します。存在しなければ新しく作ります。
options のファイルの編集が終了したところでパソコンを再起動させます。
パソコンが再起動したところで最初に確認した cfg80211 の設定を仮想端末から確認してみます。
これを見るとちゃんと日本の無線LAN規格に対応していることがわかります。
この後 network manager から無線LANで接続を試みます。私の家では 13ch で設定してありましたが ちゃんと認識して接続することもできました。
Puppy Linux でも同様の現象が発生していましたが同様の方法で対応可能かもしれません。今度確認してみたいと思っています。
これで Debian Squeeze の大きな問題点の一つが解決しました！以前から Puppy Linux でも困っていたモヤモヤだったので晴れ晴れとした感じになりました。
現在はアメリカやカナダなどの無線LAN規格の 1ch から 11ch までしか対応していませんでした。これを日本の無線LAN規格の 1ch から 14ch までに対応させるものです。これで困っている読者さんは参考にしてみてください。
無線LANの環境が入っているパソコンで Debian Squeeze を立ち上げます。仮想端末で次のコマンドを入力して dmesg から cfg80211 が記述されている部分を抽出してみます。
# dmesg | grep cfg80211ご覧のようにアメリカの無線LAN規格となっていることが判明しました。
[ 8.350515] cfg80211: Using static regulatory domain info
[ 8.350523] cfg80211: Regulatory domain: US
[ 8.351213] cfg80211: Calling CRDA for country: US
この cfg80211 の国の識別を日本へ変更します。方法はモジュール・オプションで行います。
/etc/modprobe.d/ の中に options のファイルが存在するか確認します。存在しなければ新しく作ります。
# cd /etc/modprobe.d/この options の中にモジュールオプションを記述します。
# ls options
options のファイルが存在しなければ touch コマンドでファイルを作ります。
# touch options
options cfg80211 ieee80211_regdom=JP
options のファイルの編集が終了したところでパソコンを再起動させます。
パソコンが再起動したところで最初に確認した cfg80211 の設定を仮想端末から確認してみます。
# dmesg | grep cfg80211
[ 9.318618] cfg80211: Using static regulatory domain info
[ 9.318626] cfg80211: Regulatory domain: JP
[ 9.319253] cfg80211: Calling CRDA for country: JP
[ 9.319365] cfg80211: Calling CRDA for country: JP
これを見るとちゃんと日本の無線LAN規格に対応していることがわかります。
この後 network manager から無線LANで接続を試みます。私の家では 13ch で設定してありましたが ちゃんと認識して接続することもできました。
Puppy Linux でも同様の現象が発生していましたが同様の方法で対応可能かもしれません。今度確認してみたいと思っています。
これで Debian Squeeze の大きな問題点の一つが解決しました！以前から Puppy Linux でも困っていたモヤモヤだったので晴れ晴れとした感じになりました。
2011年3月21日月曜日
二台目となる Debian Squeeze へアップグレード
ようやく重い腰をあげて二台目となる Debian Lenny から Squeeze へのアップグレードを行いました。
一台目と基本的に同じ手順で行いました。ここら辺の投稿参照。
前回はデスクトップパソコンでしたが、今回は無線LANなどの様子も観察したかったのでノートパソコンをアップグレードしてみました。具体的には IBM ThinkPad A30 をアップグレードしました。
作業時間は以前作業をしていた様子をブログに掲載していたこともあって順調に進んで2時間半ほどでした。アップグレード中の通信は安定性優先のために有線LANを使用した。
今回のアップグレードで分かったことは Squeeze の完成度が恐ろしく低く、Lenny から Squeeze へ引き上げるには余程の理由がなければ まだアップグレードは避けた方がよいと感じました。
以前の Etch から Lenny の時のように綺麗にすんなりとは行かず、まだまだ数多くの問題点が残されていました。もちろん私が知らないその他の問題も数多く内在していると思います。
[私が気づいた問題点]
1. 今回新しく判明した問題点は無線LANのチャンネル問題でした。以前 Puppy Linux でも体験した12チャンネル以上のチャンネルで通信できない問題が発生していました。アメリカやカナダなどの11チャンネルまでしかない地域の設定になっているようです。私の家のように常時二台の無線LANアクセスポイントが稼働している状況では一つのアクセスポイントを12か13チャンネルあたりに設定せざるをえない状況ではなかなかの難問です。今後早く対策がなされることを期待しています。
2. そしてデスクトップ画面のパネル部分へ追加するアプレットの「CPU周波数計測モニター」が root 権限で動作しないようで、周波数や動作モードの変更を行うときに「CPU周波数を変更する際に必要となる特権です」と表示されて いちいち root のパスワードを入力しなければならない状況となっていました。
Lenny 時代には以下のコマンドで「root 権限で制御する」を選ぶことができましたが現在は設定の画面すらも出ないで単純に無反応のままコマンドが終了してしまいます。ノートパソコンでバッテリーと外部電源アダプターの両方をよく使っている人はこのアプレットで切り替えをしている人も多いと思います。
3. それから私のようにパソコン画面のスナップショットを撮影する人には影響があると思いますが、スナップショットがデスクトップ全体しか撮影することができない状況となっています。必要としない部分までも撮影して gimp で切り抜き加工をしなければならなくなっています。
[改良されていた部分]
しかし悪いことばかりではありません。改良された部分もありました。それは GRUB2 のインストーラーでした。
一台目のアップグレードでは GRUB2 の選択画面には Debian Squeeze のカーネルしか表示されていませんでしたが、今回行ったところハードディスクの内容を検査して Windows XP などそれらしいものを探し出して一覧として表示してありました。とっても賑やかな感じです！
ただなぜか古い GRUB の menu.lst から抽出したものではないようで記述していた BackTrack4 は ubuntu 8.10 と認識されていました。そのため古い GRUB の選択画面でも BackTrack の文字などが消えてなくなっていました。どうも GRUB2 のインストーラーの影響のようです。
その他の改良点としてメーラーの icedove の諸設定がアップグレードが完了した時点で済んでいたことでした。一台目のときにはすべて手動で設定作業を行っていましたので結構楽になりました。
二回目となる Lenny から Squeeze へのアップグレードを体験した感じではまだまだ私の家では本格的に Squeeze へアップグレードすることが出来ないというのが本音です。実用的に使用しているマシンはこのまま Lenny の状態を維持したいと思っています。ぜひとも Lenny のメンテナンスの終了までに何とか Lenny 程度の完成度に引き上げて欲しいところでした。
一台目と基本的に同じ手順で行いました。ここら辺の投稿参照。
前回はデスクトップパソコンでしたが、今回は無線LANなどの様子も観察したかったのでノートパソコンをアップグレードしてみました。具体的には IBM ThinkPad A30 をアップグレードしました。
作業時間は以前作業をしていた様子をブログに掲載していたこともあって順調に進んで2時間半ほどでした。アップグレード中の通信は安定性優先のために有線LANを使用した。
今回のアップグレードで分かったことは Squeeze の完成度が恐ろしく低く、Lenny から Squeeze へ引き上げるには余程の理由がなければ まだアップグレードは避けた方がよいと感じました。
以前の Etch から Lenny の時のように綺麗にすんなりとは行かず、まだまだ数多くの問題点が残されていました。もちろん私が知らないその他の問題も数多く内在していると思います。
[私が気づいた問題点]
1. 今回新しく判明した問題点は無線LANのチャンネル問題でした。以前 Puppy Linux でも体験した12チャンネル以上のチャンネルで通信できない問題が発生していました。アメリカやカナダなどの11チャンネルまでしかない地域の設定になっているようです。私の家のように常時二台の無線LANアクセスポイントが稼働している状況では一つのアクセスポイントを12か13チャンネルあたりに設定せざるをえない状況ではなかなかの難問です。今後早く対策がなされることを期待しています。
2. そしてデスクトップ画面のパネル部分へ追加するアプレットの「CPU周波数計測モニター」が root 権限で動作しないようで、周波数や動作モードの変更を行うときに「CPU周波数を変更する際に必要となる特権です」と表示されて いちいち root のパスワードを入力しなければならない状況となっていました。
Lenny 時代には以下のコマンドで「root 権限で制御する」を選ぶことができましたが現在は設定の画面すらも出ないで単純に無反応のままコマンドが終了してしまいます。ノートパソコンでバッテリーと外部電源アダプターの両方をよく使っている人はこのアプレットで切り替えをしている人も多いと思います。
# dpkg-reconfigure gnome-applets
3. それから私のようにパソコン画面のスナップショットを撮影する人には影響があると思いますが、スナップショットがデスクトップ全体しか撮影することができない状況となっています。必要としない部分までも撮影して gimp で切り抜き加工をしなければならなくなっています。
[改良されていた部分]
しかし悪いことばかりではありません。改良された部分もありました。それは GRUB2 のインストーラーでした。
一台目のアップグレードでは GRUB2 の選択画面には Debian Squeeze のカーネルしか表示されていませんでしたが、今回行ったところハードディスクの内容を検査して Windows XP などそれらしいものを探し出して一覧として表示してありました。とっても賑やかな感じです！
ただなぜか古い GRUB の menu.lst から抽出したものではないようで記述していた BackTrack4 は ubuntu 8.10 と認識されていました。そのため古い GRUB の選択画面でも BackTrack の文字などが消えてなくなっていました。どうも GRUB2 のインストーラーの影響のようです。
その他の改良点としてメーラーの icedove の諸設定がアップグレードが完了した時点で済んでいたことでした。一台目のときにはすべて手動で設定作業を行っていましたので結構楽になりました。
二回目となる Lenny から Squeeze へのアップグレードを体験した感じではまだまだ私の家では本格的に Squeeze へアップグレードすることが出来ないというのが本音です。実用的に使用しているマシンはこのまま Lenny の状態を維持したいと思っています。ぜひとも Lenny のメンテナンスの終了までに何とか Lenny 程度の完成度に引き上げて欲しいところでした。
FreeBSD portversion のスクリプト
前回の portsnap のスクリプトと同様に私がよく使っている portversion のスクリプトを紹介します。
これは portsnap を行ったあと、どれだけの ports で新しい更新があるのか確認するものです。更新のあるものだけが表示されます。
単純に portversion のコマンドにオプションなどを付けたものをスクリプトにしたものですが、よく使うコマンドはこのようにしてスクリプトにして便利に使える事例と思ってください。
使用方法
スーパーユーザー (root) となって使用します。前回の投稿の portsnap.sh のスクリプトを実行した後にこのスクリプトを実行することを前提にしています。
このスクリプトは /root/bin へ保存しておくと どこのディレクトリに居てもこのスクリプトを実行することができます。なお /root/bin が存在しないときには mkdir コマンドでディレクトリを作っておきましょう。
スクリプト紹介
ファイル名：portversion.sh -- root:wheel 700
スクリプトは見てのとおり詳細出力するコマンドオプションを付けた portversion の出力結果に grep 検索をするだけの簡単なものです。
これは portsnap を行ったあと、どれだけの ports で新しい更新があるのか確認するものです。更新のあるものだけが表示されます。
単純に portversion のコマンドにオプションなどを付けたものをスクリプトにしたものですが、よく使うコマンドはこのようにしてスクリプトにして便利に使える事例と思ってください。
使用方法
スーパーユーザー (root) となって使用します。前回の投稿の portsnap.sh のスクリプトを実行した後にこのスクリプトを実行することを前提にしています。
このスクリプトは /root/bin へ保存しておくと どこのディレクトリに居てもこのスクリプトを実行することができます。なお /root/bin が存在しないときには mkdir コマンドでディレクトリを作っておきましょう。
# portversion.sh
スクリプト紹介
ファイル名：portversion.sh -- root:wheel 700
#!/bin/sh
/usr/local/sbin/portversion -v | grep "<"
スクリプトは見てのとおり詳細出力するコマンドオプションを付けた portversion の出力結果に grep 検索をするだけの簡単なものです。
FreeBSD portsnap のスクリプト紹介
また FreeBSD のスクリプトのネタです。
ports のツリーを最新な状態にするための portsnap をスクリプトにまとめて便利にしたものです。ご使用される場合にはよく理解した上でお願い致します。無保証です。
使用方法
スーパーユーザー (root) となって使用します。
このスクリプトは /root/bin へ保存しておくと どこのディレクトリに居てもこのスクリプトを実行することができます。なお /root/bin が存在しないときには mkdir コマンドでディレクトリを作っておきましょう。
スクリプト紹介
ファイル名：portsnap.sh -- root:wheel 700
このスクリプトも単純に複数のコマンドを一つにまとめて便利にしたものです。
なお crontab を使って一日に一回などのように定期的に更新したい場合は下記のスクリプトとなります。crontab は root で実行してください。crontab の編集は crontab -e で行います。crontab の設定や編集方法は man コマンドなどでマニュアルを参照してください。
スクリプト紹介
ファイル名：portsnapcron.sh -- root:wheel 700
ports のツリーを最新な状態にするための portsnap をスクリプトにまとめて便利にしたものです。ご使用される場合にはよく理解した上でお願い致します。無保証です。
使用方法
スーパーユーザー (root) となって使用します。
このスクリプトは /root/bin へ保存しておくと どこのディレクトリに居てもこのスクリプトを実行することができます。なお /root/bin が存在しないときには mkdir コマンドでディレクトリを作っておきましょう。
# /root/bin/portsnap.sh
または
# portsnap.sh
スクリプト紹介
ファイル名：portsnap.sh -- root:wheel 700
#!/bin/sh
/usr/sbin/portsnap fetch
/usr/sbin/portsnap update
/usr/local/sbin/portsdb -Fu
このスクリプトも単純に複数のコマンドを一つにまとめて便利にしたものです。
なお crontab を使って一日に一回などのように定期的に更新したい場合は下記のスクリプトとなります。crontab は root で実行してください。crontab の編集は crontab -e で行います。crontab の設定や編集方法は man コマンドなどでマニュアルを参照してください。
# crontab -e
これは私の設定例です。毎日12時24分に portsnap.sh を実行します。
24 12 * * * /root/bin/portsnap.sh
スクリプト紹介
ファイル名：portsnapcron.sh -- root:wheel 700
#!/bin/sh
/usr/sbin/portsnap cron
/usr/sbin/portsnap update
/usr/local/sbin/portsdb -Fu
2011年3月19日土曜日
dump & restore スクリプト紹介
先日のウェブサーバーで使用した dump & restore のスクリプトを紹介したいと思います。（この辺りの話題です。）
スライス（windows や Linux のパーティションのようなもの）毎に同じ作業の繰り返しなので間違え防止を兼ねて以前からスクリプトを組んで使用していました。私もすでに若くはなく、同じ単純作業を正確に繰り替えして行う能力や気力が消失していますのでスクリプトを活用するのはとても大切なことだと思っています。
このスクリプトは無保証です。ハードディスクをフォーマットするコマンドも含まれていますので設定を間違えるともう後戻りができない状況にもなってしまいます。安易に使用すると大変痛い思いをすると思います。スクリプトの意味が解る人だけが使用してください。
まずこのスクリプトの前提です。
新しいハードディスクは /dev/sd6 と仮定しています。そしてパーティションは第一パーティションと仮定しています。これは事前にハードディスクを FreeBSD のシステム上で整備しておきます。通常の FreeBSD 標準インストールされた状態を仮定しています。なおハードディスクのデバイス名はスクリプトの冒頭部分の変数設定部分で変更することができます。このデバイス名はとても大切なものですので実際にコピー作業を行うマシンの上でコピーされるハードディスクとそのデータを受けるハードディスクを接続して確認をしておいてください。
使い方
シングルユーザーモードで起動させます。
そして /etc/fstab に記述されているデバイスをマウントさせます。
スクリプト紹介
ファイル名：diskdump.sh -- root:wheel 700
このスクリプトは見てのとおり通常仮想端末で打ち込むコマンドを単純に羅列したものです。これがスクリプトの基本的な形だと思っています。人間がいかに楽をするか？利便性の追求こそパソコンの真髄だと思っています。
if 文でスクリプトが分岐している部分がありますが、これはデバイスが存在するかどうかを確認しているだけです。スクリプトも使いつづけるといろいろと問題点が見えてきますのでその部分だけを少しずつ修正してスクリプトを成長させています。
スライス（windows や Linux のパーティションのようなもの）毎に同じ作業の繰り返しなので間違え防止を兼ねて以前からスクリプトを組んで使用していました。私もすでに若くはなく、同じ単純作業を正確に繰り替えして行う能力や気力が消失していますのでスクリプトを活用するのはとても大切なことだと思っています。
このスクリプトは無保証です。ハードディスクをフォーマットするコマンドも含まれていますので設定を間違えるともう後戻りができない状況にもなってしまいます。安易に使用すると大変痛い思いをすると思います。スクリプトの意味が解る人だけが使用してください。
まずこのスクリプトの前提です。
新しいハードディスクは /dev/sd6 と仮定しています。そしてパーティションは第一パーティションと仮定しています。これは事前にハードディスクを FreeBSD のシステム上で整備しておきます。通常の FreeBSD 標準インストールされた状態を仮定しています。なおハードディスクのデバイス名はスクリプトの冒頭部分の変数設定部分で変更することができます。このデバイス名はとても大切なものですので実際にコピー作業を行うマシンの上でコピーされるハードディスクとそのデータを受けるハードディスクを接続して確認をしておいてください。
使い方
シングルユーザーモードで起動させます。
そして /etc/fstab に記述されているデバイスをマウントさせます。
# mount -aそしてこのスクリプトのあるディレクトリへ移動します。スクリプトの実行権限があることを確認します。以下のコマンドを実行させます。後は神様に祈りを捧げてください。一番容量の大きな /usr ( /dev/sd6s1f ) が最後にコピーされます。ここが一番時間が掛かります。800GB で12時間程度掛かりました。
# ./diskdump.sh
スクリプト紹介
ファイル名：diskdump.sh -- root:wheel 700
#! /bin/sh
drv="ad6"
label="s1"
cd /
# / dump & restore
echo "--------------/${drv}${label}a / drive dump & restoe---------------"
if [ -e "/dev/${drv}${label}a" ];
then
newfs /dev/${drv}${label}a
mount /dev/${drv}${label}a /mnt
dump 0af - / | ( cd /mnt ; restore rf - )
umount /mnt
else
echo "drive /${drv}${label}a error"
fi
wait
# /var dump & restore
echo "-------------------/${drv}${label}d /var drive dump & restoe--------------"
if [ -e "/dev/${drv}${label}d" ];
then
newfs -U /dev/${drv}${label}d
mount /dev/${drv}${label}d /mnt
dump 0af - /var | ( cd /mnt ; restore rf - )
umount /mnt
else
echo "drive /${drv}${label}d error"
fi
wait
# /usr dump & restore
echo "-------------------/${drv}${label}f /usr drive dump & restoe--------------"
if [ -e "/dev/${drv}${label}f" ];
then
newfs -U /dev/${drv}${label}f
mount /dev/${drv}${label}f /mnt
dump 0af - /usr | ( cd /mnt ; restore rf - )
umount /mnt
else
echo "drive /${drv}${label}f error"
fi
wait
# /tmp format
echo "-------------------/${drv}${label}e /tmp format---------------------------"
if [ -e "/dev/${drv}${label}e" ];
then
newfs -U /dev/${drv}${label}e
mount /dev/${drv}${label}e /mnt
chmod 1777 /mnt
umount /mnt
else
echo "drive /${drv}${label}e error"
fi
このスクリプトは見てのとおり通常仮想端末で打ち込むコマンドを単純に羅列したものです。これがスクリプトの基本的な形だと思っています。人間がいかに楽をするか？利便性の追求こそパソコンの真髄だと思っています。
if 文でスクリプトが分岐している部分がありますが、これはデバイスが存在するかどうかを確認しているだけです。スクリプトも使いつづけるといろいろと問題点が見えてきますのでその部分だけを少しずつ修正してスクリプトを成長させています。
2011年3月18日金曜日
GRUB から GRUB2 へアップグレード
GRUB2 へ Puppy Linux の項目を追加したついでに二段階ブートローダー状態となっている現状を解消するために GRUB から GRUB2 への本格的なアップグレードを行いました。
方法は GRUB のブートメニューに表示されていることを まんま 行いました。
注意事項の画面が表示されました。了解でそのまま抜けます。
するとどこに GRUB2 をインストールするか？の質問があります。一般的には MBR となる /dev/sda へインストールします。ここの項目でスペースキーを押してアスタリスクマークをつけて次へ進むと自動的にインストールは終了します。
最後に今まで使っていた GRUB の menu.lst を消去するように求める案内が表示されますので、そのまま指示されたコマンドを実行して終了となります。
これで メデタク 二段階ブートローダーの状態を解消することができました。
方法は GRUB のブートメニューに表示されていることを まんま 行いました。
# upgrade-from-grub-legacy上記のコマンドでアップグレードを開始しました。
注意事項の画面が表示されました。了解でそのまま抜けます。
するとどこに GRUB2 をインストールするか？の質問があります。一般的には MBR となる /dev/sda へインストールします。ここの項目でスペースキーを押してアスタリスクマークをつけて次へ進むと自動的にインストールは終了します。
最後に今まで使っていた GRUB の menu.lst を消去するように求める案内が表示されますので、そのまま指示されたコマンドを実行して終了となります。
# rm -f /boot/grub/menu.lst*
これで メデタク 二段階ブートローダーの状態を解消することができました。
GRUB2 へ Puppy Linux を設定
しばらく休止していた Debian Squeeze の設定関係を行ってみました。
今回は GRUB2 です。Debian Lenny から Squeeze へアップグレードしたハードディスクを使って GRUB2 の設定を試みてみました。
現在は GRUB から chanload で GRUB2 を呼び出す二段階仕掛けの状況となっています。
とりあえず二段階の GRUB をそのまま立ち上げて Debian Squeeze を立ち上げます。そして GRUB2 の項目を設定するファイルを編集します。
ディレクトリは /etc/grub.d/ にあります。
ネット上を調べてみると Puppy Linux は 40_custom に設定する人が多いようです。私もこの /etc/grub.d/40_custom へ追加してみることとしました。
Puppy Linux をブートさせるパラメータなどは以前使用していた /boot/grub/menu.lst の内容を流用します。
この Puppy Linux の項目を次のように GRUB2 のコマンドへ書き換えます。rootnoverify->set root , kernel->linux。注意点はハードディスクのパーティション番号です。私もハマりました（笑）
書き換えが終了したところで GRUB2 のメニュー画面へ反映させるために次のコマンドを実行しておきます。
これでパソコンを再起動して GRUB2 のメニュー画面から Puppy Linux を起動させて動作することを確認して終了となります。
今回は GRUB2 です。Debian Lenny から Squeeze へアップグレードしたハードディスクを使って GRUB2 の設定を試みてみました。
現在は GRUB から chanload で GRUB2 を呼び出す二段階仕掛けの状況となっています。
とりあえず二段階の GRUB をそのまま立ち上げて Debian Squeeze を立ち上げます。そして GRUB2 の項目を設定するファイルを編集します。
ディレクトリは /etc/grub.d/ にあります。
ネット上を調べてみると Puppy Linux は 40_custom に設定する人が多いようです。私もこの /etc/grub.d/40_custom へ追加してみることとしました。
Puppy Linux をブートさせるパラメータなどは以前使用していた /boot/grub/menu.lst の内容を流用します。
title Puppy Linux 431 frugal
rootnoverify (hd0,0)
kernel /puppy431/vmlinuz pmedia=atahd psubdir=puppy431
initrd /puppy431/initrd.gz
title Puppy Linux 431 retro frugal
rootnoverify (hd0,0)
kernel /puppy431retro/vmlinuz pmedia=idehd psubdir=puppy431retro
initrd /puppy431retro/initrd.gz
title Puppy Linux 511 frugal in sda1 dir puppy511
rootnoverify (hd0,0)
kernel /puppy511/vmlinuz pmedia=atahd psubdir=puppy511
initrd /puppy511/initrd.gz
この Puppy Linux の項目を次のように GRUB2 のコマンドへ書き換えます。rootnoverify->set root , kernel->linux。注意点はハードディスクのパーティション番号です。私もハマりました（笑）
menuentry "Puppy Linux 431 frugal" {
set root=(hd0,1)
linux /puppy431/vmlinuz pmedia=atahd psubdir=puppy431
initrd /puppy431/initrd.gz
}
menuentry "Puppy Linux 431 retro frugal" {
set root=(hd0,1)
linux /puppy431retro/vmlinuz pmedia=idehd psubdir=puppy431retro
initrd /puppy431retro/initrd.gz
}
menuentry "Puppy Linux 511 frugal in sda1 dir puppy511" {
set root=(hd0,1)
linux /puppy511/vmlinuz pmedia=atahd psubdir=puppy511
initrd /puppy511/initrd.gz
}
書き換えが終了したところで GRUB2 のメニュー画面へ反映させるために次のコマンドを実行しておきます。
# update-grub
これでパソコンを再起動して GRUB2 のメニュー画面から Puppy Linux を起動させて動作することを確認して終了となります。
2011年3月17日木曜日
ファイルサーバーへハードディスク追加
3月6日に HP dc7600US へウェブサーバーを変更したとき一緒に交換したハードディスクが残っていました。
すでに10日を経過して順調にウェブサーバーが動いていることから、この交換したハードディスクを再利用することとしました。
以前からファイルサーバーの容量が残っていなかったのでこの再利用のハードディスクを追加することとしました。
いつも使用するメンテナンス用のパソコンへ接続して初期設定をしてファイルサーバーへ追加することとしました。
まず最初は HGST FitnessTest で簡単にテストをした後、ディスク消去を行ってみました。
まず最初に真っ赤な画面で警告文章が二度現れてどちらも YES で答えてようやくディスク消去画面へとたどり着きました。
ここで消去スタートさせて放置しておきました。4時間ほど放置していましたが終了しておらず、このまま継続するのも面倒だったので中断することとしました。
この後 GParted を使ってハードディスク全体を領域確保して ext3 でフォーマットしました。1TB もあるとフォーマットするのに4分36秒ほど掛かっていました。今後どんどんハードディスクの容量が増加するごとにこのようなフォーマットやファイルチェックの時間が掛かってしまうようです。
いよいよファイルサーバーへハードディスクを追加します。写真の IBM IntelliStation M Pro をファイルサーバーとして使用しています。比較的最近掃除をしたばかりのマシンなので中を開いてもまだホコリが溜まっている状況ではありませんでした。気持ちよく作業出来そうでした。
仮に接続していた 40GB のハードディスクを取り外してそこへ 1TB のハードディスクを取り付けました。すでにガードレールもウェブサーバーのハードディスクとして使用していたときに取り付けてあったのでそのまま差し替えるだけでした。
最初に立ち上げると追加したハードディスクの fsck から始まりました。ここで20分程度立ち上がるまで待たされることとなりました。そこですでに設置してあるハードディスクと同様に fsck を実行しない設定をしておきました。ファイルチェックが必要な時には手動で fsck を実行すればよいだけですから。
追加したハードディスクは /dev/sdb1 ですので以下の設定で行いました。
# tune2fs -i 0 -c 0 /dev/sda1
なお現在の設定状況を確認するには次のコマンドで確認できます。
# tune2fs -l /dev/sda1
すでに samba の設定を swap で行っており、自動的にマウントされて自動的に LAN 内に公開されていました。
ファイルの転送が問題なく出来ることを確認して作業を終了しました。
昨年夏に途中で中断していた CD-R に保存していた写真ファイルをこれで思う存分保存することができそうです。
すでに10日を経過して順調にウェブサーバーが動いていることから、この交換したハードディスクを再利用することとしました。
以前からファイルサーバーの容量が残っていなかったのでこの再利用のハードディスクを追加することとしました。
いつも使用するメンテナンス用のパソコンへ接続して初期設定をしてファイルサーバーへ追加することとしました。
まず最初は HGST FitnessTest で簡単にテストをした後、ディスク消去を行ってみました。
まず最初に真っ赤な画面で警告文章が二度現れてどちらも YES で答えてようやくディスク消去画面へとたどり着きました。
ここで消去スタートさせて放置しておきました。4時間ほど放置していましたが終了しておらず、このまま継続するのも面倒だったので中断することとしました。
この後 GParted を使ってハードディスク全体を領域確保して ext3 でフォーマットしました。1TB もあるとフォーマットするのに4分36秒ほど掛かっていました。今後どんどんハードディスクの容量が増加するごとにこのようなフォーマットやファイルチェックの時間が掛かってしまうようです。
いよいよファイルサーバーへハードディスクを追加します。写真の IBM IntelliStation M Pro をファイルサーバーとして使用しています。比較的最近掃除をしたばかりのマシンなので中を開いてもまだホコリが溜まっている状況ではありませんでした。気持ちよく作業出来そうでした。
仮に接続していた 40GB のハードディスクを取り外してそこへ 1TB のハードディスクを取り付けました。すでにガードレールもウェブサーバーのハードディスクとして使用していたときに取り付けてあったのでそのまま差し替えるだけでした。
最初に立ち上げると追加したハードディスクの fsck から始まりました。ここで20分程度立ち上がるまで待たされることとなりました。そこですでに設置してあるハードディスクと同様に fsck を実行しない設定をしておきました。ファイルチェックが必要な時には手動で fsck を実行すればよいだけですから。
追加したハードディスクは /dev/sdb1 ですので以下の設定で行いました。
# tune2fs -i 0 -c 0 /dev/sda1
なお現在の設定状況を確認するには次のコマンドで確認できます。
# tune2fs -l /dev/sda1
すでに samba の設定を swap で行っており、自動的にマウントされて自動的に LAN 内に公開されていました。
ファイルの転送が問題なく出来ることを確認して作業を終了しました。
昨年夏に途中で中断していた CD-R に保存していた写真ファイルをこれで思う存分保存することができそうです。
2011年3月11日金曜日
FLORA 330W (PC-XDG7) の電解コンデンサ移設
2月上旬に入手していた FLORA 330W (PC-XDG7) の話題です。
あの灼熱のヒートシンクの脇にある電解コンデンサを移設してみました。
ヒートシンクの脇にあった電解コンデンサは入手時にパンクしていましたが新しい電解コンデンサを取り付けて快調に動作していました。しかし指で触ることが困難なほど熱くなるヒートシンクの近くにあることから この熱で電解コンデンサが炙られてパンクしたものと想像しています。
そこで早くこの熱いヒートシンクから電解コンデンサを遠ざけたかったのです。ようやく重い腰をあげて作業をしてみました。
まず最初にパソコンの分解からです。以前掃除と電解コンデンサの修理のために分解していたので大体の要領は掴んでいたので比較的早く分解することはできました。マザーボードを引き出すには電源ユニットを一度取り外さなければならないのが少し手間でした。
これがマザーボードの様子です。プロセッサのヒートシンクやファンはそのまま取り付けたままの状態で作業を行いました。
さて問題の電解コンデンサを 100W のはんだごてを使って素早く取り除きました。そして電解コンデンサを取り除いたランド部分へリード線を差し込んでハンダ付けを行いました。写真は二本のリード線を取り付けた状態の様子です。このリード線の先に電解コンデンサを取り付けて熱いヒートシンクの熱を避けようという計画です。
これはリード線の先に電解コンデンサを取り付けたところです。写真のように大型の IC の上に退避させました。ほんのり暖かくなる程度の温度しかない IC ですのでこの場所が最適のようです。
この状態でパソコンを再度組み立て直しました。電解コンデンサがマザーボードに取り付けるケーブル類と干渉しないことを確認したところで電源を投入してみました。
何だか様子が変です。ディスプレイの画面に筋状のノイズが大量に発生しています。これは入手当初に電解コンデンサがパンクしていたときと同様の症状でした。どうもリード線で足の部分を引き延ばしことが悪影響したようです。どうもこの方法では電解コンデンサの熱対策は出来てもノイズ対策は出来ないようでした。
そこで延長したリード線ではなく新しい新品の電解コンデンサを使って長い足を折り曲げ加工をして取り付けてみることとしました。様子が多少改善されるかもしれません。
再びパソコンを分解してマザーボードを取り出してハンダ付け作業を行いました。写真のように電解コンデンサの足を折り曲げた部分を無事ハンダ付けしました。
再びパソコンを組み立てて電源を投入してみました。残念ながら前回のリード線の時と同様の激しい筋状のノイズが発生していました。
今回は結構しっかりした形で電解コンデンサが固定されていることもあってノイズの発生原因を探ってみました。直接指を電解コンデンサに当ててみたり、ピンセットを使ってリード線を触ってみました。どうもここを触れてもノイズの状況は大きく変わりませんでした。何気なくヒートシンクを触ると激しくノイズが発生するようです。どうもノイズの原因はヒートシンクに繋がった三端子レギュレータのようです。
もっとノイズ除去のために電解コンデンサの容量を増やすべきなのでしょうか？ここでこの電解コンデンサの足がむき出しになっていることから電圧を測ってみました。グランドからおよそ 2V という結果でした。それもプラス極とマイナス極の電位差がゼロという結果です。一体どうしたのでしょうか？てっきり 3.3V 三端子レギュレータの出力を安定させるために設けられているものだと思っていたのが全然別の目的のものだったようです。
これほど大きな電解コンデンサが GND にも 3.3V Vcc にも繋がっていない理由がよくわかりませんでした。もしかすると電源投入時に一定時間遅らせて 3.3V 電源を立ち上げるような設計が行われていて、この電解コンデンサがその電源立ち上がりを遅らせる時定数を稼いでいるのでしょうか？
そうすると以前パンクした電解コンデンサを取り替えてノイズが減少したことは一体どうしたのでしょうか？もしかして三端子レギュレータのすぐ近くにあったこともあり、この電解コンデンサ（それも元にあったものから大型化しているものを使用）がノイズを輻射する三端子レギュレータのシールド板のような働きをしていたのでしょうか？
ともあれこれでは激しいノイズに対処することができません。三端子レギュレータやヒートシンクから輻射されるノイズの対策を考えてみることとしました。
取り合えずノイズがどのように変化するのか手持ちであったマイラーフィルムコンデンサを使ってヒートシンクと各部を接触させては様子を観察してみました。写真はその時の様子です。これでノイズをバイパスすることが出来ればノイズは減少するはずです。
いろいろと実験していると どうもヒートシンクと問題の電解コンデンサのマイナス極を接触させると効果的にノイズが減少するようです。さらに先ほど使用していたリード線付きの電解コンデンサを使ってみるとより効果が高いようです。以前パンクした電解コンデンサを交換した直後よりも全然綺麗な状況まで改善するようです。
ただあまり大きな容量の電解コンデンサを使用するのは少し危険な面もあるようでヒートシンクとシャーシのGND を接触させると何か大きなノイズが瞬間的に乗ってしまうためかパソコンがハングアップしてしまい操作を受け付けず、ディスプレイの画面の表示も乱れてしまいます。単なる三端子レギュレータではないようにも思われる感じでした。
取り合えずシャーシアースへバイパスするのを諦めて、先ほど状況の良かった電解コンデンサの足の部分へ追加で電解コンデンサを取り付けてしばらく様子を観察することとしました。写真はヒートシンクと電解コンデンサの足へリード線付きの電解コンデンサを取り付けた様子です。ヒートシンクはアルミ製のためハンダ付けが出来ないのでラグ板を経由してネジ留めとしました。
一時間ほど様子をみた後、入手したとき以来使用してこなかった蓋を取り付けてみました。これで本来の姿にようやく戻ることができました。
あの灼熱のヒートシンクの脇にある電解コンデンサを移設してみました。
ヒートシンクの脇にあった電解コンデンサは入手時にパンクしていましたが新しい電解コンデンサを取り付けて快調に動作していました。しかし指で触ることが困難なほど熱くなるヒートシンクの近くにあることから この熱で電解コンデンサが炙られてパンクしたものと想像しています。
そこで早くこの熱いヒートシンクから電解コンデンサを遠ざけたかったのです。ようやく重い腰をあげて作業をしてみました。
まず最初にパソコンの分解からです。以前掃除と電解コンデンサの修理のために分解していたので大体の要領は掴んでいたので比較的早く分解することはできました。マザーボードを引き出すには電源ユニットを一度取り外さなければならないのが少し手間でした。
これがマザーボードの様子です。プロセッサのヒートシンクやファンはそのまま取り付けたままの状態で作業を行いました。
さて問題の電解コンデンサを 100W のはんだごてを使って素早く取り除きました。そして電解コンデンサを取り除いたランド部分へリード線を差し込んでハンダ付けを行いました。写真は二本のリード線を取り付けた状態の様子です。このリード線の先に電解コンデンサを取り付けて熱いヒートシンクの熱を避けようという計画です。
これはリード線の先に電解コンデンサを取り付けたところです。写真のように大型の IC の上に退避させました。ほんのり暖かくなる程度の温度しかない IC ですのでこの場所が最適のようです。
この状態でパソコンを再度組み立て直しました。電解コンデンサがマザーボードに取り付けるケーブル類と干渉しないことを確認したところで電源を投入してみました。
何だか様子が変です。ディスプレイの画面に筋状のノイズが大量に発生しています。これは入手当初に電解コンデンサがパンクしていたときと同様の症状でした。どうもリード線で足の部分を引き延ばしことが悪影響したようです。どうもこの方法では電解コンデンサの熱対策は出来てもノイズ対策は出来ないようでした。
そこで延長したリード線ではなく新しい新品の電解コンデンサを使って長い足を折り曲げ加工をして取り付けてみることとしました。様子が多少改善されるかもしれません。
再びパソコンを分解してマザーボードを取り出してハンダ付け作業を行いました。写真のように電解コンデンサの足を折り曲げた部分を無事ハンダ付けしました。
再びパソコンを組み立てて電源を投入してみました。残念ながら前回のリード線の時と同様の激しい筋状のノイズが発生していました。
今回は結構しっかりした形で電解コンデンサが固定されていることもあってノイズの発生原因を探ってみました。直接指を電解コンデンサに当ててみたり、ピンセットを使ってリード線を触ってみました。どうもここを触れてもノイズの状況は大きく変わりませんでした。何気なくヒートシンクを触ると激しくノイズが発生するようです。どうもノイズの原因はヒートシンクに繋がった三端子レギュレータのようです。
もっとノイズ除去のために電解コンデンサの容量を増やすべきなのでしょうか？ここでこの電解コンデンサの足がむき出しになっていることから電圧を測ってみました。グランドからおよそ 2V という結果でした。それもプラス極とマイナス極の電位差がゼロという結果です。一体どうしたのでしょうか？てっきり 3.3V 三端子レギュレータの出力を安定させるために設けられているものだと思っていたのが全然別の目的のものだったようです。
これほど大きな電解コンデンサが GND にも 3.3V Vcc にも繋がっていない理由がよくわかりませんでした。もしかすると電源投入時に一定時間遅らせて 3.3V 電源を立ち上げるような設計が行われていて、この電解コンデンサがその電源立ち上がりを遅らせる時定数を稼いでいるのでしょうか？
そうすると以前パンクした電解コンデンサを取り替えてノイズが減少したことは一体どうしたのでしょうか？もしかして三端子レギュレータのすぐ近くにあったこともあり、この電解コンデンサ（それも元にあったものから大型化しているものを使用）がノイズを輻射する三端子レギュレータのシールド板のような働きをしていたのでしょうか？
ともあれこれでは激しいノイズに対処することができません。三端子レギュレータやヒートシンクから輻射されるノイズの対策を考えてみることとしました。
取り合えずノイズがどのように変化するのか手持ちであったマイラーフィルムコンデンサを使ってヒートシンクと各部を接触させては様子を観察してみました。写真はその時の様子です。これでノイズをバイパスすることが出来ればノイズは減少するはずです。
いろいろと実験していると どうもヒートシンクと問題の電解コンデンサのマイナス極を接触させると効果的にノイズが減少するようです。さらに先ほど使用していたリード線付きの電解コンデンサを使ってみるとより効果が高いようです。以前パンクした電解コンデンサを交換した直後よりも全然綺麗な状況まで改善するようです。
ただあまり大きな容量の電解コンデンサを使用するのは少し危険な面もあるようでヒートシンクとシャーシのGND を接触させると何か大きなノイズが瞬間的に乗ってしまうためかパソコンがハングアップしてしまい操作を受け付けず、ディスプレイの画面の表示も乱れてしまいます。単なる三端子レギュレータではないようにも思われる感じでした。
取り合えずシャーシアースへバイパスするのを諦めて、先ほど状況の良かった電解コンデンサの足の部分へ追加で電解コンデンサを取り付けてしばらく様子を観察することとしました。写真はヒートシンクと電解コンデンサの足へリード線付きの電解コンデンサを取り付けた様子です。ヒートシンクはアルミ製のためハンダ付けが出来ないのでラグ板を経由してネジ留めとしました。
一時間ほど様子をみた後、入手したとき以来使用してこなかった蓋を取り付けてみました。これで本来の姿にようやく戻ることができました。
2011年3月10日木曜日
慣れの怖さ
先日バッテリの充電を行った ThinkPad 235 をしばらく触ってみました。
頻繁に触っているときにはこんなものと諦めながら嬉々として操作していたものです。
しかしもう我慢ならないほど遅いと感じてしまいます。動作速度が変わっているとは思われず、自分の感覚が変わっているのが原因だと思います。
使っている Puppy Linux の動作条件としてこの ThinkPad 235 (MMX 233MHz men=160MB) より遅い MMX 166MHz men=128MB となっていました。この最低条件で動作させたら一体どうなるのか逆に興味が沸いてくるところですが、笑い話としては楽しそうですが実際に試して見ようとは思いませんでした（笑）。
人間は楽で便利なものを手に入れるとそれが基準となってしまうことはパソコンも変わらないようです。
なんと遅いのでしょう！
頻繁に触っているときにはこんなものと諦めながら嬉々として操作していたものです。
しかしもう我慢ならないほど遅いと感じてしまいます。動作速度が変わっているとは思われず、自分の感覚が変わっているのが原因だと思います。
使っている Puppy Linux の動作条件としてこの ThinkPad 235 (MMX 233MHz men=160MB) より遅い MMX 166MHz men=128MB となっていました。この最低条件で動作させたら一体どうなるのか逆に興味が沸いてくるところですが、笑い話としては楽しそうですが実際に試して見ようとは思いませんでした（笑）。
人間は楽で便利なものを手に入れるとそれが基準となってしまうことはパソコンも変わらないようです。
グーグル定期便 2011年3月号
また届きました。
内容は今までとほとんど一緒のものでした。
前回から名称が変わっていた無料クーポン券がやはり名称変更となっていました。
「無料お試し券」でした。やはりイメージ急降下中のクーポンを使わないところが世間の空気を読んでいる証拠だと思っています。さすがグーグルです。
そろそろ新しい試みをはじめるのではないかと期待しながら次号を楽しみにしています。
内容は今までとほとんど一緒のものでした。
前回から名称が変わっていた無料クーポン券がやはり名称変更となっていました。
「無料お試し券」でした。やはりイメージ急降下中のクーポンを使わないところが世間の空気を読んでいる証拠だと思っています。さすがグーグルです。
そろそろ新しい試みをはじめるのではないかと期待しながら次号を楽しみにしています。
2011年3月9日水曜日
ThinkPad 235 のキーを直しました
ThinkPad 235 のパンタグラフと一緒に外れてしまった右シフトキーをようやく直すことができました！
次のページを参考にしました。貴重な情報どうもありがとうございます。
（参考URL）キーボードのキーを修理
まず最初に判明したことはキートップにパンタグラフが付いた状態では復旧できないことでした。そこでそっとパンタグラフをキートップから取り外しました。柔軟性のあるプラスチックのようですが壊れたら一巻の終わりですから注意して外しました。
この取り外したパンタグラフを本体側へ取り付けました。このときキートップにパンタグラフが取り付いていた状態を参考にして本体側へ取り付けをしました。具体的にはパンタグラフの Enter キー側を Enter キー側からスライドさせるようにして差し込んだ後、パンタグラフの矢印の部分をパチンとはめ込みました。
パンタグラフを本体側に取り付けた状態でパンタグラフの上部を押し込むとちゃんと反発をして押し返してくれました。ラバードームの高さが極端に低かったのでもしかして必要な部品を掃除機に吸い込んでしまっていたかも？と思っていましたが無事だったようです。
次にキートップの取り付けです。最初にコの字型の金属棒（ステー）の先端を差し込み口に形成されている部分から差し込みました。
キートップの内側にある Enter キー側の差し込み口へパンタグラフの先端をスライドさせながらはめ込みます。写真のように傾斜した形で止まります。
そしていよいよキートップの固定です。ゆっくりと手前の浮き上がった部分を押し込んでキートップの内側にある爪とパンタグラフの丸棒の形状に形成された部分をパチンとはめ込みます。注意したことは前後左右のキーの位置を参考にしながら所定の位置を推測しながら行いました。まだキートップが固定されていない状態だと前後左右に意外と動きますから。
これで右シフトキーを修復することが出来てほっとしました！
次のページを参考にしました。貴重な情報どうもありがとうございます。
（参考URL）キーボードのキーを修理
まず最初に判明したことはキートップにパンタグラフが付いた状態では復旧できないことでした。そこでそっとパンタグラフをキートップから取り外しました。柔軟性のあるプラスチックのようですが壊れたら一巻の終わりですから注意して外しました。
この取り外したパンタグラフを本体側へ取り付けました。このときキートップにパンタグラフが取り付いていた状態を参考にして本体側へ取り付けをしました。具体的にはパンタグラフの Enter キー側を Enter キー側からスライドさせるようにして差し込んだ後、パンタグラフの矢印の部分をパチンとはめ込みました。
パンタグラフを本体側に取り付けた状態でパンタグラフの上部を押し込むとちゃんと反発をして押し返してくれました。ラバードームの高さが極端に低かったのでもしかして必要な部品を掃除機に吸い込んでしまっていたかも？と思っていましたが無事だったようです。
次にキートップの取り付けです。最初にコの字型の金属棒（ステー）の先端を差し込み口に形成されている部分から差し込みました。
キートップの内側にある Enter キー側の差し込み口へパンタグラフの先端をスライドさせながらはめ込みます。写真のように傾斜した形で止まります。
そしていよいよキートップの固定です。ゆっくりと手前の浮き上がった部分を押し込んでキートップの内側にある爪とパンタグラフの丸棒の形状に形成された部分をパチンとはめ込みます。注意したことは前後左右のキーの位置を参考にしながら所定の位置を推測しながら行いました。まだキートップが固定されていない状態だと前後左右に意外と動きますから。
これで右シフトキーを修復することが出来てほっとしました！
2011年3月8日火曜日
再び ごめんなさい ThinkPad 235
昨日バッテリの消耗に気づかなかった ThinkPad 235 ですが、久しぶりに触ったついでに掃除をすることとしました。
掃除機のホースの先端に先が縦長に細くなった管？を取り付けてキーボードの隙間に溜まったホコリを気持ちよく吸い取っていました。
悲劇はこのとき発生しました！
なんと右シフトキーが掃除機の吸引力で外れてしまいました！！
一瞬何が発生したのか理解できませんでした（涙）。
掃除機を使っていたときのことですのでもしかすると部品の一部が掃除機の中に入ってしまったかもしれません。
取りあえずキーを取り付けてみようと思ったのですが全然取り付けられません。大きめのキーにある特有のコの字型の金属の棒があるためかキーの底にあるパンタグラフが必要な場所へ設置できないのです。何か上手い方法（技）があるのかもしれません。
小さなプラスチック部品でもあるので無理やり力を入れてというわけもゆきません。
どこかネットにキーの装着方法がないか探しています。
しかしこの ThinkPad 235 君には放置した挙句にキー破壊という仕打ちをしてしまって申し訳なく思っています。ごめんなさい！
掃除機のホースの先端に先が縦長に細くなった管？を取り付けてキーボードの隙間に溜まったホコリを気持ちよく吸い取っていました。
悲劇はこのとき発生しました！
なんと右シフトキーが掃除機の吸引力で外れてしまいました！！
一瞬何が発生したのか理解できませんでした（涙）。
掃除機を使っていたときのことですのでもしかすると部品の一部が掃除機の中に入ってしまったかもしれません。
取りあえずキーを取り付けてみようと思ったのですが全然取り付けられません。大きめのキーにある特有のコの字型の金属の棒があるためかキーの底にあるパンタグラフが必要な場所へ設置できないのです。何か上手い方法（技）があるのかもしれません。
小さなプラスチック部品でもあるので無理やり力を入れてというわけもゆきません。
どこかネットにキーの装着方法がないか探しています。
しかしこの ThinkPad 235 君には放置した挙句にキー破壊という仕打ちをしてしまって申し訳なく思っています。ごめんなさい！
ごめんね！ ThinkPad 235 & 535X
ついうっかりしていました。最近いろいろと忙しかったもので old ThinkPad をかまってあげられなくてバッテリがすっかり消耗したままとなっていました（涙）。
この二台の ThinkPad は棚の中の目につく場所に置いてはいたのですが。。。
電源スイッチを入れても反応がありませんでした。いつもであればバッテリの消耗を知らせる警告音が鳴るのですが今回はそれすらもありませんでした。
ACアダプタを接続して二台の ThinkPad へ充電を開始しました。何だかふてくされたようにすぐに充電の LED さえも点灯せずしばらく経って点灯していました。
ごめんなさい！ と思わず声が出てしまいました。
バッテリの充電表示もゼロとなっていて明るい緑色の部分がない何とも暗い表示になっていました。ああ！ごめんなさい。
2011年3月7日月曜日
HP dc7600US の実力は
昨日からウェブサーバーとして稼働を開始した HP dc7600US ですが、以前のマシンからどの程度性能が向上したかを調べてみました。
簡単な方法で調べてみました。buildworld と buildkernel を実行して以前のサーバーと比較してみました。実行時間の計測は time コマンドを使用しました。
IBM IntellStation M Pro
--Pentium 4 (northwood) 2.2GHz memory(RD-RAM)=1,520MB
make buildworld 1:51:22
make buildkernel 30:30
HP dc7600US
--Celeron (prescott) 2.8GHz memory(DDR2)=512MB
make buildworld 1:46:13
make buildkernel 29:36
若干ビルドに掛かる時間が少なくなっていますが大きく向上した感じではありませんでした。world の方は5分程度の短縮ですが、kernel にいたっては1分たらずでした。もうちょっと性能が向上しているものと思っていただけにがっかりでした。メモリが少なすぎるのでしょうか。
意外と古いマシンが頑張っていることに今更ながら感心しました（笑）。
簡単な方法で調べてみました。buildworld と buildkernel を実行して以前のサーバーと比較してみました。実行時間の計測は time コマンドを使用しました。
IBM IntellStation M Pro
--Pentium 4 (northwood) 2.2GHz memory(RD-RAM)=1,520MB
make buildworld 1:51:22
make buildkernel 30:30
HP dc7600US
--Celeron (prescott) 2.8GHz memory(DDR2)=512MB
make buildworld 1:46:13
make buildkernel 29:36
若干ビルドに掛かる時間が少なくなっていますが大きく向上した感じではありませんでした。world の方は5分程度の短縮ですが、kernel にいたっては1分たらずでした。もうちょっと性能が向上しているものと思っていただけにがっかりでした。メモリが少なすぎるのでしょうか。
意外と古いマシンが頑張っていることに今更ながら感心しました（笑）。
2011年3月6日日曜日
ウェブサーバーとして dc7600US を使用
昨晩いろいろ悩んで HP dc7600US をしばらくウェブサーバーとして使用してみることとしました。
システムのコピーが終了した 2TB のハードディスクを dc7600US へ取り付けました。
そして BIOS を確認してハードディスクが認識されていることとドライブの起動順番を確認しておきました。
いよいよ電源を入れて起動の様子を確認してみました。問題なく起動してくれました。
このマシンでも SATA ハードディスクのドライブ名は ad4 から名前が始まるようです。このドライブ名が変わってしまうと /etc/fstab の内容も変更しなければならなかったところでした。
そして入手当初から気にしていたコイルの鳴きのような現象もしっかり発生していました。特に起動途中は激しく音が鳴り響く感じです。
しばらく動作確認をしたところで今までウェブサーバーが置かれていた場所でこの新しいウェブサーバーを設置してみました。写真は設置場所の様子です。旧式のレーザープリンタへ繋がるセントロニクスのケーブルが見えます。dc7600US にはセントロニクスのソケットがないのでどうしたものかと考えています。レーザープリンタには RS232C のソケットもあったはずなので RS232C で接続する方法も考えられます。
縦置きにしたかったのですが縦置き用のスタンドがないため横置きとしました。この dc7600US の上にルーターとして稼働中の IBM NetVista M41 Slim を積み重ねてみました。なかなかコンパクトな感じで収まっています。
ケーブルの様子を確認した上で現在ある場所から高い場所へと移設しようと考えています。そうすれば写真の棚の部分が空いてすっきりすると思っています。
システムのコピーが終了した 2TB のハードディスクを dc7600US へ取り付けました。
そして BIOS を確認してハードディスクが認識されていることとドライブの起動順番を確認しておきました。
いよいよ電源を入れて起動の様子を確認してみました。問題なく起動してくれました。
このマシンでも SATA ハードディスクのドライブ名は ad4 から名前が始まるようです。このドライブ名が変わってしまうと /etc/fstab の内容も変更しなければならなかったところでした。
そして入手当初から気にしていたコイルの鳴きのような現象もしっかり発生していました。特に起動途中は激しく音が鳴り響く感じです。
しばらく動作確認をしたところで今までウェブサーバーが置かれていた場所でこの新しいウェブサーバーを設置してみました。写真は設置場所の様子です。旧式のレーザープリンタへ繋がるセントロニクスのケーブルが見えます。dc7600US にはセントロニクスのソケットがないのでどうしたものかと考えています。レーザープリンタには RS232C のソケットもあったはずなので RS232C で接続する方法も考えられます。
縦置きにしたかったのですが縦置き用のスタンドがないため横置きとしました。この dc7600US の上にルーターとして稼働中の IBM NetVista M41 Slim を積み重ねてみました。なかなかコンパクトな感じで収まっています。
ケーブルの様子を確認した上で現在ある場所から高い場所へと移設しようと考えています。そうすれば写真の棚の部分が空いてすっきりすると思っています。
ハードディスクのコピー作業
ウェブサーバーのハードディスクのコピーを行いました。
深夜になって仕事を全て済ませてから作業を開始しました。
まず最初に現在使用しているハードディスクを IBM IntellStation M Pro から取り出しました。昨年8月から8ヶ月ほど使用していましたが写真のようにホコリが付着していました。このホコリもしっかり落としておきました。
これは新しい 2TB (左)のハードディスクと並べた今まで使用してきた 1TB (右)のハードディスクです。表面部分は写真のように同じもののように見えます。製品ラベルだけが見分ける頼りです。
そして裏側を観察してみるとプリント印刷基盤に違いがありました。新しい 2TB のハードディスクには表面から見える場所に電子部品がありませんでした。結構汚れるハードディスクなのでこうして表面に電子部品がないことは製品の信頼性向上に繋がるものと思われました。
この二つのハードディスクを HP dx6100ST へ接続してコピーの準備を行いました。写真はコピーの準備を済ませた時のものです。手前のハードディスクが新しい 2TB のハードディスクで後ろが今までの 1TB のハードディスクです。
この状態でマシンを立ち上げます。一応この状態でもウェブサーバーとして動作していることを確認した状態で再起動させます。そしてシングルユーザーモードで起動させました。
シングルユーザーモードで起動させることで必要最小限度の動作をするようになります。ウェブサーバーやメールサーバーとしての機能が動かなくなるのでコピー最中に内容が書き換わることがなく好都合でした。
なおコピーはいわゆるコピーコマンドでコピーするのではなく dump & restore （ダンプ＆リストア）で行いました。これは再現性の高いハードディスクのコピー方法です。スライス毎に dump & restore を行うのですが、私は何度も dump & restore をすることを繰り替えしてきたので既にスクリプトを作っていて、このスクリプトで作業を進めました。
さて dump & restore の開始です。ハードディスクコピー専用のスクリプトを実行させました。写真はスクリプトを実行しているときにディスプレイ画面です。画面の上部には UFS2 フォーマットが実行された様子が残っています。そして下部には dump と restore が行われている様子が見えます。
開始時刻0時20分 ＞ 終了時刻11時ごろ
およそ10時間30分の作業時間でした。
もちろん作業中は就寝していました。やはりハードディスクにあるファイル容量が大きいので時間が掛かっていました。この調子だと今度 2TB のハードディスクから 3TB のハードディスクへ移行する時には一日がかりの作業になりそうです。
dump & restore の作業が終了したところで今までのハードディスクを取り外して新しい 2TB のハードディスクを所定のソケットへ接続して再起動させました。
無事再起動することを確認してしばらく動作確認を行いました。特に問題はないようでした。
1TB のハードディスクから 2TB へ変更したので 1TB の空き容量が増えると期待していましたが、 /usr 領域の空き容量は 867GB しかありませんでした。もう少しあってもよさそうなものですがこれが現実のようです（笑）。
交換した今までの 1TB のハードディスクはまだまだ使用できますので他のマシンで使用する予定です。ただ現在のハードディスクの稼働状況を一週間程度みた後に内容を消去しようと思っています。何か万が一のことがあったときのための保険です。
深夜になって仕事を全て済ませてから作業を開始しました。
まず最初に現在使用しているハードディスクを IBM IntellStation M Pro から取り出しました。昨年8月から8ヶ月ほど使用していましたが写真のようにホコリが付着していました。このホコリもしっかり落としておきました。
これは新しい 2TB (左)のハードディスクと並べた今まで使用してきた 1TB (右)のハードディスクです。表面部分は写真のように同じもののように見えます。製品ラベルだけが見分ける頼りです。
そして裏側を観察してみるとプリント印刷基盤に違いがありました。新しい 2TB のハードディスクには表面から見える場所に電子部品がありませんでした。結構汚れるハードディスクなのでこうして表面に電子部品がないことは製品の信頼性向上に繋がるものと思われました。
この二つのハードディスクを HP dx6100ST へ接続してコピーの準備を行いました。写真はコピーの準備を済ませた時のものです。手前のハードディスクが新しい 2TB のハードディスクで後ろが今までの 1TB のハードディスクです。
この状態でマシンを立ち上げます。一応この状態でもウェブサーバーとして動作していることを確認した状態で再起動させます。そしてシングルユーザーモードで起動させました。
シングルユーザーモードで起動させることで必要最小限度の動作をするようになります。ウェブサーバーやメールサーバーとしての機能が動かなくなるのでコピー最中に内容が書き換わることがなく好都合でした。
なおコピーはいわゆるコピーコマンドでコピーするのではなく dump & restore （ダンプ＆リストア）で行いました。これは再現性の高いハードディスクのコピー方法です。スライス毎に dump & restore を行うのですが、私は何度も dump & restore をすることを繰り替えしてきたので既にスクリプトを作っていて、このスクリプトで作業を進めました。
さて dump & restore の開始です。ハードディスクコピー専用のスクリプトを実行させました。写真はスクリプトを実行しているときにディスプレイ画面です。画面の上部には UFS2 フォーマットが実行された様子が残っています。そして下部には dump と restore が行われている様子が見えます。
開始時刻0時20分 ＞ 終了時刻11時ごろ
およそ10時間30分の作業時間でした。
もちろん作業中は就寝していました。やはりハードディスクにあるファイル容量が大きいので時間が掛かっていました。この調子だと今度 2TB のハードディスクから 3TB のハードディスクへ移行する時には一日がかりの作業になりそうです。
dump & restore の作業が終了したところで今までのハードディスクを取り外して新しい 2TB のハードディスクを所定のソケットへ接続して再起動させました。
無事再起動することを確認してしばらく動作確認を行いました。特に問題はないようでした。
1TB のハードディスクから 2TB へ変更したので 1TB の空き容量が増えると期待していましたが、 /usr 領域の空き容量は 867GB しかありませんでした。もう少しあってもよさそうなものですがこれが現実のようです（笑）。
交換した今までの 1TB のハードディスクはまだまだ使用できますので他のマシンで使用する予定です。ただ現在のハードディスクの稼働状況を一週間程度みた後に内容を消去しようと思っています。何か万が一のことがあったときのための保険です。
2011年3月5日土曜日
次期ウェブサーバーのマシンは
現在 IBM IntelliStation M Pro で稼働しているウェブサーバーですが、これを HP dx6100ST へ交換しようと考えています。大きさの比較のために並べてみました。dx6100ST は筐体のカバーの部分だけです。背面部分の位置を揃えて置いてみました。写真には一緒に HP dc7600US も並べています。随分とコンパクトな感じになりそうです。
この dx6100ST はこのウェブサーバーにすることを前提として中古品をインターネット・オークションで入手したものですが、ここ数日考えるところがあり、いろいろと迷っています。
dx6100ST と同時期に入手した dc7600US のコイル鳴きが結構うるさいのです。耳を近づけて音が発生する場所を探るのですが全然わかりません。コイルやヒートパイプを手で抑えても変化がなく、どうも複数の場所から発生している感じなのです。どうも簡単に対策が出来そうにありません。
そこでこの小さな筐体の dc7600US をウェブサーバーにしてみようかと考えているところなのです。ウェブサーバーであれば近くにマシンを置かないので多少コイル鳴きがあっても気になることはありません。またサーバー用のスペースを縮小したいのでこの筐体の小ささは魅力的です。そこためこの dc7600US をウェブサーバーにすることが急浮上しているわけです。
今回ハードディスクの交換に伴ってマシン自体も入れ替えを予定していますが dx6100ST にするか dc7600US にするか迷っているところです。
ハードディスクのコピーに半日程度の時間が掛かるためこの間にじっくり考えたいと思っています。
この dx6100ST はこのウェブサーバーにすることを前提として中古品をインターネット・オークションで入手したものですが、ここ数日考えるところがあり、いろいろと迷っています。
dx6100ST と同時期に入手した dc7600US のコイル鳴きが結構うるさいのです。耳を近づけて音が発生する場所を探るのですが全然わかりません。コイルやヒートパイプを手で抑えても変化がなく、どうも複数の場所から発生している感じなのです。どうも簡単に対策が出来そうにありません。
そこでこの小さな筐体の dc7600US をウェブサーバーにしてみようかと考えているところなのです。ウェブサーバーであれば近くにマシンを置かないので多少コイル鳴きがあっても気になることはありません。またサーバー用のスペースを縮小したいのでこの筐体の小ささは魅力的です。そこためこの dc7600US をウェブサーバーにすることが急浮上しているわけです。
今回ハードディスクの交換に伴ってマシン自体も入れ替えを予定していますが dx6100ST にするか dc7600US にするか迷っているところです。
ハードディスクのコピーに半日程度の時間が掛かるためこの間にじっくり考えたいと思っています。
ウェブサーバーのハードディスク交換
ウェブサーバーのハードディスクは昨年の夏に交換していました。（この辺りの内容） しかしこの頃仕事が急に忙しくなりウェブサーバーと一緒に設定してある samba による共有ハードディスクスペースが急激に消費されてしまってハードディスクの容量不足の警告が何度も出てくるようになってきました。
ハードディスクの中には不要なファイルもごっそりあるのでこれらを整理すれば容量不足も解消されるはずなのですが、この忙しいときに慌ててハードディスクの中の不要なファイルを消去していると つい必要なファイルも消してしまう危険性があるのでどうしたものかと考えてしまいました。
過去にも同様なことがあったときに本当に必要なファイルを消してしまってかなり困ったことを経験しています。そこで今回は価格も安くなった 2TB のハードディスクへ交換しようと考えました。
容量を増やすのであればハードディスクの追加も考えられます。この方が時間もかかりません。また現在使用しているハードディスクも一年を経過していないのでまだまだ使用しても問題ないものと思われます。
しかし現在のウェブサーバーとして使用している IBM IntelliStation M Pro から HP dx6100ST へ切り替えることを前提として考えるとハードディスクを一つにまとめておく方が便利です。また電力の消費量もハードディスク2台よりは1台の方が安いので24時間運転を前提としているのでハードディスク一台の方が優位です。
そこでパソコンショップへ出かけてハードディスクを購入してきました。さすがに消耗品のハードディスクはインターネット・オークションの中古品を購入したくはないので初期不良にも迅速に対応してもらえる地元のパソコンショップで購入しました。
購入したハードディスクはいつも愛用してる日立のものです。 HDS723020BLA642 の型番のものでした。価格は8,780円でした。地方都市のパソコンショップのため多少高めのようですがこれは仕方のないことです。
最近は日立のハードディスクもしっかりとした箱に入っています。以前は本当にバルク状態で販売されていたことを考えると随分と販売方法が丁寧になったものだと思います。写真は箱から中身を取り出した状態です。取扱説明書と取り付けネジ4本が同封されていました。
さらに密閉された袋からハードディスクを取り出して外観を眺めてみましたが特に目新しいものはありません。逆に以前袋に同封されていた除湿材が無いことが新しい発見でしょうか。袋の中に窒素か何かが充填されていたのでしょうか。
取りあえず dx6100ST のケーブル類を内部から引き出して筐体の上面部分でハードディスクのコピー作業などがしやすいように準備をしてハードディスクを取り付けてみました。
SATA ドライブ用の電源コネクタは2個あり、マザーボード上には2個目の SATA ドライブを接続するためのソケットも用意されています。このためのこのマシン上でコピーが出来るようになっています。
ウェブサーバーを停止させてコピーするにはかなりの時間を要するためすぐに取りかかることができません。ウェブサーバーの中には imap4 のメールサーバーもあるため、停止させると仕事の多くを止めなければならないからです。作業は深夜になってからはじめたいと思っています。翌日のお昼までに終了すればよいものと思っています。
コピーの準備としてハードディスクをフォーマットしてそれぞれ必要なエリアを確保しておくこととしました。FreeBSD のインストールディスクによって起動させてハードディスクのフォーマットなどを行ったついでに仮に FreeBSD 7.4 のシステムをインストールしてみました。動作確認もこれで出来ると考えたからです。
インストールは無事に完了して問題なく動作しています。写真はハードディスクの中のスライス（FreeBSD のパーティションのようなもの）の様子です。自動設定を行ってみましたが SWAP や /var の容量に不安を覚えたため一度取り消して手動で設定しなおしました。肝心の /usr 領域は 1.8TB 程度が確保出来たようです。後はコピー作業の開始を待つだけです。
ハードディスクの中には不要なファイルもごっそりあるのでこれらを整理すれば容量不足も解消されるはずなのですが、この忙しいときに慌ててハードディスクの中の不要なファイルを消去していると つい必要なファイルも消してしまう危険性があるのでどうしたものかと考えてしまいました。
過去にも同様なことがあったときに本当に必要なファイルを消してしまってかなり困ったことを経験しています。そこで今回は価格も安くなった 2TB のハードディスクへ交換しようと考えました。
容量を増やすのであればハードディスクの追加も考えられます。この方が時間もかかりません。また現在使用しているハードディスクも一年を経過していないのでまだまだ使用しても問題ないものと思われます。
しかし現在のウェブサーバーとして使用している IBM IntelliStation M Pro から HP dx6100ST へ切り替えることを前提として考えるとハードディスクを一つにまとめておく方が便利です。また電力の消費量もハードディスク2台よりは1台の方が安いので24時間運転を前提としているのでハードディスク一台の方が優位です。
そこでパソコンショップへ出かけてハードディスクを購入してきました。さすがに消耗品のハードディスクはインターネット・オークションの中古品を購入したくはないので初期不良にも迅速に対応してもらえる地元のパソコンショップで購入しました。
購入したハードディスクはいつも愛用してる日立のものです。 HDS723020BLA642 の型番のものでした。価格は8,780円でした。地方都市のパソコンショップのため多少高めのようですがこれは仕方のないことです。
最近は日立のハードディスクもしっかりとした箱に入っています。以前は本当にバルク状態で販売されていたことを考えると随分と販売方法が丁寧になったものだと思います。写真は箱から中身を取り出した状態です。取扱説明書と取り付けネジ4本が同封されていました。
さらに密閉された袋からハードディスクを取り出して外観を眺めてみましたが特に目新しいものはありません。逆に以前袋に同封されていた除湿材が無いことが新しい発見でしょうか。袋の中に窒素か何かが充填されていたのでしょうか。
取りあえず dx6100ST のケーブル類を内部から引き出して筐体の上面部分でハードディスクのコピー作業などがしやすいように準備をしてハードディスクを取り付けてみました。
SATA ドライブ用の電源コネクタは2個あり、マザーボード上には2個目の SATA ドライブを接続するためのソケットも用意されています。このためのこのマシン上でコピーが出来るようになっています。
ウェブサーバーを停止させてコピーするにはかなりの時間を要するためすぐに取りかかることができません。ウェブサーバーの中には imap4 のメールサーバーもあるため、停止させると仕事の多くを止めなければならないからです。作業は深夜になってからはじめたいと思っています。翌日のお昼までに終了すればよいものと思っています。
コピーの準備としてハードディスクをフォーマットしてそれぞれ必要なエリアを確保しておくこととしました。FreeBSD のインストールディスクによって起動させてハードディスクのフォーマットなどを行ったついでに仮に FreeBSD 7.4 のシステムをインストールしてみました。動作確認もこれで出来ると考えたからです。
インストールは無事に完了して問題なく動作しています。写真はハードディスクの中のスライス（FreeBSD のパーティションのようなもの）の様子です。自動設定を行ってみましたが SWAP や /var の容量に不安を覚えたため一度取り消して手動で設定しなおしました。肝心の /usr 領域は 1.8TB 程度が確保出来たようです。後はコピー作業の開始を待つだけです。
