 |
 |
Dear experts, we have a common cluster filesystem (BeeGFS) we are exporting with xrootd for Grid access. In addition, we now consider to export the filesystem (which itself is in a private network no user can access) for user access in our "desktop" network via xrootd, i.e. "mount" the xrootd-exported FS on normal desktop machines so users can access their data on the large BeeGFS storage directly. For this, xrootdfs seems to be the way to go. The scheme would be: - xrootd data servers and redirector mount BeeGFS (i.e. the servers live in the private network and the internal desktop network). - Desktops authenticate via KRB5 with the xrootd redirector / servers. - Desktops and xrootd servers use sssd + Kerberos V + LDAP so they all "know" the same set of users and groups. Now my question is, before I delve deeper in the configuration manual and perform tests: With a single xrootdfs mount (via fstab) on the desktop machines, does the User-Mapping work as expected, i.e. will users see "their" files with correct permissions, and can they use shared directories belonging to their groups? It's crucial that also the files on BeeGFS will be created with the correct UID / GID - since users will also submit jobs working on BeeGFS natively, running with their UID. From a glance at the documentation, it sadly seems that all files would be handled by the single user which the xrootd servers are running as, and a mapping of users to directory permissions would only be possible via sss authentication + ACLs, which would ignore any existing file permissions on BeeGFS. Is this true? If yes: Is there another way to achieve what we would like with xrootd? We are especially interested in xrootd here since it allows to easily increase the bandwidth by just adding more data servers, and we are running the machinery for Grid purposes in any case. It would also allow mounting our BeeGFS from virtually anywhere (for example, from inside containers of jobs running on desktops, or even in the cloud if we open up our servers further). In case xrootdfs turns out not to be able to solve this, I am also very happy to accept any other options that may come to mind. Many thanks in advance and all the best, Oliver -- Oliver Freyermuth Universität Bonn Physikalisches Institut Nußallee 12 53115 Bonn -- ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1