rt/UPGRADING

   1 UPGRADING
   2
   3 Detailed information about upgrading can be found in the README file.
   4 This document is intended to supplement the instructions in that file.
   5
   6 Additional information about upgrading from specific versions of RT is
   7 contained below.
   8
   9 *******
  10 WARNING
  11 *******
  12
  13 Before making any changes to your database, always ensure that you have a
  14 complete current backup. If you don't have a current backup, you could
  15 accidentally damage your database and lose data or worse.
  16
  17 *******
  18
  19 UPGRADING FROM 3.5.7 and earlier - Changes:
  20
  21 Scrips are now prepared and committed in order alphanumerically by description.
  22 This means that you can prepend a number (00, 07, 15, 24) to the beginning of
  23 each scrip's description, and they will run in that order.  Depending on your
  24 database, the old ordering may have been by scrip id number -- if that is the
  25 case, simply prepend the scrip id number to the beginning of its description.
  26
  27
  28 UPGRADING FROM 3.5.1 and earlier - Changes:
  29
  30 The default for $RedistributeAutoGeneratedMessages has changed to
  31 'privileged', to make out-of-the-box installations more resistant
  32 to mail loops. If you rely on the old default of redistributing to
  33 all watchers, you'll need to set it explicitly now.
  34
  35
  36 UPGRADING FROM 3.3.14 and earlier - Changes:
  37
  38 The "ModifyObjectCustomFieldValues" right name was too long. It's been changed to
  39 "ModifyCustomField"
  40
  41
  42 UPGRADING FROM 3.3.11 and earlier - Changes:
  43
  44 = Rights Changes =
  45
  46 Custom Fields now have an additional right "ModifyCustomField".
  47 This right governs whether a user can modify an object's custom field values
  48 for a particular custom field. This includes adding, deleting and changing values.
  49
  50
  51 UPGRADING FROM 3.2 and earlier - Changes:
  52
  53 = Rights changes =
  54
  55 Now, if you want any user to be able to access the Admin tools (a.k.a.
  56 the Configuration tab), you must grant that user the "ShowConfigTab"
  57 right.  Making the user a privileged user is no longer sufficient.
  58
  59 "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.
  60
  61
  62
  63 UPGRADING FROM 3.0.x - Changes:
  64
  65 = Installation =
  66
  67 We recommend you move your existing /opt/rt3 tree completely out
  68 of the way before installating the newversion of RT, to make sure
  69 that you don't inadvertently leave old files hanging around.
  70
  71 = Rights changes =
  72
  73 Now, if you want RT to automatically create new users upon ticket
  74 submission, you MUST grant 'Everyone' the right to create tickets.
  75 Granting this right only to "Unprivileged Users" is now insufficient.
  76
  77
  78 = FastCGI configuration =
  79
  80 This section is a snapshot of the documentation available at:
  81
  82 http://wiki.bestpractical.com/index.cgi?FastCGIConfiguration
  83
  84 It's worth checking out that resource if these instructions don't
  85 work right for you
  86
  87
  88 RT 3.2 includes a signficant change to the FastCGI handler. It is
  89 no longer "setgid" to the RT group.  Perl's setid support has been
  90 deprecated for the last several releases and a number of platforms
  91 don't bundle the "sperl" or "suidperl" executable by default.
  92 Additionally, when perl is run SetUID or SetGID, the interpreter
  93 is automatically switched into /taint mode/, in which all incoming
  94 data, no matter the source is considered suspect. At first, this
  95 seems like a great idea. But perl's taint mode is a big sledgehammer
  96 used to hit small nails.  Many perl libraries aren't tested in taint
  97 mode and will fail when least expected.  Moving away from a SetGID
  98 FastCGI handler will enable more users to have a smoother RT
  99 experience.  It does require some changes in how you set up and
 100 configure RT.
 101
 102 Beginning with RT 3.2, you have several choices about how to configure
 103 RT to run as a FastCGI:
 104
 105
 106 == Install RT as the user your webserver runs as ==
 107
 108 Pros: Very easy to configure
 109
 110 Cons: Your webserver has access to RT's private database password
 111
 112
 113 === How To
 114
 115 When installing RT, run:
 116
 117  ./configure --with-web-user="webuser"  --with-web-group="webgroup"  \
 118     --with-rt-user="webuser" --with-rt-group="webgroup"
 119
 120 (Don't forget to include other configuration options that matter to you)
 121
 122 If you're using apache, you'll want to add something like the following
 123 to your httpd.conf:
 124
 125  <VirtualHost rt.example.com>
 126
 127     # Pass through requests to display images
 128     Alias /NoAuth/images/ /opt/rt3/share/html/NoAuth/images/
 129
 130     # Tell FastCGI to put its temporary files somewhere sane.
 131     FastCgiIpcDir /tmp
 132
 133     FastCgiServer /opt/rt3/bin/mason_handler.fcgi -idle-timeout 120
 134
 135     AddHandler fastcgi-script fcgi
 136     ScriptAlias / /opt/rt3/bin/mason_handler.fcgi/
 137
 138  </VirtualHost>
 139
 140
 141 == Make your webserver user a member of the "rt" group ==
 142
 143 Pros: Easy to configure
 144
 145 Cons: Your webserver has access to RT's private database password
 146
 147
 148 === How To
 149
 150 Install RT normally. Add whichever user your webserver runs as
 151 (whatever you set --with-web-user to) to the "rt" group (whatever
 152 you set --with-rt-group to) in /etc/groups.
 153
 154 To find out what user your webserver runs as, look for the line
 155
 156   User some-user-name
 157
 158 in your apache httpd.conf. Common values are www, www-data, web and nobody.
 159
 160
 161
 162 == Run RT using _suexec_ or a similar mechanism
 163
 164
 165 Pros: More secure
 166
 167 Cons: Sometimes very difficult to configure
 168
 169 Apache's _suexec_ utility allows you run CGI programs as specific
 170 users. Because that's a relatively heavy responsibility, it's very,
 171 very conservative about what it's willing to do for you. On top of
 172 that, Apache's mod_fastcgi plugin doesn't respect all of suexec's
 173 features.  While suexec is designed to execute CGI scripts in a
 174 given virtual host's !DocumentRoot, It can only execute FastCGI
 175 scripts in the system's *main* !DocumentRoot.
 176
 177 This means you have to copy the RT FastCGI handler into your main
 178 !DocumentRoot
 179
 180 The following example !VirtualHost will run RT as a FastCGI on
 181 Apache 1.3 on a Debian Linux server.
 182
 183
 184  <VirtualHost rt.example.com>
 185
 186    DocumentRoot /opt/rt3/share/html
 187
 188     # Set the rt user and group as the executing user for this virtual host
 189     User rt
 190     Group rt
 191
 192
 193     # Pass through requests to display images
 194     Alias /NoAuth/images/ /opt/rt3/share/html/NoAuth/images/
 195
 196     # Tell FastCGI to put its temporary files somewhere sane.
 197     FastCgiIpcDir /tmp
 198
 199     # Tell FastCGI that it should use apache's "suexec" binary to call any
 200     # FastCGI script.
 201     # This is a GLOBAL setting
 202     FastCgiWrapper /usr/lib/apache/suexec
 203
 204     # You need to copy the rt mason_handler.fcgi into a directory inside
 205     # the main server DocumentRoot
 206     # That directory must be owned by the user and group that will execute
 207     # the FastCGI script
 208     # In this case, that directory is /var/www/rt
 209
 210     # To find the local DocumentRoot, run "suexec -V" as root and look for the
 211     #  -D DOC_ROOT parameter.
 212
 213     # Apache 1.3 discards the user and group parameters on the FastCgiServer
 214     # line. Apache 2.0 requires them.
 215
 216     FastCgiServer /var/www/rt/mason_handler.fcgi -idle-timeout 120 -user rt -group rt
 217
 218     AddHandler fastcgi-script fcgi
 219     ScriptAlias / /var/www/rt/mason_handler.fcgi/
 220
 221  </VirtualHost>
 222