Well, not technically required for Rundeck server so much as heavily frowned upon. You should upgrade, consider Java 7 no longer supported. We may switch to actually requiring it soon.
The new version uses a different storage format ("mv_store") so switching back to 2.6 after creating a DB with 2.7 may not work.
In-place upgrade with the old storage format do seem to work, however if necessary to keep compatibility with an existing older h2 database, you can update your dataSource.url in rundeck-config.properties to add
dataSource.url = jdbc:h2:file:/path;MVCC=true;mv_store=false
;TRACE_LEVEL_FILE=4from the dataSource.url in rundeck-config.properties
We have removed the "rd-*" and "dispatch" and "run" tools from the install, although the "rd-acl" tool is still available.
You should use the new "rd" tool available separately, see https://rundeck.github.io/rundeck-cli/.
rd does require Java 8. (See, gotcha.)
/etc/rundeck/profile was modified and will probably not work with your existing install. (This change was snafu'd into 2.6.10 and reverted in 2.6.11)
If you have customized
/etc/rundeck/profile, look at the new contents and move your custom env var changes to a file in
(This is another change tha had some hiccups in the 2.6.10 release.)
You must now use
@@ (two at-signs) to produce a literal
@ in an inline script when it might be interpreted as a token, i.e.
@word@ looks like a token, but
@word space@ is ok.
You can globally disable inline script token expansion, see framework.properties.
If you are using the default "realm.properties" login mechanism, the default JAAS configuration for file-based authentication will need to be modified to use correct class name in your
Java 7 is now required for Rundeck 2.5, and Java 8 can be used. Java 6 will not work.
A bug in Rundeck previously allowed Jobs to saved with a schedule even if an Option marked "required" did not have a default value. The result was that the scheduler would fail to execute the job silently.
In Rundeck 2.5 this is now considered a validation error when creating or importing the job definition, so any scheduled jobs with required options need to have a default value set.
rd-project -a create -p projectname is executed for an existing project, this will now fail.
This release adds some new DB tables but does not alter the schema of other tables.
Rundeck 2.4 and earlier used the filesystem to store Projects and their configuration. Rundeck 2.5 can now use the DB to store project definition and configuration, but this is not enabled by default.
If you have projects that exist on the filesystem, when you upgrade to Rundeck 2.5, these projects and their configuration files can be automatically imported into the DB. This means that the contents of
project.properties will be copied to the DB, using Rundeck's Storage Facility.
In addition, there is no encryption by default, if you want the contents of your project.properties to be encrypted in the DB, you must configure Storage Converter Plugins to use an encryption plugin. There is now a Jasypt Encryption Plugin included with Rundeck which can be used.
Enable project DB storage:
You can configure Rundeck to use the Database by adding the following to
rundeck-config.properties before starting it up:
When importing previously created filesystem projects, the contents of these files are imported to the DB:
In addition, after importing, the
project.properties file will be renamed to
If desired, you can switch back to using filesystem projects by doing this:
project.properties.importedfile back to
web.xml file has changed significantly from 2.4.x to Rundeck 2.5.x.
For this reason, if you have modified your
web.xml file, located at
/var/lib/rundeck/exp/webapp/WEB-INF/web.xml, for example to change the
<security-role><role-name>user</role-name><security-role>, then you may need to back it up, and re-apply the changes you made after upgrading to 2.5.x.
If you receive a "Service Unavailable" error on startup, and the service.log file contains this message:
Then that means your web.xml file is out of date. Replace it with the one from 2.5 installation, then re-apply your changes to
If you are upgrading from 2.0.x, be sure to perform backups prior to upgrading. This release adds a new DB table but does not alter the schema of other tables.
Project access via API has been improved, and new authorizations are now required for project access. See Adminstration - Access Control Policy.
adminaccess still allows all actions
Example allowing explicit actions:
context: application: 'rundeck' for: resource: - equals: kind: 'project' allow: [create] # allow creating new projects project: - equals: name: 'myproject' allow: [read,configure,delete,import,export,admin] # access to 'myproject' by: group: admin
The storage facility for uploading public/private keys requires authorization to use. The default
apitoken.aclpolicy provide this access, but if you have custom policies you may want to allow access to these actions.
nameto narrow the access
The default apitoken aclpolicy file allows this access:
context: application: 'rundeck' for: storage: - match: path: '(keys|keys/.*)' allow: '*' # allow all access to manage stored keys by: group: api_token_group
Rundeck 2.0 has some under-the-hood changes, so please follow this guide when upgrading from Rundeck 1.6.x.
The first step is always to make a backup of all important data for your existing Rundeck installation. Refer to the Administration - Backup and Recovery section.
The most direct upgrade method is to use the project export/import method and a clean install of Rundeck 2.0.
Before shutting down your 1.6.x installation, perform Project Export for each project you wish to migrate:
/var/rundeck/projects/NAME(RPM/Deb). This includes the project.properties configuration as well as resources files.
Perform a clean install Rundeck 2.0 (no cheating!).
Then Import the projects you exported:
Finally, restore the project files for the imported project.
If you are not doing a clean install, and you want to maintain your JAAS login module configuration, you may have to change your jaas.conf file.
The default jaas-loginmodule.conf file included with Rundeck 1.6.x uses the
org.mortbay.jetty.plus.jaas.spi.PropertyFileLoginModule class. You will have to change your file to specify
$RDECK_BASE/server/config/jaas-loginmodule.conf (launcher install) or
/etc/rundeck/jaas-loginmodule.conf (RPM/Deb install).
If you want to migrate your existing H2 Database, you will have to download an additional jar file to enable upgrading to the newer H2 version used in Rundeck 2.0.
h2mig_pagestore_addon.jar file linked on this page:
Copy the file to
$RDECK_BASE/server/lib (launcher jar) or
/var/lib/rundeck/bootstrap (RPM/Deb install).
Rundeck 2.0 will add some columns to the existing tables, but should allow in-place migration of the mysql database.
However, make sure you take appropriate backups of your data prior to upgrading.