[Vserver] private ip & DNAT
Hello! I want give my virtual server private ip-address : 10.0.0.32 System - Debian Woody And this is rules from NAT table: ## this is working iptables -t nat -A POSTROUTING -p tcp -o eth0 -s 10.0.0.0/26 -j SNAT --to-source $real_ip ## but this is not working iptables -t nat -A PREROUTING -p tcp -s 0.0.0.0/0 -d domain1.ru --dport 1 -j DNAT --to 10.0.0.32:1 *** $real_ip - external ip-address domain1.ru have $real_ip address in provider's DNS How does that must work? Dmitry ___ 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] 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] 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.5&r2=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] 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] Linux-VServer Agenda ...
Herbert Poetzl wrote: yesterday evening I had the pleasure to meet with Serguei Beloussov. we had excellent Dinner at the 'Schnitzelwirt' Which one? There are so many "Schnitzelwirt" in and around Vienna. 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. There is a demand for things like these. Running old software without migration to newer OSs is one purpose, test environments is the other. E.g. I use VMware for testing stuff on different OS-versions, and on different OSs as well. The advantage is the easy installation, performance is the great disadvantage. UML is nice for test automation, e.g. in the area of simulating clusters at desaster recovery. Partitioning is nice, if some few similar environments are needed. E.g. on my last projects we had 12 test environments partitioned on 5 real IBM/AIX machines. Maybe I am wrong, but for vserver I see the great advantage there, what the name says: virtual servers - very nice for virtual server housing. At least I see a demand on integrating virtualization methods with cluster techniques like heartbeat, DRBD and SSI. 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! Hopefully the results of such a cooperation will remain Open Source under GPL. 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
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
... installs the base-packages of the given distribution with
help of 'vyum'
+urpmi ... -- -d
+... 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] Linux-VServer Agenda ...
On the other hand... always remember to look out for #1. Taking over a Free Software Project isn't a life sentence. You've already put in a monumental contribution to vserver, don't let a whole load of whining users give you the impression that to follow what is good for you is somehow not thoughtful, wrong, etc. Of course if you can get them to effectively bankroll vserver development whilst still being able to get access the the mindshare that they've built up, no-one will complain about that either. Free lunches are good while they last. Besides, so long as you remain available on IRC to field support questions, who will notice? ;) Sam. ps beware of the dark side, it is seductive and persuasive. may the source be with you at all times. Micah Anderson wrote: 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 -- Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) ___ 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)
Hello On Sun, Feb 20, 2005 at 04:11:57AM -0500, Stephen Frost wrote: > * 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? You would start a really nice little flamewar :) > > 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. I have argued about this lot of times. I think the current development branch is really good. The problem is that I do not see a timeline for the Debian release and I would like a couple of months of testing (with the package in testing) before I would like to release vserver to Debian stable. > > 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... I do not read this mailinglist every day. :) I want to explain this as it get up to discussion from time to time. 1) I'm interested in the development branch. 2) I really would like "upstream" to release this development branch in some kind of stable version. We have discussed this quite a lot and it do not seem too far away. 3) I want the development branch to have at least a couple of months of testing in the Debian distribution to catch the most critical issues before sarge is released as stable. And right now I have no clue when this is going to happen. 4) I will release a util-vservers and kernel-patch-ctx (or similar name) to exprimental soon. I hope I can get some time, maybe tomorrow. 5) My main focus before the release of sarge as stable, is to not get any release critical bugs to my packages. It would be _very_ sad if util-vserver will not be released at all becuase of build problems, RC bugs or similar. Such decisions is FTP-masters and I can not do anything about it more than having a really stable package. There are a couple of issues that have to be fixed before uploading to unstable. Exprimental is ok though. 1) Have heard of build problems on some arches. 2) debian-vservertools and integration with the development version of util-vserver? 3) Handling of /var/lib/vserver with backward compatibility mode. 4) I think there are some more. So please do not hijack my package. I have quite long experience with Debian Development and I know that changing things just before a release is a _very_ bad thing. I did so just before the last release (and during a security update) and I have learnt a big lesson there. You just can not imaging how many bug reports and email you can get on the same issue if the package is popular. So if I knew that Debian sarge will be released as stable on ... say august I would not have a big problem with this. But right now I only know that it is not next week (probably). Regards, // Ola > Stephen > ___ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PRO
Re: [Vserver] Mandrakelinux's patch for 0.30.204
Velu Erwan <[EMAIL PROTECTED]> writes:
> Velu Erwan a écrit :
>
>> Here come the patch I've made to be able to use the urpmi (an apt
>> like tool) and the mandrakelinux distribution.
>> This is the first version, I still have some work todo to add
>> options to urpmi but this version has been tested with success.
>>
> Works better with the attachement :b
Thx, I will apply the main idea to CVS; but there are some issues:
> diff -Nrub usr/lib/util-vserver/distributions/mandrakelinux//initpost
> /usr/lib/util-vserver/distributions/mandrakelinux//initpost
> --- distrib/mandrakelinux/initpost1970-01-01 01:00:00.0 +0100
> +++ distrib/mandrakelinux/initpost2005-02-19 10:01:35.0 +0100
~
I would prefer a shorter 'mandrake' here ;)
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
> --- 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.
> 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.
> diff -Nrub usr/lib/util-vserver/pkgmgmt /usr/lib/util-vserver/pkgmgmt
> --- scripts/pkgmgmt 2005-02-19 17:54:19.166560584 +0100
> +++ scripts/pkgmgmt 2005-02-19 15:11:20.0 +0100
> @@ -52,7 +52,7 @@
> if test -z "$WORKAROUND_106057"; then
> rpmdb_mntpoint=/dev
> else
> - rpmdb_mntpoint=/.rpmdb
> + rpmdb_mntpoint=$RPMDB_PATH
ditto... (note for me: remove redundancy)
> +_VURPMI="$SBINDIR/urpmi"
path should be determined in %configure. And the variable should be
named '_URPMI', not '_VURPMI'.
> --- scripts/vserver-build.functions.urpmi 1970-01-01 01:00:00.0
> +0100
> +++ scripts/vserver-build.functions.urpmi 2005-02-19
> 18:01:25.569737448 +0100
>
> +function urpmi.initVariables
> +{
> + RPMDB_PATH=$SETUP_CONFDIR/.rpmdb
> + findDir URPMIREPOSDEFAULT \
> + "$CONFDIR/.distributions/$DISTRIBUTION/rpm.repos.d" \
> + "$DISTRIBDIR/$DISTRIBUTION/rpm.repos.d" \
~~~
This does not seem to be used consistently; below you have 'urpmi.repos.d'
> +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.
> +function urpmi.initFilesystem
> +...
> +## workaround for yum's automatism to search the configuration in the
> chroot
> +local prefix='/../../../../../../../../../../../../'
are you really sure, that you need this hack for urpmi also?
> +test -z "$URPMIREPOSDEFAULT" -o -e "$PKGCFGDIR/urpmi/etc/urpmi.repos.d"
> || \
> + $_LN_S "$UPMIREPOSDEFAULT" "$PKGCFGDIR/urpmi/etc/urpmi.repos.d"
~
see note above regarding 'rpm.repos.d'
> 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.
> diff -Nrub usr/lib/util-vserver/vserver-setup.functions
> /usr/lib/util-vserver/vserver-setup.functions
> --- scripts/vserver-setup.functions 2005-02-19 17:54:19.173559520 +0100
> +++ scripts/vserver-setup.functions 2005-02-19 11:56:44.0 +0100
> @@ -169,6 +169,25 @@
> cat "$SETUP_FSTAB" >"$SETUP_CONFDIR"/fstab
> }
>
> +function setup_writeHostFile
> +{
> + tmp=${SETUP_INTERFACES[0]};
ok; let's do this at another time... This introduces redundant code and
should be solved in another way.
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).
> --- 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
> ... installs the base-packages of the given distribution
> with
>help of 'vyum'
> +urpmi ... -- -d
> +... installs the base-packages of t
[Vserver] Re: Linux-VServer Agenda ...
Le dimanche 20 Février 2005 19:31, Micah Anderson a écrit : > Herbert, > This is a great honor, congratulations! [...] > 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 +1. I totally agree with the whole mail. (Not the only parts I quote here ;)) This job is really an opportunity for you. But for the vservers, it can be as good (Company wanting to promote the project) as it can be bad (They want to sink competition), with a large range between those two extremes. 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". Crap ! My english is really too bad to say what I think ;) -- Les sociétés de l'an 2000 seront composées d'un ordinateur, d'un homme et d'un chien. L'ordinateur fera marcher la société, l'homme donnera à manger au chien, et le chien sera là pour empêcher l'homme de toucher à l'ordinateur. pgp5AGGRypybI.pgp Description: PGP signature ___ 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 schrieb am Sunday, den 20. February 2005: > In general I feel it's: > > a) bad form to hijack packages from active maintainers I'm not suggesting to hijack these packages. > b) Have multiple source packages in the archive for the same programs The difference between these programs is so vast that I don't really believe that you can say that these are the "same program". Thats like saying vim is the same as nvi is the same as elvis, or that bittorrent is the same as bittornado. They are all based on the same original thing, and often share similar code, but they all have very different enhancements that make them unique and appropriate as different packages. I am not even sure it makes sense to call the vserver kernel patch CTX anymore (the debian package is kernel-patch-ctx), even the 1.2.10 version is referred to as the vserver patch. I had no idea that this patch existed in debian, because I never thought to look for kernel-patch-ctx (and apt-cache search vserver does not return kernel-patch-ctx). > c) effectively go around the existing maintainer This I agree with. Since the maintainer is not responding to these messages, I suspect that they are busy and cannot notice them. It would be only appropriate to ask them directly, even better to CC the bug report on this so the communication can be in the open. > 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. Then we should ask them what their plans are, and what is going on with this, and if they need help. > And, again, the current maintainer seems active, a little suprised he > hasn't commented on this thread... The current maintainer has 71 packages to their name, many of them very high-profile busy packages that need a lot of work, its my guess that they have their hands full. micah ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: Mandrakelinux's patch for 0.30.204
Le dimanche 20 Février 2005 01:29, Herbert Poetzl a écrit : > basically Erwan's contribution/patch is a preliminary > support for the 'urpmi' tool which can be compared to > apt or yum (no distro war here please ;) from the util-vserver > side ... so once this has been evaluated I hope it will be > integrated into util-vserver aside with the existing support > for the other build methods ... The end of "urpmi --root /vservers/test..." ;-) ??? Thanks, Erwan ! Note that as a Mandrake user, i'm still available to try the soon-coming Mdk-vserver-kernel rpm... And the tools. -- pgpi9G2DYUQ4W.pgp Description: PGP signature ___ 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] 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
[Vserver] vserver and routing
Well, I did a fresh install 3 days ago and I'm currently fighting with the vservers to grant them access to the internet. Hollow told me 2 weeks ago I had to do this via SNAT. Said, I tried my luck. [EMAIL PROTECTED] # iptables -t nat -A POSTROUTING \ -s 192.168.16.0/255.255.255.0 -o eth0 -j SNAT --to-source 192.168.15.1 Did a tracepath inside the vserver on an adress in the external network. Hmm doesn't work. [EMAIL PROTECTED] # tracepath 141.53.7.30 1: 192.168.16.2 (192.168.16.2)0.238ms pmtu 1500 1: no reply The same from the master works like a charm. [EMAIL PROTECTED] # tracepath 141.53.7.30 1: extern28.uni-greifswald.de (141.53.18.28) 0.280ms pmtu 1500 1: access1-d1.uni-greifswald.de (141.53.250.5) 218.141ms 2: uni-greif-9.uni-greifswald.de (141.53.9.1) 211.376ms 3: ntrz100.uni-greifswald.de (141.53.7.30) 226.134ms reached Resume: pmtu 1500 hops 3 back 3 So I have no clue why the vserver doesn't get out of my local network. I think it's some sort of routing problems related to my connection. Maybe it could also be related due to my iptables rules. Thanks for the help in advance. Christian - Vserver Master: [EMAIL PROTECTED] # ip addr ls 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:84:2a:9a:af brd ff:ff:ff:ff:ff:ff inet 192.168.15.1/24 brd 192.168.15.255 scope global eth0 inet 192.168.16.2/32 scope global eth0 inet 192.168.16.2/24 brd 192.168.16.255 scope global eth0 inet 192.168.17.1/24 brd 192.168.17.255 scope global eth0:2 inet 192.168.16.1/24 brd 192.168.16.255 scope global secondary eth0:1 3: ippp0: mtu 1500 qdisc pfifo_fast qlen 30 link/ppp inet 141.53.18.28 peer 141.53.250.5/16 scope global ippp0 4: ippp1: mtu 1500 qdisc noop qlen 30 link/ppp [EMAIL PROTECTED] # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.17.00.0.0.0 255.255.255.0 U 0 00 eth0 192.168.16.00.0.0.0 255.255.255.0 U 0 00 eth0 192.168.15.00.0.0.0 255.255.255.0 U 0 00 eth0 141.53.0.0 0.0.0.0 255.255.0.0 U 0 00 ippp0 127.0.0.0 127.0.0.1 255.0.0.0 UG0 00 lo 0.0.0.0 141.53.250.50.0.0.0 UG0 00 ippp0 Vserver: [EMAIL PROTECTED] # ip addr ls 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:84:2a:9a:af brd ff:ff:ff:ff:ff:ff inet 192.168.16.2/32 scope global eth0 inet 192.168.16.2/24 brd 192.168.16.255 scope global eth0 [EMAIL PROTECTED] # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.17.00.0.0.0 255.255.255.0 U 0 00 eth0 192.168.16.00.0.0.0 255.255.255.0 U 0 00 eth0 192.168.15.00.0.0.0 255.255.255.0 U 0 00 eth0 141.53.0.0 0.0.0.0 255.255.0.0 U 0 00 * 127.0.0.0 0.0.0.0 255.0.0.0 UG0 00 * 0.0.0.0 0.0.0.0 0.0.0.0 UG0 00 * [EMAIL PROTECTED] # iptables-save # Generated by iptables-save v1.2.11 on Sun Feb 20 10:17:38 2005 *mangle :PREROUTING ACCEPT [13361180:15422431402] :INPUT ACCEPT [13305339:15399898175] :FORWARD ACCEPT [55836:22533019] :OUTPUT ACCEPT [8230996:2484298043] :POSTROUTING ACCEPT [8287150:2506612874] COMMIT # Completed on Sun Feb 20 10:17:38 2005 # Generated by iptables-save v1.2.11 on Sun Feb 20 10:17:38 2005 *nat :PREROUTING ACCEPT [4669:270648] :POSTROUTING ACCEPT [126:16164] :OUTPUT ACCEPT [308:395925] -A POSTROUTING -s 192.168.16.0/255.255.255.0 -o eth0 -j SNAT --to-source 192.168.15.1 -A POSTROUTING -o ippp+ -j MASQUERADE -A POSTROUTING -o ippp+ -j MASQUERADE COMMIT # Completed on Sun Feb 20 10:17:38 2005 # Generated by iptables-save v1.2.11 on Sun Feb 20 10:17:38 2005 *filter :INPUT ACCEPT [13305166:15399875998] :FORWARD ACCEPT [27797:19086961] :OUTPUT ACCEPT [8230996:2484298043] -A INPUT -i ippp+ -m state --state INVALID,NEW -j DROP -A FORWARD -i eth0 -o ippp+ -m state --state NEW,ESTABLISHED -j ACCEPT -A FORWARD -i ippp+ -m state --state INVALID,NEW -j DROP COMMIT # Completed on Sun Feb 20 10:17:38 2005 ___ 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)
* 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
