head	1.12;
access;
symbols;
locks; strict;
comment	@# @;


1.12
date	2001.07.21.00.10.18;	author stack;	state Exp;
branches;
next	1.11;

1.11
date	2001.07.10.23.19.09;	author stack;	state Exp;
branches;
next	1.10;

1.10
date	2001.06.23.00.11.34;	author stack;	state Exp;
branches;
next	1.9;

1.9
date	2001.06.23.00.05.26;	author stack;	state Exp;
branches;
next	1.8;

1.8
date	2001.06.22.17.24.02;	author stack;	state Exp;
branches;
next	1.7;

1.7
date	2001.06.12.16.03.09;	author stack;	state Exp;
branches;
next	1.6;

1.6
date	2001.06.01.18.33.22;	author stack;	state Exp;
branches;
next	1.5;

1.5
date	2001.06.01.01.20.32;	author stack;	state Exp;
branches;
next	1.4;

1.4
date	2001.05.30.17.47.04;	author stack;	state Exp;
branches;
next	1.3;

1.3
date	2001.05.16.19.17.04;	author stack;	state Exp;
branches;
next	1.2;

1.2
date	2001.05.14.19.51.41;	author stack;	state Exp;
branches;
next	1.1;

1.1
date	2001.05.14.18.51.12;	author stack;	state Exp;
branches;
next	;


desc
@@


1.12
log
@Made reference to evans changedomain doc.
@
text
@<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
                                                                        
              
  <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  <title>Tigris Migraitons and Upgrades</title>
   
</head>
 <body>
<div >
<h1>Tigris Migration and Upgrade Process</h1>
</div>
<p><b>Date:</b> $Date: 2001/07/10 23:19:09 $</p>
<p><b>Synopsis: </b> Migration and upgrade processes, scripts, FAQs, and documentation 
are under continual development.  This page serves as the home page 
off which links to these objects hang.</p>
<h2>Table of Contents</h2>
<ol>
  <li><a href="#1.0">Introduction</a></li>
  <ol>
    <li><a href="#1.1">Inputs</a></li>
    <li><a href="#intro_def">Definitions, Acronyms, and Abbreviation</a></li>
    <li><a href="#intro_axioms"></a><a href="#1.3">Axioms</a></li>
  </ol>
  <li><a href="#HOWTOS">HOW-TOs: Migration and Upgrade Steps</a></li>
  <li><a href="#troubleshooting">Troubleshooting</a></li>
    <ol> 
        <li><a href="#iz_perms">Issuezilla permissions problems</a></li> 
    </ol>
  <li><a href="#scenarios">War Stories</a></li>
  <ol>
    <li><a href="#sitecopy">Making a Copy of Production Site</a></li>
  </ol>
</ol>
<hr align="Left" width="100%" size="2">
<h2><a name="1.0"></a>1.0 Introduction</h2>

<p>A migration and/or upgrade comprises multiple steps.  Depending
upon your tigris configuration, your upgrade/migration target, 
customizations, and your network setup, the steps to execute will vary 
though the order in  which you run them will generally follow 
the order outlined in the scenario below.  Read over this 
outline to give yourself a high-level notion of whats 
involved upgrading/migrating tigris.</p>

<p>In the following, we move and upgrade a running tigris site, 
deploy on new hardware giving the new instance a name that differs 
from the original (From  TIGRIS.ORG to STAGING.TIGRIS.ORG).</p>

<ol>
  <li>Install the desired version of sourcecast on the TARGET machine.
           Check it works then shut it down. </li>
  <li>Stop the SOURCE running instance:  Stop tigris, qmail, and cvs (But not mysql).</li>
  <li>Take a dump of the SOURCE mysql database.</li>
  <li>Make a copy of the SOURCE SANDBOX/data directory.  This directory holds 
          mail related data, the cvs repository, fileserver data, etc.</li>
  <li>Stop the TARGET instance of tigris.  Also stop the cron job that 
     calls eyebrowse on the TARGET machine and shutdown qmail. </li>
  <li>Copy the SOURCE SANDBOX/data directory and the database dump to the 
          TARGET machine, into a location that is other than their final
          resting place.</li>
  <li>Deploy the SOURCE SANDBOX/data on the TARGET machine moving aside the
      current data.  Run patch_permissions against the just moved 
      data directory to ensure correct permissions.</li>
  <li>Run the database dump through a filter to change all mentions of TIGRIS.ORG 
          to STAGING.TIGRIS.ORG. </li>
  <li>Load the database into the TARGET machine's database.</li>
  <li>Run migration scripts to carry the SOURCE database up to the database 
          version to suit your TARGET tigris version.</li>
   <li>Run scripts to update the TARGET SANDBOX/data directory and
    to change all TIGRIS.ORG references to STAGING.TIGRIS.ORG.</li>
  <li>Start TARGET tigris.  Start qmail.  Enable eyebrowse.</li>
  <li>Test new site (Mothball the old).</li>
</ol>


<p>The rest of this document fills in details glossed over in the outline
above.  Pick-n-mix to suit your particular migration/upgrade scenario.</p>  

<p>Note that migrating and upgrading tigris, a large application built of 
many components, is not for the faint of heart though w/ the passing of 
time and experience codified in scripts and documentation linked off this
page, those wan will be able to migrate 
w/ the best of them.  The one thing you can do to make success the more 
likely is before executing on any migration/upgrade, work out a detailed 
<b>plan</b> of what you are going to do.  Ensure your plan considers all 
stake-holders, customizations and resources.  Dry-run your plan against 
against a test box; it'll help identify the holes in your scheme.</li>

<h3><a name="1.1"></a>1.1 Inputs</h3>
<ul>
    <li><a href="../scripts.html">How to Use and Write Migration Scripts</a>: This document describes rules and patterns to follow writing migration scripts.  It is also good for an understanding of how the migration scripts work.</li>

  <li><a href="http://helm.tigris.org/migration/migration.html">Moving mail from one server to another</a>.  EDK outline on upgrading mailing lists that is largely subsumed by the below.</li>
  <li><a href="http://helm.tigris.org/migration/upgrade.html">Upgrades (In-Situ)</a>. 
  EDK document on upgrading a site in-situ; the most common scenario on the upgrade parade.</li>
    </ul>

<h3 class="title"><a name="intro_def">1.2 Definitions, Acronyms, and Abbreviation</a></h3>
<ul>
  <li><b>Migration</b>: Moving of a tigris install from one location to another 
        -- usually from one machine to another.</li>
  <li><b>Upgrade</b>: Updating the version of tigris (e.g from tigris version 
        TIGRIS_1_0_2 to TIGIRIS_1_1_1).</li>
</ul>
<h3><a name="1.3"></a>1.3 Axioms</h3>
<ul>

  <li><b>IDs</b>: Keep Project IDs and User IDs the same in the target tigris as they 
  are in the source tigris.  Otherwise, at least, the fileserver layout has to be rewritten
to suit new project/user ids. </li>
</ul>


<h2><a name="HOWTOS">2.0 HOW-TOs: Migration and Upgrade Steps</a></h2>
         The below presentation is piecemeal w/ pieces missing still, 
         in need of tidying w/ interrelationship between steps in need of work.<br>
<ol>

  <li>For <b>dumping tigris databases</b>, see <a href="http://helm.tigris.org/source/browse/helm/scripts/dump_tigris_db.pl">dump_tigris_db.pl</a>. This script will dump the db
  referenced by the SANDBOX/scripts/env.sh currently sourced into your environment (Works
  w/ remote databases).  Pass the '--dir' option to dump the database to other than 
  default location.  Pass the '--dry-run' option to get a reading on the size of the
  database dump.</li>

  <li><b>Moving data between machines</b> can be ornery because of it size:
  the database data dumps and the SANDBOX/data directory are usually large.  Be careful 
  doing the copy.  Check filesystems on target to make sure they can take 
  the pending copy (I was doing a <code>'df -sh DIRECTORY'</code> and 
  <code>'df -H'</code> for looking at the filesystem). Here is an rsync 
  that copies over ssh checksuming copied files.
  <blockquote>
  <pre>% rsync --verbose --checksum --archive --dry-run --rsh=ssh --progress \
      /usr/local/tigris/data stack@@staging.tigris.org:/usr/local/data_from_src</pre>
  </blockquote>
  </li>

  <li>If you are <b>changing the domain</b> as part of your migration/upgrade, 
      e.g. TIGRIS.ORG to STAGING.TIGRIS.ORG, see <a href="http://helm.tigris.org/migration/insitu_namechange.html">Performing an In-Situ Domainname Change</a>.</li>
  <li>For <b>loading the database data</b> into target database, see <a href="http://helm.tigris.org/source/browse/helm/scripts/insert_tigris_db.sh">insert_tigris_db.sh</a>.  Give it a directory of database dump files. It will load them into the database referenced by the SANDBOX/scripts/env.sh currently sourced into your environment. Be careful.  Make sure you're loading data into the right database.</li> 

  <li><b>Upgrading:</b> Run the <a href="http://helm.tigris.org/source/browse/helm/scripts/upgrade_tigris">upgrade_tigris</a> script to move your 
  target from one version of tigris to another.  See 
  upgrade_tigris section of <a href="scripts.html">How to Use and Write Migration Scripts</a>.  <b>Upgrading in-situ</b> is probably the most popular scenario and its given special treatment here 
  in <a href="http://helm.tigris.org/migration/upgrade.html">Upgrades (In-Situ)</a>.  
  Before doing your in-situ upgrade, you'll want to do a practise upgrade 
before you run it against production data.  To do 
this you'll have to set up a copy of production box elsewhere.  This will necessitate your
running through the above steps dumping production data, moving production data, 
changing domain-name from production name to test site name to get site copy working on test box.</li>
  

  <li><b>Cleansing data</b>: Copying production data to a test site, you will want to prevent
  mail generated on the test site going out to users subscribed to the production machine.
  EDK suggests doing the following AFTER the copying of data and the running of migration scripts
  but BEFORE starting up the test site.
    <pre>    # source env.sh:
    # source /usr/local/tigris/scripts/env.sh
    # set all email addresses to some safe acct
    echo 'update HELM_USER set EMAIL="test-acct@@collab.net";' | mysqltigris
    # remove all mailing list subscribers
    DIRS=`find ~/sandbox/data/anzu/domains/sc-dev2.sp.collab.net/projects \
        -type d -name subscribers -maxdepth 5`
    ( for i in $DIRS ; do rm $i/* ; done ) 2>&1 | grep -v 'No such file'
    # add archive addresses for ezmlm lists:
    $SANDBOX/helm/scripts/anzu_admin --op=update</pre>
   </li>

</ol>


<h2><a name="troubleshooting" />3.0 Troubleshooting</h2>
<p>In general, try to fix problems encountered migrating in a non-local-edit way
or at least note in here problems that need addressing.</p>

<h3><a name="iz_perms" />3.1 Issuezilla permissions problems</h3> 

<p>All issuezilla dbs need to be mentioned
    in the mysql db tables else they'll be inaccessible (See logs for error).  You can 
    either grant perms for each db, or can do a blanket grant in following manner: 
    <pre>    mysql> INSERT INTO db VALUES ('localhost','issues_%','tigris','Y','Y','Y','Y','Y','Y','N','Y','Y','Y' );
    Query OK, 1 row affected (0.00 sec)

    mysql> INSERT INTO db VALUES ('127.0.0.1','issues_%','tigris','Y','Y','Y','Y','Y','Y','N','Y','Y','Y');
    Query OK, 1 row affected (0.00 sec)</pre>
</p>

<h2><a name="scenarios"/>4.0 War Stories</h2>
<p>Descriptions of upgrades/migrations that others may benefit from the experiences of others.</p>

<h3><a name="sitecopy" />4.1 Making a Copy of Production Site</h3>
<p>These are rough notes of a copy of a production site done on 05/29/2001.  
Objective was set up of a duplicate of a production site.</p>
    <ol>
        <li><b>Dumping production site db</b>: Coordinate w/ site owners.  Dump will take a toll 
        on running site.  Ran <a href="http://helm.tigris.org/source/browse/helm/scripts/dump_tigris_db.sh">dump_tigris_db.sh</a>.  This script dumps all dbs even those no longer in use (May want to fix
        this sometime).</li>
        <li><b>Filtering db data</b>: Copied db dump directory to the site clone machine 
        (Tarred up the db dump dir and rsynced) and then to change all db references to 
        the production machines url to instead reference the production clone machine, 
        ran <a href="http://helm.tigris.org/source/browse/helm/scripts/datadump_filter.sh">datadump_filter.sh</a>:
            <pre>   % ./helm/scripts/datadump_filter.sh -d ./dump_tigris_db.200105291000 \
        PRODUCTION_MACHINE_DOMAIN CLONE_MACHINE_DOMAIN_NAME</pre></li>

        <li><b>Loading db data</b>: Ran <a href="http://helm.tigris.org/source/browse/helm/scripts/insert_tigris_db.sh">insert_tigris_db.sh</a>. BE SUPER CAREFUL you are referencing the 
        correct machine in your upload.  Danger is that you'll overwrite 
        the wrong db.</li>

        <li><b>Copying data dir</b>: Made a directory <code>/usr/local/tigris/data.production_copy</code>.
        We'll copy the production SANDBOX/data directory to here.  Coordinate w/ the production 
        site owners.  The rsync copy will be a drain on production site.  First ran a dry-run rsync
        to see if any problems copying:
        <pre>   % rsync --verbose --checksum --archive --dry-run --rsh=ssh --progress \
        data clone_user@@clone_box:/usr/local/data.production_copy</pre>
        Then ran actual copy all the time monitoring disk usage:
        <pre>   % rsync --verbose --checksum --archive --rsh=ssh --progress \
        data clone_user@@clone_box:/usr/local/data.production_copy</pre> </li>

        <li><b>Putting in place the data directory on clone</b>: Shut down the clone tigris 
        if running.  Move aside the clone's data directory and put in place the production 
        copy.
            <pre>    % mv /usr/local/tigris/data /usr/local/tigris/data.clone_original
    % mv /usr/local/tigris/data.production_copy /usr/local/tigris/data</pre>
        Run patch_permissions to set all ownerships.
            <pre>    % source /usr/local/tigris/scripts/env.sh
    % /usr/local/tigris/scripts/patch_permissions</pre>
        Next run the <a href="http://helm.tigris.org/source/browse/helm/scripts/domain_change.pl">domain_change.pl</a> script to change the domain under the data directory to instead refer to 
        the clone (rather than production). Stop and start qmail. Run anzu_admin update
        and then anzu_admin reset_archive (TODO: Describe better what there scripts 
        are doing).</li>
        
        <li><b>Ran migration scripts</b>: (Add detail).</li>
        <li><b>Start clone and test to validate successful copy</b></li>
        </ol>



<hr><br>
  $Id: index.html,v 1.11 2001/07/10 23:19:09 stack Exp $<br>
<br>
</body>
</html>
@


1.11
log
@Note on dump_tigris_db.pl (Used to be dump_tigris_db.sh).
@
text
@d14 1
a14 1
<p><b>Date:</b> $Date: 2001/06/23 00:11:34 $</p>
d140 1
a140 15
      e.g. TIGRIS.ORG to STAGING.TIGRIS.ORG, you'll need to change 
      the domain in your database dump files before loading them into 
      the target database and you'll have to change all mentions of 
      domain under SANDBOX/data directory.
       <ol>
        <li>See <a href="http://helm.tigris.org/source/browse/helm/scripts/datadump_filter.sh">datadump_filter.sh</a>. Pass a directory of database dump 
            files, the old domain and the new domain.</li>

    <li>To change the domain under SANDBOX/data, 
        see <a href="http://helm.tigris.org/source/browse/helm/scripts/domain_change.pl">domain_change.pl</a> for fixing domains under anzu and eyebrowse.  
        For changing domain names and upgrading the SANDBOX/data/fileserv directory, 
        see <a href="http://helm.tigris.org/source/browse/helm/scripts/upgrade_fileserver.sh">upgrade_fileserver.sh</a> Read the script before running it (TODO: The latter script suffers in that it does 
        both change-of-domain and upgrade. Script needs to be broken up w/ upgrade script made 
        part of helm migration and the change-of-domain aspect part of <code>change_domain.pl</code>). </li> 
        </ol>
d143 1
a143 1
  <li><b>Upgrading</b>, run the <a href="http://helm.tigris.org/source/browse/helm/scripts/upgrade_tigris">upgrade_tigris</a> script to move your 
d145 8
a152 1
  upgrade_tigris section of <a href="scripts.html">How to Use and Write Migration Scripts</a></li>
a168 1
  
a171 5
<p><b>Upgrading in-situ</b>: See <a href="http://helm.tigris.org/migration/upgrade.html">Upgrades (In-Situ)</a>.  
You'll want to do a practise upgrade in-situ before you run it against production site.  To do 
this you'll have to set up a copy of production box elsewhere.  This will necessitate your
running through the above steps dumping production data, moving production data, 
changing domain-name from production name to test site name to get site copy working on test box.</p>
d240 1
a240 1
  $Id: index.html,v 1.10 2001/06/23 00:11:34 stack Exp $<br>
@


1.10
log
@Formatting
@
text
@d14 1
a14 1
<p><b>Date:</b> $Date: 2001/06/23 00:05:26 $</p>
d121 1
a121 1
  <li>For <b>dumping tigris databases</b>, see <a href="http://helm.tigris.org/source/browse/helm/scripts/dump_tigris_db.sh">dump_tigris_db.sh</a>. This script will dump the db
d123 3
a125 1
  w/ remote databases).</li>
d253 1
a253 1
  $Id: index.html,v 1.9 2001/06/23 00:05:26 stack Exp $<br>
@


1.9
log
@Add edk comment on how to cleanse data of email addresses and subscribers.
@
text
@d14 1
a14 1
<p><b>Date:</b> $Date: 2001/06/22 17:24:02 $</p>
d28 3
d33 1
a33 1
    <li><a href="#sitecopy">Copy of Production Site</a></li>
d187 4
a190 2
<ol>
    <li><b>Issuezilla permissions problems</b>: All issuezilla dbs need to be mentioned
d193 1
a193 1
    <pre>    mysql> INSERT INTO db VALUES ('localhost','issues_%','tigris','Y','Y','Y','Y','Y','Y','N','Y','Y' );
d198 1
a198 2
    </li>
</ol>
d203 1
a203 1
<h3><a name="sitecopy" />Copy of Production Site</h3>
d251 1
a251 1
  $Id: index.html,v 1.8 2001/06/22 17:24:02 stack Exp $<br>
@


1.8
log
@Added war stories and troubleshooting sections.
@
text
@d14 1
a14 1
<p><b>Date:</b> $Date: 2001/06/12 16:03:09 $</p>
d156 17
a180 12
<p><b>TODOs</b>
<ol>
    <li><b>Script to purge production site email addresses</b>: 
    If making a copy of production data, you will probably want to
    purge real email addresses so error messages generated are not 
    sent to the production site host and project owners.  Write scripts
    to purge production site email addresses replacing w/ those for the
    test site.</li>
</ol>
</p>


d247 1
a247 1
  $Id: index.html,v 1.7 2001/06/12 16:03:09 stack Exp $<br>
@


1.7
log
@Added link to edk upgrade in-situ doc.
@
text
@d14 1
a14 1
<p><b>Date:</b> $Date: 2001/06/01 18:33:22 $</p>
d27 5
d49 1
a49 1
  <li>Install the desired target version of sourcecast on the target machine.
d51 3
a53 3
  <li>Stop the source running instance:  Stop tigris, qmail, and cvs.</li>
  <li>Take a dump of the source mysql database (mysql needs to be running).</li>
  <li>Make a copy of the source SANDBOX/data directory.  This directory holds 
d55 4
a58 4
  <li>Stop the target instance of tigris.  Also stop the cron job that 
     calls eyebrowse on the target machine and shutdown qmail. </li>
  <li>Copy the source SANDBOX/data directory and the database dump to the 
          target machine, into a location that is other than their final
d60 1
a60 1
  <li>Deploy the source SANDBOX/data on the target machine moving aside the
d65 4
a68 4
  <li>Load the database into the target machine.</li>
  <li>Run migration scripts to carry the source database up to the database 
          version to suit your target tigris version.</li>
   <li>Run scripts to update the SANDBOX/data directory and
d70 1
a70 1
  <li>Start target tigris.  Start qmail.  Enable eyebrowse.</li>
d85 2
a86 2
stake-holders, customizations and resources.  Dry-run your plan; it'll help 
identify the holes in your scheme.</li>
d92 1
a92 1
  <li><a href="http://helm.tigris.org/migration/migration.html">Moving mail from one server to another</a>.  EDK outline on upgrading mailing lists.</li>
d94 1
a94 1
  EDK document on upgrading a site in-situ; number one scenario on the upgrade parade.</li>
d108 1
a108 1
  are in the soruce tigris.  Otherwise, the fileserver layout has to be rewritten
d146 3
a148 3
        see <a href="http://helm.tigris.org/source/browse/helm/scripts/upgrade_fileserver.sh">upgrade_fileserver.sh</a> Read the script before running it (The latter script suffers in that it does both 
        change-of-domain and upgrade. Script needs to be broken up w/ upgrade script made part of helm
        migration and the change-of-domain aspect part of <code>change_domain.pl</code>). </li> 
d157 84
d242 1
a242 1
  $Id: index.html,v 1.6 2001/06/01 18:33:22 stack Exp $<br>
@


1.6
log
@Added a how to do big data copy and upgrade items to the HOW-TO.
@
text
@d14 1
a14 1
<p><b>Date:</b> $Date: 2001/06/01 01:20:32 $</p>
d87 3
a89 1
  <li><a href="http://helm.tigris.org/migration/migration.html">Moving mail from one server to another</a>.</li>
d141 3
a143 1
        see <a href="http://helm.tigris.org/source/browse/helm/scripts/upgrade_fileserver.sh">upgrade_fileserver.sh</a> Read the script before running it (The latter script needs to be integrated into the former). </li> 
d153 1
a153 1
  $Id: index.html,v 1.5 2001/06/01 01:20:32 stack Exp $<br>
@


1.5
log
@Edits. Referenced new scripts for dumping and loading dbs.
@
text
@d14 1
a14 1
<p><b>Date:</b> $Date: 2001/05/30 17:47:04 $</p>
d75 2
a76 1
time and increasing experience, those wan will be able to migrate 
d85 1
a85 1
    <li><a href="../migration.html">How to Use and Write Migration Scripts</a>: This document describes rules and patterns to follow writing migration scripts.  It is also good for an understanding of how the migration scripts work.</li>
d107 2
a108 2
         The below presentation is piecemeal in need of tidying w/ interrelationship
    between steps in need of work.<br>
d111 1
a111 1
  <li>For dumping tigris databases, see <a href="http://helm.tigris.org/source/browse/helm/scripts/dump_tigris_db.sh">dump_tigris_db.sh</a>. This script will dump the db
d115 13
a127 1
  <li>If you are changing the domain as part of your migration/upgrade, 
d129 3
a131 1
      the domain in your database dump files and under the SANDBOX/data directory.
d139 7
a145 6
        see <a href="http://helm.tigris.org/source/browse/helm/scripts/upgrade_fileserver.sh">upgrade_fileserver.sh</a>. </li>
           </ol>
  <li>For loading the database data into target database, see
   <a href="http://helm.tigris.org/source/browse/helm/scripts/insert_tigris_db.sh">insert_tigris_db.sh</a>.  Give it a directory of database dump files. It
   will load them into the database referenced by the SANDBOX/scripts/env.sh
   currently sourced into your environment.</li>
d149 1
a149 1
  $Id: index.html,v 1.4 2001/05/30 17:47:04 stack Exp $<br>
@


1.4
log
@Edit of introduction.
@
text
@d14 1
a14 1
<p><b>Date:</b> $Date: 2001/05/16 19:17:04 $</p>
d32 1
a32 1
upon your tigris configuration, your upgrade/migration objectives, 
d39 3
a41 3
<p>In the following <i>outline</i>, we move and upgrade a running tigris site, 
deploy on new hardware giving the new instance a name that differs from the original 
(From  TIGRIS.ORG to STAGING.TIGRIS.ORG).</p>
a43 3
  <li>Prepare a detailed plan of the steps that will take you through the migration
  and/or upgrade. Ensure it considers all stake-holders, customizations and 
  resources.  Do a dry-run migration/upgrade.</li>
d65 2
a66 2
  <li>Start target tigris.  Start qmail.  Enable eyebrowse.  Test it new site.  Mothball the 
  old.</li>
d69 1
d75 6
a80 2
time and the gathering of experience, those wan will soon migrate 
w/ the best of them.</p> 
d85 2
d93 2
d98 2
a99 1
  <li>Keep Project IDs and User IDs the same in the target tigris as they 
d109 22
a130 16
  <li>How to do a database dump: <pre class="programlisting">    mysqldump -u tigris -peuphrates tigris &gt; /usr/local/to-h47/database/tigris.sql<br>    cd /var/lib//mysql/<br>    for i in issues_*; do echo $i<br>      mysqldump -t -u tigris -peuphrates $i &gt; /usr/local/to-h47/database/$i.sql  <br>    done</pre>
  </li>
  <li>Running the database dump through a filter to change domain name. See 
         <a href="http://helm.tigris.org/source/browse/helm/scripts/datadump_filter.sh">
            datadump_filter.sh</a>.<br>
  </li>
  <li>Running the SANDBOX/data directory through a filter to change domain 
     name references.   To change the domain in mail -- SANDBOX/data/anzu
 and    SANDBOX/data/eyebrowse -- see <a href="http://helm.tigris.org/source/browse/helm/scripts/domain_change.pl">
            domain_change.pl</a>.  For changing domain names and upgrading
 the  SANDBOX/data/fileserv   directory, see <a href="http://helm.tigris.org/source/browse/helm/scripts/upgrade_fileserver.sh">
           upgrade_fileserver.sh</a>. </li>
  <li>Loading the database data into the target database: <pre class="programlisting">      303  . /usr/local/tigris/scripts/env.sh<br>      304  mysql -utigris -peuphrates tigris &lt; <a href="http://helm.tigris.org/source/browse/helm/sql/org/tigris/helm/drop_all_tables.sql">drop_all_tables.sql</a><br>      308  mysql -utigris -peuphrates tigris &lt; /usr/local/from-h16/database/tigris.sql<br>      339  /usr/local/tigris/helm/scripts/populate_issue_dbs <br>      340  cd /usr/local/from-h16/database/<br>      341  for i in issues_*.sql; do echo $i<br>      342    export BN=`basename $i .sql`<br>      343    mysql -utigris -peuphrates $BN &lt; drop_issue_data.sql (To be supplied).<br>      344    mysql -utigris -peuphrates $BN &lt; /usr/local/from-h16/database/$i      <br>      345  done</pre>
  </li>
  <li>Migrating mail: See <a href="http://helm.tigris.org/migration/migration.html">
        Moving mail from one server to another</a></li>
d133 1
a133 1
  $Id: index.html,v 1.3 2001/05/16 19:17:04 stack Exp $<br>
@


1.3
log
@Make link to Leonardr's 'How to Use and Write Migration Script'.  Edits to make this doc. sync better w/ the leonard doc.
@
text
@d14 4
a17 4
<b>Date:</b> $Date: 2001/05/14 19:51:41 $<br>
<b>Synopsis: </b> This page holds links to documentation and scripts for
 migrating <a href="http://www.tigris.org">tigris</a> from one machine to
another and for upgrading tigris to a later version.<br>
a25 1
  <li><a href="#2.0">Migration/Upgrade Process Outline</a></li>
a29 14
Migration and upgrade processes, scripts 
and documentation are under continual development. 
This page serves as the home page 
off which links to these developments -- process descriptions, 
scripts and documentation -- will hang.  
<br>

<br>A migration and/or upgrade comprises multiple steps.  Depending
on your tigris configuration, your upgrade/migration objectives,
and your network setup, the steps to run will vary though the order
in  which you run them will resemble the listing in
<a href="#2.0">Migration/Upgrade Process Outline</a> below.  
The <b><a name="first">first</a> step</b> of any migration/upgrade is work out the steps that 
will take you to your objective.<br>
d31 11
a41 16
<h3><a name="1.1"></a>1.1 Inputs</h3>
<ul>
    <li><a href="../migration.html">How to Use and Write Migration Scripts</a>: This document describes rules and patterns to follow writing migration scripts.  It is also good for an understanding of how the migration scripts work.</li>
    </ul>

<h3 class="title"><a name="intro_def">1.2 Definitions, Acronyms, and Abbreviation</a></h3>
<ul>
  <li><b>Migration</b>: Moving of a tigris install from one location to another 
        -- usually from one machine to another.</li>
</ul>
<h3><a name="1.3"></a>1.3 Axioms</h3>
<ul>
  <li>Keep Project IDs and User IDs the same in source tigris as they are
in the target tigris.&nbsp; Otherwise, the fileserver layout has to be rewritten
to suit new project/user ids. </li>
</ul>
a42 9

<h2><a name="2.0"></a>2.0 Migration/Upgrade Process Outline</h2>
 To help w/ the language that surrounds the links referenced
 below and to help give a high-level notion of whats involved
 upgrading/migrating tigris, here follows an outline 
 of a typical migration and update to a tigris
 site.    In the  following scenario,  we make a copy of a running tigris
 site  and deploy  the copy on   a seperate  hardware giving the new instance
 a name that differs  from the   original (From  TIGRIS.ORG to STAGING.TIGRIS.ORG). <br>
d44 3
d53 2
a54 1
  <li>Stop the target instance of tigris. </li>
d56 2
a57 1
          target machine.</li>
d59 2
a60 3
      current data.  Run scripts to update the SANDBOX/data directory and
to   change   all TIGRIS.ORG references     to STAGING.TIGRIS.ORG.<br>
  </li>
d66 4
a69 1
  <li>Start target tigris.  Test it out.   </li>
d72 24
a95 4
<p>Outlines will vary w/ objectives and setting.  This outline leaves off
 the <a href="#first">first step</a>, the working out of the steps that will 
 take you to your objective.</p> 
     
d98 1
a98 1
<h2><a name="HOWTOS">3.0 HOW-TOs: Migration and Upgrade Steps</a></h2>
d120 1
a120 1
  $Id: index.html,v 1.2 2001/05/14 19:51:41 stack Exp $<br>
@


1.2
log
@Added an axioms section.
@
text
@d11 2
a12 2
<div align="Center">
<h1>Tigris Migrations and Upgrades</h1>
d14 1
a17 1
<b>Date:</b> $Date: 2001/05/14 18:51:12 $<br>
d22 1
a22 1
    <li><a href="#1.1">Setting the Scene</a></li>
d24 1
a24 1
    <li><a href="#intro_def"></a><a href="#1.3">Axioms</a></li>
d26 1
d31 5
a35 3
                      Migration and upgrade scripts and documentation are 
under    active    development.     This page serves as home page off which 
links   to scripts    and documentation     that currently exist hang. <br>
d37 35
a71 13
               A migration and/or upgrade comprises multiple steps.  Depending
   on   your     tigris configuration, your upgrade/migration objectives,
and   your   network     setup, the steps to run will vary though the order
in  which you  run them   should follow, roughly, their listing on this page.
    <br>
<h3><a name="1.1"></a>1.1 Setting the Scene</h3>
               To help w/ the language that surrounds the links referenced
 below    and   to  help w/ some context, here follows a high-level description
 of   whats  involved    doing  a typical migration and update of a tigris
 site.    In the  following    scenario,  we make a copy of a running tigris
 site  and deploy  the copy on   a seperate  hardward giving the new instance
 a name that differs  from the   original (From  TIGRIS.ORG to STAGING.TIGRIS.ORG).
     <br>
d93 8
a100 12
<h3 class="title"><a name="intro_def">1. 2 Definitions, Acronyms, and Abbreviation</a></h3>
<ul>
  <li><b>Migration</b>: Moving of a tigris install from one location to another 
        -- usually from one machine to another.</li>
</ul>
<h3><a name="1.3"></a>1.3 Axioms</h3>
<ul>
  <li>Keep Project IDs and User IDs the same in source tigris as they are
in the target tigris.&nbsp; Otherwise, the fileserver layout has to be rewritten
to suit new project/user ids. </li>
</ul>
<h2><a name="HOWTOS">2.0 HOW-TOs: Migration and Upgrade Steps</a></h2>
d122 1
a122 1
  $Id: index.html,v 1.1 2001/05/14 18:51:12 stack Exp $<br>
@


1.1
log
@Home page for migration and upgrade scripts and docs.
@
text
@d5 1
a5 1
      
d8 1
a8 1
    
d10 1
a10 1
<body>
d15 1
a15 1
migrating <a href="http://www.tigris.org">tigris</a> from one machine to
d17 1
a17 1
<b>Date:</b> $Date$<br>
d24 1
d30 3
a32 3
                    Migration and upgrade scripts and documentation are under 
  active    development.     This page serves as home page off which links 
 to scripts    and documentation     that currently exist hang. <br>
d34 2
a35 2
             A migration and/or upgrade comprises multiple steps.  Depending
  on   your     tigris configuration, your upgrade/migration objectives,
d38 1
a38 1
   <br>
d40 7
a46 7
             To help w/ the language that surrounds the links referenced
below    and   to  help w/ some context, here follows a high-level description
of   whats  involved    doing  a typical migration and update of a tigris
site.    In the  following    scenario,  we make a copy of a running tigris
site  and deploy  the copy on   a seperate  hardward giving the new instance
a name that differs  from the   original (From  TIGRIS.ORG to STAGING.TIGRIS.ORG).
    <br>
d49 1
a49 1
          Check it works then shut it down. </li>
d53 1
a53 1
         mail related data, the cvs repository, fileserver data, etc.</li>
d56 1
a56 1
         target machine.</li>
d58 1
a58 1
     current data.  Run scripts to update the SANDBOX/data directory and
d62 1
a62 1
         to STAGING.TIGRIS.ORG. </li>
d65 1
a65 1
         version to suit your target tigris version.</li>
d71 7
a77 1
       -- usually from one machine to another.</li>
d80 2
a81 2
       The below presentation is piecemeal in need of tidying w/ interrelationship
   between steps in need of work.<br>
d86 2
a87 2
        <a href="http://helm.tigris.org/source/browse/helm/scripts/datadump_filter.sh">
          datadump_filter.sh</a>.<br>
d90 5
a94 5
    name references.   To change the domain in mail -- SANDBOX/data/anzu
and    SANDBOX/data/eyebrowse -- see <a href="http://helm.tigris.org/source/browse/helm/scripts/domain_change.pl">
          domain_change.pl</a>.  For changing domain names and upgrading
the  SANDBOX/data/fileserv   directory, see <a href="http://helm.tigris.org/source/browse/helm/scripts/upgrade_fileserver.sh">
         upgrade_fileserver.sh</a>. </li>
d98 1
a98 1
      Moving mail from one server to another</a></li>
d101 2
a102 1
$Id$<br>
@

