6 ms·

The main point of the article is true. All configuration management software is lacking in some regard. However, the article ignores the fact that configuration

by shaggy 15y ago

The main point of the article is true. All configuration management software is lacking in some regard. However, the article ignores the fact that configuration management systems are focused on a much wider swath of OS support than RHEL and Debian based distributions. Most enterprises (and especially large enterprises) have Linux, Solaris, AIX, HP-UX and Windows that they need to manage. Managing more than one solution for configuration management solution is antithetical to a well run infrastructure. The real problem with configuration management solutions is managing the solutions themselves. Most of the widely deployed solutions are based on DSLs making the learning curve steep and the chance for error high. The commercial options (CFengine NOVA, chef and puppet) all offer GUI based management consoles but the solutions are expensive for all and often prohibitively so for smaller shops. It's a crowded space but there is still room for a well designed, easy to deploy, easy to manage commercial solution that solves these problems.

kev009 15y ago
Another commenter here also pointed out Windows and niche Unices. That's probably more the domain of IBM and CA. Cfengine can do it if you want to put in the time. But how often does Cfengine come up on this site? It's too barren by default. A promise lib that targets the EL/Debian majority shop and makes opinions and assumptions based on the smaller problem set would be welcome by many. Even if Windows is in play, it's probably self-contained in most shops. Let the big timers support themselves if you want to unify niche commercial OS.
- atsaloli 15y ago
  Thanks for bringing up this important area, Kevin. This is a relatively new and growing field and there is definitely lots of room for improvement. I was surprised you found "severe incompatibilities" between point releases of CFEngine 3 -- I've been using 3 since 3.0.2 and have not seen severe incompatibilities. What did you run into? Regarding CFEngine being barren by default -- I know what you mean. CFEngine is a configuration management FRAMEWORK. The CFEngine standard library is an example of using that framework. It does take a bit of work to use all this, but once you do, the benefits are enormous (labor and sanity saving, increased efficiency as a sysadmin, more power over the systems, infrastructure as code, etc. -- all the usual benefits of configuration management, plus the added benefits peculiar to CFEngine - support for over thirty operating systems, small memory and power footprint, very few dependencies and the resulting ability to run on a very wide range of hardware, from embedded to supercomputer). Is there something you want to do with CFEngine that is not in the standard library? (Please give some concrete examples.) Maybe I could help with that. I do have over 150 practical examples of using CFEngine 3 at http://www.verticalsysadmin.com/cfengine/cfengine_examples.tar http://www.verticalsysadmin.com/cfengine/cfengine_examples.t... and they are all RHEL/CentOS based. FYI, CFEngine, Inc. grew this year from 4 to 30 staff and are still hiring. I think you're going to be seeing a lot from CFEngine the company in the near future. Incidentally, I'm looking for CFEngine professional service engineers to help with CFEngine 3 deployments. Details at http://www.verticalsysadmin.com/pse.htm http://www.verticalsysadmin.com/pse.htm I'll be training on CFEngine 3 in Palo Alto on January 25-27 (http://cfengine3.eventbrite.com http://cfengine3.eventbrite.com), and in Los Angeles on Feb 20-22 (http://cfengine.eventbrite.com http://cfengine.eventbrite.com). Email me for a 10% off coupon. I also run a free 2 hour webinar "Getting Started with CFEngine 3" - email me and I'll let notify you of the next one. aleksey at verticalsysadmin dot com Configuration Management is an actively growing field right now, all the major players are doing a lot to improve their products. It's going to get better, stick with it.
  - kev009 15y ago
    I believe I started using a 3.x.1 distro package and on the other end a 3.x.5 package if memory serves (this was in April). The minor versions contained tons additional new features. If there's something 3.x.y can't do that 3.x.y+1 can't do, the middle number NEEDS to be incremented to signify this change. The promises from the later tail number would not work on the older one. Some things I think would be useful to ease Cfenfgine adoption: * .conf.example files that can be jockeyed around quickly to produce useful working samples within 15 minutes. Specific areas for the above include: installing a file from cfmaster to a host, installing packages using the native package manager, starting services using the native service manager * Reading about promise theory and Cfengine lingo is neat and all but if I'm not convinced of the benefits and have it running in 15 minutes, the install process/doc is flawed. Fixing this will get you much more market share. * All of the above doesn't mean Cfengine can't handle n-th order complexity and diversity. Instead what I am suggesting is to make it very easy to try on in the simplest cases, and wear well with experience and age in tougher environments. * Some simple config enumerator scripts. Run yum, dpkg, etc and get a list of all packages. Output this into a config file that the user can edit and put into use right away. I'll dig through your Cfengine examples some time and see how it's going.
    - atsaloli 15y ago
      Thanks for your thoughtful reply, Kevin. I agree with you on the version numbering, on incrementing the middle number for bigger changes. I'll talk to the CFEngine, Inc. guys about bundling my example config files into the package, having simple practical workable examples (that one can adopt to ones own use) would go a long way in helping people get started. Agreed we need to improve the whole "up and off the runway" process. Thanks again for your constructive feedback. If you have any suggestions on my Cfengine example collection, drop me a line - aleksey at verticalsysadmin dot com Best, Aleksey
  - shaggy 15y ago
    To be "that guy" this is not at all a new area. CFengine is almost 20 years old and certainly wasn't the first bit of software to try and solve the problem. There is definitely a lot of room for improvement.
- shaggy 15y ago
  There is probably a need for a more targeted promise lib for EL/Debian that does some of the simple stuff out of the box. However, it's a slippery slope because part of the problem with the configuration management domain is the mindset you exhibit. Windows and other Unix operating systems are not niches. Excluding operating systems because you don't see them being used or deployed will result in an ever growing list of small point solutions that don't solve very many problems. Then as soon as you outgrow that solution you have a larger problem on your hands. It's no harder to manage, say, Solaris using CFengine than it is to manage EL/Debian. You're right that CFengine isn't mentioned here very often and that's most likely because it's not new web 2.0 startup-o-fied ruby fanboi cool. It's been around since 1993. So in almost 20 years the problem of configuration management hasn't been solved in a satisfactory manner. It's a very difficult problem to solve.

by shaggy 15y ago

kev009 15y ago

Another commenter here also pointed out Windows and niche Unices. That's probably more the domain of IBM and CA. Cfengine can do it if you want to put in the time. But how often does Cfengine come up on this site? It's too barren by default. A promise lib that targets the EL/Debian majority shop and makes opinions and assumptions based on the smaller problem set would be welcome by many. Even if Windows is in play, it's probably self-contained in most shops. Let the big timers support themselves if you want to unify niche commercial OS.

atsaloli 15y ago
Thanks for bringing up this important area, Kevin. This is a relatively new and growing field and there is definitely lots of room for improvement. I was surprised you found "severe incompatibilities" between point releases of CFEngine 3 -- I've been using 3 since 3.0.2 and have not seen severe incompatibilities. What did you run into? Regarding CFEngine being barren by default -- I know what you mean. CFEngine is a configuration management FRAMEWORK. The CFEngine standard library is an example of using that framework. It does take a bit of work to use all this, but once you do, the benefits are enormous (labor and sanity saving, increased efficiency as a sysadmin, more power over the systems, infrastructure as code, etc. -- all the usual benefits of configuration management, plus the added benefits peculiar to CFEngine - support for over thirty operating systems, small memory and power footprint, very few dependencies and the resulting ability to run on a very wide range of hardware, from embedded to supercomputer). Is there something you want to do with CFEngine that is not in the standard library? (Please give some concrete examples.) Maybe I could help with that. I do have over 150 practical examples of using CFEngine 3 at http://www.verticalsysadmin.com/cfengine/cfengine_examples.tar http://www.verticalsysadmin.com/cfengine/cfengine_examples.t... and they are all RHEL/CentOS based. FYI, CFEngine, Inc. grew this year from 4 to 30 staff and are still hiring. I think you're going to be seeing a lot from CFEngine the company in the near future. Incidentally, I'm looking for CFEngine professional service engineers to help with CFEngine 3 deployments. Details at http://www.verticalsysadmin.com/pse.htm http://www.verticalsysadmin.com/pse.htm I'll be training on CFEngine 3 in Palo Alto on January 25-27 (http://cfengine3.eventbrite.com http://cfengine3.eventbrite.com), and in Los Angeles on Feb 20-22 (http://cfengine.eventbrite.com http://cfengine.eventbrite.com). Email me for a 10% off coupon. I also run a free 2 hour webinar "Getting Started with CFEngine 3" - email me and I'll let notify you of the next one. aleksey at verticalsysadmin dot com Configuration Management is an actively growing field right now, all the major players are doing a lot to improve their products. It's going to get better, stick with it.
- kev009 15y ago
  I believe I started using a 3.x.1 distro package and on the other end a 3.x.5 package if memory serves (this was in April). The minor versions contained tons additional new features. If there's something 3.x.y can't do that 3.x.y+1 can't do, the middle number NEEDS to be incremented to signify this change. The promises from the later tail number would not work on the older one. Some things I think would be useful to ease Cfenfgine adoption: * .conf.example files that can be jockeyed around quickly to produce useful working samples within 15 minutes. Specific areas for the above include: installing a file from cfmaster to a host, installing packages using the native package manager, starting services using the native service manager * Reading about promise theory and Cfengine lingo is neat and all but if I'm not convinced of the benefits and have it running in 15 minutes, the install process/doc is flawed. Fixing this will get you much more market share. * All of the above doesn't mean Cfengine can't handle n-th order complexity and diversity. Instead what I am suggesting is to make it very easy to try on in the simplest cases, and wear well with experience and age in tougher environments. * Some simple config enumerator scripts. Run yum, dpkg, etc and get a list of all packages. Output this into a config file that the user can edit and put into use right away. I'll dig through your Cfengine examples some time and see how it's going.
  - atsaloli 15y ago
    Thanks for your thoughtful reply, Kevin. I agree with you on the version numbering, on incrementing the middle number for bigger changes. I'll talk to the CFEngine, Inc. guys about bundling my example config files into the package, having simple practical workable examples (that one can adopt to ones own use) would go a long way in helping people get started. Agreed we need to improve the whole "up and off the runway" process. Thanks again for your constructive feedback. If you have any suggestions on my Cfengine example collection, drop me a line - aleksey at verticalsysadmin dot com Best, Aleksey
- shaggy 15y ago
  To be "that guy" this is not at all a new area. CFengine is almost 20 years old and certainly wasn't the first bit of software to try and solve the problem. There is definitely a lot of room for improvement.
shaggy 15y ago
There is probably a need for a more targeted promise lib for EL/Debian that does some of the simple stuff out of the box. However, it's a slippery slope because part of the problem with the configuration management domain is the mindset you exhibit. Windows and other Unix operating systems are not niches. Excluding operating systems because you don't see them being used or deployed will result in an ever growing list of small point solutions that don't solve very many problems. Then as soon as you outgrow that solution you have a larger problem on your hands. It's no harder to manage, say, Solaris using CFengine than it is to manage EL/Debian. You're right that CFengine isn't mentioned here very often and that's most likely because it's not new web 2.0 startup-o-fied ruby fanboi cool. It's been around since 1993. So in almost 20 years the problem of configuration management hasn't been solved in a satisfactory manner. It's a very difficult problem to solve.