A few weeks back I wrote an article Getting started with SaltStack; that article covered Configuration and Package Automation with Saltstack. In Today's article I am going to cover SaltStack's Remote Execution abilities, a feature that I feel Saltstack has implemented better than other automation tools.
Running a command in a State If you remember from the previous article SaltStack's states are permanent configurations. Adding a command in a Salt state is used when you want to have a command that is run after provisioning a server, run every time Salt manages the state of the system or run when certain conditions are true.
Recently I was working on an issue where an application was not retaining the umask setting set in the root users profile or /etc/profile. After looking into the issue a bit it seemed that the application in question only applied the umask setting that was set in /etc/bashrc and would not even accept the values being the applications own start scripts.
After doing a bit of researched I learned a little bit more about what exactly these files do, the differences between them and when they are executed.
In the world of Cloud Servers and Virtual Machines scripting and automation are top priority for any sysadmin. Recently while I was creating a script that logged into another server via SSH to run arbitrary commands, I ran into a brick wall.
$ ssh 192.168.0.169 The authenticity of host '192.168.0.169 (192.168.0.169)' can't be established. ECDSA key fingerprint is 74:39:3b:09:43:57:ea:fb:12:18:45:0e:c6:55:bf:58. Are you sure you want to continue connecting (yes/no)? To anyone who has used SSH long enough the above message should look familiar.
Are you tired of trying to memorize tons of passwords on different systems? Or do you simply want to have a faceless user SSH between two systems without being asked for a password? Well you are in luck because today we will be covering SSH keys.
SSH Servers have the ability to authenticate users using public/private keys. In the case of pass-phrase less keys this allows users to ssh from one system to another without typing a password.
Recently I have been playing with the Global Parallel File System, which is a clustered file system from IBM. When setting up a cluster you can configure GPFS to utilize SSH/SCP to send administrative tasks to the other nodes in the cluster.
The problem I ran into was that in my environment I do not run SSH over port 22 (for various reasons I wont get into). Needless to say once I configured SSH to listen on an alternate port GPFS stopped working.
While it is getting more common for companies to allow their IT staff to choose their own OS not every company allows this. In fact most companies require their IT staff to use Windows, as Windows has historically been the dominate OS for the business world. While I personally believe it is easier to administer Linux/Unix servers using a Linux desktop this doesn't mean that I get to be the exception to the rule; sometimes I have had to use a Windows desktop.
One of the coolest uses of ssh I've had to use recently is the X11 forwarding. In my case I had a java application that opened up a GUI but I had to run it from a server that did not have a running graphical user environment as it was in init state 3.
The answer is far simpler than one would initially think. With the ssh client you are able to connect to a server and enable X11 forwarding.