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