Re: [Vserver] Step by Step Guide to a nano-vserver
On Wed December 28 2005 16:28, Michael S. Zick wrote: > Joel and Group, > Today's update is available. > > Baby-01 now does proper networking, > only the directions where wrong. > > The December 28th version of the guide has been removed, but my server logs show folks still looking for it. So a small progress note: After a serious re-think of the project... After a very major re-write... After getting past the glibc nonsense... I am now back on the job; The next revision should be posted RSN. (I hope) Mike ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: 2.6.16-rc1-vs2.1.0.9 latest test on parisc
On Fri, Feb 03, 2006 at 05:11:55PM -0500, micah wrote: > In gmane.linux.vserver, you wrote: > > On Thu, Feb 02, 2006 at 02:29:38PM -0500, Micah Anderson wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> Herbert Poetzl wrote: > >> > On Thu, Feb 02, 2006 at 09:33:12AM +0100, Joel Soete wrote: > >> >>On toh for my private build from upstream src (on going to build latest > >> >>0.30.210), I disabled use of dietlibc (not yet available for hppa at this > >> >>time) and all seems to works fine. > >> > > >> > > >> > really depends on the dietlibc, but I'd assume it > >> > is _still_ broken on HPPA, nevertheless the glibc > >> > is _not_ a good alternative, although it _might_ > >> > work for simple things. > >> > >> I guess we can find out when Joel sends results of tests? > > > > possible, well, testme and testfs will not > > detect the insecurities introduced by glibc > > Ah, I meant we can find out if dietlibc is broken on HPPA or not. I > did not mean we can find out if glibc insecurities still exist. hmm, well, then see: http://list.linux-vserver.org/archive/vserver/msg12138.html > >> > PS: I hope that dietlibc on hppa will be fixed soon. > >> > >> Have the issues on HPPA been brought to the dietlibc developers? > > > > yes, but AFAICT, they were ignored ... > > I tried to google around for references to this to see if I could help > push these up, but didn't find anything. Sometimes all it takes is a > ping to the right place to get people to realise that they overlooked > something. please do so if possible :) TIA, Herbert > Micah > ___ > 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] Q: Using the vserver list for kernel development.
On Fri, 2006-02-03 at 21:58 +0100, Cedric Le Goater wrote: > Eric W. Biederman wrote: > > >>>I have recently been doing some vserver related kernel development > >>>but have had no luck CC my patches to the vserver list. This > >>>last round because I CC to many interested parties. > >>> > >>>Is the vserver list supposed to be a place where we can post > >>>patches for discussion? > >> > >>IMHO yes, so please if possible, make that happen ... > > > > Doing my best to CC the interested parties. It looks like the next > > patchset will go out to 14 different recipients. > > :) > > time for a new mailing list ? Well, the limitation might be, that we don't allow attachments or very small ones. I can have a look at things this weekend to increase it. That was the decision mad when we moved the mailinglist the last time. /Martin ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] [glibc] Usage of glibc with VServer tools
On Fri February 3 2006 10:14, Michael S. Zick wrote: > Group, > > An update on the discussions in m-l threads: > re: http://list.linux-vserver.org/archive/vserver/msg09336.html > re: http://list.linux-vserver.org/archive/vserver/msg12349.html > - - - snip - - - > > messages - pointing to the culprits: > > > warning: Using 'getgrent' in statically linked applications requires at > runtime the shared libraries from the glibc version used for linking. > > > With the same warning for: > setgrent, endgrent, getpwent, getpwnam, getpwuid, setpwent, endpwent, > getaddrinfo, getservent, setservent, endservent > > There might be others, those are the ones that Bash-3.1 complains about. > - - - Yup, there are others - - - > > The solution is to include some 'linker magic' in the build of Bash (and > the VServer tools) to include the glibc static library implementation of > those calls. > Close, but no golden ring. First, you have to build a special version of glibc with the dynamic, name system service disabled using instead the older static nss. (The glibc doc's claim it can be done, but I haven't tried it.) After all of that work, a static link of the VServer tools against the special glibc is still just a work-around, same as if the tools where linked against a *libc* that does not provide dynamic nss. I.E: A lot of work for no noticeable benefit or even lost functionality. When the linux dynamic loader can unlink and relink a different DSO in a process image - the situation might change. That feature has been on the glibc wish list for nearly a decade - don't hold your breath. None of this means that you can not use glibc with the dynamic nss enabled, it only places restrictions on version compatibility of the libraries in the host and the guest. Aw, well, back to my own project that sidesteps this whole issue. Mike ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: 2.6.16-rc1-vs2.1.0.9 latest test on parisc
On Fri February 3 2006 16:14, micah wrote: > In gmane.linux.vserver, you wrote: > > On Fri February 3 2006 12:04, Joel Soete wrote: > >> > > >> Appologies for late answer but this isp webmail interface is very a > >> nightmare > >> (it tooks me all this afternoon to reach to login Grrr). > >> > > Joel, > > > > I sent you a possible solution to that problem. > > Of course, that does not mean you received it. > > If this was a solution to Joel's problem with dietlib, can you re-send > it to the list so the rest of us can know the answer? I'd like to be > able to reference it in the future if other HPPA users come here with > the same problem. :) > Sorry, I wasn't clear... The ISP problem, not the dietlibc problems. Due to the ISP problem, I had to steal a little m-l bandwidth. Apologies, Mike ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: 2.6.16-rc1-vs2.1.0.9 latest test on parisc
In gmane.linux.vserver, you wrote: > On Fri February 3 2006 12:04, Joel Soete wrote: >> > >> Appologies for late answer but this isp webmail interface is very a nightmare >> (it tooks me all this afternoon to reach to login Grrr). >> > Joel, > > I sent you a possible solution to that problem. > Of course, that does not mean you received it. If this was a solution to Joel's problem with dietlib, can you re-send it to the list so the rest of us can know the answer? I'd like to be able to reference it in the future if other HPPA users come here with the same problem. :) micah ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: 2.6.16-rc1-vs2.1.0.9 latest test on parisc
In gmane.linux.vserver, you wrote: > On Thu, Feb 02, 2006 at 02:29:38PM -0500, Micah Anderson wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Herbert Poetzl wrote: >> > On Thu, Feb 02, 2006 at 09:33:12AM +0100, Joel Soete wrote: >> >>On toh for my private build from upstream src (on going to build latest >> >>0.30.210), I disabled use of dietlibc (not yet available for hppa at this >> >>time) and all seems to works fine. >> > >> > >> > really depends on the dietlibc, but I'd assume it >> > is _still_ broken on HPPA, nevertheless the glibc >> > is _not_ a good alternative, although it _might_ >> > work for simple things. >> >> I guess we can find out when Joel sends results of tests? > > possible, well, testme and testfs will not > detect the insecurities introduced by glibc Ah, I meant we can find out if dietlibc is broken on HPPA or not. I did not mean we can find out if glibc insecurities still exist. >> > PS: I hope that dietlibc on hppa will be fixed soon. >> >> Have the issues on HPPA been brought to the dietlibc developers? > > yes, but AFAICT, they were ignored ... I tried to google around for references to this to see if I could help push these up, but didn't find anything. Sometimes all it takes is a ping to the right place to get people to realise that they overlooked something. Micah ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Q: Using the vserver list for kernel development.
Eric W. Biederman wrote: >>>I have recently been doing some vserver related kernel development >>>but have had no luck CC my patches to the vserver list. This >>>last round because I CC to many interested parties. >>> >>>Is the vserver list supposed to be a place where we can post >>>patches for discussion? >> >>IMHO yes, so please if possible, make that happen ... > > Doing my best to CC the interested parties. It looks like the next > patchset will go out to 14 different recipients. :) time for a new mailing list ? c. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Q: Using the vserver list for kernel development.
Herbert Poetzl <[EMAIL PROTECTED]> writes: > On Thu, Feb 02, 2006 at 10:55:53AM -0700, Eric W. Biederman wrote: >> >> I have recently been doing some vserver related kernel development >> but have had no luck CC my patches to the vserver list. This >> last round because I CC to many interested parties. >> >> Is the vserver list supposed to be a place where we can post >> patches for discussion? > > IMHO yes, so please if possible, make that happen ... Doing my best to CC the interested parties. It looks like the next patchset will go out to 14 different recipients. Eric ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Samba and Vserver Best Practices
On Fri February 3 2006 12:49, Matt Nuzum wrote: > On 2/3/06, Charles Baker <[EMAIL PROTECTED]> wrote: > > I'm setting up a host server and several vservers that developers in my > > organization will use to test bug fixes of our software. They will > > occasionally need access to certain directories on the vservers to check > > logs, etc. > > > > For convenience sake samba shares to the needed directories would be the > > thing to have. Is the best practice to set up samba on the host server > > and share directories within the /vservers/$SERVERNAME/path/to/log/dir > > or set up samba w/in the vserver itself and share it that way? > > I've pondered this question myself and haven't come to a definite > conclusion. I've had some problems with locking, although that was an > older version of Samba and I here the problem I had has been resolved. > > No matter what I try, I keep coming back to SSH and tail -f and some > other custom tools I've written. > > I've thought about using named pipes that will automatically spit out > log files into multiple places, but I haven't taken the time yet to > persue this. > You mean like: /dev/log (syslog socket)? > > I envision a daemon process that watches the named pipe and (in my > case) spit out a full log file, like normal, then grab "interesting" > log entries and spit them out as separate files into a share that can > be accessed elsewhere. > Perhaps name the daemon syslogd? Try: man syslogd You can specify selected information to be remotely logged. That is the 'common' syslogd on Linux systems, if using one of the alternatives, remote logging might not be supported. Mike > For me, debugging log files containe snippets > of XML and SQL and it would be nice if those XML snippets are saved > out as *.xml files so that they open in XML spy with just a double > click and the sql is saved as *.sql files. > > The only doubt I have about this working is the challenge of keeping > the daemon running. I realize this problem has probably been solved, > but I still wonder how it will work in a named pipe scenario. > > Just food for thought and mindless rambling... > > -- > Matthew Nuzum <[EMAIL PROTECTED]> > www.followers.net - Makers of "Elite Content Management System" > View samples of Elite CMS in action by visiting > http://www.followers.net/portfolio/ > ___ > 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] Samba and Vserver Best Practices
On 2/3/06, Charles Baker <[EMAIL PROTECTED]> wrote: > I'm setting up a host server and several vservers that developers in my > organization will use to test bug fixes of our software. They will > occasionally need access to certain directories on the vservers to check > logs, etc. > > For convenience sake samba shares to the needed directories would be the > thing to have. Is the best practice to set up samba on the host server > and share directories within the /vservers/$SERVERNAME/path/to/log/dir > or set up samba w/in the vserver itself and share it that way? I've pondered this question myself and haven't come to a definite conclusion. I've had some problems with locking, although that was an older version of Samba and I here the problem I had has been resolved. No matter what I try, I keep coming back to SSH and tail -f and some other custom tools I've written. I've thought about using named pipes that will automatically spit out log files into multiple places, but I haven't taken the time yet to persue this. I envision a daemon process that watches the named pipe and (in my case) spit out a full log file, like normal, then grab "interesting" log entries and spit them out as separate files into a share that can be accessed elsewhere. For me, debugging log files containe snippets of XML and SQL and it would be nice if those XML snippets are saved out as *.xml files so that they open in XML spy with just a double click and the sql is saved as *.sql files. The only doubt I have about this working is the challenge of keeping the daemon running. I realize this problem has probably been solved, but I still wonder how it will work in a named pipe scenario. Just food for thought and mindless rambling... -- Matthew Nuzum <[EMAIL PROTECTED]> www.followers.net - Makers of "Elite Content Management System" View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Samba and Vserver Best Practices
I'm setting up a host server and several vservers that developers in my organization will use to test bug fixes of our software. They will occasionally need access to certain directories on the vservers to check logs, etc. For convenience sake samba shares to the needed directories would be the thing to have. Is the best practice to set up samba on the host server and share directories within the /vservers/$SERVERNAME/path/to/log/dir or set up samba w/in the vserver itself and share it that way? ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: 2.6.16-rc1-vs2.1.0.9 latest test on parisc
On Fri February 3 2006 12:04, Joel Soete wrote: > > > Appologies for late answer but this isp webmail interface is very a nightmare > (it tooks me all this afternoon to reach to login Grrr). > Joel, I sent you a possible solution to that problem. Of course, that does not mean you received it. When you get a chance this weekend to beat on your e-mail service, let me know off-list if you didn't receive it. Mike ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: 2.6.16-rc1-vs2.1.0.9 latest test on parisc
Hello Micah, Herbert, Mike, ...
>
> Herbert Poetzl wrote:
> > On Thu, Feb 02, 2006 at 09:33:12AM +0100, Joel Soete wrote:
> >>On toh for my private build from upstream src (on going to build latest
> >>0.30.210), I disabled use of dietlibc (not yet available for hppa at this
> >>time) and all seems to works fine.
> >
> >
> > really depends on the dietlibc, but I'd assume it
> > is _still_ broken on HPPA, nevertheless the glibc
> > is _not_ a good alternative, although it _might_
> > work for simple things.
>
> I guess we can find out when Joel sends results of tests?
>
Appologies for late answer but this isp webmail interface is very a nightmare
(it tooks me all this afternoon to reach to login Grrr).
That said if this interface was more confortable I would probably 'subject'
it: 'new util-vserver-0.30.209-2.deb failled to restart my vps ;_('
Let me tail more few words:
1/ when I installed the pkg a vps (a guest) was still runing and I want
to check that:
# vserver-stat
CTX PROCVSZRSS userTIME sysTIMEUPTIME NAME
0 76 135.7M 46.7M 18m55s70 17m46s40 6h15m00 root server
491529 38.3M 10.8M 0m03s20 0m14s73 6h08m37 <== it
would show DebSid
too bad ;-(
(mmm, btw wouldn't have to stop vps before upgrading? [very no idea])
2/ I then restart the host and try to re-start my guest:
# vserver DebSid start
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
check-unixfile: lseek(): Invalid argument
secure-mount: read(): Success
GRrrr.
Definitly, dietlibc is broken for hppa (not only test) ;-(
I so rebuild latest util-vserver-0.30.210 (disabling dietlibc use) and make
install by hand and restart my guest without pb, though.
> > PS: I hope that dietlibc on hppa will be fixed soon.
>
> Have the issues on HPPA been brought to the dietlibc developers?
>
mmm, as I just discover that it was re-enable since short, I didn't
investigate more, I will try to get some more info?
Tx for kind attention,
Joel
PS: I will take care of all other kind answers from my linux box at home this
week end.
---
A free anti-spam and anti-virus filter on all Scarlet mailboxes
More info on http://www.scarlet.be/
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] [glibc] Usage of glibc with VServer tools
Group,
An update on the discussions in m-l threads:
re: http://list.linux-vserver.org/archive/vserver/msg09336.html
re: http://list.linux-vserver.org/archive/vserver/msg12349.html
At the time of this writing, there are a lot of distributions which
have glibc-2.3.2 deployed (Debian/Sarge for one).
The glibc project has released glibc-2.3.6 recently.
There are distributions which have deployed all versions inbetween,
complicated by distribution specific patches.
If that is not confusing enough, even the same distribution may not
use the same version of glibc (and with the same build options) depending
on the system hardware.
For example, a Debian/Sarge/parisc and a Debian/Sarge/x86 system does
not deploy the same glibc with the same options.
The VServer tools are a combination of low level, compiled tools and
high level, Bash scripts. Both of which need to lookup names.
These programs expect the name lookup functions to be supplied by
the system library[1].
When executing within the host (0) context, the host system library
will be used.
When executing within the guest (>1) context, the guest system library
will be used.
The problems encountered in the referenced m-l threads are related to
when a process has to execute in both/either context(s).
Such behavior happens during the creation of and/or entry into a guest
context.
This is due to there being no guarantee that the libraries in the host
and the guest have compatable name lookup implementations.
Enforcing such a guarantee is not an option - the guest context should
be able to run any system library that is compatable with the host kernel.
One work-around is to staticly link the VServer tools - this 'hardcodes'
the name lookup implementation to whatever code the library used for
linking provided.
But what about the copy of Bash that is running the high level scripts?
Ah, so...
Building a staticly linked[2] copy of Bash-3.1 provides a set of warning
messages - pointing to the culprits:
warning: Using 'getgrent' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking.
With the same warning for:
setgrent, endgrent, getpwent, getpwnam, getpwuid, setpwent, endpwent,
getaddrinfo, getservent, setservent, endservent
There might be others, those are the ones that Bash-3.1 complains about.
Since this warning is related to how glibc implements those functions (in
an external DSO), it applies to any program that makes those function calls
and staticly linked against glibc-2.3.{2,3,4,5,6} even if that program's
build does not report the warnings.
The staticly linked Bash-3.1 will run, without runtime error reports, with
those calls not present. Of course, those functions will not work, but
Bash-3.1 will survive.
The Bash-3.1 config-bot.h may be modified to avoid the features that call
those functions. But that is not the real solution, the VServer tools
need to call those functions also.
The solution is to include some 'linker magic' in the build of Bash (and
the VServer tools) to include the glibc static library implementation of
those calls.
I have not determined that 'linker magic' yet - but the static archives
are present, even with Debian/Sarge binary only, installations.
- - - - -
Notes:
[1] Which flavor of glibc am I building against?
On your VServer tools build system, examine a dynamicly linked application;
your distribution's Bash is probably dynamicly linked, use the ldd script:
enter: ldd /bin/bash
If you see a: linux-gate.so.1 => (high memory address)
then the program is linked to use the kernel's 'fast sys-call' entry.
This is a kernel code provided, virtual, DSO - there should not
be any such file on the system.
Note the actual location of libc.so.6 (on the right of the => thing);
execute the actual library:
(Debian/Sarge/x86 - your milage will vary)
enter: /lib/tls/libc.so.6
Which will report some identifying information.
Determine the library binaries by:
enter: cat /usr/include/gnu/lib-names.h
It is the static libraries for libnss_dns*, libnss_files*, and
libnss_compat* that will need to be included in the 'linker magic'.
- - - - -
[2] Translation of "build a staticly linked Bash"
./configure --enable-net-redirections --enable-static-link \
--disable-rpath --prefix=
(Yes, that is --prefix=, not a typo)
make
make prefix=/opt/gnu/bash-static install-strip
- - - - -
Probably more than anyone wanted to know.
Mike
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: 2.6.16-rc1-vs2.1.0.9 latest test on parisc
On Thu February 2 2006 21:55, Herbert Poetzl wrote: > On Thu, Feb 02, 2006 at 08:08:38PM -0600, Michael S. Zick wrote: > > On Thu February 2 2006 19:32, Herbert Poetzl wrote: > > > On Thu, Feb 02, 2006 at 04:33:16PM -0600, Michael S. Zick wrote: > > > > On Thu February 2 2006 14:09, Herbert Poetzl wrote: > > > > > On Thu, Feb 02, 2006 at 02:29:38PM -0500, Micah Anderson wrote: > > > > > > > > > > > > > > > > > > > > > really depends on the dietlibc, but I'd assume it > > > > > > > is _still_ broken on HPPA, nevertheless the glibc > > > > > > > is _not_ a good alternative, although it _might_ > > > > > > > work for simple things. > > > > > > > > > > > > I guess we can find out when Joel sends results of tests? > > > > > > > > > > possible, well, testme and testfs will not > > > > > detect the insecurities introduced by glibc > > > > > > > > > Are there any tests available to check for these glibc problems? > > > > > > I don't know of explicit tests, but it should be > > > possible to create some, given that somebody wants > > > to spend time on it ... > > > > > > > If not, perhaps a pointer or two into the mail archives on > > > > the subject or pointer(s) to a discussion of the problems found? > > > > > > http://list.linux-vserver.org/archive/vserver/msg09379.html > > > (there are others, just goolge for it) > > > Thanks, now I read what the concerns are. . . > > > > That message is about the date of glibc-2.3.2 - current is 2.3.6 > > > > There has been a fair number of changes done between those versions. > > Some affecting getpwnam() and friends when used in staticly linked > > programs. > > well, please also check how 'small' the statically > linked tools would be when linked against recent glibc > (statically of course :) > That I can do - Just need to look up the information on build machine. This is off topic for the subject - so will break this thread. > > I think both of the mentioned restrictions can now be enforced. > > would be good as a last resort when dietlibc is failing > (as it is currently the case for parisc) > > > Let me spend some time on checking that statement before I go too > > far out on a limb. > > please do so, and keep us posted ... > Next update will be a thread tagged: [glibc] for future m-l reference. Mike ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Proc problem
On Fri, Feb 03, 2006 at 09:22:28AM +0100, Norbert Klamann (Firma) wrote: > Herbert Poetzl schrieb: > > > >after that, whatever path was configured for your > >install (they are somewhat strange on debian, but > >check with 'vserver-info - SYSINFO' if you didn't > >look at the ./configure output), will contain the > >vprocunhide runlevel script, which just has to be > >executed once at system startup ... > > > >HTH, > >Herbert > > Thanks a lot, Herbert, they are there. Does it make sense to integrate > them in the /etc/rc.X.d system ? yes, makes sense to put them there, together with the default guest startup script ... > These tools are very nice, if one gets the hang on them. best, Herbert > Greetings > > Norbert > ___ > 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] Proc problem
Herbert Poetzl schrieb: after that, whatever path was configured for your install (they are somewhat strange on debian, but check with 'vserver-info - SYSINFO' if you didn't look at the ./configure output), will contain the vprocunhide runlevel script, which just has to be executed once at system startup ... HTH, Herbert Thanks a lot, Herbert, they are there. Does it make sense to integrate them in the /etc/rc.X.d system ? These tools are very nice, if one gets the hang on them. Greetings Norbert ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
