Re: [Vserver] packaging review for new Debian packages
* Kilian Krause ([EMAIL PROTECTED]) wrote: We'd appreciate if you could go through the TODO and help us with the open questions. 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. For the documentation- create a seperate -doc package that's arch: all, then building the documentation isn't as much of an issue. Stephen signature.asc Description: Digital 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]) 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?). |- Very likely a shared lib package should be included only once if | there is more than one binary package. | | * 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. | * There is a number of compile warnings. Some of them sound | like they should be fixed. Are they ok as can be seen at: | http://backend.verfaction.de/~kk/util-vserver/buildlog_stderr.log probably heavily depends on the used compiler ... Debian default currently would be gcc 3.3, or so. Stephen signature.asc Description: Digital 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
* Kilian Krause ([EMAIL PROTECTED]) wrote: 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 ok, we'll try to bring that to the debs. Is there a list which files should go into which of these packages? As I mentioned in the other thread- please don't. It doesn't make sense and it's really not a sane thing to do for Debian. Stephen signature.asc Description: Digital 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
* 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. | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver ??? this is standard in autoconf packages. I was wondering a bit about this myself.. The difference between /usr/lib and /var/lib is pretty clear- is there stuff in util-vserver that modifies things in the /usr/lib/util-vserver install? Or does util-vserver normally install into /var/lib/util-vserver and that's the complaint? I notice on my packaging of 0.30.195 it's in /usr/lib and I don't see anything in there that looks like having it there is wrong.. | * /etc/vserver/util-vserver-vars Please do not install 'util-vserver-vars' into /etc. There is nothing which can be changed at runtime across the entire toolset (binaries have the values statically compiled in). The file is badly named and should be called 'util-vserver-consts' instead of. I agree about the naming, and that it perhaps shouldn't even be packaged at all (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? | * Both /usr/include/ and /usr/lib/pkgconfig/ are installed by | default. What is include/vserver.h installed for?! Support for 3rd party language bindings were the main idea behind an libvserver library. Dunno, if there is much interest in such ones but I do not see reasons not to ship the -devel files. Is the API/ABI adequately supported to really allow for people to be able to develop against it and depend on it? I'm guessing 'no' considering on 0.30.195 it looks like I've got a 'libvserver.so.0.0.0'. If the API/ABI isn't handled correctly through soname and soversion changes and whatnot then they should *not* be included in Debian. If someone complains because they want to build something against them or depend on them then util-vserver will *need* to have proper API/ABI support. Personally, I hope that just doesn't happen anytime soon. :) | * It would be very convenient if upstream could ship the graphviz | output with the releases, such that building for Debian doesn't | require graphviz. How is this handled in other Debian packages with 'doxygen' support? I would like to ship only the files which are really needed to build the package. Good question, honestly I don't know the answer to this one, I've only just started looking into doxygen myself. :) | * 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.. 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... Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: Bug#287364: kernel-patch-ctx: Stable quota support and related tools ?
On Mon, Dec 27, 2004 at 12:35:45 +0100, Ola Lundqvist wrote: [...] Herbert Poetzl made a patch for latest debian sources (2.4.27), you can download it there (works fine in a production stage) : http://vallar.linuxfr.org/vserver/patch-2.4.27-3-vs1.29-q0.14.1.diff.gz Is this a complete patch or a addition to the ctx patch. Is it stable enough to replace the normal ctx patch or should I make another kbuild target? It is a complete - all in one - patch. I think you should make another kbuild target as long as related vr-tools and cq-tools aren't pakaged or else added to current debian vserver tools (vserver-utils ?). Quota patch features seems to be freeze for 2.4.X kernels. But i don't know if vserver's team call it 'stable' and then follow this post to vserver mailing list... Hope we'll do the best following recent vserver mailing list threads ;-) Best regards, Val. -- .''`. : :' : Laurent Vallar - aka Val - Network System Engineer `. `' GPG Key: 1024D/C4F38417 - http://Vallar.LinuxFR.org `- ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
Hi Enrico, | * /etc/vserver/util-vserver-vars Please do not install 'util-vserver-vars' into /etc. There is nothing which can be changed at runtime across the entire toolset (binaries have the values statically compiled in). The file is badly named and should be called 'util-vserver-consts' instead of. I don't. There's no single rule which would put it there in my packaging. Thus this is coming from the install or install-distribution targets. If i did copy the specfile wrong, i'm sorry for that. That's why i'm asking what target is to be called. Yet the option to allow a relocation of the default vserver rootdir would be highly appreciated. (and IMHO broken if not availble at all) | * util-vserver contains a large number of utilities - binaries and | shell scripts. These utilities serve different purposes and belong | to different conceptual layers. 'contrib/manifest.dat' contains the proposed grouping/subpackaging. See the %install stage of the shipped .spec file for ways how to use it. Ok, will check that. Thanks. | * Both /usr/include/ and /usr/lib/pkgconfig/ are installed by | default. What is include/vserver.h installed for?! Support for 3rd party language bindings were the main idea behind an libvserver library. Dunno, if there is much interest in such ones but I do not see reasons not to ship the -devel files. Has so far only _one_ app been coded outside the util-vserver domain? If not, i'd vote for leaving this out until someone complains. | * It would be very convenient if upstream could ship the graphviz | output with the releases, such that building for Debian doesn't | require graphviz. How is this handled in other Debian packages with 'doxygen' support? I would like to ship only the files which are really needed to build the package. I need: doxygen, tetex-bin, tetex-extras, gs, graphviz alltogether to build the doc target. And shipping only the needed to build sounds like a good idea as that IMHO involves a static doc already. | * What is recommended for packaging, running both install and | install-distribution (along with make all doc) or just make install? The 'install-distribution' target installs files outside of $(prefix). These are the /vservers directory and the /sbin/vshelper symlink. | * 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. | * There is a number of compile warnings. Some of them sound | like they should be fixed. Are they ok as can be seen at: | http://backend.verfaction.de/~kk/util-vserver/buildlog_stderr.log The only true ones are the missing strchr()/strlen() declarations and the unknown '\params' doxygen directive. First issue should be solved in CVS some time ago, latter will be fixed soon. The other warnings are caused by incomplete and currently unused code (vserver-start/*), support for the kernel 2.4 API and missing documentation. Ok, sounds fine to me. =) | # remove newvserver.defaults (because that is linuxconf and that is not | supported in debian). | rm -f $(CURDIR)/debian/util-vserver/etc/vservers/newvserver.defaults this should not be installed by 'make install*'. ok, will check that. | # New since SID for they are not standard for a Debian binary package | rm -rf $(CURDIR)/debian/util-vserver/usr/include/ | rm -rf $(CURDIR)/debian/util-vserver/usr/lib/pkgconfig/ I do not understand the reason behind this... If i'd leave in the include/vserver.h i'd need to make a libvserver-dev package. Thus not shipping no header at all is the clean solution here. And the pkgconfig isn't used on Debian, thus no need to ship it either. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
hi Stephen, Am Montag, den 27.12.2004, 08:49 -0500 schrieb Stephen Frost: * Kilian Krause ([EMAIL PROTECTED]) wrote: We'd appreciate if you could go through the TODO and help us with the open questions. Just as another (very) interested Debian developer- welcome to the troups. Feel free to testdrive my packages and comment on them or send me a patch. =) 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. copying from the specfile i have included make doc which wasn't/isn't present in the upstream deb. Thus my question here if running this is required at all or if so cannot be moved to the dist packaging. For the documentation- create a seperate -doc package that's arch: all, then building the documentation isn't as much of an issue. sure. If you have something handy like your old deb, feel free to mail me the patch or deb.. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
Hi Stephen, | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver ??? this is standard in autoconf packages. I was wondering a bit about this myself.. The difference between /usr/lib and /var/lib is pretty clear- is there stuff in util-vserver that modifies things in the /usr/lib/util-vserver install? Or does util-vserver normally install into /var/lib/util-vserver and that's the complaint? I notice on my packaging of 0.30.195 it's in /usr/lib and I don't see anything in there that looks like having it there is wrong.. Well, it does install all into /usr/lib/ instead only the libvserver* into /usr/lib/ and the scripts and addon parts into /var/lib/ where IMHO they belong. Thus setting the pkglibdir is the only solution to clean up the dir structure for now. Feel free to tell me /usr/lib/ is right and /var/lib/ needn't be used. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ 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 said: As I mentioned in the other thread- please don't. It doesn't make sense and it's really not a sane thing to do for Debian. It just makes it more complex, with no real benefit. I would reccomend keeping it the same 2 packages. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
* Kilian Krause ([EMAIL PROTECTED]) wrote: | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver ??? this is standard in autoconf packages. I was wondering a bit about this myself.. The difference between /usr/lib and /var/lib is pretty clear- is there stuff in util-vserver that modifies things in the /usr/lib/util-vserver install? Or does util-vserver normally install into /var/lib/util-vserver and that's the complaint? I notice on my packaging of 0.30.195 it's in /usr/lib and I don't see anything in there that looks like having it there is wrong.. Well, it does install all into /usr/lib/ instead only the libvserver* into /usr/lib/ and the scripts and addon parts into /var/lib/ where IMHO they belong. Thus setting the pkglibdir is the only solution to clean up the dir structure for now. Feel free to tell me /usr/lib/ is right and /var/lib/ needn't be used. Well, alright, here's how it is in my head (at least): /usr/bin for scripts/binaries expected to be used by users /usr/sbin for scripts/binaries expected to be used by superusers /usr/lib for libraries/.so files /usr/lib/util-vserver for programs/scripts *not* used by (super)users /usr/lib/util-vserver for system-depdendent static data /usr/share/util-vserver for system-independent static *data* /usr/share/doc/util-vserver for documentation /var/lib for system-dependent *variable* data I'm pretty sure this is pretty much what FHS says too, if I'm wrong about that, let me know. :) So, libvserver* into /usr/lib should be right, if libvserver should really be shipped at all. Scripts that you think a user/superuser would use should be in /usr/(s)bin. Scripts that are called by other scripts or other things in /usr/lib/util-vserver. Vserver roots should be in /var/lib/vservers, and let people create a symlink from there to wherever they'd like (exactly the same as I already do for postgres, apache, mysql and other things). Hope that helps... If there's other specific things you're wondering about I'd be happy to provide my feelings on it. :) Stephen signature.asc Description: Digital 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
On Mon, Dec 27, 2004 at 04:26:45PM +0100, Kilian Krause wrote: Hi Enrico, | * /etc/vserver/util-vserver-vars Please do not install 'util-vserver-vars' into /etc. There is nothing which can be changed at runtime across the entire toolset (binaries have the values statically compiled in). The file is badly named and should be called 'util-vserver-consts' instead of. I don't. There's no single rule which would put it there in my packaging. Thus this is coming from the install or install-distribution targets. If i did copy the specfile wrong, i'm sorry for that. That's why i'm asking what target is to be called. Yet the option to allow a relocation of the default vserver rootdir would be highly appreciated. (and IMHO broken if not availble at all) | * util-vserver contains a large number of utilities - binaries and | shell scripts. These utilities serve different purposes and belong | to different conceptual layers. 'contrib/manifest.dat' contains the proposed grouping/subpackaging. See the %install stage of the shipped .spec file for ways how to use it. Ok, will check that. Thanks. | * Both /usr/include/ and /usr/lib/pkgconfig/ are installed by | default. What is include/vserver.h installed for?! Support for 3rd party language bindings were the main idea behind an libvserver library. Dunno, if there is much interest in such ones but I do not see reasons not to ship the -devel files. Has so far only _one_ app been coded outside the util-vserver domain? If not, i'd vote for leaving this out until someone complains. hmm, well, the thing here is that we _should_ try to get folks adding/modifying stuff or adapting tools to become context/vserver aware (for administration purpose) like find, du, df, ... to use 'the' library because it will be able to cope with the various interface versions from stable vserver 1.2x up to recent devel versions 1.9.x, not to mention the syscall number and invocation which is different on almost every arch ... I agree that the library might need some adaptations first and probably also requires a documented API to be usable for 3rd party stuff ... but I guess nobody will complain if it isn't there, they just will recode or copy/paste the code from existing tools and create fragile versions which will break on the first change ... nothing anybody wants. | output with the releases, such that building for Debian doesn't | require graphviz. How is this handled in other Debian packages with 'doxygen' support? I would like to ship only the files which are really needed to build the package. I need: doxygen, tetex-bin, tetex-extras, gs, graphviz alltogether to build the doc target. And shipping only the needed to build sounds like a good idea as that IMHO involves a static doc already. in general I think that documentation should be optional so that somebody recompiling the stuff can easily do that (with all the required tools installed) or leave the doc package out, I'm personally annoyed by packages insisting to build a documentation, when all I need is a working binary (especially if they require huge addons like gs or tetex) | * What is recommended for packaging, running both install and | install-distribution (along with make all doc) or just make install? The 'install-distribution' target installs files outside of $(prefix). These are the /vservers directory and the /sbin/vshelper symlink. | * 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. any reason for 'deleting' it anyway? | * There is a number of compile warnings. Some of them sound | like they should be fixed. Are they ok as can be seen at: | http://backend.verfaction.de/~kk/util-vserver/buildlog_stderr.log The only true ones are the missing strchr()/strlen() declarations and the unknown '\params' doxygen directive. First issue should be solved in CVS some time ago, latter will be fixed soon. The other warnings are caused by incomplete and currently unused code (vserver-start/*), support for the kernel 2.4 API and missing documentation. Ok, sounds fine to me. =) | # remove newvserver.defaults (because that is linuxconf and that is not | supported in debian). | rm -f $(CURDIR)/debian/util-vserver/etc/vservers/newvserver.defaults this should not be installed by 'make install*'. ok, will check that. | # New since SID for they are not standard for a Debian binary package | rm -rf
Re: [Vserver] packaging review for new Debian packages
* Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Mon, Dec 27, 2004 at 04:26:45PM +0100, Kilian Krause wrote: Has so far only _one_ app been coded outside the util-vserver domain? If not, i'd vote for leaving this out until someone complains. hmm, well, the thing here is that we _should_ try to get folks adding/modifying stuff or adapting tools to become context/vserver aware (for administration purpose) like find, du, df, ... to use 'the' library because it will be able to cope with the various interface versions from stable vserver 1.2x up to recent devel versions 1.9.x, not to mention the syscall number and invocation which is different on almost every arch ... I agree that the library might need some adaptations first and probably also requires a documented API to be usable for 3rd party stuff ... but I guess nobody will complain if it isn't there, they just will recode or copy/paste the code from existing tools and create fragile versions which will break on the first change ... nothing anybody wants. I think the answer here is pretty simple- properly document the API and monitor the ABI and do proper SONAME/SOVER changes and we'll be glad to create -dev/-lib versions for other people to code against, even if no one uses them at first. Until that's done I think it's a very bad idea to include the headers since it would encourage people to code against it, which would have many of the same problems as if they just copied pasted the code except that they'd have good cause to be upset with us for shipping it. If i'd leave in the include/vserver.h i'd need to make a libvserver-dev package. Thus not shipping no header at all is the clean solution here. And the pkgconfig isn't used on Debian, thus no need to ship it either. the library, plus (maybe sanitized) headers are a good candidate for a devel package, which IMHO is a reasonable thing to do (see comments above) The library would be in a libvserver package if something outside of util-vserver used it. Until it's got decent API documentation and a real SONAME/SOVER that's actually monitored and updated when ABI changes are made I'm strongly against having a libvserver/-dev package in Debian. Stephen signature.asc Description: Digital 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
Hello On Mon, Dec 27, 2004 at 08:57:09AM -0500, Stephen Frost wrote: * 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?). As the current maintainer of the debian package I must say that I agree. Do not split unless there is a real need for it. As there is no lib/dev things yet it should be be split out and as there is no real huge docs yet it should not be split either. That is my packaging practice at least. :) |- Very likely a shared lib package should be included only once if | there is more than one binary package. | | * 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. Interesting. I have never heard about this issue. I have run very lot of vservers and some of them are logging servers. | * There is a number of compile warnings. Some of them sound | like they should be fixed. Are they ok as can be seen at: | http://backend.verfaction.de/~kk/util-vserver/buildlog_stderr.log probably heavily depends on the used compiler ... Debian default currently would be gcc 3.3, or so. Some arches use 3.3 and some 3.4 as far as I know. Stephen Regards, // Ola ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
[EMAIL PROTECTED] (Kilian Krause) writes: | * /etc/vserver/util-vserver-vars Please do not install 'util-vserver-vars' into /etc. ... Yet the option to allow a relocation of the default vserver rootdir would be highly appreciated. (and IMHO broken if not availble at all) The default vserver rootdir is determined by the '--with-vrootdir' configure option. But this is used at very few places only. Root-directory of existing vservers is /etc/vservers/.../vdir and the location for newly created vservers is based on /etc/vservers/.defaults/vdirbase. | * Both /usr/include/ and /usr/lib/pkgconfig/ are installed by | default. What is include/vserver.h installed for?! Support for 3rd party language bindings were the main idea behind an libvserver library. Dunno, if there is much interest in such ones but I do not see reasons not to ship the -devel files. Has so far only _one_ app been coded outside the util-vserver domain? Yes, vserver-djinni ([1]) ;) | * 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. Sorry, I do not know how to change this. This file is added by automake to the $(CONFIG_CLEAN_FILES). After automake.info, I am doing the right thing: | * If `configure' built it, then `distclean' should delete it. Enrico Footnotes: [1] http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/files/ ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Razor problems with the mailinglist (was: Listserver trouble)
On Thu, 2004-12-23 at 23:40, Thorsten Gunkel wrote: Hi *, hi list-maintainer, can anyone confirm that messages from this list are untruly reported as spam to razor[1] by some subscribers? The mailinglist is not using razor or anything like that. On the listserver we use RBL, spamassassin (w/o razor or alike) and a whitelisting (TMDA alike) feature to keep spam away from the list. If subscribers of the list report the list as spam there is not much I would be able to do against that. To quote the message I'm just replying to (this header has been added by spamassassin): , | X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, | RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,RCVD_BY_IP autolearn=no | version=3.0.1 ` If this is true and if your mailserver drops/rejects/sorts mails tagged by razor you'll miss mails from this list. No, razor is not used on the server. Slán leat, Martin List-Petersen Listmaster ___ 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
[EMAIL PROTECTED] (Stephen Frost) writes: | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver ??? this is standard in autoconf packages. I was wondering a bit about this myself.. The difference between /usr/lib and /var/lib is pretty clear- is there stuff in util-vserver that modifies things in the /usr/lib/util-vserver install? No, everything under /usr/lib/util-vserver is touched by 'make *install' only. Neither a tool, nor the administrator should change something there. | * /etc/vserver/util-vserver-vars Please do not install 'util-vserver-vars' into /etc. There is nothing which can be changed at runtime across the entire toolset (binaries have the values statically compiled in). The file is badly named and should be called 'util-vserver-consts' instead of. I agree about the naming, Chances are high that its naming and function was inspired by INNs 'innshellvars' file. ;) 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. (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) * you can configure tools with special paths at ./configure time * execve(2) is more efficiently than execvp(3) | * Both /usr/include/ and /usr/lib/pkgconfig/ are installed by | default. What is include/vserver.h installed for?! Support for 3rd party language bindings were the main idea behind an libvserver library. Dunno, if there is much interest in such ones but I do not see reasons not to ship the -devel files. Is the API/ABI adequately supported to really allow for people to be able to develop against it and depend on it? I'm guessing 'no' considering on 0.30.195 it looks like I've got a 'libvserver.so.0.0.0'. If the API/ABI isn't handled correctly through soname and soversion changes and whatnot then they should *not* be included in Debian. Ok, as long as the tools are labeled 'alpha' I do not intend to introduce so-naming. | * 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.. No, it must be shipped. Else 'rpmbuild -ta util-vserver...tar.bz2' would not work anymore. Enrico ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
[EMAIL PROTECTED] (Herbert Poetzl) writes: As there is some discussion about the package-count let me explain the background of the packaging: |- How should the packaging devide up the groups most conveniently? util-vserver-core-0.30.196 Contains low-level utilities which use the linux-vserver kernel API directly. Most of them do not know util-vserver's idea of vservers (cfg-directory + chroot) at all. This package is very lightweighted and has nearly no dependencies so that it can be used in guest-systems also. util-vserver-0.30.196 This is used to operate existing vservers (starting/stopping). It uses my idea about vservers and has moderate dependencies. util-vserver-lib-0.30.196 Shared libraries; should be self-explaining util-vserver-devel-0.30.196 devel-files; adds a dependency on pkgconfig util-vserver-sysv-0.30.196 SysV initscripts; because: * I do not like SysV init * they introduce additional, ugly dependencies (the 'initscripts' package on Fedora) they are packaged separately. util-vserver-build-0.30.196 This contains tools about the creation of vservers. It has complicated dependencies (rpm, apt-get) which might be unwanted. util-vserver-legacy-0.30.196 The legacy-tools... Enrico ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
Hi Enrico, Am Montag, den 27.12.2004, 23:02 +0100 schrieb Enrico Scholz: [EMAIL PROTECTED] (Kilian Krause) writes: | * /etc/vserver/util-vserver-vars Please do not install 'util-vserver-vars' into /etc. ... Yet the option to allow a relocation of the default vserver rootdir would be highly appreciated. (and IMHO broken if not availble at all) The default vserver rootdir is determined by the '--with-vrootdir' configure option. But this is used at very few places only. Root-directory of existing vservers is /etc/vservers/.../vdir and the location for newly created vservers is based on /etc/vservers/.defaults/vdirbase. thanks for the pointer. Sounds like a good start to a README.Debian way of explaining things. yet somewhat using a .defaults here might call for using a symlink to /etc/default/util-vserver here. Objections? -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
* Enrico Scholz ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] (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*? * 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. 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 signature.asc Description: Digital 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
* Kilian Krause ([EMAIL PROTECTED]) wrote: Am Montag, den 27.12.2004, 23:02 +0100 schrieb Enrico Scholz: Root-directory of existing vservers is /etc/vservers/.../vdir and the location for newly created vservers is based on /etc/vservers/.defaults/vdirbase. thanks for the pointer. Sounds like a good start to a README.Debian way of explaining things. yet somewhat using a .defaults here might call for using a symlink to /etc/default/util-vserver here. Objections? Not sure that makes sense in this case.. I really don't like have a '.defaults' directory under /etc. The only other .files in /etc on this particular system are in /etc/skel and /etc/cron.*. /etc/skel because it's got .bash_profile and .bashrc, and /etc/cron.* so that dpkg doesn't remove them (which, arguably, is really a bug in something that should be fixed). Stephen signature.asc Description: Digital 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
* Hans Ulrich Niedermann ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: 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. Alright, then maybe a -legacy or some such package, or just a really stern warning at the start of all the -legacy stuff saying this is legacy, you shouldn't be using it, or just don't distribute it at all (my personal favorite). 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. Well, syslog-ng, at least, works just fine in that role. Of course, if the kernel is changed to provide a link that's just empty then anything will work. So, I don't think util-vserver needs to or should care about it. Stephen signature.asc Description: Digital 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
On Mon, Dec 27, 2004 at 08:16:54PM -0500, Stephen Frost wrote:
* Enrico Scholz ([EMAIL PROTECTED]) wrote:
[EMAIL PROTECTED] (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,
PATH=/sbin:/usr/sbin:/bin:/usr/bin,
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
best,
Herbert
___
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] packaging review for new Debian packages
* Herbert Poetzl ([EMAIL PROTECTED]) wrote:
On Mon, Dec 27, 2004 at 08:16:54PM -0500, Stephen Frost wrote:
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,
PATH=/sbin:/usr/sbin:/bin:/usr/bin,
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);
Ah, interesting... That means anything that's needed by vshelper that's
not in those paths on most systems is a candidate for being hard-coded.
Does much fall into this category? Another option would be to have
vshelper read a config file which specifies it's path, I kind of like
that, personally. Is vshelper called much by the kernel?
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 ...
I'm all for that... :) I'd really like to see a 'stable' release of
vserver.
Stephen
signature.asc
Description: Digital 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]) wrote: On Mon, Dec 27, 2004 at 08:28:45PM -0500, Stephen Frost wrote: Alright, then maybe a -legacy or some such package, or just a really stern warning at the start of all the -legacy stuff saying this is legacy, you shouldn't be using it, or just don't distribute it at all (my personal favorite). the thing is, many people have existing 2.4 vservers and want to see 'some' migration path, and telling them sorry, you are out of luck isn't the way we want to go there ... so the legacy stuff _is_ important ... having a separate package (as with rpm, see my list) is a good idea IMHO, because it allows to remove those tools once the legacy vservers have been converted Perhaps, I just don't like releasing legacy tools. How difficult is it to move to the new tools? Are the 'new' vservers the 2.6 ones, and the 'old' vservers the 2.4 ones, or can you have 'new' 2.4 vservers? Well, syslog-ng, at least, works just fine in that role. Of course, if the kernel is changed to provide a link that's just empty then anything will work. So, I don't think util-vserver needs to or should care about it. IMHO it would be a natural thing to _not_ mix syslogd and klogd into the same script/package, because they _are_ very different in purpose and functionality ... 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... one is directly talking to the kernel and receiving system wide (read host) information, while the other is a pure userspace daemon receiving just userspace messages ... Sure, and they're seperate packages under Debian, just both installed by default and some things depend on a linux-kernel-logger or whatever, iirc. so I really wonder why both ended up in the same script on most distros ... Because they used to be distributed together... They're no longer in the same init script or package on Debian. if this is the case in debian too (I read various diversive statements about that in irc and this ml) then this should be fixed in the distro (but I'm realistic enough that this will not happen soon if at all, so we might do another hack, like we do for the broken bind) Perhaps in Debian/stable they're still as sysklogd but in Debian/unstable (which is what we're talking about here anyway- Debian/stable isn't going to change, if it even has util-vserver?) they're definitely seperate packages now. Stephen signature.asc Description: Digital 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]) wrote: On Mon, Dec 27, 2004 at 08:38:10PM -0500, Stephen Frost wrote: Ah, interesting... That means anything that's needed by vshelper that's not in those paths on most systems is a candidate for being hard-coded. Does much fall into this category? Another option would be to have vshelper read a config file which specifies it's path, I kind of like that, personally. Is vshelper called much by the kernel? currently no, just on reboot/reset/halt and in near future on context creation and destruction, but it might become used more often if we decide to route kernel fs requests through it (e.g. proc) ... hrmmm, why does that sound like a bad idea to me? But then, I don't really know what the purpose of vshelper was anyway and why it's not done in the kernel already. Seems like it'd be a rather slow way to access /proc stuff, which is rather concerning, and if you did all I/O through it you'd end up with UML-like speeds I'd think. ;) testing util-vserver (alpha) and reporting back to enrico (regarding stability and or improvements) will probably help there ... I'll be setting up a bunch more vservers soon, I'll be sure to provide all kinds of comments about how that goes. ;) Stephen signature.asc Description: Digital 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
On Mon, Dec 27, 2004 at 08:48:43PM -0500, Stephen Frost wrote: * Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Mon, Dec 27, 2004 at 08:28:45PM -0500, Stephen Frost wrote: Alright, then maybe a -legacy or some such package, or just a really stern warning at the start of all the -legacy stuff saying this is legacy, you shouldn't be using it, or just don't distribute it at all (my personal favorite). the thing is, many people have existing 2.4 vservers and want to see 'some' migration path, and telling them sorry, you are out of luck isn't the way we want to go there ... so the legacy stuff _is_ important ... having a separate package (as with rpm, see my list) is a good idea IMHO, because it allows to remove those tools once the legacy vservers have been converted Perhaps, I just don't like releasing legacy tools. How difficult is it to move to the new tools? Are the 'new' vservers the 2.6 ones, and the 'old' vservers the 2.4 ones, or can you have 'new' 2.4 vservers? in theory, you could have newstyle 2.4 vservers, practically you won't do that, and the missing piece is a conversion script, which takes the old config and converts it to the new style config ... this would at least provide a one way 'upgrade' to newstyle (not sure if that is better than allowing for both configs until legacy fades away ...) Well, syslog-ng, at least, works just fine in that role. Of course, if the kernel is changed to provide a link that's just empty then anything will work. So, I don't think util-vserver needs to or should care about it. IMHO it would be a natural thing to _not_ mix syslogd and klogd into the same script/package, because they _are_ very different in purpose and functionality ... 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? one is directly talking to the kernel and receiving system wide (read host) information, while the other is a pure userspace daemon receiving just userspace messages ... Sure, and they're seperate packages under Debian, just both installed by default and some things depend on a linux-kernel-logger or whatever, iirc. so I really wonder why both ended up in the same script on most distros ... Because they used to be distributed together... They're no longer in the same init script or package on Debian. if this is the case in debian too (I read various diversive statements about that in irc and this ml) then this should be fixed in the distro (but I'm realistic enough that this will not happen soon if at all, so we might do another hack, like we do for the broken bind) Perhaps in Debian/stable they're still as sysklogd but in Debian/unstable (which is what we're talking about here anyway- Debian/stable isn't going to change, if it even has util-vserver?) they're definitely seperate packages now. so I see no issue there, as I said, just unconfigure that 'hardware' related service like the others (random, rtc, usb ...) best, Herbert Stephen ___ 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] packaging review for new Debian packages
* Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Mon, Dec 27, 2004 at 08:48:43PM -0500, Stephen Frost wrote: Perhaps, I just don't like releasing legacy tools. How difficult is it to move to the new tools? Are the 'new' vservers the 2.6 ones, and the 'old' vservers the 2.4 ones, or can you have 'new' 2.4 vservers? in theory, you could have newstyle 2.4 vservers, practically you won't do that, and the missing piece is a conversion script, which takes the old config and converts it to the new style config ... this would at least provide a one way 'upgrade' to newstyle (not sure if that is better than allowing for both configs until legacy fades away ...) Well, if there's a workable upgrade script then we could run that in our post-inst and not have to ship the legacy tools. It's a thought anyway, but it's up to the Debian maintainer if he wants to expend that effort or not. 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. Stephen signature.asc Description: Digital 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
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: Perhaps, I just don't like releasing legacy tools. How difficult is it to move to the new tools? Are the 'new' vservers the 2.6 ones, and the 'old' vservers the 2.4 ones, or can you have 'new' 2.4 vservers? in theory, you could have newstyle 2.4 vservers, practically you won't do that, and the missing piece is a conversion script, which takes the old config and converts it to the new style config ... this would at least provide a one way 'upgrade' to newstyle (not sure if that is better than allowing for both configs until legacy fades away ...) Well, if there's a workable upgrade script then we could run that in our post-inst and not have to ship the legacy tools. It's a thought anyway, but it's up to the Debian maintainer if he wants to expend that effort or not. 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 ...) Stephen best, Herbert ___ 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] Re: The Future of Linux Capabilities ...
On Mon, Dec 27, 2004 at 03:22:32PM -0800, Ulrich Drepper wrote: On Mon, 27 Dec 2004 02:40:41 +0100, Herbert Poetzl [EMAIL PROTECTED] wrote: II) add 32 (or more) sub-capabilities which depend on the parent capability to be usable, and add appropriate syscalls for them. example: CAP_IPC_LOCK gets two subcapabilities (e.g. SCAP_SHM_LOCK and SCAP_MEM_LOCK) which I won't try to say anything about III, but I is not really suitable, it breaks code currently using capabilities. Or at least makes them less secure. let me assure you that III) does neither break the existing code nor reduce security, for the following reasons: a) the per process capability is a requirement for _all_ subcapabilities (when the cap is in the cap_mask) b) the capability system isn't changed for caps not in the cap_mask c) reducing a cap by removing a subcapability can only increase security not lower it With sub-capabilities the interface diverges from the POSIX capabilities interfaces, but at least one can keep backward compatibilities. to some extend, yes ... An alternative would be to keep the existing capabilities, and add new ones for all the cases which need splitting. If the old value is set/reset, all the split-out values are magically affected as well. I consider the 'magically' part another solution I didn't list in my previous mail, but it is a kind of variation from II) where we do not necessarily need subcaps for _all_ aspects of a capability (as a matter of fact it's one less) This would help keeping the interfaces in line with POSIX and no additions to the userlevel libcap would be needed. Yes, new cap[gs]et syscalls would be needed, but this fact is hidden from the user. I guess it might be doable, although the 'magically' part would require to keep masks for all caps which got split to select the corresponding sub-capabilities ... thanks, Herbert - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
[EMAIL PROTECTED] (Stephen Frost) writes: Alright, then maybe a -legacy or some such package, or just a really stern warning at the start of all the -legacy stuff saying this is legacy, you shouldn't be using it, or just don't distribute it at all (my personal favorite). the thing is, many people have existing 2.4 vservers and want to see 'some' migration path, and telling them sorry, you are out of luck isn't the way we want to go there ... so the legacy stuff _is_ important ... ... Perhaps, I just don't like releasing legacy tools. How difficult is it to move to the new tools? Are the 'new' vservers the 2.6 ones, and the 'old' vservers the 2.4 ones, or can you have 'new' 2.4 vservers? My production vservers have only the new style on 2.4 kernels, and (at least on my side) the alpha utils are more tested for 2.4 than for 2.6. But expressing a formal migration path from old style is difficultly. It is more than converting the configuration-file: * as the init-script handling is more strict in 'alpha' tools, you have to do some hacks manually (e.g. replacing /etc/init.d/halt, make sure that /etc/rc.d/rc.sysconfig succeeds, disable some init-scripts) * you will have to convert the old, human-written vserver.sh script. Filesystem-mounting (a common task there) is now done natively. * perhaps not an issue for Debian, but the old 'vrpm' does not work anymore: this method corresponds to the new external package-management which requires lot of additional configuration data. I tried to keep some vservers with the old style where I could test migration methods with. But unfortunately, the harddisk died and I created them from scratch with the new method ;) Enrico ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] packaging review for new Debian packages
[EMAIL PROTECTED] (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? Yes; e.g. ,--- pathconfig.h.pathsubst --- | #define MOUNT_PROG@MOUNT@ ,--- src/secure-mount.c --- | if (mount_prog==0) mount_prog = MOUNT_PROG; | ... | execv(mount_prog, const_cast(char **)(argv)); Or | $ strings /usr/lib/libvserver.so | ... | /vservers/.pkg | /etc/vservers/.defaults/run.rev I'm thinking it might go in /usr/share/util-vserver then, since it's not system-dependent it is system-dependent; e.g. on i386 it has | PKGLIBDIR='/usr/lib/util-vserver' x86_64 would have | PKGLIBDIR='/usr/lib64/util-vserver' and isn't configurable. The other option would be /usr/lib/util-vserver, either would be fine with me. it is expected in /usr/lib/util-vserver by default. * 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 using execvp(3) would mean: * trusting in $PATH that it contains the wanted path (this has to deal with packaging philosophies also which expect all 3rd party apps under /opt/name) -- /etc/profile.d/* et.al. must be executed before everything else * trusting in $PATH that it contains not too much (e.g. no '.'); we are operating in hostile environments (guest-servers) -- sanity checks for $PATH are required * iterating over all elements of $PATH and try execve() there With execve(2) you do not have these problems and both coding and runtime-executing is more efficiently. I do not see an advantage in guessing paths with execvp(3) over and over again, when they can be determined at buildtime. [ ... util-vserver.spec ...] 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? I will think about this; but I still do not understand the problem there. Enrico ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Sys V IPC tracking
Hi all, Merry XMas - Is there a simpler way to track IPC resources short of entering every context and running ipcs? It seems that context 1 can only see its own semaphores/locks/etc, wouldn't it make more sense if it saw all of them? vs1.9.3 Thanks! Grisha ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
