Technical Notes

テクニカルノーツ

2014年

  • 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 以上

  • 2014.1.23
    開発プロセス

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

    共通フレーム2013を購入するところから 「独立行政法人　情報処理推進機構（IPA）著　共通フレーム2013」をようやく購入しました。 会社にお願いして昨年手に入れようとしたのですが、書店ではすでに在庫がなく、図書館の蔵書まで探していただきました。司書曰く、「北海道には蔵書がありません。国会図書館か近畿の大学の蔵書ならあります。郵送で貸出しすることができますよ。」 すばらしい。図書館ネットワーク恐るべし。 さらに曰く、「出版社に問い合わせたところ、近々増刷の予定があるそうで、・・・（増刷予定の親切な説明）・・・、お急ぎなら、蔵書を郵送しますか？」 すばらしい。接客の鑑だ。図書館司書あなどりがたし。 結局、増刷後、IPAから直接購入しました。 どう見直すのか 前置きがながくなりましたが、既存開発プロセスを見直し、「共通フレーム2013」を反映します。現状の自社開発プロセスは独自基準。「共通フレーム２０１３」をベースにIPAの各種ガイドラインで再構成します。 長年、当社ではKKD手法をベースとした。。。古代バビロニアから伝わる。。。。プリンシプルな開発手順が数パターン存在しております。それらを案件に応じてテーラリング・実行といったスタイルです。今回の取り組みは「共通フレーム2013」のソフトウェア実装プロセスを中心にマッピングしなおし、不足している基準を検討します。 現状の開発手順「簡便なツール開発レベル」の手順（抜粋） 1. 提案・見積時 1.1 適用業務範囲の妄想 1.2 ツール摘要作業範囲の妄想 1.3 ソフトウェア構成の妄想 1.4 ツール機能一覧洗い出し 1.5 開発規模算出 1.6 WBS作成 1.7 要員スケジュール作成 1.8 開発スケジュール作成 1.9 前提条件作成 2. 受注 3. 設計～テスト 4. 納品～検収～売上 共通フレームのソフトウェア実装プロセスに強引にマッピングすると、、、 共通フレーム2013のソフトウェア実装プロセスのアクティビティを自社の「簡便なツール開発レベル」に当てはめてみると、小規模開発の場合、要件定義は見積、引合段階で行うことがほとんどで、以下のようになりました。 2.4 ソフトウェア実装プロセス 2.4.1 ソフトウェア実装プロセス開始の準備プロセス →1.6 WBS作成 2.4.2 ソフトウェア要件定義プロセス →1.1 適用業務範囲の妄想 →1.2 ツール摘要作業範囲の妄想 →1.3 ソフトウェア構成の妄想 →1.4 ツール機能一覧洗い出し →1.9 前提条件作成 2.4.3 ソフトウェア方式設計プロセス →1.3 ソフトウェア構成の妄想 →1.9 前提条件作成 マッピング結果をベースに社内で検討した結果 ソフトウェア要件定義プロセスは、設計の開始時点もしくは、基本設計の初期段階で「発注者ビューガイドライン　システム振舞い編」に従った作業が終わった状態とイコール。小規模でも（ドキュメントとしては枚数がすくないかもしれないが）、ソフトウェアをブラックボックスとした発注者視点のできることとできないことを書面で合意しておくことが必要ではないか。 ソフトウェア実装プロセス開始の準備プロセスは、小規模であるからといってタスクをまとめるだけではなく、「EVM活用型プロジェクト・マネジメント導入ガイドライン」に従った管理指標を設定する必要があるのではないか。 小規模案件はとくに顧客に費用転嫁しないよう、管理資料に時間をかけすぎない工夫が必要。 等々 検討してわかったこと 小規模だからと言って、要件定義をさぼっていないか？ 要件定義が不要なのではなく、設計開始時点で明確になっているから工程として設けていないだけ。 少人数だからと言って、実績工数管理をさぼっていないか？ だいたいでは済まされない、積み重ねが見積精度の改善・向上につながる。 反映作業はこれから、、、 2014年4月までに完了させる予定です。経過は順次公開していきます。（できる範囲ですが） →次回　共通フレーム2013をベースに開発プロセスを見直してみた その2

  • 2014.1.23
    ネットワーク

    SoftEther VPNのリモートアクセスVPN機能を使ってみた

    はじめに 外出先から社内イントラへのアクセスや、自社とビジネスパートナーとのアクセスを安全に行いたいと思ったことはありませんか？（例えば外出先で、自社イントラ環境からしかアクセスできないアプリを利用したいなど） これらを解消する方法の一つに、外部環境が自社イントラであるかのように通信を行うことができる「VPN」がありますが、VPN専用機器の購入や、サービス費用などコストがかかってしまうために（お金がない人にとっては）簡単に行うことができませんでした。 しかし、最近知った「SoftEther VPN」は無償公開されており、専用機器も（仮想HUBが作られるため）不要のためコストがかかりません。 SoftEther VPNとは VPNは「仮想ネットワーク」を構築するためのソリューションです。VPNでは、既存の公衆IPネットワークの中の離れた2地点の間で仮想ネットワークを構築し、その中で自由な通信を可能とするために「トンネリング」と呼ばれる手法が使用されます。VPN 通信の起点と終点との間で「トンネル」と呼ばれるセッションを通じてカプセル化されたデータが伝送されます。この手法を行うことで、生のデータがネットワーク上を流れることはありません。 SoftEther VPNは、「Ethernetの通信の仕組みをそのままソフトウェアで実装し仮想化することによってVPNを実現する」ソフトウェアです。 基本的な通信方式は、Ethernetに対応した通信装置（LAN カード）を持ったコンピュータ同士が、スイッチングHUBにつながることで自由に通信することができます。SoftEther VPNでは、「スイッチング HUB」や「LAN カード」を仮想化することによって、VPN 通信を実現しています。 SoftEther VPNで実現することができるネットワークには、大きく分けて以下の3つの形態があります。 コンピュータ間VPN リモートアクセスVPN 拠点間接続VPN これらの形態を使い分け、または組み合わせて複雑なVPNを構築することも可能です。 「コンピュータ間 VPN」は、一箇所に設置した VPN Server の仮想 HUB に対して、VPN Clientの設定をした複数台のコンピュータの仮想LANカードを接続することにより、VPNに参加しているコンピュータ間で自由な通信が安全に行えます。ただし、それ以外のコンピュータを VPN に参加させることはできません。 「リモートアクセス VPN」は、インターネットからは直接アクセスすることができないネットワークに、出張先や自宅などのコンピュータから自由にアクセスを行うことができます。1つの拠点に対して、外部から複数台のVPN Clientをインストールしたコンピュータが、リモートアクセスすることができます。実現するためには、社内LANにVPN Serverを設置し、そのVPN Server内に作成した仮想HUBと、既存の物理的なEthernetセグメントとの間を「ローカルブリッジ接続」によってブリッジ接続します。 「拠点間接続 VPN」は、物理的に離れた場所にある複数の拠点同士を接続することができるVPN接続方法です。複数の離れた拠点の物理的なレイヤ2セグメント同士が1つのセグメントとして認識されます。 セットアップしてみる VPNを利用する目的は様々なので、「SoftEther VPN」でどこまでできるかはこれから検証していくことになりますが、まずは使ってみようと思います。 今回は個人的にも興味のある、外部ネットワークから社内環境へアクセスできる「リモートアクセスVPN」を試してみます。 尚、正規ドキュメントは、SoftEtherドキュメント(日本語)にあるので困ったときには参照しますが、とりあえずはマニュアルなしでセットアップしてみます。 １．インストール インストール先はVPN接続元、接続先ともにWindows7で行います。 VPN接続元にVPNサーバ、VPN接続先にVPNクライアントをインストールする必要があります。ダウンロードしたインストーラは次の通りです。 softether-vpnserver_vpnbridge-v4.04-9412-rtm-2014.01.15-windows-x86_x64-intel.exe softether-vpnclient-v4.04-9412-rtm-2014.01.15-windows-x86_x64-intel.exe インストール自体は簡単なので手順は割愛します。 ２．セットアップ ２．１．VPNサーバ （１）VPN Serverへの接続設定で「新しい接続設定」で新規追加 接続設定名を入力 接続先VPN Serverの指定で「このコンピュータ(localhost)に接続」にチェック 管理パスワードを入力 他はDefault （２）接続設定を選択し、接続ボタンを押下（VPN サーバー管理マネージャが表示） （３）仮想HUBを作成（「仮想HUBの作成」ボタン押下） 仮想HUB名を入力 仮想HUBの管理用パスワード入力 他はDefault （４）利用ユーザーを追加（「仮想HUBの管理」ボタンを押下し、「ユーザーの管理ボタン」押下） ユーザー名を入力 パスワードを入力 他はDefault （５）ダイナミックDNS設定の確認（VPNクライアントでサーバー接続先として利用する） 割当てられているダイナミックDNSホスト名 ２．２．VPNクライアント （１）接続設定の作成（「新しい接続設定の作成」押下） 接続設定名を入力 ホスト名を入力（上記で確認したダイナミックDNSホスト名を入力） ユーザー認証（ユーザー名、パスワード）を入力 他はDefault 動作確認 VPNクライアントで設定した接続設定名をダブルクリックして接続してみました。「VPNサーバーに接続しました」というダイアログが出力されたので、接続が成功しているかをping(接続先のプライベートアドレス)で確認したところ、通りませんでした。（接続失敗） 原因の調査 いろいろ試しましたが上手くいかず、結局正規のマニュアルを参照することで解決しました。 VPN Server側の問題で、ローカルブリッジ接続がされていませんでした。 ローカルブリッジとは 「VPN Serverで動作している仮想HUB」と「そのサーバーコンピュータ上に接続されている物理的なLANカード」間を接続し、もともと別々のEthernetセグメントで動作していた２つのセグメントを１つのセグメントに結合する機能 で、この設定を追加していなかったためセグメントが分かれたままの状態であったことが原因でした。 VPN Serverの設定を変更 VPN管理マネージャの「ローカルブリッジ設定」を行う。 （１）ブリッジする仮想HUBに、登録した仮想HUBを選択 （２）ブリッジ先のEthernetデバイス（LANカード）を選択 （３）「ローカルブリッジを追加」を押下し、ローカルブリッジを作成 再度動作確認 VPNクライアントで設定した接続設定名をダブルクリックして接続したところ、「VPNサーバーに接続しました」ダイアログの後に「VPN通信が可能になりました。IPアドレス...の割り当てが完了しました」というダイアログが出力されました。 その後、pingが通るか確認したところ、正常に通りました。次に接続先イントラのファイルサーバが参照できるかの確認もできました。 おわりに 今回、多少の時間はかかりましたが、大きな問題もなくVPNを利用することができました。 今後利用していく上で、セキュリティがどの程度担保されているかを調べる必要はありますが、使いやすさとコストがかからない点では大いに利用する価値があると思います。

Category

Archive

Latest Post