Announcing BatchLogin
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:
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. ExamplesThese 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 2005I 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.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_meBLT 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 pserver1If 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 ferrisNote 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 SessionsBut 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 pserver2This 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 UpWe'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.
|
|
| Subject | Topic Starter | Replies | Views | Last Post |
|---|---|---|---|---|
| LET'S SAY I BREAK INTO YOUR HOUSE... | ackmac | 0 | 2,236 | Jul 2, 2007 8:28 PM |
| Bravo - Almost a Useful Tool | SeanConnery315 | 1 | 2,853 | Jun 28, 2005 9:28 AM |
You cannot post until you login.