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.
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.
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 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, the 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 the [name deleted] project needed a patch to its [name deleted] solution, 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 [name deleted] 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.
Unfortunately, expect is a real piece of work when it comes to text manipulation, which brings us to:
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:
I put some Java in there because I'm out of my mind.
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.