スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

LinkStation[LS-WTGL/R1]修理依頼

【環境構築】
TFTPでカーネルをロードさせる作戦に決定したので母艦の準備です。

さて、少し修理のネタから脱線しますが母艦とはなんぞや?
いきなり「母艦」と検索しても多分、検索出来ないので少しだけメモしておきます。

シンクライアント端末と呼ばれる端末の多くはサーバからOSをダウンロードして
システムが起動します。
このときの通信プロトコルにTFTPを使用している事が多く、母体となるTFTPサーバを
用意しないと「ただの箱」は起動できません。
つまり、OSイメージ(カーネル)をダウンロードさせるサーバの事を「母艦」と呼んでいます。


ということでサーバとなるベース環境をVMware + debianにすることにしました。

それにしても端末のIPアドレスってDHCPで取れるようになってるんじゃないの?
ブートローダはフラッシュに焼きこんであるはずなんだけどなぁ・・・
とにかく現段階ではフラッシュにカーネルが焼き込まれているかどうか以前に
ブートローダの種類がU-Bootってくらいしか把握できていないので疑問点は多くありますが
割り当てられたIPアドレスは把握しておきたいのでDHCPサーバの構築から着手する事にしました。

debianをインストールしたての仮想端末にいざログイン!
へ?はじかれた?
おかしいなー。SSHログインできるはずなんだけどなぁ・・・
・・・SSHサーバがインストールされていなかった。いきなりこれかよ。
仕方ないので仮想端末にGUIでログインしてSSHのインストール。
apt-get install openssh-server
DHCPサーバもインストールされていないからついでに。
apt-get install dhcp3-server

これでSSHリモートログインできるようになったので後は全てターミナル上でコントロールできる。
早速、dhcpd.confの編集。
と、その前にサーバのIPを192.168.0.10に固定しておいて他のPCに影響のないように・・・・
ifconfig eth0 192.168.0.200
で、リースするIPもルータと喧嘩しないように。
subnet 192.168.0.0 netmask 255.255.255.0{
host Client_001{
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.0.200;
#filename"/tftpboot/xxxxxxxxx";
}
}
log-facility local5;

syslog.confも修正して、ログの分離でデバッグしやすいようにしたので
いざ電源ON!
ん?IPをリースしていない?macアドレスの記述間違えたかな?
確認しても記述は特に間違っていないようだが・・・
ログには
DHCPDISCOVER from xx:xx:xx:xx:xx:xx via eth0: network 192.168.11/24: no free leases
は?192.168.11って・・・
セグメント超えたIP割り当てなんて指示してないんですけど。
てか、なんでクライアントがセグメント指定すんの?
はっ!
推測だが、フラッシュに書き込まれたU-Bootはネットブート時のTFTPサーバのアドレスを固定してる?
で、カーネルイメージと初期RAMディスクを読み込ませファイルシステムにマウントさせてる?
もしかしたら・・・自分なんぞが考えた事は必ず他の人も既に考えてるはず!とにかく検索!

こんなんでました。
【バッファロー様謹製ツール「TFTPリカバリツール」】

・・・・・・・・・・・さすがメーカー様。
公開してないツールとはいえ・・・・しかもWINDOWS上でTFTPサーバを立ち上げさせるなんて。




さてと・・・・・

やばい。

やばいよ。。。。。

やっぱり飽きてきた。

せっかくウキウキしてたのに。

この先が見えちゃった。

こうなったら後は完全に機械作業。
①リカバリツールでOSとして最低限の機能を有効にする。
②ファームアップツールでファームを書き込もうとするがRAIDとして異変があるからフォーマットさせる。
③リカバリ完了!わーい。

試しにこの手順を試したところやっぱり手順②の「フォーマットします!」だって・・・

ただ、誤算だったのはHDDの物理破損の件。
シーク時の異常音は聞こえなかったのにOSが機能したとたんDISK_1が「カツン・・カツン・・・」
やっぱりフォーマットは失敗するし。
初動調査では音だけで判断してたけどやっぱりファイルアクセスさせて調査しないとダメって事ですね。
面倒くさがってはダメなんですね。メモメモ。

うーん。
取りあえず修理としてはHDDを正常なものに交換してリカバリして終わりなんですが・・・

せっかく高価なオモチャを借りてるので許可をもらって遊んでいいかお願いしーよおっと♪
※一応、業務依頼として請け負っていますが話のわかる元上司なのでお願い出来る事です。
 一般のお客様には絶対やってはいけません。

という事でもっとネタを探してみます。その前にお願いが先でした。

ここから先は興味がある方だけ読んでみてください。

【シンクライアントの起動プロセス --LINUX系OS版--】
いわゆる基板(マザーボード)には必ずCPUが載っています。
このCPUがインテル系であればボード上のフラッシュにはBIOSが載っていることが多く
ほとんどの場合でネットブートが可能となっています。
このような場合、PXEブートと言う手法が可能ですが今回はARMマイコン。多分、というより
間違いなくARM926がコアとして採用されています。
ARM系CPUだけではなく多くのマイコンは経験上、独自のブートローダ。
もしくはU-Bootなどを利用してネットワークに参加するようになっています。
ここでいうブートローダとは非常に境界線が難しいのですが、0番地から命令を読み出し
エントリポイントまで飛ばしてくれる機能を所有するプログラムを指しています。
なんだか文章だけですとグダグダになってしまいますが・・・

とにかく「ブートローダ」とはネット越しであれ、外付けフラッシュであれOSイメージを
読み出すまでの役割としましょう。

取りあえずブートローダに従ってOSをロードする行程までくると基板はネットワーク上の
OSイメージを取得しにいきます、この時使用するプロトコルがTFTPと呼ばれるプロトコルです。
FTPと似ていますがTCPでデータの確実性を持つFTPに比べ、TFTPではUDPで確実性を持ちませんが
認証が必要なく高速通信が可能な為、システム起動に適しているといえます。
基板はこのTFTPを使用し、OSをダウンロードし、メモリ管理や
I/Oリソース管理するOSとしての機能を持ちます。
しかし、この段階では最低限の機能しか持っていないためHDDのファイルシステムといった概念が
ないので「初期段階でのファイルシステム」とも呼ばれるinitrdを読み込みモジュールを
RAM上に保持させます。この事によりHDDにアクセスする事が可能になるのでHDDにマウントを試みます。
こうやって基板はマウントしたHDDのファイルにアクセスし、
様々なアプリ?デーモンを実行出来るのです。
また、NFSにマウントする事もあります。

ではrootfs.imgとは?
これはHDDを搭載していない機器によくあるファイルシステムでRAMに展開するものです。
説明が非常に難しいところですがこのrootfs.imgは圧縮ファイルでこの圧縮ファイルの中に
デバイス情報やアプリ?デーモンが格納されています。

図書館や公共の場に備え付けられているPCの多くは訪れたお客様が「ネットで調べる」機能が
あればというか「ネットで調べる機能」しか必要ありません。
逆にいえば「余計なプログラムをインストールされたくない」わけです。
そりゃそうでしょうね。変にトロイやウィルスなんて入ってしまった日には・・・・
という事でクラウドコンピューティングになった現代にこの端末運用方法はもう一度
考える必要があるのかなと感じた気がします。

ブログという形式なのであまり多くをご説明する事は出来ませんが、これからいろいろ試してみよう!
という10数年前の私と同じような若者にせめてもの足がかりをここに記します。

スポンサーサイト

コメント

非公開コメント

プロフィール

新井優仁

Author:新井優仁
FC2ブログへようこそ!

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。