テクニカルノーツ | 有限会社ワン・エックス

テクニカルノーツ

2016.3.11
Windows

Windows10からWindows7に戻したら日本語入力ができなくなった場合の対処法

Windows10の半強制アップグレードが行われているらしい 2016年3月11日現在、Windows10への意図しないアップグレードが行われてしまったという報告が相次いでいる。いずれの場合も自ら望んでアップデートしたわけではないのだが、キャンセルの方法がわからずに知らず知らずにアップグレードを選択してしまったという事情らしい（詳細はWindows10への半強制アップグレードが再び猛威を奮っている模様？を参照）。アップグレード後、1ヶ月以内はWindows7に戻すことが可能望まぬアップグレードにより Windows10 になってしまった場合でも救済措置はある。アップグレード後、元の OS に戻す機能が用意されている。元のOSに戻す方法を書くことが本稿の主旨ではないので、必要な場合は「Windows10にアップグレードした後、元のOSに戻す方法」を参照されたい。日本語入力ができなくなる問題は元に戻した後に発生する。一件、普通に Windows7 が起動したかに見えて、いざ日本語入力をしようとしても IME が立ち上がってこない。ESCを押してもALT+ESCを押しても、一切の日本語入力ができない。キーボードのプロパティを操作してもまったくの無駄である。 Vista以降の Windows では、サインイン後に MsCtfMonitor というタスクが実行されて IME を呼び出すことができるようになるのだが、一旦 Windows10にアップグレードしたことによって Windows7 のタスクが正常に実行されなくなってしまったことが原因である。確認のためにタスクスケジューラを開こうものなら「タスクイメージは破損しているか、または変更されています。(HRESULT からの例外:0x80041321)」というエラーが表示され、OKボタンを押しても繰り返しエラーが表示されて、少なくとも80回を超えるクリックを強いられる（万が一クリック地獄に堕ちてしまった場合はCtrl+Shift+ESCでタスクマネージャを開いて、タスクスケジューラを強制終了させよう）。タスクスケジューラを立ち上げずにエラーを確認するためにはコマンドラインから schtasks /query ENTER を実行する方法もあるが、後述するプログラムで同様のことができるので必ずしも実行する必要はない。 IMEを起動させるだけなら ctfmon.exe をスタートアップに入れることで復旧可能だが、タスクスケジューラに大量のエラーを残したままであり、根本的な解決とはならない。システム管理者としてはエラーの影響が測定できない以上、捨てておくべきではない。大量のタスクの復旧もっとも優れた復旧方法はWindowsバックアップから復元することだが、大半のエンドユーザは毎日バックアップしていることなどない。そうなるとひとつひとつ破損したタスクを復旧させていかなければならないのだが、壊れたタスクを復旧させる方法はなかなかむずかしい。レジストリとデータファイルをひとつひとつ操作する必要があるため、現実的な方法ではないのだ。しかし、ありがたいことにこの復旧方法をプログラム化してくれた人がいる。Repair Tasks がそれだ。 Repair Tasks を実行せよ日本語入力はできなくともブラウザは動く。まずは Repair Tasks のダウンロードページ（2018.6.26補記：CodePlexのサポート終了に伴い、サイトはGitHubに移行した）へ行って、RepairTasks.zip をダウンロードしよう。23KBほどしかない小さなプログラムだから、あっという間に落とせるはずだ。適当な場所にダウンロードしたZIPを解凍し、RepairTasks.exe を起動すると下記のウィンドウが表示される。タスクをバックアップし、エラーをスキャンせよバックアップはいつも大事だ。Repar Tasks を実行したら、すぐにウィンドウ右下の Backup Tasks を実行しよう。保存する場所はデスクトップでもドキュメントフォルダでもどこでもオーケーだ。次にウィンドウ左上の Scan ボタンを押すと、大量のエラーが流れていくはずだ（この時の結果をテキストファイルで残しておきたいときには Save Results ボタンを押すこと）。破損したタスクを修復するエラーを検知すると Scan ボタン右にある Repair ボタンが活性化される。迷わず Repair ボタンをクリックしてみよう。タスクの修復が始まると思う。ただし、すべてのタスクが修復できるとは限らない。おそらく 31個ほどのエラーが残る。これは Windows10で実行されるタスクが残っているために発生するエラーなので、致命的なエラーではない。 Windows7 を再起動してみようとりあえずはこれで必要な修復は終わったはずなので、Windows7 を再起動させてみよう。ExcelなりWordなりメモ帳なりを立ち上げて、日本語入力ができるようになっていれば復旧は成功だ。あとは暇なときにタスクマネージャを開き、根気よくエラー画面のOKボタンを押してから、タスクのフォルダをひとつひとつ開いてエラーが出るタスクを削除していけばいい。その他の障害が併発する場合もある以上の手順だけで復旧がついた場合は比較的幸せだ。中には Windows10 自体が正常に起動しなかったり、Windows7 のデスクトップアイコンが表示されなかったりする場合がある。 Windows10 自体が正常に起動しない場合は Shift+再起動 Windows10 自体が正常に起動しない場合には、なんとか Ctrl+Shift+ESC でタスクマネージャを表示させて、再起動アイコンを表示させよう。そして Shiftキーを押しながら再起動アイコンをクリックしてみよう。これは Windows 8 以降のセーフモードの起動方法だ。この方法で再起動すると起動オプションの選択ができるようになるので「トラブルシューティング」－「詳細オプション」から Windows 7 への復元の道が開くはずだ。 Windows 7 のデスクトップアイコンが表示されなくなった場合実際に起こったことなのだが、Windows 7 のデスクトップアイコンが表示されなくなったケースもある。この場合の対処は極めて簡単で、デスクトップ上の任意の位置（どこでもいい）で右クリックして、「表示」メニューから「デスクトップアイコンの表示」をチェックするだけでいい。今後も半強制アップグレードは続くこの半強制アップグレードによって多くのエンドユーザ・システム管理者・システム担当者の貴重な時間が浪費されたことだろうが、おそらくこれで終わりではないだろう。また復旧方法が見つからず、泣きながらひとつひとつエラーを復旧している担当者もいるかもしれない。私自身、この復旧方法を見つけ出すために数時間を費やした。同様の現象で悩んでいる日本の Windowsユーザの一助となればと考え、手順をまとめてみた。あらかじめ準備をしていたわけではないのでスクリーンショットは用意できなかったが、明日も本件のサポートでエンドユーザ企業に訪問するので、できればもう少し整備した情報にしたい。
2014.11. 7
開発プロセス

共通フレーム2013をベースに開発プロセスを見直してみたその4

前回のおさらい共通フレーム2013をたよりに構成管理プロセスを見直しました。登録対象や手順を設けました。しかしながら、開発現場からは「ソースファイルに恨みのコメントを刻むのに役立っている」と。。。耳を傾けたこと「開発プロセス見直しの担当者」が現場の声に対応したのは、構成管理プロセスのみ。つまり「最終成果物を探すのが難しい」の1点のみ。現場の声を聴いたのは自己満足のため！？ ■開発部の声当時の担当者がもういないようなシステムの改修依頼が来た際、改修の経緯がわからず、仕様判断に困ることがある。プロジェクト用ファイルサーバーはプロジェクトごとに管理方法が異なるので、最終成果物を探すのが難しい。担当者が退職した場合だと、引き継ぎから漏れたプロジェクトの最新ソースを探すのに一苦労した。過去の見積契約内容をたどりたい場合、見積番号を調べにくい。現状では見積書ファイルは顧客名＋案件名等で管理されているが、見積番号はファイルを開かないとわからない。 ■経営層の声プロジェクトを横断的に進捗把握できるツールがないため、個人の主観が混じった進捗報告を個別に聞いている。小規模案件を多数受注している場合、誰があいているのかわかりにくい。対応期限でスケジュールが引かれているケースもあるため、案件引合時に空きリソースを判別しにくい。関連するプロセスを見出す必要がありそうです。現場の声1．改修の経緯がわからず、仕様判断に困ることがあるそもそも「改修」ってなんのことか？改修は改修だろう。。。google先生に頼らずに自分で考えてみることにします。「システムの仕様を変更し、プログラムに変更を加えること」「システムリリース後の機能変更や追加」。これはシステムを利用する人の視点でしょうか。プログラマ視点で考えると、システム構築中でも「作成終了したプログラムを修正するケース」もあてはまります。ここでは改修を「システムの要件、システムの仕様、ソフトウェアの仕様、プログラムの仕様に変更を加えて、システムを再リリースするまでのプロセスこと」と定義します。では、「改修の経緯がわからず」とはなんのことでしょう？シチュエーションを想像すると、お客様から「システムが出力している合計金額が合わない」との連絡を受けたシステムエンジニアが調査したところ、プログラムは設計書のとおりに金額出力していた。ただ設計書の改訂履歴を見ると、お客様からの指摘により改訂されて現仕様になっていた。この改訂を破棄して元の仕様に戻せばよいのだが、なぜこの改訂がなされたのか、知る人がいない。お客様に確認しても、「そんなことあったかなぁ。あったような気がするなぁ。どうだったかなぁ。わからないなぁ。そっちで何とかしてよ」との回答をいただいた。そしてシステムエンジニアは重たいため息をついた。システムエンジニアが、機能追加しようと設計書を読み込んでいたところ、矛盾した仕様を発見した。改訂履歴をみたところ、仕様変更があり複数の機能に同じ処理を追加しているが、特定の機能だけは他と同じ仕様にすることはできない。このままの仕様だと、システムの要件を一部満たすことができない。それでも良いという合意のもと対応されたのか？お客様もシステムエンジニアにもわからない。そしてお客様とシステムエンジニアは苦笑いをした。プログラマが、修正作業のため修正箇所を確認していると、理解できない謎のロジックが追加されているのを発見した。プログラムの部分的な修正だけと踏んでいたが、このロジックがあるために、どのような影響を与えているのか全体的に調べなくてはならない。面倒なのでやりたくない。システムエンジニアにこの修正目的を確認しても知る人がいない。そしてプログラマはイライラした。このような状況下で、「仕様判断」は何をさしているのか。過去の対応が不完全なため、変更した内容をそのままとすべきか、変更を加えるべきかの判断。最後に、「困る」とはどういうことでしょうか。お客様が「正しい仕様？そんなの覚えてねぇー、いいからやれと」おっしゃるが、「やれ」を実施するのがハイリスク。何か問題がおこったら、どうせ、めちゃくちゃ怒られるんだろう。こんな担当やりたかない。仕様を提示した通りに修正してくれればよいのに、プログラマが悲鳴をあげている。うるさい。進捗ミーティングの際、横柄な態度をとるようになった。なんでこんないい加減な仕事をどいつもこいつもしてるんだ、今日中に完了しろと言われているのに、こんな広範囲な作業できるか。腹たつなぁ。なるほど、これは困る。「ソースファイルに恨みのコメントを刻むのに役立っている」という理由をよーく理解できる。人間味ある対応「改修する」人たちは、なにかしらの矛盾を見つけたとき、矛盾を生み出した経緯を知りたがります。そして過去の記録を探しまわります。矛盾が解消されてもされなくても、探し回る手間に不満を感じます。どう対応すべきでしょうか？愛で解決する。これに尽きるのではないか。しかし「プロセスに不具合があるから問題が生まれる」と信じ、過去のプロセスを探ることにします。共通フレーム2013からプロセスを想像してみるいずれの問題も、過去の改修は仕様変更の手続きにのっとり、お客様のレビューも実施しています。プロジェクトごとに管理方法がことなり、変更結果だけ記録されたものがほとんどでした。記録上暫定対応なのか恒久対応なのか判断できなく、複数の当事者間でことなる認識のケースもありました。共通フレーム2013「1.3 合意・契約の変更管理プロセス」では、以下のように定義されています。合意・契約の変更管理プロセスの目的は、取得者と供給者の二者間で締結した契約内容に影響を与える変更要求が生じた場合、二者間で合意できる新たな契約内容を導くことにある。このプロセスは取得者または供給者の変更要求の提示で始まり、変更要求の取り下げ、全部又は一部了承など二者が合意する結論で終わる。契約にかかわる変更については、お客様との取り交わしが厳密に行われており、今回ヒアリングしたケースはマッチしませんでした。共通フレーム2013「2.2.6 要件の記録」では、以下のように定義されています。要件定義者は、ライフサイクルを通して及びその後も、要件管理に適した形式で、利害関係者要件を記録する。この一文を読んだとき、ある先輩ＳＥの発言がフラッシュバックしました。小規模だからと言って、要件定義をさぼっていないか？新規にシステムを構築する場合、要件をまとめあげるシステムエンジニアがいて、システムを設計・製造するメンバーとは別の人が行うことが多いです。そして、無事リリースされてから数年後、お客様からちょっとした改修したいことが列挙された要望リストが提示されることが少なくありません。この改修を担当する人は、設計・製造を担当していたシステムエンジニアやプログラマであることがほとんどです。そして、彼らは要件定義を見直すほどの、改修はないと判断しがちです。よく知っている設計書に新しい仕様を追記していくのです。改版履歴もきちんと残して。。。「ライフサイクルを通して及びその後も」というのはとても重い言葉です。当たり前のことを実行することほど難しい。予算との兼ね合いで要件は知らないけど、「こんな画面、こんな機能を作る。」と宣言してしまえば、システムは構築できてしまいます。本当にお客様のためになるシステムづくりの基本は、お客様の視点を持つことすなわち要件定義者は、ライフサイクルを通して及びその後も、要件管理に適した形式で、利害関係者要件を記録する。この考え方を、実践しているプロジェクトもありました、プロジェクト開始後、設計書の修正から入るのではなく、少ない工数をやりくりしながら改修の目的、経緯、対応方針をA3用紙1ページにまとめあげ、要件にかかわる事項をお客様と共有してから、設計作業に入っていました。共通フレーム2013からプロセスを開発プロセスを見直してみる小規模な改修案件の多くの場合、要件は見積の前提に記載され、設計者が要件定義書で合意する内容が見積書の前提条件に記載されます。そのため、WBSに、要件定義作業が割愛されケースが目立ちます。お客様との要件の合意は見積書なされるからです。社内の見積作成の流れを要約すると次のとおりです。担当者アサイン見積者の決定要求仕様の把握担当者による要求・要件仕様の把握担当者アーキテクチャの検討開発部1次レビュー開発工数の算出開発規模の把握標準工数の算出 WBS作成開発スケジュールの検討要員配置工数最終決定見積仕様作成開発部2次レビュー見積承認見積書作成開発部3次レビュー会社レビュー顧客提示 2.3.開発部1次レビューでは、業務機能とシステムの実現可能性を中心にレビューが行われます。4.4.開発部2次レビューでは工数や前提条件の妥当性を中心に判断が行われます。5.2.開発部3次レビューでは事務手続き上のチェックが行われます。要件定義が必要かどうかを決定するプロセスについて、共通フレーム2013では「テーラリング」とよばれるタスクが定義されています。社内の手順ではテーラリングに相当するタスクはありません。 2.3.開発部1次レビューのタイミングで、テーラリングを行うよう社内のルールを変更します。テーラリングには標準ＷＢＳの準備が必要になるため、合わせて作成することにしました。次回は標準WBSの作成を行います。
2014.9.25

ネットショップのASPサービス【カラーミーショップ】を検証する　その2

前回は、ネットショップとはなんぞや、どのようにして構築するのかなどを書かせていただきました。今回はネットショップのサービスの比較と、ネットショップのAPSサービス「カラーミーショップ」について書きたいと思います。ネットショップサービスの種類前回も書きましたが、ネットショップを立上げるにあたって、どのようなことをやりたいか、現状はどんな状況なのか、管理者の構築スキルはどの程度持っているか、費用はどの程度使えるかなど、条件に合ったサービスを利用ことが重要です。ここでは、各サービスの概要と所感を簡単に説明致します。ショッピングモール出店既にあるショッピングモール（有名なところだと、楽天市場、Yahoo!ショッピング、DeNAショッピングなど）に出店するサービスです。有名なモールの場合は集客率が高いため注目度は高くなりますが、その分月々の料金は割高で売上手数料も必要です。また、個々のショップとしてのアピールがしにくい、顧客データ所有権はモール側にある、ショップデザインや運営方法に制限があるというデメリットがあります。多少コストがかかっても商品を多くの人に見てもらいたいなど注目を集めたい場合にはこのサービスが最適だと思います。カート付きのネットショップ ASP(クラウド)サービス会社が構築した、カート付きのホームページが構築できるサービスです。「カラーミーショップ」もこれに属します。他にもショップサーブやe-shopsカート2などがあります。サービスのレンタル料を支払えば、商品情報と商品画像があればすぐに出店することができます。このサービスは大体無料お試し期間があるので、やりたいことを具体的にしてから、実際に使ってみて必要な機能がそろっているかを確認すると良いと思います。また、サービス会社のサポートが充実しているか確認しておいたほうがよいでしょう。サイトデザインもテンプレートがいくつか用意されているところがほとんどなため、難しい知識がなくても簡単にショップを立ち上げられます。大手のショッピングモール（楽天など）と比べると集客力は弱いですが、その分売上手数料が不要なのでコストを抑えることができます。カートのみを設置するサービスカート機能のみをレンタルするサービスです。e-shopsカート2、SHOP-Maker、エクスカートなどが有名です。カート機能をサイトにリンクを貼るだけです。商品管理、顧客管理、決済機能などカート付きネットショップで使える機能はほぼこのサービスで利用できます。既にあるサイトからネットショップを立ち上げたい場合やサイト自体は自前で作りたい場合などに適したサービスです。集客力はないので自分で集客する必要があります。カート付きレンタルサーバ貸出サービスレンタルサーバー会社が、高機能なショッピングカートシステムを提供しているサービスです。ショップサーブ、カラーミーショップ for ロリポップ、アップテンポなどが有名です。レンタルサーバにショッピングサイトがついている形なので、サーバーのメンテナンスはサーバー会社が行います。レンタルサーバなのでネットショップ以外にもサイトを立ち上げたり他のサービスを立ち上げたい場合などには適していますが、その場合は専門知識が必要となります。管理・運用をシステム会社にお願いしている、またはお願いする場合に適したサービスです。集客も自分で行う必要があります。ネットショップ構築ソフトサービスとは異なり、ネットショップのパッケージを購入します。一度購入すれば月のレンタル費用が掛からないというメリットはありますが、自分でネットショップを立ち上げるために必要な各種機能の専門知識や、立ち上げるためのコスト（サーバやドメイン、etc..）がかかるため、専門知識がない方にはおすすめできません。ネットショップ・オーナー、ダヴィンチ・カート、ホームページ・ビルダーなどがあります。カラーミーショップをつかってみた感想ネットショップを試験的にやってみたいがお金をあまりかけたくないという方に一番適しているサービスが「カート付きのネットショップ」です。その中で「カラーミーショップ」が手ごろな値段で知名度も高かったので試しに構築してみましたが、マニュアルの通りに進めると簡単にネットショップを立ち上げることができました。初心者でも比較的簡単に立ち上げることができると思います。デザインも複数のテンプレートが用意されてます。30日間無料お試し期間があるので興味のある方は気軽にできると思います。試しに立ち上げてみてはどうでしょうか？ ※ショップの立上げ方については、カラーミーのマニュアルに具体的に記載されているためここでは書きません。カラーミー立上げの流れ１．ショップを立ち上げるカラーミーのトップページで、ショップのアドレス、メールアドレス、パスワードを入力し「ショップを開く」ボタンを押下すると、入力したメールアドレスに登録完了通知がきます。この時点でネットショップのサイトが立ち上げられます。※この段階ではまだ開店していません２．開店手順マニュアルの開店手順に従う。概要は次の通り。（1) 商品を登録（2) トップページの設定（3) 特定商取引法を設定（4) ショップのデザインを設定（5) 支払い方法を設定（6) 配送方法を設定（7) プライバシーポリシーを設定（8) メールを設定（9) 商品のテスト購入（10) ショップを開店これで、ネットショップが開店しました。失敗した事例カラーミーショップを利用してみて失敗した事例があったので、ここに記したいと思います。別サイトからカートに入れる機能「どこでもカラーミー」がうまく使えないやりたかったことは、カラーミーショップのサイトとは別のサイトでもカートに入れたりカートの中を参照したかったので、「どこでもカラーミー」というカート機能を使用してみましたが、機能追加したサイトでカートにいれた商品を確認する画面にいくと、カートに入っていませんでした。サポートセンターに問い合わせてみたところ、カラーミーショップのドメインと別ドメインのサイトが異なるため商品の同期がとれていないことが原因でした。この機能を実現させたい場合は、機能追加したサイトのドメインを同社のムームードメインに変更して下さいという話でした。結局ドメインを変更するのも大変だったので、そのサイトからはカラーミーショップへのリンクを張り、買い物自体はカラーミーショップで行うことで解決しました。この事例のようなケースはあまりないとは思いますが、参考までに書かせてもらいました。
2014.7.31

Linuxサーバにアンチウィルスソフトをいれてみた

Centos6 にアンチウィルスソフトをいれてみた。セキュリティ強化の一環としての導入です。アンチウィルスソフトはフリーでマナーな、「Clam AntiVirus」を選択しました。事前準備「Clam AntiVirus」は、初期のyumのリポジトリには入っていないので、RPMforgeリポジトリを使用できるようにしておきます。 Clam AntiVirusのインストール #yum install clamd #yum install clamav-devel Clam AntiVirusの設定 root権限で動作するようにするため、以下の設定を変更 #vi /etc/clamd.conf User clamav ↓コメントアウトします。 #User clamav Clam AntiVirusの起動 #service clamd start Clam AntiVirusの自動起動設定 chkconfig clamd on chkconfig --list | grep clamd (確認) ウィルス定義ファイル更新機能の有効化 #vi /etc/freshclam.conf Example ↓コメントアウトします。 #Example ウィルス定義ファイル最新化 # freshclam コマンドを実行すると最新化されます。 ※以降はcronで日時更新されるようになります。ウィルススキャンテストコマンド実行するとウイルススキャンが実行されます。 # clamscan --infected --remove --recursive ----------- SCAN SUMMARY ----------- Known viruses: 3505561 Engine version: 0.98.3 Scanned directories: 7231 Scanned files: 28336 Infected files: 0 ← 0なので問題なし Data scanned: 155.20 MB Data read: 549.99 MB (ratio 0.28:1) Time: 57.475 sec (0 m 57 s) ■結果 Infected filesが 0なので問題なしテスト用のウィルスをダウンロードしてやってみる # mkdir test # cd test/ # wget http://www.eicar.org/download/eicar.com # clamscan --infected --remove --recursive /root/test /root/test/eicar.com: Eicar-Test-Signature FOUND /root/test/eicar.com: Removed. ----------- SCAN SUMMARY ----------- Known viruses: 3505561 Engine version: 0.98.3 Scanned directories: 1 Scanned files: 1 Infected files: 1 Data scanned: 0.00 MB Data read: 0.00 MB (ratio 0.00:1) Time: 6.675 sec (0 m 6 s) ■結果 Infected filesが 1 で検知ダウンロードした「eicar.com」が正常に削除されてた。ウイルスチェック定期実行用にスクリプトを作成 /etc/cron.daily/ に作る事でcronで定期実行させる #vi /etc/cron.daily/clamscan 以下の内容で登録 #!/bin/bash PATH=/usr/bin:/bin # clamd update yum -y update clamd /dev/null 21 # excludeopt setup excludelist=/root/clamscan.exclude if [ -s $excludelist ]; then for i in `cat $excludelist` do if [ $(echo "$i"|grep \/$) ]; then i=`echo $i|sed -e 's/^\([^ ]*\)\/$/\1/p' -e d` excludeopt="${excludeopt} --exclude-dir=^$i" else excludeopt="${excludeopt} --exclude=^$i" fi done fi # virus scan CLAMSCANTMP=`mktemp` clamscan --recursive --remove ${excludeopt} / $CLAMSCANTMP 21 [ ! -z "$(grep FOUND$ $CLAMSCANTMP)" ] \ # report mail send grep FOUND$ $CLAMSCANTMP | mail -s "Virus Found in `hostname`" root rm -f $CLAMSCANTMP パーミッションを変更実行権限を付加しておく #chmod 755 /etc/cron.daily/clamscan 除外指定について先ほどのスクリプト内に指定した以下のファイルに記載することでウイルスチェックを除外したいフォルダやファイルを指定できます。 /root/clamscan.exclude 追記例 echo "/sys/" >> /root/clamscan.exclude 以上で設定完了です。
2014.4.23
開発プロセス

共通フレーム2013をベースに開発プロセスを見直してみたその3

前回のおさらい「共通フレーム2013」を入手し、開発プロセス再構築についてのディスカッションを繰り返した結果、問題の本質を把握することの重要性に気が付いたのでした。現場の声「現場」を「開発部」とした場合、と「経営層」とした場合では、問題の質が大きく異なることがわかります。 ■開発部の声当時の担当者がもういないようなシステムの改修依頼が来た際、改修の経緯がわからず、仕様判断に困ることがある。プロジェクト用ファイルサーバーはプロジェクトごとに管理方法が異なるので、最終成果物を探すのが難しい。担当者が退職した場合だと、引き継ぎから漏れたプロジェクトの最新ソースを探すのに一苦労した。過去の見積契約内容をたどりたい場合、見積番号を調べにくい。現状では見積書ファイルは顧客名＋案件名等で管理されているが、見積番号はファイルを開かないとわからない。 ■経営層の声プロジェクトを横断的に進捗把握できるツールがないため、個人の主観が混じった進捗報告を個別に聞いている。小規模案件を多数受注している場合、誰があいているのかわかりにくい。対応期限でスケジュールが引かれているケースもあるため、案件引合時に空きリソースを判別しにくい。開発部からの声は、構成管理にまつわる内容が半数をしめており、引合から保守作業の情報と成果物との紐づきに問題が集中していることが分かりました。経営層からは、状況把握に関する内容が主であり、プロジェクト状況の共有方法について課題があることがわかりました。まずは構成管理プロセスの見直し現状の構成管理は、Subversion、Git、VSS、TFSなどの構成管理システムがプロジェクトごとに構築されている状態です。また、ファイルサーバー上に開発機を仮想マシンごと格納するといった特殊なケースもありました。構成管理の対象も、ソースファイルだけのプロジェクトもあれば、リリースモジュールを含めているもの。ドキュメントも構成管理システムに格納しているものもあります。「共通フレーム2013」によると、「ソフトウェア構成管理プロセス」と比較すると、 a) ソフトウェア構成管理戦略が作成されている。→構成管理手順は個別に作成しているケースもありますが、構成管理の手順がルール等を文書化したものはありません。 b)プロセス又はプロジェクトによって生成される品目が識別され、定義され、ベースライン化されている。→管理対象のベースライン。。。ありません。 c)品目の修正及び、リリースが制御されている。 d)品目及び修正の状態が記録され、報告されている。 e)品目の完全さ及び一貫性が確保されている。 f)品目の保管、取扱い及び納入が制御されている。→リリースの単位ごとにタグ打ちしているプロジェクトもありましたが、多くのプロジェクトでは、コミットをしているだけの状態です。→チケットシステムと構成管理システムが連動していないため、コメントを頼りにトレースすることになります。厳密な管理はできていません。かいぜん社内の構成管理サーバーをＧＩＴに統合し、ガイドラインを設けることにします。ソフトウェア構成管理のガイドライン抜粋管理対象物を次の通りとする。ソースプログラムソフトウェアビルドに関するコンフィグレーションファイル納品対象のプログラム実行ファイル納品対象のドキュメント納品対象のコンフィグレーションファイル管理対象物は、構成管理サーバー（資産管理番号ＸＸ-ＸＸＸＸＸ）で管理する。※GIT利用手順参照リビジョン設定のベースラインを次の通りとする。リリース・納品時管理対象物を社外へ提供する時構成管理サーバーに過去資産を移行し、社内に周知しました。社内周知の抜粋寄せ集めであるわれわれのGitリポジトリは弱さではなく、力であることを知っている。われわれはSVN教徒、VSS教徒、TFS教、Git教、そして無信仰の人々の開発部である。帯広市内から来たさまざまな開発文化がわれわれを形づくっている。われわれはソースデグレードやドキュメント不備による仕様祖語の苦渋を味わい、暗い歴史を超え強く立ち上がり、団結を強めた。だからこそ、過去の不在担当者への憎しみは乗り越えられると信ぜずにはいられない。開発文化間の隔たりは解消され世界が小さくなるにつれ、共通の人間性が現れると。そして、開発部は新たな構成管理サーバーへのライブラリアンとしての役割を務めねばならない。ありがとう。バラク・オバマ。ありがとう。どうしんウェブ。そして歴史は繰り返す社内統一の構成管理サーバーを構築し、利用手順やガイドランも設け、自分の仕事は終わった感でいっぱいになった「開発プロセス見直しの担当者」は、高楊枝で過ごしています。しかし、開発部員から「問題が解決していない」との声が聞こえ始めます。われわれはソースデグレードやドキュメント不備による仕様祖語の苦渋をGitリポジトリに深く刻むことを覚えた。だからこそ、過去の不在担当者への憎しみは乗り越えられる。しかし、深く刻まれたコメントだからこそ、聞こえてくるのは呪いの言葉だけである。次回は構成管理サーバーを構築し格納対象を決めたにも関わらず何が足りていないのか。「共通フレーム２０１３」をベースに現場の声を取り込みます。
2014.4. 9

ネットショップのASPサービス【カラーミーショップ】を検証する　その1

ネットショップのAPSサービス「カラーミーショップ」を検証することになりました。そもそも商品を購入したことはあっても、ショップを構築すること自体が未経験だったので、まずは「ネットショップとはなんぞや？」から調べていきたいと思います。ネットショップとは？「ショッピングサイト」「オンラインショップ」などともいわれており、インターネット上で買い物ができるサイトのことです。ネットショップの一般的な購入の流れは次の通りです。【処理フロー】１．購入者：商品を注文（１）商品をカートに入れる（２）個人情報を入力（３）送付方法を選択（４）決済方法を選択（５）注文を確定２．ショッピングサイト：注文情報(購入した顧客情報、商品と在庫情報)が登録(更新)される３．ショッピングサイト：注文情報の通知（メール通知）（１）購入者に注文完了を通知(ご注文ありがとうございます。注文を受付けました。など) （２）ショップ管理者に受注情報を通知（注文がきています。受注しました。など）４．ショップ管理者：商品の発送手続き（１）在庫確認（２）決済方法確認（入金が確定するまで発送しない）（３）ショッピングサイトの受注～発送処理（在庫状況、発送状況などの更新）５．発送完了通知（メール通知）ネットショップをどのようにして構築するか現在ネットショップは、ネットショップ自体を立上げるサービスや、カート機能のみ利用できるサービス、ネットショップ構築パッケージなど、様々なものがあります。ネットショップを立上げるにあたって、どのようなことをやりたいか、現状はどんな状況なのか、管理者の構築スキルはどの程度持っているか、費用はどの程度使えるかなど、条件に合ったサービスを利用ことが重要です。例として、前提条件を次に挙げるので参考にして下さい。（１）どのようなことをやりたいかショッピングサイトのこだわりデザイン重視独自の操作を行いたい商品を公開して注文が来るのであれば、こだわらない管理形態自社（または個人）でネットショップのサーバーを構築したいサーバーは管理できない（２）現状はどんな状況なのかネットショップを一から構築する公開しているWebサイトが既にあり、ネットショップを追加したい（３）管理者の構築スキルはどの程度持っているか何も知らない HTML、CSS、JavaScriptの知識がある CMSサイト(MT)の構築ができる（４）費用はどの程度使えるのか今回は次のような条件を考えようと思います。個人でネットショップを立ち上げたい商品を公開して注文が来るのであれば、大くは望まない(多少の修正ができればいい) サーバー管理はできない費用はなるべく抑えたい（人件費をなるべく抑えたい）ネットショップを試験的に行いたいこれらの条件より探してみたところ有名な候補がいくつか上がりましたが、そのなかでも、「ショップサーブ」と「カラーミーショップ」は多くのユーザーが利用しており、初めての人でも簡単にネットショップを立ち上げられ、サポートも充実しているとのことでした。次回は、「カラーミーショップ」を検証していきたいと思います。
2014.3.14
Linux

WEBサーバを構築してみた

Centos6 でWEBサーバを構築してみた。 yumでインストールするのは簡単ですが、今回は少しセキュリティ面を考慮したインストールと設定について記載します。 Apacheは、時々脆弱性等がみつかりバージョンアップします。標準リポジトリでインストールすると、現時点ではバージョン「2.2.15-29」が入りますがこれは少し古いものです。セキュリティ対策の入ったなるべく新しい物をインストールするために、CentALTリポジトリを使用してApacheをインストールします。 CentALTリポジトリの追加 #rpm -ihv http://centos.alt.ru/repository/centos/6/x86_64/centalt-release-6-1.noarch.rpm Apacheのインストール #yum install httpd httpd-devel #httpd -version Server version: Apache/2.2.26 (Unix) 現時点（2014-03-14）では、バージョン「2.2.26」がインストールされました。リポジトリの優先順位設定このままだと、他の物をインストールする際もCentALTリポジトリを使用してしまうので、「yum-plugin-priorities」をインストールして標準リポジトリが優先されてインストールされるようにします。 yum install yum-plugin-priorities 標準リポジトリ設定ファイルを修正しますすべてのセクションに「priority=1 」を追記します。 #vi /etc/yum.repos.d/CentOS-Base.repo [base] ... priority=1 #←追加 [updates] ... priority=1 #←追加 [extras] ... priority=1 #←追加 [centosplus] ... priority=1 #←追加 [contrib] ... priority=1 #←追加その他Apacheの設定 TRACEメソッドを無効にする「Cross Site Tracing」の脆弱性があり、TRACEメソッドが有効だとBasic 認証のパスワードが盗まれたりします。TRACEメソッドを使用する予定がないので無効にしておきます。 #vi /etc/httpd/conf/httpd.conf TraceEnable Off　#←追加以下のようにtelnetで無効になっているか確認が出来ます。 # telnet localhost 80 Trying ::1... Connected to localhost. Escape character is '^]'. OPTIONS / HTTP/1.0 ← #入力してエンター HTTP/1.1 200 OK Date: Fri, 14 Mar 2014 01:23:39 GMT Server: Apache Allow: GET,HEAD,POST,OPTIONS ← #ここに[TRACE]が無ければOK Content-Length: 0 Connection: close Content-Type: text/html; charset=UTF-8 Connection closed by foreign host. エラー画面等のOS、Apacheバージョンを非表示にする攻撃者に対して余計な情報を与えることになるので非表示にしておきます。 #vi /etc/httpd/conf/httpd.conf #ServerTokens OS ServerTokens Prod ↓こうなります。 ※「Apache Server」の表示を外すには、ソースからのインストールでオプション指定が必要なようです。ソースからインストールするとyum管理から外れる、アップデートや再インストール必要な場合の対応が大変なので、今回はCentALTリポジトリでインストールしてます。以上
2014.3. 8
開発プロセス

共通フレーム2013をベースに開発プロセスを見直してみたその2

前回のおさらいシステム開発の経典を探し求め、ようやく手に入れた「共通フレーム2013」。難解な経典に辟易しながらも、ディスカッションを繰り返すことで問題点の抽出までたどり着く。ようやく開発プロセス再構築のスタートラインに立ったのでした。魔法の杖ディスカッションの目的は、「共通フレーム2013」と比較し作業プロセスに内在する問題点を発見することでした。問題を重みづけし、順次ガイドラインに盛り込んでいくことで、開発プロセスの見直し作業を完了する予定でした。「共通フレーム2013」を読み込むことで開発プロセスが整備される。きっとそうに違いない。なぜなら、あんなに苦労して経典を手に入れたのだから。わたしは、この作業を進めるにあたってかような幻想を抱いておりました。しかし、いくら読み込んでも「魔法の杖」が見つからないのです。【共通フレーム2013 共通フレーム概説より】 1. 共通フレームの目的共通フレームを産業界で「共通の物差し」として用いることにより、国内における「システム及びソフトウェア開発と、その取引の明確化」が可能となるだけでなく、増大するシステム及びソフトウェア開発の国際取引においても相互理解を容易にするなど、市場の透明性を高め、取引のさらなる可視化を実現する。 5.2　共通フレームで取り決めていないこと（１）文書化の詳細を規定しない共通フレームは、文書の詳細な規定は行っていない。共通の物差し。。。文書の詳細な規定は行っていない。。。あッ！わたしに見えていた「魔法の杖」はこの瞬間、「三菱鉛筆」であったことを知りました。なるほど。共通フレームからあるべき作業プロセスをマッピングすることで社内の作業の品質が向上するわけではないということでしょう。それはそうだ。しかしながらせっかく社内の作業プロセスを洗い出しているのですから、前回「共有した問題点」を改善する施策を盛り込むことにします。銀の弾丸共通フレームと社内の開発プロセスをマッピングしただけでは、「やっぱり上流は大事だよね」「手抜きしちゃだめだよね」等々、タスクの「抜かす」「省く」を、ルールとチェックで縛るのが限界です。しかし根本的な問題として「顧客合意したにも関わらずテスト段階、納品後に仕様が変わる」といったタスクの品質については是正できません。テクニカルプロセスに関する、先人たちの知恵が詰まった問題解決メソッドを手に入れるため、あちこちの情報をかき集めました。「発注者ビューガイドラインの公開」むむむっ。IPA頑張っている。先人たちの知恵がまとめられている。今度は「銀の弾丸」を手に入れたここちです。さっそくガイドラインを参考に、いままで使っていた成果物テンプレートの修正作業を行い始め、設計エリアについてテンプレートを修正を行います。問題は何かテンプレートへ「発注者ビューガイドライン」を反映する作業に明け暮れ、ひと段落したとき、グループディスカッションを開催しました。「ルールや担当者の意識が改善しなければ、タスク品質は向上しない」「テンプレートで目に見える問題が解決するのか疑問」恥ずかしながら、テンプレートの作成に没頭しているうちに、テンプレートを作ることがゴールになっていたことの指摘を受け、懐に隠し持っていた「銀の弾丸」は「チオビタドリンクの空き瓶」であったことに気づいたのでした。フレデリック＝ブルックス氏の"No Silver Bullet"（銀の弾丸などない）では、＜wiki pediaから引用＞ソフトウェア開発の複雑性について偶有的な複雑性は、ソフトウェア開発者自身が発生させていて解決可能な問題に間連する。例えば、アセンブリ言語のプログラムコードの記述と最適化や、バッチ処理によりもたらされる遅延は、偶有的な複雑性に由来する。本質的な複雑性は、解決するべき問題によってもたらされる。そして本質的な複雑性を取り除くことはできない。もし利用者が30の異なることを行う1つのプログラムを望む場合、この30のことは本質的であり、開発するべきプログラムはこの30の異なることを実行しなければならない。過去に行われてきたソフトウェア技術の発展は、ソフトウェア開発における偶有的な複雑性を攻略した。ただし偶有的な複雑性に対する攻略であって、本質的な複雑性に対する攻略ではない。利用者が３０の異なることを行うことを望むならば、テンプレートは３０の中に入っていたのか？仕事の仕方。。。次回からは次回は、解決すべき問題が「何を実行することなのか」をスタートラインに、改善策の検討を行います。
2014.1.25
Windows

Windows7機のマザーボードを換装してみた結果、Linuxでレジストリを書き換えてみた

もしマザーボードが壊れたら Windows7もリリースから早くも4年と3ヶ月が過ぎたが(Windows7は2009年10月22日発売)、Windows8.1がリリースされた現在でもいまだ現役で使用され続けている。OSのリプレースがユーザに直接的なメリットを感じさせないことやユーザ・インターフェイスの大幅な変更がユーザの不評を買ったこともあってWindows8系のOSが商業的に成功を見ていないため、しばらくの間はビジネス市場でWindows7が使い続けられるであろうことは想像に難くないが、Windows7がその役目を終えるまで何の問題なく使い続けられる幸運を誰もが持ち合わせているわけではない。ハードウェアには寿命があるからだ。もし寿命の尽きたハードウェアがDVDドライブやメモリや電源であれば話は簡単で、パーツを交換すればすむ話だ。不幸にしてハードディスクがまったく動かなったのなら、Windowsのクリーン・インストールを余儀なくされるだろうし（不幸にしてバックアップを取る習慣のない人にはとても悲しいできごとだけれども）、選択肢が限られている分あきらめもつく。だが、問題はマザーボードに障害が起きた場合だ。 Windowsが起動しないハードディスクには異常がないのだから、他のパーツ同様に交換すればすむんじゃないの？と考えた人（私のことだが）は今のOSを知らない。Windows XPの時代はいざ知らず、Vista以降はマザーボードを換装した場合、Windowsが正常に起動しない。運がよければスタートアップ修復のダイアログを目にすることができようが、結局のところ修復は失敗に終わり、再起動から再びスタートアップ修復を目にする羽目になる。運が悪ければブルースクリーンが表示され、まったく起動しない。これは最近の Windows は初期インストール後に環境に合わせて最適化され必要なドライバしか読み込まないため、引っ越し先のハードウェアに適応していないことが原因だ。したがって、レジストリの書き換えによって生き残ったハードディスクにインストールされたWindowsを初期状態に戻してやる必要があるのだ。ただし、この段階で起動しないことが判明したからには、既にマザーボードは交換済みのはずだ。賢明にしてマザーボード換装前にこのエントリと遭遇した人は、この先を読んでスタートアップ修復（またはブルースクリーン）を回避して欲しい。交換前のマザーボードがまだ生きていて、なおかつ手を動かすことに抵抗のない人は、マザーボードを元に戻そう。そんな面倒なことはごめんだそんな面倒なことは御免蒙（ごめんこうむる）！という人（私のことだが）にも救いの道はある。世の中にはLinuxというOSもあって、Linuxからレジストリを書き換えるためのchntpwというコマンドを開発した偉い人も存在する。Petter Nordahl-Hagen さんというノルウェーの人だが、なんと読むかはわからない。まあ、ペッターさんでいいだろう。読み方はわからなくても感謝の気持ちは大事だ。ペッターさんに感謝しながら使おう。 chntpwが使えればLinuxのディストリビューション（ディストリビューションが何かわからない人はLinuxディストリビューションを読むこと。こんなにたくさんの種類があるので一言では説明できないのだ。）は何でもかまわないのだが、レジストリを書き換えるだけのためにLinuxを利用しようという人には以下のISOイメージをダウンロードして使うことをおすすめする。 Kaspersky Rescue Disk 10 trinity rescue kit Kaspersky Rescue Disk 10 はアンチウイルスなどのセキュリティ製品で有名なカスペルスキーが配布しているツールで、主な目的はウイルスやマルウェアに感染したコンピュータを修復することだが、修復の過程でレジストリの編集が必要となるケースもあってか chntpwがGUIで使えるようになっている。使いやすい分、こちらの方がおすすめだ。 trinity rescue kit は Windowsマシンの復旧・修復用に作られた 1CD Linux（CD1枚で起動するLinuxのこと。Live Linux ともいう。）で、主にコマンドラインから利用しなければならないし、ハードディスクのマウントの知識など Linux のリテラシが必要になるので比較的ハードルが高い。ISOイメージをCDに焼けない人のために Windows上で自動解凍するとCDまで焼いてくれるバージョンも用意されていたりするのだが、こんなものを使おうという人がISOイメージを焼けないなんてことがあるのかという疑問はあるものの、いつでも感謝の気持ちを忘れてはいけない。Kaspersky Rescue Disk 10 が使えない場合にはありがたく使わせていただこう。ちなみにどちらも英語版なので、最低限の英語力は必要だ。中学・高校と6年間も英語教育を受けさせてくれた両親・保護者にも感謝を忘れないこと。 Kaspersky Rescue Disk 10 を起動してみたさっそく Kaspersky Rescue Disk 10 の CD を作成して起動してみた。グレーン基調のスマートな画面が表示され、ハードディスクも自動的にマウントされる。スクリーンショットを見れば分かるように、起動直後にはウイルススキャンのウィンドウが表示され、このディスクがセキュリティ目的のためにつくられたことがわかる。画面左側にあるアイコンには、マウントされたハードディスクを表すフォルダアイコンの他、ファイルマネージャ、レジストリ・エディタの他、ブラウザまで用意されている。このアイコンからレジストリ・エディタ（Registry Editor）をダブルクリックする。レジストリを書き換えるレジストリ・エディタからは HKEY_LOCAL_MACHINE\System 配下に複数あるControlSet（ControlSet001 とかControlSet002など。ControlSet001とかControlSet003 の組み合わせの場合もあるし、2個以上ある場合も考えられる。）以下のキーを修正する。ControlSetはWindowsが起動したときに記録されるシステム・レジストリのセットであり、システムの変更状態によっていくつかのバックアップが取られる。少なくとも前回正常起動時のバックアップと現在の ControlSet の２つが存在しているはずだ。Windows が起動したときに、どの ControlSet が使われるかはHKEY_LOCAL_MACHINE\SYSTEM\Select以下をみればわかるのだが、修正漏れがないようにすべてのControlSet に対して修正を施しておくほうが無難だろう。修正対象のキー修正は最低限（ControlSet001の場合）、 HKEY_LOCAL_MACHINE\System\ControlSet001\Services\Msahci の Startエントリの値を 0 に書き換えてやれば Windowsは起動する。ただし前述の通り、不要なドライバを読み込まないようになっているのは最適化のためなので、逆に不要なドライバを読み込むことによって起動に時間がかかるようになる可能性もある。どれほどの影響があるかは不明だが、以下のキーについても同様に Startエントリを 0 に書き換えておいたほうがいいようだ。 Aliide.sys Amdide.sys Atapi.sys Ataport.sys Cmdide.sys Intelide.sys Pciide.sys Pciidex.sys Viaide.sys まだマザーボードを交換していない、もしくは元のマザーボードに戻した人は、Windows を起動して Regedit で以上の作業を完了させればいい。戦いは終わっていないこれでようやく Windows を起動できるようになったはずだが、これで終わりというわけではない。マザーボードを変更したことで、チップセットをはじめ、LAN・VIDEO・USBその他諸々のドライバも新しいものが必要になっている。交換したマザーボードに添付されているCDから適宜必要なドライバをインストールしよう。おっと、これで終わったと思ってはいけない。マザーボードを交換したことによって Windows7 のアクティベーションが無効になっているからだ。システムのプロパティを表示して、再アクティベーションを行う（詳細はこのコンピューターの Windows をライセンス認証するを参照のこと）。プロダクトキーは今まで使っていたものと同じキーでアクティベーションしてくれるが、もちろん保証の限りではない。ライセンスの問題は各自で解決すること。同様にMS-Officeのアクティベーションも無効になっている可能性が高い。こちらについては Excel や Word を起動すると自動的にアクティベーションを要求されるので、そのままインターネット経由でアクティベーションを実行しよう。私の場合は特に問題もなくアクティベーションが完了した。次回予告勘の良い人はお気づきになったかもしれないが、本来、chntpw とはその名の通り Change NT Password、つまり Windows のパスワードを変更するためのコマンドだ。次回は trinity rescue kit を使って、パスワードがわからなくなったマシンを復旧する方法について書いてみようと思う。
2014.1.23
DNS

DNSサーバを構築してみた

Debian wheezyでDNSサーバを構築してみました。基本的なインストール方法と設定手順を説明します。なお、各正・逆引きファイルの設定内容は省略しています。 BINDインストール #aptitude install bind9 bind9-host bind9utils 設定ファイルの設定 named.confの設定以下の２行のみ設定を有効にする include "/etc/bind/named.conf.options";include "/etc/bind/named.conf.local"; named.conf.optionsの設定 options { directory "/var/cache/bind"; //query-source address * port 53; //コメントアウト auth-nxdomain no; # conform to RFC1035　　　listen-on-v6 { none; }; //IPv6は使用しないので設定 allow-query { 192.168.XXX.0/24; XXX.XXX.XXX.XXX/XX; }; allow-transfer { 192.168.XXX.0/24; XXX.XXX.XXX.XXX/XX; }; version "DNS Server";} 設定内容 //query-source address * port 53 コメントアウトするのは、ポートを固定すると攻撃先のポートが特定されて攻撃へのリスクが高くなります。 allow-query 問合せを許可する範囲を設定します。 allow-transfer ゾーンの転送を許可する範囲を設定します。 named.conf.localの設定各正・逆引きゾーンファイルの設定内容は省略します。なお、ゾーンファイルの命名規則は、内側はファイル名の頭に「db.」＋ホスト名、外側はファイル名の頭に「zone.」＋ホスト名にして、ファイル名で各ホストの外側・内側の設定ファイルがわかりやすいようしています。 view "internal" { match-clients { 192.168.XXX.0/16; 127.0.0.0/8; }; recursion yes; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "one-x.co.jp" { type master; file "/etc/bind/db.one-x.co.jp"; }; } view "external" { match-clients { any; }; allow-query { any; }; recursion no; zone "one-x.co.jp" in { type master; file "/etc/bind/one-x.co.jp.zone"; } ;} 設定内容 view "internal" 内向けのLAN内の設定を記載します。 view "external" 外向けのWAN側の設定を記載します。 match-clients 指定範囲の物が定義を参照します。 recursion 再帰検索の設定。外側の設定は禁止(no)にすること。yesにすると攻撃（不正なリクエスト）に対して再帰検索による不要な検索（管理外のドメインに対する検索）やDNSキャッシュするで、サーバに負荷がかかったりやキャッシュポイズニング等にる攻撃に弱くなるためです。設定の確認以下のコマンドで設定のシンタックスエラーをチェックできます。問題がある場合は、コマンド実行後にエラーが表示されます。表示されない場合は問題ありません。 # named-checkconf /etc/bind/named.conf BINDの起動 #/etc/init.d/bind9 start 動作検証 dnsutils をインストール digコマンドを使うので dnsutils をインストールします。 #aptitude install dnsutils dig コマンドで検証 dig コマンドで AUTHORITY SECTION が正常に取得できることを確認します。以下は、コマンド実施の例です。 #dig @localhost one-x.co.jp MX; DiG 9.8.4-rpz2+rl005.12-P1 @localhost one-x.co.jp MX; (1 server found);; global options: +cmd;; Got answer:;; -HEADER- opcode: QUERY, status: NOERROR, id: 35491;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1;; QUESTION SECTION:;one-x.co.jp. IN MX;; ANSWER SECTION:one-x.co.jp. 86400 IN MX 0 mail.one-x.co.jp.;; AUTHORITY SECTION:one-x.co.jp. 86400 IN NS ns.one-x.co.jp.;; ADDITIONAL SECTION:ns.one-x.co.jp. 86400 IN A XXX.XXX.X.XX;; Query time: 9 msec;; SERVER: 127.0.0.1#53(127.0.0.1);; WHEN: Thu Jan 23 16:26:01 2014;; MSG SIZE rcvd: 83 以上

Category

Archive

Latest Post