The Batch Login Project

What is BatchLogin?

BatchLogin is a free software (GPL) licensed tool that allows you to manage connections to servers in serial format across diverse environments. It has its limitations, but for the most part, any script or data file can be automatically transferred and executed across a multiple server environment, regardless of the complexity of the "zone" (I.E.: iDMZ, DMZ, etc). It does this in a way that shell scripts and access to servers can easily be managed on a "per admin" basis. See the usage instructions for more on the configuration aspect of the program.

What Can This Thing Do For Me?

Just about anything that can be done with a shell script on a Unix box. In other words, just about anything that is repetitious.

What Are The Current Abilities?

• Data can be transferred via uuencode/uudecode.
• Shell scripts can be created and executed via "here" documents.
• Custom expect programs can be created and executed from a central location (In other words, expect is seamlessly leveraged from one place using BatchLogin to "leverage" the access credentials of the user.

How Does It Work?

The BatchLogin program starts up as a shell script, and prompts the user for the executable (script) to pass, and the password list to run the program against. It then asks for the password for that encrypted list. Using a decryption program that utilizes the blowfish encryption algorithm, it unencrypts the connection data, which is a specially prepared, white space delimited encrypted text file. It feeds this data into an array (this is done in such a way that the password(s) cannot be seen in a process show command or otherwise, for security reasons) and begins by logging into the first server.

Once on the server, it creates the shell script(s) in /tmp, chmod's it(them), and then finally, it executes the program(s). Error codes are checked and if the program exited with anything other than 0 (success), it echos an error string that can be later sifted easily out of the primary log file. Finally, it cleans up after itself by removing the freshly created executable. All data is logged, except for password entries. This gives an administrator a log of the entire process.

Log files created by the session are stored in ~/.batch2/logs. Log files are named for the program run, the password list it ran against, and the process id of the BatchLogin program itself. This way no file will ever have the same name, and the program can run concurrently without fear of over-running a log file.

How Does BatchLogin Run Expect On A Server Where Expect Is Not Loaded?

BatchLogin can run a merged expect script instead of a shell script. The mode of operation is extremely similar to the execution of shell scripts. Normally, BatchLogin uploads the script to be executed and uses the remote machine's shell interpreter. With an expect script, the BatchLogin expect program is altered in 3 areas to allow custom expect code to be executed (this is of course, executed in the same process as the BatchLogin program itself).

This way, things like password changing on the remote node, and other items requiring expect-like functionality, can be executed seamlessly.

The program auto-senses this behavior during the executable selection routine. If a user picks a program that ends with a .exp extension (expect), it pieces together a new BatchLogin program and calls that instead of the stock upload/execute functionality.

What if I don't want to do something to everything in a password list?

Before BatchLogin goes out to terrorize the known Unix universe with some new program, it displays a list of target execution nodes. At this point it says, more or less, "Okay, one last time here, this is what I'm gonna do...". You can easily say n for no, y for yes, or c -- for confirm on each node. In other words, you have expect stop at each node, waiting for confirmation.

What Prompted The Creation Of This Program?

BatchLogin was concieved to address a complex network environment I was exposed to as part of my job. In this environment, multiple DMZs, different access methodologies and differing technologies prompted me to create a program that would address all of these concerns by virtualizing the login process.

In this environment, simple questions like "How many instances of Web server X are in [a particular group of servers]?" Were not so simple to answer.

You could get to a server here and there, but each group of servers was different, and from an administrative point of view, it was a situation of extreme frustration. Servers in different zones could use one mode of file transport from one place but not to another. Servers in another secure location could only be reached via another secure protocol, but not via the first and so on.

There seemed to be no really easy way to execute anything or transport data across the entire environment. Canned automated system management software was an option for some servers, which would have solved a lot of issues, but that software was managed by another group entirely and only available on half of the servers. Over and over, the same questions were being answered the same way: Things are just different in each environment. Different connection methods, different automation tools.

Complicating matters, another secure environment was added with a totally different transport mechanism. While this was great from a security perspective (I'm a big proponent of security), it was yet another degree of complexity in terms of managing the environment.

Worse, the most simple of audits required somehow checking the entire list of servers, and I was part of a security team that required that all machines be treated more or less alike. I believe it was J. C., however, who pointed out that the production boxes all had one level of connectivity that was more or less consistent.

The idea was an old one. BatchLogin was born from this idea. Essentially, the idea was to use secure term servers (which are very slow) in serial fashion with an automated program.

Batch Login came into being a piece at a time. When a new project needed a patch to some software, and it was going to require a program and a file edit across 70 servers, this program took rough shape. The initial program was written by G. P., and the first file to transport via the "Expect Here Document" method, was an awk script that simply fixed a config file that was part of the configuration.

I took that program, and a week or so later, extended it to handle the term servers in the [group name deleted] server farm. At this point, I had to code around a couple of new term server issues. Some term servers were [section removed]. It all looked fairly good at this point.

Then I attempted to execute something in another environment, and ran into a snag; About 1/3 of the servers there didn't have the same access method. Worse, some of the servers required a different access protocol

At each of these points, the whole configuration concept was extended. And extended. And Extended. It got to be a horrible configuration mess.

BatchLogin 2 was created to undo this configuration madness and document more clearly the connection information -- including password expiration issues -- needed to attach to a server. BatchLogin 2 takes into account a lot of the server and operating system specific quirks that foiled BatchLogin 1. All Unicies are not alike, but they're close enough that this program can leverage some seriously quick wins in our environment.

Why did you use Expect?

It does the job. Because it is free software (free as in freedom, not cost). It is available for most Unices , and it does this kind of interaction (fairly) painlessly. No other language really has an interactive that can deal with input streams and terminal issues like with an API like this, from my experience. It's very focused upon dealing with serial communication data and decision making.

Unfortunately, expect is a real piece of work when it comes to text manipulation, which brings us to:

Why then does this program have a shell component?

It does the job. Because it's free. It comes built into the operating system, and it does things like setup and text manipulation really, really well. No other language really has the flexibility or bang for the buck of the shell from my experience.

Unfortunately, the shell doesn't do things like graphical user interfaces very well (unless you count desktop korn shell, which, I'm sorry to say, is a serious aberration and besides that an unholy marriage of posix compliance and motif API calls. If you think I'm joking, and well, I am somewhat, the fact is that I'm not making this up). The program really needed a Graphical User Interface (GUI) to get to the next level.

Which again, brings us to:

Why then does this program have a Java component?

It does the job. Because it's a somewhat open, flexible language. It is available for most Unicies, and it does things like browsers and graphical interfaces (swing) really, really well. No other language really has the flexibility/portability or neat logo... Okay, that's stretching it.

I put some Java in there because I'm out of my mind.

Seriously, the Java is there so that the keyboard-impaired among you would have a somewhat easier time of launching BatchLogin sessions. The Java, unfortunately is somewhat less easy in the sense of number of lines of code to actual work performed category. I'd say the signal to noise ratio in comparison to the shell is about 30 to 1, and about 10 to one compared to expect.

I'm somewhat biased, so take that with a grain of salt.

The Java interface is Not Done(TM). I haven't focused upon it much more than what you see. The passlist editor is broken at the moment (launching works, however). If someone out there wants to get involved with it, feel free.

What can I do to help?

Find bugs and squash them. Suggest improvements. Write some documentation.