From: BrandonHoult (BrandonHoult_at_netscape.net)
Date: Fri 23 Aug 2002 - 05:14:29 BST
Ok, I haven't yet tried these suggestions, am going to bed now and will
try tomorrow. But right after I wrote that e-mail I thought I would see
what would happen if I just copied libc.so.6 & libnss_compat.so.2 from
the /lib into /vservers/debian/lib. The error changed to some other lib
file so I just copied the entire /lib from the redhat install.
Strangely enough this seemed to work, and I could enter the vserver and
apt-get update. I don't have any delusions that this was actually a
good idea though... seems that arbitrarily overwriting library files is
going to cause a problem somewhere, so I was going to mess with it some
more tomarrow. I thought it was odd that the files inside the vserver
would effect the functioning of the external "vserver debian enter"
command. Do the libraries have to be identical inside and out? If so
that seems 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
>
>