Change Delta Brief Description
355 289 Minor cleanups to RT cli tool
356 290 Fixup to rt-setup-database tool for local schema
357 291 Display.html takes TicketObj; Update.html uses it
358 292 localization for link text, not whole link
359 293 ProcessTicketCustomFieldUpdates takes TicketObj
360 294 Transaction batching
363 295 protect against reentrancy in Ticket::DESTROY
365 296 FastCGI fix to make the CLI work
366 297 #4415: Fix for imporeting merged tickets
368 298 Regression and upgrade cleanups
367 299 Ticket creation and updates via the Web UI were sometimes
encoded wrong
369 300 CLI tool should pass through orderby arg
371 302 none
372 303 Decode uuencoded attachments
373 304 Fixing next/prev ticket navigation (#4461) it sometimes disappeared.
375 305 Ticket counts became inaccurate after repeated web searches
376 306 Certain non-western From: headers were being mangled
377 307 Numerous CLI improvements
378 308 Bumping to 3.0.8pre2
379 309 Switching to new I18NSafe lowercasing behaviour for Pg
380 310 Adding a new index doubles my performance on /index.html
381 311 Importing fixes from ourinternet
382 312 Researching email corruption
197 313 Fixing CreaetTickets documentation
383 314 #4572: Fix searching on links
385 315 #4554: callbacks should be ordered
386 316 #4552 arguments for AddCustomFieldValues
387 317 #4455: Better handling of bad link URIs
388 318 #3725: Making CLI display newly created tickets ids
389 319 #3736: Backport RT 3.1 'inplace' layout
390 320 #3813: the CreateTickets scripaction couldn't handle customfields
391 321 #3608: search by ccs and adminccs in addition to requestors
114 322 #3066: crontool docs
393 323 #4711: search ON Dates
392 324 order SelfService tickets by numeric id
395 325 Bumping to 3.0.8RC1
396 326 AutoOpen should set correct type for Status transaction
397 327 Fixing apparent SQL error on logout. Actually bug in localization
21 328 #2587: turn off autocomplete in RT's search box
309 329 #3660: add a 'timeout' flag to the rt-mailgate
315 330 #3608: fixing quicksearch to work with new watcher search
398 331 Allow RT::CurrentUser to load objects based on RT::User
objects passed in; Backported a fix to the Language Selector
for non-traditional languages; bumped to 3.0.8
Change Delta Brief Description
355 289 Minor cleanups to RT cli tool
356 290 Fixup to rt-setup-database tool for local schema
357 291 Display.html takes TicketObj; Update.html uses it
358 292 localization for link text, not whole link
359 293 ProcessTicketCustomFieldUpdates takes TicketObj
360 294 Transaction batching
363 295 protect against reentrancy in Ticket::DESTROY
365 296 FastCGI fix to make the CLI work
366 297 #4415: Fix for imporeting merged tickets
368 298 Regression and upgrade cleanups
367 299 Ticket creation and updates via the Web UI were sometimes
encoded wrong
369 300 CLI tool should pass through orderby arg
371 302 none
372 303 Decode uuencoded attachments
I take it this is the attachment corruption issue?
Change Delta Brief Description
355 289 Minor cleanups to RT cli tool
356 290 Fixup to rt-setup-database tool for local schema
357 291 Display.html takes TicketObj; Update.html uses it
358 292 localization for link text, not whole link
359 293 ProcessTicketCustomFieldUpdates takes TicketObj
360 294 Transaction batching
363 295 protect against reentrancy in Ticket::DESTROY
365 296 FastCGI fix to make the CLI work
366 297 #4415: Fix for imporeting merged tickets
368 298 Regression and upgrade cleanups
367 299 Ticket creation and updates via the Web UI were sometimes
encoded wrong
369 300 CLI tool should pass through orderby arg
371 302 none
372 303 Decode uuencoded attachments
Jesse,
Thanks for the great work and the update. I’m new to RT (relatively) so
I’m curious about the procedure for upgrading. I took a look at the TAR
file and see a bunch of changes to /sbin and /lib files, however it
extracts to a rt-3-0-8 directory. Since the standard, default install
directory is /opt/rt3, what’s the preferred method of installation? I
did look for a README and the RT docs on the website but didn’t see
anything that could be applied.
Just a suggestion, but maybe with RT4 we could go to a directory
structure where each version resides in it’s own directory and then a
sym link from the base directory (root or opt?) takes you to the most
recent
e.g.
[john@localhost rt3]$ ls -l
drwxr-xr-x 2 root root 1024 Nov 2 rt1
drwxr-xr-x 2 root root 1024 Dec 3 rt2
drwxr-xr-x 2 root root 1024 Jan 2 rt3
drwxr-xr-x 2 root root 1024 Jan 31 rt3.0.8
lrwxrwxrwx 2 root root 1024 Jan 31 rt → rt3.0.8
My apologies if this is already possible and I’m just not savy (or
awake) enough to figure it out. I like this method because if an upgrade
goes awry, it’s easy and fast to back out by changing the sym link back.
Read through the UPGRADING document included in this distribution.
It may contain important instructions for updating your database
As root, type:
make install (replace "make" with the local name for
Make, if you need to)
This will build new binaries, config files and libraries without
overwriting your RT database.
It may then instruct you to update your RT system database objects
One last thing to keep in mind: remember to restart Apache. It seems pretty
automatic to do that anyway, but I once upgraded to 3.0.6 on a development
system before my morning coffee and spent about 2 hours trying to figure out
why it was still running on 3.0.2. :)From: Todd Chapman [mailto:rt@chaka.net]
Sent: Monday, January 05, 2004 10:24 AM
To: John Schubert
Cc: RT Users
Subject: Re: [rt-users] RT 3.0.8
Upgrading is mentioned in the README.
5b FOR UPGRADING: (Within the RT 3.0.x series)
Read through the UPGRADING document included in this distribution.
It may contain important instructions for updating your database
As root, type:
make install (replace "make" with the local name for
Make, if you need to)
This will build new binaries, config files and libraries without
overwriting your RT database.
It may then instruct you to update your RT system database objects
Also, there is an UPGRADING document.
-Todd
Jesse,
Thanks for the great work and the update. I’m new to RT (relatively) so
I’m curious about the procedure for upgrading. I took a look at the TAR
file and see a bunch of changes to /sbin and /lib files, however it
extracts to a rt-3-0-8 directory. Since the standard, default install
directory is /opt/rt3, what’s the preferred method of installation? I
did look for a README and the RT docs on the website but didn’t see
anything that could be applied.
Just a suggestion, but maybe with RT4 we could go to a directory
structure where each version resides in it’s own directory and then a
sym link from the base directory (root or opt?) takes you to the most
recent
e.g.
[john@localhost rt3]$ ls -l
drwxr-xr-x 2 root root 1024 Nov 2 rt1
drwxr-xr-x 2 root root 1024 Dec 3 rt2
drwxr-xr-x 2 root root 1024 Jan 2 rt3
drwxr-xr-x 2 root root 1024 Jan 31 rt3.0.8
lrwxrwxrwx 2 root root 1024 Jan 31 rt → rt3.0.8
My apologies if this is already possible and I’m just not savy (or
awake) enough to figure it out. I like this method because if an upgrade
goes awry, it’s easy and fast to back out by changing the sym link back.
Just a suggestion, but maybe with RT4 we could go to a directory
structure where each version resides in it’s own directory and then a
sym link from the base directory (root or opt?) takes you to the most
recent
./configure --prefix=/opt/rt-3.0.8-that-i-installed-tuesday. Same as
with any other package that uses autoconf.
Read through the UPGRADING document included in this distribution.
It may contain important instructions for updating your database
As root, type:
make install (replace "make" with the local name for
^^^^^^^
Typo: make upgrade
Emmanuel Lacour ------------------------------------ Easter-eggs
44-46 rue de l’Ouest - 75014 Paris - France - M�tro Gait�
Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 41 35 00 76 mailto:elacour@easter-eggs.com - http://www.easter-eggs.com
Just a suggestion, but maybe with RT4 we could go to a directory
structure where each version resides in it’s own directory and then a
sym link from the base directory (root or opt?) takes you to the most
recent
./configure --prefix=/opt/rt-3.0.8-that-i-installed-tuesday. Same as
with any other package that uses autoconf.
Incidentally, while the topic of installation is being discussed, what’s
the install-sh script in the root source directory for?
One last thing to keep in mind: remember to restart Apache. It seems pretty
automatic to do that anyway, but I once upgraded to 3.0.6 on a development
system before my morning coffee and spent about 2 hours trying to figure out
why it was still running on 3.0.2.
-----Original Message-----
From: Todd Chapman [mailto:rt@chaka.net]
Sent: Monday, January 05, 2004 10:24 AM
To: John Schubert
Cc: RT Users
Subject: Re: [rt-users] RT 3.0.8
Upgrading is mentioned in the README.
5b FOR UPGRADING: (Within the RT 3.0.x series)
Read through the UPGRADING document included in this distribution.
It may contain important instructions for updating your database
As root, type:
make install (replace "make" with the local name for
Make, if you need to)
This will build new binaries, config files and libraries without
overwriting your RT database.
It may then instruct you to update your RT system database objects
Also, there is an UPGRADING document.
Thanks Mike ( and Jesse). I did see that section in the RT docs online,
but I didn’t think I’d have to recompile, so that was my mistake.
Looking at it a 3rd time, the Makefile should have given it away. My
apologies (again). After spending 4 weeks (on and off) making RT3 work
with RH, I’m leary about any upgrade that doesn’t have an easy back
out. When you recompile, is there a way to back out if things go
wrong?
Just a suggestion, but maybe with RT4 we could go to a directory
structure where each version resides in it’s own directory and then a
sym link from the base directory (root or opt?) takes you to the most
recent
./configure --prefix=/opt/rt-3.0.8-that-i-installed-tuesday. Same as
with any other package that uses autoconf.
Incidentally, while the topic of installation is being discussed, what’s
the install-sh script in the root source directory for?
That is a standard part of the autotools suite. It is used by the
makefiles.
Incidentally, while the topic of installation is being discussed,
what’s the install-sh script in the root source directory for?
Most autoconfiscated packages have it; I believe it can be used in
place of /usr/bin/install if your (antiquated) system doesn’t happen
to include it. It’s just a shell script, the top of the file has some
history on where it came from.
Thanks Mike ( and Jesse). I did see that section in the RT docs online,
but I didn’t think I’d have to recompile, so that was my mistake.
Looking at it a 3rd time, the Makefile should have given it away. My
apologies (again). After spending 4 weeks (on and off) making RT3 work
with RH, I’m leary about any upgrade that doesn’t have an easy back
out. When you recompile, is there a way to back out if things go
wrong?
I always install RT into a fresh directory, in this case, rt-3.0.8, and
then update
httpd.conf
/etc/smrsh/rt-mailgate
/etc/aliases
etc/RT_SiteConfig.pm
to point to the new version.
I do a diff between the old and new unmodified etc/RT_SiteConfig.pm to see
if there’s any new options that I need to take into account.
If there’s a problem, it’s easy to back down to the previous
version.
It’s a little more work, but pretty safe this way.
When you recompile, is there a way to back out if things go
wrong?
In a lazier variation on Blair’s theme, I always install into the same
location, but beforehand I make a copy of the RT web directory. E.g.,
in my case:
cd /usr/local/
sudo cp -Rp rt3 rt3.2004-01-02
I also make sure I have an at-hand backup of the rt database. On top
of my existing automated tape backups, I usually do something like this
right before an upgrade:
cd /usr/local/pgsql
su - postgres
pg_dump rt3 >rt3.2004-01-02.dump
The above commands are specific to my setup.
In addition to modifying RT_SiteConfig.pm as Blair indicates, if you
have made custom versions of any RT files in the ‘local’ subdirectory,
you would want to diff those against the new ones and merge in any
changes. (Do all this before restarting Apache, eh?)
As far as I understand, if you are upgrading from a recent version, you
can often downgrade by just swapping the old web directory back in and
restarting Apache. If the upgrade involved any database changes (which
should be documented, hopefully), then a downgrade would also involve
restoring the database. For the truly paranoid, you would test the new
version of RT using separate Apache and database instances and mail
aliases, etc, before installing it for real. Thankfully my application
doesn’t need that level of robustness. If you have made Perl module
upgrades along with the RT upgrade, there is potential danger there,
but not usually.
I always install RT into a fresh directory, in this case, rt-3.0.8, and
then update
httpd.conf
/etc/smrsh/rt-mailgate
/etc/aliases
etc/RT_SiteConfig.pm
to point to the new version.
I do a diff between the old and new unmodified etc/RT_SiteConfig.pm to see
if there’s any new options that I need to take into account.
If there’s a problem, it’s easy to back down to the previous
version.
It’s a little more work, but pretty safe this way.
Blair,
Thanks! I like your approach, so that’s the way I’ll do it. I have a
long background of military and telecom “operations”, so having a
back-out plan (and doing upgrades outside of business hours) is very
important to me for platform stability reasons. I’ll just add steps to
"cp httpd.conf httpd.last.working.conf" (etc). Doing more prep work
before an upgrade is time well spent in my book, so I don’t mind the
extra work.
In a lazier variation on Blair’s theme, I always install into the same
location, but beforehand I make a copy of the RT web directory. E.g.,
in my case:
cd /usr/local/
sudo cp -Rp rt3 rt3.2004-01-02
I also make sure I have an at-hand backup of the rt database. On top
of my existing automated tape backups, I usually do something like this
right before an upgrade:
cd /usr/local/pgsql
su - postgres
pg_dump rt3 >rt3.2004-01-02.dump
The above commands are specific to my setup.
In addition to modifying RT_SiteConfig.pm as Blair indicates, if you
have made custom versions of any RT files in the ‘local’ subdirectory,
you would want to diff those against the new ones and merge in any
changes. (Do all this before restarting Apache, eh?)
This was one of my fears. I have spent some time customizing the index
and some other pages, so I didn’t want an upgrade to whack the changes.
This is why I liked Blair’s solution. Then I can just “diff” away and
change back anything changed. Your suggestion also gave me the idea of
tarring/zipping, rather than CPing the directory. Either way this gives
me some ideas.
Thanks! I know they’re newbie questions, but I haven’t had to wear my
"sys admin" hat in a couple of years (other than getting RH up and
running). Maybe that’s why I’ve been procrastinating on the MySQL data
backups and looking into upgrading from MySQL 3.23.xx
