Logging each transfer info into separated file no longer supported?

[enricovianello]

We were used to keep separated all the gridftp server's transfer info with -log-transfer option.
But it seems that latest releases have removed this feature because the transfer log file remains empty.
Can you confirm this or -log-transfer option should it still work?

[enricovianello]

After reading code and commits, it may had stopped working after the removal of usage statistics collection support: 9a8f75e#diff-7b8084ebaf25da156f409243079c6b76
could you confirm this?

[fscheiner]

@enricovianello: Thanks for the pointer, I didn't notice that so far.

But I think the relevant code was removed specifically here 9a8f75e#diff-0d41fe5a384e8076fc8f2dc3424bc45a.

I wonder if -log-transfer can work without the Globus Usage Statistics and that it was accidently removed, because the information bits gathered and logged are very similar to identical for both from a quick check. If not, I'm not sure if that functionality will return, as it was/is more important to have that phone home "feature" removed.

CCing @ellert, @matyasselmeci, @msalle here for their assessment.

BTW, globus_i_gfs_log_transfer() - the function used in a part of the above mentioned diff - is still in the source according to a quick search, so maybe this can work w/o the Globus Usage Statistics and we can just partially revert the above mentioned diff to reactivate that -log-transfer functionality.

[msalle]

I'm not sure, we should certainly have feedback from @ellert, but looking at the commit in L10420-10424 and later L10473 versus L10492-10493 it looks like we might be able to roll back just the -log-transfer functionality.

[fscheiner]

Maybe in the meantime @enricovianello could locally test a patch that only restores the -log-transfer functionality? Unfortunately ATM I'm fully occupied with other tasks (GSI-OpenSSH w/HPN for SUSE), so cannot take care of such a patch for some time. So @enricovianello, do you think you could come up with a patch that would accomplish that? Then if @ellert is OK with it later, we could just include that patch in the next GCT (maintenance) version.

[fscheiner]

@enricovianello:
@ellert has partially reverted 9a8f75e#diff-0d41fe5a384e8076fc8f2dc3424bc45a to restore the log-transfer functionality. If you're building your GridFTP server directly from the sources, could you please give it a try with these changes included and report back the result?

[enricovianello]

@fscheiner No, we aren't building our GridFTP server from sources. We developed a dsi module. So, If you've already built a rpm of globus-gridftp-server (something like a nightly or a beta rpm) we can easily test it.

[fscheiner]

@enricovianello
Sorry for the delay, I had already created a comment but it seems it got lost somehow.

@fscheiner No, we aren't building our GridFTP server from sources. We developed a dsi module. So, If you've already built a rpm of globus-gridftp-server (something like a nightly or a beta rpm) we can easily test it.

Sorry, we don't do that right now, but only create updated source tarballs with each new release. But thanks to @matyasselmeci's scripts you can create RPMs yourself from within the source tree. Here's a quick guide on how to do that (I used CentOS7 but assume this will also work for CentOS6 and might also work for CentOS8).

1. First install packages needed for the build:

$ sudo yum install make autoconf automake libtool libtool-ltdl-devel patch curl git bison openssl openssl-devel rpm-build doxygen graphviz 'perl(Pod::Html)' fakeroot udt udt-devel glib2-devel libnice-devel gettext-devel libffi-devel libxml2-devel pam-devel voms-devel cyrus-sasl-devel openldap-devel voms-clients initscripts python-devel 'perl(DBI)' redhat-lsb-core m2crypto mod_ssl mod_wsgi pyOpenSSL python-crypto perl-generators 'perl(Test::More)' gcc-c++ 'perl(URI)'

2. Then enter the <SOURCE_TREE_ROOT>/travis-ci/ subdirectory of the source tree and invoke the following commands:

$ ./make_source_tarballs.sh
$ ./make_rpms.sh -C

NOTICE: If the make process fails due to missing dependencies, install the dependencies and restart the failed command. I did my tests in a non-pristine CentOS7 driven VM, so don't know for sure, that the above package list is complete.

3. The resulting RPM packages are available in <SOURCE_TREE_ROOT>/packaging/rpmbuild/RPMS/

[fscheiner]

Fixed in GCT 6.2.20201212 maintenance release.