forked from adamlaska/datatracker
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathINSTALL
More file actions
187 lines (125 loc) · 6.52 KB
/
INSTALL
File metadata and controls
187 lines (125 loc) · 6.52 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
=====================================
Datatracker Installation Instructions
=====================================
General Instructions for Deployment of a New Release
====================================================
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
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/
Change into the directory of the new release and run migrations::
cd $releasenumber
PYTHONPATH=$PWD ietf/manage.py migrate
cd ..
and then re-point the 'web' symlink::
rm ./web; ln -s $releasenumber web
and finally restart apache::
sudo /etc/init.d/apache2 restart
It's now also a good idea to go to the datatracker front page:
http://datatracker.ietf.org/
to check that it's alive and kicking, and displaying the new release
number at the bottom of the left-side menubar :-) -- if not, 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. The general Django depoloyment instructions are relevant, however.
Additional Version-Specific Instructions
========================================
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