Release Management/Managing servers

Release Management/Internal

Release Management/Backup and availability strategy Release Management/Customizing the Setup Tool Release Management/How to setup Openbravo ERP live testing environment Release Management/Keys Release Management/Managing code.openbravo.com Release Management/Managing servers Release Management/Professional Appliance Calendar Proposal Release Management/Professional Appliance Updates/2.50 Release Management/Rebundling Professional Appliance AMIs Release Management/Smoke test with Hudson Release Management/Testing environments Release Management/Upgrading Demos Release Management/Upgrading Process from Last Release MP to latest to be released OBX Release Management/rPath Management Console Development Release Management/Configuring New Amazon Instance Release Management/System Monitoring with munin/monit

Index

Introduction

The Release Management Team is in charge of managing various servers, mostly powered by Gentoo Linux. This document explains how to keep the servers up to date.

List of servers

These are the production servers RM manages:

• builds.openbravo.com
• code.openbravo.com
• irc.openbravo.com
• issues.openbravo.com

Update process

We use portage to perform the updates. Firstly, get the latest changes in the portage tree:

$ emerge --sync

Then, update the packages in the world:

$ emerge -avquDN world

While doing this check if any thing has to be backed up (configurations, directories with vital data, etc)

The world contains the list of packages explicitly installed by us at some point, excluding the dependencies. For example, if we install package-1, as ass dependency this installs package-2 and package-3 as well, only package-1 is part of the world. That is, it's a list of the packages we want to have in the system. We not interested in package-2 per se, but because we want to have package-1.

Used options:

• a: stands for ask, so that it asks us for confirmation.
• u: stands for update and it updates packages to the best version available.
• D: stands for deep and it forces to consider the entire dependency tree of packages. Not only the packages in the world, but also their dependencies.
• v: stands for verbose, so that is displays useful extra information such as USE flags.
• N: stands for newuse and it tells emerge to include installed packages where USE flags have changed since the last compilation.

Some of the updates included might include updates in the configuration files, typically in /etc. Portage notifies the user about this at the end of the update process. Example:

* IMPORTANT: 1 config files in '/etc' need updating.
* See the CONFIGURATION FILES section of the emerge
* man page to learn how to update config files

We use the dispatch-conf utility for this purpose:

$ dispatch-conf

This tool presents the required files, one by one. So when dispatch-conf finds a config file that has a new update the user is provided with a menu of options for how to handle the update. These are the most useful options:

• u: update (replace) the current config file with the new config file and continue. Useful when you 100% accept the new changes.
• z: zap (delete) the new config file and continue. This will keep the old config file. Useful when you 100% accept the old config.
• m: interactively merge the current and new config files.
• q: quit dispatch-conf.

It is usual that the newly upgraded versions of the packages have more or less dependencies than the previous releases. In those cases where it now depends on less packages, we want to get rid of those packages. Portage provides this functionality:

$ emerge -a --depclean

It may also happen that a newly upgraded version of a package breaks another package, because it was built against the old version of that package. As an example, imagine that package-1 installs package-2 as a dependency. At some point package-2 gets an update, and package-1 does not work any more. It would need to be rebuilt to make it work again. For this purpose we use the revdep-rebuild utility, part of the gentoolkit package:

$ revdep-rebuild -- -a

Finally, eix is a program that provides indexed search to the portage tree, many times faster than using emerge -s. The only downside is that it requires updating the database from time to time. It is a short operation and the benefit is higher, so we run it:

$ eix-update

Category: RM Internal Docs