IBM Support

Moving ClearDDTS installation from one machine to another

Troubleshooting


Problem

This technote explains how to move an IBM® Rational® ClearDDTS® installation from one machine to another.

Resolving The Problem

The procedure for moving a ClearDDTS (DDTS) database involves the following steps:

  1. Taking the current DDTS database off the DDTS network of connected sites.
  2. Tarring up all the files under the DDTS home directory on the current machine.
  3. Extracting the files into the DDTS home directory on the new machine, then bringing up the new DDTS server.
  4. Bringing the new site up on the same DDTS network as before.
    Note: Steps need to be taken to ensure that the new DDTS installation is properly licensed and that your web server points to the new location for scripts and other files.
    If your DDTS site is connected to several other sites, then you will have to coordinate your activities with the administrators of all those connected sites.

The exact steps are as below:

A. Taking the current site off the DDTS network:

  1. Log in as 'ddts' on the current machine.
  2. Run 'adminbug lsub' to get the list of subscribed projects. You'll need this information later to re-subscribe to these projects in step 4 of part A and steps 2 and 4 of part D.
  3. Run 'adminbug lsit' to get the list of sites to which you are currently connected. You will need this information in step 5 of part A and step 2 of part D.
  4. Run 'adminbug dsub' against each of the projects in step 2.
  5. Run 'adminbug dcon' against each of the sites in step 3. Please note that this will unsubscribe the remote sites from projects owned on the current site, and may take DDTS administrators on those sites by surprise. Therefore, it is best to coordinate this step with them.
  6. Run 'crontab -l' to see which scripts and programs are being run from the DDTS user's crontab. You may want to save this information for step 5 of part C.
  7. Run 'crontab -r' to delete the corntab entries for user 'ddts'.
  8. Make sure that there are no files to be processed in the following directories under ~ddts/spool - bugs.in, net.out, bugmail, dbackend, cm.in, dadmin.in.
  9. Run 'adminbug dsbl' to take the system cleanly off the DDTS network. Allow enough time for the mail messages to be transmitted - ie, wait for all activity in the ~ddts/spool/LOG and ~ddts/spool/ADMINLOG files to come to a halt.


B. Tarring up the current installation:
  1. Log in as root
  2. cd to the DDTS home directory
  3. tar cvf /dev/xxx .
    NOTE: The xxx is a backup device such as a magnetic tape drive and '.' is the current directory (~ddts).

C. Extracting the files on the new machine, and bringing up the DDTS server:
  1. Take the tape to the new machine and go through the standard installation process described in the ClearDDTS Installation and Licensing Guide, with the following exceptions:
  2. in step 2 on p1-7, log in as root, instead of as 'ddts' (su - root)
    1. if your new machine is of a different architecture than your previous one, then make sure that you extract the new platform-specific bin directory from the product CD into the new DDTS home directory, and remove the soft link 'bin', which may still be pointing to the old platform-specific binaries. To extract only the platform-specific bin directory from the product CD, run the command

      tar xvf /cdrom/<OS_subdirectory>/clearddts.tar NEWCLEARDDTS/<platform_specific_bin>

      This will create a directory called NEWCLEARDDTS/<platform_specific_bin>. You can then move this directory one level up in to ~ddts, and then remove the NEWCLEARDDTS directory. The <platform_specific_bin> directories are as follows:

      Solaris:   sol2x_bin
      HP-UX:     hp800_bin
      AIX4.2:    aix4.2_bin
      AIX4.3:    aix4.3_bin
      SGI:       sgi_bin
      DEC:       dec_alpha_bin
    2. Log out as 'root' and log back in as 'ddts', and create a file called 'status' in the directory '~ddts/conf' (touch ~ddts/conf/status), before proceeding past step 4 on p1-7.
    3. If you plan on retaining the same site id as before, save a copy of the file ~ddts/conf/def.seq for (G) below.
    4. run ./ddtsinstall in the current directory (i.e., in the ddts home directory) rather than running NEWCLEARDDTS/ddtsinstall as specified in step 2 on p1-8. Also, make sure that a directory called NEWCLEARDDTS does not already exist in the ddts home directory - if it does, rename it before proceeding.
    5. When prompted with the question "Are you entering an evaluation license?", answer "N", and ignore the License Validation error message that results, for now.
    6. If you were earlier connected to an Oracle database, then the rebuild of the database may fail if the oracle home directory is not visible from the new machine.
    7. If you retained the same site id as before, replace ~ddts/conf/def.seq with the copy you made in step C above.
  3. Ensure that the product is properly licensed.
  4. If you are not planning to move your license server, then all that needs to be done is to change the path to the rational VENDOR daemon in the new ~ddts/license.dat file, such that it points to the new ~ddts/<license_server_architecture_bin>/rational binary
    NOTE: the path needs to be NFS-extended so that it is visible from the license server.
  5. If you are planning to move your license server, Please refer to technote 1250433 to generate the new license keys.
  6. Ensure that your web server is set up properly.
  7. If your web server machine is going to change, as part of installation procedure you should have already changed the Alias and ScriptAlias (or their Netscape Enterprise equivalents) appropriately. Also, if the owner of your web server process (httpd, for example), is going to change, then you have to make sure that all the files under ~ddts/www/user_prefs and under ~ddts/allbinaries are owned by the new user, and that the file ~ddts/conf/http_user has the new userid.

    NOTE: if your web server machine is the same as before, you will need to change a couple of paths in the file ~ddts/www/ddts_main.perl - the very first line should point to NFS extended ~ddts/<web_server_architecture_bin>/wt_perl, the variable INSTALL_HOME should point to the NFS-extended ddts home directory, and the variable INSTALL_BIN should point to the <web_server_architecture_bin> directory. Also, make sure that the owner of the httpd process ('nobody', for example) is also defined on your new ddts server machine, with the same uid and gid as on the web server machine. To check this, you can compare the /etc/passwd files on the 2 machines.

    NOTE: You need to ensure that the system time on your web server machine exactly matches the system time on your ddts server machine. This is to prevent old cached files from being reused by webddts, which could happen if the time on the web server machine is ahead of that on the ddts server machine.
  8. Bring up the DDTS server
    If your web server machine is going to change, then the URL to the attachments, stored in the defect records, has to be changed to reflect the new server name. To do that, run the script "fix_attachments.sh" which may be downloaded from the URL given below:
  9. Download fix_attachments.sh.tar.Z and uncompress/untar it.
  10. Run chmod +x fix_attachments.sh
  11. Run fix_attachments.sh to see its usage

    Note: Since your machine name has changed (and perhaps your site id and ddts email address), you have to make sure that the Submitter-path field in all your defects reflects this change as well. This field can have any one of the following formats (apart from the trivial case of a blank field):

    Submitter-path: XXXyy ddts@domain.com
    Submitter-path: XXXyy ddts%domain.com@M1
    Submitter-path: XXXyy ddts%domain.com%M1@M2

    where M1 and M2 are machine names, and the Submitter-path field may have multiple [Siteid email_address] pairs.

    Next, depending on what elements of this field are changing for you (site id, email address, machine name), you will have to make sure that the changes are reflected in this field for every defect. Since it is difficult to write a general-purpose script that will do all of this, we refer you to ClearDDTS Technical Support for help with specific cases.
  12. Restore your crontab entries (using crontab -e) from step 7 of part A.
  13. Check that your user intefaces are working properly.
    The web user-preferences files need to have the correct home directory as seen from the web server machine (NFS-extended, if necessary). For this, run the following command:
    ~ddts/bin/setdbm setkey -force <username> PDDTS_HOME <path_to_ddts_home_dir>

    Note: You will have to do this for every user preference file under the ~ddts/www/user_prefs directory. For example, you could use the following shell script:

    -------------------------------------------
    #!/bin/sh
    DDTSHOME=<edit to be full path to ~ddts>
    cd $DDTSHOME/www/user_prefs
    for i in *; do
             $DDTSHOME/bin/setdbm setkey -force $i PDDTS_HOME "$DDTSHOME"
    done
    --------------------------------------------


D. Bringing up the new installation on the ddts network:
  1. Set up mail at your new location (if necessary).
    - Make sure that as user 'ddts', you can send email out (to yourself, as a first check), and receive incoming mail. When you send an email to the new ddts email address, it should send an email to the administrator with the Subject line containing the text "Confusing ddts mail". This will indicate that incoming email is being processed by the ddts site.
  2. If your site id changed as part of the installation process, then you need to inform the ddts administrators on all the sites that you were connected to earlier (refer to the saved copy of the submit.sites file from step 3 of part A), to change their export and import files accordingly. In addition, those administrators will have to run 'adminbug mprj' against each of the projects to which you were subscribed (see list in part A, step 2), to change the sites that are allowed to modify defects in that project. (Remote-mod-ok).
  3. Next, run adminbug conn against each of those sites.
  4. Run 'adminbug asub' against each of the projects that you were subscribed to earlier (refer to step 2 of part A). Coordinate this step with each of the administrators of the connected sites, so that they re-subscribe to projects that are owned on your machine (see step 5 of part A).



[{"Product":{"code":"SSSH4K","label":"Rational ClearDDTS"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"General Information","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF027","label":"Solaris"},{"code":"PF015","label":"IRIX"}],"Version":"4.7;4.8","Edition":"","Line of Business":{"code":"","label":""}}]

Historical Number

11709

Document Information

Modified date:
29 September 2018

UID

swg21135069

Page Feedback