2018年7月23日 (月)

ぼくのかんがえたさいきょうのドキュメントCIかんきょう

1. 前説:こんな書かれ方をするといやなのだ

みなさん、ソフトウェアの設計書ってどうやって書いてます?
....やっぱExcelですよね、この業界。

僕の周囲でもこれはそうなんだけど、個人的には

  • 自分一人で設計を書き、
  • その設計をもとに自分一人で実装し、
  • 実装内容とは無関係な体裁の修正に、十分な時間がかけられ、
  • 版の管理は気にしなくてよい

場合になら、たぶんExcelを普通に使うと思う。

ただ、実際の現場だとそんな悠長なことを言っていられるわけでもなく、人が書いた設計書をもとに実装、なんてことは普通で、場合によってはこんな設計書()に出くわすこともありうる。
Revision_of_mislieading_design

この場合の正解は、商品情報.商品カテゴリが104のとき、商品情報.個数を加算する。なんだけど、不要な情報が一緒に目に飛び込んでくるのは、正直勘弁してほしいと思う。個人的には。

それに、設計書がMicrosoft Office(xlsだと特に)だとこんなことが起きうる。

  1. 共有ディスクに設計書がアップされる
  2. 共有ディスクの設計書ファイルをそのまま開くと、反応が悪い上に場合によってはファイルを破壊する可能性もあるので、作業効率を優先してローカルディスクにダウンロード
  3. 実装作業中の設計書がいつの間にか更新される(アナウンスはなし)
  4. 更新を知らないままローカルファイルで実装を終える
  5. 「設計と挙動が違う」とバグ表を切られる

ほかにもいろいろあるが、設計書がMicrosoft Officeだとこんな弊害が起きる、と個人的には考えている。

  • 版の管理にはOneDrive for Businessとかが必要で、ふつうのVCSでやるのは悪夢でしかない
  • (上に関連するが)リビジョン間で「どこがどう変わったか」を把握するのは、容易なことではないので、一つの最終版ドキュメントにすべての情報を押し込めようとする
  • 集中管理されるべき設計書がカジュアルコピーとして拡散するので、どれが本物かわからなくなる
  • 設計とは本質的に関係のない「体裁の修正」に、少なくはない労力を割かなければならない

ここまでで終わらせたらただの文句でしかないので、どうすればましになるかを考える。

2. 設計書作成ツールとしてのMicrosoft Office

オフィススイートであるMicrosoft Officeでもっとも設計書作成で使われるのは、表計算ソフトであるExcelじゃないだろうか。
表計算をほとんど必要としない文書なのに、なぜExcelを使うのか、僕なりに考察してみた。

  • 日本には昔から「方眼紙文化」があるが、Wordだと方眼紙的なインデントが面倒だが、Excelだとセルを狭めることで方眼紙的なレイアウトを容易に再現できる
  • 複数の独立した文書を、「ワークシート」という単位で一つのファイルにまとめることができる
  • 日本のオフィスPCには、原則Microsoft Officeが入っているので、環境を選ばない。これは、設計書を「納品」しても、それを相手先でも読むことができることを意味する

Excelを使うときの利点を考えたら、僕ではこれくらいしか思いつかない。読者諸兄で、これ以外の利点がご存知ならご教示いただきたい。

個人的には、これらは何もExcelでなくても達成できるものだと思う。
そう考える理由は以下のとおり。

  • 方眼紙的なインデントが必要なのは、「一見して文書の意味付けを把握できるようにしたい」という要求の現れなので、要件に合うような文書構造にすればよい
  • 独立した文書を一つのファイルにまとめたいなら、HTMLでもできる
  • 環境を選ばないファイル形式には、Adobe PDFというものがある
  • 版の管理とリビジョン間の更新差分の管理がMicrosoft Officeだと難しいのは、ファイルフォーマットがバイナリが基本なのが原因なので、原稿をプレーンテキストで記述できれば差分管理はVCSが良しなにしてくれる
  • 単一の原稿から複数のフォーマットの成果物を生成できれば、「開発時は開発サーバ上のHTMLを参照」し、「納品にはPDFを使う(必要であれば印刷してもよい)」という方式がとれる
  • ドキュメントビルダを経由すれば、規定のマークアップ仕様のもとで、体裁は統一された仕様として構造化された文書に紐づくので、「文書体裁の修正」と「ソフトウェアの設計」を明示的に分離できる

前置きが長くなったが、これらを一度に解決する(と僕が考える)ソフトウェアがある。Sphinxである。

3. 本題:ぼくのかんがえたさいきょうのドキュメントCIかんきょう

まずは目標とすることを挙げてみる。

  • 文書の意味付けは標準テンプレートでまかなう
  • 版の管理をVCSに分離する
  • VCSにコミットされた原稿からのビルドは、人手を介することなく自動的に行われるようにする
  • 開発中の設計書が拡散しないよう、Webサーバで参照できるようにする
  • 納品用成果物となる設計書は、PDFにして管理する

いろいろ挙げたが、概念的にはこんな図になる。
Document_ci_overview

というわけで、ひとつひとつ書いていく。

3-1. プロジェクトとVCSの設定

プロジェクトについては、プロジェクトを作るの記事に従って sphinx-quickstart を実行して作るだけなので、特に難しいことはないはず。
VCSも、現状Git以上にベターな選択肢はないので、Gitを選択し、外部のホスティングサービスにおいている。ここでは、プライベート/パブリックの切り替えが簡単なAtlassian BitBucketを使っている。

プロジェクトを作ったら、UTF-8を扱えるエディタでreStructuredTextのマークアップ仕様に基づいて設計書を書いていこう。入門記事もある。

3-2. 面倒なことは有能な執事に任せる

「体裁の修正」や「可読性の高い文書ファイルの生成と配置」といった、本質的に設計と関係ないところで労力を割きたくないので、このテの作業はすべてJenkinsに任せる。
BitBucketがプッシュを受け付けたことをトリガーにしてビルドを始めるのが、反映タイミングとしては最速なのだが、これを実現するためにBitBucketにWebHookを設定する。

まず、Jenkins側にBitBucketからのWebHookを受け付けるためのプラグインを導入する。これにはBitBucket pluginを使った。導入自体は、Jenkinsのプラグインマネージャーから行える。

導入したら、ビルドプロジェクトをつくる。

ソースコード管理はGitにする。BitBucketの仕様に従っていれば特に問題はないはず。
01_source_code_control

次のビルドトリガは Build when a change is pushed to BitBucket を選択する。
02_build_trigger

最後に実際のジョブだが、 make の成果物をディレクトリにコピーするシェルスクリプトを実行する。
Ubuntu の DocumentRoot である /var/www/html 以下に反映する。

#!/bin/bash
HTML_ROOTDIR=/var/www/html/designdoc
UID_TOMCAT=tomcat
UID_WWW=www-data

LANG_CD=ja

HTML_DIST=$HTML_ROOTDIR/$LANG_CD
EPUB_DIST=$HTML_ROOTDIR/epub/$LANG_CD
PDF_DIST=$HTML_ROOTDIR/pdf/$LANG_CD

make clean html epub latexpdf

PS4='+ [${BASH_SOURCE}:${LINENO}] ${FUNCNAME:+$FUNCNAME(): }'
set -vx

if [ ! -e $HTML_ROOTDIR ]; then
mkdir $HTML_ROOTDIR
fi

sudo chown -R $UID_TOMCAT:$UID_TOMCAT $HTML_ROOTDIR

if [ ! -e $HTML_DIST ]; then
mkdir -p $HTML_DIST
fi
rsync -rlDH --delete _build/html $HTML_DIST

if [ ! -e $EPUB_DIST ]; then
mkdir -p $EPUB_DIST
fi
cp -f _build/epub/MySkill.epub $EPUB_DIST

if [ ! -e $PDF_DIST ]; then
mkdir -p $PDF_DIST
fi
cp -f _build/latex/MySkill.pdf $PDF_DIST

sudo chown -R $UID_WWW $HTML_ROOTDIR

set +vx

ただ、 Tomcat の実行ユーザーと Apache の実行ユーザーが違うので、 /etc/sudoers をいじって chown を認証なしで実行できるようにしている。

tomcat	ALL=(ALL:ALL)	NOPASSWD:	/bin/chown

このあたり、もっとましなやりようがないものか。我ながらかなりの力技だ(汗)。

Jenkins側の受け入れ態勢ができたところで、BitBucketのプロジェクトにWebHookを送る設定を書く。
[送信先URL]/bitbucket-hook/を宛先にする。
Webhook_from_bitbucket

ここまでやれば、手元で原稿を書き、それをBitBucketへプッシュするだけで、実装者にも納品担当者にもうれしい設計文書が作られているはずである。

| | コメント (0) | トラックバック (0)

2017年12月 6日 (水)

Redmineを入れてみる on CloudGarage

CloudGarageというNHNテコラスさんが展開している定額制パブリッククラウドサービスがあって、こちらのご厚意で開発者ライセンスを発行してもらえるようになった。

で、Ubuntu Serverのインスタンス一つ立てて、前から欲しかった「自分専用BTS」をセットアップしてみることに。自分自身はRedmineが使い慣れているので、がんばってセットアップに挑戦してみた。

手順自体はRedmine.JPさんのブログの手順のとおりで、特にこれといって特別なことはしていないんだが、途中のPassengerのビルドがメモリ不足で止まる。

むぅ、1GBじゃきびしいか、と思っていたんだが、ある日ふと「スワップ拡大すれば何とかならないか?」と考えてスワップを切りなおすことに。

とりあえず現状。

# swapon -s
Filename                                Type            Size    Used    Priority

え? スワップきいてない?
では、ってことでスワップを追加してみることに。さすがにスライス切りなおすわけにもいかないので、Windowsみたいにファイルをスワップにしてみる。伝統的に物理メモリの2倍にしてみる。

# mkdir /swap
# fallocate -l 2G /swap/swapfile
# chmod 600 /swap/swapfile
# mkswap /swap/swapfile
# swapon /swap/swapfile

ここまで出来たら再度確認。

# swapon -s
Filename                                Type            Size    Used    Priority
/swap/swapfile                          file            2097148 360544  -1

うむ、有効になってる。これで作業再開してみると、こんどはちゃんとビルドが通る。これでめでたくRedmineが使えるように。

CloudGarageさんのインスタンスはディスクがSSDなので、スワップアウトしてもさほど気にならない。いいですな。

| | コメント (0) | トラックバック (0)

2013年9月24日 (火)

Wheezyにia32-libを入れる

0. イントロダクション

 Androidの開発機をDebian GNU/Linux amd64に変更したんだけど、amd64なのでちょいとハマったことについてメモ。

1. Androidとia32-libs

 Android SDKをセットアップしていると、adbにパスを通しているにも関わらず「そんなファイルはない」と怒られることしきりなんだが、その原因がこれ。
 早い話、Wheezyのベースシステムにx86互換レイヤーが含まれていないから、という理由らしい。

 で、入れればいいでしょ?というわけになるんだが、ここでハマったのでメモっておく。

2. 最初の一歩

 ダイレクトに

# apt-get install ia32-libs

とかやっても「依存関係が壊れている」とか言われてNGなので、i386をアーキテクチャに追加する。

# dpkg --add-architecture i386
# apt-get update
# apt-get install ia32-libs

 とここで、libtinfo5:i386のインストールでつまづいた。コンソールいわく、「依存関係の解決法がわからなけりゃ、apt-get -f installをやるしかないかもね」だそうだが....。

3. 非常手段に打って出る

 しかたないので強制インストール。

# apt-get -f install libtinfo5:i386

 ここで再度apt-get install ia32-libsを実行してやることで、依存関係の解決をみた。あんまりスマートな方法ではなかったかもしれないが....。

 とはいえ、これで「adbがない」とか怒られずに済むので、AVDも自由に作成できるようになる。

 あと、確認はしていないけど、NDKを使うときもこれが引っかかるんじゃないか、とか疑っているので、NDKを使うことになる時はこれをやっとかないといけないかもしれない。

 あとは、Yahoo!知恵袋の「Android仮想デバイス(AVD)の高速化」ノートを参考に、qemu-kvmとlibvirt-binパッケージをapt-getで入れてAtom System ImageでAVDを作れば、エミュレータもキビキビ動いて快適になるはずだ。

 というところで寝る。

| | コメント (0) | トラックバック (0)

2013年9月14日 (土)

リモートGitリポジトリにHTTPSでアクセスする

 俺得アプリ開発に使っているVCSを、SubversionからGitに変えてかなり経つが、今回はGitでHTTPSアクセスするときにハマった時の、自分用メモだったりする(汗)。

 今の開発環境は、以下のとおり。

  • OS : Debian GNU/Linux 7.1 amd64
  • JDK : Oracle社のJDK7u40 for Linux x64
  • VCS : git 1.7.10.4
  • IDE : Eclipse 4.3 for Java Developers Linux x64
  • ADT : 22.0.5を、Google Plugin for Eclipseとしてセットアップ

 とある事情によりプライベートリポジトリにしている開発リポジトリがあるんだけど、そいつにgit pushかけようとしたら、こんな状況に。

error: Problem with the SSL CA cert (path? access rights?) while accessing https://path/to/repo.git/info/refs
fatal: HTTP request failed

 はて?「パスかアクセス権に問題」とな? なんだろうと思っていろいろググってみた。

 よく似た事象で言えば、GitHubでのHTTPSアクセスに関する部分か。GitHub(実はこのプライベートリポジトリにはGitHubを使っていないんだけど)の公式には、「おたくんところのCAが古いんじゃない?」という解説があったんだけど、そんなこといわれてもなぁ。

 念のためSSL周りのパッケージを調べてみたけど、当然のことながら最新。

 まぁ、自分でCAたてたりApacheにSSL仕込んだりするわけではないから、巷に出回っているSSLの設定とやらでは対処できそうにない。それにしても、クライアント証明書を独自に作らなきゃいけない、ってとれるんだけど、同じリポジトリにWindowsでアクセスした時には、そんなことを強いられた記憶はない。

 じゃあどうするんだい? ってことになるんだが、GitリポジトリにHTTPSでアクセスするときの作業ログを残している方がおられた。
 この方の場合、「オレオレ証明書のGitリポジトリにアクセスする場合」として「SSL証明書の検証をバイパスする」という方法をとっていた。

 ということで、.gitconfigに

git config http.sslVerify false

を追加してみると、すんなり通った。
 git configにあえて--globalをつけていないのは、「デフォルトはSSL証明書の検証をするけど、このプロジェクトではやらない」という方針にしたほうがいいように思ったから。

 まぁ、こいつのトラブルシュートで半日費やすことになったし、根本的な解決になっていないような気もするが、問題自体は解決できたし、とりあえずよしとするか。

| | コメント (0) | トラックバック (0)

2012年12月17日 (月)

Samba 4.0 has come!

迷ったけど、カテゴリはLinuxに。

それはさておき、10年越しの、やつがリリースされた。その名はSamba 4.0。
で、そのプレスリリースを読んでいるわけだけど、すごいわ、これ。

特にこの一文

  • Upgrade scripts are also provided for organizations using the previous Microsoft Windows NT Domain Controller functionality in Samba 3.x, to allow them to migrate smoothly to Samba 4.0.

がイカす。「Samba 3.xで構成されたMicrosoft Windows NTドメインコントローラを使っている組織が、スムーズにSamba 4.0に移行できるよう、アップグレードスクリプトを用意しています。」てな感じだろうか。

確かに、3.xでもWindows ServerのADにメンバーサーバとしてぶら下がる機能は持ってたけど、そいつらも丸ごとADにできる、ってことなんだろうか。だとしたら、えらいことかも。

とはいえ、その検証のためだけにSamba 3.xでDCセットアップするのも面倒だが、10年越しの偉業達成は素直にエールを送りたい。

| | コメント (0) | トラックバック (0)

2008年5月18日 (日)

ディスクが消える

 ゆうべNASとして運用中の玄箱(ホスト名pai)のNAS領域をバックアップしようと思い、Debian amd64を入れているAthlon64自作機(ホスト名lilith)を久々に起動した。起動自体は普通に起動して、Xも普通に動いているのだが、rsyncの実行速が異様に遅い。

 lilithにはHDDを計4台接続していて、うち1本はOSのインストールされたシステム領域(/dev/hda)なのだが、残りはSerial ATA 1.5Gbpsのディスクをつなげて(/dev/sda、/dev/sdb、/dev/sdc)、こいつらをmdadmでRAID-5ボリュームとして扱っていた。ソフトウェアRAIDとはいえ、普通に単独運用するよりもボリューム全体としての性能は底上げされているわけだから、ボリュームそのものの問題とはそのときは思えなかった。

 で、ファイルの数の問題かと思って一晩放置していたのだが、翌朝になってもrsyncが終わってないではないですか。

 こいつはおかしい、と思って/proc/mdstatの中身を確認してみると、なんと/dev/sdcが消えていた、という。どうりで性能が出ないわけだ、と納得。

 前からどうも調子がおかしいな、と思っていたのだが、ここへきて本格的にイカレたらしい。同じ日に買った同じロットのディスクなんで、まだエラーを吐いてない他のディスクも時間の問題かもしれない。

 が、船乗りをしていた昔と違って、今は10000rpmの高性能品がホイホイ買えるほど給料がいいわけではないので、今月の給料が出るまでしばらく我慢するしかなさそうだ。

 まぁ、今のところlilithは常時起動しておく予定はないので、とりあえずは大丈夫か? そういえばpaiに入れているディスクもそろそろ3年になるが、常時運用なんでそろそろ代替品を考えないと。あぁ....。

| | コメント (0) | トラックバック (0)

2007年6月 6日 (水)

なんとかEtch化

 玄箱/Proをつつき始めて、ようやくDebian化にこぎつけた。実は、玄箱PROのDebian Etch化の手順を基にフルスクラッチビルドしたかったのだが、wgetのビルドがどうしてもできない。というわけなので、次のような作戦に打って出ることにした。というか、元ネタのシリアルコンソールなしにハックキットそのまんまなんだが(爆)。

  1. ターゲットにするHDDと作業用のHDDの2台とSerial ATA用のUSB接続ディスクケースを用意する。
  2. 付属CD-ROMのhddrootfs.tar.gzとファームウェア1.02のuImage.buffaloを使って、両方のディスクにHDDブート環境を作る。
  3. 作業用HDを玄箱に、ターゲットHDをディスクケースにそれぞれ入れ、ターゲットHDの第2領域をマウント、そこに書かれているファイルをすべて消去する。
  4. sushi-k日記2 >> KURO-BOX/PRO Debian化決定版?で公開されているDebian etchのルートイメージを、ターゲットHDの第2領域に展開する。
  5. ターゲットHDのetc以下を、自宅のネットワーク環境に合うようにカスタマイズする。
  6. 終わったらディスクを入れ替え、ターゲットHDで玄箱を起動する。

 ということなのだが、一応Debianが起動してくれた。あとはapt-getでアプリケーションをインストールするだけなのだが、apt-get updateを実行すると、GPG errorなんていわれる。この辺をググってみると、有効なGPG鍵がないことが原因らしいことが判明。あれ? etchって今年出たんじゃなかったっけ? と思ったんだが、apt-key listを実行すると、gpg: key 2D230C5F was created 1136285233 seconds in the future (time warp or clock problem)、だなんていってくる。

 clock problemぅ? もしやと思い、システムの時計をdateコマンドで表示させると、Thu Jan 1 09:25:24 JST 1970をさしている。そういえば時計合わせをしてなかったっけ。ということでntpdateを強制インストールして、ntpdate-debianでとりあえず時計あわせ。で、再度apt-get updateを実行すると、今度は何事もなかったかのようにapt-lineをあたってくれた。

 apt-getもちゃんと動くようになったので、これで煮るなり焼くなり好きにできるわけなんだけど、今日はこの状態でとりあえずやめておく。今度は、ディスクを入れ替えてこのルートイメージをtarballにでもしておこうかな? 余裕があったら公開してもいいかも。

| | コメント (0) | トラックバック (0)

2007年6月 5日 (火)

SWATをSSL化するネタ

 ちょっと寄り道して、Samba 3.0のSWATをSSL化するネタを公開してみる。ちなみに内部を LinkStation/玄箱 をハックしようの著者が製作されたハックキット 2.0alphaを使って、Vine Linux 3.1相当にしてある。

SWAT自体はinetdなんかのスーパーサーバを使うことが前提になっているので、daemontoolstcpserver(ucspi-tcp)+SSLパッチを使うことにする。で、それぞれをダウンロード。

 daemontoolsとucspi-tcp(djb謹製アプリケーションはほぼすべてらしい)には、glibcのバージョンが2.3.1以上だと正常にコンパイルできないという不具合(というべきだろう)があるため、ucspi-tcp-0.88.errno.patchdaemontools-0.76.errno.patch もダウンロードしておいた。それぞれにパッチを当て、コンパイル開始。

 daemontoolsは正常終了。起動も問題なし。で、ucspi-tcpなのだが、tcpserver SSL/TLS patchにはすでにerrnoのパッチが取り込まれていたので、SSLパッチだけ当ててmake。...ってエラーを吐いてとまる。パッチなしの状態だとmakeが普通に通るので、「もしかして?」ということでSSLパッチを当てた後、errnoパッチをリバースパッチとして当ててみた。すると正常終了。make setup checkも問題なし。なんだかなぁ。

 ucspi-tcp-0.88のディレクトリでmake certを実行して、SSLのサーバ証明書を生成する。ファイル名はcert.pemになってしまうが、別に問題はなかろう。

 このcert.pemをdaemontoolsのswat サービスディレクトリにコピーして、runを書く。こんな感じ。

  #!/bin/sh

  SAMBA_PREFIX=/usr/local/samba
  PATH=$PATH:$SAMBA_PREFIX/sbin:/$SAMBA_PREFIX/bin
  export PATH

  # tcpserver(8) environment
  # ACL ectry file
  ACLS=/usr/local/etc/acls/default.cdb
  # run as this user
  USER=root
  # my linstening address or host
  HOST=0
  # my linstening port or service name
  PORT=10901
  # run this program
  PROG=swat

  exec 2>&1
  exec tcpserver -vRHl0 -s -n ./cert.pem -x $ACLS \
      -u `id -u $USER` -g `id -g $USER` \
      $HOST $PORT $PROG

 自己証明書なので証明書を無条件で受け入れてくれないのだが、https://{玄箱のIPアドレス}:10901/で、ちゃんとSSL化された。これで野良にしても大丈夫...か?

| | コメント (0) | トラックバック (0)

2007年6月 1日 (金)

温度管理ネタを

 さまざまなところでhddtempを使った温度管理ネタが披露されているので、夏も近いことだしやってみることにした。

 よくあるRPMやdebを取得してインストール、というやつではなく、まじめに(?)ソースからビルドした。ソースは同プロジェクトのダウンロードページ(Download Area)から、hddtemp-0.3-beta15.tar.bz2を取得。

 tarballを展開して、まずINSTALLに目を通す。HDDのデータベースファイルが必要らしい。こいつもwgetで取得する。./configureを実行する際、データベースのパスを指定できるようだ。デフォルトでは/usr/share/misc/hddtemp.dbをサーチするようになっているんだが、インストールプリフィックスが/usr/localなので./configure --with-db-path=/usr/local/etc/hddtemp.dbで./configureを実行。忘れずに/usr/local/etcにデータベースファイルhddtemp.dbをコピーしておく。

 ということで、後は何の芸もなくmake; make installでインストールは一通り終了。hddtempは/usr/local/sbinにインストールされた。

 とりあえず温度を取得してみる。

  [root@pai root]# hddtemp /dev/hda
  /dev/hda: WDC WD3200JB-00KFA0: 39°C

 山下氏の解析結果によると、AVRマイコンへ送る情報でファンの回転速度を調整できる、ということなので、

  • まず現在の温度を取得し、
  • それが閾値以上であればファンを高速で回転させ、
  • 閾値以下になればファンの回転速度を下げる

 といったシェルスクリプトを書いてcron実行させればいいのでは、ことなのだが、今日は疲れたのでそれは次の日以降の宿題にすることにして、今日は寝ることにする。

| | コメント (0) | トラックバック (0)

2007年5月30日 (水)

KURO-BOX/PRO

 PCベースで動かしている各種サーバをコンパクトなアプライアンスで動かせれば、部屋の中もずいぶんすっきりするんじゃなかろうか? という単純な理由から、以前からこの手のキットを物色していたんだけど、玄箱にするかIO DATAのGLAN TANKにするか迷っていたんだけど、いつの間にかGLAN TANKのほうが在庫限りの状態になってしまったこともあり、思い切って玄人志向のKURO-BOX/PROを購入。本体は約2万円なり。ハードディスクはHGSTDeskstar T7K500500GBモデルをチョイス。

 早速家に帰って組み立てを始める。ビスを3本緩めるだけでハードディスクのマウンタを取り出せるようになっていることに、まず驚いた。むちゃくちゃ分解しにくかった前の玄箱から比べると、整備性が大きく向上している。これは分解していろいろいじれ、ということなんだろうか。

 初期状態ではtelnetを受け付けるようになっているので、とりあえずtelnetしてみる。どうやらまだ内蔵のフラッシュから起動しているだけのようだ。Samba 3,0は普通に動いているようだけど、ハードディスクからOSを起動する仕組みが用意されているようなので、これからの自由度を考えたらハードディスクからシステムが起動してくれたほうが都合がいいんだが。

 もっと情報を集める必要があるなぁ。

| | コメント (0) | トラックバック (0)

より以前の記事一覧