4 ms·

The nice thing about an approach like this is that you don't actually need to use shell for your scripts - you could use Perl, Python, etc. The point is you ca

by agwa 13y ago

The nice thing about an approach like this is that you don't actually need to use shell for your scripts - you could use Perl, Python, etc. The point is you can just write in whatever scripting language you like/gets the job done and not need to worry about learning a new domain-specific configuration language. Does anyone else here see value in a configuration management system that centers around installing files and running scripts, much like FSS? I'm contributing to, and using in production, a configuration management system that takes this approach. It's a lot more mature than FSS, but unfortunately the primary author isn't ready to open source it yet. If there's some demand for it, maybe I can convince him to hurry up.

sbt 13y ago
This does not manage a server, it provisions a server. The whole point of configuration management software is to bring your software into a desired state from any actual state the server may be in. This rests on the notion that configuration drifts, i.e. for long running services a server gets misconfigured eventually for a variety of reasons. Bottom line, if you are just running a small startup with a few servers and a few people, then by all means use FSS, but eventually you will need real CM.
- agwa 13y ago
  The CM system I'm using "journals" every change it makes to the system, so if you later remove or change a file or script in your CM repository, it undoes the old change. This eliminates virtually all configuration drift, provided you aren't making changes by hand outside of the CM system (which you should never do anyways). This system has been managing about 100 servers and several hundred desktops at a single site since 2009, so the approach does scale. It has some problems that declarative solutions like Puppet solve, but at the same time it solves problems that Puppet/Chef/others have.
  - oftenwrong 13y ago
    Which CM system?
- jamiesonbecker 13y ago
  In the cloud, provisioning a server might be the only management that you do. In fact, arguably, SHOULD do. Servers are now disposable.
stevekemp 13y ago
I use (my own tool) Slaughter for configuring about fifteen servers. The vast majority of configuration changes are: * Upload/update a configuration file, and if it resulted in a change then restarting the affected service. * Append a line to a file, if it is missing. * Search/replace a pattern against a file and do something if that resulted in a change. So yes, add the ability to install/remove a native package (be it a .deb, .rpm, or whatever) and you've got a lot of power. http://www.steve.org.uk/Software/slaughter/ http://www.steve.org.uk/Software/slaughter/

by agwa 13y ago

sbt 13y ago

This does not manage a server, it provisions a server. The whole point of configuration management software is to bring your software into a desired state from any actual state the server may be in. This rests on the notion that configuration drifts, i.e. for long running services a server gets misconfigured eventually for a variety of reasons. Bottom line, if you are just running a small startup with a few servers and a few people, then by all means use FSS, but eventually you will need real CM.

agwa 13y ago
The CM system I'm using "journals" every change it makes to the system, so if you later remove or change a file or script in your CM repository, it undoes the old change. This eliminates virtually all configuration drift, provided you aren't making changes by hand outside of the CM system (which you should never do anyways). This system has been managing about 100 servers and several hundred desktops at a single site since 2009, so the approach does scale. It has some problems that declarative solutions like Puppet solve, but at the same time it solves problems that Puppet/Chef/others have.
- oftenwrong 13y ago
  Which CM system?
jamiesonbecker 13y ago
In the cloud, provisioning a server might be the only management that you do. In fact, arguably, SHOULD do. Servers are now disposable.

stevekemp 13y ago

I use (my own tool) Slaughter for configuring about fifteen servers. The vast majority of configuration changes are: * Upload/update a configuration file, and if it resulted in a change then restarting the affected service. * Append a line to a file, if it is missing. * Search/replace a pattern against a file and do something if that resulted in a change. So yes, add the ability to install/remove a native package (be it a .deb, .rpm, or whatever) and you've got a lot of power. http://www.steve.org.uk/Software/slaughter/ http://www.steve.org.uk/Software/slaughter/