Re: [ROOT] Problems with shared libraries in rootd authentication

From: Birger Koblitz (Birger.Koblitz@cern.ch)
Date: Mon Apr 26 2004 - 17:39:50 MEST


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