r9 - 22 May 2008 - 19:21:16 - EricTYou are here: Wiki >  AppLogic23 Web > ClientSideMacros
ALERT! AppLogic 2.3 Beta Documentation The latest production release is AppLogic 3.0.30

Client-side Macros

ALERT! This page is maintained and supported by LeoKalev. It is a small independent project, which I am making public here in the hope that it will help make better and easier use of AppLogic. There's no warranty of any kind for it and no support beyond what I can handle personally. Post your feedback and questions here on this page, or e-mail lion at 3tera dot com.

Client-side macros for GNU Bash and OpenSSH client, for easy access to all the functionality of 3tshell - the AppLogic command-line interface, directly from your local shell prompt.

  • access to the full CLI from local command prompt
  • additional shortcut macros for frequent tasks
  • useable in non-interactive scripts
  • extendable with additional commands, by defining new shell functions

Download here:

  • rmacros.sh: Client-access macros to 3tshell, via OpenSSH.

To use this on your system, all you need is to have GNU Bash 2.0 or later and the OpenSSH client program (ssh), version 3.9 or later. Download the attached shell file, save it on your disk and include it in your shell using the source command (or .) - this can be done in the '.bashrc' file, so that it is available to every interactive shell instance that you start.

Once the rmacros.sh file is loaded, the following commands become available from the shell prompt. The same commands can also be used in a non-interactive script - simply include the rmacros.sh file from your script with the "source" command:

controller hostname-or-ip set the hostname of the controller to which to direct subsequent commands. This must be done before using any of the other commands
controller - disconnect from controller. This closes the master ssh session with the controller. See below for more on this.
3t any 3tshell command this is the same as typing the command at the AppLogic shell prompt
3t Invoke the interactive AppLogic shell
ca appname set the current application. This works the same way as the 'ca' command in the interactive shell. Note that doing 3t ca myapp won't work because a new instance of the AppLogic shell is started by each invocation of the '3t' command
pwa print the name of the current application (as set by ca)
assh [appname:]component open an interactive shell to a running appliance instance in the current application, or in the specified application. component is the instance's full name in the application hierarchy. The name of the top-level assemlby (main.) can be omitted, e.g., the following are equivalent:
assh the-app:main.web.srv1
ca the-app ; assh web.srv1
assh [app:]component cmd [args] run a non-interactive command on an appliance instance. NOTE: on older (1.x) versions of AppLogic, the command name and the arguments cannot contain spaces, i.e., this will not work as expected:
assh web.srv1 cat "the file with spaces in its name".
If you must do this on an older grid, make a short script and copy it to the running appliance using the ascp command below, then start that script.
ascp src dest copy a file to/from a running appliance. One of the src or dest parameters must be the name of a local file or directory. The other specifies the remote appliance and file name in a form similar to that of the 'scp' command:
comp.name:filename
The component name is the full path of the component in the application assembly (as with assh, the main. prefix can be omitted). This command requires that the current application be set with the ca command.
als Shortcut. same as 3t app list
astop Shortcut. Same as 3t app start `pwa`
astop Shortcut. Same as 3t app stop `pwa`
vmnt Not supported in AppLogic 2.3. Please use the new vol manage operation instead.
vumnt Not supported in AppLogic 2.3
vscp (Coming soon - not implemented yet). Copy to/from a volume mounted with vmnt. For now you will have to use 'scp' the old way, as described in the CLI reference, addressing the /vol/ virtual directory on the controller.

Configuring Custom SSH Options

Besides the normal way of setting SSH options (which is to put them in your ~/.ssh/config file), the commands provided by rmacros.sh also accept an environment variable setting with options that affect only ssh invocations generated by the macros, but not any other ssh commands. This is useful if you need a different set up for working with the AppLogic grid(s) and for other ssh sessions, and the per-host method supported by the .ssh/config file is not suitable to separate the different options. This includes the case when you also have "maintainer" access to the AppLogic grid (e.g, if you installed that grid) - in such a case you have an SSH key that provides root access to the controller - not what is needed to work as a normal "client".

To provide additional options to the remote access macros in rmacros.sh, set the AL_SSH_OPT variable. It should contain options in the form accepted by ssh and all of its companion programs (scp, sftp, etc.): -o OptionName=option-value. Do not use shorthand options like -i, -t, etc. - they work with ssh, but not with scp.

Example:
export AL_SSH_OPT='-o IdentityFile=/home/lk/t-key -o IdentitiesOnly=yes -o StrictHostKeyChecking=no'

This tells SSH: use the key /home/lk/t-key for public-key authentication; do not use any keys served by ssh-agent; disable strict host identity checking (use the last one only if you frequently re-install grids from scratch, causing the SSH Id of the controller to change every time).

Fast and Easy Access with Master SSH Session

The functions defined in rmacros.sh use the Master Session feature of the OpenSSH client. The first command that is run will start a background ssh client in 'master' mode, and all subsequent commands use the session maintained by the 'master' to run additional ssh sessions over the same secure channel.

This provides two benefits: first, typing a passphrase to access the SSH private key is only necessary once - after that, the session is maintained open and no additional logins are made.

Second, this makes new invocations of 'ssh' as fast as typing commands to an already open SSH session - faster, in fact - because the command is sent once, when you press Enter, while an interactive session uses character-by-character echo as you type the command.

Also, running the commands locally from your shell and not from the 3tshell console allows one to use the full power of the shell, to make up commands that are not possible with an interactive 3tshell session, for example:

Get a list of running applications:
3t app list | grep running

Save volume list to a file:
3t vol list >file

Transfer configuration from one application to another:
3t app config app1 --batch | 3t app config app2 --stdin

-- LeoKalev - 08 Oct 2006

 
Copyright © CA 2005-2011. All Rights Reserved.
%