[CentOS-docs] vservers: was: Article for wiki consideration

[R P Herrold]

On Thu, 29 May 2008, Ralph Angenendt wrote:

> Only if that person also wants to support that on the #irc channel and
> can explain why we support one type of vserver and don't support the
> other :)

a bit harsh -- the wiki article as written is to address 
_broken_ vserver matters
   http://wiki.centos.org/TipsAndTricks/BrokenVserver

I worked a bit on wordsmithing part of that, hoping for the 
emergence of a 'grafted on' vserver which was respectful of 
what I (and I think most of us) would consider a 'CentOS' 
server, with the tests of the section:


You are saying I was lied to and mislead?

Yes, a true CentOS installation has a CentOS kernel, the 
CentOS centos-release package, the CentOS yum package, and no 
modification or additions to the contents of 
/etc/yum.repos.d/. All dependencies will be satisfied, and 
except for configuration files (see: man rpm), an

 	$ sudo rpm -Va

     will run silently except for expected configuration file 
changes.

A true CentOS system also may be freely updated at any time. 
We add this requirement as security fixes also issue 
asynchronously. One indication that there may be a problem is 
that the rack hosting vendor offers CentOS 4.X (where X is a 
digit), rather than CentOS 4, and so forth; the CentOS team 
(and indeed the upstream distribution stabilizer) do not 
permit 'holding back' at a non-current, prior 'point' version, 
and still representing the product as the 'genuine' article.

-------------------------------------------------------------

So long as any sub-set install has addons which is packaged, 
satisfies all dependencies [and thus is without material 
excludes= holdbacks], and does not break rpm -V on packaged 
CentOS core items (or the subsystem the inquirant is having 
issues with), I've no problem with discussing and trying to 
support it in IRC

We have people wander in with hand compiled php, MySQL AB 
binaries, and config file edits;  they chose to fork and are 
on their own, until they revert to something CentOS ships.

So long as a misbehaving package is ours, and not tampered 
with, I think we have some obligation to respond in IRC, and 
in the bug tracker; but contrarywise, when the packages from 
others, I certainly have no compunction about referring the 
person back to the packging source, where (one assumes) it is 
known as to quirks and supported.

-- Russ herrold