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.
Comments
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`