Things to Look Out For
When Installing GridFTP

____________________________________________

_____________________________________________

 

CRL list:

While I was trying to install GridFTP, I initially encountered the following error when I was trying to execute grid-proxy-init:

[shakib@w04gva shakib]$ grid-proxy-init -debug -verify

User Cert File: /home/shakib/.globus/usercert.pem

User Key File: /home/shakib/.globus/userkey.pem

Trusted CA Cert Dir: /etc/grid-security/certificates

Output File: /tmp/x509up_u2035

Your identity: /O=Grid/O=CERN/OU=cern.ch/CN=Shakib Mostafa

Enter GRID pass phrase for this identity:

Creating proxy .++++++++++++

......++++++++++++

Done

ERROR: Couldn't verify the authenticity of the user's credential to generate a proxy from.

grid_proxy_init.c:951:

globus_gsi_cred_handle.c:1515: globus_gsi_cred_verify_proxy_cert_chain: Error verifying credential: Failed to verify credential

OpenSSL Error: (null):0: in library: (null), function (null): (null)

globus_gsi_callback.c:281: globus_i_gsi_callback_create_proxy_callback: Could not verify credential

globus_gsi_callback.c:440: globus_i_gsi_callback_cred_verify: Could not verify credential: unable to get issuer certificate

 

The reason turned out to be that I did not have an up-to-date CRL list. I was using ca_CERN-0.7, which was supposed to contain information about my used certificate. But later on, when I installed ca_CERN-0.15, grid-proxy-init ran without any trouble. Hence it is very important to make sure that the latest CRL list has been installed.

 

grid-mapfile and .gridmap:

While trying to transfer files one common error message that occurs is:

> globus-url-copy -s "`grid-cert-info -subject`" file:///tmp/file1 gsiftp://192.91.239.2:5678/tmp/file4
error: the server sent an error response: 530 530 No local mapping for Globus ID

This normally occurs if /grid-security/grid-mapfile and ~/.gridmap don't have the exact syntax described in the GridFTP installation section. 

 

Access Rights for User Certificates:

[shakib@w02gva gridftp]$ grid-proxy-init -debug -verify


ERROR: Couldn't find valid credentials to generate a proxy.

grid_proxy_init.c:489:
globus_gsi_system_config.c:3656: globus_gsi_sysconfig_get_user_cert_filename_unix: Error with certificate filename
globus_gsi_system_config.c:380: globus_i_gsi_sysconfig_create_cert_string: Error with certificate filename: /home/shakib/.globus/usercert.pem has invalid permissions.
 

This happens when the user certificates don't have the correct access rights :

usercert.per -rw-r--r--

userkey.pem -r--------

 

resolv.conf:

While trying to transfer files to all DataTAG machines, I sometimes got the following error message: 

[shakib@w05gva shakib]$ globus-url-copy -s "`grid-cert-info -subject`" file:///tmp/file1 gsiftp://192.91.239.3:5680/tmp/file4
error: globus_ftp_control_connect: globus_libc_gethostbyname_r failed
 

This was caused by incorrect information in /etc/resolv.conf. For all DataTAG PCs, this file should contain:

nameserver 192.91.244.10

search datatag.org

 

PID file for GridFTP:

I encountered some problems with the pid file for GridFTP. Every time I was starting the GridFTP server, it produced a syslog error message:

Sep 22 12:35:18 w02gva gridftpd[30100]: Cannot write pidfile: Permission denied
Sep 22 12:35:18 w02gva gridftpd[30100]: FTP server started without ftpaccess file
Sep 22 12:35:18 w02gva gridftpd[30100]: FTP server (GridFTP Server 1.5 [GSI patch v0.5] wu-2.6.2(2) Thu Sep 18 11:24:02 CEST 2003) ready.

The server would still start and there wouldn't be any trouble while transferring data. Because the pid file could not be written, other programs that need to use the pid file would not work properly. This pid file problem may be the reason why the server would crash every time I started the NetLogger daemon. 

I tried to fix this bug in a number of ways. First I found out that this error message originated from the file:

    Server/globus_gridftpserver-1.6/src/ftpd.c

I looked into the code and found the relevant part:

int Bypass_PID_Files = 0;                                                        // line 549

 

if (!Bypass_PID_Files){                                                            // starts from line 8063

    if ((pidfile = fopen(_PATH_FTPD_PID, "w"))) {

            fprintf(pidfile, "%ld\n", (long) getpid());
            fclose(pidfile);
    }
    else {
             syslog(LOG_ERR, "Cannot write pidfile: %m");
    }

}   

I tried to change the mask of the directory where the pid file was to be written by adding the following piece of code:

if (!Bypass_PID_Files){

    mode_t oldumask = umask(0000);

    ...

But that didn't help. Then I tried to change the directory where the pid file was to be written. To do so, I created a directory called /var/run/gridftpd with access right drwxrwxrwx and set _PATH_FTPD_PID to be /var/run/gridftpd/gridftp.pid, but this time also in vain, because just setting _PATH_FTPD_PID = /var/run/gridftpd/gridftp.pid didn't change the value of _PATH_FTPD_PID. I found that out when I put syslog calls at various places of this piece of code and checked the value of _PATH_FTPD_PID, which was still set to /var/run/gridftpd.pid. I also put syslog calls to make sure that the umask was indeed being changed. The umask was indeed changed but unfortunately that did not help.

In the end, I simply changed the default value of Bypass_PID_Files:

int Bypass_PID_Files = 1;             // line 549

This did not fix the error of not being able to write the pid file; rather, it made it possible to skip this section of the code.