-----------------
MOOTY QUICK HOWTO
-----------------
Sections
--------
- INTRODUCTION
- SOME COMMON TASKS WITH MOOTY
- So what can mooty do for you?
- BELOW IS A QUICK-START GUIDE FOR MOOTY IN A TYPICAL LINUX ENVIRONMENT
- QUICK INSTALLATION AND USE
- SUMMARY
------------
INTRODUCTION
------------
Mooty is a root-level Linux server tool designed for controlling MANY client
machines (up to 1000s) en mass and in parallel. It is a pluggable CLI tool
with built-in capabilities to assist the System Administrator at the command
line. It currently has some SUSE Linux flavoring, but is easily adapted to
other distributions for use in System Administration tasks across multiple
machines.
---------------------------- ----------------------------------------
SOME COMMON TASKS WITH MOOTY DESCRIPTION OF WHAT THE TASK DOES
---------------------------- ----------------------------------------
bash mooty.sh --help ................ View Mooty help even if the controller
script (mooty.sh) is not set as
executable
bash mooty.sh --demo ................ Coming soon! Built-in demo system which
shows how to Mooty from simple
installation to complex solutions
bash mooty.sh --upg ................ Install or upgrade Mooty (or even
"downgrade", if an older version is
called with this option)
Works even if the controller script
(mooty.sh) is not set as executable
Does the following:
1. Copies itself to /root/bin
2. Creates filename links to itself
3. Makes itself executable
4. Automatically creates the
/etc/defcon/mooty.conf default
configuration file (or "defcon"
file), if one does not already
exist, meaning a default config file
is created and thereafter used, if
existent; custom configurations are
NEVER overwritten
---------------------------------
NOTE: Several of the tools in the
Mooty payload now use the
defcon system:
JIC, CQT, Dep_tool, etc
---------------------------------
mooty.sh --uninst ................ Un-installs Mooty, which essentially
means that the controller 1) removes the
/root/bin/[mxs].* links and 2) changes
itself (mooty.sh) to non-executable
[Doesn't touch (ie, leaves the
following elements intact):
- The working directory
(/var/lib/mooty/) in case you have
important data there that you do
not want removed
- The docs directory
(/usr/share/doc/packages/mooty/)
in case you have custom
documentation there that you do
not want removed
- The Mooty defcon file
(/etc/defcon/mooty.conf) in case
you have customized your Mooty
configuration file
- The Power Shell Profile (PWS)
(SUSE: /etc/bash.bashrc.local)
(SysRCD: /etc/bash/bashrc)
(RedHat: n/a)
----------------------------------
NOTE: Although the PWS can be
installed/upgraded/downgraded
along with Mooty, for convenience,
the controller plays nice and does
not delete it at uninstallation.
----------------------------------
m.serial_exec "command;list" ....... Serially executes the command list on
the default list (/var/lib/master.list)
-------------- (Three simple examples) -----------------------------------------
m.serial_exec "init 6" .............. Reboot all machines in the master.list
m.serial_exec "acpi;echo '======'" .. Run "acpi" on all machines in the
master.list file and generate a simple
report about those machines on stdout
(essentially just a simple bash script
on a single line, passed to all the
nodes in the master.list)
m.serial_exec -l my.list "acpi" ..... Show power state on all machines in the
list file "my.list"
--------------------------------------------------------------------------------
m.hyper_exec 'command;list' ....... Executes actions in DISCONNECTED a
manner, or in other words, IN PARALLEL
The command list is a single quoted
command list, separated by semi-colons.
For those that know scripting, this
should be obvious as a simple bash
script, on a single line. Complex
scripts can be put into a "job" file,
deployed to machines, and then executed
en mass, just like any other
command!
-------------- (An example) ----------------------------------------------------
m.hyper_exec 'zypper --non-interactive -y in xosview'
In this example, the SA uses the command,
in conjunction with zypper's
non-interactive options, to install
the xosview package on all the machines
in the master.list. Single quotes are
not REQUIRED, but they keep the bash shell on the controller from expanding the command before sending it to the remote machines
-----------------------------------------
(See steps 8 and 9, below, for deploying
a large file using m.hyper_exec and
Udpcast, for multi-casting)
-----------------------------------------
m.serial_deploy /src/file /dest/file ..This deploys SMALL files and directories
to listed machines; it is fast and
effective, using scp tunnels
m.serial_get /some/generic/file ...... Collects files OF THE SAME NAME, from
master.list machines. They get sorted for
the user on the Mooty server. This is a
great command for collecting small config
backups, and the like.
m.unique_get /some/unique/*.file ..... This command is for collecting files that
are SIMILAR, yet unique, from all the
machines in the master.list. Use it to
collect individual files with similar
extension names, etc.
m.<Tab><Tab> ......................... Show a list of the m.dot commands
available from the command line.
The m.dot commands report the IP address
of the machine for each connection. If
that is too messy, you can use the silent
s.dot commands.
s.<Tab><Tab> ......................... Show a list of the m.dot commands. S.dot
commands are great for running a quick
"visual" report and showing the results
on the console of the controller machine,
without the clutter of each IP address
displaying on the console. These are for
treating any group of computers as a true
Mooty herd, instead of being tied to each
machine (IE, true "cloud" computing).
x.<Tab><Tab> ......................... Show a list of the x.dot commands. X.dot
commands allow you to show X-windows-apps
back through your comm channels back to
the controller machine. These can be run
either in parallel or serially, with
either x.hyper_exec or x.serial_exec,
respectfully.
-----------------------------
SO WHAT CAN MOOTY DO FOR YOU?
-----------------------------
Mooty can save you HOURS of work. For example, it can be used to multi-cast
a very large set of files to client machines in the background. With Mooty,
there is no need to reboot to use additional imaging tools to deploy add-on
files to machines. You can install software, run reports on hardware, etc., all
from a central console, right now. EN MASS. In parallel!
Mooty is easy to use, but you have to start playing with it, to be any good at
using it and taking advantage of its power and flexibility. It leverages the
power and features of existing, common, System Administration tools on Linux
distributions, such as the bash read-line libraries (for tab-completion), bash
history, Linux NOS commands, X-windows applications, etc.
That's just the tip of the iceberg, as far as Mooty's features go.
***
I have already used Mooty to control MS Windows clients, as well.
The intention is to port Mooty to the MS Windows environment as well, though
some non-native components will need to be put in place to allow it to function
correctly. It seems likely that this will be a derivation of the excellent
Cygwin environment, owned and licensed by RedHat. Kudos to the folks that
created such an excellent add-on for the MS Windows environment!
To read about Cygwin and find out about licensing see:
http://www.redhat.com/services/custom/cygwin/
To download and begin using Cygwin on your own MS Windows clients, see:
http://cygwin.com
---------------------------------------------------------------------
BELOW IS A QUICK-START GUIDE FOR MOOTY IN A TYPICAL LINUX ENVIRONMENT
---------------------------------------------------------------------
Some notes on how to quickly start using Mooty.
To use it, you're going to have to get it installed:
If it's not bundled in a software package (RPM, pkg, etc., then the framework
installer script is going to be called something like "mooty.sh". It may look
something like this "mooty.sh-.09.10.22". Either way, it should install roughly
the same, though it will usually be attached as a tarball (or zip file), when it
is not bundled in an RPM. So, if it did not make it through your email
filtering, contact your network administration folks to discuss how to get it.
OK, so a quick set of steps to install and run your first multi-cast, using
Mooty. The following steps should serve as an example of how to install, setup,
and run commands with Mooty, even if you don't have any fancy auto-install
precans for use through Mooty.
--------------------------
Quick Installation and Use
--------------------------
Execute the following numbered commands on supported systems to quickly
install and use Mooty to perform a multi-cast:
0. Extract the tarball (or zip file) using the provided password, if
applicable. This is not necessary if you obtained the Mooty controller
directly from sourceforge.net.
-----------------------------------------------------------------------------
NOTE: Mooty is designed to be installed as a ROOT-LEVEL tool on the control
server (the control server will hereafter be called the "Controller" in
Mooty speak). You will need to be logged in as root to install Mooty
correctly on the Controller.
-----------------------------------------------------------------------------
1. su - (Enter the Controller root password, when prompted.)
2. bash /path/to/mooty.sh --upgrade
(The installer does the following:)
a. Copies the mooty.sh script to /root/bin/mooty.sh and makes it executable.
The destination file is always, /root/bin/mooty.sh, regardless of the
name of the original script. This means that regardless of build name,
the main Mooty Controller script will always be /root/bin/mooty.sh,
unless some other Controller is used (which is WAY more advanced than
this document is intended to be).
b. Creates m.dot, s.do, and x.dot links in /root/bin/ that point right back
to mooty.sh, in that same /root/bin/ directory. There are a lot of link
names there, which are tab-completable, if you are using bash tab
completion. THIS IS INTENDED TO MOOTY HIGHLY USEFUL FOR
HIGH PERFORMANCE ADMINISTRATION (HPA):
- Engineers
- System Administrators
- Consultants
c. If you do not have a DSA ssh key (the default) already created, then the
installer uses ssh-keygen to create a DSA key in the default ~/.ssh
location.
--------------------------------------------------------------------------
NOTE: If you change the Mooty defcon key to RSA, then thereafter Mooty
will check for and create an RSA key instead of DSA, if one does not
exist. This way, you can deploy a custom /etc/defcon/mooty.conf file and
auto-create RSA keys, instead of DSA keys.
--------------------------------------------------------------------------
d. Installs a small filesystem payload that includes the Mooty working
directory, some common distributables like the Power Shell Profile, and
the Just In Case (jic.sh) backup code, and other valuable Mooty framework
elements.
(Payload installs under /var/lib/mooty/)
3. Accept the upgrade or installation of the Power Shell Profile (PWS).
The Mooty installer prompts you to install (or upgrade) the PWS. I suggest
that you do this unless you have some compelling reason not
to. THE REASON: The PWS contains powerful extensions to your standard Bash
shell that not only make it MUCH more powerful and quick by itself, but it
also plugs into the Mooty framework on the Controller, allowing for extreme
HPA capabilities. See the documentation on the Power Shell Profile for
more information.
-----------------------------------------------------------------------------
NOTE: If you have installed the PWS along with Mooty, you can also run "pws"
to see lists of tips, aliases, and functions that are built into your Bash
Shell Profile. The PWS is integrated into Mooty and can be upgraded (and
downgraded) with the Mooty control script (mooty.sh).
-----------------------------------------------------------------------------
4. source /etc/bash.bashrc.local
This adds the PWS settings (variables, aliases and functions) to your
current Bash shell.
5. cd $m
Changes to the /var/lib/mooty/ "working" directory. "m" and "M" are
variables set by the PWS to make it quick to get to the Mooty working
directory on the controller box.
6. m.scan_lan 192.168.1.0
Makes a list of all ssh servers, with DSA or RSA keys, listening on the
192.68.1.0 network (Mooty only supports class C networks, but you can always
manually make your own lists if you want).
-----------------------------------------------------------------------------
NOTE: If you want to change your default network to 192.168.1.0, you can
simply edit the /etc/defcon/mooty.conf file and set the MENV variable to
your desired prefix. The default is "10.0.0", for simplicity.
While you are at it, you can also change the default configuration to scan
for open ssh ports, using either DSA or RSA keys, or both. The default is
to scan for both.
-----------------------------------------------------------------------------
7. mv list.now.* /var/lib/mooty/master.list
The all important master list file! The default behavior for Mooty is to
use the master.list to perform all actions, though one CAN use an
alternative list at any time, using the "-l" option.
Where appropriate, most commands will take the following optional argument:
-l </path/to/a/different/list/file>
This allows you to act on a list OTHER THAN the master list file.
Here's a list of some of the Mooty commands, that take the "-l" option:
m.copy_ids
m.serial_deploy
m.serial_exec
m.serial_get
m.hyper_deploy
m.hyper_exec
m.hyper_get
m.populate_known_hosts
m.unique_get
m.xosview
8. m.populate_known_hosts
Run this before running the next general step "m.copy_ids" to add the ssh
server known keys, from the master list computers, to your
/root/.ssh/known_hosts file. This saves key strokes when setting up Mooty
groups. Exercise standard SSH security caution with such keys, of course.
*** The scanning features of Mooty are a convenience in trusted
environments, not a guarantee of security. ***
9. m.copy_ids
Run this to copy root's ~/.ssh/id_pub.dsa file to all computers in the
master list.
When prompted, enter the password for the root user on all the machines.
Note that you will only have to do this once: when setting up the group,
ie when installing Mooty ssh tunneling capabilities to a machine for the
first time.
-----------------------------------------------------------------------------
NOTE: The $m/lib/freecans/exp.* scripts can be used for automating this
process on 10s, 100s or 1000s of machines at the same time. For groups with
different passwords, simply change the script to automate the process of
initial ssh public key (pubkey) deployment.
-----------------------------------------------------------------------------
10. mooty.sh --help
Shows you how to install and use Mooty.
Of course, you can also read the code, if you dare. I make no apologies for
its obscurity <8o), though I am trying to de-obfuscate the code now that
Mooty is an open source project, in keeping with the spirit of Open Source
Software.
----------------------------------------------------------------------------
NOTE: Using Vim and the pvi.sh .vimrc booster shot, coding practices for
traditional code are less applicable in Mooty, since a) jumping to a
description works roughly at the speed of thought and b) the code itself is
uncompiled, so for the most part it needs less "source commenting" than
compiled code. The code is its own documentation, so to speak.
----------------------------------------------------------------------------
Once Mooty has been installed, you can pass "--help" to any of the link-name
commands as an option.
For example, you can type:
"m.serial_exec --help"
Mooty will then jump to the "m.serial_exec" section of the usage.txt file,
located in /usr/share/doc/packages/mooty/. It will open the file in the
less pager and hi-light the section in question. This allows Mooty to offer
quick documentation even on systems where a functional man page system may
not exist.
----------------------------------------------------------------------------
(mooty.sh --demo)
Mooty will shortly offer a built-in demo system that allows the user to
pick both simple and complex topics like installation and multi-cast
deployment, respectively, and will show the exact command line syntax in
text as it is being typed in!
**************************************
** Text Entry and Results Displayed **
**************************************
The demo player will use the standard util-linux "scriptreplay" command to
show text-based typing and results. All text-based results to stdout (ie,
serial results) are displayed, including ncurses for things like "dialog"
based tools, text-based YaST, partimage, etc.
****************************
** Simple Demo Management **
****************************
To manage the default demos that ship with the controller, and to allow for
custom demos for those that customize the controller, the Mooty builder
script will be upgraded to include a demo directory as part of the source
code, allowing easy creation and management of demos, for the source
project contributors or for private organizations.
********************
** Tiny Demo Size **
********************
Such core demos will not significantly increase the contoller script size,
compressing down to miniscule sizes (they're simply text, not videos), but
they will dramatically assist users in changing to the HPA paradigm that
Mooty leverages.
*****************
** Coming Soon **
*****************
The demo system is slated to be release sometime at the end of the summer,
2011. Look for it, as it should be one of the coolest new features of
Mooty!
----------------------------------------------------------------------------
-------------------------------------------------------------
11. m.remote_exec 'udp-receiver --nokbd --file /really_big.iso'
-------------------------------------------------------------
---------------------------------------------------------------------
A little bit of background info on Linux multi-casting, just in case:
---------------------------------------------------------------------
Here's why that command works:
The underlying tech for multi-casting in Linux is the excellent package
Udpcast. Udpcast uses a server (udp-sender) and a receiver (udp-receiver)
to multi-cast a file to multiple clients. Technically you do not need Mooty
to multi-cast. If you wanted to send a 10GB file to 300 clients, you could
simply start udp-sender on the server and then go around to the 300 clients
and start a udp-receiver on each one. Even if you logged into each machine
using SSH it could potentially take hours to image the machines, especially
if mistakes are made in the syntax; repeating the process would kill lots of
valuable time.
Enter Mooty: Its distinct advantage is that it provides you an easy way to
quickly execute udp-receiver on hundreds of machines, rather than having to
touch each one. If you do not have an imaging precan that adds on to the
basic features, then to multi-cast big files, you will have to enter two
commands: 1) The udp-receiver command (on each client, with options), and 2)
the udp-sender command (on the multi-cast server, with options).
Luckily, you can simply put these commands into the m.hyper_exec command to
execute on the clients, and then simply run the sever command. For your
convenience, I provide the two commands just below, as well as in the
usage.txt file.
The first command opens a multi-cast listener on all the machines in the
master list, and will write what it gets from the sender as "really_big.iso"
right under the slash (/) directory:
m.remote_exec 'udp-receiver --nokbd --file /really_big.iso'
-----------------------------------------------------------------------------
NOTE: The command "m.hyper_exec --help |grep udp" will also print this
command line example to the screen for you to copy and paste, if you'd
like.
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
NOTE: dep_tool.sh is a multi-casting tool included with Mooty that can be
used for complex multi-casting and deployment scenarios, especially
for repeated deployments or staging situations. It is suggested for
frequently deploying large file sets such as VMs, ISO images, or large
add-ons.
-----------------------------------------------------------------------------
12. OK, back to that multi-cast using Mooty. All you need to do next is execute
udp-sender and tell it the file to send.
Here's the example, sending the really_big_original.iso file:
------------------------------------------
udp-sender --file /really_big_original.iso
------------------------------------------
See the udp-sender and udp-receiver documentation for additional options
such as imaging, compression, auto-extraction of archives, multiple NICs,
etc.
--------------------------------------------------------------------------------
So that is an example of using Mooty, from installation to multi-casting, a
common use for Mooty (though far from the limit of what it can do for you).
--------------------------------------------------------------------------------
-------
Summary
-------
Mooty is designed to work on minimal systems, without requiring any additional
agents, shells, or other heavy parameters.
Be aware though, that the power of Mooty is its extensibility. Mooty was
designed from the beginning to allow you to plug precanned executables into its
framework, not just use it at the command line itself. The Engineer in you may
want to use it as a stand-alone tool. Never forget that the developer in you
can also create "precans" to run through Mooty and have them executed across
your entire environment, all at the same time.
I made Mooty for you us, you and I. It is my sincere hope that you enjoy using
it as much as I do and that it makes your job better, faster and stronger.
Have fun getting your parallel groove on!
- Brandon K. Heaton, ME0, ME1
Mooty Creator and Maintainer
b k heaton
at
g mail
dot
com
Tue Sep 13 19:04:21 MDT 2011
