Software versions question

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.

Thanks…

hancocksh.vcf (283 Bytes)

Hi Stephen,

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@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.

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 -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@. User baz which logged into the web inteface was
recognized by RT has having mail address foo@. 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@quarkit.com.au writes:

Hi Stephen,

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@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@oit.duke.edu +1.919.660.6951
IT Security Office, OIT, Duke University
Box 90132, Durham NC 27708-0132 USA

Stephen Hancock wrote:

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?
RT works with MySQL 4.1 as back-end storage!