RucioN2N does direct access to mounted name space

[gbehrmann]

We spent years to get rid of any reliance on a mounted name space. RucioN2N reintroduces such a check:

                    if (Files.exists(path)) {

This will only work if you have an NFS mount of dCache on this host. Rather than checking yourself, you should let dCache check the patch by simply returning it.

Even if the name space is mounted, your check would fail if a site uses a standard dCache setup in which the door runs as an unprivileged user. E.g. at NDGF most dCache code runs as user 'dcache' however that user doesn't have access to any of the atlas name space. So even when the name space is mounted (which most of the time it is not), your code would not have privileges to check if the file exists.

[ivukotic]

I would love to remove that. What do I replace it with?

Just returning it is not an option. Maybe intention of this part of code is not clear: Even with RUCIO n2n is not one-to-one but one-to-few. In other words: while the second path of the file is completely deterministic (scope/xx/xx/filename), the first part can be one or more of the “storage token” values read at initialization from a remote repository. The code is also trying to speed things up by first looking up places that had largest number of “hits”.

On Nov 19, 2013, at 1:12 , Gerd Behrmann notifications@github.com<mailto:notifications@github.com> wrote:

We spent years to get rid of any reliance on a mounted name space. RucioN2N reintroduces such a check:

                if (Files.exists(path)) {

This will only work if you have an NFS mount of dCache on this host. Rather than checking yourself, you should let dCache check the patch by simply returning it.

Even if the name space is mounted, your check would fail if a site uses a standard dCache setup in which the door runs as an unprivileged user. E.g. at NDGF most dCache code runs as user 'dcache' however that user doesn't have access to any of the atlas name space. So even when the name space is mounted (which most of the time it is not), your code would not have privileges to check if the file exists.

— Reply to this email directly or view it on GitHubhttps://github.com/ivukotic/plugins/issues/14.

[gbehrmann]

I see. You are correct that the intention of the code was not entirely clear to me. Unfortunately doing a direct callout to PnfsManager is not that easy to do from within the plugin. There are ways, but they are ugly. You could instantiate the Chimera library directly. That needs access to the Chimera database, still bypassing PnfsManager. Still not that clean to do for a plugin, but it would solve the issue with requiring a mounted name space and solve the issue with authorization.

Something along the lines of:

    BoneCPDataSource ds = new BoneCPDataSource();
    ds.
    ds.setJdbcUrl(url);
    ds.setUsername(username);
    ds.setPassword(password);
    ds.getConfig().setDefaultReadOnly(true);
    JdbcFs fs = new JdbcFs(ds, dialect);

    fs.path2inode(path);

The last line will throw FileNotFoundHimeraFsException if the file does not exist. Username and other settings should be extracted from the properties that get injected into your plugin.