From: BrandonHoult (BrandonHoult_at_netscape.net)
Date: Mon 09 Sep 2002 - 21:02:45 BST
Had this problem a while back was caused by different versions of the
library, could bypass by ssh to vserver or upgrade to same libraries
inside and out. Here is a copy of the relavent e-mail
------------------
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
>>
>>
>
>
>
>