Comparing 2 Systems Using Machinery | SUSE Communities

Comparing 2 Systems Using Machinery


Recently I was faced with a bit of a predicament where the ability of comparing two systems had the potential of providing needed insights into a problem I was encountering. Well, what better way to do this than to dig into the SUSE toolbox and reach for the machinery tool, read the documentation, get my hands dirty and see what happens next.

I have to admit that I am not the best reader of documentation and my ability to follow instructions, well lets just say is not necessarily top notch. Anyway, in the Machinery documentation I quickly found what I was looking for:

machinery inspect HOSTNAME1
machinery inspect HOSTNAME2
machinery compare HOSTNAME1 HOSTNAME2

Easy enough, but what if I have two systems on two networks and never the two shall meet? Well the answer also appears obvious, connect a machine that can connect to both networks to one of the networks then run

machinery inspect HOSTNAME1

disconnect from network A and connect to network B and run

machinery inspect HOSTNAME2

disconnect from network B and the machine that was used to inspect both systems will have the data machinery needs to run

machinery compare HOSTNAME1 HOSTNAME2

All fair and easy enough, but that doesn’t really meet the “never the two shall meet” requirement as one can obviously play tricks on the central machine to make the other two hosts meet after all, ouch and certainly a good way to get into trouble.

Also what if the hosts are somewhere far far away, as in a public cloud? Or root login, i.e. root@HOSTNAME, is not enabled or setup? Further what if the hosts use different ssh keys for user login?

Questions, questions, questions……

At present machinery only takes the users default key into consideration when trying to connect to a remote host for any type of action. This implies that one either needs to inject one’s default key into the root/.ssh/authorized_keys file on the target system(s), which may not be desirable, or one has to set things up locally such that machinery picks up some other private key as the “default” key. If remote root login is completely disabled on the target machine than that setting has to be changed temporarily.

None of these inconveniences are insurmountable barriers. However, they do constitute potential for forgetting to undo a changed setting or making some kind of other error that might have undesirable side effects. Thus, having another way that makes the comparison with machinery possible without having to fiddle with the machine configuration of the machine we are trying to inspect is a good thing. And the comparison of two systems with machinery is awesome and provides a lot of information that other wise is tedious to collect and collate.

Here is how to go about it:

Log into each machine that needs inspection and become root. Then on each machine run

machinery inspect -n MY_MACHINE_X localhost

where MY_MACHINE_X should be replaced with an appropriate name that helps you remember the origin of the configuration later. Once the analysis is complete machinery has stored the results of the inspection in ~/.machinery/MY_MACHINE_X. This is easy enough to bundle up,

cd ~/.machinery
tar -cjf MY_MACHINE_X.tar.bz2 MY_MACHINE_X

With a tarball of the analyzed system(s) in hand transportation to another system is easy. For completely disconnected systems a USB stick or optical media will come in handy. On any machine with machinery installed extract the tarball(s) to the ~/.machinery directory.

tar -C ~/.machinery -xjf MY_MACHINE_X.tar.bz2

and voila now the comparison can be completed as advertised

machinery compare MY_MACHINE_X MY_MACHINE_Y

Machinery is cool and gaining new features all the time. It is part of SLES 12 and delivered in the Advanced Systems Management Module. Check it out.

(Visited 1 times, 1 visits today)


  • Thanks for the post Robert and for your feedback. You’ll be happy to know we’ve added support to specify the ssh key as an option of the inspect command.

    `machinery inspect –ssh-identity-file HOST_NAME`

  • Leave a Reply

    Your email address will not be published.