[rt-users] software versions question
Herb Commodore
herb at oit.duke.edu
Tue Jan 4 10:49:48 EST 2005
I just got through migrating from RT 3.0.11 on a Centos 3.3 box
running MySQL 3.23.58-2.3 and httpd-2.0.46-44.ent.centos.2 to RT 3.2.2
on a different machine with the same software. httpd-2.0.46 is
Apache2. We've been running RT under apache 2 for a few months now
without trouble, using FastCGI.The problems and solutions I
encountered in this migration:
Permissions & owner for the fastcgi tmp directory: httpd was bombing
because it could not write to the fastcgi/dynamic directory. I ended
up making those two directories mode 777 owned by apache:apache. (rt3 is a
member of the apache group). Yes, the mode is not conducive to
filesystem security, but we don't allow anyone else on the box. (and
if anyone unauthorized does make it to the machine, I don't think the
mode on a directory really matters to those intruders).
Database errors: [error] [client 152.3.XXX.XXX] FastCGI: server
"/opt/rt3/bin/mason_handler.fcgi" stderr: DBD::mysql::db rollback
failed: Warning: Some non-transactional changed tables couldn't be rolled back at /usr/lib/perl5/site_perl/5.8.3/DBIx/SearchBuilder/Handle.pm line 716., referer: https://machine.duke.edu/rt3/Ticket/Display.html?id=12469
Solution: our old RT3 database tables were of the type MyISAM and, Innodb
is not enabled by default with FC2/Centos 3.3/Redhat's mysql-server
3.23 package. /etc/my.cnf needed to be mofied (example only, very
system dependant with regards to memory size):
# RT3 uses InnoDB
innodb_data_file_path=ibdata1:500M:autoextend
set-variable=innodb_buffer_pool_size=1G
set-variable=innodb_additional_mem_pool_size=20M
and the sql server restarted. See the documentation on dev.mysql.org
on the various Innodb variables which can be tuned to your specific
installations.
Then all of the tables needed to have their table types changed from
MyISAM to Innodb. You can cut and paste the following and then do:
mysql -u <foo> -p rt3 < alter_tables.txt
alter table ACL type=Innodb;
alter table Attachments type=Innodb;
alter table CachedGroupMembers type=Innodb;
alter table CustomFieldValues type=Innodb;
alter table CustomFields type=Innodb;
alter table GroupMembers type=Innodb;
alter table Groups type=Innodb;
alter table Links type=Innodb;
alter table Principals type=Innodb;
alter table Queues type=Innodb;
alter table ScripActions type=Innodb;
alter table ScripConditions type=Innodb;
alter table Scrips type=Innodb;
alter table Templates type=Innodb;
alter table TicketCustomFieldValues type=Innodb;
alter table Tickets type=Innodb;
alter table Transactions type=Innodb;
alter table Users type=Innodb;
alter table sessions type=Innodb;
Depending on when you ran the "upgrade" scripts specified in the RT
documentation, you might also have to alter the Attributes table as
well. MySQL does not tell you if it can not create a table of the type
Innodb; if its not able to create that type, it will silently create
the tables of type MyISAM.
Problem: Testing installation of RT. Initial tests were done via incoming
mail from address foo at . User baz which logged into the web inteface was
recognized by RT has having mail address foo at . When baz tried to update
tickets created by foo@, expecting an email message to be generated,
RT failed, stating no recipients were found.
Solution: multiple bogus accounts created to send mail to RT and baz was
able to answer w/o problem. I probably could have changed
Set($NotifyActor, 0) in RT_SiteConfig.pm, but, in the end, it would
not have allowed the thoroughness of testing with multiple accounts.
Hope this helps someone...
-- Herb
"Quark IT - Hilton Travis" <hilton at quarkit.com.au> writes:
> Hi Stephen,
>
> > -----Original Message-----
> > From: rt-users-bounces at lists.bestpractical.com
> > [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf
> > Of Stephen Hancock
> > Sent: Tuesday, 4 January 2005 06:47
> >
> > Since RT 3.2.3 is due out this week and soon to be
> > followed by 3.2.4, will they be supporting mysql
> > 4.1x now? Will there be any other changes in
> > software version support?
> >
> > Maybe support is the wrong way to phrase this.
> >
> > Are there still problems with the newer versions of
> > mysql? (specifically) and other programs. While
> > support may not be available for them, I am really
> > interested in whether the apps will run under the
> > new versions or not. There is much conflicting
> > information on versions and configurations
> > throughout the Wiki docs and the README's.
>
> I agree with the conflicting information in the documentation - for a
> person such as myself - who is infinitely more comfortable getting my
> hands dirty with an AD configuration and design than compiling packages
> on a Linux box (however, not shy to try), the contradictions make RT
> rather difficult to come to grips with. For example, "use apache 2"
> then "don't use apache 2" and "use the latest mysql" versus "don't use
> mysql 4.1.x" and the "create a Linux group called 'rt'" to the debian
> package not actually creating this group upon installation, and also the
> Debian install instructions themselves not being too sure if they were
> written for postgresql or mysql as the *default* database.
>
> If we could clear this up (and I say "we" because I'm interested in
> helping where I can if RT proves to be the product Quark IT will use)
> then RT would likely become an easier application to install, resulting
> in less "newbie" questions asking about the basics that *should* be
> covered clearly in the docs.
>
> --
>
> Regards,
>
> Hilton Travis Phone: +61 (0)7 3344 3889
> (Brisbane, Australia) Phone: +61 (0)419 792 394
> Manager, Quark IT http://www.quarkit.com.au
> Quark AudioVisual http://www.quarkav.net
>
> http://www.threatcode.com/ <-- its now time to shame poor coders
> into writing code that is acceptable for use on today's networks
>
> War doesn't determine who is right. War determines who is left.
>
> This document and any attachments are for the intended recipient
> only. It may contain confidential, privileged or copyright
> material which must not be disclosed or distributed.
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> Be sure to check out the RT wiki at http://wiki.bestpractical.com
>
--
Herb Commodore <herb at oit.duke.edu> +1.919.660.6951
IT Security Office, OIT, Duke University
Box 90132, Durham NC 27708-0132 USA
More information about the rt-users
mailing list