Tuesday, April 30, 2019

How do you run inspec.io on Solaris without killing yourself ??

We are using inspec.io for our post deployment verification / checking strategy. When I evaluated inspec, I really like a few things about it:


  • It had a small toolchain and good support for various platforms - Windows, Redhat, Ubuntu, Mac etc. Easy to install, experiment and implement.
  • It's supermarket checks is like collection of checks done and outsourced by other teams which are open sourced which we can leverage and quickly get working on our own script to do code as governance. 
  • You do your scripts in Ruby. Period.
  • The ability to run locally as well using ssh which is something that I really liked as well. 
We were planning to use inspec as the post deployment verification after deployment as part of our Continuous Delivery strategy. Everything was going along fine, until today. A few things hit us. This target server that we wanted to run the scripts on was a Solaris platform. First warning bell tolls. Sola-whut-again ? Really ? No packages were available for Solaris for inspec on their site. 

So that rules out calling our post deployment checks locally on the server. I mean of course this is not the end. We can try to install inspec on the server using source. Have not tried this, don't know what kinds of misery awaits to take huge chunks of meat from my arm when I reach out to open this door once, but I have a feeling we will have an easy time with this one. At this point too I was thinking ... I might not know enough here but who in their right minds runs a production system on an OS whose very existence instantly puts the whole project into a deep tech dept ?? Put another way, I was at one point in my life, keyword here definitely being "was" impressed with SunOS way back in 2005 back in the days of IpVx watching in awe as my Senior banged out long strings of commands without the help of the tab key and could somehow magically get the commands right every single time while he looked straight ahead and banged them out in blinding speed. Fast forward to 2019, let's just say after all that's happened I have lost equal measure of respect for that senior as well the OS on which he was banging out those commands on. Come on .... who uses SunOS in this day and age ? I don't really like using RedHat when managing servers but RedHat is manna from heaven compared to this rusty old doornail. Thanos ... hand me that glove while I snap this tired old OS out of it's existence in my workplace! The day was getting along, tired and a trying to avoid pushing my blood pressure up any further, I soldiered on for other solutions that we could use.

Installing inspec on the Jenkins server ?


So, then we thought about calling inspec from the build server which is a Jenkins server. So, the plan: Install inspec on the Jenkins server, call the scripts from the Jenkins server and use the "-t ssh:// ..." argument to target the deployment server. Sounds good. Not ideal but it's workable. I don't really like this idea as in order to run it in this fashion, ssh keys has to be maintained in the Jenkins server or some kind of script wizardy has to be imbued in the scripts to make it run correctly. At this stage my first paddle did not look so good, so I decided what is the harm in trying the second paddle ... turns out the second paddle has it's problem as well. It's running an almost ancient version of Windows. I know, I know who in their right minds would run Jenkins on Windows right ? Sigh, for the sake of argument and the readability of this post, believe me, we did question this. Let's just say the server OS choice and installation is out of our control and our control extends as far as being able to configure stuff using Jenkins only. Again we hit the same problem here: There are not packages available for this OS as well. Yes another day in the land of "Dev" on this side of the mountain while "Ops" being on the other continent! So yayy for our second paddle sinking to the murky depths of the river. 

So what now ?

The way I look at it, we are left with a few choices now. All unknowns ... great! 

  1. Try to bash my skull in and install inspec on Solaris. There was one measly comment on SO when someone asked this question pointing to some Chef scripts. That's all ! Confidence level plummeted to the core of the earth after seeing this. The usually boisterous SO was strangely quiet this time. 
  2. Try to install all of our post deployment scripts on an external RedHat server and call them from there. The question here then becomes how the heck to you capture the status of the checks ? Is this even possible ?
  3. Spin up a docker instance in Jenkins and call the scripts from within the docker from the Jenkins server ? I really don't know this one and I have not tried it. 
I am reaching out to all those 48 people who read this blog if you guys have ever tried or better yet succeeded in using inspec on your Solaris boxes before, please find it in the kindness of your hearts to share in the comments section on how you did it to benefit the tired writer of this blog as well as the others who might one day stumble upon this blog post. Cheers.

1 comment:

68xo3omrsg said...

Skip welding helps avoid metal distortion and warping, often attributable to uneven warmth distribution. Often, welders just try to modify the weld axis to seem flat or horizontal for higher convenience. The approach remains some of the used welding methods in industries. It has a broad scope of application, appropriate for both ferrous Ted Hose Compression Stockings and non-ferrous metals. Also, it's effective and environment friendly for welding pipes and tubes, repairs of air flow and air-con methods, etc. As the name suggests, laser and electron beam welding makes use of lasers and electron beams as the warmth source to fuse and be part of items of metals.