Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
* Micah Anderson ([EMAIL PROTECTED]) wrote: Stephen Frost schrieb am Thursday, den 17. February 2005: This is certainly something I'm all for, and were the Debian maintainer of vserver going to upload a kernel-patch for 1.9.4 I'd be happy to help him create that package such that it patches cleanly against Debian kernel sources (again, not hard to do, really). What is to stop us (both debian developers), as well as other debian developers who are wanting this, from creating our own kernel-patch package that implements the patches for 1.9.4 and the updated tools? An example would be the difference between kernel-patch-2.4-grsecurity (for 2.4 kernels and old grsec) and kernel-patch-grsecurity2 (for 2.6 kernels and new grsec). Obviously the maintainer of the -ctx patch and the util-vserver does not find the newer patch and utilities important or stable enough, but everyone else does. If the maintainer of the -ctx patch and of util-vserver wishes to continue to maintain those old packages and does not wish to maintain the package for the newer kernel patch and newer utilities, we should have no problem with that. We simply solve what is obviously our problem, rather than try to make it Ola Lundqvist and Ron Lee's problem. In general I feel it's: a) bad form to hijack packages from active maintainers b) Have multiple source packages in the archive for the same programs c) effectively go around the existing maintainer It's not entirely the case that the existing maintainer is totally uninterested in the 1.9.x vserver series or I'd be more concerned. He's shown interest and seemed to be working with some others on a better solution to the current situation (which might involve what you're suggesting, but I'd really hope not..). I don't know that we've given them quite enough time yet to claim that nothing's happening and that we need to move forward independently - it's only been maybe a month or so as I recall since serious discussion of 1.9.x was brought up to the maintainer. And, again, the current maintainer seems active, a little suprised he hasn't commented on this thread... Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Linux-VServer Agenda ...
Hi bertl, sounds great to me, go for it! :-) On Sunday 20 February 2005 02:03, Herbert Poetzl wrote: Hi Community! yesterday evening I had the pleasure to meet with Serguei Beloussov. we had excellent Dinner at the 'Schnitzelwirt' where we talked about - who would have guessed - different virtualization techniques and various commercial and non commercial products in this area ... he clearly pointed out that his company has some interest, that virtualization techniques - like the one linux-vserver uses - 'gain momentum' in the face of system emulators like VMware(tm) and partitioning approaches like Xen. he also told me that they are watching this project very closely and that, while it is small compared to their products, it's quite interesting ... after that we had some fun with Billards (Carambol) and right afterwards I was basically offered a job where I would be able to do some kernel development and get payed for doing so ... let me know what you think! TIA, Herbert ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- regards, Georges Toth ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Linux-VServer Agenda ...
Herbert, This is a great honor, congratulations! Ultimately the decision is up to you, however as someone who has found your presence in the vserver project to be incredibly valuable, I fear that we will loose such an important piece of this project if you were to take this position. Many free software developers are hired by corporations because the corporations have found that their software is valuable to them, their paying someone enables them to contribute to the community, as well as ensure that the development of the software is able to be sustained in such a way that does not leave them in a bind. It also gives them the ability to say that they contribute to the Free Software movement, if they find it advantageous to make such a claim. If this company is wanting to hire you so that you can continue to work on the vserver project (and get paid), then this is a great opportunity for you and weighing the pros and cons of taking this position are very easy. If the company is wanting to hire a good kernel developer to work on their product, then I would be suspicious. Why? Well, they obviously have identified you as a good kernel developer and would find you a valuable addition to their team. However, they would be asking you to focus your work, time and energy on their product, rather than the vserver product. This may be fine, because you could still work on vserver in your spare time, but working for a demanding company takes its toll and your spare time is often spent recovering from work, rather than doing more coding. You have done incredible work in the vserver project, this work has been done with care and passion, time and energy. If this company wants to take you away from the project that you have devoted so much of yourself to, then there must be a very good reason for you to do that, otherwise they are tearing you away from something you enjoy to work on their commercial product. This would show to me that they do not care about the vserver project, but only their product, and this is not a very nice way to treat someone. It is my opinion that if they want to take you away from the project that you have devoted yourself to in a very passionate way, then they either should be supporting the vserver project in doing so, or it does not matter because you need the money. I suppose some of this suspicion comes from the fact that this company develops a product that is very similar to vservers, but it is commercial and proprietary. I question their motivation behind wanting to hire you, the driving force behind the free software competitor to their product. It would be a shrewd business move for them to hire you away from the vserver project because they think that it would languish and fall apart without you behind it. However, I do not know the details of what your arrangement with them would be, or what they have said to you about the vserver project, or their plans for their own product. Perhaps they want to pay you to work on vservers and they will move their product to use vservers as a base, I do not know. These are important questions I think to ask. I do not say all of this to dissuade you from taking this job, if you need to take it, you should, the decision is up to you. I for one would miss greatly Bertl if he was not around because he got vacuumed up by a company. micah Herbert Poetzl schrieb am Sunday, den 20. February 2005: Hi Community! yesterday evening I had the pleasure to meet with Serguei Beloussov. we had excellent Dinner at the 'Schnitzelwirt' where we talked about - who would have guessed - different virtualization techniques and various commercial and non commercial products in this area ... he clearly pointed out that his company has some interest, that virtualization techniques - like the one linux-vserver uses - 'gain momentum' in the face of system emulators like VMware(tm) and partitioning approaches like Xen. he also told me that they are watching this project very closely and that, while it is small compared to their products, it's quite interesting ... after that we had some fun with Billards (Carambol) and right afterwards I was basically offered a job where I would be able to do some kernel development and get payed for doing so ... let me know what you think! TIA, 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] Mandrakelinux's patch for 0.30.204
Enrico Scholz a écrit :
First thing, thanks to handle my patch so quickly.
I would prefer a shorter 'mandrake' here ;)
Everyone prefer mandrake but the real name is Mandrakelinux.
I do not know if urpmi supports this, but it should be possible to
specify the version of Mandrake Linux. E.g.
| vserver ... build -m urpmi -- -d mdk10
Of course it could be done, but the main idea was to install the vserver
using the virtual basesystem rpm (available on all mandrakelinux release).
--- distrib/mandrakelinux/pubkeys/pubkey 1970-01-01 01:00:00.0 +0100
+++ distrib/mandrakelinux/pubkeys/pubkey 2005-02-19 17:38:49.0 +0100
I am not sure if I should ship foreign gpg keys in my package. Copying
the keys from existing pacakges at %post time would be probably the
better solution.
They will never change so it could be cool to provide it.
diff -Nrub usr/lib/util-vserver/functions /usr/lib/util-vserver/functions
--- scripts/functions 2005-02-19 17:54:19.038580040 +0100
+++ scripts/functions 2005-02-19 17:51:22.203463064 +0100
@@ -236,7 +236,7 @@
if test -z $WORKAROUND_106057; then
_rpmdb_mntpoint=/dev
else
- _rpmdb_mntpoint=/.rpmdb
+ _rpmdb_mntpoint=$BASEDIR/.rpmdb
This does not look sane. The rpm-database mountpoint MUST be at the / of
the vserver.
I must assume that some hack were introduce but certainly because I
didn't catch everything in vserver's architecture.
+_VURPMI=$SBINDIR/urpmi
path should be determined in %configure. And the variable should be
named '_URPMI', not '_VURPMI'.
Once again a lake in the the global knoweldge :/
~~~
This does not seem to be used consistently; below you have 'urpmi.repos.d'
I've copy that from yum, I'm not even sure its usefull for urpmi.
+function urpmi.initDB
+{
+ rm -rf $1/var/lib/rpm
+ mkdir -p $1/var/lib/rpm
+ rpm --root $1 --initdb
+rpm --root $1 --rebuilddb
+}
see above; rpm-db MUST NOT be under /.../. Using the 'rpm.initDB'
function should suffice.
I had some troubles using rpm.initDB. It never generates the rpmdatabase
because of a mount -bind.
Even more strange, the rpm database provided is not working with urpmi.
I agree to change the paths but please keep use the real rpm call.
are you really sure, that you need this hack for urpmi also?
I don't think so, I've kept that from yum.
diff -Nrub usr/lib/util-vserver/vserver-build.urpmi /usr/lib/util-vserver/vserver-build.urpmi
--- scripts/vserver-build.urpmi 1970-01-01 01:00:00.0 +0100
+++ scripts/vserver-build.urpmi 2005-02-19 18:02:40.343370128 +0100
...
+urpmi.initDB $VDIR
see above; 'rpm.initDB' should suffice.
Using today rpm fake it doesn't seems. Please keep that.
Btw... is this really needed? DNS should carry information about your
hostname so an extra /etc/hosts entry seems to be superfluously (except
for the DNS server).
It was not really necessary for urpmi. A rest of a personal hack. sorry.
--- scripts/vserver-build~ 2005-02-19 18:31:29.202699861 +0100
+++ scripts/vserver-build 2005-02-19 18:37:36.595585034 +0100
@@ -56,6 +56,9 @@
yum ... -- -d distribution
... installs the base-packages of the given distribution with
help of 'vyum'
+urpmi ... -- -d distribution
+... installs the base-packages of the given distribution with
+ help of 'vurpmi'
~~
This program is not part of your patch, right?
Agreed. Appologies. s/vurpmi/urpmi/
Thx for the patch
Enrico
I'm free to test the cvs integration.
Thx for your experienced proof reading,
Erwan
___
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)
Stephen Frost wrote: In general I feel it's: a) bad form to hijack packages from active maintainers b) Have multiple source packages in the archive for the same programs c) effectively go around the existing maintainer ACK - mostly. First I have to disclaim, that I am new to this list, and have no experience with vserver. I only read the documentation up to now. Let me tell a success story, which maybe has some similarities compared to the current situation. In January 2004 I get involved with DRBD, first trying to use it, then mastering the the installation, which was hard. Then I corrected ~200 errors in the outdated docs for Version 0.6.10. Developers were busy at this time getting 0.7.x working. After 8 prereleases 0.7.0 was ready in July, and the Debian maintainer announced an upload within one week. This did not happen very long. In the meantime some Debian users - including me - tried to get packaging and compiling against Debian kernels working, as 0.7.4 got known production quality. In October DRBD got two Co-Maintainers doing great work and discussing actively with upstream developers. And yes, it got renamed from drbd to drbd0.7 within Debian. There was also a heavy discussion where I defended to have a working /debian subdirectory at upstream SVN. Let me list some facts and arguments related to the aims of involved persons: - upstream developers don't have the time to support distributions (except you pay them;-) - developers should be (and mostly they are) interested to get their software tested as early as possible - some users want the current version, many or most want the latest stable version, but are not skilled enough, or do not have the time to manage the packaging problems. Solutions can be: - the Debian maintainer finds a way to keep in track - some advanced users provide patches or .debs outside of Debian - vserver gets Co-Maintainers - if time is the problem Helmut Wollmersdorfer ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Mandrakelinux's patch for 0.30.204
[EMAIL PROTECTED] (Velu Erwan) writes: I do not know if urpmi supports this, but it should be possible to specify the version of Mandrake Linux. E.g. | vserver ... build -m urpmi -- -d mdk10 Of course it could be done, but the main idea was to install the vserver using the virtual basesystem rpm (available on all mandrakelinux release). I have to admit that I do not know anything about 'urpmi', but with 'yum' and 'apt' I can configure the repository which is going to be used. This makes it possible to install FC2 guests on FC3 hosts by using '... -d fc2'. So it would be nice when I could call 'urpmi' in the same way (install mdk9 guests on a mdk10 hosts e.g.). -_rpmdb_mntpoint=/.rpmdb +_rpmdb_mntpoint=$BASEDIR/.rpmdb This does not look sane. The rpm-database mountpoint MUST be at the / of the vserver. I must assume that some hack were introduce but certainly because I didn't catch everything in vserver's architecture. Oooh... I just detected an ugly bug in the rpmdb handling which was hidden by the /var/lib/rpm symlink. Please try [1] if it fixes your problems. Else: Base idea behind the external packagemanagement is, that host commands shall never rely on any guest data. E.g. I do not trust db4 (the databasesystem used by rpm) enough to store the rpmdb within the guest. Perhaps there are exploits in the database-reading-code which can be triggered by a manipulated database. So, using /var/lib/rpm as a place for the rpmdb is dangerous: an attacker within the vserver could create a /var/lib - /somewhere symlink pointing to such a manipulated database. And there is nothing which can be done against it... That's why, the rpmdb has to be mounted into the toplevel directory where such symlinks are impossible. Using /.rpmdb is a hack; /dev would be a much nicer place because it is available everywhere and ignored by rpm. But there is rh bugzilla bug #106057 which requires that the rpm database must be both in the chroot-environment and in the real-root one. So the /.rpmdb has to stay. The position of the rpm-database is specified by the %_dbpath macro which is changed in the vserver specific rpm-configuration. I do not know if 'urpmi' honors this macro (apt had a similar bug which caused me to create an (insecure) /var/lib/rpm - /.rpmdb symlink), whether it must be configured at another place, or if 'urpmi' must be fixed. +_VURPMI=$SBINDIR/urpmi path should be determined in %configure. And the variable should be named '_URPMI', not '_VURPMI'. Once again a lake in the the global knoweldge :/ How will you operate after the vserver was build? Do you require an 'vserver ... pkgmgmnt internalize'? If not, you should create a 'vurpmi' wrapper. A plain 'urpmi --root /vserver/...' is dangerous and must never be used. Enrico Footnotes: [1] http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/scripts/vserver-build.functions.rpm.diff?r1=1.5r2=1.6 pgpG6nJ1dZb2x.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: Linux-VServer Agenda ...
On Sun, 20 Feb 2005, Nicolas Costes wrote: You need to deeply discuss those facts with the company, and why not try to secure the vservers' future in the job contract... My english is too bad when it comes to that domain, but I can try to say it like this: I agree to work for you if you agree to support vservers developpement, instead of trying to make them disappear, ie. use and promote the vservers technology in your products, and respect the GPL. That'd be all water under the bridge, since ultimately a corporation is to serve its stockholders regardless of what any officer of the corporation may say, even if it is truly spoken from the heart. The key thing is the holder of the copyright. And a typical employment agreement usually states that whatever work you do is actually owned by the company (regardless whether you do it in your spare time). And whoever owns the copyright can govern the project in whichever direction possible, even make part or all of it closed-source. I do not mean to say that this is what's going to happen, but it's a possibility nonetheless. Therefore the ideal situation is when the copyright is owned by a separate corporate entity, usually a not-for-profit, formed with a charter to specifically to support the project. Some good examples are the ASF (apache), Mozilla Foundation, OSDL, PSF, etc, etc. These organizations have no other interests, are not there to make money and cannot be easily intimidated legally or otherwise. There is a good reason why all these foundations exist in today's world of SCO and the like. Grisha ___ 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
