Batch Login Documentation
Who should read this document?
This document is aimed at administrators, engineers and users of Unix or
Linux servers. It introduces a powerful automation tool that attempts to
ease the difficulty of complex environments from the perspective of
different connection protocols, zones (DMZs) and methods.
It is not for non-Unix capable administrators or people that do not
understand the fundamentals of automation and command-line access to Unix-like
What is the purpose of this document?
This documentation describes two programs:
Batch Login Version 2 (bl2) and Batch Login Terminal (blt2).
These programs are written in the Korn shell programming language,
Java, bash and expect.
This document refers to the different languages at times in an
effort to help new users adapt BatchLogin to their purposes.
What is the scope of this document?
This is an overview document, aimed at introducing BatchLogin to the
uninitiated. Where possible, it points to other documentation
that may serve the needs of the moment.
- Frequently asked questions.
- Getting started and usage instructions.
- How to configure password lists (passlists).
- How to configure the initial startup file (bltrc).
- Minimal Cyber-ark command line utility help.
- Log directory structure and encryption.
- File transfer methods and technical details.
Introducing Batch Login
BatchLogin is a program that aids in running tasks across multiple
groups of servers. It does this by allowing a user to maintain groups
of programs and password lists, leveraging the connectivity of the list
against the automation provided by the scripts. It depends upon users who
understand simple shell scripting and typical authentication methods
utilized by command line access to Unix servers.
This program is specifically geared to address the complexity of the large,
diverse environments, but can be utilized in any environment where multiple
servers are employed.
Often, in large enterprise-class environments, servers are configured in
a multitude of ways with varying connection methods to each server.
By eliminating the typical methods of file transport (ftp/scp/nfs) and
concentrating on a simple network connection (ssh/telnet) to create and
run automation, BatchLogin simplifies administration by allowing a group
of servers that are not alike to be treated as such.
BatchLogin gains its producivity edge by eliminating this portion of the
solution from the worry of the end user or administrator. Often, questions
like "I can't ftp/scp/nfs transport the file from server X" go away.
BatchLogin does this by creating programs and data utilizing simple
Unix commands through a shell connection.
All an administrator has to do is create a program and the rest is
"taken care of" by BatchLogin.
The BatchLogin program depends upon a user maintaining a directory structure
in their home directory called ".batch2". Under this directory, 4 different
subdirectories can be found:
Programs in the scripts directory are small shell and expect scripts
that are to be transported and/or run on the servers. There are two types
of programs: scripts (run by the default shell spawned) and .exp scripts.
Files that end in .exp are merged into the BatchLogin program and run in
the expect interpretor on the starting machine. This is to allow for
interactive expect sessions on machines that do not have expect loaded
(This is one of the more powerful features of BatchLogin).
Files in this directory typically end in two different extensions: .blf
(it stands for blowfish -or- batch login file) and .txt .
- BLF files.
These are blowfish encoded password lists.
The BatchLogin.crypt program maintains these and is fairly menu
driven, although switches for encoding and decoding make some
Care is taken to prevent passwords from appearing in scripts or in
process show commands. The user is expected to understand these
limitations if advanced expect automation is attempted.
- TXT files.
Text files are not encoded (plain text, in other
words). Files that end in _group.txt are sub-groupings that
reference servers in the encoded files. Utilizing this convention,
a user can have a master password list and reference a sub-group
inside the list. This allows a master password list to be easily
maintained while separately keeping an overlapping grouping
of servers. The BatchLogin.crypt program looks for .txt files
- BAK files.
These are created when the BatchLogin.crypt program
does an edit on an existing .blf file. It is possible to edit an
encrypted file with the batchlogin.crypt EDIT feature. If the file
is updated, a backup file is created (usually .enc.bak).
The tmp directory simply houses files that batchlogin creates upon the fly.
For forensic reasons, if a session gets killed or errors, the temporary
expect script that failed may be found here. This directory may need
regular cleaning for this reason.
Finally, the "logs" directory contains a log pertaining to every
session that is executed. The process id is also embedded into the log
file name, preventing overlapping file names.
All text that scrolls during a session is logged, so that a user has
a concrete diary that can be examined, after the fact, of any session
When batchlogin is called for the first time, this directory structure
is created automatically. If the user does not have a password store
(likely), the batchlogin program offers to start a batchlogin.crypt session,
which allows a user to easily create a passlist store for execution.
Note that scripts are not created in the same fashion. If a user does
not know how to create a script, it's likely that they shouldn't be using
batchlogin in the first place.
What can batchlogin do?
Just about anything that can be done from a command line interface can be
automated with this program. It can transfer data (sluggishly) directly
through terminal sessions with uuencode/uudecode.
It's a great problem solver for a diverse enterprise-class environments.
For example, say you need to find all servers that are running a certain piece
of software. One option is to log into each one individually, the other
might be to schedule a process through some sort of existing enterprise-class
automation tool, such as CA-Unicenter or IBM Tivoli. Or, you could
write a quick program and fire it off using batchlogin. In the third case, the
output is logged, and the results more or less immediate, and you have the
ability to interact if needed.
What are the limitations?
Mainly (at the moment) file transport speed.
While it can easily transport a small shell script, it's a bad idea (TM) to
transport large files across the network over a (potentially) 9600 baud
console terminal session (as a worst-case example).
That's the main limitation. Fairly reasonable
(say several megabyte) tar archives can easily be passed in reasonable (say
2 to 3 minutes) per server, over a fast ssh network connection. Telnet
sessions are much slower, but functional. Keep hands and feet away.
It also counts upon the user being somewhat skilled in shell scripting, and
it depends upon the administrator being aware of connection protocols and
passwords for the machines in question. Finally, it's not an end-all for
For all of these limitations, it's a great 80/20 solution.
Batch Login Terminal
Batch Login Terminal (BLT) is a variation on the batchlogin process. It uses
the same password store as batchlogin, but leverages it to do single
sessions on remote Unix servers.
BLT came into being after batchlogin. Watch anyone with a password list,
gaining access to a set of servers, and you'll catch part of the reason
the program was created. Users have an excel spreadsheets (oh no) or a
Cyber-ark session open. They look up a particular server, cut the password
for root out of it, and paste it into a terminal program of some kind.
This entire interaction is painstaking and chock full of ways to make an
easy mistake (That wasn't the server I wanted, that wasn't the right terminal
window, the cut was missed, etc, etc, etc). It was obvious, when I started
using the encrypted output of the program the same way, that a simple
shortcut could be engineered -- one where the password on the list would
be utilized to decrypt the data, and the access would automatically leverage
out of that data to give me a login on the box.
BLT (Batch Login Terminal) was born.
The main syntax of BLT is: blt [server]. BLT asks for the users' password
that is used to decrypt the data, and batchlogin is spawned either as a
sub process, or in a terminal session. It's fired in a special mode that
simply loops through the list, looking for the matching server name.
Once found, it uses the login data to log onto the server.
BLT uses a configuration file in the users' .batch2 directory called the
bltrc . The file looks something like this:
# Written by /opt/fericyde/bl2/batchlogin.sh on Mon Oct 6 15:15:29 EDT 2003
When a user first starts blt2, it checks for the existence of this file,
and if it does not exist, it walks the user through creation of a default
bltrc. It finishes by writing the file. Note that by customizing the
SCRIPT parameter (in this case, it calls SHELL.exp), a user may set things
like default environment items that won't effect other users on the host.
For example, by setting and exporting PS1 in the SHELL.exp, a user would
be able to have their prompt be something other than the machine default
-- and they would see this on any machine called with blt.
The change would not be seen by other users, since the
customization is done without altering the machines' default .profile.
Utilizing this and other tricks, such as the alias command, automation can be
leveraged to make logging into differently configured Unix boxes much less
The CTLFILE parameter controls the default password list that will be
scanned for a users' environment. Attempting to log into servers where
no password entry exists will result in an error. BLT is not meant to
replace the lower connection methods of secure shell (or even, heaven
forbid, telnet), but to augment and automate the processes.
BLT2 remembers a connection that is outside of the default password list,
allowing the next connection to that same label to occur without prompting for
the server list again.
The TERMLOGIN variable is used to designate a program that spawns the
terminal itself. Most Unix environments have terminal programs
(xterm, dtterm, rxvt, konsole -- it's a long list). All of these programs
typically take an argument of a program to run after initialization.
A default example using dtterm exists to illustrate how a user can control
this environment as well. Colors, fonts, window titles and so on can be easily
controlled in this manner. To customize, do a man page or a google search
for a man page on your favorite terminal program, and find the options for
these items, code them into a script using the default program for an
example. It's really that simple.
Where do I go from here?
Create a password list, and run the bl2 program. One of the first things
it will do is create the .batch2 directory, and ask to encrypt your
password list. Name your list something that you will easily be able to
identify, give it a password that no one will be able to guess -- the longer
the better. Make it something that won't wear out your keyboard, though.
Next, run the blt2 program and run a test login into your favorite server.
You should find it fairly easy to get around this way.