- General
- Interoperability
- Security
-
Technical
- Where are 3rd party resource model providers?
- How do I configure multiple authentication mechanisms?
- How do I configure a SMTP server for email notifications?
- How do I convert my Rundeck config file to groovy?
- How do I Specify a new config file location?
- I see an IOException with a stacktrace coming from
java.io.File.createTempFile - How do I specify a new temp directory for Rundeck?
- Why do I get redirected to
localhost/ why do I have to log in twice? - How do I change the default session timeout duration?
- Why is my PATH or other shell initialization not working?
Rundeck is cross-platform open source software that helps you automate ad-hoc and routine procedures in data center or cloud environments. Rundeck allows you to run tasks on any number of nodes from a web-based or command-line interface. Rundeck also includes other features that make it easy to scale up your scripting efforts including: access control, workflow building, scheduling, logging, and integration with external sources for node and option data.
Rundeck software is free and completely open source. It’s licensed under the terms of the Apache 2.0. Download it. Try it. Use it. If you find value in it and would like to actively participate in the project, introduce yourself on the mailing list or the IRC channel.
Bugs are tracked on Github Issues.
Post messages to google groups: http://groups.google.com/group/rundeck-discuss
At irc.freenode.net #rundeck
You can see the irc logs here: http://irclog.rundeck.org
Download a development build from our jenkins-ci instance here: [[http://build.rundeck.org]]
Rundeck has a few goals of its own:
-
Firstly, we want to create an easy way to define routine sequences as "Job workflows" as a basis for runbook automation solutions.
-
Secondly, enable the integration of node and environment metadata sources as Rundeck "resource model providers". In this way, Rundeck can use Puppet or Chef node data to drive remote execution.
-
Thirdly, evolve role-based access control definitions into a high level DSL that ties privilege level to resource model and workflow actions
-
Lastly, to develop Rundeck into a plugin system supporting the concept of "dispatch providers" to delegate to tools like mcollective, knife, func, fabric, PsExec and others for cross tool execution.
Ultimately, we want to create a tool that is simple to use for the end user of the automated process yet be flexible enough to complement existing tool chains.
For more information see a recent article posted on Rundeck.org: Jenkins is for development, Rundeck is for operations.
Rundeck is not a continuous integration server, and Jenkins is not an ops console. At a high level, Rundeck shares some features with Jenkins since both are able to provide a self serve job interface to automate routine procedures. Rundeck and Jenkins are also able to execute shell scripts on remote nodes to facilitate deployment tasks.
They are complementary tools, and it really comes down to use case. Rundeck is meant as job console for the operations group and is geared to work with that ecosystem of tools.
The jenkins rundeck-plugin provides a two-way bridge between Jenkins and Rundeck, and demonstrates how complimentary the two tools are in a continuous deployment tool chain. Jenkins can handle the build end of the CI loop and triggering Rundeck to provide distributed orchestration across the deployment management tool chain. Rundeck can also trigger Jenkins builds if desired, and pull build artifact information from Jenkins to use as input to Job executions.
We’re designing Rundeck to work on unix flavors and windows. This assumes the commands you execute can run on the targeted host.
Yes, Rundeck server can be configured to use SSL. Consult the Security section in the manual. http://rundeck.org/docs/administration/configuring-ssl.html
Yes, If you have load balancer or reverse proxy, you can let them handle SSL and just do http between them and Rundeck servers:
-
Set up Rundeck as http
-
in profile file, add option -Drundeck.jetty.connector.forwarded=true to RDECK_JVM
-
Set framework.rundeck.url and grails.serverURL to use https
Yes, Rundeck can be configured to authenticate to an LDAP directory service. See http://rundeck.org/docs/administration/authenticating-users.html#active-directory.
HTTP ERROR 403 Problem accessing /rundeck/. Reason: !role
The cause is that there is a "required role" which any user you wish to allow
access to Rundeck must belong to. By default that role name is user (As of
Rundeck 2.0 and earlier). The required role name must be manually changed if you
want a different required role. (In future versions we plan to make this easier
to configure, see Issue #590.)
To modify the required role name, edit the web.xml file:
-
RPM/debian install path:
/var/lib/rundeck/exp/webapp/WEB-INF/web.xml -
Jar/launcher: After running once or executing
--installonly, modify the path$RDECK_BASE/server/exp/webapp/WEB-INF/web.xml-
after modifying the file you must run the launcher jar with
--skipinstallto avoid overwriting the file with the original value
-
Modify the section shown below and replace user with your own required role
name:
<security-role>
<role-name>user</role-name>
</security-role>
Your sudoers file might require a user to run sudo in a login shell (tty allocated). The built in (jsch-based) SSH plugin allocates a TTY if secondary sudo password authentication is set.
These properties are configured in framework.properties configuration file.
Only the CLI tools use these properties to login to rundeck to perform actions for the configured user. The configured user must be allowed to perform the CLI tool actions. Generally, this means it’s a user in the 'admin' group with appropriate ACL policy.
Note, the CLI tools will eventually be refactored to negate this need.
The list is kept here: https://github.com/dtolabs/rundeck/wiki/Resource-model-providers
You can use multiple JAAS loginmodule configurations within a single named JAAS configuration. See Multiple Authentication Modules
You can add configuration to the Rundeck-config.properties file, using the config settings shown under the Grails Mail Plugin "Configuration" section.
Since the default rundeck config file is Java ".properties" format, you will either have to flatten the config hierarchy shown in that document .e.g "grails.mail.host=hostname", or convert your Rundeck config file to Groovy format, and specify the right config file location at Rundeck startup.
The groovy format is a java-like language, and it is not the same as properties. You can either use nested values using curly brackets, or use dot-notation "a.b.c", but since it is not simple text properties, strings have to be quoted.
E.g. : a.b.c="blah" is the same as:
a{
b{
c="blah"
}
}
Also, make sure you put quotes around all string values, but it is not necessary
for true/false or numbers.
#java properties format some.property=value //groovy format: some.property="value"
For the launcher, place the file in the $BASEDIR/server/config dir, and
specify -Drundeck.config.name=rundeck-config.groovy when you run the launcher.
For the rpm/deb, specify a
-Drundeck.config.location=/path/to/rundeck-config.groovy in the
/etc/rundeck/profile JVM arguments. Or if you are using just the war file, put
that in the $CATALINA_OPTS if you are deploying the war to Tomcat for example.
This probably means that your Java Temporary Directory location is unset, or pointing at directory that doesn’t exist, or does not have appropriate permission for Rundeck to modify.
You need to Modify your Temp Directory setting
The default for RPM/DEB is /tmp/rundeck, if it doesn’t exist or does not have
permissions, you may encounter errors.
If you are using the launcher, you will need to add
-Djava.io.tmpdir=/path/to/dir to your Java system properties when you start
the server.
If you installed with the RPM package, modify the /etc/sysconfig/rundeckd
file, and if you installed with the DEB package, modify the
/etc/default/rundeckd file and add:
export RUNDECK_TEMPDIR=/tmp/rundeck
You need to set the grails.serverURL property in your
rundeck-config.properties file to specify a fully qualified domain name for
your server.
Rundeck uses that URL as the base URL for redirects, so you need to change it from localhost after installation. (Related issue #1049)
For Rundeck 3:
See the System Configuration
Use config property server.session.timeout.
For Rundeck 2:
-
edit
/var/lib/rundeck/exp/webapp/WEB-INF/web.xml(change path depending on you Rundeck install) -
find
<session-config> -
raise the timeout:
<session-config> <session-timeout>43200</session-timeout> </session-config>
If you are executing commands to remote nodes that use bash as the login shell, you might not be getting the shell environment you see when logging in interactively. This is because remote commands create a non-interactive shell session.
To illustrate add the following line to your .bash_profile and .bashrc files for a remote user to test.
echo "Reading $BASH_SOURCE"
Next, login as a remote user:
user@rd ~ $ ssh test@centos7 Last login: Fri Jan 12 16:24:26 2018 from linuxmint Reading .bash_profile
Notice the .bash_profile is read. Now log out.
[test@centos7 ~]$ exit logout Connection to centos7 closed.
This time execute a remote command rather than logging in:
user@rd ~ $ ssh -i /home testcentos7 umask Reading .bashrc 0002
This time .bashrc file is read.
So to summarize:
-
For interactive ssh, it will read .bash_profile
-
For non-interactive ssh, will read .bashrc
Rundeck remote command steps result in a non-interactive shell.
You can check this useful link also, Invocation section: https://linux.die.net/man/1/bash