From: Nuno Silva (nuno.silva_at_vgertech.com)
Date: Fri 23 Aug 2002 - 06:36:12 BST
Hi!
BrandonHoult wrote:
> Do the libraries have to be identical inside and out?  If so that seems 
Good point! I don't use redhat, so I don't have this problems.
Anyway... I think I know what's wrong. Capchroot is run *after* the 
chroot has been made in the "vserver XYZ start" command.
capchroot is a dynamic exe and it tries to load the (now, chrooted) libs 
that can be different.
***********************************************************
To promote distribution independence I think this should be fixed 
upstream. (Are you reading, Jacques? :))
***********************************************************
The fix is trivial so I won't make a proper diff.
Just change the Makefile and replace:
-----------------------------
capchroot: capchroot.cc syscall.o
         gcc $(GCCOPTS) -DVERSION=\"$(PACKAGE_REV)\" capchroot.cc 
syscall.o -o capchroot \
                 -lstdc++
-----------------------------
with:
------------------------------
capchroot: capchroot.cc syscall.o
         gcc $(GCCOPTS) -static -DVERSION=\"$(PACKAGE_REV)\" 
capchroot.cc syscall.o -o capchroot \
                 -lstdc++
-------------------------------
(Note the added "-static" switch to gcc.)
Then: make;make install
and enjoy =)
This will build a static capchroot that will run (I hope) with any /lib.
Regards,
Nuno Silva
> a little inconvenient, but if I can manage to ssh into it by fixing the
> password as you suggested then it is easy enough to get around.  I will 
> try more stuff and let you know the results tomarrow. Thanks for the 
> help...the open source community is truely amazing sometimes.
> 
> Brandon.
> 
> Paul Sladen wrote:
> 
>> On Thu, 22 Aug 2002, BrandonHoult wrote:
>>
>>  
>>
>>>  So I got the debian image (mini-debian-vservers-020.tgz) and 
>>> followed the instructions.  Now it seems I can ssh to it, but I don't 
>>> know the root password.  *'ed; does not work. [...]
>>>   
>>
>>
>> Passwords are stored as hashes of the actual password in /etc/shadow:
>>
>>  root:P4$$W0RDH4$H:12345:0:99999:7:::
>>
>> (Most of these fields are only relevant to `/etc/passwd' and are 
>> ignored in
>> the shadow password file).  Replacing the password hash with a `*' means
>> that there is an *invalid* password hash and access will be denied 
>> (called
>> ``starring-out'').
>>
>> You can either delete the hash field completely and leave it empty: 
>> `root::'
>> (which means no password set).  To set a a password that you already 
>> know,
>> paste in a password-hash copied out of an existing shadow or passwd 
>> file, or
>> a generated hash using the `htpasswd' program that comes with Apache.
>>
>> It should be noted that the `sshd_config' in Nuno's image does not permit
>> logging in with empty passwords, unless you change it.  Make the changes
>> with a standard $EDITOR (eg.  emacs or vi) from within the *host* server:
>>
>>  root_at_hostserver:~$ emacs /vservers/alpha/etc/shadow
>>  root_at_hostserver:~$ emacs /vservers/alpha/etc/sshd_config
>>
>> I believe Nuno's image starts SSH on a weird port, so you'll probably 
>> want
>> to fix that before use--again, by using an editor on 
>> `etc/ssh/sshd_config'.
>>
>>  
>>
>>> /usr/lib/vserver/capchroot: relocation error: 
>>> /lib/libnss_compat.so.2: symbol _nss_files_parse_pwent, version 
>>> GLIBC_2.0 not defined in file libc.so.6 with link time reference
>>>   
>>
>>
>> This is more worrying since I can't tell you why it is happening;  The
>> dynamic linker--that `plugs in' functions from shared libraries upon an
>> application loading--is complaining that one the functions it is 
>> trying to
>> `plug in' isn't available in the `libnss' library.
>>
>> (The `Name Switch Service' sets the order that glibc searchs for passwd,
>> group and network configuration files in `/etc/';  for instance by using
>> NIS/YP to lookup information from a remote server in preference to 
>> reading
>> the local passwd files.)
>>
>> My take is that it is a glibc versioning problem, checking/updating the
>> versions in use in the image may cure it.  Has anyone (apart from 
>> Nuno! :-)
>> had success, or failure with this latest 0.20 skeleton image?
>>
>>     -Paul
>>  
>>
> 
> 
> 
>