Starting Globus 2.4 Services

These instructions will show you how to start up the various server daemons that you now have on your system. The next section will show you how to verify that they are operating correctly.  In cases where we refer to LD_LIBRARY_PATH, please use your system-equivalent if you have one.  E.g., LIBPATH or LD_LIBRARYN32_PATH.  See your administrator if you do not know which variable to use.

  1. Starting GRAM
  2. Starting MDS
  3. Starting GridFTP

Starting GRAM

While running globus-personal-gatekeeper as a user is a good test, you will want to configure your machine to run globus-gatekeeper as root, so that other people will be able to use your gatekeeper. If you just run the personal gatekeeper, you won't have authority to su to other user accounts. To setup a full gatekeeper, you will need to make the following modifications as root:

In /etc/services, add the service name "gsigatekeeper" to port 2119.

gsigatekeeper      2119/tcp                   # Globus Gatekeeper

Depending on whether your host is running inetd or xinetd, you will need to modify its configuration. If the directory /etc/xinetd.d/ exists, then your host is likely running xinetd. If the directory doesn't exist, your host is likely running inetd. Follow the appropriate instructions below according to what your host is running.

    Inetd
    For inetd, add the following entry, all on one line, to /etc/inetd.conf. Be sure to replace GLOBUS_LOCATION below with the actual value of $GLOBUS_LOCATION in your environment.

       gsigatekeeper stream tcp nowait root
           /usr/bin/env env LD_LIBRARY_PATH=GLOBUS_LOCATION/lib 
           GLOBUS_LOCATION/sbin/globus-gatekeeper
           -conf GLOBUS_LOCATION/etc/globus-gatekeeper.conf

    As noted earlier in this guide, this entry has changed from the entry provided for the gatekeeper in the Globus Toolkit 2.0 Administrator's Guide.  The reason is that if you followed the instructions from the install section, you do not have a static gatekeeper.  This requires you to set the LD_LIBRARY_PATH so that the gatekeeper can dynamically link against the libraries in $GLOBUS_LOCATION/lib.  To accomplish the setting of the environment variable in inetd, we use /usr/bin/env (the location may vary on your system) to first set LD_LIBRARY_PATH, and then to call the gatekeeper itself.

    The advantage of this setup is that when you apply a security update to your installation, the gatekeeper will pick it up dynamically without your having to rebuild it.

    Xinetd
    For xinetd, add a file called "globus-gatekeeper" to the /etc/xinetd.d/ directory that has the following contents. Be sure to replace GLOBUS_LOCATION below with the actual value of $GLOBUS_LOCATION in your environment.

       service gsigatekeeper
       {
          socket_type  = stream
          protocol     = tcp
          wait         = no
          user         = root
          env          = LD_LIBRARY_PATH=GLOBUS_LOCATION/lib
          server       = GLOBUS_LOCATION/sbin/globus-gatekeeper
          server_args  = -conf GLOBUS_LOCATION/etc/globus-gatekeeper.conf
          disable      = no
       }

    As noted earlier in this guide, this entry has changed from the entry provided for the gatekeeper in the Globus Toolkit 2.0 Administrator's Guide.  The reason is that if you followed the instructions from the install section, you do not have a static gatekeeper.  This requires you to set the LD_LIBRARY_PATH so that the gatekeeper can dynamically link against the libraries in $GLOBUS_LOCATION/lib.  To accomplish the setting of the environment variable in xinetd, we use the "env =" option to set LD_LIBRARY_PATH in the gatekeeper's environment.

    The advantage of this setup is that when you apply a security update to your installation, the gatekeeper will pick it up dynamically without your having to rebuild it.

After you have added the globus-gatekeeper service to either inetd or xinetd, you will need to notify inetd (or xinetd) that its configuration file has changed. To do this, follow the instructions for the server you are running below.

    Inetd
    On most Linux systems, you can simply run `killall -HUP inetd`

    On other systems, the following has the same effect: ps aux | grep inetd | awk '{print $2;}' | xargs kill -HUP

    Xinetd
    On most linux systems, you can simply run `/etc/rc.d/init.d/xinetd restart`.  Your system may also support the "reload" option.

    On other systems (or if that doesn't work), see man xinetd.

At this point, your gatekeeper will start up when a connection comes in to port 2119, and will keep a log of its activity in $GLOBUS_LOCATION/var/globus-gatekeeper.log. However, it does not yet have any authorization mapping between certificate subjects and usernames. You will need to create a file named /etc/grid-security/grid-mapfile which consists of single line entries listing a certificate subject and a username, like this:

"/O=Grid/O=Globus/OU=your.domain/CN=Your Name"    youruserid
    

You can check your subject name using grid-cert-info -subject.  There are utility commands in $GLOBUS_LOCATION/sbin/grid-mapfile* for adding entries, removing entries, and checking consistency.

Starting MDS

Start MDS 2.4 with the following command:

   % GLOBUS_LOCATION/sbin/globus-mds start

This command starts the OpenLDAP 2.0 slapd server for the GRIS. It does not require the environment variable $GLOBUS_LOCATION to be set. To make this startup automatic, place it in the startup scripts of your machine. Contact your system administrator to determine where the call to this script needs to be placed. On a RedHat Linux system, the answer is /etc/rc.d/init.d, with a call to that script made in the appropriate /etc/rc.d/rc?.d (where ? is the default runlevel of your system, as specified in /etc/inittab).

There is a single slapd instance for both GRIS and GIIS.

You are now set for anonymous queries. For non-anonymous queries, you will need a server certificate, and a grid-mapfile for MDS.  MDS defaults to using the same grid-mapfile as GRAM, namely /etc/grid-security/grid-mapfile.  To change that location, modify $GLOBUS_LOCATION/etc/grid-info-server-env.conf.

Setting up a GridFTP server

Setting up GridFTP is similar to setting up a gatekeeper. Make the following changes to your system as root:

Add an entry to /etc/services reading:

   gsiftp  2811/tcp

Depending on whether your host is running inetd or xinetd, you will need to modify its configuration file.

    Inetd
    For inetd, add the following entry, all on one line, to /etc/inetd.conf. Be sure to replace GLOBUS_LOCATION below with the actual value of $GLOBUS_LOCATION in your environment.

        gsiftp  stream  tcp     nowait  root
          /usr/bin/env env LD_LIBRARY_PATH=GLOBUS_LOCATION/lib
          GLOBUS_LOCATION/sbin/in.ftpd -l -a -G GLOBUS_LOCATION
    

    As noted earlier in this guide, this entry has changed from the entry provided for the GridFTP server in the Globus Toolkit 2.0 Administrator's Guide.  The reason is that if you followed the instructions from the install section, you do not have a static in.ftpd.  This requires you to set the LD_LIBRARY_PATH so that the server can dynamically link against the libraries in $GLOBUS_LOCATION/lib.  To accomplish the setting of the environment variable in inetd, we use /usr/bin/env (the location may vary on your system) to first set LD_LIBRARY_PATH, and then to call in.ftpd itself.

    The advantage of this setup is that when you apply a security update to your installation, the GridFTP server will pick it up dynamically without your having to rebuild it.

    Xinetd
    For xinetd, add a file called "grid-ftp" to the /etc/xinetd.d/ directory that has the following contents. Be sure to replace GLOBUS_LOCATION below with the actual value of $GLOBUS_LOCATION in your environment.

        service gsiftp
        {
    	    instances               = 1000
    	    socket_type             = stream
    	    wait                    = no
    	    user                    = root
    	    env			    = LD_LIBRARY_PATH=GLOBUS_LOCATION/lib
    	    server                  = GLOBUS_LOCATION/sbin/in.ftpd
    	    server_args             = -l -a -G GLOBUS_LOCATION
    	    nice                    = 10
                disable                 = no
        }
    

    As noted earlier in this guide, this entry has changed from the entry provided for the GridFTP server in the Globus Toolkit 2.0 Administrator's Guide.  The reason is that if you followed the instructions from the install section, you do not have a static in.ftpd.  This requires you to set the LD_LIBRARY_PATH so that the server can dynamically link against the libraries in $GLOBUS_LOCATION/lib.  To accomplish the setting of the environment variable in xinetd, we use the "env =" option to set LD_LIBRARY_PATH in the gatekeeper's environment.

    The advantage of this setup is that when you apply a security update to your installation, the GridFTP server will pick it up dynamically without your having to rebuild it.

The -G GLOBUS_LOCATION (remember to substitute your real GLOBUS_LOCATION) tells the in.ftpd to look for ftpaccess in $GLOBUS_LOCATION.  If you do not specify this flag, the server will use /etc/ftpaccess.

After you have added the gridftp service to either inetd or xinetd, you will need to notify inetd (or xinetd) that its configuration file has changed. To do this, follow the instructions for the server you are running below.

    Inetd
    On most linux systems, you can simply run `killall -HUP inetd`

    On other systems, the following has the same effect: ps aux | grep inetd | awk '{print $2;}' | xargs kill -HUP

    Xinetd
    On most linux systems, you can simply run `/etc/rc.d/init.d/xinetd restart`

    On other systems (or if that doesn't work), see man xinetd.

    GridFTP uses /etc/grid-security/grid-mapfile for authorization, just like GRAM.

Back to Index


Charles Bacon

Last modified: Wed Sep 27 11:01:50 CDT 2002