Re: [Vserver] packaging review for new Debian packages
Kilian Krause <[EMAIL PROTECTED]> writes: >> > | * The distclean target does also remove util-vserver.spec which is >> > | shipped in the release tarball. >> >> Where is the problem? The corresponding clean-rule is autogenerated >> by autoconf and the file can be recreated by './configure' resp. >> './config.status'. > > The point is you don't delete files you ship in the release tarball. > Thus if the spec is included in the official tarball the clean shouldn't > remove it. This sounds to me like deleting util-vserver.spec is a job for the maintainer-clean target. GruÃ, Uli pgpO3CNAniopa.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
Stephen Frost <[EMAIL PROTECTED]> writes: > * Enrico Scholz ([EMAIL PROTECTED]) wrote: >> [EMAIL PROTECTED] (Herbert Poetzl) writes: >> > | * A lot of programs don't have documentation. Add man pages in DocBook? >> >> Maintainership of the man-pages will be a problem; especially in >> the current stage where features might be added or removed very >> fast. Incorrect documentation is worse than missing one. > > It'd be nice if the commits of such feature addition/deletion also > included the appropriate documentation changes... In addition, the > man-pages could have a note in them about the current flux or some such. In the current stage where the APIs aren't even fix yet, maintaining accurately detailed man pages is a PITA and almost impossible to do. However, the basic idea what, say, lsxid does will remain the same, even if the options will still change. So a man page for lsxid which basically says ,- |NAME | lsxid - list files with their context ID |SYNOPSIS | lsxid [options] [files...] |DESCRIPTION | List context IDs of files. Context IDs are blah... |NOTE | lsxid is still very much in alpha stage. Therefore, its options are | still changing a lot. Run "lsxid --help" for information on the | current set of options. `- would not take any time to maintain but still would give users valuable assistance. >> > | * The distclean target does also remove util-vserver.spec which is >> > | shipped in the release tarball. >> >> Where is the problem? The corresponding clean-rule is autogenerated >> by autoconf and the file can be recreated by './configure' resp. >> './config.status'. > > Sounds like maybe it shouldn't be shipped in the release tarball then.. The release tarball requires the util-vserver.spec in order for rpmbuild -ta util-vserver-0.30.196.tar.gz to build an RPM package. > Debian packages are generally built along the lines of 'make clean, > generate Debian diff, configure, make, make install'. We don't like > things showing up in the Debian diff that shouldn't really be there. :) > It makes everyone's life harder having to deal w/ large diffs... GruÃ, Uli pgp6qGNREFDwU.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
Stephen Frost <[EMAIL PROTECTED]> writes: > Just as another (very) interested Debian developer- > > The graphviz stuff sounds new, I don't recall seeing it when I did > 0.30.195.. In general I'd say either remove it or use something free to > build it. graphviz is used by doxygen while building the API docs, and at least my 0.30.195 tarball already contains the corresponding options in lib/apidocs/Doxyfile.in. GruÃ, Uli pgpvRIslqRjqI.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
Stephen Frost <[EMAIL PROTECTED]> writes: > * Herbert Poetzl ([EMAIL PROTECTED]) wrote: >> |- How should the packaging devide up the groups most conveniently? >> >> util-vserver-0.30.196 >> util-vserver-lib-0.30.196 >> util-vserver-sysv-0.30.196 >> util-vserver-core-0.30.196 >> util-vserver-build-0.30.196 >> util-vserver-legacy-0.30.196 > > Good grief, Charlie Brown. That's a hell of alot of packages. The > 0.30.195 i386 .deb that I did ended up being only 330k. I don't think > it's useful to split up util-vserver into this many packages on Debian, > in fact, I think it'd be a *terrible* idea. I'd say perhaps a main > util-vserver package and a -doc package. Maybe a -lib/-dev, but only if > something outside of util-vserver is expected to use the libraries/API > provided by util-vserver (do any actually exist?, is it even sane?). Putting the legacy stuff into a separate legacy package would help new users a lot by reducing confusion as to what is legacy and what is not. >> | * guest systems cannot run klogd (because there is only one kernel and >> | the klogd thus is best addressed in the host system). >> | So a distribution has to ship an empty dummy package to satisfy the >> | packages which depend on klogd (Debian: linux-kernel-log-daemon). >> >> hmm, this is a kernel issue, and maybe we can solve >> that at this level (by providing a fake or empty >> connection point for klogd) but IMHO it would be best >> to break up the syslog package into syslogd and klogd >> (which would render this point obsolete) > > ehhh, I don't think util-vserver as a package should really care about > this all that much. People can install syslog-ng and use that instead > (that's what I do). A fake/empty connection point for klogd isn't all > that bad of an idea, imv, though. On my Debian Sarge system, these packages depend on the virtual package linux-kernel-log-daemon: syslog-ng socklog-run metalog So there should be some package for installation on guest systems which provides linux-kernel-log-daemon. However, as there seems to be a concensus that there should be nothing vserver specific to be installed on a vserver guest, it cannot be "util-vserver" with its tools which provides linux-kernel-log-daemon, but there must be a separate package. GruÃ, Uli pgpAEvJlNV3vs.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
Herbert Poetzl <[EMAIL PROTECTED]> writes: > On Mon, Dec 27, 2004 at 09:05:21PM -0500, Stephen Frost wrote: >> * Herbert Poetzl ([EMAIL PROTECTED]) wrote: >> > On Mon, Dec 27, 2004 at 08:48:43PM -0500, Stephen Frost wrote: >> > > syslogd and klogd are seperate packages already, the problem is that >> > > klogd doesn't work and complains because it doesn't have proper >> > > permissions. I think that's the main issue... >> > >> > hmm, so why not simply unconfigure (remove the link for >> > the kernel logger service for the default runlevel) and >> > be done? no change required at all, right? >> >> Sure, but you can't do that in the Debian util-vserver package. :) Can't >> touch other package config files. That's one of the reasons why I think >> it shouldn't be the Debian's packages problem- let the user handle it, >> it's not that big of a deal... >> >> > so I see no issue there, as I said, just unconfigure >> > that 'hardware' related service like the others >> > (random, rtc, usb ...) >> >> Again, a Debian util-vserver package couldn't do that due to sane policy >> issues. It'd be nice if we didn't have to worry about it because the >> kernel/vserver patch took care of it, but otherwise I think the user can >> handle it and maybe we could have some stuff in README.Debian about it. > > you got that one wrong, the service is working fine > on the host, it's the guest setup which doesn't allow > for those services, and this IMHO has to be configured > at guest installation anyway (otherwise you end up with > a lot of error messages, when the vserver tries to access > the hardware, configure the usb disks or set the system > time) ... > > so I really, really, dont see any issues with disabling > klogd (runlevel service that is) for a guest when it is > isntalled, and this will solve the klogd issues in the > guest (there should be none on the host, if so then it's > a bug and we will try to fix it ...) And you can even do that disabling cleanly and automatically if you install your guest systems with a virtual klogd instead of the standard one which contains nothing but Provides: linux-kernel-log-daemon Conflicts: linux-kernel-log-daemon Replaces: linux-kernel-log-daemon OK, it could make sense to call this package not "util-vserver-something" but "vserver-guest". This isn't about util-vserver any more, but more something like adding Debian support for a new hardware platform. And for the other hardware stuff Herbert mentioned (random, rtc, usb)... theoretically, this vserver-guest package could pull in dependencies on adapted versions, or provide virtual packages which aren't useful on the guest system. GruÃ, Uli ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Vserver configuration for IPv4 and IPv6
Hi, this is an excerpt from util-vserver-0.30.196/doc/cfg.txt: /etc/vservers |-- `-- interfaces |-- [dev] |-- [prefix] |-- [mask] |-- [bcast] `-- * |-- ip |-- [dev] |-- [prefix] |-- [mask] |-- [bcast] |-- [name] |-- [scope] |-- [only_ip] ...use only the ip; do not modify/set | the interface `-- [disabled] ...ignore this interface This looks pretty much IPv4-centristic to me. Is that correct? If so, I think IPv6 support should be added in a way that IPv4 and IPv6 are equally represented. Something like this: /etc/vservers |-- `-- interfaces |-- [dev] |-- ipv4 | |-- [prefix] | |-- [mask] 1.2.3.0/24 notation is better | `-- [bcast] |-- ipv6 | |-- [prefix] | `-- [prefixlength] `-- * Something similar should then be done under *. Unfortunately I don't know enough details about vserver yet to judge whether what I described above a) is feasible from a technical point of view b) is sensible from a simplicity and consistency point of view c) is feasible from a political point of view (concerns for installed base of vservers with different configuration) Support for IPv6 in the vserver kernel patch will appear some time soon, and there is no configuration for IPv6 yet, so the matter of configuring IPv6 has to be raised one way or the other anyway :) GruÃ, Uli pgpSWYL5FX6Zt.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
Herbert Poetzl <[EMAIL PROTECTED]> writes: > On Tue, Dec 28, 2004 at 11:23:03AM +0100, Hans Ulrich Niedermann wrote: [ Vserver guest systems are different from normal systems, and thus require special handling services for klogd and hardware access. Herbert Poetzl says "just disable the services" Hans Ulrich Niedermann says "provide dummy packages to replace the services". ] >> And for the other hardware stuff Herbert mentioned (random, rtc, >> usb)... theoretically, this vserver-guest package could pull in >> dependencies on adapted versions, or provide virtual packages which >> aren't useful on the guest system. > > hmm, yes, would be an option, but what is the problem > with simply disabling those services? > > just as an example: Mandrake has a tool called chkconfig > where you simply do > > chkconfig --del network > > and it removes all the links from the various runlevels > so that 'network' isn't started anymore ... The problem is that as soon as the next update to the "network" package happens it will re-enable the service. So you have to manually stop it and disable it (ugly, error prone, maintenance intensive) or write a hook for your packaging system to stop it (still ugly). > doing the same for klogd, while leaving syslogd untouched > would be precisely what you want here ... If I want it disabled permanently, why install it in the first place? The less obsolete stuff on the (vserver guest) system, the better. > (similar is true for all the hardware specific stuff) Exactly my point :) GruÃ, Uli pgpSH6UB0vUv7.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] alpha util-vserver patch: fix typo in $_MKTEMPDIR definition
Summary: fix typo in $_MKTEMPDIR: Use $_MKTEMP not $MKTEMP URL: http://vserver.lauft.net/util-vserver/patches--merge/util-vserver--merge--0.30.196--patch-2.patch Revision: util-vserver--merge--0.30.196--patch-2 Archive: [EMAIL PROTECTED] fix typo in $_MKTEMPDIR: Use $_MKTEMP not $MKTEMP Patches applied: * [EMAIL PROTECTED]/util-vserver--hun--0.30.196--patch-6 fix typo in $_MKTEMPDIR: Use $_MKTEMP not $MKTEMP --- orig/scripts/util-vserver-vars.pathsubst +++ mod/scripts/util-vserver-vars.pathsubst @@ -102,7 +102,7 @@ _MKDIR="@MKDIR@" _MKFIFO="@MKFIFO@" _MKTEMP="@MKTEMP@" -_MKTEMPDIR="$MKTEMP -d" +_MKTEMPDIR="$_MKTEMP -d" _MODPROBE="@MODPROBE@" _MOUNT="@MOUNT@" _MV="@MV@" ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] alpha util-vserver patch: ship generated docs in dist tarball
Summary: ship generated docs in dist tarball and use xsltproc as fallback xslt
processor
URL:
http://vserver.lauft.net/util-vserver/patches--merge/util-vserver--merge--0.30.196--patch-3.patch
Revision: util-vserver--merge--0.30.196--patch-3
Archive: [EMAIL PROTECTED]
About this patch:
* xsltp understands XSD and thus produces precise XHTML output. However,
xsltp isn't all that common (yet).
* xsltproc does not understand XSD and thus produces slightly degraded
XHTML output with respect to whitespace. But xsltproc is quite common.
* Therefore, if we are forced to resort to xsltproc because xsltp, is
not available, we warn the user but create degraded output instead of
failing completely.
* Move cleaning of generated doc/*.html files to maintainer-clean target.
Advantages:
* Produces only slightly degraded XHTML output instead of aborting.
* Building util-vserver doesn't require heavy special doc tools any more.
* Only require special doc tools when the results (html, pdf) are not
present yet. Results are shipped with dist tarball, so this will not be
the case for a majority of users.
* Makes it possible to build a Debian package with docs (graphviz and
xsltp are non-free and contrib, respectively).
Disadvantages:
* dist source tarball gets a little larger
--- orig/configure.ac
+++ mod/configure.ac
@@ -55,13 +55,35 @@
ENSC_PATHPROG(VCONFIG, vconfig)
ENSC_PATHPROG(WGET, wget)
-ENSC_PATHPROG(DOXYGEN, doxygen, [:])
-ENSC_PATHPROG(XSLTP, xsltp,[:])
-ENSC_PATHPROG(XSLTPROC, xsltproc, [:])
+AC_MSG_CHECKING([for apidoc PDF])
+if test -s "${srcdir}/lib/apidoc/libvserver-apidoc.pdf"; then
+AC_MSG_RESULT([yes, in srcdir])
+else
+AC_MSG_RESULT([no, generation required])
+ENSC_PATHPROG(DOXYGEN, doxygen, [:])
+fi
+AM_CONDITIONAL(HAVE_DOXYGEN, test -x "$DOXYGEN")
+
+
+AC_MSG_CHECKING([for XSLT output])
+if test -s "${srcdir}/doc/configuration.html"; then
+AC_MSG_RESULT([yes, in srcdir])
+else
+AC_MSG_RESULT([no, generation required])
+ENSC_PATHPROG(XSLTP, xsltp,[:])
+if test ! -x "$XSLTP"; then
+ENSC_PATHPROG(XSLTPROC, xsltproc, [:])
+ AC_MSG_WARN([*** ***])
+ AC_MSG_WARN([*** xsltp not found, using xsltproc as fallback. ***])
+AC_MSG_WARN([*** xsltproc does not support XSD, so the***])
+AC_MSG_WARN([***XSLT results will be slightly degraded. ***])
+ AC_MSG_WARN([*** ***])
+fi
+fi
+AM_CONDITIONAL(HAVE_XSLTP, test -x "$XSLTP")
+AM_CONDITIONAL(HAVE_XSLTPROC, test ! -x "$XSLTP" && test -x "$XSLTPROC")
-AM_CONDITIONAL(HAVE_XSLTP, test "$XSLTP" != ':')
-
ENSC_CHECK_CC_FLAG([-std=c99 -Wall -pedantic -W])
ENSC_CHECK_CXX_FLAG([-ansi -Wall -pedantic -W -fmessage-length=0])
--- orig/doc/Makefile-files
+++ mod/doc/Makefile-files
@@ -19,7 +19,7 @@
doc_old_doc = doc/intro.txt
-XSLT_AMFLAGS = --stringparam confdir '$(sysconfdir)/vservers'
+XSLTPROC_AMFLAGS = --stringparam confdir '$(sysconfdir)/vservers'
XSLTP_AMFLAGS =-param confdir '$(sysconfdir)/vservers'
doc_gen_DOCS = doc/configuration.html \
@@ -51,8 +51,22 @@
doc_doc: $(doc_gen_DOCS)
if HAVE_XSLTP
-CLEANFILES += $(doc_gen_DOCS)
+MAINTCLEAN_FILES = $(doc_gen_DOCS)
%.html:%.xml $(STYLESHEET)
LANG=C $(XSLTP) $(XSLTP_AMFLAGS) -in '$<' -xsl
$(STYLESHEET) -out '[EMAIL PROTECTED]'
@mv -f '[EMAIL PROTECTED]' '$@'
+else
+# Only use xsltproc as fallback, as it produces degraded output with XSD.
+if HAVE_XSLTPROC
+MAINTCLEAN_FILES = $(doc_gen_DOCS)
+%.html:%.xml $(STYLESHEET)
+ LANG=C $(XSLTPROC) $(XSLTPROC_AMFLAGS) -o
'[EMAIL PROTECTED]' $(STYLESHEET) '$<'
+ @mv -f '[EMAIL PROTECTED]' '$@'
+endif
endif
+
+maintainer-clean-doc-hook:
+ rm -f $(MAINTCLEAN_FILES)
+
+maintainer-clean-generic: maintainer-clean-doc-hook
+
--- orig/lib/apidoc/Makefile-files
+++ mod/lib/apidoc/Makefile-files
@@ -15,11 +15,20 @@
## along with this program; if not, write to the Free Software
## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-CLEANFILES += lib/apidoc/.apidoc
-EXTRA_DIST += lib/apidoc/list2xxx.syntax
+doc_api_DOC = lib/apidoc/libvserver-apidoc.pdf \
+ lib/apidoc/libvserver-apidoc.tar.gz
-doc: lib/apidoc/.apidoc
-clean-local: clean_lib_apidoc
+EXTRA_DIST += lib/apidoc/list2xxx.syntax \
+ $(doc_api_DOC)
+
+doc: $(doc_api_DOC)
+
+if HAVE_DOXYGEN
+
+CLEANFILES += lib/apidoc/.ap
[Vserver] alpha util-vserver patch: improve/fix dietlibc version detection
Summary: improve dietlibc version detection
URL:
http://vserver.lauft.net/util-vserver/patches--merge/util-vserver--merge--0.30.196--patch-4.patch
Revision: util-vserver--merge--0.30.196--patch-4
Archive: [EMAIL PROTECTED]
The changes:
* Detect and require "sort"
* Use "sort -n" instead of multiplication magic to determine whether the
dietlibc version is sufficiently new. This test should be more robust.
What they fix:
* handle a version number like 0.27-7
* handle "diet -v" output like "diet version $VERSION" in addition to
the old "dietlibc-$VERSION"
--- orig/m4/ensc_dietlibc.m4
+++ mod/m4/ensc_dietlibc.m4
@@ -72,19 +72,14 @@
if test "$use_dietlibc" = detected -a '$2'; then
_dietlibc_ver=$(${DIET:-diet} -v 2>&1 | sed '1p;d')
_dietlibc_ver=${_dietlibc_ver##*dietlibc-}
- _dietlibc_ver_maj=${_dietlibc_ver%%.*}
- _dietlibc_ver_min=${_dietlibc_ver##*.}
- _dietlibc_ver_min=${_dietlibc_ver_min%% *}
- _dietlibc_cmp=$2
- _dietlibc_cmp_maj=${_dietlibc_cmp%%.*}
- _dietlibc_cmp_min=${_dietlibc_cmp##*.}
+ _dietlibc_ver="$(echo ${_dietlibc_ver##diet version})"
+ _dietlibc_cmp="$(echo $2)"
- ensc_version_dietlibc=$_dietlibc_ver_maj.$_dietlibc_ver_min
+ ensc_version_dietlibc=$_dietlibc_ver
- let _dietlibc_ver=_dietlibc_ver_maj*1000+_dietlibc_ver_min
2>/dev/null || _dietlibc_ver=0
- let _dietlibc_cmp=_dietlibc_cmp_maj*1000+_dietlibc_cmp_min
-
- test $_dietlibc_ver -ge $_dietlibc_cmp || use_dietlibc=detected_old
+ _dietlibc_newer="$(echo -e "$_dietlibc_cmp\n$_dietlibc_ver" \
+ | sort -rn | sed '1p;d')"
+ test "$_dietlibc_newer" = "$_dietlibc_ver" ||
use_dietlibc=detected_old
else
ensc_version_dietlibc=
fi
--- orig/m4/ensc_pathprog.m4
+++ mod/m4/ensc_pathprog.m4
@@ -83,6 +83,7 @@
ENSC_PATHPROG(RMDIR, rmdir)
ENSC_PATHPROG(SED, sed)
ENSC_PATHPROG(SH,sh)
+ ENSC_PATHPROG(SORT, sort)
ENSC_PATHPROG(TAC, tac)
ENSC_PATHPROG(TAR, tar)
ENSC_PATHPROG(TOUCH, touch)
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: alpha util-vserver patch: improve/fix dietlibc version detection
Enrico Scholz <[EMAIL PROTECTED]> writes:
> Hans Ulrich Niedermann <[EMAIL PROTECTED]> writes:
>
>> The changes:
>> * Detect and require "sort"
>> * Use "sort -n" instead of multiplication magic to determine whether the
>> dietlibc version is sufficiently new. This test should be more robust.
>
> Sorry, I added some extra functionality in the meantime which was not
> submitted yet. So your patch can not be applied.
OK, so let's sort it out...
>> What they fix:
>> * handle a version number like 0.27-7
>
> Can you check if CVS ([1]) fixes your problem?
It does not.
For _dietlibc_ver_min="27-7", the line
_dietlibc_ver_min=${_dietlibc_ver_min%%[!0-9]*}
doesn't do what it is supposed to do.
>> * handle "diet -v" output like "diet version $VERSION" in addition to
>> the old "dietlibc-$VERSION"
>
> hmm... seems to be an error/incompatibility in your dietlibc. Its
> Makefile defines
>
> | VERSION=dietlibc-$(shell head -n 1 CHANGES|sed 's/://')
>
> (note the leading 'dietlibc-') which seems to be overridden by your
> distribution with 'VERSION=0.27-7'
Hmm... I'd say that VERSION=1.2.3.4 is nothing which should be
discounted in general.
GruÃ,
Uli
pgpIVQRIGAMkA.pgp
Description: PGP signature
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: alpha util-vserver patch: improve/fix dietlibc version detection
Enrico Scholz <[EMAIL PROTECTED]> writes:
> Hans Ulrich Niedermann <[EMAIL PROTECTED]> writes:
>> For _dietlibc_ver_min="27-7", the line
>>
>>_dietlibc_ver_min=${_dietlibc_ver_min%%[!0-9]*}
>>
>> doesn't do what it is supposed to do.
>
> What do you expect there?
>
> | $ _dietlibc_ver_min="27-7"
> | $ echo ${_dietlibc_ver_min%%[!0-9]*}
> | 27
>
> seems to be the correct result.
Exactly, if it is in the shell. But due to [] being the m4 quotes, you
have to write that as
dietlibc_ver_min=${_dietlibc_ver_min%%[[!0-9]]*}
in m4/ensc_dietlibc.m4.
(I have now tested to verify how it went wrong instead of just stating
it doesn't work :)
GruÃ,
Uli
pgpgULuO6GgLZ.pgp
Description: PGP signature
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Debian vserver guest
Gilles <[EMAIL PROTECTED]> writes: > I built a Debian "template" vserver with > > vserver template build -m debootstrap \ >--hostname template \ >--netdev dummy0 --interface 192.168.83.99/24 \ >--context 99 -- -d sarge > > The procedure completed fine too. But problems remains, some of which > I had mentioned a few weeks ago. > 1. Removing dispensable packages: > > pciutils fdutils ipchains makedev ppp pppconfig pppoe pppoeconf > dhcp-client console-common console-data console-tools klogd sysklogd > >[Note: klogd still triggers that cpu-hogging behaviour, which makes it >*indispensable* to remove...] I think you'd want to keep sysklogd but just remove klogd - you'll still want the software in the vserver guest to log their stuff to /var/log/something via a syslogd running within the vserver guest, right? This is something my suggestion for a (virtual) vserver-guest Debian package would have handled automatically, but the concensus was that such a package wasn't needed. Interesting to see that the problem doesn't go away by itself :-) GruÃ, Uli ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
