About this list Date view Thread view Subject view Author view Attachment view

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Tue 28 Dec 2004 - 01:33:33 GMT

On Mon, Dec 27, 2004 at 08:16:54PM -0500, Stephen Frost wrote:
> * Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de) wrote:
> > sfrost_at_snowman.net (Stephen Frost) writes:
> > > and that it perhaps shouldn't even be packaged at all
> >
> > No, things like $PACKAGE_VERSION are changing with every version and
> > must be told to the single scripts. Same holds for the configured paths.
> So, it's used by scripts *and* is compiled into programs? I'm thinking
> it might go in /usr/share/util-vserver then, since it's not
> system-dependent and isn't configurable. The other option would be
> /usr/lib/util-vserver, either would be fine with me.
> > > (or installed by make install- is it?), but I'm a little concerned
> > > about some of the constants that are in there- what's the problem with
> > > searching the path for things like awk, grep, etc?
> >
> > Some might be unneeded, but:
> >
> > * /sbin might be missing in $PATH (it happens that 'vserver ... start'
> > cleans the environment, or when vshelper is called by the kernel
> > directly)
> vserver should only be run by root, no? If root doesn't have sbin in
> his path then there's something not right. dpkg handles this by
> checking for the things it needs being in the path and bailing if
> they're not.
> Not entirely sure what to tell you about vshelper and being called by
> the kernel... That's just an odd situation. :) Is there any
> environment at that point, coming from *somewhere*?

yes, there is an environment and it is coming from
the kernel ... currently that is:

        char *envp[] = {"HOME=/", "TERM=linux",

plus three further vars:

        snprintf(cmd_buf, sizeof(cmd_buf)-1, "VS_CMD=%08x", cmd);
        snprintf(uid_buf, sizeof(uid_buf)-1, "VS_UID=%d", current->uid);
        snprintf(pid_buf, sizeof(pid_buf)-1, "VS_PID=%d", current->pid);

> > * you can configure tools with special paths at ./configure time
> Yeah, so, that doesn't exactly cut it when we're talking about something
> that goes into a binary package. :P
> > * execve(2) is more efficiently than execvp(3)
> Is there something in here that actually would notice from such a
> change? Seriously, is there *really* some benefit here for an end user
> or is this just a lame excuse thrown in at the end? :P I don't recall
> anything where performance changes at that level would make a bit of
> difference in the vserver stuff.
> > Ok, as long as the tools are labeled 'alpha' I do not intend to introduce
> > so-naming.
> Fair enough, then they won't be included in Debian as seperate packages
> for people to develop against.

well, maybe we should try to get out of alpha in near
future as I think we will need non-alpha tools for a
stable 2.6 release ...

> > > Sounds like maybe it shouldn't be shipped in the release tarball
> > > then..
> >
> > No, it must be shipped. Else 'rpmbuild -ta util-vserver...tar.bz2' would
> > not work anymore.
> Hrmpf. Then can we just not delete it in make clean? That'd work
> too...
> Stephen


> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver

Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Tue 28 Dec 2004 - 01:33:47 GMT by hypermail 2.1.3