Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

oarsh(1) [debian man page]

oarsh(1)							   OAR commands 							  oarsh(1)

NAME
oarsh - remote shell connector for OAR batch scheduler. oarcp - oarsh compagnon to copy files from a node or to a node. SYNOPSIS
oarsh [OPTIONS] <NODENAME> [COMMAND] oarcp [OPTIONS] [NODENAME:]<PATHNAME> [NODENAME:]<PATHNAME> DESCRIPTION
Connect a node from the submission frontal of the cluster or any node. OPTIONS
oarsh uses OpenSSH client (the ssh command) underneath to perform the connection. Thus any OpenSSH option can be used. ENVIRONMENT
OAR_JOB_ID From the frontal of the cluster or any node, specify the Id of the job oarsh must connect to. OAR_JOB_KEY_FILE Specify a job key oarsh must use, e.g. the one that was used for the submission of the job you want to connect to. This is mandatory when connecting to a node of a job from a host that does not belong to the nodes managed by the OAR server the job was submitted to. The -i option may be used as well. CONFIGURATION
In order to provide the user with the ability to use oarsh to connect both the nodes of his job or other hosts that live out of the scope of his job, oarsh tries to read two configuration files: first ~/.oarsh-host-include then ~/.oarsh-hosts-exclude. If exist, those files must contain one regular expression matching a hostname per line. At execution time, if oarsh finds in ~/.oarsh-host-include a match for the hostname used in the command line, it continues with the execution of oarsh, skipping ~/.oarsh-hosts-exclude file. If not, it tries to find a match in ~/.oarsh-hosts-exclude and if one is found, then executes ssh with the same command line. Finally, it no match is found (or for instance, if none of those files exists), it continues with the execution of oarsh. For instance, if all nodes look like name-XXX.domain, one may place ^[^.]+-[[:digit:]]+ in ~/.oarsh-host-include and .* in ~/.oarsh-hosts-exclude and then can use oarsh to connect any host. The feature finally becomes really sexy when one considers placing a symlink to oarsh named ssh, and then can always use the ssh command to connect any host. EXAMPLES
Connecting from within our job, from one node to another one (node23): > oarsh node-23 Connecting to a node (node23) of our job (Id: 4242) from the frontal of the cluster: > OAR_JOB_ID=4242 oarsh node-23 Connecting to a node (node23) of our job that was submitted using a job key: > OAR_JOB_KEY_FILE=~/my_key oarsh node-23 Same thing but using OpenSSH-like -i option: > oarsh -i ~/my_key node-23 NOTES
All OpenSSH features should be inherited by oarsh, for instance X11 forwarding. However, one feature that oarsh does break is the SSH Agent. None of OpenSSH user configuration files (within ~/.ssh directory) are used by oarsh. SEE ALSO
oarsub(1), oardel(1) oarstat(1), oarnodes(1), oarhold(1), oarresume(1) COPYRIGHTS
Copyright 2008 Laboratoire d'Informatique de Grenoble (http://www.liglab.fr). This software is licensed under the GNU Library General Public License. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. oarsh 2012-05-23 oarsh(1)

Check Out this Related Man Page

ganeti-masterd(8)						   Version 2.5.2						 ganeti-masterd(8)

Name
       ganeti-masterd - Ganeti master daemon

Synopsis
       ganeti-masterd [-f] [-d] [--no-voting]

DESCRIPTION
The ganeti-masterd is the daemon which is responsible for the overall cluster coordination. Without it, no change can be performed on the cluster. For testing purposes, you can give the -f option and the program won't detach from the running terminal. Debug-level message can be activated by giving the -d option. ROLE The role of the master daemon is to coordinate all the actions that change the state of the cluster. Things like accepting new jobs, coor- dinating the changes on nodes (via RPC calls to the respective node daemons), maintaining the configuration and so on are done via this daemon. The only action that can be done without the master daemon is the failover of the master role to another node in the cluster, via the gnt- cluster master-failover command. If the master daemon is stopped, the instances are not affected, but they won't be restarted automatically in case of failure. STARTUP At startup, the master daemon will confirm with the node daemons that the node it is running is indeed the master node of the cluster. It will abort if it doesn't get half plus one positive answers (offline nodes are queried too, just in case our configuration is stale). For small clusters with a number of nodes down, and especially for two-node clusters where the other has gone done, this creates a problem. In this case the --no-voting option can be used to skip this process. The option requires interactive confirmation, as having two masters on the same cluster is a very dangerous situation and will most likely lead to data loss. JOB QUEUE The master daemon maintains a job queue (located under the directory /var/lib/ganeti/queue) in which all current jobs are stored, one job per file serialized in JSON format; in this directory a subdirectory called archive holds archived job files. The moving of jobs from the current to the queue directory is done via a request to the master; this can be accomplished from the command line with the gnt-job archive or gnt-job autoarchive commands. In case of problems with the master, a job file can simply be moved away or deleted (but this might leave the cluster inconsistent). COMMUNICATION PROTOCOL The master accepts commands over a Unix socket, using JSON serialized messages separated by a specific byte sequence. For more details, see the design documentation supplied with Ganeti. REPORTING BUGS
Report bugs to project website (http://code.google.com/p/ganeti/) or contact the developers using the Ganeti mailing list (ganeti@google- groups.com). SEE ALSO
Ganeti overview and specifications: ganeti(7) (general overview), ganeti-os-interface(7) (guest OS definitions). Ganeti commands: gnt-cluster(8) (cluster-wide commands), gnt-job(8) (job-related commands), gnt-node(8) (node-related commands), gnt- instance(8) (instance commands), gnt-os(8) (guest OS commands), gnt-group(8) (node group commands), gnt-backup(8) (instance import/export commands), gnt-debug(8) (debug commands). Ganeti daemons: ganeti-watcher(8) (automatic instance restarter), ganeti-cleaner(8) (job queue cleaner), ganeti-noded(8) (node daemon), ganeti-masterd(8) (master daemon), ganeti-rapi(8) (remote API daemon). Ganeti htools: htools(1) (generic binary), hbal(1) (cluster balancer), hspace(1) (capacity calculation), hail(1) (IAllocator plugin), hscan(1) (data gatherer from remote clusters). COPYRIGHT
Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011 Google Inc. Permission is granted to copy, distribute and/or modify under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. On Debian systems, the complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL. Ganeti ganeti-masterd(8)
Man Page