Have something to say?

Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?

Announcing BatchLogin

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:

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

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

Transfer a script and execute it.

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:

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.

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:

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:

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:

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: