 |
 |
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 >