 |
 |
Hi, Artem and Andi I fixed the autotools build in the current xrootd CVS head and tested it on Linux (32bit, Intel and AMD based) and Solaris 9 on sparc. Only the javaint I couldn't get to compile, but it also failed with configure.classic, so I guess it might still be unstable, at least judging from the configure.classic code. The Tokenauthz libraries that are needed as an additional dependency one needs to get from the ARDA repository as written on the link I sent you: For the CVS version. cvs -d:pserver:[log in to unmask]:/local/reps/arda co -d TokenAuthz alice/TokenAuthz Artem. If you have difficulties compiling on opteron/Solaris10, can you give me temporary access to such a machine? I spent last year quite some time with resolving build issues, so I think I should be able to fix it fast. Cheers, Derek On Friday 03 February 2006 17.42, Artem Trunov wrote: > Hi, Derek! > > Ok, thanks! > Nothing is really urgent here, I can use your tarball by now. However I do > need a source for building on our opteron servers under Solaris 10. :( > > Artem. > > On Fri, 3 Feb 2006, Derek Feichtinger wrote: > > Hi, Artem > > > > I noticed yesterday that the head of the xrootd CVS does no longer build > > with autotools (must have been some change in the last week), so I'll > > investgate and try to fix it asap. > > > > The error you are getting is due to a missing dependency (tokenauthz) you > > can find on the arda www area: When I still was at CERN working for > > ALICE, I had set up this page for alice downloads of xrootd (we had a > > separate autotools build, before most of this went into the xrootd CVS) > > > > http://project-arda-dev.web.cern.ch/project-arda-dev/xrootd/tarballs/ > > > > I don't know which version Andreas is currently using, but he is be the > > best source for how to operate the XrdTokenAuthz, because he implemented > > most of it and only AliEn is currently enabled for this method. I cannot > > test here, because I don't have an AliEn setup. > > > > Cheers, > > Derek > > > > On Friday 03 February 2006 16.17, Artem Trunov wrote: > > > Hi, Derek! > > > > > > Thanks for all explanations! I am now trying to actually setup servers > > > for Alice. > > > > > > Since this libTokenAuthzOfs library is replacing libXrdOfs in the > > > xrd.fslib directive , is it compatible with original? > > > > > > I tried to compile xrootd (20060105-0311) with token support, but got > > > the following: > > > > > > XrdTokenAuthzOfs.cc:8:25: TTokenAuthz.h: No such file or directory > > > XrdTokenAuthzOfs.cc: In member function `virtual int > > > XrdTokenAuthzOfsFile::open(const char*, int, unsigned int, const > > > XrdSecEntity*, const char*)': > > > XrdTokenAuthzOfs.cc:71: `TAuthzXMLreader' undeclared (first use this > > > function) > > > > > > ..etc... > > > > > > For my very first tests, I can probably use production alien > > > installation at our site with it's token library, but I do need to be > > > able to compile xrootd with it for normal production installations... > > > > > > Is this just packaging problems? Or there dependencies on ROOT? > > > > > > Artem. > > > > > > On Thu, 2 Feb 2006, Derek Feichtinger wrote: > > > > Hi, Artem > > > > > > > > On Thursday 02 February 2006 11.10, Artem Trunov wrote: > > > > > Hi, Derek! > > > > > > > > > > Thanks for detailed explanations! I now see that we indeed can't > > > > > get away with generic setup of xrootd clusters, and will have to > > > > > run AliEn-enabled version. It's not a big problem by itself, buth > > > > > there is a complication - we have to maintain authorization > > > > > database on every leaf node - not a nice thing... > > > > > > > > No, I was too unclear in my previous mail. > > > > The leaf nodes are completely generic. They all contain the same > > > > little policy file where keys per VO are defined and maybe some > > > > special rules, if required (you can slice of part of the namespace > > > > for a certain VO, etc). The authorization decision is taken by the > > > > catalog. The token you get contains everything that the xrootd needs > > > > to determine the access rights. The method just guarantees that the > > > > catalog's decision is safely forwarded to the xrootd. > > > > > > > > Conceptually, the catalog is the owner of all files in this method > > > > (however, we provided a possibility in the policy file, where local > > > > site policy can be enforced, since this is a requirement from some > > > > sites). > > > > > > > > > If I understad you correctly, you prefere to avoid authorization on > > > > > the master, and push it to leaf nodes? What do you think about > > > > > reverse solution - authorization only on the master? This way the > > > > > master is also you authorization server, and leaf nodes are > > > > > generic... > > > > > > > > We want to avoid authentication on the redirector, because it is slow > > > > (and as a consequence, I cannot do full authorization, because this > > > > depends on prior authentication). The redirector should work in a way > > > > that it can redirect clients as fast as possible, leaving the grunt > > > > work to the leafs. > > > > > > > > For your approach, you would need to modify the xrootd protocol in a > > > > way that the redirector informs the leaf that your access is allowed, > > > > because your client is not proxied through the redirector to the > > > > leafs, but really makes an own connection to the leaf node: If you > > > > know the name of the file and on which leaf it resides, you can just > > > > go there directly without ever contacting the redirector. So, in the > > > > present system you need authen and authz on the leafs. > > > > I think this is ok, because the additional effort is then optimally > > > > distributed over the servers and you don't have a bottleneck in a > > > > centrally important machine. > > > > > > > > Cheers, > > > > Derek > > > > > > > > > Artem. > > > > > > > > > > On Thu, 2 Feb 2006, Derek Feichtinger wrote: > > > > > > Hello, Artem > > > > > > > > > > > > > > we would be forced to run it on both redirectors and leaf > > > > > > > > nodes (awful). > > > > > > > > > > > > > > Could you please explain a bit more, since this contradicts to > > > > > > > Andy's answer. I.e. what will happen if Alien client carrying > > > > > > > authz token comes to a server w/o AliEn authz lib? > > > > > > > > > > > > Ok. In our current design, the client asks the xrootd for the > > > > > > LFN. The PFN is contained in the encrypted token from the catalog > > > > > > together with the permission information and the requester's > > > > > > certificate subject (the token can contain entries for multiple > > > > > > files). But the redirector needs to know the PFN in order to > > > > > > perform its duty, so it has to decrypt the token. > > > > > > > > > > > > xrootd gets the request as a normal URL: > > > > > > root://server/LFN?authz=encrypted-token&vo=VO-name > > > > > > > > > > > > This was done, so that even the names of the physical files are > > > > > > hidden from outside (and we wanted to have this in mainly to show > > > > > > what possibilities the method offers, also for the paper we > > > > > > presented at SC05). However, this forces us to decode the token > > > > > > already on the redirector. > > > > > > We could drop this hiding of the PFN, or we could think of a > > > > > > setup where we still perform the token decryption on the > > > > > > redirector, but without doing any authentication there. > > > > > > Authentication will then be done on the leaf node together with > > > > > > another token decryption. The token decryption is pretty fast > > > > > > (<10 ms). > > > > > > I think this would be a good solution. > > > > > > > > > > > > The whole mechanism has the advantage that it can be easily > > > > > > implemented for every catalog and that a single server can also > > > > > > easily work securely for a number of different VOs (the catalog > > > > > > and the storage elements just need to know each others public > > > > > > keys. That's the central part of the encryption) Here is a link > > > > > > to the SC05 paper, if you are interested: > > > > > > > > > > > > Paper: http://people.web.psi.ch/feichtinger/doc/authz.pdf > > > > > > > > > > > > (slides, somewhat flashy and ppt format): > > > > > > http://people.web.psi.ch/feichtinger/doc/Grid05_dfeich.ppt > > > > > > > > > > > > > > > > > > Cheers, > > > > > > Derek