Hi Fons, maybe I was not really clear. I expect the _user_ to start the rootd/proofd, he wants his own rootd/proof-server. In a grid-environment, what would happen is: - User gets node A - User sets LD_LIBARY_PATH on A - User deploys his peferred rootd/proofd on A - User starts his analysis on another node B using node A with proof/rootd service -> Authentication should work on A, even if the rootd/proofd is provided by the user. This is what I tested. If you use inetd to start the rootd/proofd, then the user cannot choose, however in a Grid-Environment (given the constant improvement/change of root ;-) ) user will want to make their own choices and start their daemon themselves. When authenticaton is done this should work using static tools or using the same LD_LIBRARY_PATH as used when the user started the daemon. Cheers, Birger On 26 Apr 2004, Fons Rademakers wrote: > Hi Birger, > > I can look into linking it statically. However, note that normally > also rootd will fail in this setup (without gcc lib path in ld.so.conf) > if started via inetd. > > Cheers, Fons. > > > On Mon, 2004-04-26 at 16:53, Birger Koblitz wrote: > > Hi Fons, > > > > I understood that. However, in a Grid-Environment this will not work, > > since users will not have root-privileges but will expect to nevertheless > > choose their root-installation. They can choose the rootd service, only > > the authentication to it will then fail, because of the LD_LIBRARY_PATH. > > Maybe it would be possible to statically link the authentication tools > > such as ssh2rpd? After authentication the user could set the paths. > > > > Another solution would be that the rootd which starts his authentication > > service knows about library paths, this should be possible. It was also > > the user with his LD_LIBRARY_PATH who started the server, so the > > information is available to rootd. > > My suggestions: The authentication service is started from the rootd in > > the same environment in which the rootd was started itself. Would that be > > possible? > > > > Cheers, > > Birger > > > > > > On 26 Apr 2004, Fons Rademakers wrote: > > > > > Hi Birger, > > > > > > how should the server know where to find the LD_LIBRARY_PATH? The > > > program is being called before the user is authenticated. The best thing > > > to do in such cases is to have the sysadmin who installed the > > > non-standard compiler to add the lib directories of the compiler to > > > /etc/ld.so.conf, in this case: > > > > > > /usr/local/gcc-alt-3.2.3/lib > > > > > > > > > Cheers, Fons. > > > > > > > > > > > > On Mon, 2004-04-26 at 15:09, Birger Koblitz wrote: > > > > Hi, > > > > > > > > I am looking into PROOF for the ARDA project and did some tests with the > > > > rootd, first. I ran into the following problem: > > > > I use the root 4.00.03 installation at > > > > /afs/cern.ch/sw/root/v4.00.03/rh73_gcc32/root and have started up the > > > > rootd successfully. Now, when I try to authenticate via ssh, I get > > > > > > > > /afs/cern.ch/sw/root/v4.00.03/rh73_gcc32/root/bin/ssh2rpd: error while > > > > loading shared libraries: libgcc_s.so.1: cannot open shared object file: > > > > No such file or directory > > > > > > > > It seems my LD_LIBRARY_PATH settings are not correctly taken into account. > > > > Looking at > > > > ldd /afs/cern.ch/sw/root/v4.00.03/rh73_gcc32/root/bin/ssh2rpd > > > > libdl.so.2 => /lib/libdl.so.2 (0x4002a000) > > > > libstdc++.so.5 => /usr/local/gcc-alt-3.2.3/lib/libstdc++.so.5 > > > > (0x4002e000) > > > > libm.so.6 => /lib/i686/libm.so.6 (0x400df000) > > > > libgcc_s.so.1 => /usr/local/gcc-alt-3.2.3/lib/libgcc_s.so.1 > > > > (0x40101000) > > > > libc.so.6 => /lib/i686/libc.so.6 (0x42000000) > > > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > > > > > > > suggests problems with the gcc3.2 libraries. As root on that machine I > > > > fixed this problem easily by links of libstdc++.so.5 and lib/libgcc_s.so.1 > > > > into /lib. My question: > > > > > > > > Within the Grid-Framework it will be necessary that the users run > > > > individualized versions of root on the machines depending on their library > > > > paths. They cannot depend on the superuser to solve their problems. Did I > > > > overlook anything, or is this currently impossible? > > > > > > > > Cheers, > > > > Birger > > > > -- Birger Koblitz +41 22 767-3318 CERN IT 2-1-046
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:07 MET