[rt-users] RT3.8.8 getting logged out after doing search
Dear all, We recently had a MySQL crash [ due to RAM failure ], after RAM replaced and sessions table dropped and re-created from Schema in rt3.sql dump we are seeing a new problem with searches. When the search is executed the resulting tickets are displayed fine but any attempt to open one results in the RT login screen. If we do login the required ticket is opened. When browsing tickets from the HOME base list this does not happen. Here is an example apache log of the above search: 143.239.74.146 - - [06/Jan/2012:11:36:46 +] GET /Search/Results.html?Format='%20%20%20%3Cb%3E%3Ca%20href%3D%22__WebPath__%2FTicket%2FDisplay.html%3Fid%3D__id__%22%3E__id__%3C%2Fa%3E%3C%2Fb%3E%2FTITLE%3A%23'%2C%0A'%3Cb%3E%3Ca%20href%3D%22__WebPath__%2FTicket%2FDisplay.html%3Fid%3D__id__%22%3E__Subject__%3C%2Fa%3E%3C%2Fb%3E%2FTITLE%3ASubject'%2C%0A'__Status__'%2C%0A'__QueueName__'%2C%0A'__OwnerName__'%2C%0A'__Priority__'%2C%0A'__NEWLINE__'%2C%0A''%2C%0A'%3Csmall%3E__Requestors__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__CreatedRelative__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__ToldRelative__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__LastUpdatedRelative__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__TimeLeft__%3C%2Fsmall%3E'Order=DESC%7CASC%7CASC%7CASCOrderBy=LastUpdated%7C%7C%7CPage=1Query=Status%20%3D%20'new'%20OR%20Status%20%3D%20'open'RowsPerPage=50SavedChartSearchId=newSavedSearchId= HTTP/1.1 200 35950 143.239.74.146 - - [06/Jan/2012:11:37:09 +] GET /Ticket/Display.html?id=16718 HTTP/1.1 200 5267 143.239.74.146 - - [06/Jan/2012:11:37:25 +] POST /Ticket/Display.html HTTP/1.1 200 32802 -- I have cleared old cookies and caches etc Thanks Oliver ubuntu 10.04 perl 5.10.1 apache 2.2.17 mod_perl 2.0.5 [ previously we used mod_perl 2.0.4 ] this is only change since crash. -- Oliver Nash CSSG Computer Science UCC - RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
[rt-users] New install has no 'style'
Hi, I've just installed rt3.8.8 on a Debian Squeeze server. Have got it running, but it displays as text only. http://old.nabble.com/file/p33092601/rt.jpg What have I missed? Thanks, Martin -- View this message in context: http://old.nabble.com/New-install-has-no-%27style%27-tp33092601p33092601.html Sent from the Request Tracker - User mailing list archive at Nabble.com. RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
[rt-users] img html tag in customized search result columns
Hi there! I'm trying to configure RT 4.0.4 on Debian Squeeze In advanced query builder the img tag seems filtered. Is there a good way to use icons in search results? Here an example: -- snip -- '__Status__', '__LastUpdated__', 'ba href=/rt/Ticket/Display.html?id=__idSubject__/a/b/TITLE:Subject', '__QueueName__', 'a href=/rt/Ticket/Display.html?Status=deletedamp;id=__id__ target=_blankimg src=icon-delete.png/a/TITLE: Direkt', '__NEWLINE__', '__UpdateStatus__ /TITLE:Neue', 'small__LastUpdatedRelative__/small', 'small__Requestors__/small', '__OwnerName__', 'a href=/rt/Ticket/Display.html?Status=resolvedamp;id=__id__ target=_blankimg src=icon-resolved.png/a/TITLE: (neues Fenster)' -- snap -- Thanks in advance Regards, Armin Kneip -- Antworten bitte nur über die Liste Für PM ml durch Vornamen ersetzen RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
[rt-users] Solved - New install has no 'style'
OK, found the problem. Needed to add Include /etc/request-tracker3.8/apache2-modperl2.conf RedirectMatch ^/$ /rt/ to the apache2 file. martinmoore wrote: Hi, I've just installed rt3.8.8 on a Debian Squeeze server. Have got it running, but it displays as text only. http://old.nabble.com/file/p33092601/rt.jpg There are no errors in the Apache2 logs. What have I missed? Thanks, Martin -- View this message in context: http://old.nabble.com/New-install-has-no-%27style%27-tp33092601p33092647.html Sent from the Request Tracker - User mailing list archive at Nabble.com. RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
Re: [rt-users] possible RT 4.0.4 attachment bug
OK, this seems to be a relevant portion of the log file. Sorry about the delay
in replying. -Mike
[Thu Dec 15 19:38:48 2011] [warning]: DBD::mysql::st execute failed: Got a
packet bigger than 'max_allowed_packet' bytes at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 587.
(/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm:587)
[Thu Dec 15 19:39:43 2011] [warning]: DBD::mysql::st execute failed: Got a
packet bigger than 'max_allowed_packet' bytes at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 587.
(/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm:587)
[Thu Dec 15 20:38:53 2011] [warning]: DBD::mysql::st execute failed: Got a
packet bigger than 'max_allowed_packet' bytes at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 587.
(/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm:587)
[Thu Dec 15 20:39:49 2011] [warning]: DBD::mysql::st execute failed: Got a
packet bigger than 'max_allowed_packet' bytes at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 587.
(/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm:587)
[Thu Dec 15 21:38:49 2011] [warning]: DBD::mysql::st execute failed: Got a
packet bigger than 'max_allowed_packet' bytes at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 587.
(/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm:587)
[Thu Dec 15 21:39:29 2011] [warning]: DBD::mysql::st execute failed: Got a
packet bigger than 'max_allowed_packet' bytes at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 587.
(/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm:587)
[Thu Dec 15 22:38:49 2011] [warning]: DBD::mysql::st execute failed: Got a
packet bigger than 'max_allowed_packet' bytes at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 587.
(/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm:587)
[Thu Dec 15 22:38:56 2011] [warning]: RT::Handle=HASH(0x2b474a6b16f0) couldn't
execute the query 'INSERT INTO Attachments (Subject, ContentType, Filename,
Headers, MessageId, Creator, Parent, Created, ContentEncoding, Content,
TransactionId) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 600
DBIx::SearchBuilder::Handle::SimpleQuery('RT::Handle=HASH(0x2b474a6b16f0)',
'INSERT INTO Attachments (Subject, ContentType, Filename, Head...', '',
'application/x-zip-compressed', 'antiques_bkup_20111215_1408.zip',
'Content-Description: antiques_bkup_20111215_1408.zip\x{a}content-...', '',
193, 582, ...) called at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 350
DBIx::SearchBuilder::Handle::Insert('RT::Handle=HASH(0x2b474a6b16f0)',
'Attachments', 'Subject', '', 'ContentType', 'application/x-zip-compressed',
'Filename', 'antiques_bkup_20111215_1408.zip', 'Headers', ...) called at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle/mysql.pm line 36
DBIx::SearchBuilder::Handle::mysql::Insert('RT::Handle=HASH(0x2b474a6b16f0)',
'Attachments', 'Subject', '', 'ContentType', 'application/x-zip-compressed',
'Filename', 'antiques_bkup_20111215_1408.zip', 'Headers', ...) called at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Record.pm line 1292
DBIx::SearchBuilder::Record::Create('RT::Attachment=HASH(0x2b475ef06b80)',
'Subject', '', 'Filename', 'antiques_bkup_20111215_1408.zip', 'ContentType',
'application/x-zip-compressed', 'Headers', 'Content-Description:
antiques_bkup_20111215_1408.zip\x{a}content-...', ...) called at
/opt/rt4/sbin/../lib/RT/Record.pm line 304
RT::Record::Create('RT::Attachment=HASH(0x2b475ef06b80)',
'TransactionId', 908, 'ContentType', 'application/x-zip-compressed',
'ContentEncoding', 'none', 'Parent', 582, ...) called at
/opt/rt4/sbin/../lib/RT/Attachment.pm line 193
RT::Attachment::Create('RT::Attachment=HASH(0x2b475ef06b80)',
'TransactionId', 908, 'Parent', 582, 'Attachment',
'MIME::Entity=HASH(0x2b472a166690)') called at
/opt/rt4/sbin/../lib/RT/Attachment.pm line 172
RT::Attachment::Create('RT::Attachment=HASH(0x2b475ef37e40)',
'TransactionId', 908, 'Attachment', 'MIME::Entity=HASH(0x2b472a1586c0)') called
at /opt/rt4/sbin/../lib/RT/Transaction.pm line 543
RT::Transaction::_Attach('RT::Transaction=HASH(0x2b475eea18e0)',
'MIME::Entity=HASH(0x2b472a1586c0)') called at
/opt/rt4/sbin/../lib/RT/Transaction.pm line 160
RT::Transaction::Create('RT::Transaction=HASH(0x2b475eea18e0)',
'ObjectId', 63, 'ObjectType', 'RT::Ticket', 'TimeTaken', 0, 'Type', 'Create',
...) called at /opt/rt4/sbin/../lib/RT/Record.pm line 1447
RT::Record::_NewTransaction('RT::Ticket=HASH(0x2b472a1ca1f0)', 'Type',
'Create', 'TimeTaken', 0, 'MIMEObj', 'MIME::Entity=HASH(0x2b472a1586c0)',
'CommitScrips', 1, ...) called at /opt/rt4/sbin/../lib/RT/Ticket.pm line 676
RT::Ticket::Create('RT::Ticket=HASH(0x2b472a1ca1f0)',
Re: [rt-users] possible RT 4.0.4 attachment bug
On 01/06/2012 12:35 PM, mja...@guesswho.com wrote: OK, this seems to be a relevant portion of the log file. Sorry about the delay in replying. -Mike [Thu Dec 15 19:38:48 2011] [warning]: DBD::mysql::st execute failed: Got a packet bigger than 'max_allowed_packet' bytes at /usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 587. (/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm:587) This error will cause the Attachment creation to fail, which cascades up to the Transaction creation and Ticket creation. All of it is done inside a database-level transaction which is rolled back on failure. The end result is the id sequence is incremented, but no such ticket exists. Such gaps don't cause any problem though. What is your max_allowed_packet? I'll bet it's tiny and should be increased. Thomas RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
[rt-users] mysqlcheck reports table errors
MySQL 5.0.77 (I know it's past EOL and we should upgrade) RT 3.8.5 Recently we had a hiccup with RT, so I ran mysqlcheck and got these errors: rt3.ACL error: Table upgrade required. Please do REPAIR TABLE `ACL` to fix it! rt3.Attributes error: Table upgrade required. Please do REPAIR TABLE `Attributes` to fix it! rt3.Groups error: Table upgrade required. Please do REPAIR TABLE `Groups` to fix it! rt3.Links error: Table upgrade required. Please do REPAIR TABLE `Links` to fix it! rt3.ObjectCustomFieldValues error: Table upgrade required. Please do REPAIR TABLE `ObjectCustomFieldValues` to fix it! rt3.Tickets error: Table upgrade required. Please do REPAIR TABLE `Tickets` to fix it! rt3.Transactions error: Table upgrade required. Please do REPAIR TABLE `Transactions` to fix it! Of course, REPAIR TABLE doesn't work on InnoDB tables, so I eventually dumped and reloaded the RT db. That seemed to fix the problem, but when I ran mysqlcheck on all dbs (-A) I still got error reports. When I ran mysqlcheck -B rt3, no errors, and no errors manually running CHECK TABLE on those tables. OK, so maybe mysqlcheck is buggy. We have observed no data loss or corruption. But it got stranger when I started seeing the same errors on a second RT db on the same MySQL server. Have others observed this issue? I realize this may not be a RT-related issue per se, but it's curious that the errors are only showing up on RT dbs and only on those specific tables, so it would be helpful to from other on this. Thanks, David RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
Re: [rt-users] possible RT 4.0.4 attachment bug
The user had tried to submit a mysqldump that was 20GB as an attachment :) Larger than my max_allowed_packet as you can guess. But I didn't expect RT to increment the id when ticket creation failed. I thought I'd found a bug. The instance is working fine, btw. No ill effects. Thanks for the explanation. Mike -Original Message- From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Thomas Sibley Sent: Friday, January 06, 2012 12:51 PM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] possible RT 4.0.4 attachment bug On 01/06/2012 12:35 PM, mja...@guesswho.com wrote: OK, this seems to be a relevant portion of the log file. Sorry about the delay in replying. -Mike [Thu Dec 15 19:38:48 2011] [warning]: DBD::mysql::st execute failed: Got a packet bigger than 'max_allowed_packet' bytes at /usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 587. (/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm:587) This error will cause the Attachment creation to fail, which cascades up to the Transaction creation and Ticket creation. All of it is done inside a database-level transaction which is rolled back on failure. The end result is the id sequence is incremented, but no such ticket exists. Such gaps don't cause any problem though. What is your max_allowed_packet? I'll bet it's tiny and should be increased. Thomas RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012 RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
Re: [rt-users] possible RT 4.0.4 attachment bug
On Fri, 2012-01-06 at 16:11 -0500, mja...@guesswho.com wrote: The user had tried to submit a mysqldump that was 20GB as an attachment I'm surprised your mail server didn't fall over from that. But I didn't expect RT to increment the id when ticket creation failed. For reference, RT isn't the one incrementing the id -- the database is. This is a side effect of transaction isolation and database integrity. _Not_ doing so would be a bug. - Alex RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
Re: [rt-users] possible RT 4.0.4 attachment bug
Thanks. I knew that mysql had done the id increment - I was sloppy in my language. Sorry about that. And now I know more about how database integrity works. Have a good weekend. -Original Message- From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Alex Vandiver Sent: Friday, January 06, 2012 4:21 PM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] possible RT 4.0.4 attachment bug On Fri, 2012-01-06 at 16:11 -0500, mja...@guesswho.com wrote: The user had tried to submit a mysqldump that was 20GB as an attachment I'm surprised your mail server didn't fall over from that. But I didn't expect RT to increment the id when ticket creation failed. For reference, RT isn't the one incrementing the id -- the database is. This is a side effect of transaction isolation and database integrity. _Not_ doing so would be a bug. - Alex RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012 RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
