Re: [Vserver] packaging review for new Debian packages
* Kilian Krause ([EMAIL PROTECTED]) wrote: well, it doesn't forcibly re-activate them. Just update-rc.d has a logic that when *NONE* of the runlevels has any symlink for either S??$SERVICENAME or K??$SERVICENAME then it'll try to create them for it's thinking it's being installed for the first time. That does remove overhead for a more special configuration of first and update install. So the clean fix is to remove all but one symlink (which will be a K99 or so) to have this made working. Or just put 'exit 0' at the top of /etc/init.d/klogd, or whatever. In my idea the guest-vserver virtual package could/should provide as many services as we need to be available, but not original daemons and then offer a debconf dialog to the user querying about all the other daemons to be shut off. Poking around /etc/rc*.d/[SK]* symlinks is valid from debconf as far as i know the policy in case you do that upon user request. Of course altering any symlinks except for our own without asking or even telling the user is out of the limits we should be staying within. I really don't think we need a guest-vserver package. I'd rather vserver provide empty hooks for the things needed in a 'normal' system, but otherwise just let the admin take care of it. ...which would be a nice task for a vserver-guest virtual package including a fancy postinst script. I don't like fancy postinst scripts. :) 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
Hi Enrico, Am Dienstag, den 28.12.2004, 03:49 +0100 schrieb Enrico Scholz: [ ... 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. very easy to tell. You're talking about what configure builds, make clean purges yet you're rolling the release tarball with a *.spec already. Thus it's not configure building it, but autogen.sh at dist stage. So the make clean shouldn't purge it, but going back into mrproper mode should. Maybe someone can tell me if distclean is supposed to clean this and doing a make clean would be the appropriate fix here? (Not technically, but stylistic in general terms of automake/autoconf etc.) I know for now i use distclean to revert all built objects and tempfiles into the release state and if clean is sufficient, then that might be the answer to that question. -- 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 Herbert, Am Mittwoch, den 29.12.2004, 00:01 +0100 schrieb Herbert Poetzl: 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). wait you are saying that your distro re-enables disabled services when they get updated? sounds like a bug to me, I would not want a distro to decide which services I run, just consider the security impact, when I disable telnet and the distro decides to re-enable it 'just' because a new telnet package was available ... well, it doesn't forcibly re-activate them. Just update-rc.d has a logic that when *NONE* of the runlevels has any symlink for either S??$SERVICENAME or K??$SERVICENAME then it'll try to create them for it's thinking it's being installed for the first time. That does remove overhead for a more special configuration of first and update install. So the clean fix is to remove all but one symlink (which will be a K99 or so) to have this made working. In my idea the guest-vserver virtual package could/should provide as many services as we need to be available, but not original daemons and then offer a debconf dialog to the user querying about all the other daemons to be shut off. Poking around /etc/rc*.d/[SK]* symlinks is valid from debconf as far as i know the policy in case you do that upon user request. Of course altering any symlinks except for our own without asking or even telling the user is out of the limits we should be staying within. I do not think that any serious distro will do that ... so I guess it is 'safe' to disable those services right after guest installation ... ...which would be a nice task for a vserver-guest virtual package including a fancy postinst script. -- 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
[EMAIL PROTECTED] (Kilian Krause) writes: [ ... util-vserver.spec ...] 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. very easy to tell. You're talking about what configure builds, make clean purges yet you're rolling the release tarball with a *.spec already. Thus it's not configure building it, but autogen.sh at dist stage. So the make clean shouldn't purge it, but going back into mrproper mode should. Sorry, I am out of sync now... util-vserver has neither an 'autogen.sh' script nor a 'mrproper' make-target. The clearify things: * 'util-vserver.spec' is *not* removed by 'make clean' * 'util-vserver.spec' *is* removed by 'make distclean'; this clean rule is generated automatically by automake * 'util-vserver.spec' *is* generated by './configure', './config.status' and (at least) 'make dist' * 'util-vserver.spec' is *not* generated by automake, autoconf, aclocal, autoheader or libtoolize And I still do not see the problem: it is common practice to build a '.spec' file from a '.spec.in' file and to ship it in the tarball. E.g. most Gnome packages have the behavior above; how is Debian packaging done there? 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
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
Re: [Vserver] packaging review for new Debian packages
* Enrico Scholz ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] (Stephen Frost) writes: So, it's used by scripts *and* is compiled into programs? Yes; e.g. I believed you, I just find it kind of ugly. :) 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 ehh, alright, the example you gave isn't actually how it works out on Debian currently (amd64 is pure64, which means /usr/lib and no lib64) but perhaps there's other things, it's not a big deal, /usr/lib/util-vserver is fine too. * 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. Alright, you've jumped from a performance issue to being concerned about security. So, let's talk about security then- Who's going to run the programs? Are any of them setuid? What if the root user is running it and *wants* . in his path for some testing work? If a hostile person has root access in the guest server, what if they just replaced the binaries themselves? Or created an alias/function in root's .profile? Should a root user in a guest server even be able to change context anyway? Lack of the binaries wouldn't stop someone who has root in a vserver from being able to download the appropriate binaries and if that allowed them to break out of the vserver there'd be a more serious problem here I'd think. I do not see an advantage in guessing paths with execvp(3) over and over again, when they can be determined at buildtime. The problem is that you're not building on every box out there- you're building on one box and then shipping binary files which can't be changed very easily. Therefore, being flexible is generally preferred, especially when you're talking about paths to other programs which the admin may want to install his own utilities for, for whatever reason. 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 09:05:21PM -0500, Stephen Frost wrote: 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) ... Err, I was talking about in the guest... 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 ...) From a user's perspective, I tend to agree.. I think what was being discussed was the possibility of having a package which would take care of disabling klogd, or just having a fake package to satisfy the linux-kernel-logger or whatever dependency. By doing that you could set up a list of packages to install which wouldn't require such additional guest-system configuration. 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: 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. Yeah.. Honestly, I'd rather see the vserver patch 'fake out' this stuff instead of having a bunch of special packages be required in the guest. If nothing else, it makes it that much more obvious that it's a vserver guest and that there's a master server somewhere which someone might be interested in trying to bust into... 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
[EMAIL PROTECTED] (Stephen Frost) writes: [... absolute paths vs. resolution with $PATH ...] 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. Alright, you've jumped from a performance issue to being concerned about security. So, let's talk about security then- Who's going to run the programs? Are any of them setuid? rebooting with 'vshelper' might have a setuid-like effect... What if the root user is running it and *wants* . in his path for some testing work? Having '.' in $PATH results in undefined behavior when non-absolute programnames are used. I do not want undefined behavior... If a hostile person has root access in the guest server, what if they just replaced the binaries themselves? One problem is: | $ vserver foo start | ... | cd /vservers/foo/... | mount /blahblub '.' When root has still '.' in $PATH (which was set e.g. for the testing work above), you could give root-access for the host-system to the guest-admin also... When executing | /bin/mount /blahblub '.' things are ok. Or created an alias/function in root's .profile? ... util-vserver should/must not use anything in the guest-system. Using absolute paths is part of the strategy to avoid this. I do not see an advantage in guessing paths with execvp(3) over and over again, when they can be determined at buildtime. The problem is that you're not building on every box out there- you're building on one box and then shipping binary files which can't be changed very easily. 1. I do not ship binaries 2. I do not believe into the one-binary-for-all-distributions concept It is free software; everybody can recompile it in his/her environement or use packages for the used environment/distribution. 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
On Tue, Dec 28, 2004 at 05:23:18PM +0100, Enrico Scholz wrote: [EMAIL PROTECTED] (Stephen Frost) writes: [... absolute paths vs. resolution with $PATH ...] 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. Alright, you've jumped from a performance issue to being concerned about security. So, let's talk about security then- Who's going to run the programs? Are any of them setuid? rebooting with 'vshelper' might have a setuid-like effect... What if the root user is running it and *wants* . in his path for some testing work? Having '.' in $PATH results in undefined behavior when non-absolute programnames are used. I do not want undefined behavior... to clarify, there are actually three modes in the current linux-vserver setup/solution: a) you are on the host system b) you are inside the vserver (e.g. with ssh) c) you are basically on the host system but half way inside the vserver (doing stuff like starting services, etc) where a) and b) is of no concern regarding pathes or permissions, but c) is a big deal if you call the wrong (i.e. malign) binary ... If a hostile person has root access in the guest server, what if they just replaced the binaries themselves? One problem is: | $ vserver foo start | ... | cd /vservers/foo/... | mount /blahblub '.' When root has still '.' in $PATH (which was set e.g. for the testing work above), you could give root-access for the host-system to the guest-admin also... When executing | /bin/mount /blahblub '.' things are ok. Or created an alias/function in root's .profile? ... util-vserver should/must not use anything in the guest-system. Using absolute paths is part of the strategy to avoid this. yes, and unless we 'decide' not to allow to manage the vserver from the host system, this will stay an important issue, if we decide (on public demand, which I doubt) that access to the vserver from the host system is not allowed, we can loosen the rules there without reducing the security ... I do not see an advantage in guessing paths with execvp(3) over and over again, when they can be determined at buildtime. The problem is that you're not building on every box out there- you're building on one box and then shipping binary files which can't be changed very easily. 1. I do not ship binaries I totally agree with that philosophy, we do not do binary kernels either ... 2. I do not believe into the one-binary-for-all-distributions concept It is free software; everybody can recompile it in his/her environement or use packages for the used environment/distribution. best, Herbert Enrico ___ 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
On Tue, Dec 28, 2004 at 11:23:03AM +0100, Hans Ulrich Niedermann wrote: 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. 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 ... doing the same for klogd, while leaving syslogd untouched would be precisely what you want here ... (similar is true for all the hardware specific stuff) best, Herbert Gruß, Uli ___ 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] 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
Re: [Vserver] packaging review for new Debian packages
On Tue, Dec 28, 2004 at 08:08:34PM +0100, Hans Ulrich Niedermann wrote: 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). wait you are saying that your distro re-enables disabled services when they get updated? sounds like a bug to me, I would not want a distro to decide which services I run, just consider the security impact, when I disable telnet and the distro decides to re-enable it 'just' because a new telnet package was available ... I do not think that any serious distro will do that ... so I guess it is 'safe' to disable those services right after guest installation ... 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. sure, nothing against a streamlined guest distro I do that myself for my linux-vserver guests, but there are other folks out there which _want_ to use a guest as close as it can be to default install and hey, if they want all those packages lying around I'm not going to stop them ... (similar is true for all the hardware specific stuff) Exactly my point :) ah, good, we agree here *G* Gruß, Uli 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
* 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
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] 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
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] packaging review for new Debian packages
Hi Enrico, Hans Ulrich Niedermann and me have started reviewing the debian package and put up some agenda we think should be clarified to ease packaging (not only on Debian). The TODO file with our questions can be found at http://backend.verfaction.de/~kk/util-vserver/TODO alongside with preliminary alpha debs which can be used with deb http://backend.verfaction.de/~kk/util-vserver/ ./ in sources.list.. Comments and feedback are welcome. We'd appreciate if you could go through the TODO and help us with the open questions. The linda and lintian reports plus the build log are also in that directory. -- 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
On Mon, Dec 27, 2004 at 02:36:24AM +0100, Kilian Krause wrote: Hi Enrico, Hans Ulrich Niedermann and me have started reviewing the debian package and put up some agenda we think should be clarified to ease packaging (not only on Debian). The TODO file with our questions can be found at http://backend.verfaction.de/~kk/util-vserver/TODO alongside with preliminary alpha debs which can be used with deb http://backend.verfaction.de/~kk/util-vserver/ ./ in sources.list.. Comments and feedback are welcome. okay, here the list, so that I can comment ... --- | * A lot of programs don't have documentation. Add man pages in DocBook? | - chxid | - exec-cd | - lsxid | - setattr | - showattr | - vapt-get | - vattribute | - vcontext | - vdu | - vfiles | - vkill | - vlimit | - vnamespace | - vrpm | - vrsetup | - vsched | - vserver-info | - vshelper | - vuname | | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver | | * /etc/vserver/util-vserver-vars VROOTDIR doesn't affect | DEFAULT_VSERVERDIR='/var/lib/vservers' | DEFAULT_VSERVERPKGDIR='/var/lib/vservers/.pkg' | | * util-vserver contains a large number of utilities - binaries and | shell scripts. These utilities serve different purposes and belong | to different conceptual layers. | | It appears there is or may be: | | a) Stuff for basic administration. |Command line interfaces to the vserver syscalls and the like. yes, they are part of the lib and core packages (on rpm based systems) | b) Higher-level stuff. | |I) Used only on host systems. | Like rebootmgr, vserver start and stop scripts, etc. rebootmanager is obsoleted since a long time (it was replaced by vshelper) |II) Used only on guest systems. | Is there something like this? not that I know of ... at least not in recent systems |III) Used on both host and guest systems. | Is there something like this? lsxid? chxid? not that I know of either ... |- Which are the binaries for each group and have we listed all | groups? |- 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 |- 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) | * Both /usr/include/ and /usr/lib/pkgconfig/ are installed by | default. What is include/vserver.h installed for?! | Do we need a -dev package? | | * Is the api documentation to be split into a separate -doc package? | | * Repeatedly calling rebootmgr start starts multiple processes. | This is bad. as I said, rebootmgr is obsoleted, don't use it don't package it, just let it die in peace ... | * Is there up-to-date documentation for /etc/vservers/NAME/* ? included as xml file in the source of util-vserver | * It would be very convenient if upstream could ship the graphviz | output with the releases, such that building for Debian doesn't | require graphviz. (graphviz is marked non-free in Debian and thus | would force util-vserver from main into contrib). Pre-building the | graphviz output in the (maintainer-mode?) dist-target should be easy | enough not not allow this to happen. | | Is it necessary for the entire doc target to be rebuilt at | packaging time? If this could be moved to the dist target as well, | that would speed up the packaging even more. | | * What is recommended for packaging, running both install and | install-distribution (along with make all doc) or just make install? | | * The distclean target does also remove util-vserver.spec which is | shipped in the release tarball. | Perhaps make distcheck and the resulting cleanups would help. | | * 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 ... | * The current Debian package removes the following files before | packaging, which upstream's make install install-distribution | installs: | | rm -f $(CURDIR)/debian/util-vserver/usr/lib/*.la | # have to remove v_ init
Re: [Vserver] packaging review for new Debian packages
Re, -(snip)- rebootmanager is obsoleted since a long time (it was replaced by vshelper) ok, fine. yet the make install or make install-distribution does still yield it. That's nothing i would copy within the debian/rules. |- 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 ok, we'll try to bring that to the debs. Is there a list which files should go into which of these packages? | * 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) is already the case for debian. the linux-kernel-log-daemon is the virtual package for a klogd (as opposed to sysklogd | system-log-daemon) | * Repeatedly calling rebootmgr start starts multiple processes. | This is bad. as I said, rebootmgr is obsoleted, don't use it don't package it, just let it die in peace ... It's not that we'd have requested it. The alpha tools still ship it. =) The list of files contained in the package can be found in the lower part of: http://backend.verfaction.de/~kk/util-vserver/util-vserver_0.30.196.build where it reads chroot-unstable/build/wanna-build/util-vserver_0.30.196-1_i386.deb:... | * Is there a script to convert existing chroots into vservers yet? If | not, what's the closest we can get to write one from the newvserver | lower half? newvserver is not part of the utils IIRC, but basically you can take a chroot as it is, add the appropriate config, move it in place (or not) and start any application within a context ... which is why i had quoted it like newserver for i know it's no longer current. The idea was though to just create a vserver config file in /etc/vserver/ and all else it takes to make it vserver-bootable from a given chroot without moving it around. Like running the skeleton installer upon a given chroot dir which is then probed for the needed binaries/scripts. (so far the idea *g*) -- 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
