Machinery 101

After postponing this for way too long, the time has come for me to write few words on what has kept an awsome team at SUSE busy for the last few months. 

Ladies and Gents, without further ado it's my pleasure to introduce you to Machinery

Machinery is a SUSE experiment, driven in a completely agile fashion (If you are interested about our agile methodologies we can also discuss about that, but not now, so please remind me later).
Currently, its feature and implementation are mainly based on the feedback we receive, as we want to learn as much as possible from our users (potential and actual), and their needs.

To quote the homepage:

“The architecture and design of Machinery is based on the idea of a universal system description. This describes the content of a system. The description can be stored, compared to other descriptions, analysed, modified, or used to replicate a system from a description. You can call it "offline systems management".

This pretty much summarizes what machinery is and what aims to be, but as I believe you'd all like to see some practical example before running to install it, I'll be a little more verbose.

The first necessary operation after installing machinery is to run an inspection.
Inspecting a system is what creates a system descriptor, basically the finger print of your system. 

Therefore, let's start by creating one:

> machinery inspect localhost

Surely out there in the wild datacenter inspecting your localhost isn't the most exciting thing to do, but do not fear: It's just an example. Any machine you can ssh into (and exchange keys with) will do.

Just give the right hostname, press enter, sit down and relax.

This bring us to the requirements:

What do I need to setup and install on the machine to inspect?

• See above.

No, you are not blind.

Yes, that’s all the preparation you need.

Just in case this isn't completely clear, no, you don’t need to install anything at all on the machine you’re planning to inspect.

That’s indeed one of the very handy bits of machinery: As the entire inspection relies on standard Unix tools, no client is needed.  Speaking of which, if you want to use sudo in conjunction with another non root user, make sure to have version 1.7.0 installed.

Once you inspected one or more machines over a span of few days, months or years, you might want to have a look at what has been inspected so far:

Next to the hostnames you’ll see a list. Those items are what we call “scopes”.  Each scope can be included or excluded in your inspection. 

What you see above is generated by using a default set of scopes. Depending on what you are looking for some tuning might be beneficial. 

Feel free to have a look and experiment with all the available scopes. If something like “config-files” or “unmanaged-files” catches your attention make sure to tell machinery to extract them for you, and see what happens.

In case you want to inspect a machine more than once, you can rename the profiles: In my example localhost, okashi_base and okashi_updated are the very same machine.

okashi_base: Initial inspection. The machine is freshly installed from DVD,  nothing has been done with it. Machinery has been installed on top of a default installation.

okashi_ updated: This inspection was done after a system update and few changes.

localhost: The every last inspection.   

If you’re still with me, the time has come to see what machinery can do.

> machinery analyze

This command will let you analyse the stored system description.

As I write, there is one supported argument to this command:

config-file-diffs: Generate diffs against the original version of the package for the modified config files

Practically speaking? We have two different options here. Running the command the “Hint” section provided us, or going for the html view (just add --html to that).

Up to you to decide which option suits you best:

But what about comparing two system descriptions, for example my okashi_base and okashi_updated?

As my memory is short, and I really don’t remember any longer what I did to okashi_updated (apart from updating), I’ll let machinery give me a hand:

> machinery compare okashi_base okashi_updated

Ah right, the evil_user tried to setup a world_domination group on my machine and while at it he also deleted my debug repos. Quite an unpleasant user indeed.

Those are just a couple of the things you can do with machinery, but definitely not all:

You can transform system descriptions in AutoYaST profiles or kiwi descriptions, take care of your unmanaged  files (you know, all that stuff you installed from source a while ago that is now lost somewhere on your disk) and much much more.

This is all nicely documented in the machinery man page, so you can have a look for yourself.

If you don’t want to commit to the point of doing a zypper in machinery, you can quench your thirst by looking at the wiki hosted on github.

Last but not least, machinery is a relatively new experiment - we are looking for all the feedback we can get. Do you have ideas, feature requests, suggestions? Let me know, or subscribe to the mailing list .

Would you like to contribute or expand machinery to suit your needs? The github repo awaits.