some strong points there...
just 1 thing about the grsec/vserver combo: i do change stuff to make
linux-vserver and grsecurity work seamlesly together. It's just that i
don't have the time to re-engineer grsecurity, pax AND linux-vserver
completely to make a perfectly integrated combo patch. The reason why i
don't deem this necessary is that there is just a very small overlap in
the functionality they both implement.
Since they are not "doing" the same and don't interfere much (except some
atomic operations, "selectable kernel parameters" and so on...).
I just try to please you in such a way that you would be happy to have
this kind of patch in "your project" ;)
Greetings,
Rik Bobbaers
-- http://harry.enzoverder.be
linux/unix/system/network/security/hardware admin
infrastructure architect
> On Thu, Oct 21, 2010 at 02:27:15PM +0200, Rik Bobbaers wrote:
>> Just a small question, bertl:
>
> first, please don't hijack threads, especially closed ones
> (I can only consider this trolling :)
>
>> People that use vserver in production environment want a
>> stable environment.
>
> then they should pay some developers, preferably the
> existing ones, to do the testing and code cleanups
>
>> If you ever want linux-vserver to become something widely
>> used and accepted, there should be a stable patch, there
>> should be warnings if something is wrong and so on...
>
> there should also be contributions, this isn't a one
> man show. period.
>
>> You should inform people as much as possible and cooperate
>> with people doing packaging for distributions.
>
> I always cooperate with any distro maintainer and even
> volunteered a bunch of times to do the initial port for
> a given distro (to ease adoption)
>
>> As i get it, you hate every distribution in the world and
>> don't want to have anything to do with their patches.
>
> no, I do not want to maintain any distro patches over
> a longer period, and that is mainly because I am only
> one person, and after all, that's what distro maintainers
> are for (maintaining distro specific packages)
>
>> If you just say: that's a crappy kernel, just upgrade...
>> it's fun when you're playing around.
>
> well, what should I say about a crappy kernel then?
>
>> not if you 've been doing tests etc for weeks
>> before putting stuff in production.
>
> if you are referring to the debian kernel, I strongly
> advised against using the 2.6.26 patches, but despite
> my warnings, it was adopted, and of course, it turned
> out to be a fiasco ...
>
>> Right now, what we have is a very clear dev version of
>> util-vserver, a 2.3 patch series that's relatively stable
>> and testing version of the utilities
>
> I do not consider the experimental releases 'dev' or
> production ready, despite the fact that they work fine
> in production for many people out there
>
>> All the rest is is very old (kernel 2.6.22 and 0.30.215
>> of util-vserver).
>> Whenever someone asks a question about a kernel that old
>> or version of util-vserver that's that old, you just say:
>> upgrade to the latest.
>
> no, the latest stable release and stable util-vserver as
> well as older stable releases will work fine, as they are
> thoroughly tested, and given that somebody reports a bug
> to that kernel/patch version, it will of course be fixed
>
> folks come to me with 'obscure' kernel versions, because
> their distro or hardware or simply because they randomly
> picked a kernel version and complain about issues which
> are usually known and already fixed in more recent patches
>
> there are a few maintained branches (I do that exactly
> because those are long term kernels to be used by distros)
> like 2.6.27 or now 2.6.31/32 and of course recent kernel
> branches to give some choices ...
>
>> so essentially, you're saying "put the latest
>> unstable/testing kernel in production, but don't
>> complain if it dies, because i call it dev, so
>> you're on your own."
>
> what I am saying (usually) is, if you want a recent
> kernel/patch, you have to live with experimental, because
> we do not have the resources to do the required testing
> for a stable release ...
>
>> All that i do for the grsecurity/linux-vserver patch,
>> i just do because people want it.
>> There are many people that really use it and find it
>> useful...
>
> good, that's why we have the patches linked on the
> main page, no?
> but I doubt that you do the extensive testing required
> to label those patches 'stable' and that doesn't even
> relate to the Linux-VServer part :)
>
>> so here's the question: What is your view on this
>> project? do you really hate all the users that want
>> this to be production-ready?
>
> definitely not, all users that want a stable release,
> please start testing/reviewing the code/contributing
> to the project, so that we can get there eventually
>
>> do you really hate the grsec/vserver patch?
>
> I am fairly indifferent about the grsec patch ...
> I hate the fact that folks believe that adding the
> grsec patch to the mix will increase security out
> of the box (without doing proper setups) and I hate
> the fact that there is no properly adapted grsec
> which handles the special aspects of Linux-VServer
>
>> if so, just say so, and i will stop doing anything
>> all together.
>
> It seems that the community likes those patches, so
> the only folks you would hurt are those who use the
> patches ...
>
>> If you keep saying: you're using a distro kernel, so
>> screw you!, i don't want to be involved.
>
> I'm saying: if you want to use a distro kernel, how
> broken it may be, go ahead, be my guest, but if you
> encounter known or unknown issues with that kernel,
> you have to contact the distribution maintainer and
> not me ...
>
> once again, I cannot fix every distribution kernel
> out there, mostly because I do not have the time for
> that and in certain cases (debian for example) because
> they refuse to fix issues at all ...
>
>> It's normal that people want something that WORKS.
>> If you say: the only thing worth running now is 2.3
>> with the latest util-vserver, then make it stable/
>> support it/whatever! but don't tell people "there
>
> all recent kernels/patches are 'supported' and well
> maintained ...
>
>> is no reason not to upgrade to the latest version of
>> everything", when that version is unstable and not
>> working properly
>
> let me put it this way, why not install linux-2.6.36-rc1
> with the coresponding Linux-VServer pre-release patch?
>
> probably because -rc2 to -rc7 fixed issues found during
> mainline stabilization, and similar happened for Linux-
> VServer patches, so AFAICT, there is no reason whatsoever
> to use linux-2.6.36-rc1 in production ...
>
>> Sorry for my rant, but some people here (including me)
>> would like something stable that's not almost 3 years
>> old.
>
> then start contributing to the stabilization, it's a
> community project after all ....
>
>> If not, this project can be considered dead and people
>> will abandon this project.
>
> as with Linux-VServer guests, this project will be dead
> when the last 'user' dies ...
>
>> so for me it's time to choose: or, you start making
>> it work and start supporting stuff or, this project
>> will die because of frustration of all the users that
>> just get a : you don't have the latest utils that just
>> got out yesterday and you don't use the patch i
>> uploaded 2 days ago.
>
> well, there is no way to travel back in time and fix
> issues before they get into a patch, so if somebody
> comes to me with a known (and thus fixed) issue, then
> I'll advise him/her to use the fixed patch/tools because
> that is the easiest way to get the problem solved ...
>
> I don't think it would be better to advise them to
> backport changes to their kernel version, because that
> is the job a distro maintainer is supposed to do, given
> that they want to stick with an older kernel.
>
>> just my 2 cents,
>>
>> KR,
>>
>> Rik Bobbaers
>
Received on Thu Oct 21 14:15:44 2010