Getting started

From ControlTier

Jump to: navigation, search

Introduction

Methodology

Modeler Getting started

After reading this Getting Started page, you should have the general pattern to using ControlTier to define and manage your automation. It begins with the installation of the ControlTier server and client across your hosts. Then you create a project where you will manage your work. Each step of automation is specified in a new or existing script. Each script can then be exposed as a defined command in a type. Automation steps are combined into a workflow. Any script or type-defined command can be executed across the network via the command dispatcher via the GUI or CLI. Dispatching flags control how the commands are executed across the network.

Download and Install

Main article: Installation

Download the desired package type (e.g., ZIP installer or RPM installer)
Set the CTIER_ROOT environment variable
Install the ControlTier Server package to the chosen ControlTier server.
Install the Client package on each additional client host. (optional)
- Be sure to run ctl-setup for each client host, to configure the server's hostname.
Once the server is running access the server landing page and login.
Set your ControlTier Environment Variables

If ControlTier is working correctly you should now be able to type ctl --version in the terminal window and see output below:

ctl --version	
	.
	.
	.
[CTL version 3.6.0 (20100913)]

Create a project

Main article: Creating a project

A ControlTier "Project" provides a space to manage related automation activities. The ctl-project shell command is used to create the workspace for each project from command line. There is a GUI frontend, but we will stick to the command line here.

On the ControlTier server, run the ctl-project command and specify a project name, here we use "demo":

ctl-project -a create -p demo

This will create the Project in the server, and registering the server host as a Node in the "demo" project's Resource Model.

Node resources

Main article: Node

During project setup, the "ctl-project -a create" command generated a bit of metadata about the ControlTier server host in the form of a Node resource in the project's resource model. The resource model is stored in a database and accessed during command execution.

You can list information about Nodes in the resource model via the shell using the ctl-exec -v command. Specify the -p option and the Project name. Here the ctl-exec command lists the registered Nodes for the "demo" project after the server install:

  $ ctl-exec -p demo -v	
  strongbad:
     hostname: strongbad
     os-arch: x86_64
     os-family: unix
     os-name: Mac OS X
     os-version: 10.6.2
     tags: []
     ---- Attributes ----

Node resources have standard properties that can be extended via attributes but one of the more useful properties is the "tags" property. A tag is a text label that you give to the Node, perhaps denoting a classification, a role the node plays in the environment, or group membership. The output above shows the "strongbad" node currently has an empty tags property: tags: []

It is useful to start thinking about node tagging for your own nodes because you will use it later when specifying #Command_dispatcher_options to drive distributed command execution.

Node resource data can be maintained with the graphical interface, with an XML definition or via the command line.

Here we use a command line tool to add two tags to the server Node, "strongbad". This is done using a utility command called tag-add in the modelutil module:

ctl -p demo -m modelutil -c tag-add -- -type Node -name strongbad -tags admin,simple

Running ctl-exec -v again shows the tags property now contains "admin, simple":

  $ ctl-exec -p demo -v	
  strongbad:
     hostname: strongbad
     os-arch: x86_64
     os-family: unix
     os-name: Mac OS X
     os-version: 10.6.2
     tags: [admin, simple]
     ---- Attributes ----

The modelutil tag-remove command can remove a tag. Here the "simple" tag is removed from strongbad:

ctl -p demo -m modelutil -c tag-remove -- -type Node -name strongbad -tags simple

Now the node has only one tag, "admin":

  $ ctl-exec -p demo -v	
  strongbad:
     hostname: strongbad
     os-arch: x86_64
     os-family: unix
     os-name: Mac OS X
     os-version: 10.6.2
     tags: [admin]
     ---- Attributes ----

Add client Nodes

With the ControlTier server Node configured and defined, install the ControlTier client on the hosts you wish to manage. Run the project creation procedure you ran on the server. Once that is done, those client hosts will be registered as Node resources in the project.

For the sake of this Getting Started document, imagine two hosts had the ctier-client RPMs installed: centos54 and ubuntu. The following bash script would run the needed ctl-project command to setup project, "demo":

for host in centos54 ubuntu
do
  ssh $host su - ctier -c "ctl-project -p demo -a create"
done

Use the tag-add modelutil command to define tags for ubuntu and centos54. We'll give both hosts a common "dev" tag while each get their own tag signifying a functional role (ie, "web" vs "cache").

ctl -p demo -m modelutil -c tag-add -- -type Node -name ubuntu -tags dev,web
ctl -p demo -m modelutil -c tag-add -- -type Node -name centos54 -tags dev,cache

Running the ctl-exec -v command now displays three Node resources:

ctl-exec -p demo -v
centos54:
   hostname: 192.168.1.106
   os-arch: i386
   os-family: unix
   os-name: Linux
   os-version: 2.6.18-164.el5
   tags: [cache, dev]
strongbad:
   hostname: strongbad
   os-arch: x86_64
   os-family: unix
   os-name: Mac OS X
   os-version: 10.6.5
   tags: [admin]
ubuntu:
   hostname: 172.16.167.211
   os-arch: i386
   os-family: unix
   os-name: Linux
   os-version: 2.6.27-7-generic
   tags: [dev, web]

...and this is how the ControlTier GUI will show the nodes:

Command execution

Main article: Command execution

The ControlTier Command dispatcher enables distributed command execution of scripts or commands across the registered Nodes. Execution can be managed either through command line tools or a graphical interface. Dispatcher options control how the command or scripts will execute and lets you coordinate actions across hosts. The Scripters cookbook page offers several examples on how to take advantage of various features and useful utilities that cover common scripting use cases.

Ad hoc commands

Main article: Running ad hoc commands

An "ad hoc" command is a shell script or system executable that you might run at an interactive terminal. Ad hoc commands can be executed via the ctl-exec shell command. Use ctl-exec to execute individual commands or shell script files.

Here ctl-exec is used to run the Unix uptime command to print system status:

$ ctl-exec -I os-family=unix -- uptime
[ctier@centos54 ctl-exec][INFO]  10:34:54 up 46 min,  2 users,  load average: 0.00, 0.00, 0.00
[alexh@strongbad ctl-exec][INFO] 10:34  up 2 days, 18:51, 2 users, load averages: 0.55 0.80 0.75
[demo@ubuntu ctl-exec][INFO]  10:35:01 up 2 days, 18:40,  2 users,  load average: 0.00, 0.01, 0.00

Notice, the ctl-exec command prepends the message output with a header that helps understand from where the output originates. The header format includes the login and node where the ctl-exec execution occurred.

Execute the Unix whomi command to see what user ID is used by that Node to run dispatched commands:

$ ctl-exec -I os-family=unix -- whoami
[ctier@centos54 ctl-exec][INFO] ctier
[alexh@strongbad ctl-exec][INFO] alexh
[demo@ubuntu ctl-exec][INFO] demo

You can see that each Node is defined to use a different login to execute ctl-exec commands. That feature can be handy when Nodes serve different roles and therefore, use different logins to manage processes.

The ctl-exec command can also execute shell scripts. Here's a trivial script that generates a bit of system info:

#!/bin/sh
# Example script: info.sh
echo "info script"
echo uptime=`uptime`
echo whoami=`whoami`
echo uname=`uname -a`

Use the -s option to specify the "info.sh" script file:

$ ctl-exec -I os-family=unix -s info.sh

The ctl-exec command copies the "info.sh" script located on the server to each host and then executes it.

Dispatcher options

Main article: Dispatcher options

The command dispatcher supports a number of flags that can control how commands are executed across nodes. The command line tools, ctl, ctl-exec as well as job definitions support the notion of command dispatching flags.

Include/exclude flags

Include and exclude flags filter the set of nodes the command will execute. The node inclusion and exclusion is controlled via "-I" and "-X" flags.

To execute a command across all Nodes use a wildcard to the "-I" include flag:

ctl-exec -I '.*' -- uname -a

Below, the "-I os-name=Linux" option specifies to include all nodes that have the operating system name "Linux". The "-X centos54" excludes the node named "centos54":

ctl-exec -I os-name=Linux -X centos54 -- uname -a

Here's an example that runs the who am i unix command on all hosts that tagged "simple":

ctl-exec -I tags=simple -- who am i

Parallel execution

Parallel execution is managed using thread count via "-C" option. The "-C" option specifies to the number of execution threads. Here's an example that runs the uptime command across the Linux hosts with two threads:

ctl-exec -I os-name=Linux -C 2 -- uptime

Keepgoing flag

The keepgoing and retry flags control when to exit incase an error occurs. Use "-K/-R" flags. Here's an example script that checks if the host has port 8080 in the listening state. If it does not, it will exit with code 1.

#!/bin/sh
netstat -an | grep 8080 | grep -q LISTEN
if [ "$?" != 0 ]; then
echo "not listening on 8080"
exit 1;
fi
echo  listening port=8080, host=`hostname`;

Commands or scripts that exit with a non-zero exit code will cause the dispatch to fail unless the keepgoing flag is set.

$ ctl-exec -I os-family=unix -s /tmp/listening.sh

[alexh@strongbad ctl-exec][INFO] Connecting to centos54:22
[alexh@strongbad ctl-exec][INFO] done.
[ctier@centos54 ctl-exec][INFO] not listening on 8080
error: Remote command failed with exit status 1

The script failed on centos54 and caused ctl-exec to error out immediately.

Running the command again, but this time with the "-K" keepgoing flag will cause ctl-exec to continue and print on which nodes the script failed:

$ ctl-exec -K -I tags=web -s /tmp/listening.sh

[alexh@strongbad ctl-exec][INFO] Connecting to centos54:22
[alexh@strongbad ctl-exec][INFO] done.
[ctier@centos54 ctl-exec][INFO] not listening on 8080
[ctier@centos54 ctl-exec][ERROR] Failed execution for node: centos54: Remote command failed with exit status 1
[alexh@strongbad ctl-exec][INFO] listening port=8080, host=strongbad
[alexh@strongbad ctl-exec][INFO] Connecting to 172.16.167.211:22
[alexh@strongbad ctl-exec][INFO] done.
[demo@ubuntu ctl-exec][INFO] not listening on 8080
[demo@ubuntu ctl-exec][ERROR] Failed execution for node: ubuntu: Remote command failed with exit status 1
error: Execution failed on the following 2 nodes: [centos54, ubuntu]
error: Execute this command to retry on the failed nodes:
	ctl-exec -K -s /tmp/listening.sh -p demo -I name=centos54,ubuntu

Ad hoc Jobs

For the most part, an ad hoc job is is like an ad hoc command except the command is executed and tracked using the Ctlcenter webapp.

To begin, login to the Ctlcenter webapp, and press the "Jobs" tab.

1. Locate the "New Job" button in the right hand corner and press it to display the "Create New Job" form.

2. A job is defined in terms of one or more workflow items. In the Workflows area, click the "Add an item" link

3. Workflow items can be one of several types. Click the "Script" workflow item type

4. A script type can be any script that can be executed on the target hosts. Type in the "info" shell script we executed earlier using ctl-exec.

5. At the bottom of the form, run the "Run and Forget" button to begin execution

6. Execution output can be followed on the subsequent page.

Job dispatch options

The "info" script example above was fairly simple and unlikely to generate script related errors. Also, just as we saw earlier with ctl-exec, Jobs default to executing on just the ControlTier server. The Job create form includes dispatch option controls to filter target machines and control when to keep going if an error occurs, equivalent to the ctl-exec "-I/-X" and "-K" flags.

Imagine a script that checks for a condition and if the condition was unmet, exits with a non zero code. The following script follows that pattern.

#!/bin/sh
netstat -an | grep 8080 | grep LISTEN
if [ $? ! = 0 ]; then
  echo NOT LISTENING ; exit 1 ;
else
  echo LISTENING
fi

Remember, commands that exit with non zero will cause the dispatcher to exit unless keepgoing is set true.

The Job create form can be expanded to "Dispatch to Nodes" and "Keep going on error" as the screenshot below illustrates:

The "Node Include Filters" is equivalent to the -I os-name=unix" option. Setting the "Yes" button for the "Keep going on error?" is the same as specifying "-K" option.

After you are satisified with the dispatch options, press the "Run and Forget" button to execute the script to the selected Nodes:

Queuing commands to Ctlcenter

Commands or scripts executed on the command line by ctl-exec can also be queued as jobs in CtlCenter by using the "-Q" option. The ctl-exec -Q usage is equivalent to a "Run and Forget" action in Ctlcenter.

The script below is a long running check that will run periodically waiting a set time between each pass. It can be run with or without arguments as the parameters are defaulted inside the script:

$ cat ~/bin/checkagain.sh 
#!/bin/bash
iterations=$1 secs=$2 port=$3
echo "port ${port:=8080} will be checked ${iterations:=30} times waiting ${secs:=5}s between each iteration"
 
i=0
while [ $i -lt ${iterations} ]; do
  echo "iteration: #${i}"
  netstat -an | grep $port | grep LISTEN && exit 0
  echo ----
  sleep ${secs}
  i=$(($i+1))
done
echo "Not listening on $port after $i checks" ; exit 1

Running ctl-exec with the -Q option causes the dispatch to queue in Ctlcenter and controlled as an ad-hoc job. The -I centos54 limits execution to just the "centos54" node:

$ ctl-exec -Q -I centos54 -s ~/bin/checkagain.sh 
Succeeded queueing workflow: Workflow:(threadcount:1){ [command( scriptfile: /Users/alexh/bin/checkagain.sh)] }
Queued job ID: 5 <http://strongbad:8080/ctlcenter/execution/follow/4>

Saved Jobs

Ad hoc commands are a typical part of day to day administrative duties. Occasionally, ad hoc commands become routine procedures and if reusable, would become more valuable as they could be handed off or called by other Jobs. Ctlcenter provides an interface to declare and save jobs, both graphically or declared with an XML file.

As many jobs will accumulate over time, it is useful to organize Jobs into groups. A group is a logical set of jobs, and one job group can exist inside another. Ctlcenter displays job lists as a set of folders corresponding to the group structure your jobs define.

Beyond organizing jobs, groups assist in defining access control policy, as we'll cover later.

Simple info job example

For the first saved Job example, create a Job that calls the info script. Like in the earlier example, begin by pressing the "New Job" button to reveal the new job form. This time, select "Yes" for the "Save this job?" prompt. Pressing Yes reveals a form to define a name, group and description for the job. For "Job Name", enter "info" and for the "Group", enter "adm/resources". Providing a description will be come helpful to other users to understand the intent and purpose for the Job.

Check the box for "Dispatch to Nodes" and this time choose the "Node Exclude Filters" and enter the name of your Ctlcenter server. This will cause the job to run on just the target Nodes (eg., centos54 and ubuntu).

Type in the info script that we used earlier. Once saved to the Workflow, press the "Create" button.

Once the the job is created, the browser will be directed to the main Jobs page. The folder structure reflecting the group naming will show one Job.

Pressing through the folders and then to the job itself, will reveal a button bar with controls for editing and running the job. Press the green arrow icon to run the Job.

Press the "Run Job Now" button to begin execution.

Output from the script execution from the target Nodes will be displayed on the subsequent page.

Multi-Job example

Saved jobs are a convenient method to draw from a library of routine procedures. By its nature, a saved Job encapsulates a process into a logically named interface. Jobs can begin as a single item workflow that calls a small or large shell script but evolve into a multi-item workflow. The next step in evolution, is to build Jobs on top of other Jobs. Using this approach one can view each Job as a reusable building block upon which more complex automation can be built.

Let's imagine our three nodes support a web-based application for acme.com, a fictitious anvil reseller. Because anvil sales are seasonal, a virtual IP address (VIP) is used to distribute traffic across a variable sized pool of web servers. Also, the anvil sales application isn't perfect and periodically requires restarting. Scripts were created to manage the startup and shutdown procedures to coordinate with the load balancer to add or remove the stopped servers from the VIP.

The goal here is to expose these restart scripts as Jobs, in order to provide a central point of control. Because the VIPs are different between QA and production, the Jobs should also support passing the desired VIP address to the scripts. For both QA and production hosts, the web restart scripts are located in a standard path: /apps/web/bin.

Real scripts to manage startup and shutdown, along with interacting with the load balancer would be somewhat involved. For this example, we show scripts that merely echo their intent and the arguments passed to the them.

The table below shows the four scripts - lb-add.sh, lb-remove.sh, start.sh and stop.sh - located on the Nodes tagged "web":

lb-add.sh

lb-remove.sh

start.sh

stop.sh

#!/bin/sh
# Usage: lb-add.sh [vip]
echo added `hostname` to vip: $1

#!/bin/sh
# Usage: lb-remove.sh [vip]
echo removed `hostname` from vip: $1

#!/bin/sh
# Usage: start.sh
echo web started.

#!/bin/sh
# Usage: stop.sh
echo web stopped.

Though not a requirement, it is helpful to have a convention for Job group naming. A good naming convention assists others with navigation scheme that helps them remember and find the desired procedure.

For this example, the Jobs will correspond to the name space of the scripts directories.

With an idea of the Acme management scripts in mind, the next step is to define three jobs to encapsulate the procedures. The overall goal is to provide a restart procedure but for the sake of reusability, it might be preferred to break the restart procedure into separate "stop" and "start" procedures.

The "stop" job can be defined as a script that calls the "lb-remove.sh" script to remove the server from the specified VIP argument. Afterwards, the stop.sh script is called. The "start" job is similar except the server is first started via the "start.sh" before the server is added back to the specified VIP by the "lb-add.sh" script.

Job options

Any command or script can be wrapped as a Job. Creating a Job for every use case would proliferate a large number of Jobs differing only by how the Job provides data to the scripts they call. These differences are often environment or application version related and would be better treated as a menu choice made by the person running the Job. Once chosen, the value selected by the menu could then be passed to the script.

Allowed values

Sometimes it is important to control or produce values presented to a given Job option. For example, the Acme Anvil sales site is accessible from two VIP addresses one for production and one for testing - https://www.acme.com and https://qa.acme.com, respectively. The shutdown and startup management scripts require the appropriate VIP name to interact correctly with the load balancer. Therefore, the start and stop Jobs need to present a user with VIP value choices, but only those choices.

The screenshot below contains the Option edit form for an option named "vip". The form includes elements to define description and default value, as well as, Allowed Values and Restrictions.

Values can be specified as a comma separated list as seen above but can also be requested from an external source using a "remote URL".

Option choices can be controlled using the "Enforced from values" restriction. When set "true", the Ctlcenter UI will only present a popup menu. If set "false", a text field will also be presented. Use the "Match Regular Expression" form to validate the input option.

Here's a screenshot of how Ctlcenter displays the two VIP choices as a menu:

Script usage

Option values can be passed to scripts as an argument or referenced inside the script via a named token. For example, the value for the "vip" option selection can be accessed in one of several ways:

Value passed as an environment variable.
Bash: $CT_OPTION_VIP
Value passed in the argument vector to the executed script or command
Commandline Arguments: ${option.vip}
Value referenced as a named token inside the script and replaced before execution
Script Content: @option.vip@

Job composition

With an understanding of the scripts and the VIP option needed to control the restart operation, the final step is to compose three Job definitions. All three jobs will share these features:

Dispatch include flag: "tags=web"
Only dispatch to the Nodes tagged "web"
Option: set "vip" option to use enforced values
select from the list: "https://qa.acme.com,https://www.acme.com"

While each job can be defined graphically in Ctlcenter, each can succinctly be defined via a job.xml file instead. This job.xml document contains a set of tags corresponding to the choices seen in the Ctlcenter GUI form.

Below are the XML definitions for the three jobs: stop, start and restart. One or more jobs can be defined inside a single XML file but your convention dictate how to organize the definitions. The files can be named any way you want and do not have to correspond to the Job name or its group.

stop.xml

<joblist>	
<job> 
  <name>stop</name>  
  <description>the web stop procedure</description>  
  <additional/>  
  <loglevel>INFO</loglevel>  
  <group>apps/web</group>  
  <context> 
    <project>demo</project>  
    <options> 
      <option name="vip" enforcedvalues="true" required="true" 
	values="https://qa.acme.com,https://www.acme.com"/> 
    </options> 
  </context>  
  <sequence threadcount="1" keepgoing="false" strategy="node-first"> 
    <command> 
      <script><![CDATA[#!/bin/sh
/apps/web/bin/lb-remove.sh $1
/apps/web/bin/stop.sh]]></script>  
      <scriptargs>${option.vip}</scriptargs> 
    </command> 
  </sequence>  
  <nodefilters excludeprecedence="true"> 
    <include> 
      <tags>web</tags> 
    </include> 
  </nodefilters>  
  <dispatch> 
    <threadcount>1</threadcount>  
    <keepgoing>false</keepgoing> 
  </dispatch> 
</job>
</joblist>

Defines Job, /apps/web/stop, that executes a two line shell script to Nodes tagged "web". The shell script is passed a single argument, ${option.vip}, containing the value chosen in the Job run form.

start.xml

<joblist>	
<job> 
  <name>start</name>  
  <description>the web start procedure,the vip name</description>  
  <additional/>  
  <loglevel>INFO</loglevel>  
  <group>apps/web</group>  
  <context> 
    <project>demo</project>  
    <options> 
      <option name="vip" enforcedvalues="true" required="true" 
	values="https://qa.acme.com,https://www.acme.com" /> 
    </options> 
  </context>  
  <sequence threadcount="1" keepgoing="false" strategy="node-first"> 
    <command> 
      <script><![CDATA[#!/bin/sh
/apps/web/bin/start.sh
/apps/web/bin/lb-add.sh $1]]></script>  
      <scriptargs>${option.vip}</scriptargs> 
    </command> 
  </sequence>  
  <nodefilters excludeprecedence="true"> 
    <include> 
      <tags>web</tags> 
    </include> 
  </nodefilters>  
  <dispatch> 
    <threadcount>1</threadcount>  
    <keepgoing>false</keepgoing> 
  </dispatch> 
</job>
</joblist>

Defines Job, /apps/web/start, that executes a two line shell script to Nodes tagged "web". The shell script is passed a single argument, ${option.vip}, containing the value chosen in the Job run form.

restart.xml

<joblist>	
<job> 
  <name>restart</name>  
  <description>restart the web server</description>  
  <additional/>  
  <loglevel>INFO</loglevel>  
  <group>apps/web</group>  
  <context> 
    <project>demo</project>  
    <options> 
      <option name="vip" enforcedvalues="true" required="false" 
	values="https://qa.acme.com,https://www.acme.com" /> 
    </options> 
  </context>  
  <sequence threadcount="1" keepgoing="false" strategy="node-first"> 
    <command> 
      <jobref name="stop" group="apps/web"> 
        <arg line="-vip ${option.vip}"/> 
      </jobref> 
    </command>  
    <command> 
      <jobref name="start" group="apps/web"> 
        <arg line="-vip ${option.vip}"/> 
      </jobref> 
    </command> 
  </sequence>  
  <nodefilters excludeprecedence="true"> 
    <include> 
      <tags>web</tags> 
    </include> 
  </nodefilters>  
  <dispatch> 
    <threadcount>1</threadcount>  
    <keepgoing>true</keepgoing> 
  </dispatch> 
</job>	
</joblist>

Defines Job, /apps/web/restart, that executes a sequence of Job calls, first "stop" and second "start" across Nodes tagged "web".

Saving those XML definitions as files located on the Ctlcenter server, you can load them using the ctl-jobs command.

Run the ctl-jobs load command for each job definition file:

ctl-jobs load -f start.xml
ctl-jobs load -f stop.xml
ctl-jobs load -f restart.xml

The ctl-jobs list command queries Ctlcenter and prints out a list of defined jobs:

$ ctl-jobs list
Found 4 jobs:
	- info [7] <http://strongbad:8080/ctlcenter/scheduledExecution/show/7>
	- restart [9] <http://strongbad:8080/ctlcenter/scheduledExecution/show/9>
	- start [10] <http://strongbad:8080/ctlcenter/scheduledExecution/show/10>
	- stop [11] <http://strongbad:8080/ctlcenter/scheduledExecution/show/11>

Of course, the jobs can be viewed inside Ctlcenter's UI by going to the Jobs page:

The composition of the "restart" job can be seen as a workflow that calls the two other jobs: stop and start. The "restart" job passes the "vip" option value to the lower level stop and start Jobs.

Command line Job control

Shell utilities exist to provide command line Job control.

The ctl-run command is used to start the execution of a Job defined in Ctlcenter.

Here's an example that runs the "restart" job defined in the section above:

$ ctl-run -j apps/web/restart -- -vip https://qa.acme.com
Job execution started:
[51] restart <http://strongbad:8080/ctlcenter/execution/follow/51>

Jobs as well as commands executed with the -Q option can be listed with the ctl-queue command. The ctl-queue command lists jobs currently running in Ctlcenter execution queue:

$ ctl-queue
Queue: 1 items
[5] workflow: Workflow:(threadcount:1){ [command( scriptfile: /Users/alexh/bin/checkagain.sh)] } <http://strongbad:8080/ctlcenter/execution/follow/5>

Running jobs can also be killed via the ctl-queue "kill" command. The ctl-queue command includes the execution ID for each running job. Specify execution ID using the "-e" option:

$ ctl-queue kill -e 5
ctl-queue kill: success. [5] Job status: killed

Access control policy

Main article: aclpolicy

Access to running or modifying Jobs is managed in an access control policy defined using the aclpolicy XML format. This file contains a number of policy elements that describe what user group is allowed to perform which actions.

Policies can be organized into more than one file to help organize access by group or pattern of use. The normal ControlTier install will have generated a policy for the "admin" group. Not all users will need to be given "admin" access level to control and modify all Jobs. More typically, a group of users will be given access to just a subset of Jobs.

For an example, lets create a policy that allows users in the "deploy" group to run commands just in the "apps" and "apps/web" Job groups. We can reference the "deploy" user and group as it was also included in the normal install.

Create the aclpolicy file for the "deploy" group
cp $CTL_BASE/etc/admin.aclpolicy $CTL_BASE/etc/deploy.aclpolicy
Modify the <command> and <group> elements as shown in the example below. Notice that just workflow_read,workflow_run actions are allowed.

$ cat $CTL_BASE/etc/deploy.aclpolicy
<policies>
  <policy description="Deploy group that has access policy.">
    <context project="*">
      <command group="apps" job="*" actions="workflow_read,workflow_run"/>
      <command group="apps/web" job="*" actions="workflow_read,workflow_run"/>
    </context>
    <by>
      <group name="deploy"/>
    </by>
  </policy>
</policies>

Restart jetty so Ctlcenter loads the new policy file.
jetty.sh restart

Once the Ctlcenter webapp has started, login as the "deploy" user (the password is probably "deploy"). Just the Jobs in the "apps" group are displayed in the Jobs page. The "1 authorized jobs are not shown" message indicates that "deploy" user does is not allowed to access jobs outside of "/appsi group (i.e., nothing in the "/adm" job group).

Notice the absence of the "New Job" button displayed earlier when logged in as "admin". Job creation is an action not granted to "deploy". Notice also, that the button bar for the listed Jobs does not include icons for editing or deleting the Job. Only workflow_read and workflow_actions were allowed.

Where to go from here

Getting started

From ControlTier

Contents

Download and Install

Create a project

Node resources

Add client Nodes

Command execution

Ad hoc commands

Dispatcher options

Include/exclude flags

Parallel execution

Keepgoing flag

Ad hoc Jobs

Job dispatch options

Queuing commands to Ctlcenter

Saved Jobs

Simple info job example

Multi-Job example

Job options

Allowed values

Script usage

Job composition

Command line Job control

Access control policy

Where to go from here

Personal tools

Namespaces

Variants

Views

Actions

Search

Navigation

Communication

Development

Toolbox

Print/export