Announcing BatchLogin

Posted by PaulFerris on Jun 28, 2005 5:46 AM
LXer; By Paul (FeriCyde) Ferris

Have you ever found yourself logging into several servers, serial fashion, just to do the same repetitive task and found yourself wondering why the login process itself couldn't be automated? If so, this software may be for you...

At the core of Unix and Linux creativity is the shell, and the name "command-prompt" itself implies a fundamental question.

Let's take a step back and look at something intrinsic to Linux (and enterprise-class operations) -- the command-line prompt. A simplistic thing, the dollar sign, or the pound sign, often customized to show the directory or system name.

It asks a fundamental question: "What do you want me to do?"

The language surrounding this question: It's a prompt -- for a command-line. This language is fundamentally simple, but the activities, contrastingly complex. The question terrifies new users and enthralls experienced Linux and Unix administrators.

It is the seductive thing about Linux systems, yet often the reason why most "Unix/Linux people" are made fun of consistently. Command-lines are perceived as dull -- yet underneath it all they represent the core facet of computing itself. Am I going to do what the computer offers me on a "menu", or am I going to "command" it to do my bidding?

For those of us in the know, that have been using computers for over a decade in extremely complex situations, a command-line represents much more. It is at the center of our daily activity. Large amounts of what would amount to impossible problems are solved in just a few keystrokes. In some regards, shell command-lines are complex, but in yet another striking way they represent simple and elegant design. An example: Large mainframe computers to embedded palm devices all look alike to me: They have shell prompts and with that seemingly innocuous thing, they are equal.

Batchlogin's primary unit of "work" so to speak, is this prompt itself, with whatever implied privileges the user brings along. It strives to make connecting to one computer and executing a task almost as easy as connecting to 100 computers and doing the same. It does this by "virtualizing" the steps a user takes to obtain that prompt.

Once there, BatchLogin can do several things with that prompt:

  1. Hand control to the user, allowing them to execute whatever commands are necessary until they need the next connection.


  2. Transfer files (using, believe it or not, uuencode / uudecode).


  3. Transfer a script and execute it.


  4. In advanced expect configuration: Any combination of the above.




It goes without saying that BatchLogin extends the true power of a Unix shell programmer. It also offers new users and seasoned admins alike a novel new way to virtualize connections to multiple machines. It panders to the problems that a user in an mid-size to enterprise class setting faces on a daily basis: Various machines in various zones and states of security: DMZ, legacy systems that only support telnet, machines that have need for strange authentication credentials. For new users on smaller networks, the problem doesn't seem all that hard to deal with.

When you take responsibility for managing 30 machines and higher, the situation can become rather obtuse. The human brain simply wasn't made to store information about dozens of systems (mine wasn't, anyway) with different credential expirations, authentication stores, different root passwords and so on.

Things begins to get even more complex if those machines are on different network segments, behind firewalls or require differing access methods (telnet/ssh). Some of you might be thinking "Oh, I don't have telnet on my network!", and others are nodding their heads silently -- you don't always have a choice to turn off telnet in some legacy driven environments. In those situations, BatchLogin really shines -- you can virtually connect to everything and let the software configuration deal with the facts as they come. A server switched from telnet to ssh at a later date and time does not throw you off -- one configuration change and you're back where you belong.

Batchlogin's strength is to cater to managing the chaos of these situations. It's configuration is encrypted with blowfish, allows for multiple credential sets, password supercession, abstraction of connection and credential protocols (ssh/telnet/su) and it provides a mechanism to abstract these items such that your connection information can be stored separately from the authentication information. This means that all of the hard work that you as an admin may have discovered over time can easily be shared with a new coworker -- without sharing your own passwords. That coworker simply creates one or two personalized configuration files and they have access as granted to the same group of computers.

Finally, once you've got that prompt on that remote machine -- wherever it is -- you can do simple things like transmit a script to execute, run that script and log the results. You can transmit data (using uuencode/uudecode) and even use BatchLogin to give you an interactive prompt. This last feature seems popular with users of large groups of machines where a lot of ad-hoc type of shell execution is needed. It's even possible to maintain aliases and custom environment settings from one location and propagate them each time a login is obtained. For example, I like having my vi editor mode set without affecting the .bashrc or .profile on the remote end of the equation. This setting is natural for me but something that pisses off new admins to whom learning vi is the mental equivalent of editor root canal.

At this point, some of you might be asking just where and why BatchLogin came into being, and all I can say is that Open Source/Free Software makes sense to more than just end users; corporations can have extremely good business reasons for joining the team. BatchLogin is such a product. I can tell you that the people it was developed for are a special lot. We'll leave the subject of why this has happened for another day and article. I can lay claim to the creation of the software. The central features came from experience and suggestions from a lot of different people.

All of this adds up to increased productivity for me, as BatchLogin makes my day more efficient. I'm constantly hopping around networks and connecting to server clusters for design and maintenance. BatchLogin makes these sessions as easy to for me to execute as running a script or command-line session on one machine locally. It also maintains my multiple sets of identities with only a small list of passwords. It helps me keep my passwords up to date by making the changeover from one password to the next a breeze.

The only ramp-up time comes from the time spent configuring the program. This time is easily gained back once the syntax is mastered. Speaking of that syntax, BatchLogin has a unique configuration format. Before you leap you need to read the configuration guide. BatchLogin is, of course, released under the terms of the GNU General Public License. If this sounds like something that would help you in your day to day life, I recommend you take the time to Read The Fine Manual (also created by yours truly) and get it working. If you have a network or problems to solve that would benefit from this, the time will be well worth it.

After all, most of my time is spent in shell-land. A GUI to me is only useful for managing multiple shell windows (oh, and I have been known to use the GIMP, but everyone has an Achilles heel). Don't get me wrong, I use office software when I have to -- but probably it probably won't surprise most of you to learn that I prefer straight free-form HTML format using vi over any word processor. To me it's the quickest route to good documentation. A lot of things, actually, have really good text counter-parts that with a little knowledge are hands above slogging GUI interferences.

The shell to me is the sweet-spot in the efficiency curve. For infrastructure work, it can't be beat. If you have Linux as the foundation and the shell as the steering mechanism, your days will be productive beyond comprehension. BatchLogin, for me, represents a turbocharger in this equation -- it gets me to more shell prompts in a hurry. It lets me run shell scripts regardless of the authentication mechanism involved or location of the machine on the network. It reduces the automation questions to focus upon what needs to be done by taking care of the where and how I'm going to get there to do the work.

Examples

These are small examples being presented here, in both cases only an attachment to 3 servers. Regardless, the picture painted should illustrate the advantages of BatchLogin in short order. It could be 300 servers, because it's all up to the user how many servers are addressed (via configuration) and how the the technology is utilized.

Example 1: SU connection to three servers in serial fashion.

In this small example, a configuration file has been created that describes the connection to three servers. This configuration file looks like this:
# myserver.blf created Fri Feb 25 18:28:31 EST 2005

id: ext: passlist local userpass.blf PASSWORD root: ext: passlist local rootpass.blf PASSWORD

padmin_me: start: ssh adminserver myracf: myracf: padmin: padmin_me: su * prodroot: prodroot:

pserver1_me: start: ssh cluster1 myracf: myracf: pserver1: pserver1_me: su * prodroot: prodroot:

pserver2_me: start: ssh cluster2 myracf: myracf: pserver2: pserver2_me: su * prodroot: prodroot:

I need to deploy an RPM upgrade to the foo_bar system on these servers, so I create a shell script that upgrades this RPM from a known network location over http. Here's that script:
#!/bin/ksh
rpm -Uvh http://updates.mynetwork.corp/rpmupdates/foo_bar-3.0.1-21.i3...
Yeah, it's not going to win the Pulitzer prize, but it will do in this case. The rpm is obviously bogus, but the format is from a real world example. I've changed the names here to protect the innocent. Basically, this is a script that I need to execute across a bunch of servers on my network as root. Being an enterprise setting, however, I want to log in as myself first, switch user to root, and then pull down and install the updated code. The beauty of BatchLogin shines here. These servers could be anywhere on my network -- behind a gateway server in a DMZ -- it doesn't matter.

Why? Because BatchLogin will take care of using the information shown above to login into these servers using my credentials -- then su to root, then transport/create the script and finally execute the script, clean up after itself (delete the script), all the while maintaining a log file of the entire transaction in my logs directory. To execute the transaction, I fire up BatchLogin:

   BatchLogin version 2.1, Copyright (C) 2005 Paul Ferris
   BatchLogin comes with ABSOLUTELY NO WARRANTY; for details select the
   license option from the main menu.  This is free software, and you are
   welcome to redistribute it under certain conditions -- see the license
   license option from the main menu.

1) [ABORT] 5) LASTLOG 9) PW_UPDATE_VARS 13) SHELL.exp 2) PASSLISTS 6) LOGS 10) CYBERARK_MENU 14) cleantemps.sh 3) GUI 7) DEBUG 11) CYBERPORT 15) fixfoo_bar.sh 4) HELP 8) DISPLAY 12) LICENSE Select program option -or- script to execute: 15 1) [ABORT] 2) mycluster.blf 3) yourcluster.blf 4) theircluster.blf 5) someothercluster.blf Select server control list: 2 Enter the password to unlock mycluster.blf : *************
At this point I am presented with options -- do I want to confirm every server as I go? Do I want it to just run onward and so on. BatchLogin will log into the servers, SU to root with the passwords contained in the external encrypted files, transfer the small script and run it. I can use the log viewer later to see the results. It gives me time to do other things with my day -- like check LXer for flame from DinoTrac, for example.

Several things to note here. I can label these servers as I wish. Often, node-names are chosen by different means and they (sometimes) don't make sense in a working context. BatchLogin allows for a concept called "labeling", which means a server can be addressed with whatever name is desired. This means, for example, that I can access the first server in the cluster, as myself (not SU-ing to root) by typing in:

# blt pserver1_me
BLT stands for (among other things) BatchLogin Terminal. BLT will spawn a new shell terminal (providing that my DISPLAY variable is set properly), open a new BatchLogin session and log into the server (cluster1) as myself. It will, of course, prompt for a password before doing this. This password is a password used to encrypt the passwords for my account and configuration information. In other words it's not the actual password used to log into the server.

It is just as simple to log in as root from BatchLogin's perspective -- just address a different label in the encrypted config file:

# blt pserver1
If you're having trouble seeing how this is so, go back and take a close look at the configuration information. The interactive session uses a special script called "SHELL.exp" that allows my configuration (vi editor mode, some weird aliases, my prompt and so on) to follow me around the network without altering .profiles and annoying the piss out of coworkers who, like typical whining lamers, insist that emacs editor mode is superior to vi. Not that I'm biased or anything.

Here's what a typical session looks like, just before it presents me with a prompt:

SCRIPT: SHELL.exp 
SERVERS: the following labels(s): 
================================
cluster1 cluster2 admin
================================
CONTINUE: y=yes n=no c=confirm s=specify  (y/n/c/s) [n]: y
Username used will be ferris

#################################################################### ## BatchLogin Version 2.0.1 ## Logfile /home/ferris/.batch2/logs/2005/06/26/log_2816.log ## Outfile /home/ferris/.batch2/logs/2005/06/26/run_SHELL_mycluster_12816.log ## Script SHELL.exp ## Control mycluster.blf ####################################################################

Checking for passwd on passlist mycluster.blf . Loading authentication array. Authorization file mycluster.blf [ 1 of 3 ] added. Authorization file userpass.blf [ 2 of 3 ] added. Authorization file rootpass.blf [ 3 of 3 ] added. Shell spawn PID=6832 successful. PSERVER1: executing hop 1 of 2 [PSERVER1_ME:] Connecting as user ferris on node cluster1 PSERVER1: executing hop 2 of 2 [PSERVER1:] Switch user to root on node cluster1 Logged in. Label=PSERVER1:
Note that the authorization files userpass.blf and rootpass.blf are encrypted with the same password that mycluster.blf uses -- the configuration file utilizes a special PASSWORD keyword to unlock referenced blowfish-encrypted files with the same password used on the parent. This allows the main information (the password list shown here) to be shared with coworkers -- albeit after an decryption, as the data is never left on disk in an unencrypted state.

Example 2: Multiple Terminal Sessions

But there's more. Now I need to do some fancy footwork that requires a prompt on all three servers at once. I create yet another configuration file (In BatchLogin parlance -- a "group"). BatchLogin group files are created with a simple menu function that prompts for all of the relevant data -- but the files themselves are human-readable. The contents of the cluster_group.txt file look like this:
passlist mycluster.blf
comment Production Cluster Servers
server admin
server pserver1
server pserver2
This grouping could include other blowfish passlists and labels, or even a subset of all of the servers in mycluster.blf -- it's meant to be a simple abstraction method. In this simple example, it's just the "root" labels in the cluster. My goal is to have 3 terminal windows open to three different servers in one "group". In each window, I want to be logged in as myself first, and root as an SU -- and it's a walk in the park. The name of my file (cluster_group.txt) is important, because the blt (BatchLogin Terminal) program auto-senses that I'm referencing a group, and after a password prompt, it does the rest:
# blt cluster
Group:
 Production Cluster Servers
Enter password for mycluster.blf: **********
Upon password entry, BatchLogin opens three separate terminal windows, logs into the three separate servers as myself, then does an SU to root -- and I'm in with all of my preferences, just the way I like them. This saves me all of the connection time, the time remembering obtuse root passwords and all of the password fat-fingering that usually goes on. I either get logged in or I fail to decrypt the configuration information (I am human, after all).

Summing it All Up

We've just scratched the surface. BatchLogin does something called password looping (It can maintain a list of passwords to try -- newest to oldest) and has much more capability than time (or most of your attention span here) permits. If there's enough demand, I'll write about that in a second article -- for now, this is probably enough to whet your appetite. See the end of this article for where to download BatchLogin if you've seen something that looks like it will save you time. I know enough to say that it works well for me.

For me, BatchLogin opens a whole new dimension of ways to get to even more shell prompts in even less time. I hope it gives you the same kind of power and satisfaction.

These shell prompts in conjunction with the multiplexing capability that BatchLogin provides give me an added edge of productivity -- knowledge is power, after all. BatchLogin simply gets me to the point where my knowledge can have the greatest effect in the shortest time and without the hassle of all the stuff in-between. Once the prompt is there, as usual, it asks me that question I so love to hear:

"Paul, what do you want me to do?"

And my mind reels at the possibilities.
Enjoy!
--FeriCyde



Return to the LXer Features

Subject Topic Starter Replies Views Last Post
LET'S SAY I BREAK INTO YOUR HOUSE... ackmac 0 972 Jul 2, 2007 8:28 PM
Bravo - Almost a Useful Tool SeanConnery315 1 1,579 Jun 28, 2005 9:28 AM

You cannot post until you login.

LXer

  Latest Features
Scott Ruecker (Phoenix, U.S.) : Interview With Richard Kenner of AdaCore
Aug 29, 2014

Scott Ruecker (Phoenix, U.S.): LXer Weekly Roundup for 24-Aug-2014
Aug 24, 2014

Carla Schroder: Test Sites for Heartbleed OpenSSL Vulnerability
Apr 09, 2014

penguinist: Better Than a Quad-Head Display: My Adventures with "4K" 2160p and Linux
Mar 31, 2014

Dr Tony Young: Replacing KDE4 with Xfce
Mar 07, 2014

Dr Tony Young: Removing/Disabling The Semantic Deskop in KDE4 Running on openSUSE 13.1 Part 2
Feb 18, 2014

Dr Tony Young: Removing/Disabling The Semantic Deskop in KDE4 (and firing up Thunderbird) Part 1
Feb 08, 2014

Dr Tony Young: KMail Complexity - and a little Patience
Jan 26, 2014

Carla Schroder: Linux Nerd New Year's Resolutions
Dec 29, 2013

Carla Schroder: Fedora 20 Released With New, Newer, and Newest
Dec 17, 2013


View all

  Search Features

Search LXer Features:

[ Copyright © LXer | All times are recorded in Central Daylight Time (CDT) ]

[ Contact Us | Privacy Policy | Terms of Service | About us | rss | Mobile ]

Login