[Vserver] linux-2.6.12 and latest patch?
Hi guys, i was just about to try new VS2.00 and found the latest available patch (against 2.6.11.11) not applying cleanly to 2.6.12... Is there one in the make for 2.6.12 now it's out? ;) Thanks! -- Best regards, Kilian signature.asc Description: This is a digitally signed message part ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Debian vserver guest
Hi Gilles, i'll comment to this email rather than the one which does only refer to this list :-P Yes, util-vserver 0.30.204 is in SID now and it should be offering a transition-path according to the changelog. See the 0.30.203 uploads at http://packages.qa.debian.org/u/util-vserver.html for the detailled wording. I daresay i haven't challenged it as i don't have any old-style vservers around. But whoever has a sarge could bootstrap that old config-style and then upgrade to the SID version and report back success/problems. Ideally, the template should be with the minimum functionality, with everything that's necessary (to make it comfortable to install the server applications) and nothing that comes in the way of vserver (i.e. all hardware- and kernel-related packages). well, *where* i'd prefer this to be put is cdebootstrap. It's quite easy to select a flavour like build already. Thus adding a skeleton or a vserver flavour should be quite feasible. As debootstrap's options are directly accessible through the commandline, that's quite accessible already, yet the (c)debootstrap don't offer a vserver profile yet, only the buildd profile. Moreover, with cdebootstrap replacing debootstrap we should seriously move forward to it and ask cdebootstrap's upstream to include some flavour for this - in case you need more than the standard flavour which is already in. So here is a list of steps that could be added to the vserver build script to come closer to such a ready-to-use vserver environment: 1. Removing dispensable packages: pciutils fdutils ipchains makedev ppp pppconfig pppoe pppoeconf dhcp-client console-common console-data console-tools klogd sysklogd [Note: klogd still triggers that cpu-hogging behaviour, which makes it *indispensable* to remove...] Others? well, for now i prefer doing a cdebootstrap -f build ... which brings me somewhat closer to what i want, objections? the above list is missing, however the sysklogd should be included into the vserver flavour for sure. Plus the build flavour doesn't boostrap a working set of /dev entries. Having a /dev/null, /dev/random and /dev/urandom however is quite essential for a working vserver. This would then need to go into the new profile aswell. 2. Installing indispensable packages: less ssh Others? vim ;) 3. Prepare for package installation: (a) Copy the contents of the host's /etc/apt/sources.list (b) Run apt-get update apart from sources.list a resolv.conf is needed to get a working networking setup. 4. Network interfaces (a) In the /etc/init.d/reboot script: Remove the -i option (to avoid the guest trying to deconfigure the network interfaces upon halting). i guess this should be an option in /etc/default/reboot or so. Have you tried rasing this against the package in Debian? Having the util-vserver package bring forth an alternative /etc/init.d/reboot is probably not an option. (b) Remove spurious links to scripts that will try to configure the interfaces: update-rc.d -f ifupdown remove update-rc.d -f ifupdown-clean remove update-rc.d -f networking remove 5. ... [Not yet finished.] when building from the build flavour we also need to put a proper /dev setup and move start-stop-daemon.REAL into place. Moreover you must not boostrap into an existing mountpoint with util-vserver, i.e. you can only boostrap into a subdir of a partition not into the mountpoint itself. I kinda dislike that, but apparently Enrico thinks it's neccessary as even the --force doesn't yield me a chance to overcome this. Some more questions: (a) Should I remove the mount package (to suppress any attempt by the vserver guest to try such things)? [The Debian package management issues a strong warning when uninstalling it (package is essential).] Or should I only remove the symlinks as for the networking scripts? I'd rather go for the not running it rather than removing any chance of even trying. At least if this could be working for some vserver client setup. (d) The file /etc/hostname, inside the vserver, contains the host's name instead of the guest name. Is it supposed to be so? [uname -n provides the right name.] uname does also report the kernel arch rather than the userland arch (in case x86_64 and i386 differ). At least for the latter Herbert just needs a box to test this. What I kinda would love to see is dchroot support with vserver. Going through sudo with vserver suexec is kinda long way to type and setup. Having a dchroot context-enabled would be a very handy thing for especially developer build environments IMHO. -- 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] Debian vserver guest
Hi Gilles, [Until we have a plug-n-play debian package with the latest version of vserver patch and tools,] I'm again trying to configure Debian vservers on Debian from source. what's wrong with the one from experimental? like http://ftp.de.debian.org/debian/pool/main/u/util-vserver/util-vserver_0.30.203-1_i386.deb It's in official Debian already, just not 204 but 203. -- 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] Patching kernel-source-2.6.10 (Debian)
Hi Helmut, Solutions can be: - the Debian maintainer finds a way to keep in track he is. - some advanced users provide patches or .debs outside of Debian there are packages that WorkForMe(TM) and i have long standing offered to hand them to everybody interested on this list. Moreover Ola is having access to the SVN where they came from and should thus not have any problem moving whatever he likes from there into experimental. You see it's not about technical limitations, it's politics. And I daresay that even though I don't agree from a personal point on keeping 1.9x out of Debian, he's very helpful and positive about packaing the new alpha tools. The only problem, which may or may not be fixed in the meantime, was the lack of a 32bit-kernel API for x86_64 CPUs with 32bit userland. That was however an upstream problem. Apart from that they do work just nicely for me (yet not as intuitively as i sometimes wish, but that's another upstream issue which was also addressed as part of the alpha-packaging). -- 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] unable to start server with quota's enabled
Hi Lucas, 1.)I cannot find the lsxid command for debian, even after doing a google for it. they are part of the alpha tools. Currently there's no official Debian package for those utils but only for the stable ones. We're working on changing that. If you want to try the alpha-util-vserver debian test package rather than poking around with sources, drop me a private note. 2.)Where can I host vserver+grsec2+tagctx kernel packages for debian? I'm not sure they are of public interest, but i think as this is now the archive, people can come to you asking for them (personally i prefer my own kernels *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
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] Vserver configuration for IPv4 and IPv6
Hi Herbert, please keep this discussion going (maybe some typical ipv6 examples or so?) so we can get a feeling for it. what kind of typical example are you asking for? The default IPv6 address style is quite forward to the ipv4 notation (well, same logic applies, but a slightly changed notation): an ipv6 address would be: 2001:abcd:ef01::1/64 where the :: is an abbreviation for fill up with all 0 here.. Thus the full length notation is: 2001:abcd:ef01:::::0001 which may be found with ipv6calc -i -m 2001:abcd:ef01::1. The /64 is the prefix length which makes the local prefix be: 2001:abcd:ef01: Length of IPv6 is 128bit in 8 blocks written in hex. Each of the blocks is 2 bytes which makes an overall of 8*16=128 bit. There's special target prefixes for site-local and link-local yet that might be rather a routing question and transparent to the vserver, but i'm not sure. Please ask for further hints if you need some. -- 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 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
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
[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
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
Re: [Vserver] new patch for 2.6.10
Hi Herbert, Am Samstag, den 25.12.2004, 19:42 +0100 schrieb Herbert Poetzl: On Sat, Dec 25, 2004 at 05:09:30PM +0100, Kilian Krause wrote: Hi, am i plain blind or is the last 2.6.10 patch for rc3? I've just tried to apply on a vanilla 2.6.10 release source and it apparently does lack some adjustments. The one i tried was: http://vserver.13thfloor.at/Experimental/patch-2.6.10-rc3-vs1.9.3.12.diff right you are ... expect the 2.6.10 patch (vs1.9.3.13) in a few minutes ... just found it. Thanks! -- 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] debian-newvserver.sh patch
Hi Darryl,
Am Mittwoch, den 24.11.2004, 15:10 +1030 schrieb Darryl Ross:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 24 Nov 2004, Kilian Krause wrote:
-IPROOTDEV=eth0
+IPROOTDEV=${INTERFACE}
i cannot see this bug filed in the Debian BTS. Would you please open a
bug for it so it gets fixed upstream Debian ASAP (just making sure SARGE
doesn't ship with the broken package).. ;)
Fixed upsteam ;-)
Does that mean I don't need to file a bug report? (Just asking because
I'm not actually signed up on the debian bug tracker or a developer).
as already pointed out reportbug is a great tool to help you. But
basically you could even just forward this mail to the BTS.
In case things get fixed upstream you should still file a bug so the
Debian Developer does know there's an *IMPORTANT* new version in
upstream and will package that rather soon than when it's ready..
However, if you want i can move this snipplet up to the BTS. Is there a
new source of util-vserver out already, or not yet?
--
Best regards,
Kilian
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Kernel 2.6.8.1 and Vserver 1.92
Hi TK Lew, Am Donnerstag, den 21.10.2004, 17:14 +0800 schrieb TK Lew: hi : Thank for reply. I am using this command to build the vserver : ./vserver germanium build --force -m debootstrap -- -d sarge At some stage of the debootstrap it failed on configuring Exim and exits. Errors were encountered while processing: exim4-config exim4-daemon-light at exim4 exim4-base mailx W: Failure while configuring base packages. This will be attempted 5 times. is there anyway i can complete the debootstrap manually ? Just move /sbin/start-stop-daemon.REAL to /sbin/start-stop-daemon Hth. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
