Configuration Engines for Unix

As a system administrator, there is one problem that is persistent. Standardizing and keeping track of configuration changes.

Standardizing begins with the installation of a system. All major unix brands have their own installation methods. As mainly a Solaris administrator, I'm very familiar with the Jumpstart framework.

Using plain vanilla jumpstart is ok, if no customization in addition to the OS is needed (special configurations/application installation)

For advanced customization, Sun Professional Services UK developed the JET framework. JET is an addition to Jumpstart. The advantage of JET is in its usage of template files. All information about a client to install is kept in one file. The framework provides a simple way to add additional software, make additional software changes.

With JET it is possible to get a host running with all its settings and applications. But,
as soon as there are changes on a specific host, which could affect standardization, those changes have to be propagated towards JET.

A couple of years ago, when we used our own framework on top of Jumpstart, we already had this discussion, about getting changes back to Jumpstart. We never found a real solution to this problem. Sometimes, changes were forgot by human error (lazyness?), or some changes would not fit into the framework.

Fortunatly there are others, that have had the same problem. After googling some time, I found three configuration engines:

While I haven't looked at these tools in detail, all of them are managing configuration files from a central host. Local configuration changes are always initiated from a central host. The new configuration will either be pushed from the central host or pulled from the local host. If somebody changes configuration files locally they will be overwritten. The local configurations can be generated dynamically by rules.

The more I think about it, the right way seems to be to install a plain-vanilla OS, then install additional software packages (the configuration engines support this too), and finally push the configuration to the host.

This would make it simple to reinstall or upgrading the OS on a host. Jumpstart could be used in a plain-vanilla configuration, with only needing the configuration engine to be installed.

I will certainly further investigate the tools above.

Comments

Anonymous said…
Can anyone recommend the best Managed Service tool for a small IT service company like mine? Does anyone use Kaseya.com or GFI.com? How do they compare to these guys I found recently: N-able N-central remote pc software
? What is your best take in cost vs performance among those three? I need a good advice please... Thanks in advance!
December 20, 2009 at 12:41 AM
Post a Comment

Popular posts from this blog

SLOG Latency

Image
After reading Brendan's newest blog entry, I was curious about what kind of slog latency we can see for our data migration load. To remind you, only synchronous writes go into the slog SSD devices. As this is a migration running, we can see mostly NFS write operations: In our configuration the SSD slog is mirrored (HDD4 and HDD8). Hence the same number of IOPS: The next picture shows us the latency for our SDD SLOG Device HDD 4. We can see here that latencies start at 79 us and are mostly under 200 us. There are some outliers, but approx. 95% are under 500 us: This matches quite well with the values Brendan blogged about (137-181 us), which includes NFSv3 latency. For reference (no picture here), we can see latencies of about 170-500 us mostly for NFSv4. By the way. SLOG Devices are mostly one way devices, as shown here. Only if things go really bad, they are read from...
Read more

Heating up the Data Pipeline (Part 1)

Image
Pre-Processing Data I often hear the question from our customers, how data can be transformed prior to indexing in Splunk. Damien from  Baboonbones  has done a tremendous job in creating add-ons   providing custom inputs for Splunk. Most of his custom inputs provide the means to pre-process data by allowing custom event handlers to be written. Sometimes you still want to pre-process data that gets collected from Splunk's standard input types, like file monitors, Windows EventLogs, scripted inputs etc. Also, not everyone is capable of writing custom event handlers. A requirement these customers have, is that they have rolled out a large number of Splunk Universal Forwarders and they do not want to install another agent. To summarize, the solution capable of pre-processing data, should be easy to use, be easily integrated and be build on top of their existing architecture. How to plumb Splunk Pipelines Splunk has its own fittings to connect a Universal Forwar
Read more

Heating up the Data Pipeline (Part 2)

Image
In Part 1 we went through how to route events from Splunk to a 3rd party system without losing metadata. Now I'll show you how events can be transformed using Apache NiFi and be sent back to Splunk into the  HTTP Event Collector . Note: The following is not a step-by-step documentation. To learn how to use Apache NiFi you should read the G etting Started Guide . Simple Pass-Through Flow As a first exercise we will create a simple flow, that only passes data through NiFi, without applying any complex transformations. The following picture shows a high-level NiFi flow, that receives events in our custom uncooked event format with a TCP listener, then sends the data further into a transformation "black box" (aka Processor Group), which emits events in a format, that can be ingested into a Splunk HTTP Event Collector input. Apache Nifi currently provides a rapidly growing number of processors (currently 266), which can be used for data ingestion, transfo
Read more