Re: [Vserver] Screen inside vserver
Herbert Poetzl wrote: PS: a simple but suprisingly natural solution is to start the screen on the host, right _before_ the enter (which will work quite fine) head -> table ARGH - great !! Will try this ;) Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 smime.p7s Description: S/MIME Cryptographic Signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
On Sat, Jan 14, 2006 at 11:48:56AM -0600, Michael S. Zick wrote:
> On Sat January 14 2006 11:20, Benedikt Boehm wrote:
> > On Saturday 14 January 2006 17:34, Michael S. Zick wrote:
> > > Using: strace -o screen.txt -e trace=file screen (from within an
> > > xterm)...
> > > These are the system calls (in the guest) that you have to make
> > > succeed from the host that is running udev (the pts/1 is because
> > > the xterm is using pts/0):
> > > - - - -
> > > readlink("/proc/self/fd/0", "/dev/pts/1", 511) = 10
> > > - - - -
> > > readlink("/proc/self/fd/0", "/dev/pts/1", 4095) = 10
> > > stat64("/dev/pts/1", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...})
> > > = 0 open("/dev/pts/1", O_RDWR|O_NONBLOCK) = 3
> > > - - - -
> > > So a simple hardlink might not work, but having a rule
> > > script that also (on the host) makes the correct node in
> > > ///dev/pts/* should work.
> > you're not supposed to make device nodes in /dev/pts, because it is
> > a dynamic filesystem showing allocated pseudo terminals... [1]
> > > Note that it is the stat64 ... st_rdev=makedev(136, 1) that is the
> > > call to the udev system, in your case, triggered on the guest and
> > > but directed at the host.
> > > So the question remains: Which VServer (by host path) and which
> > > xid?
> > > It can't be the /proc/self/ read by the script, since
> > > that is running on the host - not in the guest context that
> > > triggered the request for a pts.
> > > Still scratching my head over this question - it might require a
> > > pre-loaded *.so in the guest context to trap these trigger events
> > > and proxy them to the udev system running in the host context
> > > (with the additional info required).
> > > I just hope someone can suggest an easier way. A good starting
> > > point would be to repeat my tests, since they may have cockpit
> > > errors.
> > Well, prefering fixes and not workarounds (as stated previously ;)
> > i'd rather tend to create the necessary files in /dev/pts (inside
> > the guest) by allocating a pseudo terminal after migrating the
> > vserver process.. trying it out right now, and will report any issue
> > back here..
let me first explain _why_ this happens and _what_
actually happens, so that you can talk about solutions
regarding the issue instead of voodoo :)
I assume you ssh-ed to your host somehow, which
established a pseudo terminal to work as logon terminal
and which is your 'current' connection to the outside
you can verify that with the following commands:
# ls -la /proc/self/fd/{0,1}
lrwx-- 1 root root 64 2006-01-14 20:02 /proc/self/fd/0 -> /dev/pts/0
lrwx-- 1 root root 64 2006-01-14 20:02 /proc/self/fd/1 -> /dev/pts/0
now, this pseudo terminal was allocated via the /dev/ptmx
terminal multiplexor, which 'assigned' the /dev/pts/0
to the host context (i.e. it is tagged as being a host
terminal for linux-vserver)
now you enter the guest via:
# vserver test101 enter
which does not change anything on the file descriptors
or terminal allocations ... (i.e. the ls from above will
give the exactly same results) but, the following command:
# ls /dev/pts/
1
clearly shows that there is no /dev/pts/0 anymore. why?
simple, because the /dev/pts (which is a virtual filesystem
called devpts -- what a name!) is isolated in regard of
contexts, on the host, the same command will show:
# ls /dev/pts/
0
so, this kind of isolation ensures that the guests will
not read from other guests pseudo terminals and/or send
strange commands to the other end ...
so, the 'real' issue/question is, how to 'reconnect' the
ssh (or whatever) you used to reach the host, with a
new pseude terminal inside the guest in a secure way ...
HTC,
Herbert
PS: a simple but suprisingly natural solution is to
start the screen on the host, right _before_ the enter
(which will work quite fine)
> The main issue is that the /dev/pts is a kernel provided, virtual
> filesystem that tracks which of the 255 pts are in use.
> However you do it, you have to run through the kernel in context 0 so
> that its record keeping is correct.
> Otherwise, you might end up using pts/0 in all of the guests while the
> kernel records that pts/0, pts/1, pts/2 ... are in use.
> I am pretty sure that the kernel will believe any major/minor number a
> device special node carries - so even though the kernel is assigning
> a new /dev/pts/16 to the most recent request - hand creating a
> /vserver/vps16/dev/pts/16 should work since it has the correct
> major/minor. Programs within the guest (such as login) that check
> for a link outside of /dev/* will only see the guest's view of
> /dev/pts/16.
> I am not suggesting that one should modify /dev/pts/* - only the
> /vserver/vps16/dev/pts/16 path. The trick is keeping it in lock-step
> with the kernel's virtual filesystem.
>
> Mike
>
>
> > [1] http://www.nsa.gov/selinux/papers/slinux/node60.html
> > ___
> > Vserver mailing list
Re: [Vserver] Screen inside vserver
On Sat January 14 2006 11:25, Oliver Welter wrote: > Hi Guys, > > sorry for the hints - but dont make too much noise ,) > > seems to be not that easy... > No problem. It was a good question. It needs to be dealt with sooner or later. You might want to reconsider running sshd in your guest while the answer developes ;-) Mike > Oliver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
On Sat January 14 2006 11:20, Benedikt Boehm wrote:
> On Saturday 14 January 2006 17:34, Michael S. Zick wrote:
> > Using: strace -o screen.txt -e trace=file screen (from within an xterm)...
> >
> > These are the system calls (in the guest) that you have to make succeed
> > from the host that is running udev (the pts/1 is because the xterm is using
> > pts/0):
> >
> > - - - -
> > readlink("/proc/self/fd/0", "/dev/pts/1", 511) = 10
> > - - - -
> > readlink("/proc/self/fd/0", "/dev/pts/1", 4095) = 10
> > stat64("/dev/pts/1", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...})
> > = 0 open("/dev/pts/1", O_RDWR|O_NONBLOCK) = 3
> > - - - -
> >
> > So a simple hardlink might not work, but having a rule script that also (on
> > the host) makes the correct node in ///dev/pts/*
> > should work.
>
> you're not supposed to make device nodes in /dev/pts, because it is a dynamic
> filesystem showing allocated pseudo terminals... [1]
>
> >
> > Note that it is the stat64 ... st_rdev=makedev(136, 1) that is the call to
> > the udev system, in your case, triggered on the guest and but directed at
> > the host.
> >
> > So the question remains: Which VServer (by host path) and which xid?
> >
> > It can't be the /proc/self/ read by the script, since that is
> > running on the host - not in the guest context that triggered the request
> > for a pts.
> >
> > Still scratching my head over this question - it might require a pre-loaded
> > *.so in the guest context to trap these trigger events and proxy them to
> > the udev system running in the host context (with the additional info
> > required).
> >
> > I just hope someone can suggest an easier way.
> > A good starting point would be to repeat my tests, since they may have
> > cockpit errors.
>
> Well, prefering fixes and not workarounds (as stated previously ;) i'd rather
> tend to create the necessary files in /dev/pts (inside the guest) by
> allocating a pseudo terminal after migrating the vserver process.. trying it
> out right now, and will report any issue back here..
>
The main issue is that the /dev/pts is a kernel provided, virtual filesystem
that tracks which of the 255 pts are in use.
However you do it, you have to run through the kernel in context 0 so that its
record keeping is correct.
Otherwise, you might end up using pts/0 in all of the guests while the kernel
records that pts/0, pts/1, pts/2 ... are in use.
I am pretty sure that the kernel will believe any major/minor number a device
special node carries - so even though the kernel is assigning a new /dev/pts/16
to the most recent request - hand creating a /vserver/vps16/dev/pts/16 should
work since it has the correct major/minor. Programs within the guest (such as
login) that check for a link outside of /dev/* will only see the guest's view
of /dev/pts/16.
I am not suggesting that one should modify /dev/pts/* - only the
/vserver/vps16/dev/pts/16 path. The trick is keeping it in lock-step with the
kernel's virtual filesystem.
Mike
> [1] http://www.nsa.gov/selinux/papers/slinux/node60.html
> ___
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
>
>
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
Hi Guys, sorry for the hints - but dont make too much noise ,) seems to be not that easy... Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 smime.p7s Description: S/MIME Cryptographic Signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
On Saturday 14 January 2006 17:34, Michael S. Zick wrote:
> Using: strace -o screen.txt -e trace=file screen (from within an xterm)...
>
> These are the system calls (in the guest) that you have to make succeed
> from the host that is running udev (the pts/1 is because the xterm is using
> pts/0):
>
> - - - -
> readlink("/proc/self/fd/0", "/dev/pts/1", 511) = 10
> - - - -
> readlink("/proc/self/fd/0", "/dev/pts/1", 4095) = 10
> stat64("/dev/pts/1", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...})
> = 0 open("/dev/pts/1", O_RDWR|O_NONBLOCK) = 3
> - - - -
>
> So a simple hardlink might not work, but having a rule script that also (on
> the host) makes the correct node in ///dev/pts/*
> should work.
you're not supposed to make device nodes in /dev/pts, because it is a dynamic
filesystem showing allocated pseudo terminals... [1]
>
> Note that it is the stat64 ... st_rdev=makedev(136, 1) that is the call to
> the udev system, in your case, triggered on the guest and but directed at
> the host.
>
> So the question remains: Which VServer (by host path) and which xid?
>
> It can't be the /proc/self/ read by the script, since that is
> running on the host - not in the guest context that triggered the request
> for a pts.
>
> Still scratching my head over this question - it might require a pre-loaded
> *.so in the guest context to trap these trigger events and proxy them to
> the udev system running in the host context (with the additional info
> required).
>
> I just hope someone can suggest an easier way.
> A good starting point would be to repeat my tests, since they may have
> cockpit errors.
Well, prefering fixes and not workarounds (as stated previously ;) i'd rather
tend to create the necessary files in /dev/pts (inside the guest) by
allocating a pseudo terminal after migrating the vserver process.. trying it
out right now, and will report any issue back here..
[1] http://www.nsa.gov/selinux/papers/slinux/node60.html
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
On Sat January 14 2006 09:48, Benedikt Boehm wrote:
> On Saturday 14 January 2006 16:46, Benedikt Boehm wrote:
> > On Saturday 14 January 2006 16:08, Michael S. Zick wrote:
> > > On Sat January 14 2006 08:59, Michael S. Zick wrote:
> > > > On Sat January 14 2006 06:40, Oliver Welter wrote:
> > > > > eyck wrote:
> > > > > >> afair, you have to ssh into the box to use screen.
> > > > > >> vserver enter and issuing a screen command does not work.
> > > > > >
> > > > > > it's not that it doesn't work, it's that it easier and safer to
> > > > > > tell people 'just ssh into your guest' instead of explaining how to
> > > > > > make it work.
> > > > >
> > > > > As I dont have SSH running inside the guest and I am not afraid of
> > > > > some work, how :)
> > > >
> > > > You could try making it 'by hand' - but that would only work for the
> > > > pts that you create by hand. Also recall, that on that system, you are
> > > > using udev and /dev is probably mounted in /tmpfs, not as persistent
> > > > files on the hard disk.
> > > > Gentoo gives you three ways to handle a missing device (follow the
> > > > directions for a missing /dev/console or /dev/null).
> > > >
> > > > But what you want to handle is dynamic devices (pts 0...254) in the
> > > > guest with a device creation system that runs in the host.
> > > >
> > > > First, grab all the udev manuals you can lay your hands on...
> > > >
> > > > The 'stock' system scripts are creating devices in '/dev'; modify to
> > > > create them also in ///dev
> > > >
> > > > Sorry, I don't know how only what.
> > >
> > > Scratch that - - here is how:
> > >
> > > Each udev rule can call an external script - write one that hardlinks the
> > > just created /dev/pts/xx to a ///dev/ptx/xx
> > >
> > > Now all you have to do is figure out 'which vserver' to create the link
> > > in.
> > >
> > > Mike
>
> i missed that you link it in the root path of the vserver.. probably it
> works,
> but it looks more like a workaround, than a fix..
>
Ah, yes, an interesting problem. But a step towards getting the correct USB
socket (dedicated to a particular workstation) with a security device to show
up in the correct vserver dedicated to that particular workstation.
Using: strace -o screen.txt -e trace=file screen (from within an xterm)...
These are the system calls (in the guest) that you have to make succeed from
the host that is running udev (the pts/1 is because the xterm is using pts/0):
- - - -
readlink("/proc/self/fd/0", "/dev/pts/1", 511) = 10
- - - -
readlink("/proc/self/fd/0", "/dev/pts/1", 4095) = 10
stat64("/dev/pts/1", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0
open("/dev/pts/1", O_RDWR|O_NONBLOCK) = 3
- - - -
So a simple hardlink might not work, but having a rule script that also (on the
host) makes the correct node in ///dev/pts/* should work.
Note that it is the stat64 ... st_rdev=makedev(136, 1) that is the call to the
udev
system, in your case, triggered on the guest and but directed at the host.
So the question remains: Which VServer (by host path) and which xid?
It can't be the /proc/self/ read by the script, since that is running
on the host - not in the guest context that triggered the request for a pts.
Still scratching my head over this question - it might require a pre-loaded *.so
in the guest context to trap these trigger events and proxy them to the udev
system
running in the host context (with the additional info required).
I just hope someone can suggest an easier way.
A good starting point would be to repeat my tests, since they may have cockpit
errors.
Mike
> >
> > The thing is, you normally don't run udev inside a vserver, because you
> > don't have CAP_MKNOD...
> >
It would be reasonable to only run udev on the host - host does hardware
management,
even software emulated hardware.
> >
> > the problem with /dev/pts entries not appearing on vserver ... enter is
> > that the vserver prorcess only migrates to the context and replaces itself
> > with bash, so there is no login process and no terminal devices are created
> > by devpts filesystem (in contrary to the ssh attempt)...
> >
> > i don't know a solution for this atm, but if anyone can help, i'd
> > appreciate it
> >
> > Bene
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
On Saturday 14 January 2006 16:46, Benedikt Boehm wrote: > On Saturday 14 January 2006 16:08, Michael S. Zick wrote: > > On Sat January 14 2006 08:59, Michael S. Zick wrote: > > > On Sat January 14 2006 06:40, Oliver Welter wrote: > > > > eyck wrote: > > > > >> afair, you have to ssh into the box to use screen. > > > > >> vserver enter and issuing a screen command does not work. > > > > > > > > > > it's not that it doesn't work, it's that it easier and safer to > > > > > tell people 'just ssh into your guest' instead of explaining how to > > > > > make it work. > > > > > > > > As I dont have SSH running inside the guest and I am not afraid of > > > > some work, how :) > > > > > > You could try making it 'by hand' - but that would only work for the > > > pts that you create by hand. Also recall, that on that system, you are > > > using udev and /dev is probably mounted in /tmpfs, not as persistent > > > files on the hard disk. > > > Gentoo gives you three ways to handle a missing device (follow the > > > directions for a missing /dev/console or /dev/null). > > > > > > But what you want to handle is dynamic devices (pts 0...254) in the > > > guest with a device creation system that runs in the host. > > > > > > First, grab all the udev manuals you can lay your hands on... > > > > > > The 'stock' system scripts are creating devices in '/dev'; modify to > > > create them also in ///dev > > > > > > Sorry, I don't know how only what. > > > > Scratch that - - here is how: > > > > Each udev rule can call an external script - write one that hardlinks the > > just created /dev/pts/xx to a ///dev/ptx/xx > > > > Now all you have to do is figure out 'which vserver' to create the link > > in. > > > > Mike i missed that you link it in the root path of the vserver.. probably it works, but it looks more like a workaround, than a fix.. > > The thing is, you normally don't run udev inside a vserver, because you > don't have CAP_MKNOD... > > the problem with /dev/pts entries not appearing on vserver ... enter is > that the vserver prorcess only migrates to the context and replaces itself > with bash, so there is no login process and no terminal devices are created > by devpts filesystem (in contrary to the ssh attempt)... > > i don't know a solution for this atm, but if anyone can help, i'd > appreciate it > > Bene > > > > Mike > > > > > > > Oliver > > > > > > ___ > > > Vserver mailing list > > > Vserver@list.linux-vserver.org > > > http://list.linux-vserver.org/mailman/listinfo/vserver > > > > ___ > > Vserver mailing list > > Vserver@list.linux-vserver.org > > http://list.linux-vserver.org/mailman/listinfo/vserver > > ___ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
On Saturday 14 January 2006 16:08, Michael S. Zick wrote: > On Sat January 14 2006 08:59, Michael S. Zick wrote: > > On Sat January 14 2006 06:40, Oliver Welter wrote: > > > eyck wrote: > > > >> afair, you have to ssh into the box to use screen. > > > >> vserver enter and issuing a screen command does not work. > > > > > > > > it's not that it doesn't work, it's that it easier and safer to tell > > > > people 'just ssh into your guest' instead of explaining how to make > > > > it work. > > > > > > As I dont have SSH running inside the guest and I am not afraid of some > > > work, how :) > > > > You could try making it 'by hand' - but that would only work for the pts > > that you create by hand. Also recall, that on that system, you are using > > udev and /dev is probably mounted in /tmpfs, not as persistent files on > > the hard disk. > > Gentoo gives you three ways to handle a missing device (follow the > > directions for a missing /dev/console or /dev/null). > > > > But what you want to handle is dynamic devices (pts 0...254) in the guest > > with a device creation system that runs in the host. > > > > First, grab all the udev manuals you can lay your hands on... > > > > The 'stock' system scripts are creating devices in '/dev'; modify to > > create them also in ///dev > > > > Sorry, I don't know how only what. > > Scratch that - - here is how: > > Each udev rule can call an external script - write one that hardlinks the > just created /dev/pts/xx to a ///dev/ptx/xx > > Now all you have to do is figure out 'which vserver' to create the link in. > > Mike The thing is, you normally don't run udev inside a vserver, because you don't have CAP_MKNOD... the problem with /dev/pts entries not appearing on vserver ... enter is that the vserver prorcess only migrates to the context and replaces itself with bash, so there is no login process and no terminal devices are created by devpts filesystem (in contrary to the ssh attempt)... i don't know a solution for this atm, but if anyone can help, i'd appreciate it Bene > > > Mike > > > > > Oliver > > > > ___ > > Vserver mailing list > > Vserver@list.linux-vserver.org > > http://list.linux-vserver.org/mailman/listinfo/vserver > > ___ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
On Sat January 14 2006 08:59, Michael S. Zick wrote: > On Sat January 14 2006 06:40, Oliver Welter wrote: > > eyck wrote: > > >> afair, you have to ssh into the box to use screen. > > >> vserver enter and issuing a screen command does not work. > > > it's not that it doesn't work, it's that it easier and safer to tell > > > people 'just ssh into your guest' instead of explaining how to make it > > > work. > > > > As I dont have SSH running inside the guest and I am not afraid of some > > work, how :) > > > You could try making it 'by hand' - but that would only work for the pts > that you create by hand. Also recall, that on that system, you are using > udev and /dev is probably mounted in /tmpfs, not as persistent files on > the hard disk. > Gentoo gives you three ways to handle a missing device (follow the directions > for a missing /dev/console or /dev/null). > > But what you want to handle is dynamic devices (pts 0...254) in the guest > with a device creation system that runs in the host. > > First, grab all the udev manuals you can lay your hands on... > > The 'stock' system scripts are creating devices in '/dev'; modify to create > them also in ///dev > > Sorry, I don't know how only what. > Scratch that - - here is how: Each udev rule can call an external script - write one that hardlinks the just created /dev/pts/xx to a ///dev/ptx/xx Now all you have to do is figure out 'which vserver' to create the link in. Mike > Mike > > Oliver > ___ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver > > ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
On Sat January 14 2006 06:40, Oliver Welter wrote: > eyck wrote: > >> afair, you have to ssh into the box to use screen. > >> vserver enter and issuing a screen command does not work. > > it's not that it doesn't work, it's that it easier and safer to tell > > people 'just ssh into your guest' instead of explaining how to make it > > work. > > As I dont have SSH running inside the guest and I am not afraid of some > work, how :) > You could try making it 'by hand' - but that would only work for the pts that you create by hand. Also recall, that on that system, you are using udev and /dev is probably mounted in /tmpfs, not as persistent files on the hard disk. Gentoo gives you three ways to handle a missing device (follow the directions for a missing /dev/console or /dev/null). But what you want to handle is dynamic devices (pts 0...254) in the guest with a device creation system that runs in the host. First, grab all the udev manuals you can lay your hands on... The 'stock' system scripts are creating devices in '/dev'; modify to create them also in ///dev Sorry, I don't know how only what. Mike > Oliver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Guest OS Stops Responding After Hours Of Working
On Fri January 13 2006 18:19, John Alberts wrote: > Hi all. I'm using vserver on a Gentoo machine. I originally tried to get > some help on the gentoo-vserver irc channel; however, I think we must all > have opposite schedules. > > Anyway, I am using Gentoo for my host machine and also Gentoo as the guest > os. The guest os runs Apache2 and MySQL and it works well for a while (5, 6 > hours). After a while I am unable to connect to the guest os. From the > host os, I can reach the guest os (ping, browse web page using links, etc), > but not from outside the host os. If I go into the guest os using vserver > myguest enter, the only fqdn i can ping is the one for the host os the is in > my hosts file. No other fqdn's work. > Is DNS accessible on both nic cablings? Could be the resolver is trying the nic/cable setup that does not reach any name server. > If I ping a known working ip address, > everything starts working again! I have no idea what this means or how to > fix it. As a temporary solution, just to keep my guest os working, I put a > cron job that pings 2 different servers every half hour. > I think it's probably a routing problem, but I'm not sure what to do. My > host has 2 gigabit nics, both on the same subnet. > > Here is my ifconfig -a and route from my host os: (route hangs a while and > then finally prints the output below) > The delay in route response is probably DNS lookup time (failing and retrying) See if there is a difference in: "route " and "route -n" See below > --- > ifconfig -a > > route > > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse > Iface > 205.215.68.0* 255.255.255.0 U 0 00 eth0 > 205.215.68.0* 255.255.255.0 U 0 00 eth1 > loopback* 255.0.0.0 U 0 00 lo > default 205.215.68.254 0.0.0.0 UG0 00 eth0 > default 205.215.68.254 0.0.0.0 UG0 00 eth1 > Note there is no name resolution for names not in '/etc/hosts' > > > Here is the ifconfig -a and route from inside my guest os: > -- > ifconfig -a > eth0 Link encap:Ethernet HWaddr 00:04:23:C3:C4:FE > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:929890 errors:0 dropped:0 overruns:0 frame:0 > TX packets:981291 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:256023685 (244.1 Mb) TX bytes:1085603257 (1035.3 Mb) > Base address:0xecc0 Memory:df9e-dfa0 > > eth0:100 Link encap:Ethernet HWaddr 00:04:23:C3:C4:FE > inet addr:205.215.68.100 Bcast:205.215.68.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:929890 errors:0 dropped:0 overruns:0 frame:0 > TX packets:981291 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:256023685 (244.1 Mb) TX bytes:1085603257 (1035.3 Mb) > Base address:0xecc0 Memory:df9e-dfa0 > > route > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse > Iface > 205.215.68.0* 255.255.255.0 U 0 00 eth0 > 205.215.68.0* 255.255.255.0 U 0 00 * > loopback* 255.0.0.0 U 0 00 * > default 205.215.68.254 0.0.0.0 UG0 00 eth0 > default * 0.0.0.0 UG0 00 * > -- > Same here. What is the search order in /etc/host.conf? What name services in /etc/resolv.conf? What are the service providers for 'hosts:' in /etc/nsswitch.conf Duh... Which libc version is handling the above? Mike > Thanks in advance for any help. > > John > ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
eyck wrote: afair, you have to ssh into the box to use screen. vserver enter and issuing a screen command does not work. it's not that it doesn't work, it's that it easier and safer to tell people 'just ssh into your guest' instead of explaining how to make it work. As I dont have SSH running inside the guest and I am not afraid of some work, how :) Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 smime.p7s Description: S/MIME Cryptographic Signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
> afair, you have to ssh into the box to use screen. > vserver enter and issuing a screen command does not work. it's not that it doesn't work, it's that it easier and safer to tell people 'just ssh into your guest' instead of explaining how to make it work. -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Total Existance Failure ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Screen inside vserver
afair, you have to ssh into the box to use screen. vserver enter and issuing a screen command does not work. kind regards, raoul bhatia Oliver Welter wrote: Hi Folks, anyway who can point me to an idea how to use "screen" inside a guest ? When calling screen, it complains about the nonexisting "/dev/pts/0"... Can I safely create the device or will this be a security issue ?? Guest (and Host) is Gentoo, 2.6.15vs2.1 with recent utils regards Oliver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- raoul bhatia email.[EMAIL PROTECTED] ipax web.http://www.ipax.at - chief technician, support - irc. #ipax (quakenet) ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Screen inside vserver
Hi Folks, anyway who can point me to an idea how to use "screen" inside a guest ? When calling screen, it complains about the nonexisting "/dev/pts/0"... Can I safely create the device or will this be a security issue ?? Guest (and Host) is Gentoo, 2.6.15vs2.1 with recent utils regards Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 smime.p7s Description: S/MIME Cryptographic Signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
