Elsware comes with quite a few actions that are ready to go.
This uses pxssh to login to a server over ssh, and saves the logged in session with the clients object. The ssh session object is an instance of elsware.ssh.SSHSession - which is actually just a wrapper around pxssh with shortcuts.
Registered as ‘ssh_login’.
'login':{
'action_class':'ssh_login',
'server':'admin@slicehost',
'password':'mypassword', #optional
'password_in_opt':'ssh_password', #optional
}
Logs out of the active ssh session.
Logs out of an active ssh session.
Registered as ‘ssh_logout’
'logout':{
'action_class':'ssh_logout',
'server':'admin@slicehost',
}
Logs into the server through ssh.
The apache actions help you stop, start, and restart an apache server. It requires a logged in ssh session, and some additional information in your servers’ configuration:
config={
'servers':{
'admin@slicehost':{
'ip':'111',
'user':'admin',
'apache':{ #required
'apachectl':'/usr/bin/apachectl' #required
'sudo':True|False, #optional
}
}
},
#...
}
Optionally apache actions can run with sudo.
Passwords are searched for in the traditional order {(as described here)}, but passwords are also searched for inside of the apache configuration for a server:
config={
'servers':{
'admin@slicehost':{
'ip':'111',
'user':'admin',
'apache':{
'apachectl':'/usr/bin/apachectl'
'sudo':True|False,
'password':'', #optional
'password_in_opt':'', #optional
}
}
},
#...
}
Each apache action should define it’s parameters like this:
'restart':{
'action_class':'apache_restart',
'server':'admin@slicehost',
}
The apache restart action runs apachectl restart on the logged in ssh client.
Registered as ‘apache_restart’.
This action will not perform a rollback, as the opposite of restart is restart.
The git update action cd’s to the target directory on the server, and runs “git pull origin master”. It requires a logged in ssh session.
The repository must already exist on the server - this will not clone a repo for you.
Registered as ‘git_update’.
'update':{
'action_class':'git_update',
'server':'admin@slicehost',
'dir':'/var/www/vhosts/projects/site/',
}
Runs git reset --hard -q COMMIT. Where COMMIT is the head commit object, before the update.
The svn update action cd’s to the target directory on the server, and updates the repo.
The repo should already exist on the server.
Registered as ‘svn_update’.
'svnup':{
'action_class':'svn_update',
'server':'admin@slicehost',
'dir':'/var/www/vhosts/project/',
'force_checkout':True|False
}
By default, the –force option isn’t used. Instead, it cd’s to the target directory, runs rm -rf ./*, and then runs an svn update.
There are still linux distributions that come with subversion 1.4.2, which does not include the –force option. If you know your subversion install supports –force, you can turn on “force_checkout”.
The SCP push action pushes a local directory, up to a server over scp. It requires an available ssh session - over ssh it copies the target directory on the server, as a backup. Then the scp transfer is initiated.
When the action is finalized, the temporary copy on the server is deleted.
Registered as ‘scp’
'scppush':{
'action_class':'scp',
'server':'admin@slicehost',
'localdir':'/Users/aaronsmith/projects/project',
'serverdir':'/var/www/vhosts/projects/project'
}
On rollback, the temporary copy of the original directory on the server is restored.
The SCP push zipped action is pretty much the same as the scp push action, but this one zips up the local file, or directory, pushes it up to the server, then unzips it on the server. It can save a little time and bandwidth.
The FTP push action pushes a local file or directory up to a server over FTP.
The email admins action is specific to django. Generally, you want to put it last in your action chain. If any messages, or exceptions have accrued into self.deployment.messages, an email is sent to settings.ADMINS with those messages.
Registered as ‘email_admins’.
'email':{
'action_class':'email_admins',
'subject':'The subject for my email',
'from':'me@example.com',
}
The stdout action prints accrued messages in self.deployment.messages to stdout.
Registered as ‘print’.
The raise exception action is used for testing transactions. For example, you could define an action chain like this:
...
'slicehost':{
'actions':(
{'transaction':('login','git_update','exception','logout')},
)
}
...
This will cause the action runner to ‘login’, ‘git update’, then raise an exception, which will trigger transactions.
Registered as ‘exception’.
The http request action makes a request to a desired url - optionally given data it will POST to the url. This is a good way to notify, or perform some other actions that some other scripts provide. For example, you may have a php script that restarts a mail server, or sends out emails to a mailing list.
Registered as ‘request’.
'request':{
'action_class':'request',
'url':'http://www.google.com/',
'data':{}, #optional
}