1. In order to fetch a new release of the django datatracker code, simply

check out the appropriate tag from svn::

svn co http://svn.tools.ietf.org/svn/tools/ietfdb/tags/$releasenumber

2. Don't forget to copy $releasenumber/ietf/settings_local.py from the

old release to the new one; otherwise things won't work!

::

cp $oldreleasenumber/ietf/settings_local.py $releasenumber/ietf/

3. Change into the directory of the new release::

cd $releasenumber

It is recommended set up a Python virtual environment

under $releasenumber/env/::

virtualenv env # optional

source env/bin/activate # optional

4. Install requirements (make sure your pip is reasonably fresh first).

The following will install required python modules locally if you

are using a virtualenv, or globally if you are not::

5. Move static files to the appropriate direcrory for serving via CDN::

ietf/manage.py collectstatic

6. Run migrations. Some migrations create files which need to be writeable

by the web servers, so make sure that you're running as wwwrun when

doing this::

sudo su wwwrun -s /bin/bash

source env/bin/activate

ietf/manage.py migrate

^D

7. Run some basic datatracker system checks::

ietf/manage.py check

rm ./web

ln -s $releasenumber web

9. Reload apache::

sudo service apache2 reload

10. It's now also a good idea to go to the datatracker front page::

and then check that it's alive and kicking, and displaying the new release

number at the bottom of the left-side menubar :-)

11. If things **aren't** cool, revert the symlink step, re-pointing the

symlink to the release that was running before the new release, and restart

apache again to roll back to that.

Installing from Scratch

=======================

In addition to the new release deployment instructions above, the

settings_local.py file has to be set up properly, and Apache has to be

configured. Since the IETF datatracker is only intended to be deployed from

scratch once, these instructions don't cover this scenario in any more detail.

The general Django depoloyment instructions are relevant, however.

Sometimes it can prove necessary to patch an existing release. The following

process should be used:

1. Code and test the patch on a development system copy of the production

release which has no other code changes (or on trunk, with no uncommitted

code changes, if it's sufficiently close).

~/src/ietfdb/working $ svn diff > 2013-03-25-ballot-calculation.patch

4. Make a recursive copy of the production code to a new directory, named

with a patch number. Assuming the production code is in 4.43/, and we

have web -> 4.43/::

/a/www/ietf-datatracker $ rsync -a web/ 4.43.p1/

(you could use 'cp -rp' instead, but rsync seems to do this faster).

/a/www/ietf-datatracker $ cd 4.43.p1/

/a/www/ietf-datatracker/4.43.p1 $ patch -p0 \

This should not produce any messages about failing to apply any chunks;

if it does, you probably should go back to 1. and figure

out why.

`General Instructions for Deployment of a New Release`_ .

Additional Version-Specific Instructions

========================================

Version 4.50

------------

Before you run step 3 (migration) of the general instructions, please run some specific

initial migrations with the a --fake argument:

cd $releasenumber

PYTHONPATH=$PWD ietf/manage.py migrate group 0001 --fake

cd ..

Version 4.42

------------

- In order to serve the secretariat tools static pages (such as image, css and js

files) the exceptions to which urls need to be handled by the python-handler

must be updated.

In the datatracker test server, the following configuration has been used to

make apache handle the static files, and Django the dynamic pages. The new

part is the <LocationMatch/> which mentions /secr/. Adapt as needed for ietfa::

----------------

# Logging and document root settings omitted

<Location "/">

PythonPath "['/srv/www/ietfdb'] + sys.path"

SetHandler python-program

PythonHandler django.core.handlers.modpython

SetEnv DJANGO_SETTINGS_MODULE ietf.settings

PythonDebug On

</Location>

<LocationMatch "^/(robots.txt|favicon.ico|images|css|js|media|error)(/|$)">

SetHandler None

</LocationMatch>

# New for secretariat tools:

<LocationMatch "^/secr/(img|css|js|error)">

SetHandler None

</LocationMatch>

<Location "/accounts/login/">

AuthType Digest

AuthName "IETF"

AuthUserFile /var/local/loginmgr/digest

AuthGroupFile /var/local/loginmgr/groups

AuthDigestDomain http://tools.ietf.org/

Require valid-user

</Location>

# Caching and compression settings omitted

----------------

Version 4.40

------------

- (DONE) Add ianasync user with an auth role in the "iana" group and an

rfceditorsync user with an auth role in the "rfceditor" group (don't

think Group(acronym="rfceditor") exists yet); IANA and RFC Editor need

to know the passwords for the poke mechanism

- (DONE) Make sure mailing list for iab-stream@iab.org is up (since we're now

emailing that)

- (DONE) Set rfc_must_published_later_than date in bin/iana-protocols-updates to today

- (DONE) Run the 3 new doc South migrations

- (DONE) New polling scripts, to be run every hour::

web/ietf/bin/iana-changes-updates

web/ietf/bin/iana-protocols-updates

web/ietf/bin/rfc-editor-index-updates (replaces mirror_rfc_index)

web/ietf/bin/rfc-editor-queue-updates (replaces mirror_rfc_queue)

- (DONE) Import old events from IANA::

bin/iana-changes-updates --from="2005-01-01 00:00:00" --to="2013-01-31 00:00:00" --no-email

- (DONE) Pipe IANA review emails to the datatracker. There used to be an action to pipe

such mails to henrik@levkowetz.com, for testing this feature, but I haven't seen

any in a little while, so I don't know if this has broken. Anyway, the iana review

emails should be piped into::

/www/ietf-datatracker/web/ietf/bin/iana-review-email

- (DONE) Tell IANA we're doing this for real now.

Version 4.34

------------

The migration step you do as a part of the release sequence is going to take

quite some time -- probably minutes. It will generate some output while it's

working, too. As long as it doesn't halt and say that something failed or

gave an error, this is as expected, and when it terminates, you should be OK

to continue.

Version 4.21

------------

This release will you to run migrations before moving the link to the new

version and doing the apache reload. I know you have a routine for the steps

needed to deploy a new release by now, but thought I'd mention it, anyway.

If there is any problem at all doing the migrations, then you'll need to

do a fake initial migration, as follows::

web $ PYTHONPATH=PWD ietf/manage.py migrate --fake meeting 0001

and then to the regular migration again.

Version 4.20

------------

Some one-time actions that need to be taken are as follows::

Assuming that the release has been checked out in /a/www/ietf-datatracker/4.20:

cd /a/www/ietf-datatracker/4.20

PYTHONPATH=$PWD ietf/manage.py migrate --fake doc 0001

PYTHONPATH=$PWD ietf/manage.py migrate --fake name 0001

PYTHONPATH=$PWD ietf/manage.py dbshell <<< "delete from django_content_type where app_label='doc'

and model='groupballotpositiondocevent';"

PYTHONPATH=$PWD ietf/manage.py migrate doc || { \

PYTHONPATH=$PWD ietf/manage.py dbshell <<< 'CREATE TABLE `doc_groupballotpositiondocevent`

(`block_comment` longtext NOT NULL, `comment` longtext NOT NULL,

`ad_id` integer NOT NULL, `comment_time` datetime NULL,

`block_comment_time` datetime NULL, `pos_id` varchar(8) NOT NULL DEFAULT "norecord",

`docevent_ptr_id` integer NOT NULL PRIMARY KEY);'

PYTHONPATH=$PWD ietf/manage.py dbshell <<< 'DROP TABLE `doc_ballottype` CASCADE;'

PYTHONPATH=$PWD ietf/manage.py dbshell <<< 'DROP TABLE `doc_ballottype_positions` CASCADE;'

PYTHONPATH=$PWD ietf/manage.py dbshell <<< 'DROP TABLE `doc_ballotdocevent` CASCADE;'

PYTHONPATH=$PWD ietf/manage.py dbshell <<< 'ALTER TABLE `doc_ballotpositiondocevent`

DROP COLUMN `ballot_id` CASCADE;'

}

PYTHONPATH=$PWD ietf/manage.py migrate doc

PYTHONPATH=$PWD ietf/manage.py migrate name

PYTHONPATH=$PWD python ietf/wgcharter/migrate.py | tee -a ~/charter-migration.log