1、服务查询

默认情况下，Linux系统在默认安装中已经安装了Samba服务包的一部分 ，为了对整个过程有一个完整的了解，在此先将这部分卸载掉。 使用命令

rpm -qa | grep samba ，默认情况下可以查询到两个已经存在的包：

samba-client-3.0.33-3.7.el5

samba-common-3.0.33-3.7.el5

2、卸载Samba

用rpm -e 将两个包卸载掉。对于samba-common-3.0.33-3.7.el5，因为与其它rpm包之间存在依赖关系，所以必须加参数-f和--nodeps，-f是指强制，--nodeps是指不检查依赖关系，具体完整命令为：

 rpm -e samba-common-3.0.33-3.7.el5 -f --nodeps

rpm -e samba-client-3.0.33-3.7.el5 -f --nodeps

3、安装Samba 

用以下命令安装：

rpm -ivh samba-3.0.33-3.29.el5_6.2.i386.rpm -f --nodeps

     首先备份一下samba的配置文件

cd /etc/samba

mv  smb.conf smb.conf bak

然后重新创建一个smb.conf文件

touch smb.conf

然后我们把这段写入smb.conf中 

[global]

     netbios name = LinuxSir05
     server string = Linux Samba Server TestServer
     security = share

  [linuxsir]
             path = /opt/linuxsir
            writeable = yes
                browseable = yes 

    guest ok = yes

第二步：建立相应目录并授权；  

[root@localhost ~]#  mkdir -p /opt/linuxsir

[root@localhost ~]# chown -R nobody:nobody /opt/linuxsir 

    注释：

关于授权nobody，我们先用id命令查看了nobody用户的信息，发现他的用户组也是nobody，我们要以这个为准。有些系统nobody用户组并非是nobody ； 

第三步：启动smbd和nmbd服务器；

      [root@localhost ~]# nmbd

     （1）RequestDispatcher.forward方法只能将请求转发给同一个WEB应用中的组件；而HttpServletResponse.sendRedirect 方法不仅可以重定向到当前应用程序中的其他资源，还可以重定向到同一个站点上的其他应用程序中的资源，甚至是使用绝对URL重定向到其他站点的资源。如果传递给HttpServletResponse.sendRedirect 方法的相对URL以“/”开头，它是相对于整个WEB站点的根目录；如果创建RequestDispatcher对象时指定的相对URL以“/”开头，它是相对于当前WEB应用程序的根目录。

    （2）调用HttpServletResponse.sendRedirect方法重定向的访问过程结束后，浏览器地址栏中显示的URL会发生改变，由初始的URL地址变成重定向的目标URL；而调用RequestDispatcher.forward 方法的请求转发过程结束后，浏览器地址栏保持初始的URL地址不变。

    （3）HttpServletResponse.sendRedirect方法对浏览器的请求直接作出响应，响应的结果就是告诉浏览器去重新发出对另外一个URL的访问请求，这个过程好比有个绰号叫“浏览器”的人写信找张三借钱，张三回信说没有钱，让“浏览器”去找李四借，并将李四现在的通信地址告诉给了“浏览器 ”。于是，“浏览器”又按张三提供通信地址给李四写信借钱，李四收到信后就把钱汇给了“浏览器”。可见，“浏览器”一共发出了两封信和收到了两次回复， “浏览器”也知道他借到的钱出自李四之手。RequestDispatcher.forward方法在服务器端内部将请求转发给另外一个资源，浏览器只知道发出了请求并得到了响应结果，并不知道在服务器程序内部发生了转发行为。这个过程好比绰号叫“浏览器”的人写信找张三借钱，张三没有钱，于是张三找李四借了一些钱，甚至还可以加上自己的一些钱，然后再将这些钱汇给了“浏览器”。可见，“浏览器”只发出了一封信和收到了一次回复，他只知道从张三那里借到了钱，并不知道有一部分钱出自李四之手。

     （4）RequestDispatcher.forward方法的调用者与被调用者之间共享相同的request对象和response对象，它们属于同一个访问请求和响应过程；而HttpServletResponse.sendRedirect方法调用者与被调用者使用各自的request对象和response对象，它们属于两个独立的访问请求和响应过程。对于同一个WEB应用程序的内部资源之间的跳转，特别是跳转之前要对请求进行一些前期预处理，并要使用HttpServletRequest.setAttribute方法传递预处理结果，那就应该使用RequestDispatcher.forward方法。不同WEB应用程序之间的重定向，特别是要重定向到另外一个WEB站点上的资源的情况，都应该使用HttpServletResponse.sendRedirect方法。

    （5）无论是RequestDispatcher.forward方法，还是HttpServletResponse.sendRedirect方法，在调用它们之前，都不能有内容已经被实际输出到了客户端。如果缓冲区中已经有了一些内容，这些内容将被从缓冲区中清除。
      
        怎么选择是重定向还是转发呢？通常情况下转发更快，而且能保持request内的对象，所以他是第一选择。但是由于在转发之后，浏览器中URL仍然指向开始页面，此时如果重载当前页面，开始页面将会被重新调用。如果你不想看到这样的情况，则选择转发。
不要仅仅为了把变量传到下一个页面而使用session作用域，那会无故增大变量的作用域，转发也许可以帮助你解决这个问题。 
         重定向：以前的request中存放的变量全部失效，并进入一个新的request作用域。 
         转发：以前的request中存放的变量不会失效，就像把两个页面拼到了一起。

１．  設計書の作成について

　　 1 つの設計書は１つのレビューできる成果物です。不同の使用者向け、設計書に該当の内容を明記すべきであります。

・      SD の方面

　　 SD 階段の設計書は構成設計書です。書く時に、以下の観点を注意されます。

①      この設計書の使用者は MK1 の担当者と MK3 の担当者です。この設計書によって、ソースは作成することができます。しかも他の問題を考慮する必要がありません。 MK3 の担当者はこの設計書よりテスト設計書を作成することができます。

②      この設計書の詳しい程度、品質の要求の高低と時間に係ります。最低の要求は、すべてのクラスとメソッドにインタフェースやパラメータをはっきり書きなければならなくて、簡単な処理フローを書きます。しかも言語は曖昧な意味があることができません。

③      この設計書を書く時、きっと先にクラスとメソッドの一覧を作成して、且つ根拠を書き出します。また、 FD の設計書のすべての機能を全部含ます。

④      設計書を書く時、条理があって、入力から出力まで 1 つのステップずつを説明します。一足飛びのロジックがあることができません。

⑤      言語は分かり易くなって、多義性があることができません。且つレビューし易いために多くの細い点を注意します。

・      BD の方面。これらは近日 FJ 殿の BD 設計書から習いました。間違いの場所を指摘してください。

①      BD 階段の設計書は基本設計書です。ユーザ（例えば：本製品の使用者）の立場からこの設計書を作成します。ユーザのすべての需要に対応して、説明を行います。

②      システムのソフトウェア、ハードウェアの規模性と複雑性に対して、設計書に対応することがあるかどうか。

③      システムの拡張性、設計書に対応することがあるかどうか。

④      使用された技術の複雑性と難しくに対して、製品の高い品質のために、設計書に対応することがあるかどうか。

⑤      性能とセキュリティなど方面、設計書に対応することがあるかどうか。

⑥      この製品はどれくらいの時間を使うことができます。設計書に対応することがあるかどうか。

⑦      ユーザの需要が曖昧の場合、設計書に対応することがあるかどうか。そして増えるまたは減らす作業量、複雑性などに対して、考えることがあるかどうか。

⑧      言語は分かり易くなって、多義性があることができません。設計書を書く時、どのようにレビューし易いと考えます。

・      FD の方面。

①      FD 階段の設計書は機能設計書です。主に基本設計書を対応して、コンピュータの上でどのように実現します。

②      基本設計書と構成設計書の間すべての設計は機能設計書の内容だと思います。この設計書は開発者の根拠です。内容必ずは合理的と正しいです。

③      言語は分かり易くなって、多義性があることができません。且つレビューし易いために多くの細い点を注意します。

２．  レビューについて

①      設計書では、プロジェクトと会社の規約によって、 Excel 版文書または Word 版文書があります。 Excel 版の文書は分かり易くて、しかしレビューに役立ちません。 Word 版の文書はレビューに役立って、しかし分かることは苦労しています。

②      設計書の難しい程度と会社のデータによって、予定するバッグ数を確定します。

③      設計書を書き終わった後に、自己レビューして、向かうしレビューすることが必要です。

④      レビュー前に、本回のレビュー観点を明確します。

⑤      レビューの時に、担当者は設計書を読むんで、レビュー者は問題を指摘します。問題のタイプによって、分類します。

⑥      レビュー終わったから、レビュー結果報告書と結果分析報告を作成します。指摘されたバッグ、バッグの原因、予定するバッグ数によって、分析して、見解を提出します。また、もう一回レビューが必要かどうかとレビュー観点を確定します。合計するバッグ数は予定するバッグ数より大きくまたは少なく場合、管理者はこの問題を重視する必要があります。

⑦      レビュー結果報告書と結果分析報告によって、管理者は設計書の品質と担当者の問題を見ます。

３．  プロジェクト管理について。

①      オフショアので、プロジェクト内容は明確にしなければなりません。明確しない作業があることができません。

②      プロジェクトの開発の中で、 2 つの表を保守する必要があります。問題一覧表と作業一覧表です。

③      それぞれのデータを取得します。例えば：新規開発 1k ステップ当たり各階段の指標、レビューのバッグ数等。

④      MK2 、 MK3 、 CT 、 ST それぞれのテスト観点を明確しました。テストされる内容はソース、構成設計書、機能設計書、基本設計書です。

⑤      線票で進捗情報を表示します。

⑥      プロジェクト会議に問題を記録して、次の会議にすべての問題を確認します。

1.1 - Server

A Server element represents the entire Catalina servlet container. (Singleton)

1.2 - Service

A Service element represents the combination of one or more Connector components that share a single Engine
Service是这样一个集合：它由一个或者多个Connector组成，以及一个Engine，负责处理所有Connector所获得的客户请求

1.3 - Connector

一个Connector将在某个指定端口上侦听客户请求，并将获得的请求交给Engine来处理，从Engine处获得回应并返回客户
TOMCAT有两个典型的Connector，一个直接侦听来自browser的http请求，一个侦听来自其它WebServer的请求
Coyote Http/1.1 Connector 在端口8080处侦听来自客户browser的http请求
Coyote JK2 Connector 在端口8009处侦听来自其它WebServer(Apache)的servlet/jsp代理请求

1.4 - Engine

The Engine element represents the entire request processing machinery associated with a particular Service
It receives and processes all requests from one or more Connectors
and returns the completed response to the Connector for ultimate transmission back to the client
Engine下可以配置多个虚拟主机Virtual Host，每个虚拟主机都有一个域名
当Engine获得一个请求时，它把该请求匹配到某个Host上，然后把该请求交给该Host来处理
Engine有一个默认虚拟主机，当请求无法匹配到任何一个Host上的时候，将交给该默认Host来处理

1.5 - Host

代表一个Virtual Host，虚拟主机，每个虚拟主机和某个网络域名Domain Name相匹配
每个虚拟主机下都可以部署(deploy)一个或者多个Web App，每个Web App对应于一个Context，有一个Context path
当Host获得一个请求时，将把该请求匹配到某个Context上，然后把该请求交给该Context来处理
匹配的方法是“最长匹配”，所以一个path==""的Context将成为该Host的默认Context
所有无法和其它Context的路径名匹配的请求都将最终和该默认Context匹配

1.6 - Context

一个Context对应于一个Web Application，一个Web Application由一个或者多个Servlet组成
Context在创建的时候将根据配置文件$CATALINA_HOME/conf/web.xml和$WEBAPP_HOME/WEB-INF/web.xml载入Servlet类
当Context获得请求时，将在自己的映射表(mapping table)中寻找相匹配的Servlet类
如果找到，则执行该类，获得请求的回应，并返回

2 - Tomcat Server的结构图

3 - 配置文件$CATALINA_HOME/conf/server.xml的说明

该文件描述了如何启动Tomcat Server

4 - Context的部署配置文件web.xml的说明

一个Context对应于一个Web App，每个Web App是由一个或者多个servlet组成的
当一个Web App被初始化的时候，它将用自己的ClassLoader对象载入“部署配置文件web.xml”中定义的每个servlet类
它首先载入在$CATALINA_HOME/conf/web.xml中部署的servlet类
然后载入在自己的Web App根目录下的WEB-INF/web.xml中部署的servlet类
web.xml文件有两部分：servlet类定义和servlet映射定义
每个被载入的servlet类都有一个名字，且被填入该Context的映射表(mapping table)中，和某种URL PATTERN对应
当该Context获得请求时，将查询mapping table，找到被请求的servlet，并执行以获得请求回应

分析一下所有的Context共享的web.xml文件，在其中定义的servlet被所有的Web App载入

5 - Tomcat Server处理一个http请求的过程

假设来自客户的请求为：
http://localhost:8080/wsota/wsota_index.jsp

<!----------------------------------------------------------------------------------------------->


<web-app>


  <!-- 概述：
       该文件是所有的WEB APP共用的部署配置文件，
       每当一个WEB APP被DEPLOY，该文件都将先被处理，然后才是WEB APP自己的/WEB-INF/web.xml
       -->



  <!--  +-------------------------+  -->
  <!--  |    servlet类定义部分    |  -->
  <!--  +-------------------------+  -->



  <!-- DefaultServlet
       当用户的HTTP请求无法匹配任何一个servlet的时候，该servlet被执行
       URL PATTERN MAPPING : /
       -->

    <servlet>
        <servlet-name>default</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.DefaultServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <init-param>
            <param-name>listings</param-name>
            <param-value>true</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>


  <!-- InvokerServlet
       处理一个WEB APP中的匿名servlet
       当一个servlet被编写并编译放入/WEB-INF/classes/中，却没有在/WEB-INF/web.xml中定义的时候
       该servlet被调用，把匿名servlet映射成/servlet/ClassName的形式
       URL PATTERN MAPPING : /servlet/*
       -->

    <servlet>
        <servlet-name>invoker</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.InvokerServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <load-on-startup>2</load-on-startup>
    </servlet>


  <!-- JspServlet
       当请求的是一个JSP页面的时候（*.jsp）该servlet被调用
       它是一个JSP编译器，将请求的JSP页面编译成为servlet再执行
       URL PATTERN MAPPING : *.jsp
       -->

    <servlet>
        <servlet-name>jsp</servlet-name>
        <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
        <init-param>
            <param-name>logVerbosityLevel</param-name>
            <param-value>WARNING</param-value>
        </init-param>
        <load-on-startup>3</load-on-startup>
    </servlet>



  <!--  +---------------------------+  -->
  <!--  |    servlet映射定义部分    |  -->
  <!--  +---------------------------+  -->


    <servlet-mapping>
        <servlet-name>default</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>invoker</servlet-name>
        <url-pattern>/servlet/*</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>jsp</servlet-name>
        <url-pattern>*.jsp</url-pattern>
    </servlet-mapping>


  <!--  +------------------------+  -->
  <!--  |    其它部分，略去先    |  -->
  <!--  +------------------------+  -->

    ... ... ... ...

</web-app>


<!----------------------------------------------------------------------------------------------->

<!----------------------------------------------------------------------------------------------->



<!-- 启动Server
     在端口8005处等待关闭命令
     如果接受到"SHUTDOWN"字符串则关闭服务器
     -->

<Server port="8005" shutdown="SHUTDOWN" debug="0">


  <!-- Listener ???
       目前没有看到这里
       -->

  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" debug="0"/>
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" debug="0"/>


  <!-- Global JNDI resources ???
       目前没有看到这里，先略去
       -->

  <GlobalNamingResources>
    ... ... ... ...
  </GlobalNamingResources>


  <!-- Tomcat的Standalone Service
       Service是一组Connector的集合
       它们共用一个Engine来处理所有Connector收到的请求
       -->

  <Service name="Tomcat-Standalone">


    <!-- Coyote HTTP/1.1 Connector
         className : 该Connector的实现类是org.apache.coyote.tomcat4.CoyoteConnector
         port : 在端口号8080处侦听来自客户browser的HTTP1.1请求
         minProcessors : 该Connector先创建5个线程等待客户请求，每个请求由一个线程负责
         maxProcessors : 当现有的线程不够服务客户请求时，若线程总数不足75个，则创建新线程来处理请求
         acceptCount : 当现有线程已经达到最大数75时，为客户请求排队
                       当队列中请求数超过100时，后来的请求返回Connection refused错误
         redirectport : 当客户请求是https时，把该请求转发到端口8443去
         其它属性略
         -->

    <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" 
               port="8080" 
               minProcessors="5" maxProcessors="75" acceptCount="100" 
               enableLookups="true" 
               redirectPort="8443" 
               debug="0" 
               connectionTimeout="20000" 
               useURIValidationHack="false" 
               disableUploadTimeout="true" />


    <!-- Engine用来处理Connector收到的Http请求
         它将匹配请求和自己的虚拟主机，并把请求转交给对应的Host来处理
         默认虚拟主机是localhost
         -->

    <Engine name="Standalone" defaultHost="localhost" debug="0">


      <!-- 日志类，目前没有看到，略去先 -->

      <Logger className="org.apache.catalina.logger.FileLogger" .../>

      <!-- Realm，目前没有看到，略去先 -->

      <Realm className="org.apache.catalina.realm.UserDatabaseRealm" .../>


      <!-- 虚拟主机localhost
           appBase : 该虚拟主机的根目录是webapps/
           它将匹配请求和自己的Context的路径，并把请求转交给对应的Context来处理
           -->

      <Host name="localhost" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="true">


        <!-- 日志类，目前没有看到，略去先 -->

        <Logger className="org.apache.catalina.logger.FileLogger" .../>


        <!-- Context，对应于一个Web App
             path : 该Context的路径名是""，故该Context是该Host的默认Context
             docBase : 该Context的根目录是webapps/mycontext/
             -->

        <Context path="" docBase="mycontext" debug="0"/>


        <!-- 另外一个Context，路径名是/wsota -->

        <Context path="/wsota" docBase="wsotaProject" debug="0"/>


      </Host>

    </Engine>

  </Service>

</Server>


<!----------------------------------------------------------------------------------------------->