Hi Birger, I am well aware of the Grid sandbox environment where everything runs under the users account. Since ssh2rpd is started by the sshd (which does NOT run under the user's environment, even on the Grid) we need to statically link this program. Cheers, Fons. On Mon, 2004-04-26 at 14:39, Birger Koblitz wrote: > 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 > > > > > > -- Org: CERN, European Laboratory for Particle Physics. Mail: 1211 Geneve 23, Switzerland E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248 WWW: http://www.rademakers.org/fons/ Fax: +41 22 7679480
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:07 MET