...based on my experience, for use in all non-certified enterprise
operations (large and small) on general-purpose computers.
RHEL is, of course, the better alternative when you require the upstream
vendor's certified platform, certified and tested integrated solutions,
industry-leading support, or customized solutions. Their offerings are a
bargain when you consider the benefits they provide to an enterprise,
especially if you can absorb the cost over your organization's overall
First, let me add my thanks to the development team and contributors for
their countless hours of relentless efforts and uncompromising QA in
(re)producing this enterprise-class OS. Well done! Were it not for
CentOS; organizations like mine with extremely limited personnel,
materiel, and financial resources would be much less productive or may
have to shutdown altogether. With budgets getting ever-tighter it is
even more critical to leverage OSS and the work of generous volunteers
like you. In return, I and my associates will attempt to contribute in
whatever way possible to further this work. My hope is that this
testimonial will encourage others to consider or continue using CentOS
and contribute in whatever way they can too.
I also feel obligated to give a nod to the upstream vendor without whom
we would not have CentOS. Their long-standing, generous contributions to
the worldwide community have been a dominant force in shaping the OSS
movement, increasing productivity, stability, and availability of
business and personal information systems all over the globe.
In my role managing networks I thank you for the rock-solid "binary
compatibility" that gives us a secure, stable, reliable, versatile,
highly available platform on which to build and/or supplement an
In my role as a DoD contractor and citizen I thank you for giving me a
way to accomplish the mission while reducing the burden on taxpayers
without sacrificing value, security, or quality.
As a Linux and OSS enthusiast since the early 90's I thank you for
making possible an enterprise-class platform on which to experiment and
learn new things.
As an RHCE I thank you for making it so much easier to keep my RHEL
skills current without breaking the bank.
I've just completed a flawless upgrade to 5.6 on my main sysadmin
workstation. Although there were over 250 packages updated from our
internal CentOS and EPEL mirrors, it was quick and painless. Not so much
as a single error in the logs. In fact, the system seems much more
responsive now. With such a successful pilot, I have no reservations
about rolling out this MR throughout our facilities on-site.
I'm eagerly anticipating release of CentOS 6 for use in migrating our
RHEL 4 servers and CentOS 5 development systems. Long awaited
replacement hardware now appears likely for two of our main department
servers and a critical engineering/development server. We will install
CentOS 6 on the new Dell PowerEdge servers and migrate existing
services. CentOS 6 built-in LXC support will be a vital component of one
development server, enabling several developers to simultaneously build
and test modifications to aircraft simulation software. With multi-core
CPUs and CentOS 6 native virtualization on the new department servers,
we will be able to de-commission the last of our dedicated MS Windows
servers (and re-purpose them using CentOS), relegating them to virtual
space where they can be more easily controlled. Most of the remaining MS
Windows services (AD, file, print, etc.) will also migrate to CentOS,
leaving only those services which require a Redmond-based OS to run
(i.e. WSUS, Symantec Endpoint Protection, eEye Retina - mandated
While our RHEL installations have served us well, the cost of
maintaining the entitlements has been deemed too much for our budget. We
need to expand the use of an enterprise Linux distro but the RHEL EULA
requires separate entitlement fees for each installation even though our
call volume is extremely low (2 real incidents in 7 yrs) and download
bandwidth negligible. Also, the upstream vendor provides no economical
way to mirror RHEL updates on isolated networks - Satellite is out of
the question. RHEL 4 updates must be painstakingly retrieved manually,
one at a time, on the "Internet machine" before transport and
distribution to internal networks. RHEL 5 yum updates are not much
simpler when all is said and done.
The plan is to standardize all internal Linux machines on CentOS. To
cover unforeseen circumstances we've purchased a block of hours of OSS
support from a 3rd party vendor that is not tied to a specific machine
or platform. The cost is a fraction of what we were paying for RH
entitlements and is the same whether we have 2 or 200 Linux hosts.
Granted, we forfeit the unparalleled support offered by the upstream
vendor and wait (usually) just a bit longer for updates. For our needs,
however, this is acceptable.
[How We Use CentOS]
Desktop Workstations: Most software developers use CentOS as either
their primary workstation for office and development tasks or a
combination of CentOS and MS workstations. Even those that require or
prefer Windoze have RHEL/CentOS at their disposal via VNC/XDMCP over
stunnel on our servers. I'm always looking for Windoze devotee converts
too, wherever feasible.
Network & Systems Administration: All systems and network administration
staff have a CentOS machine either as their primary workstation or at
their disposal. All admin personnel besides myself have other primary
duties so having a stable, reliable, versatile computer platform is
Dedicated Development Machines: We've duplicated a software support
server based on RHEL 5 designed to support software engineering for
aircraft simulators using CentOS 5. The original cannot be modified as
it was purchased with the training systems. The CentOS version can be
optimized and customized to fit our needs. CentOS 6 will give this
server even more flexibility.
Multi-platform Legacy System Software Development: Using a combination
of commercial Linux cross-compilers (Concurrent PLDE), remotely accessed
legacy (RISC) real-time Unix machines, open source software CM (Aegis),
custom scripting, and a little ingenuity, we continue to modify and
maintain real-time simulation systems that are decades old as well as
the latest Linux-based training systems. Even software support for MS
based training systems are managed on the same RHEL (and soon CentOS)
Transient Workstations: We refit older, obsolete, MS-based workstations
with CentOS for visiting contractors. We often have 3rd party
contractors come on site that need access to engineering and development
resources. It's much simpler to offer them a machine on which to work
than try to secure and validate their company equipment.
Update Servers: One of our restricted access networks gets all its
updates (MS, Linux, development apps, CM, security, and 3rd party apps)
from a tiny Dell Optiplex machine running CentOS 5. The server itself is
updated periodically via a read-only USB drive and custom updates
scripts CentOS will run fairly well on very lightweight hardware so is
very useful for limited role servers.
Main Department Servers: As I indicated above all our main servers will
be migrated to CentOS. These provide all vital services to keep our
operations running efficiently for office administration, personnel
management, project management, hardware and software engineering, and a
multitude of overhead tasks.
Research and Development: As new requirements are discovered or unique
challenges are presented, CentOS provides a versatile platform on which
to develop and test solutions.
[Security Updates during 5.6 delay]
For us, delays in security updates while awaiting 5.6 were troubling.
Our organization must comply with strict DoD IA directives and respond
to a steady barrage of vulnerability notices. Even RHEL updates are
sometimes not quick enough to satisfy these. Regardless of the actual
security impact on our isolated networks, the same reporting deadlines
apply to our development and workgroup servers as to the Red Hat
Certificate Servers that host the majority of DoD's security
infrastructure. With our homogeneous network of RHEL, CentOS, MS Win,
Unix variants, and assortment of real-time OSes hosted on mostly legacy
equipment; this is quite a challenge. Add to this the fact that all our
engineering networks are isolated from all outside networks (including
the Internet), and maintaining IA compliance becomes a monumental task.
Fortunately, I took Russ Herrold's helpful, patient, and polite
suggestion to setup a repeatable "one-off" re-build process for security
updates from upstream sources. These updates are distributed internally
from a custom "localcentos" repo so they won't interfere with CentOS
updates when they become available. It was surprisingly simple to
implement. It took a bit of time and effort to setup and document (still
documenting) but it's worth the peace of mind to keep the IA gods off
our back. It also gives junior sysadmins a reliable method of
maintaining compliance in my absence. Hopefully others will take Russ's,
KB's, and other cool-heads' example and use the fora and MLs to
encourage and inspire rather than to incite and anger.
[The Bank of CentOS]
The CentOS team represents a wealth of information that can be tapped
through the many on-line resources; including documentation, fora, and
mailing lists. With a little research, patience, and empathy no problem
or challenge need go unsolved. Some of us may need only a pointer to
appropriate resources or a suggestion from someone who's tried "it"
before, where others may need a jump-start. Like many these days, I'm
always short on time and long on ToDo lists but I'll renew my efforts to
share what I've learned to help pay for what I've been so generously
given in CentOS and other OSS projects. Hopefuly, others will do the
same and we'll all benefit and live happily ever after... er, um...
okay, well at least we'll all benefit. :-)
Very Gratefully Yours,
CentOS mailing list