globus-gridftp-server authentication broken?

[gusbroo]

Hello,

On September 17 yum installed a globus gridftp server update: globus-gridftp-server-13.20-1.el6.x86_64 Since then, all transfers fail with 530 530-Login incorrect. : globus_gss_assist: Error invoking callout 530-globus_callout_module: The callout returned an error 530-an unknown error occurred 530 End.

There is no information whatsoever in the logs (and the logs don't rotate anymore). The start of the log doesn't say anything about trying to read the gridmap-file. (I cannot tell if this was in the old version as that had run for too long for things to still be in the logs.)

I don't even know where to start. This is rather urgent.

Thanks,

Gustaaf

[maarten-litmaath]

Hoi Gustaaf, the first few items on this page may still give you a clue:

https://wiki.egi.eu/wiki/Tools/Manuals/SiteProblemsFollowUp#Authentication

[msalle]

Hi Gustaaf, it would also be useful to know which callout you're running. What is in /etc/grid-security/gsi-authz.conf ?

[gusbroo]

Hi Gustaaf, it would also be useful to know which callout you're running. What is in /etc/grid-security/gsi-authz.conf ?

Hi: globus_mapping liblcas_lcmaps_gt4_mapping.so lcmaps_callout

[gusbroo]

Hi again, One thing I realized is we have the globus griftp server from epel, but lcmaps from osg. So I switched the globus gridftp server to the osg version (13.11-1.1.osg34.el6, vs 13.20-1.el6 from epel), and just doing that "solved" the issue. I.e. things work again, but I still don't know what the source of the problem is/was. Gustaaf

[matyasselmeci]

The OSG version modifies the init script/service file to set some environment variables required to get LCMAPS to work. We'd like to upstream those changes one day so OSG GridFTP sites can just use the RPMs from EPEL, but we'd need to make them less OSG-specific first.

[gusbroo]

Hi, It looks like at least one problem is that the epel GridFTP is looking for the lcmaps db in the wrong spot: Sep 22 03:21:26 xenia globus-gridftp-server: lcmaps: /etc/lcmaps/lcmaps.db:1: [error] Could not open file '/etc/lcmaps/lcmaps.db'. => in our installation it is /etc/lcmaps.db

I'm going to close this issue now, as the problem is gone and I cannot go back to the epel version to debug further.

Thanks for the help.

Gustaaf

[fscheiner]

The OSG version modifies the init script/service file to set some environment variables required to get LCMAPS to work. We'd like to upstream those changes one day so OSG GridFTP sites can just use the RPMs from EPEL, but we'd need to make them less OSG-specific first.

@matyasselmeci @msalle @ellert Should we put up a warning so user don't mix packages from OSG and EPEL in the meantime? If yes, any suggestions for the place: gridcf.org, discuss@gridcf.org, announcement@gridcf.org?

CCing @gusbroo from here on Or is there a way to configure the package manager to prefer packages from specific repos over packages from other repos?

I found https://docs.fedoraproject.org/en-US/Fedora/14/html/Musicians_Guide/sect-Musicians_Guide-CCRMA_Repository_Priorities.html which seems to allow something like that:

If a newer version is available at a repository with lower priority, yum does not upgrade the package.

Careful, higher priority there means lower number actually (i.e. 1 means highest prio. 99 means lowest prio.).

[matyasselmeci]

OSG specifically uses yum priorities to prefer OSG versions of packages over EPEL (and OS) versions. Fortunately we're down to only a few globus/gct packages: globus-gridftp-server, gsi-openssh, and myproxy. Upstreaming those patches is on our todo list.

[msalle]

FYI the EGI UMD is doing the same, i.e. using yum priorities. @matyasselmeci keep me in the loop about upstreaming your patches, in particular anything related to LCMAPS.

[matyasselmeci]

@msalle of course! Hopefully one day we can stop using yum priorities...

[fscheiner]

@matyasselmeci Does OSG still plan to upstream the mentioned changes? I think if they are useful for our users, we should have them here, too.