Globus 1.1系统的安装和配置

Globus 1.1系统的安装和配置
国防科技大学的研究生褚瑞rchu@ 写作时间：2001
感谢作者主动提供此文档在“中国网格信息中转站”发表
1．简介
我们将要安装的Globus系统是1.1.3或者1.1.4版本，从1.1.3版开始，Globus有了比较大的改变，主要体现在目录信息服务和安全结构这两个方面：
1）目录服务方面，1.1.3以前的版本遵循一种老式的MDS模型：所有的信息保存在指定的中央目录服务器中，由资源的守护进程定期更新；而1.1.3之后，开始支持一种分布式的MDS模型（当然，老式模型也同时得到支持）：不仅目录服务器不再是指定的，而且支持多个目录服务器
（GRIS），用来存储资源信息。

为了把这些目录服务器进一步组织起来，还可以（不是必须）开设一个索引信息服务（GIIS），专门存储目录服务器的信息。

老式的MDS模型又被称为“推”模型，而目前的分布式模型又被称为“拉”模型。

2）安全结构：
Globus采用SSL提供的API进行安全验证等工作。

当一个客户向资源所有者发出任务请求时，资源所有者一方由Gatekeeper接收这个请求。

在这个过程中，对话双方，客户和Gatekeeper，都需要一份证书，这个证书由CA签发。

从1.1.3版开始，Globus支持多种CA。

你的证书可以由Globus CA签发，也可以由第三方CA 签发，甚至可以由自己创建的CA签发。

下面我们将会看到，由于实验条件的限制，我们无法得到Globus CA的信任，必须自己建立CA并且签发证书。

针对以前的版本而言，这两点改进对于我们建立自己的实验环境是非常有利的。

整个安装和配置步骤大致如图1所示：
下面将按照图1中标识的顺序，对安装和配置过程逐步进行介绍。

重点是整个过程中可能遇到的问题，以及解决办法。

图1. 安装和配置过程示意
2．准备工作
安装Globus之前，应该首先创建必要的用户帐号和目录，并安装好SSLeay和OpenLDAP。

2．1．建立用户帐号
尽管不是必须，但Globus系统推荐在安装前首先建立一个单独的登录帐号，如用户名globus，后面所有工作除了特殊说明外都用这个账号完成。

下面我们要创建三个目录，这三个目录在以后会反复用到，不能混淆：
1)源代码所在目录
2)安装目录
3)展开目录
这三个目录我们分别简称为%src%，%install%和%deploy%。

2．2．安装SSLeay
Globus 1.1.3推荐的SSLeay版本是0.90b，安装过程中需要注意，首先需要用Configure进行配置。

但是，SSLeay 0.90的这个Configure脚本是用Perl语言编写的，因此需要Perl解释器作为Shell进行解释。

Redhat 7.0环境中内置了Perl解释器，因此我们需要这样执行：
%perl Configure
配置结束后，按照make clean→make depend→make→make install的顺序进行安装即可。

整个过程并不复杂，但我在实际安装过程中发现，Globus对SSLeay版本的要求并不严格，甚至不用安装，找一份安装完成的SSLeay复制到/usr/local就行了，我们假设这个安装目录是%ssl%。

2．3.安装OpenLDAP
这个过程已经在前面的文档中多次提及，不再赘述。

3．编译和安装
3．1．概述
Globus编译之前同样需要有一个配置的过程，而且，在有多种体系结构计算机存在的计算节点上，必须对每种结构分别进行配置；配置完成后，需要完成编译、复制文件的工作。

为了简化上述过程，Globus提供了一个比较庞大的shell script文件，可以完成配置、编译、复制文件这一系列动作，这就是%src% / globus-install文件。

需要注意，整个安装过程都不能以root帐号进行，推荐使用我们在准备阶段创建的globus专用帐号。

但是在实际安装过程中，我们会看到这个shell script也不是非常好用。

因为整个%src%目录中没有任何类似README的安装指导，唯一可以参考的资料就是这个script本身的参数说明，出现问题时会让人无所适从。

下面我们来讨论安装中比较常见的问题和解决办法。

3．2．问题及解决办法
1)不加任何参数运行globus-install，报告错误：Cannot find suitable LDAP files under
"/usr/local/ldap"!
可是在此之前我已经安装了OpenLDAP在/usr/local目录下，为什么报告找不到呢？
解决：查看globus-install文件，发现这样一行：
if [ ! -x ${GLOBUS_LDAP_PATH}/libexec/slapd ]
这说明globus-install要在/usr/local/ldap/libexec查找slapd这个文件，我们找到这
个文件在/usr/local/libexec目录下，于是安装时填写/usr/local，问题解决
如果报告找不到SSLeay，解决方法类似。

2)编译没有完成，仅仅提示there are errors，查看%install%目录，仅有几个log文件，文件中
报告错误："structure has no member named `ld_timeout'”
这个问题仅仅从源代码上看，只能定位到出错原因是LDAP结构没有成员变量ld_timeout，
没有解决办法。

根据Globus站点上的叙述，使用一个加过patch的OpenLDAP 1.2.7版本，
问题解决。

注意，与SSLeay相比，Globus对LDAP的版本要求非常苛刻，即使是标准的OpenLDAP 1.2.7
也会出现上述问题，究竟如何patch我们也无从得知，必须使用patch过的OpenLDAP并且
重新安装LDAP。

3)编译时整个Linux系统死机
解决：在安装时会得到提示：
Allow parallel builds (bad for slow CPUs or small RAM)?
选择no，则顺利通过，猜测可能是Redhat 7.0 SMP内核和Globus存在冲突。

3．3．常用的参数
运行globus-install可以加的参数有将近300个之多，这也从另一方面说明了globus-install的复杂。

下面介绍一些常用的参数：
●-prefix=<globus-install-dir>
这个参数允许预先指定globus的安装路径，如果这里不指定，安装时会以对话的形式提
示。

●-with-ssl-path=<ssl-install-path>
●-with-ldap-path=<ldap-install-path>
这两个参数允许预先指定SSLeay和OpenLDAP的路径，如果不指定，安装时会先到
/usr/local/ssl去找SSLeay，到/usr/local/ldap去找OpenLDAP，如果找不到，则提示用户
输入。

●-dryrun
并不真正编译，可以用来作完整性检查
●-with-umask=<umask>
指定生成文件的权限掩码，默认值为022
●-enable-64bit
指定目标计算机使用64位库。

默认是使用32位进行编译。

4．本地展开
我们已经把Globus安装到了%install%目录下，但是这样并不能直接使用，一个必须完成的工作是本地展开。

所谓本地展开，其实是按照设置的内容复制必要的文件，特别需要注意的是不能展开到非本地的文件系统如NFS中。

4．1．准备工作
首先我们需要对MDS和GSI进行设置，这两步工作可以由%install%/sbin/globus-setup以提示的方式完成。

注意在第一次运行globus-setup之前请先在profile中设置一个环境变量
GLOBUS_INSTALL_PATH=%install%，这一步文档中没有提及，但是如果不做的话会出错。

首先设置的是MDS，你可以选择的是使用老式还是新式的MDS模型，如果是新式模型，还可以选择是使用GIIS和GRIS协同工作还是仅仅配置一个GRIS管理所有的资源。

显然我们只可能使用新式模型，并且暂时只用一个GRIS管理资源。

这样配置，一切都使用默认值就行了。

对于GSI的设置，主要需要我们指定用户证书和资源证书的DN，在申请证书时将用到。

后面我们会看到，我们使用自己的CA创建证书，因此这里如何设置并不重要。

4．2．本地展开
和安装过程一样，展开的过程不允许用root账号进行。

使用我们创建的globus账号登录，然后运行%install%/sbin/globus-local-deploy <%deploy%>。

运行globus-local-deploy有几个参数是可选的，比如我们如果使用老式的MDS模型，就必须加上-classic参数。

这些参数对我们来讲没有太大价值，就不作介绍了。

在展开的过程中我没有遇到任何问题，这个步骤完成后，会在%deploy%/tmp/路径下生成一个globus-root-instructions文件，指导了下一步应该如何进行。

这个说明非常粗略，不具有很大的指导价值。

下一步，我们用root账号登录，把下述文件的所有者改为root
%deploy%/gd/sbin
%deploy%/sbin/globus-gatekeeper-controller
%deploy%/sbin/globus-gatekeeper
%deploy%/libexec
%deploy%/libexec/globus-k5
%deploy%/etc
%deploy%/etc/grid-mapfile
%deploy%/etc/globus-services
%deploy%/etc/globus-gatekeeper.conf
这些文件主要都是和gatekeeper相关的，gatekeeper是资源管理模块的一个相当重要的程序，后面我们将简单介绍它，并且会看到，这个程序必须以root身份运行。

4．3．申请证书
deploy结束后，将会在%deploy%/etc/ 路径下生成三个文件
globus-gatekeeper.cert
globus-gatekeeper.key
globus-gatekeeper.request
这里的.key和.cert就是供gatekeeper使用的一对私钥和证书（用于标明自己的身份，防止gatekeeper的伪造），但是我们还没有申请证书，所以这里的globus-gatekeeper.cert是一个空文件。

按照deploy后生成的globus-root-instructions文件给我们的指导，下一步应该在Globus CA申请一份证书，申请的大致方法是使用申请人的账号（不是root，也不是globus）登录，运行cat
/home/globus/gd/etc/globus-gatekeeper.request|mail ca@命令，发送一封email给Globus CA，CA进行必要的验证后，将回复一个.cert文件，也就是gatekeeper的证书。

很遗憾，当我使用自己的免费邮箱去Globus CA申请证书的时候，他们的回复是我的身份不可信，不能签发证书。

下面，我们将尝试建立自己的CA，并且签发证书。

5．签发身份验证
由于申请证书失败，我在globus的讨论组中询问能否跳过所有的安全机制，回复是不可能跳过，但是可以选择使用Globus CA，第三方CA或者自己的CA。

显然我们只可能建立自己的CA。

我在这一步上面花费的时间比较多，因为我们对SSL安全机制缺乏必要的了解。

我下载并且阅读了一些关于SSL的文档，这里先按照我个人的理解，介绍一下SSL的基本知识：
5．1．SSL简介
安全套接口SSL 是Secure Sockets Layer的缩写，它能保证网络上传输数据的安全性，防止被窥视、窜改、伪造。

由于受到当时技术条件的限制，tcp/ip等网络平台无法提供加密的数据传输方式，网络的应用程序必须自己提供安全措施，如口令保护、des加密等，结果是管理工作量大，安全性差。

SSL 对网络平台进行了扩充，为网络上应用程序间数据传输提供保护。

RSA公钥加密在计算机产业中被广泛使用在认证和加密。

公钥加密是使用一对非对称的密码加密或解密的方法。

每一对密码由公钥和私钥组成。

公钥被广泛发布。

私钥是隐密的，不公开。

用公钥加密的数据只能够被私钥解密。

反过来，使用私钥加密的数据只能用公钥解密。

这个非对称的特性使得公钥加密很有用。

在Globus系统中，公钥加密的算法主要用于身份验证。

传统的网络应用一般采用口令来确认对方身份，很显然，口令的管理是比较麻烦的，而且口令位数有限，容易被猜测和尝试。

为了增强网络安全，SSL采用身份认证技术进行身份识别。

网络中的每个成员都持有一个长数百字节的身份证书。

一方向另一方提供自己的身份证书，对方使用特定算法进行真伪检查，这就是身份识别。

这里经常出现的一个词汇是“证书”。

现在我们知道了公钥和私钥的概念，证书是什么呢？按照我的理解，证书是指已经用CA本身的私钥进行了签名的用户公钥。

那么什么是“签名”呢？签名提供了对信息来源的确定并能检测信息是否被篡改。

做法是随着原始信息发送附加信息，以此向接受方保证，接受方收到的每一个字都与发送方要发的相同。

签名值是关于发送方的私钥和要发送的信息的一个数学函数的值。

发送方计算出的签名和数据一起传送给接收方，算法的构造保证如果不知道私钥的话就不可能计算出这个签名值。

接收方可以通过依赖发送方的公钥、签名值和接收到的数据的另一个数学算法来验证接收到的信息就是发送方签名的信息。

也就是说，申请证书者需要首先根据某种算法生成一对配套的私钥和公钥，私钥在任何时候都不应该出现在网络上，他可以把自己的公钥交给CA，CA经过认证后，用CA本身的私钥对这个用户公钥进行签名，然后送给申请者。

这个经过签名的公钥就是证书。

这样做的好处是：如果有一个恶意用户，可以截获并篡改CA和申请者之间的对话，他所能获得和篡改的，仅仅是一个申请者的公钥和经过CA签名的公钥（证书）。

这些数据全部都是公开的，即使获取了也没有任何特别的意义，而用户公钥经过签名，变成证书后，可以认为它是只读的，因为CA的公钥是众所周知的，而CA的私钥是保密的。

任何人都可以从证书中读出公钥，却不能修改证书，否则证书中的签名根本就不能正确解码。

这样就有效防止了恶意用户伪造CA。

证书中包含的信息不仅仅是申请者的公钥和CA的签名，还包括证书申请者的名称及相关信息，证书有效期等内容。

注意证书的使用是有年限的，过期的证书自动作废，必须由CA重新签发。

在使用SSL进行网络通信时，通信双方都要持有各自由CA发放的身份证书，以及CA的公钥。

在身份识别过程中，服务端先把自己的身份证书传给客户端，客户端用CA的公钥来检验证书数字签名，如果能正确，且证书处于有效期内，就认为服务端的身份有效。

随后，客户端也把自己的身份证书传给服务端，服务端用CA的公钥检验证书数字签名，如果能正确，且日期有效，则客户端的身份有效。

这一过程双方除了能证实对方身份，客户方还可从证书中得到对方的公钥，用于下一步的密钥交换。

这里我们看出，CA的作用仅仅局限于发放证书，到了实际的身份验证阶段，对话双方只需要知道CA的公钥即可进行，并不需要CA的参与。

这个问题曾经困扰过我一段时间，我起初以为身份验证时必
须由CA提供双方的证书，这就意味着我们自己建立的CA至少也应该启动一个守护进程。

可是这个守护进程在哪里？我没有找到，事实上也不可能找到。

现在我们看到了，问题比我想象的要简单。

从以上的分析介绍，可以看出SSL的一些特点：服务端只需持有CA的公钥，不需要维护一个庞大的用户口令表，就可以实现对所有访问者的身份确认。

另外，使用身份认证方式来识别通信双方的身份，可以有效地阻止猜测、伪造等入侵。

在理解了SSL身份验证的基本原理后，我们看看SSLeay软件的使用。

5．2．用SSLeay建立自己的CA
SSLeay这套软件提供了若干实用工具，在%ssl%/bin下。

其中最重要的是ssleay。

这个工具需要提供参数，作为命令。

合法的命令有60个左右，比较常见的是以下的命令：
ssleay genrsa : 创建一个PEM格式的RSA私钥
ssleay rsa : 查看某个RSA私钥的细节
ssleay ca : 签署一份证书
ssleay x509 : 查看一份证书的细节，包括证书申请者的名称及相关信息，公钥，证书有效期等内容
由于涉及到CA的私钥等敏感信息，下面所有的命令都必须在root账号下进行。

要建立一个CA，我们可以先为自己的CA创建一个私钥：
#ssleay genrsa -des3 -out ca.key 1024
输入口令，产生私钥文件ca.key后，把它保存到合适的路径下。

但是这样做比较麻烦，为了使用上的简便，SSLeay提供了一个script文件CA.sh，我们运行CA.sh –newca，它会自动生成一个叫demoCA的目录，并且创建一个私钥放在这个目录下。

用下面的命令可以看到ca.key的一些细节：
#ssleay rsa -noout -text -in ca.key
下面应该做的是为gatekeeper签署证书，我们使用以下命令：
#ssleay ca –in globus-gatekeeper.request –out globus-gatekeeper.cert
输入正确的口令后，发生错误。

这是因为SSLeay还有一个配置文件，这个至关重要的配置文件并不存放在%ssl%/etc目录下，而是%ssl%/lib下一个名为f的文件。

从这个配置文件中可以看到：
[ CA_default ]
dir = . # Where everything is kept
certs = $dir/certs # Where the issued certs are
new_certs_dir = $dir/newcerts #default place for new certs.
……
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = match
emailAddress = optional
在CA_default小节中，dir是指存放CA本身的私钥的目录，改为%ssl%/bin/demoCA
下面的这个policy_match看来是指CA对允许签署的证书的要求，如countryName等等信息必须一致才可以签署。

我们把policy_math小节所有内容都由match改为optional 这样修改后，再执行ssleay ca –in globus-gatekeeper.request –out globus-gatekeeper.cert，输入正确的口令，即可生成一个globus-gatekeeper.cert文件，这就是我们创建的证书，按照默认值，它的有效期是一年。

用下面的命令：
# ssleay x509 -noout -text -in globus-gatekeeper.cert
即可看到这个证书的细节。

6．证书配置
6.1.gatekeeper证书的配置
前面提到过，在本地展开完成后，会产生一个globus-gatekeeper.request文件，我们用CA对这个文件进行签发，形成一张证书，也就是globus-gatekeeper.cert文件。

至此，我们拥有了一对私钥和证书，globus-gatekeeper.request这个文件就不再需要了。

私钥和证书应该存放在%deploy%/etc/这个路径下，特别值得注意的是，属主必须是root，而且两个文件必须只对root可读，而对其他用户没有任何访问权限，即权限为0400，这一点非常重要。

在gatekeeper运行时会检查这里的权限，如果不符，将会出错。

而这个要点在globus的正式文档中居然没有提及，我在发生错误后去读源码，才找到根本原因。

之所以这样设计，我想是因为私钥属于保密信息，必须严格限制权限。

globus-gatekeeper.request文件是在展开时自动形成的，如果事后出于种种原因我们需要重新形成这个文件，globus提供了一个script，在%install%/tools/<arch>/bin/目录下，这样运行它：grid-cert-request –gatekeeper gatekeepername -cert globus-\ gatekeeper.cert -key globus-gatekeeper.key -req globus-\ gatekeeper.request
即可重新生成私钥和公钥，当然也可以重新签发证书。

另外，我们在重新展开globus的时候，也不一定要重新签发证书，把原有的证书和私钥复制到新的展开目录并且设置好权限，仍然可以继续使用。

6.2.用户证书的配置
在介绍SSL的时候我们说过，对话双方必须都有自己的证书，以便验明身份。

在globus系统中，不仅仅是gatekeeper需要证书，每个用户也同样需要。

比如为用户globus创建证书时，我们需要在用户globus的目录，如/home/globus下建立一个新目录，名为.globus，专门用于存放证书。

然后同样运行grid-cert-request，不加任何参数，即可在.globus目录下形成usercert_request.pem，usercert.pem，userkey.pem 这样三个文件，很显然，它们分别是用户的公钥，证书和私钥。

现在usercert.pem还是空文件，CA签发证书后，用签发的usercert.pem覆盖这个空文件，整个过程和创建gatekeeper证书类似。

只是证书的权限规定并不严格，设为0644就可以了。

但是仅仅这样还不够。

我们知道，对话过程中双方有一个必须知道的信息就是CA的公钥，我们必须让gatekeeper和用户同时知道自己建立的CA的公钥。

这一步globus也没有在任何文档中提及，只是说从Globus CA获取证书后，随证书他们会给你必要的指导。

而对于使用第三方CA或者自己的CA的用户，这一步就比较困难了。

我在globus的讨论组里问了这个问题，Jonathan Wrightsell给了下面的指导：
cp %cadir%/cacert.pem %deploy%/share/certificates
cp %cadir%/cacert.pem %install%/share/certificates
第一步很容易理解，当然是把CA本身的证书复制到%deploy%和%install%目录下，供gatekeeper和用户使用。

%ssl%/bin/c_hash cacert.pem
这里我们得到了8个数字，实际上是一个64位二进制数xxxxxxxx。

这个数字似乎是CA的证书经过某个散列函数变换后得到的，至于这个函数是什么，为什么要做这个散列变换，我还只是照章办事，并不清楚具体原理，猜测可能是SSL本身所规定的。

运行c_hash有一点小问题，就是这个script没有指明ssleay的路径，好在这个script非常简单，修改一下就可以了。

cd %deploy%/share/certificates
ln -s cacert.pem xxxxxxxx.0 #last digit is a zero
cd %install%/share/certificates
ln -s cacert.pem xxxxxxxx.0
这是第三步，我们要在%deploy%和%install%这两个目录下分别创建符号链接，名字就是前面得到的那个64位数。

完成了这一步，还没有结束。

在％deploy％/share/cert目录下有一个文件名为
ca-signing-policy.conf，从文件名可以看出它的作用是规定什么样的CA签署的证书才算有效。

它的主要内容是下面这三行：
access_id_CA X509 '/C=US/O=Globus/CN=Globus Certification Authority'
pos_rights globus CA:sign
cond_subjects globus '"/C=us/O=Globus/*" "/C=US/O=Globus/*"
"/O=Grid/O=Globus/*"'
分析一下这其中的内容：第一行指明了CA的信息，我们知道，一张证书中包含有CA的信息，看看我们签署的证书：
# ssleay x509 -noout -text -in globus-gatekeeper.cert
我们看到有这样的信息：
Signature Algorithm: md5WithRSAEncryption
Issuer: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
Validity
Not Before: Mar 5 20:40:04 2001 GMT
Not After : Mar 5 20:40:04 2002 GMT
很明显，第二行就是关于我们的CA的信息，按照这里修改ca-signing-policy.conf。

ca-signing-policy.conf的第二行不必修改
第三行又说明，这个CA可以签署的证书是DN以/C=us/O=Globus或/C=US/O=Globus或
/O=Grid/O=Globus为前导的申请者所申请的证书。

我们把它改为：
cond_subjects globus *
让这个CA可以签署任何证书。

7．gatekeeper测试
7．1．gatekeeper简介
gatekeeper是本地资源管理模块中的一个部件，它主要负责的是一个“接口”的工作。

当用户发送请求的时候，它负责按照标准SSL身份验证方案和用户交换证书，互相验明身份；然后把这个远程的用户映射成为一个本地用户；最后启动具体的资源管理器jobmanager，向jobmanager提交任务。

这里我们看到，gatekeeper是要负责身份验证工作的，它必须和证书、私钥打交道，因此，gatekeeper通常以root 身份运行。

另外，gatekeeper必须对某个端口（默认是2119）进行监听，以接收用户的请求。

在以前版本的Globus 中，gatekeeper的这个功能是通过inetd守护进程完成的。

在目前的Globus中，gatekeeper可以通过inetd 监听（默认），也可以单独作为一个守护进程。

在我们使用的Redhat7.0中，inetd已经被取消，取而代之的是一个非常复杂的xinetd。

Globus讨论组中有人建议不要使用xinetd，而是让gatekeeper单独作为一个守护进程。

7．2．配置gatekeeper
首先我们修改%deploy%/etc/globus-services，（注意不是%install%/etc/ globus-services.conf，后者需要在本地展开前进行修改）这个文件定义了当前资源提供者可用的服务类型，如我们比较常见的LSF，或者是一个简单的Unix fork，以及其他一些服务。

每种服务在这个文件中用一条记录来表示，每个记录包含下面的字段：
<服务名称> <选项> <用户ID> <命令行> [参数表]
按照默认，gatekeeper提供的服务仅仅是启动一个jobmanager并进行fork操作，于是文件中仅有一条记录：
jobmanager stderr_log,local_cred - /home/globus/gd/libexec/globus-jobmanager globus-jobmanager -conf /home/globus/gd/etc/globus-jobmanager.conf
这样，将来gatekeeper就仅仅接受名称为jobmanager的服务，启动jobmanager，至于jobmanager本身作什么操作，可以在globus-jobmanager.conf中指定。

下面我们修改%deploy%/etc/globus-gatekeeper.conf，这个文件中指明了gatekeeper运行的参数，当然如果不在这里修改，而是在运行时加上这些参数，效果是一样的。

在globus-gatekeeper.conf文件中可以指定gatekeeper所在目录，jobmanager所在目录，证书所在目录，需要监听的端口等等信息，这些都可以使用默认值，我们唯一需要修改的地方是把-inetd 参数替换成-f，后者表示gatekeeper以守护进程的方式运行。

前面说过，之所以这样做是因为我们使用的RedHat7.0对inetd的支持发生了变化。

另外可以加上的一个参数是-d，它表示gatekeeper以debug方式运行，我们可以在log文件中看到更多的错误提示。

当然，如果让gatekeeper以inetd方式运行，还要修改/etc/inetd.conf文件，这就不属于我们要讨论的内容了。

全部修改完毕之后，用root账号在%deploy%/sbin目录下运行gatekeeper：
#./globus-gatekeeper –conf ../etc/globus-gatekeeper.conf&
gatekeeper在作为守护进程运行时不会和终端分离，因此我们必须指定它在后台运行。

下面我们用ps查看，可以看到一个名为globus-gatekeeper的进程，用telnet 127.0.0.1 2119测试，发现2119端口处于监听状态。

7．3．测试gatekeeper
gatekeeper在配置完毕之后，就可以在root账号下运行./globus-gatekeeper
–conf ../etc/globus-gatekeeper.conf –test进行测试，这个测试的主要工作是检查各个工作目录以及gatekeeper证书的合法性，并不实际提交一个任务，因此如果配置合理，通过测试应该是比较容易的。

测试成功的信息如下所示：
Testing gatekeeper
Local user id (uid) : root
Home directory : /home/globus/gd
Libexec directory : /home/globus/gd/libexec
Gatekeeper subject name : "/O=Grid/O=Globus/CN=localhost.localdomain"
Gatekeeper test complete : Success!
Gatekeeper shutting down!
下面列举出我在测试中发现的一些问题，事实上，如果前面每一步都按照我们讨论的步骤进行，这里的问题都不会出现，但我还是列出供参考：
(1)提示错误信息：Problems with security of private key Func : proxy_init_cred
解决：为解决这个问题我在源码中找到了这个proxy_init_cred（定位
于%src%/Security/gssapi-ssleay/sslutils.c中），阅读后发现是因为.cert文件和.key
文件的权限不对。

前面我们在配置证书时说过，这两个文件的属主必须是root，权限必须
是0400。

这样重要的信息在正式文档中居然没有提及。

（事后我在globus站点的FAQ
上见到过）
(2)提示错误信息：Run grid-proxy-init on wgpi first
bad password read
出现这个问题是因为我当时还不能签发证书，随便找到一对公钥和私钥进行测试。

事实上
我们知道，公钥和证书完全是两个不同的概念。

(3)提示错误信息：Function:proxy_init_cred
Reason:User cert has expired。