Hello All,
I have been tasked with getting some configuration management system running at work.
We have about 20 web servers running (some virtual and some physical), and we are trying to come up with a tool that will assist setting up new boxes as we bring them online, as well as maintaining existing systems when changes are necessary.
After spending a little bit of time searching around today, I have run across 2 that seem like good options, cfengine and puppet.
Does anyone have any thoughts about either of these tools? Is there definite advantage to using one over the other from your experience? Is there a another tool that I should be evaluating?
On Thu, Aug 26, 2010 at 2:11 PM, Ski Dawg centos@skidawg.org wrote:
Does anyone have any thoughts about either of these tools? Is there definite advantage to using one over the other from your experience? Is there a another tool that I should be evaluating?
There's been some discussion, not too recent:
http://forum.nginx.org/search.php?24,search=puppet+centos+cfengine,author=,p...
2010/8/27 Ski Dawg centos@skidawg.org:
After spending a little bit of time searching around today, I have run across 2 that seem like good options, cfengine and puppet.
Does anyone have any thoughts about either of these tools? Is there definite advantage to using one over the other from your experience? Is there a another tool that I should be evaluating?
have a look at http://www.linux-mag.com/id/7841
my 2 cents bye,
Stefano Sasso wrote:
2010/8/27 Ski Dawg centos@skidawg.org:
After spending a little bit of time searching around today, I have run across 2 that seem like good options, cfengine and puppet.
Does anyone have any thoughts about either of these tools? Is there definite advantage to using one over the other from your experience? Is there a another tool that I should be evaluating?
have a look at http://www.linux-mag.com/id/7841
my 2 cents
Here's another two cents: first part of last year, I was working with Spacewalk, the released version of RedHat's satellite. While I was fighting it tooth and nail, it went from 0.4 to 0.5. With that experience, I'd say *don't* bother about it....
mark "user hostile"
On 27 August 2010 14:41, m.roth@5-cent.us wrote:
Stefano Sasso wrote:
2010/8/27 Ski Dawg centos@skidawg.org:
After spending a little bit of time searching around today, I have run across 2 that seem like good options, cfengine and puppet.
Does anyone have any thoughts about either of these tools? Is there definite advantage to using one over the other from your experience? Is there a another tool that I should be evaluating?
have a look at http://www.linux-mag.com/id/7841
my 2 cents
Here's another two cents: first part of last year, I was working with Spacewalk, the released version of RedHat's satellite. While I was fighting it tooth and nail, it went from 0.4 to 0.5. With that experience, I'd say *don't* bother about it....
mark "user hostile"
Basing your comments on a version 0.4/0.5 that is pretty unfair.
It is now 1.1 and the user mailing list is active for assistance.
I maintain nearly 100 servers that are a mix of virtualised guests, kvm hosts, production systems, dev/qa systems and so on with various different profiles.
It has made my admin life much easier keep track of what updates are due for what and deploying both software and files - or running script son groups of systems.
The only provisos I would put in place right now are that it requires an oracle database at this time and only use it if you are only looking after Redhat based systems... RHEL, Fedora, CentOS, etc ... Solaris support is there but it doesn't have a huge following to help troubleshoot and Debian support is still on its way.
James
On 8/27/2010 9:57 AM, James Hogarth wrote:
On 27 August 2010 14:41,m.roth@5-cent.us wrote:
Stefano Sasso wrote:
2010/8/27 Ski Dawgcentos@skidawg.org:
After spending a little bit of time searching around today, I have run across 2 that seem like good options, cfengine and puppet.
Does anyone have any thoughts about either of these tools? Is there definite advantage to using one over the other from your experience? Is there a another tool that I should be evaluating?
have a look at http://www.linux-mag.com/id/7841
my 2 cents
Here's another two cents: first part of last year, I was working with Spacewalk, the released version of RedHat's satellite. While I was fighting it tooth and nail, it went from 0.4 to 0.5. With that experience, I'd say *don't* bother about it....
mark "user hostile"Basing your comments on a version 0.4/0.5 that is pretty unfair.
It is now 1.1 and the user mailing list is active for assistance.
I maintain nearly 100 servers that are a mix of virtualised guests, kvm hosts, production systems, dev/qa systems and so on with various different profiles.
It has made my admin life much easier keep track of what updates are due for what and deploying both software and files - or running script son groups of systems.
The only provisos I would put in place right now are that it requires an oracle database at this time and only use it if you are only looking after Redhat based systems... RHEL, Fedora, CentOS, etc ... Solaris support is there but it doesn't have a huge following to help troubleshoot and Debian support is still on its way.
cfengine has a bit more cross-platform capability, but note that CentOS supplies a 2.x release where the project has moved on to 3.x with wildly different syntax, and a native windows build is only available in the commercial version.
On Fri, Aug 27, 2010 at 5:15 PM, Les Mikesell lesmikesell@gmail.com wrote:
cfengine has a bit more cross-platform capability, but note that CentOS supplies a 2.x release where the project has moved on to 3.x with wildly different syntax, and a native windows build is only available in the commercial version.
cfengine 2.x will be with us for years to come. It works great, it's easy to deploy, easy to use and has few dependencies.
Cfengine3 is interesting, but I'll wait until Campi an Bauer write the 3rd edition of "Automating Linux and Unix System Administration" ;-) (the $40 I spent on Automating Linux and Unix System Administration, Second Edition by Campi and Bauer have made my life so much easier: thanks guys!).
As to the windows build: no-one prevents you from building it yourself and running it, it is not that difficult: http://blog.zzamboni.org/installing-cfengine-on-windows-7-under-cygwin. You could even (gasp) consider buying the commercial version, Windows shops are used to paying for software anyways ;-)
No experience with puppet, though. I am happy with cfengine already :-)
James Hogarth wrote:
On 27 August 2010 14:41, m.roth@5-cent.us wrote:
Stefano Sasso wrote:
2010/8/27 Ski Dawg centos@skidawg.org:
After spending a little bit of time searching around today, I have run across 2 that seem like good options, cfengine and puppet.
Does anyone have any thoughts about either of these tools? Is there
<snip>
Here's another two cents: first part of last year, I was working with Spacewalk, the released version of RedHat's satellite. While I was fighting it tooth and nail, it went from 0.4 to 0.5. With that experience, I'd say *don't* bother about it....
Basing your comments on a version 0.4/0.5 that is pretty unfair.
Why? The current CentOS kernel isn't anywhere near the latest, nor is a fair bit of other stuff in CentOS 5.5. And there are lots of folks running yr-old releases.
It is now 1.1 and the user mailing list is active for assistance.
I was on the mailing list. Did they ever put the change to the documentation that I sent in, that I found, about the settings required to make Oracle happy to work with it? <snip> mark
Stefano Sasso wrote:
2010/8/27 Ski Dawg centos@skidawg.org:
After spending a little bit of time searching around today, I have run across 2 that seem like good options, cfengine and puppet.
Does anyone have any thoughts about either of these tools? Is there
<snip> >> Here's another two cents: first part of last year, I was working with >> Spacewalk, the released version of RedHat's satellite. While I was >> fighting it tooth and nail, it went from 0.4 to 0.5. With that >> experience, >> I'd say *don't* bother about it....
Thanks to everyone for the replies, and the links to articles for further research. I will definitely continue reading those.
At this time, we are not interested in Spacewalk because of the Oracle db requirement, but I will investigate the other options as well.
Thanks to everyone for the replies, and the links to articles for further research. I will definitely continue reading those.
At this time, we are not interested in Spacewalk because of the Oracle db requirement, but I will investigate the other options as well. -- Doug
Given your numbers given (20 web servers) you can use oracle-xe for the instance on the local box without much issue. My 80 odd systems with CentOS Base, Updates, EPEL, Spacewalk and my own custom repos all in place with full mirrors of upstream take about 2GB of the 4GB allowance of Oracle-XE.
Work is ongoing to switch to postgres... but that probably won't be complete for at least 4-6 months if not longer.
At the end of the day it depends on your requirements - if you want to manage package updates and kickstarts as well or just configuration files. Spacewalk is better for the former but if just files I'd favor puppet,
James
James
On 27/08/2010 19:11, Ski Dawg wrote:
Stefano Sasso wrote:
2010/8/27 Ski Dawgcentos@skidawg.org:
After spending a little bit of time searching around today, I have run across 2 that seem like good options, cfengine and puppet.
Does anyone have any thoughts about either of these tools? Is there
<snip> >> Here's another two cents: first part of last year, I was working with >> Spacewalk, the released version of RedHat's satellite. While I was >> fighting it tooth and nail, it went from 0.4 to 0.5. With that >> experience, >> I'd say *don't* bother about it....
Thanks to everyone for the replies, and the links to articles for further research. I will definitely continue reading those.
At this time, we are not interested in Spacewalk because of the Oracle db requirement, but I will investigate the other options as well.
Have you looked into bcfg2? Of all the options have looked into, it looks like the best for what I want.
My experience with Spacewalk is that is not ready yet and that it takes too much effort to set it up. It will probably be worth it but I can't dedicate the time it would take to set it up.
On Sat, 28 Aug 2010, Gabriel Tabares wrote:
Have you looked into bcfg2? Of all the options have looked into, it looks like the best for what I want.
My experience with Spacewalk is that is not ready yet and that it takes too much effort to set it up. It will probably be worth it but I can't dedicate the time it would take to set it up.
One should also note that it requires the use of the 'free beer' version of Oracle which has space limitations. From my experiments, I think it would top out in the low 100's of boxes (ie, < 500). Course if you have more than that, you probably have an Oracle license anyway.
---------------------------------------------------------------------- Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
Why? The current CentOS kernel isn't anywhere near the latest, nor is a fair bit of other stuff in CentOS 5.5. And there are lots of folks running yr-old releases.
I... I... I don't really know how to answer this one...
Anyone who is running *CentOS* from a year ago is strongly urged to upgrade... they always have been on this list. There have been plenty of bug fixes over the course of the past year in CentOS and it would have to take a very 'special' set of circumstances not to be at the very least on the last point release if not all updates for security and bug reasons.
I think you need to differentiate between a major and minor product release and how to deal with a product under heavy development. Spacewalk does not have branches that get backported fixes - as indeed Redhat backports fixes from current software to the older they ship when appropriate.
If you showed up on the Spacewalk mailing list saying you have a 0.5 instance with X problem the first thing to be said is at least get up to 1.0 as there have been so many bug fixes over a year that it becomes difficult to troubleshoot an issue and any fix found will not be backported to 0.5 but rather released as either a hotfix to the current version or fixed in the next release.
Your comment would be like complaining about the state of say KVM a year ago and refusing to update CentOS to at least 5.5 (if not current) to get the numerous bug fixes that have gone in over that time.
I was on the mailing list. Did they ever put the change to the documentation that I sent in, that I found, about the settings required to make Oracle happy to work with it?
<snip> mark
I did mention a dependency on Oracle. I, and others, followed the instructions on the wiki and got an instance running fine. What did you mention specifically? Looking at the website there are steps to follow for oracle:
https://fedorahosted.org/spacewalk/wiki/OracleXeSetup
Please only comment on stuff you have genuine *current* knowledge of and not something you dabbled in a year ago... technology changes quickly especially in a product under heavy and active development.
James
On 8/27/2010 1:14 PM, James Hogarth wrote:
Please only comment on stuff you have genuine *current* knowledge of and not something you dabbled in a year ago... technology changes quickly especially in a product under heavy and active development.
Are wild changes in the span of a year really something you want to see in a system that is supposed to be managing your configurations for you? And if you accept the fact that technology changes quickly, do you want to install a system that locks you in to one or only a few distributions?
On 27 August 2010 19:30, Les Mikesell lesmikesell@gmail.com wrote:
On 8/27/2010 1:14 PM, James Hogarth wrote:
Please only comment on stuff you have genuine *current* knowledge of and not something you dabbled in a year ago... technology changes quickly especially in a product under heavy and active development.
Are wild changes in the span of a year really something you want to see in a system that is supposed to be managing your configurations for you? And if you accept the fact that technology changes quickly, do you want to install a system that locks you in to one or only a few distributions?
Indeed these are genuine questions that should be asked in the process of evaluating a set of requirements.
For myself we are a heavy CentOS house and will be for at least the foreseeable future - plans are already underway to start testing our apps on RHEL6 beta in preparation for CentOS6.
As for 'wild changes' I personally have no problem using a product under development so long as data is carried forwards with no point of a 'format' change requiring a rebuild of data. At least with an active product suggests made or code contributions get looked at quickly ^^
Once the debian support is in place then as a product it opens up the field very swiftly for distribution changes.... and besides we often see huge changes in the space of just a year as we all know.... look at SPICE, KVM, ext4, btrfs, openjdk to name but a few that either didn't exist a year ago or have improved massively over the course of a year and anyone would be insane to be using releases from that far ago versus currently supported revisions in your preferred OS. Some of these technologies have gone from general talk to production ready and supported by Redhat, Canonical and others over that timespan.
At any rate I stand by my position that in tech if you are going to put an opinion piece out on a mailing list, a blog or another medium it should be relevant to the current situation and not something you tried a year ago and didn't work out great so you advise others to steer clear a year later without checking to see what progress, if any, has been made in that area.
James
On 8/27/2010 1:51 PM, James Hogarth wrote:
At any rate I stand by my position that in tech if you are going to put an opinion piece out on a mailing list, a blog or another medium it should be relevant to the current situation and not something you tried a year ago and didn't work out great so you advise others to steer clear a year later without checking to see what progress, if any, has been made in that area.
Agreed, but a large part of that opinion and one of the most helpful pieces of information for others relates to how stable a project is over a long period of time. Of course it is hard to predict the future, but the past is often a good indicator. If we weren't all interested in stability, we probably wouldn't be subscribed to this particular mail list.
At any rate I stand by my position that in tech if you are going to put an opinion piece out on a mailing list, a blog or another medium it should be relevant to the current situation and not something you tried a year ago and didn't work out great so you advise others to steer clear a year later without checking to see what progress, if any, has been made in that area.
Agreed, but a large part of that opinion and one of the most helpful pieces of information for others relates to how stable a project is over a long period of time. Of course it is hard to predict the future, but the past is often a good indicator. If we weren't all interested in stability, we probably wouldn't be subscribed to this particular mail list.
Agreed - and given the OP has got the info he wanted (and more no doubt!) I think we should let it rest on that good point...
James
James Hogarth wrote:
Why? The current CentOS kernel isn't anywhere near the latest, nor is a fair bit of other stuff in CentOS 5.5. And there are lots of folks running yr-old releases.
I... I... I don't really know how to answer this one...
Anyone who is running *CentOS* from a year ago is strongly urged to upgrade... they always have been on this list. There have been plenty
I agree... but some won't, or can't. I've got someone here who insists on running RHEL 3, because of collaborators around the world who can't upgrade. <snip>
If you showed up on the Spacewalk mailing list saying you have a 0.5 instance with X problem the first thing to be said is at least get up to 1.0 as there have been so many bug fixes over a year that it becomes difficult to troubleshoot an issue and any fix found will not be backported to 0.5 but rather released as either a hotfix to the current version or fixed in the next release.
Fortunately, that was on a previous job, and we have something here that a) doesn't need a d/b, and b) is *nowhere* near as outright hostile to install and configure. I've been burned, badly, and don't care to use it again. <snip>
I was on the mailing list. Did they ever put the change to the documentation that I sent in, that I found, about the settings required to make Oracle happy to work with it?
<snip>
I did mention a dependency on Oracle. I, and others, followed the instructions on the wiki and got an instance running fine. What did you mention specifically? Looking at the website there are steps to follow for oracle:
https://fedorahosted.org/spacewalk/wiki/OracleXeSetup
Please only comment on stuff you have genuine *current* knowledge of and not something you dabbled in a year ago... technology changes quickly especially in a product under heavy and active development.
I didn't "dabble", my manager and VP insisted I get it up asap. And I just went to the page, above, and no, it does *not* mention what I found, which is that I had to go into Oracle admin, and up the memory available to, mmm, I think it was 995M, where the default is only 940M, and that was the *only* way to get around the stop-dead-in-my-tracks problem.
mark
Fair enough - it didn't meet your requirements and you found something better that did :)
My experience is that when managers/VPs start specifying a tech to use as opposed to a problem to solve things tend to get irritating quickly.
I feel very fortunate to be in a company that looks to the future rather than hacking away to hang on to the past...
James
On 8/27/2010 2:17 PM, James Hogarth wrote:
Fair enough - it didn't meet your requirements and you found something better that did :)
My experience is that when managers/VPs start specifying a tech to use as opposed to a problem to solve things tend to get irritating quickly.
I feel very fortunate to be in a company that looks to the future rather than hacking away to hang on to the past...
Keep in mind that next year the work you are doing now will be in the past and they may want to toss it (and the people who did it) for the next new thing. Let us know how that works out for everyone. My experience has been that the companies that hang on to the past do so because they have something worth keeping.
Keep in mind that next year the work you are doing now will be in the past and they may want to toss it (and the people who did it) for the next new thing. Let us know how that works out for everyone. My experience has been that the companies that hang on to the past do so because they have something worth keeping.
Or they don't want to spend money to update infrastructure or are locked into some proprietary dependency...
Heck in a year if our needs change I'll no doubt run a project to replace what I did this year ;)
Having worked in places that are afraid to touch that thing that has run forever and working where I am now I'll take the place that is flexible enough to trial new technologies over struggling to maintain something beyond EOL any day...
James
I haven't seen much mentioned about puppet and though I am not a puppet master (yet) and am really just now getting into using it, I will provide my reason for selecting puppet.
Not having much experience with configuration management tools and after seeing a relatively new service it made sense for me to investigate puppet, thinking that puppet might have learned from the short comings that plagued earlier tools. I liked the large amount of active development that was happening with the project and after I caught Luke Kanies the original author of puppet on an episode of TLLTS discussing it my interest was peeked even further.
It has the ability to integrate with cobbler; something I do currently use, though I haven't gotten that far yet, and even though I am sure other configuration management services could do this as well, the mention of puppet on the cobbler website and documentation on how to use the two together reinforced my continued efforts to explore it.
I am not familiar with cfengine, though I have read some high level discussions regarding it, so I imagine that it supports SSL, but I really liked the fact that puppet supports SSL out of the box with no configuration required.
I installed the puppet server on a Fedora 13 box (I tend to install actively developed services on Fedora), I will be managing CentOS 5.5 and it was installed and up and running in less then 5 min. Installing the puppet client on my CentOS boxes was even quicker.
I suppose some dislike having to learn the ruby syntax that is required for the puppet configuration files, but like any other new venture it is what it is, you just have to learn it.
The documentation on the puppet labs website is decent and has helped me through several configurations I have needed, this plus the few things I mentioned have me content with my decision to use puppet to manage my environment.
Hope this helps a little. David
On 08/27/2010 02:35 PM, Les Mikesell wrote:
On 8/27/2010 2:17 PM, James Hogarth wrote:
Fair enough - it didn't meet your requirements and you found something better that did :)
My experience is that when managers/VPs start specifying a tech to use as opposed to a problem to solve things tend to get irritating quickly.
I feel very fortunate to be in a company that looks to the future rather than hacking away to hang on to the past...
Keep in mind that next year the work you are doing now will be in the past and they may want to toss it (and the people who did it) for the next new thing. Let us know how that works out for everyone. My experience has been that the companies that hang on to the past do so because they have something worth keeping.
-
Dave -
David -
Gabriel Tabares -
James Hogarth -
Jim Wildman -
Les Mikesell -
m.roth＠5-cent.us -
Natxo Asenjo -
Ski Dawg -
Stefano Sasso