File: UPGRADING

package info (click to toggle)
request-tracker3.6 3.6.1-4+etch1
  • links: PTS
  • area: main
  • in suites: etch
  • size: 9,028 kB
  • ctags: 1,371
  • sloc: perl: 27,270; sh: 671; makefile: 327
file content (222 lines) | stat: -rwxr-xr-x 7,079 bytes parent folder | download | duplicates (3)
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
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
UPGRADING

Detailed information about upgrading can be found in the README file.
This document is intended to supplement the instructions in that file.

Additional information about upgrading from specific versions of RT is
contained below.

*******
WARNING
*******

Before making any changes to your database, always ensure that you have a 
complete current backup. If you don't have a current backup, you could 
accidentally damage your database and lose data or worse.

*******

UPGRADING FROM 3.5.7 and earlier - Changes:

Scrips are now prepared and committed in order alphanumerically by description.
This means that you can prepend a number (00, 07, 15, 24) to the beginning of
each scrip's description, and they will run in that order.  Depending on your
database, the old ordering may have been by scrip id number -- if that is the
case, simply prepend the scrip id number to the beginning of its description.


UPGRADING FROM 3.5.1 and earlier - Changes:

The default for $RedistributeAutoGeneratedMessages has changed to
'privileged', to make out-of-the-box installations more resistant
to mail loops. If you rely on the old default of redistributing to
all watchers, you'll need to set it explicitly now.


UPGRADING FROM 3.3.14 and earlier - Changes:

The "ModifyObjectCustomFieldValues" right name was too long. It's been changed to
"ModifyCustomField"


UPGRADING FROM 3.3.11 and earlier - Changes:

= Rights Changes =

Custom Fields now have an additional right "ModifyCustomField". 
This right governs whether a user can modify an object's custom field values
for a particular custom field. This includes adding, deleting and changing values.


UPGRADING FROM 3.2 and earlier - Changes:

= Rights changes =

Now, if you want any user to be able to access the Admin tools (a.k.a. 
the Configuration tab), you must grant that user the "ShowConfigTab" 
right.  Making the user a privileged user is no longer sufficient.

"SuperUser" users are no longer automatically added to the list of users who can own tickets in a queue. You now need to explicitly give them the "own tickets" right.



UPGRADING FROM 3.0.x - Changes:

= Installation =

We recommend you move your existing /opt/rt3 tree completely out
of the way before installating the newversion of RT, to make sure
that you don't inadvertently leave old files hanging around.

= Rights changes =

Now, if you want RT to automatically create new users upon ticket
submission, you MUST grant 'Everyone' the right to create tickets.
Granting this right only to "Unprivileged Users" is now insufficient.


= FastCGI configuration =

This section is a snapshot of the documentation available at:

http://wiki.bestpractical.com/index.cgi?FastCGIConfiguration

It's worth checking out that resource if these instructions don't 
work right for you


RT 3.2 includes a signficant change to the FastCGI handler. It is
no longer "setgid" to the RT group.  Perl's setid support has been
deprecated for the last several releases and a number of platforms
don't bundle the "sperl" or "suidperl" executable by default.
Additionally, when perl is run SetUID or SetGID, the interpreter
is automatically switched into /taint mode/, in which all incoming
data, no matter the source is considered suspect. At first, this
seems like a great idea. But perl's taint mode is a big sledgehammer
used to hit small nails.  Many perl libraries aren't tested in taint
mode and will fail when least expected.  Moving away from a SetGID
FastCGI handler will enable more users to have a smoother RT
experience.  It does require some changes in how you set up and
configure RT.

Beginning with RT 3.2, you have several choices about how to configure
RT to run as a FastCGI:


== Install RT as the user your webserver runs as ==

Pros: Very easy to configure

Cons: Your webserver has access to RT's private database password
 

=== How To

When installing RT, run:

 ./configure --with-web-user="webuser"  --with-web-group="webgroup"  \ 
    --with-rt-user="webuser" --with-rt-group="webgroup"

(Don't forget to include other configuration options that matter to you)

If you're using apache, you'll want to add something like the following 
to your httpd.conf:

 <VirtualHost rt.example.com>

    # Pass through requests to display images
    Alias /NoAuth/images/ /opt/rt3/share/html/NoAuth/images/
    
    # Tell FastCGI to put its temporary files somewhere sane.
    FastCgiIpcDir /tmp

    FastCgiServer /opt/rt3/bin/mason_handler.fcgi -idle-timeout 120

    AddHandler fastcgi-script fcgi
    ScriptAlias / /opt/rt3/bin/mason_handler.fcgi/
    
 </VirtualHost>


== Make your webserver user a member of the "rt" group ==

Pros: Easy to configure

Cons: Your webserver has access to RT's private database password


=== How To

Install RT normally. Add whichever user your webserver runs as
(whatever you set --with-web-user to) to the "rt" group (whatever
you set --with-rt-group to) in /etc/groups.

To find out what user your webserver runs as, look for the line

  User some-user-name

in your apache httpd.conf. Common values are www, www-data, web and nobody.



== Run RT using _suexec_ or a similar mechanism


Pros: More secure

Cons: Sometimes very difficult to configure

Apache's _suexec_ utility allows you run CGI programs as specific
users. Because that's a relatively heavy responsibility, it's very,
very conservative about what it's willing to do for you. On top of
that, Apache's mod_fastcgi plugin doesn't respect all of suexec's
features.  While suexec is designed to execute CGI scripts in a
given virtual host's !DocumentRoot, It can only execute FastCGI
scripts in the system's *main* !DocumentRoot.

This means you have to copy the RT FastCGI handler into your main
!DocumentRoot

The following example !VirtualHost will run RT as a FastCGI on
Apache 1.3 on a Debian Linux server.


 <VirtualHost rt.example.com>
 
   DocumentRoot /opt/rt3/share/html
 
    # Set the rt user and group as the executing user for this virtual host
    User rt
    Group rt


    # Pass through requests to display images
    Alias /NoAuth/images/ /opt/rt3/share/html/NoAuth/images/
    
    # Tell FastCGI to put its temporary files somewhere sane.
    FastCgiIpcDir /tmp

    # Tell FastCGI that it should use apache's "suexec" binary to call any 
    # FastCGI script.
    # This is a GLOBAL setting
    FastCgiWrapper /usr/lib/apache/suexec

    # You need to copy the rt mason_handler.fcgi into a directory inside 
    # the main server DocumentRoot
    # That directory must be owned by the user and group that will execute 
    # the FastCGI script
    # In this case, that directory is /var/www/rt

    # To find the local DocumentRoot, run "suexec -V" as root and look for the 
    #  -D DOC_ROOT parameter.

    # Apache 1.3 discards the user and group parameters on the FastCgiServer 
    # line. Apache 2.0 requires them.

    FastCgiServer /var/www/rt/mason_handler.fcgi -idle-timeout 120 -user rt -group rt

    AddHandler fastcgi-script fcgi
    ScriptAlias / /var/www/rt/mason_handler.fcgi/
    
 </VirtualHost>