Old Release

Icon

This documentation covers an old version of Fedora. Looking for another version? See all documentation.

Skip to end of metadata
Go to start of metadata

Upgrading from 3.4.x to 3.4.2

Version 3.4.2 is a bugfix release and does not require a database or resource index rebuild, nor does it require an upgrade to your configuration if you are upgrading from an earlier 3.4 release. In order to "swap in" the new version of the software, you may:

  1. Shut down your old 3.4.x repository
  2. Install the newer version of Fedora in a different location, but before starting it:
    1. Copy your old server/config/ directory into the new installation's server/config/ directory.
    2. If you are using the legacy llstore implementation instead of Akubra, modify the fedora.fcfg file, ensuring that the object_store_base and datastream_store_base values point to the absolute path of these existing directories. If you'd rather keep the paths relative in the config file, move or copy the content to the matching location in the new installation instead.
    3. If you have previously made changes to the repository-wide XACML policies, copy them into the new repository installation's data/fedora-xacml-policies directory (you will need to create this directory)
  3. Start the new instance of Fedora for the first time.

Upgrading from 3.x to 3.4.2

Akubra low-level storage

Icon

As of Fedora 3.4, Akubra is the default low-level storage implementation. Akubra is not backwards-compatible with the datastream and object storage from previous releases, so when upgrading ensure you select the legacy-fs option for Low level Storage. If you are using an install.properties file ensure you specify the llstore.type=legacy-fs property. A migration utility to migrate from legacy low-level storage to Akubra will be provided in a future release.

  1. Shut down your old 3.x repository
  2. Install the newer version of Fedora in a different location, but before starting it, modify the new fedora.fcfg so that:
    1. It points to your previous 3.x database
    2. The object and datastream paths point to your previous 3.x locations
    3. Note: Due to the Mulgara version upgrade, if you have enabled the Resource Index previously, it will need to be rebuilt.  Therefore, it is unnecessary to point the resource index configuration to the old location.
  3. Start the new repository for the first time.
  4. Shut down the new repository.
  5. If you have previously made changes to the repository-wide XACML policies, copy them into the new repository's XACML directory.
  6. If you previously enabled messaging, and there were messages from your old repository that have not yet been delivered, copy its activemq-data directory over the new activemq-data directory in your new install.
  7. Run the Resource Index Rebuilder.
  8. Restart the new repository