[CentOS] Centosplus & CentOS Extras, Enlarge your tent

Sanjay Arora sanjay.k.arora at gmail.com
Tue Mar 14 14:07:10 UTC 2006

On 3/13/06, Karanbir Singh <mail-lists at karan.org> wrote:
> there has already been a bit of planning for a http://wiki.centos.org/ -
> and a few various wiki s/w were looked at a few weeks back, settling on
> moin.
Long post below.....don't sleep ;-))

Enterprise Strategy for myself using CentOS...some thoughts...maybe
you guys will find some insight in this for your planning.

Some Background: Indian SME, using 5 Desktops (now Centos...only one
machine Windoz Dual-boot), One IPcop firewall on the 256 Kbps ADSL,
Five Servers (all Centos), Samba File Server (with mySQL, apache &
qmail/vpopmail installed), INN News Server (NNTP + Mailing lists thru
mail2news), Database Server postgreSQL & minor mySQL install
(minimally used), BackupPC for entire network backup to large capacity
HDDs (4 x 300 GB) on the LAN and one machine in the DMZ with apache &
associated web-tools, postgresql, mysql, qmail/vpopmail with
spamassasin & clam, getmail for gmail.

All machines are minimally installed for their function & only the
desktops are installed with full options, though server daemons are
stopped. I do NOT need anything out of the CentOS repo for
these....all are stable applications on CentOS.

When Redhat slapped support on EL, I was in a hell of fix. In a
haphazard way tried different distros until I installed whitebox from
which I shifted to CentOS. I was then planning to phase our Windoz and
therefore Redhat action was a major setback because I got no
budget...let alone a shoestring one. Guess I need to thank you guys
for the job that you do....mostly thankless, I guess...so here
goes...THANKS, GUYS!

Now that I evaluate the IT requirements for the future of my SME
Company, basic requirements remain the same except for a few changes.
I guess it would apply to various enterprises, milages may vary, due
to Internet Access type/costs & other issues.

Four major areas I foresee for any SME and maybe for biggies too..

1. Firewalling...distributed...not only on the perimeter, easily
available with iptables, maybe even with canned scripts & GUI tools
like fwbuilder that I am currently evaluating BUT major area is a GUI
based approach on centralized logs...ACID etc...again all available, I
think without breaking CentOS repo updates, though rpms would be
lovely ;-)

2. Intranet/Extranet/Portal...This is for the DMZ Web/mail Server &
the Intranet Server on the LAN. Many could make do with CMSs with no
changes to their repo requirements. Some, especially those with
workflow aspirations like myself would go for solutions like
Plone/Zope/latest python combo, which would break the Centos repo
update path & hence the security/stability of the systems.

3. Desktop Applications...This is the area where CentOS lags behind.
Enterprise does require stability, but workstations used by the staff
need a major push...nobody is happy due to minor issues like playing
music, video, glitches of java & flash with firefox...many ask for one
or the other app that leads to repo hell.

4. Disaster Recovery...and I do not mean backing up a continent away
or recovering from Katrina etc., all one needs is recovering from a
failed HDD or restoring from backup or providing services from another
machine while upgrading one...all very everyday...buy invariably all
pains in the butt...;-(

Enter XEN...Virtualization technologies are going to be a very
important player to the enterprise. I plan on going for Xen in a major
way....if my distro will support...great...but I don't have a choice
as I see it...I got to master it.

As I see it, my basic infrastructure in point 1 (Servers) is stable
and no need to change anything there, except to virtualize each of the
services provided by these servers and thereby provide
failover/disaster recovery. I am not talking HA/Carp etc., only being
able to restore service from another machine from a web-based
interface on my intranet.

Coming to Desktops & DMZ web/mail server, they do need to break from
the CentOS repo & business is business...you gotta do what you gotta
do. Enter Xen again, I maintain each service in a seperate Xen domu,
each service in a seperate compartment and unaffected by the
other...you end up doing one or two violations in each domu, basic
Centos in each is kept with minimal repo changes. I want to convert
repo hell to repo trouble!

All very easy to say..in this very long post...but its going to be a
very long and painful process. This is where I believe a movement in
the CentOS community can make a difference....using the wiki & a
defined ENABLEMENT process...lets call it CentOS enables your
applications movement or something equally syrupy ;-)

I believe the wiki should be divided into application forums further
subdivided into application software e.g. Centos Wiki -> mail -> qmail
-> Various threads of qmail how-to, each a complete howto of a given
application on Centos e.g. qmailrocks.org on Centos Howto or
qmailtoaster on Centos Howto or Qmail/vmailmanager on CentOS from
source howto.

These howtos should be moderated by group wise moderators who are
knowledgable about that application, maybe even a couple of users
(those who use any form of EL) from that application's mailing list
should be invited to help moderate the thread or forum.

Tested installs from these howtos should find their way into CentOS
contrib repo, so average users can start using these, without going
too far away from the home fires ;-)

Another thing...community should be mentored & encouraged in learning
to package software in rpms for centos and contribute. The mentors can
test & check the package...thats the only way community can really
grow...Karan & his fellow sufferers can do only so much for us ;-)

Take me, I know how to deploy from binary/src rpm and from source but
just ask me to package something for my system & I'll probably faint
;-) This is what needs to change!

Hope I have not bored you guys too much...those that have fallen
asleep, please do wake up. My harrasement of you is over ;-)

With best regards.

More information about the CentOS mailing list