Web Server

最近はクラウドサービスなども多くなり、必要最小限のTCPポートしか開いていないWindows Server同士でファイルのやり取りをする必要が発生することが増えました。単純にエクスプローラーで「\\ServerName」などと入力すればアクセスできる同一LAN内とは違って色々と工夫が必要です。 リモートデスクトップ接続でドライブをマウントする 個人的に一番お手軽だと思うのはリモートデスクトップ接続時にローカルディスクを接続する方法です。 たったこれだけで、マイコンピューターから簡単にコピー出来ます。必要なポートもRDPのポートのみなのでお手軽ですね。 ただし、この方法だとリモートデスクトップ接続をしている時にしかアクセスできませんし、手動でコピーするのはいいとしても自動化するのは厳しいです。 WebDavを使う方法 何かいい方法はないかなぁと考えたのですがあまりいい物が思い浮かびませんでした。ftpでもsshでも自動化可能ですが、少々構成が手間です。そこで比較的構成しやすい方法としてWebDavなんてどうでしょうか? サーバー側でIISを動作させないといけないのですが、OSの標準機能で完結するので比較的構成しやすいのではとおもいます。WebDavサーバーとして構成する手順としては以下が簡単にまとまっています。 - [Deploy a File Server in the Cloud ( WebDav on Windows Azure ) - My Thoughts On IT…](http://mythoughtsonit.com/2013/05/deploy-a-file-server-in-the-cloud-webdav-on-windows-azure/) 例としてサイトのルートからWebDavを有効にしています。私の環境ではサブディレクトリからWebDavを有効にしてもそれだけではアクセス出来ず、やはりルートからWebDavを有効にしてあげる必要がありました。それにもならず、サブディレクトリで有効化した後、ルートでも有効化すると、サブディレクトリの設定がエラーで正常に開けなくもなってしまったので、現状サブディレクトリからの有効化はやってはいけない操作であるようにも見えます。 さて、これでサーバー側はOKです。クライアントからはnet useでドライブマップすることができます。昔はエクスプローラーのアドレスの部分にhttp://～とアドレスを入力すればアクセスできたOSもあったのですが、どうやらWindows8, Windows Server 2012ではnet useあるいはドライブマップをGUIから行うことでのみアクセスできるようです。 ここで規定の状態ではWindows 8からはアクセスできるのにWindows Server 2012からはアクセスできなくて困りました。結局調べたところ、WebDavクライアントとして動作するためには「WebClient」というサービスが動作している必要がある、ということがわかりました。このサービスがWindows 8は規定の状態で動作しているが、Windows Server 2012では動作していないので動かなかった、というわけです。 WebClientサービスのWindows Server 2012への導入方法 Windows Server 2012にWebClientサービスを導入するには「デスクトップエクスペリエンス」機能を導入してあげる必要があります。 機能を追加して再起動するとWebClientサービスが導入されます。 これでドライブマップを正常に行えるようになります。具体的には以下のようにコマンドを入力すれば良いです。 net use x: http://hogehoge/hoge password /USER:domain\username これでWebDav経由でファイルコピーを行う処理を全自動化できますね。

今回はWeb、その中でもHTTPの部分の話です。世の中にはさまざまなブラウザがあり、非常に高機能なものが多いです。でも、それらが提供している機能のうち一番の基礎となる通信部分に関してはかなりシンプルです。 HTTPとは まず、はじめにHTTPとは何か?という点に関してです。HTTPはHyper Text Transfer Protocolの略で、Hyper Textを転送するための手続きだ、というわけですね。Hyper Textというのはテキストを超えるものだ、ということです。そして、Hyper Textを書く手段がHTMLで、そのHTMLを伝える手段がHTTPなわけです。このあたりはWikipediaに説明を譲ります。 - [Hypertext Transfer Protocol - Wikipedia](http://ja.wikipedia.org/wiki/HTTP) - [ハイパーテキスト – Wikipedia](http://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%A4%E3%83%91%E3%83%BC%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88) - [HyperText Markup Language – Wikipedia](http://ja.wikipedia.org/wiki/HyperText_Markup_Language) 要は世の中に沢山あるWebサーバーから情報をひっぱってこようとおもったら、HTTPでおしゃべりすればいい、ということです。 Webページを取得してみる それでは実際にやってみましょう。やってみると簡単ですよ。簡単なページが良いので、いつものようにGoogleのページを引っ張ってきてみましょう。 まずは、googleのWebサーバーであるwww.google.co.jpに接続します。WebサーバーはTCPの80番で動作していますので80番に接続します。 1 : C : \ > t e l n e t w w w . g o o g l e . c o . j p 8 0 接続に成功すると何も表示されない状態になります。それで正常です。この状態でWebサーバーに対してページを要求します。以下のように入力します。 1 : G E T / H T T P / 1 . 1 ...

「インターネットに繋がらない！」という発言をよく聞きます。テクノロジーを理解していないお客さんならともかく、プロとしてはこのような発言はしたくないものです。「インターネットに繋がらない」時には具体的にどのようなことが原因として考えられるのか考えてみます。 ※ここでは「インターネットに繋がる」という言葉の正確さに関しては議論しないことにします。 大まかな流れとその確認確認ポイント 通常お客さんが「インターネットに繋がらない」と言ったときにはブラウザでWeb上のコンテンツを表示できなくなったときでしょうから、そのときの大まかな流れを見てみます。 PCが起動する 有線または無線にてEthernetに接続する 固定またはDHCPにてTCP/IPの設定がなされる ブラウザにてURLが指定される DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 該当のWeb Serverに接続する Web Serverからコンテンツを得る ブラウザにコンテンツを表示する これはかなり大まかな流れであって、実際にはまだまだいくらでも細かく処理を記述することが可能ですが、最低この程度の粒度では事象を抑えてもらいたいです。 このレベルでの確認ポイントは以下です。 きちんとケーブルが刺さっているか IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 該当のWeb Serverに接続できているか コンテンツを得られるか それぞれ確認方法を紹介してみましょう。 きちんとケーブルが刺さっているか これはどうやって確認すればいいかというと････。目で見て確認してください(笑)。でも、せっかくなのでコマンドで確認する方法も紹介しましょう。 このように「ipconfig」というコマンドを使うとネットワークの状態を見ることができます。今、上の図ではきちんとIPアドレス等が表示されているので、この状態であれば「ケーブルがきちんと刺さっている」と言うことがわかります。ケーブルがきちんと刺さっていない場合にはここには「media disconnected」と表示されます。このように表示された場合にはケーブルが刺さっていない状態ですので、ケーブルの確認をしてください。 IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか ケーブルが刺さっていることを確認したら次はIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNS等のTCP/IPの設定がきちんとなされているかを確認します。これも先ほどと同じく「ipconfig」コマンドで確認できるのですが、「ipconfig」コマンドだけではDNSの設定が確認できないので「ipconfig /all」コマンドを実行することで確認します。 ここできちんとIPアドレス(IP Address)、サブネットマスク(Subnet Mask)、デフォルトゲートウェイ(Default Gateway)、DNS(DNS Servers)が設定されていることを確認します。 ここでこれらのパラメータを自分で設定している人(固定的に設定している人)と自動的に設定している人とで若干確認、修正方法が異なります。 固定になっているのか、自動になっているのかの判別は上記コマンド結果の「Dhcp Enabled」の部分がYesになっているかNoになっているかでわかります。上記のサンプルではDHCPが有効になっていて、DHCPサーバー(192.168.1.254)からTCP/IPの設定を自動取得していることがわかります。 固定で設定している場合には「インターネットプロトコル(TCP/IP)」のプロパティから手動で値を設定、修正します。 自動になっている場合にはDHCPサーバーがきちんと稼動して、正しい設定を配布してくれている必要があります。自動的に取得する設定になっているにもかかわらず「169.254.x.x」、あるいは「0.0.0.0｣というアドレスになっている場合には正常にDHCPサーバーから設定を取得できていない状態です。DHCPサーバーの正常動作を確認するか、あるいは固定で設定してしまうかなどの対応が必要です。 参考：APIPA - Wikipedia そもそもどんな値を設定すればいいのか、設定されていればいいのかわからない人はTCP/IPの基礎を勉強しなくてはいけないですね。後日書く予定です。 ここまでの設定の確認としては、「デフォルトゲートウェイまでのpingが通ることを確認する」という方法が有効です。 「ping デフォルトゲートウェイのIPアドレス」を実行して、Pingに対してReplyがあることを確認しましょう。 DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 次にDNSでの名前解決がきちんとなされているかの確認方法です。「nslookup」というコマンドをつかって「nslookup ホスト名」とすることで調べられます。「ホスト名」というのはURLのうち下の例で言うとxxxx.xxx.xxの部分です。 「http://xxxx.xxx.xx/yyy/xxx/」 http://の直後からはじめの「/」の前までの部分ですね。 このようにホスト名からIPアドレスへの変換がうまくいっている必要があります。そもそもここでスペルミスなどをすると以下のように答えが返ってきません。 ここがうまくいかない場合には以下の2つの可能性があります。 TCP/IPの設定でDNSの設定を間違えている(正しいDNSサーバーを利用していない) 接続しようとしている先のサイトの情報を保持しているDNSサーバーに障害が起きている どちらなのかを判断するためには、その他のホスト名の名前解決ができるかどうかを調べましょう。私はいつも「www.google.com」が解決できるかどうか試しています。 ここまでのこと(ケーブル、TCP/IP設定、DNS)を一度に試す方法があります。それは「ping www.google.com」を実行することです。 ケーブルが繋がっていなければPingに応答があるわけはありませんし、TCP/IPの設定がただしいからgoogleのサーバーまで通信できています。また、www.google.comをDNSをつかってIPアドレスに変換できているからPingが打てているのです。www.google.comのホストはきちんとpingのReplyを返してくれるので確認が取れるわけです。 該当のWeb Serverに接続できているか ここまでの確認でクライアント側のTCP/IPおよびDNSの設定は問題ないことがわかりました。もう少し上の層に視点を切り替えていきます。まずは、該当のWeb Serverに接続できているかどうかです。 ...