...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 IT budget.
[Thanks!]
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 enterprise operation.
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.
################# ## Testimonial ## #################
[Upgrade to CentOS 5.6]
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.
[Planned Migrations]
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 vulnerability scanner).
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 essential.
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) hosts.
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,
Cal Webster
On Apr 12, 2011, at 1:43 PM, Cal Webster wrote:
...based on my experience, for use in all non-certified enterprise operations (large and small) on general-purpose computers.
Wow, what a great post.
Thanks Carl, very cool.
Hope you aren't retiring any time soon, I see too many barnies in charge making thoughtless decisions. As a consultant I'm often on the outside looking in and what I see is a scary trend of rash and flippant choices.
- aurf
On Tue, 2011-04-12 at 14:08 -0700, aurfalien@gmail.com wrote:
On Apr 12, 2011, at 1:43 PM, Cal Webster wrote:
...based on my experience, for use in all non-certified enterprise operations (large and small) on general-purpose computers.
Wow, what a great post.
Thanks Carl, very cool.
Thanks for letting me know someone read it Aurf. If I've helped encourage even one I'm happy.
Hope you aren't retiring any time soon, I see too many barnies in charge making thoughtless decisions. As a consultant I'm often on the outside looking in and what I see is a scary trend of rash and flippant choices.
- aurf
Retire? Not likely anytime soon with 3 kids, 5 grandkids (and many pseudo-grands) and more on the way. Besides, there's so much left to see and do and so little time... Thanks to CentOS and OSS I'll never really have to retire anyway. ;-)
./Cal
Cal Webster wrote:
On Tue, 2011-04-12 at 14:08 -0700, aurfalien@gmail.com wrote: Thanks for letting me know someone read it Aurf. If I've helped encourage even one I'm happy.
I also read it, and even it's 01h after too long day, now I found it interesting to read and fine praise for CentOS team.
Ljubomir
Not specifically a Centos question but does anyone know how to change the column widths in "top"? I'm in the unique position where I need to be able to see more than 9999.0% CPU :-)
Thanx,
Russell ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
On 04/12/11 2:10 PM, Smithies, Russell wrote:
Not specifically a Centos question but does anyone know how to change the column widths in "top"? I'm in the unique position where I need to be able to see more than 9999.0% CPU :-)
probably have to hack the source :-/
Thought as much :-( Atop seems to display much better, currently running at 12728% CPU :-)
--Russell
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of John R Pierce Sent: Wednesday, 13 April 2011 9:27 a.m. To: centos@centos.org Subject: Re: [CentOS] changing column widths in "top"?
On 04/12/11 2:10 PM, Smithies, Russell wrote:
Not specifically a Centos question but does anyone know how to change
the column widths in "top"?
I'm in the unique position where I need to be able to see more than
9999.0% CPU :-)
probably have to hack the source :-/
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
On Tue, Apr 12, 2011 at 10:35 PM, Smithies, Russell Russell.Smithies@agresearch.co.nz wrote:
Thought as much :-( Atop seems to display much better, currently running at 12728% CPU :-)
Give htop a try as well; it's in EPEL AFAIK.
Htop looks interesting and I might try it on one of our other servers but on this one I only see the first 60 CPUs.
--Russell
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Lucian Sent: Wednesday, 13 April 2011 9:41 a.m. To: CentOS mailing list Subject: Re: [CentOS] changing column widths in "top"?
On Tue, Apr 12, 2011 at 10:35 PM, Smithies, Russell Russell.Smithies@agresearch.co.nz wrote:
Thought as much :-( Atop seems to display much better, currently running at 12728% CPU :-
)
Give htop a try as well; it's in EPEL AFAIK. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
Htop looks interesting and I might try it on one of our other servers but on this one I only see the first 60 CPUs.
I strongly recommend http://nmon.sourceforge.net/pmwiki.php for such things. I have put my current src rpm here http://www.invoca.ch/pub/packages/nmon/
Simon
--Russell
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Lucian Sent: Wednesday, 13 April 2011 9:41 a.m. To: CentOS mailing list Subject: Re: [CentOS] changing column widths in "top"?
On Tue, Apr 12, 2011 at 10:35 PM, Smithies, Russell Russell.Smithies@agresearch.co.nz wrote:
Thought as much :-( Atop seems to display much better, currently running at 12728% CPU :-
)
Give htop a try as well; it's in EPEL AFAIK. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. ======================================================================= _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, 13 Apr 2011, Simon Matter wrote:
Htop looks interesting and I might try it on one of our other servers but on this one I only see the first 60 CPUs.
I strongly recommend http://nmon.sourceforge.net/pmwiki.php for such things. I have put my current src rpm here http://www.invoca.ch/pub/packages/nmon/
Hi Simon,
Thanks for posting that SRPM. It seems the nmon version in RPMforge lost track of nmon development. They do not appear to report new releases on freshmeat :-/
I have updated the release in RPMforge based on your SRPM.
Thanks again,
On Tue, Apr 12, 2011 at 21:43, Cal Webster cwebster@ec.rr.com wrote:
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
Why not purchase RHN Proxy instead?
On Apr 12, 2011, at 6:09 PM, Christopher J. Buckley wrote:
On Tue, Apr 12, 2011 at 21:43, Cal Webster cwebster@ec.rr.com wrote:
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
Why not purchase RHN Proxy instead?
I would guess that it doesn't pass FIPS, DoD, etc... compliance.
I did a little work in the area and its pretty intense.
- aurf
On 04/12/2011 08:09 PM, Christopher J. Buckley wrote:
On Tue, Apr 12, 2011 at 21:43, Cal Webster cwebster@ec.rr.com wrote:
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
Why not purchase RHN Proxy instead?
Dag has a product called mrepo that can mirror RHEL4 very easily.
On Wed, 2011-04-13 at 06:11 -0500, Johnny Hughes wrote:
On 04/12/2011 08:09 PM, Christopher J. Buckley wrote:
On Tue, Apr 12, 2011 at 21:43, Cal Webster cwebster@ec.rr.com wrote:
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
Why not purchase RHN Proxy instead?
Dag has a product called mrepo that can mirror RHEL4 very easily.
Hmm... wasn't aware of that. I'll take a look - thanks Johnny!
On Wed, 2011-04-13 at 02:09 +0100, Christopher J. Buckley wrote:
On Tue, Apr 12, 2011 at 21:43, Cal Webster cwebster@ec.rr.com wrote:
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
Why not purchase RHN Proxy instead?
Prohibitively expensive for our budget. We'd have to purchase 2 (one external/internet and 1 internal/intranet) and I'd still have to sneakernet the data and sync.