Skip to content

Instantly share code, notes, and snippets.

View ahonor's full-sized avatar

Alex Honor ahonor

View GitHub Profile

To: groups.google.com/group/controltier

Announcing project "RunDeck"

Hello fellow ControlTier users,

In addition to working on ControlTier, I'm working on a new open source project along with a couple ControlTier developers called "RunDeck". The goal of this project is a client-less, easy to install and use command and control server. It's really a spin off or a promotion of some of ControlTier's most popular features: Jobs and ad-hoc command execution.

RunDeck shares many ControlTier ideas and its code base was seeded from ControlTier 3.6. Combine CTL Center, supporting shell tools (ctl-exec, ctl-queue, ctl-run, ctl-jobs), document formats like job.xml and a subset of resources.xml, and you can probably envision the RunDeck footprint. The user interface design should also be quite familiar to CTL Center users with some improvements, as well.

Rundeck announcement

Annoucing project "RunDeck" !

RunDeck is an open source software project with the goal of creating an easy to use command and control server that administrators can use to execute commands across servers in datacenter and cloud environments. The kinds of commands can be … well anything the day requires. It should be easy to have a single command, script or sequence of steps execute across your servers. Also, administrators today manage large numbers of servers in dynamic environments; dynamic because the number of nodes fluctuate (increase and decrease) or the role nodes play changes over time.

Here's a few ideas that drive the RunDeck development effort:

  • abstracted distributed command execution
  • filter driven host addressing (eg tags)
### Troubleshooting access control policy
After defining an aclpolicy file to grant access to a particular group
of users, you may find them getting "unauthorized" messages or
complaints that certain actions are not possible.
To trouble shoot this, begin by checking two bits:
1. The user's group membership. This can be done by going to the
user's profile page in RunDeck. That page will list the groups the
user is a member.
mappedRoles.admin=admin
mappedRoles.user_admin=admin
mappedRoles.workflow_read=user
mappedRoles.workflow_create= admin
mappedRoles.workflow_update= admin
mappedRoles.workflow_delete= admin
mappedRoles.workflow_kill= user
mappedRoles.workflow_run= user
mappedRoles.events_read=user
mappedRoles.events_create=user
#!/bin/bash
#
# rundeckd Startup script for the Launcher install of RunDeck
# paramaters:
# - env vars: [RDECK_BASE, RDECK_PORT, RDECK_JAR]
# - standard RDECK_PORT values: [http: 4440, https: 4434]
# RDECK_BASE must be set and exist
[ -z "$RDECK_BASE" -o ! -d "$RDECK_BASE" ] && {
echo "RDECK_BASE not set or does not exist" ;
#!/bin/bash
#
# rundeckd Startup script for the RunDeck server
#
# description: rundeckd, providing rundeckd
# pidfile: $RDECK_BASE/var/run/rundeckd.pid
# Source installation profile
[ -z "$RDECK_BASE" -o ! -d "$RDECK_BASE" ] && {

User

Dealer: User

A person that initiates Dispatches and perhaps defines and groups them. Users can belong to groups representing roles with responsibilities. See the User as a card dealer issuing card hands to Resources.

Resource

Resource metaphor icon

A network node representing an operating system instance that can receive Dispatches. Resources evaluate these "card hands" and hopefully do not fail. Failing causes the Dealer to bust and end the game round.