Re: [rt-users] RT Mobile for iPhone (Dustin Collins)
Offline work would be great, but not needed for the first step! - Originalnachricht - Kuehne + Nagel (AG Co.) KG, Geschaeftsleitung: Hans-Georg Brinkmann (Vors.), Dirk Blesius, Reiner Heiken, Bruno Mang, Alfred Manke, Christian Marnetté, Mark Reinhardt, Jens Wollesen, Rainer Wunn, Sitz: Bremen, Registergericht: Bremen, HRA 21928, USt-IdNr.: DE 812773878, Persoenlich haftende Gesellschaft: Kuehne Nagel A.G., Sitz: Contern/Luxemburg Geschaeftsfuehrender Verwaltungsrat: Klaus-Michael Kuehne Von: rt-users-boun...@lists.bestpractical.com rt-users-boun...@lists.bestpractical.com An: John Bartelt bart...@slac.stanford.edu Cc: rt-users@lists.bestpractical.com rt-users@lists.bestpractical.com Gesendet: Tue Jun 29 02:03:19 2010 Betreff: Re: [rt-users] RT Mobile for iPhone (Dustin Collins) As a first step, it would probably be easier to create a special stylesheet to create the illusion of an app. Yes, my first thought was that a mobile stylesheet might make it easier to use RT on a mobile device. It could be done on the server side, rather than the client (but then it's not an app you can sell). It's not that hard to put together a reasonable mobile UI for RT, especially if we start reasonably small. That would have the advantage of working on many platforms instead of just one. How many of you need offline-ability for your mobile RT usage? -Jesse Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Limit users by a non-empty customfield
Kevin Falcone wrote: On Mon, Jun 28, 2010 at 12:05:13PM +0200, Wolfram Huettermann wrote: Hello, I have got a user customfield called MyComment and I want to filter all users where this customfield is not empty. In my case, it is of freefrom type. The function LimitToCustomField does not work properly if I use $User-LimiToCostumField(FIELD = MyComment, OPERATOR = !=, VALUE = ); I assume you meant LimitCustomField, and that doesn't take a FIELD argument -kevin Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Yes, you are totally right. But even this code: $User-LimiToCostumField(CUSTOMFIELD = MyComment, OPERATOR = !=, VALUE = ); does not work. Greetings, Wolfram Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] script : custom action by ticket creation or modification
Hello,
the following scrip works only On transaction but not wen a new
ticket is created.
What is wrong ?
- Condition : User Defined
- Custom condition :
my $trans = $self-TransactionObj;
my $ticket = $self-TicketObj;
if ($trans-Type eq 'CustomField') {
my $cf = new RT::CustomField($RT::SystemUser);
$cf-LoadByName(Queue = $ticket-QueueObj-id, Name =
Qualification sécurité);
return 0 unless $cf-id;
if ($trans-Field == $cf-id $trans-NewValue eq Oui) {
return 1;
}
}
return 0;
Thanks in advance for your help.
Horst
___
Le contenu de ce courriel est uniquement réservé à la personne ou
l'organisme à qui il est destiné. Si vous n'êtes pas le destinataire
prévu, veuillez nous en informer au plus vite et détruire le présent
courriel. Dans ce cas, il ne vous est pas permis de copier ce courriel,
de le distribuer ou de l'utiliser de quelque manière que ce soit.
The content of this e-mail is intended only and solely for the use
of the named recipient or organisation. If you are not the named
recipient, please inform us immediately and delete the present e-mail.
In this case, you are nor allowed to copy, distribute or use this
e-mail in any way.
___
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] pulling AT custom fields into ticket custom fields
Found some code in another thread.
my $AssObj = RTx::AssetTracker::Asset-new(RT-SystemUser);
$AssObj-Load($AssId);
my $AssCFs=$AssObj-CustomFields();
while(my $AssCF = $AssCFs-Next()) {
print $AssCF-Name, : ;
my $AssValues=$AssObj-CustomFieldValues($AssCF-id);
while($AssValues and my $assvalue = $AssValues-Next) {
print $AssValue-Content,\t;
}
print \n;
}
Thanks
Adam
-Original Message-
From: Adam Brown
Sent: Monday, June 28, 2010 1:33 PM
To: 'Todd Chapman'
Cc: rt-users@lists.bestpractical.com
Subject: RE: [rt-users] pulling AT custom fields into ticket custom fields
All scripts and html files that I have seen seem to call the libraries from the
RTx directories.
Ie. RTx::AssetTracker::Assets-new($RT::SystemUser);
Are Asset.pm and Record.pm in ../lib/RTx/AssetTracker/ the place to be looking
or somewhere else?
Thanks
Adam
-Original Message-
From: Todd Chapman [mailto:t...@chaka.net]
Sent: Monday, June 28, 2010 1:28 PM
To: Adam Brown
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] pulling AT custom fields into ticket custom fields
Asset Tracker uses RT's custom field libraries, so that's where to
look for the appropriate methods.
On Mon, Jun 28, 2010 at 1:21 PM, Adam Brown adam.br...@fidessa.com wrote:
I currently have it set up where I have a ticket custom field set up with
all the assets in AT. When creating a ticket it makes the link to the asset
based on the custom field.
I want to set it up now where when a user picks the asset in the CF for the
ticket, a number of custom fields in the ticket will be populated based on
the custom field values from the asset. This way I can query a ticket using
any spec from the asset
I think I can write the scrip but I can't figure out how to extract the
custom field value for a given field on given asset. I can't seem to find
the sub routine in any of the RTx lib files.
Any suggestions?
Adam
**
This message is intended only for the stated addressee(s) and
may be confidential. Access to this email by anyone else is
unauthorised. Any opinions expressed in this email do not
necessarily reflect the opinions of Fidessa. Any unauthorised
disclosure, use or dissemination, either whole or in part is
prohibited. If you are not the intended recipient of this message,
please notify the sender immediately.
**
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] RT Mobile for iPhone (Dustin Collins)
As a first step, it would probably be easier to create a special stylesheet to create the illusion of an app. Yes, my first thought was that a mobile stylesheet might make it easier to use RT on a mobile device. It could be done on the server side, rather than the client (but then it's not an app you can sell). It's not that hard to put together a reasonable mobile UI for RT, especially if we start reasonably small. That would have the advantage of working on many platforms instead of just one. How many of you need offline-ability for your mobile RT usage? -Jesse ME !! It would be very handy for us, since we're always travelling, so access from Blackberry/IPhone/Android/etc. would make things easier. We are currently trying to roll-out RT here and are trying our best with RSS feeds and command-by-email, but an actual mobile RT would be great. Steve Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Slow Ticket History 3.8.8
Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] SetPriority oddities.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone I've been trying to wrap my head around RT for a couple of days now (actually RT-IR). Currently I am trying to add some business logic (yes...scrips :) ). I noted some oddities while trying to set my priority field using custom fields. I can essentially get it to work, but I have not been able to figure out why I run into the problem below. So I made up a very simple scrip to illustrate my point: Condition: on Transaction Action: User defined Global Template: Blank Stage: Transaction Batch Custom action cleanup code: $self-TicketObj-SetPriority (50); Then I set about to test it: 1) Create ticket -- ticket gets created and priority is 50. 2) Edit ticket -- I update anything but the priority in the ticket, just to trigger the script. For instance by changing the tickets subject. -- Save changes -- Priority remains 50. 3) Edit ticket -- this time I update the priority field and set it to, say, 100. The expected outcome: priority will be set to 50 by the script - -- Save changes -- actual outcome: the priority field _seems_ to be set to 100, although the script was triggered (confirmed by using RT::Logger). 4) Now this is where I get confused. Somehow, my script was overruled in 3). However, as soon as I access the ticket again by navigating to the ticket, i.e. clicking on display or selecting the ticket in the left menu bar or otherwise navigating around, the priority will be at 50, without my scrip running again. So my guess is, that my script actually saved the right priority in the database, but didn't update some essential object when displaying the ticket right after pressing 'Save Changes' Does anybody know what is happening here? Please bear in mind that the scrip here just illustrates my point and is not the actual final scrip I want to use in production (which would be setting the priority through several custom fields). Hope somebody has an answer. regards - -- Marc Andersen IT Security Analyst The Danish GovCERT -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMKff0AAoJEOI5XK2IuGDrhHgH/AwO+91nGJtPuLKyPN0DcKQ3 OTkwTKZDOaxXg29y7XQ8bp36ulB28SWKLRycnXsuw5+UCRvIEtyrdf8E7vra9exB ljKyos/13IvvI7oRcWSOvtB4tBxXH2Bd14h7gOZ9UhX3MKyQCdSZAhEl0t2CGhKd 4vb9ie0fCcY+k0TAZd5mtMYZUR4w5CH7t99hUe2TIwpRjNmzx6pzyVGkC8Nl8+ym 0eKw4h26WEvOEHsPHVNWXT/iWo3/0UjrPV/r5vNSA9R+dhfPf5BBfw6dp+6N1zyL XCPpTXXP/KHscRvmjws9GpouhDw5cdobXBqlX0zfMdd7kFDuFggOjpeGsiMBsmQ= =ZDm1 -END PGP SIGNATURE- Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Quite outside of the speed of RT, what database are you using as a back-end? How long has it been since you did some care and feeding of your database? How big are your tables? If you are using mysql or postgres have you used their tools to examine your database, especially the indexes and statistics? This may be an issue with indexes needing to be rebuilt, or asking the database to gather new statistics for the queries your are running. Cheers-- Charles On Jun 29, 2010, at 8:09 AM, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Charles Johnson, Vanderbilt University Advanced Computing Center for Research Education Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203 Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143, Nashville, TN 37212 Office: 615-343-4134 Cell: 615-478-5743 Fax: 615-343-7216 charles.john...@accre.vanderbilt.edu Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Hi Charles, But as far as we can tell from our profiling the time is spent in the perl rendering the ticket, not in the query used to retrieve the ticket and attachments in the first place (which happens once at the start I believe). The loop that renders the ticket history and each attachment takes anything up to 20+ seconds. So I'm not sure how the DB can be an issue here? Unless I'm wrong about it doing 1 big query at the start and there are loads of little queries inside the loop. Cheers, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:14, Charles Johnson wrote: Quite outside of the speed of RT, what database are you using as a back-end? How long has it been since you did some care and feeding of your database? How big are your tables? If you are using mysql or postgres have you used their tools to examine your database, especially the indexes and statistics? This may be an issue with indexes needing to be rebuilt, or asking the database to gather new statistics for the queries your are running. Cheers-- Charles On Jun 29, 2010, at 8:09 AM, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Charles Johnson, Vanderbilt University Advanced Computing Center for Research Education Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203 Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143, Nashville, TN 37212 Office: 615-343-4134 Cell: 615-478-5743 Fax: 615-343-7216 charles.john...@accre.vanderbilt.edu Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Hi, If you are using mysqld have a look at mysqltuner.pl perl script (google) This has fixed quickly many performance issues on both RT and other web-based software we use. I run this every few weeks and apply suggested changes and then simply restart mysqld when things are quite. Regards, Jason Doran Computer Centre NUI, Maynooth On 29 Jun 2010, at 14:09, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Justin, thank you for the kindness of your reply. I didn't intend to send you chasing rabbits, so to speak. Just offering something to add to the checklist of items to be crossed off before digging too deeply into the perl code. If you are convinced that mysql is performing at its best then please ignore my noise! :) Cheers-- Charles On Jun 29, 2010, at 9:18 AM, Justin Hayes wrote: Hi Charles, But as far as we can tell from our profiling the time is spent in the perl rendering the ticket, not in the query used to retrieve the ticket and attachments in the first place (which happens once at the start I believe). The loop that renders the ticket history and each attachment takes anything up to 20+ seconds. So I'm not sure how the DB can be an issue here? Unless I'm wrong about it doing 1 big query at the start and there are loads of little queries inside the loop. Cheers, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:14, Charles Johnson wrote: Quite outside of the speed of RT, what database are you using as a back-end? How long has it been since you did some care and feeding of your database? How big are your tables? If you are using mysql or postgres have you used their tools to examine your database, especially the indexes and statistics? This may be an issue with indexes needing to be rebuilt, or asking the database to gather new statistics for the queries your are running. Cheers-- Charles On Jun 29, 2010, at 8:09 AM, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Charles Johnson, Vanderbilt University Advanced Computing Center for Research Education Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203 Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143, Nashville, TN 37212 Office: 615-343-4134 Cell: 615-478-5743 Fax: 615-343-7216 charles.john...@accre.vanderbilt.edu -- Charles Johnson, Vanderbilt University Advanced Computing Center for Research Education Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203 Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143, Nashville, TN 37212 Office: 615-343-4134 Cell: 615-478-5743 Fax: 615-343-7216 Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Thanks Jason - I'll give that a go as well. We have got a large DB (~10gb) so keeping it tuned is definitely important. However as stated the time seems to be lost in code, after I'd have thought it had run the query for the ticket (though I may be wrong in that assumption). Cheers, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:22, Jason Doran wrote: Hi, If you are using mysqld have a look at mysqltuner.pl perl script (google) This has fixed quickly many performance issues on both RT and other web-based software we use. I run this every few weeks and apply suggested changes and then simply restart mysqld when things are quite. Regards, Jason Doran Computer Centre NUI, Maynooth On 29 Jun 2010, at 14:09, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Upgrading from RT 3.6.5
I'm in the process of trying to upgrade now and I've gotten to the part of updating the database and I get the following error. Can anyone help me? r...@nethealth:/opt/rt3/sbin# ./rt-setup-database --dba root --prompt-for-dba-password --action upgrade In order to create or update your RT database, this script needs to connect to your mysql instance on localhost as root Please specify that user's database password below. If the user has no database password, just press return. Password: Working with: Type: mysql Host: localhost Name: rtdb User: rtuser DBA:root Couldn't finish 'upgrade' step. ERROR: Couldn't read dir './etc/upgrade' with upgrade data The upgrade directory is there, not sure why it can't read it. Of course, I'm not an expert on permissions either. r...@nethealth:/opt/rt3/etc# ls -l total 196 -r 1 root www 90 2010-06-28 15:53 acl.Informix -r 1 root www 859 2010-06-28 15:53 acl.mysql -r 1 root www 27 2010-06-28 15:53 acl.Oracle -r 1 root www1912 2010-06-28 15:53 acl.Pg -r 1 root www 232 2010-06-28 15:53 acl.Sybase -r 1 root www 22776 2010-06-28 15:53 initialdata -r--r- 1 root www 46335 2010-06-28 15:53 RT_Config.pm -rw-r- 1 root www1027 2010-06-28 16:11 RT_SiteConfig.pm -r 1 root www 10518 2010-06-28 15:53 schema.Informix -r 1 root www 13236 2010-06-28 15:53 schema.mysql-4.0 -r 1 root www 14164 2010-06-28 15:53 schema.mysql-4.1 -r 1 root www 11776 2010-06-28 15:53 schema.Oracle -r 1 root www 13904 2010-06-28 15:53 schema.Pg -r 1 root www 10769 2010-06-28 15:53 schema.SQLite -r 1 root www 11550 2010-06-28 15:53 schema.Sybase drwxr-xr-x 25 administrator administrator 4096 2010-06-28 15:52 upgrade -Original Message- From: Jerrad Pierce [mailto:jpie...@cambridgeenergyalliance.org] Sent: Friday, June 25, 2010 2:14 PM To: Patton, Brandon Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Upgrading from RT 3.6.5 Ungh, Ubuntu as a server. Leaving that aside, simply use the package manager (something like Synaptic in the GUI) to check where the files for the rt package are installed. Back those up if you have concerns about possible customizations done to core instead of local code. Backup your database. Then: A) Update your system to something more modern, and install the corresponding rt package B) Download the source tarball from Best Practical, and follow the enclosed directions P.S. /opt/rt3 is the default path, for some reason several distributions like Ubuntu like to shove stuff under /usr/local/packageName and give users longer pathnames to deal with. Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Hehe thanks Charles. I think you might have a point anyway. Running that script recommended by Jason has thrown up a few things that need tweaking with mysql. Not sure what some of them mean yet, and not sure if it'll help, but we'll see. I appreciate you helping believe me! Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:28, Charles Johnson wrote: Justin, thank you for the kindness of your reply. I didn't intend to send you chasing rabbits, so to speak. Just offering something to add to the checklist of items to be crossed off before digging too deeply into the perl code. If you are convinced that mysql is performing at its best then please ignore my noise! :) Cheers-- Charles On Jun 29, 2010, at 9:18 AM, Justin Hayes wrote: Hi Charles, But as far as we can tell from our profiling the time is spent in the perl rendering the ticket, not in the query used to retrieve the ticket and attachments in the first place (which happens once at the start I believe). The loop that renders the ticket history and each attachment takes anything up to 20+ seconds. So I'm not sure how the DB can be an issue here? Unless I'm wrong about it doing 1 big query at the start and there are loads of little queries inside the loop. Cheers, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:14, Charles Johnson wrote: Quite outside of the speed of RT, what database are you using as a back-end? How long has it been since you did some care and feeding of your database? How big are your tables? If you are using mysql or postgres have you used their tools to examine your database, especially the indexes and statistics? This may be an issue with indexes needing to be rebuilt, or asking the database to gather new statistics for the queries your are running. Cheers-- Charles On Jun 29, 2010, at 8:09 AM, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Charles Johnson, Vanderbilt University Advanced Computing Center for Research Education Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203 Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143, Nashville, TN 37212 Office: 615-343-4134 Cell: 615-478-5743 Fax: 615-343-7216 charles.john...@accre.vanderbilt.edu -- Charles Johnson, Vanderbilt University Advanced Computing Center for Research Education Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203 Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143, Nashville, TN 37212 Office: 615-343-4134 Cell: 615-478-5743 Fax: 615-343-7216 Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
I did just have a problem with 3.8.8 and one of the indexes (didn't have the problem on 3.8.6 or below). It turned out to be the index GROUPS2 on the Groups table... dropped the index, and performance was back to normal (pre 3.8.8) Nicola -Original Message- From: rt-users-boun...@lists.bestpractical.com on behalf of Justin Hayes Sent: Tue 6/29/2010 9:28 AM To: Jason Doran Cc: rt Users Subject: Re: [rt-users] Slow Ticket History 3.8.8 Thanks Jason - I'll give that a go as well. We have got a large DB (~10gb) so keeping it tuned is definitely important. However as stated the time seems to be lost in code, after I'd have thought it had run the query for the ticket (though I may be wrong in that assumption). Cheers, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:22, Jason Doran wrote: Hi, If you are using mysqld have a look at mysqltuner.pl perl script (google) This has fixed quickly many performance issues on both RT and other web-based software we use. I run this every few weeks and apply suggested changes and then simply restart mysqld when things are quite. Regards, Jason Doran Computer Centre NUI, Maynooth On 29 Jun 2010, at 14:09, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Seem to be quite a few things to look at Jason. Need to figure out what they all mean first. Justin General Statistics -- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.1.37-1ubuntu5.4-log [OK] Operating on 64-bit architecture Storage Engine Statistics --- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 611M (Tables: 8) [--] Data in InnoDB tables: 10G (Tables: 20) [!!] Total fragmented tables: 21 Performance Metrics - [--] Up for: 19d 19h 32m 37s (110M q [64.266 qps], 222K conn, TX: 637B, RX: 39B) [--] Reads / Writes: 98% / 2% [--] Total buffers: 602.0M global + 134.8M per thread (150 max threads) [!!] Maximum possible memory usage: 20.3G (262% of installed RAM) [OK] Slow queries: 0% (229K/110M) [!!] Highest connection usage: 100% (151/150) [OK] Key buffer size / total MyISAM indexes: 512.0M/6.7M [OK] Key buffer hit rate: 100.0% (84M cached / 7K reads) [OK] Query cache efficiency: 71.4% (76M cached / 107M selects) [!!] Query cache prunes per day: 661360 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2M sorts) [!!] Joins performed without indexes: 112714 [!!] Temporary tables created on disk: 33% (968K on disk / 2M total) [OK] Thread cache hit rate: 99% (1K created / 222K connections) [OK] Table cache hit rate: 36% (318 open / 880 opened) [OK] Open file limit used: 14% (166/1K) [OK] Table locks acquired immediately: 99% (39M immediate / 39M locks) [!!] InnoDB data size / buffer pool: 10.1G/8.0M Recommendations - General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Reduce your overall MySQL memory footprint for system stability Reduce or eliminate persistent connections to reduce connection usage Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** max_connections ( 150) wait_timeout ( 28800) interactive_timeout ( 28800) query_cache_size ( 16M) join_buffer_size ( 2.0M, or always use indexes with joins) tmp_table_size ( 128M) max_heap_table_size ( 64M) innodb_buffer_pool_size (= 10G) - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:22, Jason Doran wrote: Hi, If you are using mysqld have a look at mysqltuner.pl perl script (google) This has fixed quickly many performance issues on both RT and other web-based software we use. I run this every few weeks and apply suggested changes and then simply restart mysqld when things are quite. Regards, Jason Doran Computer Centre NUI, Maynooth On 29 Jun 2010, at 14:09, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Hi Nicola, I've just tried upgrading from 3.8.4 which I've been on for ages, on the hope that it would be better, but isn't. So I don't think it's something that has either been introduced or fixed by 3.8.8. I'll take a look at that index though. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:49, Foggi, Nicola wrote: I did just have a problem with 3.8.8 and one of the indexes (didn't have the problem on 3.8.6 or below). It turned out to be the index GROUPS2 on the Groups table... dropped the index, and performance was back to normal (pre 3.8.8) Nicola -Original Message- From: rt-users-boun...@lists.bestpractical.com on behalf of Justin Hayes Sent: Tue 6/29/2010 9:28 AM To: Jason Doran Cc: rt Users Subject: Re: [rt-users] Slow Ticket History 3.8.8 Thanks Jason - I'll give that a go as well. We have got a large DB (~10gb) so keeping it tuned is definitely important. However as stated the time seems to be lost in code, after I'd have thought it had run the query for the ticket (though I may be wrong in that assumption). Cheers, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:22, Jason Doran wrote: Hi, If you are using mysqld have a look at mysqltuner.pl perl script (google) This has fixed quickly many performance issues on both RT and other web-based software we use. I run this every few weeks and apply suggested changes and then simply restart mysqld when things are quite. Regards, Jason Doran Computer Centre NUI, Maynooth On 29 Jun 2010, at 14:09, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Limit users by a non-empty customfield
On Tue, Jun 29, 2010 at 09:29:08AM +0200, Wolfram Huettermann wrote: Kevin Falcone wrote: On Mon, Jun 28, 2010 at 12:05:13PM +0200, Wolfram Huettermann wrote: Hello, I have got a user customfield called MyComment and I want to filter all users where this customfield is not empty. In my case, it is of freefrom type. The function LimitToCustomField does not work properly if I use $User-LimiToCostumField(FIELD = MyComment, OPERATOR = !=, VALUE = ); I assume you meant LimitCustomField, and that doesn't take a FIELD argument Yes, you are totally right. But even this code: $User-LimiToCostumField(CUSTOMFIELD = MyComment, OPERATOR = !=, VALUE = ); You're still using the wrong method name. There is no method LimitToCustomField on Users objects. -kevin pgpmK0jDNRRPz.pgp Description: PGP signature Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] script : custom action by ticket creation or modification
On Tue, Jun 29, 2010 at 10:09:19AM +0200, Horst Kriegers wrote:
the following scrip works only On transaction but not wen a new ticket
is created.
What is wrong ?
Your condition says only work when this is a custom field change, it
doesn't consider Create types at all.
-kevin
- Condition : User Defined
- Custom condition :
my $trans = $self-TransactionObj;
my $ticket = $self-TicketObj;
if ($trans-Type eq 'CustomField') {
my $cf = new RT::CustomField($RT::SystemUser);
$cf-LoadByName(Queue = $ticket-QueueObj-id, Name = Qualification
securite);
return 0 unless $cf-id;
if ($trans-Field == $cf-id $trans-NewValue eq Oui) {
return 1;
}
}
return 0;
pgprCEDbwiqQu.pgp
Description: PGP signature
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
As a test we've just created a long ticket in an empty RT DB and it's very fast. So does look to be DB related - contrary to our earlier investigations. I guess it must still access the DB resultset during the ticket rendering (which isn't how we thought it would work). Time to tune the hell out of mysql then... Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:53, Justin Hayes wrote: Seem to be quite a few things to look at Jason. Need to figure out what they all mean first. Justin General Statistics -- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.1.37-1ubuntu5.4-log [OK] Operating on 64-bit architecture Storage Engine Statistics --- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 611M (Tables: 8) [--] Data in InnoDB tables: 10G (Tables: 20) [!!] Total fragmented tables: 21 Performance Metrics - [--] Up for: 19d 19h 32m 37s (110M q [64.266 qps], 222K conn, TX: 637B, RX: 39B) [--] Reads / Writes: 98% / 2% [--] Total buffers: 602.0M global + 134.8M per thread (150 max threads) [!!] Maximum possible memory usage: 20.3G (262% of installed RAM) [OK] Slow queries: 0% (229K/110M) [!!] Highest connection usage: 100% (151/150) [OK] Key buffer size / total MyISAM indexes: 512.0M/6.7M [OK] Key buffer hit rate: 100.0% (84M cached / 7K reads) [OK] Query cache efficiency: 71.4% (76M cached / 107M selects) [!!] Query cache prunes per day: 661360 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2M sorts) [!!] Joins performed without indexes: 112714 [!!] Temporary tables created on disk: 33% (968K on disk / 2M total) [OK] Thread cache hit rate: 99% (1K created / 222K connections) [OK] Table cache hit rate: 36% (318 open / 880 opened) [OK] Open file limit used: 14% (166/1K) [OK] Table locks acquired immediately: 99% (39M immediate / 39M locks) [!!] InnoDB data size / buffer pool: 10.1G/8.0M Recommendations - General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Reduce your overall MySQL memory footprint for system stability Reduce or eliminate persistent connections to reduce connection usage Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** max_connections ( 150) wait_timeout ( 28800) interactive_timeout ( 28800) query_cache_size ( 16M) join_buffer_size ( 2.0M, or always use indexes with joins) tmp_table_size ( 128M) max_heap_table_size ( 64M) innodb_buffer_pool_size (= 10G) - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:22, Jason Doran wrote: Hi, If you are using mysqld have a look at mysqltuner.pl perl script (google) This has fixed quickly many performance issues on both RT and other web-based software we use. I run this every few weeks and apply suggested changes and then simply restart mysqld when things are quite. Regards, Jason Doran Computer Centre NUI, Maynooth On 29 Jun 2010, at 14:09, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer tickets? It would be really appreciated. Thanks, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden
Re: [rt-users] Upgrading from RT 3.6.5
On Tue, Jun 29, 2010 at 10:42:44AM -0400, Patton, Brandon wrote: I'm in the process of trying to upgrade now and I've gotten to the part of updating the database and I get the following error. Can anyone help me? r...@nethealth:/opt/rt3/sbin# ./rt-setup-database --dba root --prompt-for-dba-password --action upgrade In order to create or update your RT database, this script needs to connect to your mysql instance on localhost as root Please specify that user's database password below. If the user has no database password, just press return. Password: Working with: Type: mysql Host: localhost Name: rtdb User: rtuser DBA:root Couldn't finish 'upgrade' step. ERROR: Couldn't read dir './etc/upgrade' with upgrade data The error message is telling you that there is no /opt/rt3/sbin/etc/upgrade directory You need to run the command from a higher directory, or optionally you could explicity pass --datadir. Usually you run this from the unpacked tarball that you ran make upgrade from. -kevin The upgrade directory is there, not sure why it can't read it. Of course, I'm not an expert on permissions either. r...@nethealth:/opt/rt3/etc# ls -l total 196 -r 1 root www 90 2010-06-28 15:53 acl.Informix -r 1 root www 859 2010-06-28 15:53 acl.mysql -r 1 root www 27 2010-06-28 15:53 acl.Oracle -r 1 root www1912 2010-06-28 15:53 acl.Pg -r 1 root www 232 2010-06-28 15:53 acl.Sybase -r 1 root www 22776 2010-06-28 15:53 initialdata -r--r- 1 root www 46335 2010-06-28 15:53 RT_Config.pm -rw-r- 1 root www1027 2010-06-28 16:11 RT_SiteConfig.pm -r 1 root www 10518 2010-06-28 15:53 schema.Informix -r 1 root www 13236 2010-06-28 15:53 schema.mysql-4.0 -r 1 root www 14164 2010-06-28 15:53 schema.mysql-4.1 -r 1 root www 11776 2010-06-28 15:53 schema.Oracle -r 1 root www 13904 2010-06-28 15:53 schema.Pg -r 1 root www 10769 2010-06-28 15:53 schema.SQLite -r 1 root www 11550 2010-06-28 15:53 schema.Sybase drwxr-xr-x 25 administrator administrator 4096 2010-06-28 15:52 upgrade -Original Message- From: Jerrad Pierce [mailto:jpie...@cambridgeenergyalliance.org] Sent: Friday, June 25, 2010 2:14 PM To: Patton, Brandon Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Upgrading from RT 3.6.5 Ungh, Ubuntu as a server. Leaving that aside, simply use the package manager (something like Synaptic in the GUI) to check where the files for the rt package are installed. Back those up if you have concerns about possible customizations done to core instead of local code. Backup your database. Then: A) Update your system to something more modern, and install the corresponding rt package B) Download the source tarball from Best Practical, and follow the enclosed directions P.S. /opt/rt3 is the default path, for some reason several distributions like Ubuntu like to shove stuff under /usr/local/packageName and give users longer pathnames to deal with. Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com pgpYLbq7wdOvg.pgp Description: PGP signature Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Justin, I didn't see this mentioned and may have missed it, but are you displaying attachements inline? That might cut back on the I/O for History. Just a thought. Kenn LBNL On Tue, Jun 29, 2010 at 8:04 AM, Justin Hayes justin.ha...@openbet.comwrote: As a test we've just created a long ticket in an empty RT DB and it's very fast. So does look to be DB related - contrary to our earlier investigations. I guess it must still access the DB resultset during the ticket rendering (which isn't how we thought it would work). Time to tune the hell out of mysql then... Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:53, Justin Hayes wrote: Seem to be quite a few things to look at Jason. Need to figure out what they all mean first. Justin General Statistics -- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.1.37-1ubuntu5.4-log [OK] Operating on 64-bit architecture Storage Engine Statistics --- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 611M (Tables: 8) [--] Data in InnoDB tables: 10G (Tables: 20) [!!] Total fragmented tables: 21 Performance Metrics - [--] Up for: 19d 19h 32m 37s (110M q [64.266 qps], 222K conn, TX: 637B, RX: 39B) [--] Reads / Writes: 98% / 2% [--] Total buffers: 602.0M global + 134.8M per thread (150 max threads) [!!] Maximum possible memory usage: 20.3G (262% of installed RAM) [OK] Slow queries: 0% (229K/110M) [!!] Highest connection usage: 100% (151/150) [OK] Key buffer size / total MyISAM indexes: 512.0M/6.7M [OK] Key buffer hit rate: 100.0% (84M cached / 7K reads) [OK] Query cache efficiency: 71.4% (76M cached / 107M selects) [!!] Query cache prunes per day: 661360 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2M sorts) [!!] Joins performed without indexes: 112714 [!!] Temporary tables created on disk: 33% (968K on disk / 2M total) [OK] Thread cache hit rate: 99% (1K created / 222K connections) [OK] Table cache hit rate: 36% (318 open / 880 opened) [OK] Open file limit used: 14% (166/1K) [OK] Table locks acquired immediately: 99% (39M immediate / 39M locks) [!!] InnoDB data size / buffer pool: 10.1G/8.0M Recommendations - General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Reduce your overall MySQL memory footprint for system stability Reduce or eliminate persistent connections to reduce connection usage Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** max_connections ( 150) wait_timeout ( 28800) interactive_timeout ( 28800) query_cache_size ( 16M) join_buffer_size ( 2.0M, or always use indexes with joins) tmp_table_size ( 128M) max_heap_table_size ( 64M) innodb_buffer_pool_size (= 10G) - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:22, Jason Doran wrote: Hi, If you are using mysqld have a look at mysqltuner.pl perl script (google) This has fixed quickly many performance issues on both RT and other web-based software we use. I run this every few weeks and apply suggested changes and then simply restart mysqld when things are quite. Regards, Jason Doran Computer Centre NUI, Maynooth On 29 Jun 2010, at 14:09, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow. Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g. spanTime to display: 24.996907/span Can anyone share some numbers from theirs for longer
Re: [rt-users] SetPriority oddities.
Marc, I could be wrong but I suspect that what you are seeing after you made a change has to do with what is in cache. Your scrip code was for Cleanup so after RT made your change to 100, the Cleanup scrip came along and changed it back to 50, but cache still has what you TYPED into that field. That's my best guess. Hope it helps. Kenn LBNL On Tue, Jun 29, 2010 at 6:41 AM, Marc Andersen m...@govcert.dk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone I've been trying to wrap my head around RT for a couple of days now (actually RT-IR). Currently I am trying to add some business logic (yes...scrips :) ). I noted some oddities while trying to set my priority field using custom fields. I can essentially get it to work, but I have not been able to figure out why I run into the problem below. So I made up a very simple scrip to illustrate my point: Condition: on Transaction Action: User defined Global Template: Blank Stage: Transaction Batch Custom action cleanup code: $self-TicketObj-SetPriority (50); Then I set about to test it: 1) Create ticket -- ticket gets created and priority is 50. 2) Edit ticket -- I update anything but the priority in the ticket, just to trigger the script. For instance by changing the tickets subject. -- Save changes -- Priority remains 50. 3) Edit ticket -- this time I update the priority field and set it to, say, 100. The expected outcome: priority will be set to 50 by the script - -- Save changes -- actual outcome: the priority field _seems_ to be set to 100, although the script was triggered (confirmed by using RT::Logger). 4) Now this is where I get confused. Somehow, my script was overruled in 3). However, as soon as I access the ticket again by navigating to the ticket, i.e. clicking on display or selecting the ticket in the left menu bar or otherwise navigating around, the priority will be at 50, without my scrip running again. So my guess is, that my script actually saved the right priority in the database, but didn't update some essential object when displaying the ticket right after pressing 'Save Changes' Does anybody know what is happening here? Please bear in mind that the scrip here just illustrates my point and is not the actual final scrip I want to use in production (which would be setting the priority through several custom fields). Hope somebody has an answer. regards - -- Marc Andersen IT Security Analyst The Danish GovCERT -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMKff0AAoJEOI5XK2IuGDrhHgH/AwO+91nGJtPuLKyPN0DcKQ3 OTkwTKZDOaxXg29y7XQ8bp36ulB28SWKLRycnXsuw5+UCRvIEtyrdf8E7vra9exB ljKyos/13IvvI7oRcWSOvtB4tBxXH2Bd14h7gOZ9UhX3MKyQCdSZAhEl0t2CGhKd 4vb9ie0fCcY+k0TAZd5mtMYZUR4w5CH7t99hUe2TIwpRjNmzx6pzyVGkC8Nl8+ym 0eKw4h26WEvOEHsPHVNWXT/iWo3/0UjrPV/r5vNSA9R+dhfPf5BBfw6dp+6N1zyL XCPpTXXP/KHscRvmjws9GpouhDw5cdobXBqlX0zfMdd7kFDuFggOjpeGsiMBsmQ= =ZDm1 -END PGP SIGNATURE- Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] RT::Authen::ExternalAuth and privileged users
Oeter,
What Kevin said is what you need.
nor can I add them to groups - You can only add Privileged Users to a
group
Kenn
LBNL.
On Mon, Jun 28, 2010 at 2:27 PM, Kevin Gagel ga...@cnc.bc.ca wrote:
Peter,
Look into:
Set($WebExternalAuto,1);
Set($AutoCreate,{Privileged=0});
It's one or both that you need. These are my settings and my users are auto
created for me.
Kevin W. Gagel
Network Administrator
College of New Caledonia
My Blog:
http://mail.cnc.bc.ca/blogs/gagel
My Shared Files:
http://mail.cnc.bc.ca/users/gagel
On Monday 28/06/2010 at 2:24 pm, Peter Andersen wrote:
I currently have RT 3.8.6 working with RT::Authen::ExternalAuth to the
point where it allows me to authenticate and access the Self Service page
but I am stuck getting with all users being unprivileged. Users I create
inside RT can be privileged but none of the external users are privileged
nor can I add them to groups.
I see references to autocreate users but am unable to get any creation to
happen with ExternalAuth. Do I need to use RT::Extension::LDAPImport to
create user accounts before I can move forward? What options do I need to
look into for auto creating users? Can I set all my external users to
privileged (not the best idea)?
RT is running on Gentoo Linux with Apache2/fast_cgi, perl 5.10.1
threaded, RT::Authen::ExternalAuth 0.08 and connects to a Win2003 AD. I am
not attached to 3.8.6 so replacing with 3.8.8 is an option.
--
The College of New Caledonia
Visit us at http://www.cnc.bc.ca
*Virus scanning is done on all incoming and outgoing email
Anti-spam information for CNC can be found at http://gateway.cnc.bc.ca *
--
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
[rt-users] RESOLVED: Re: Custom scrip: Ticket created, but commit fails.
Pardon the top posting, but I feel that I have worked around the
problem we had with failing commits on ticket creation. Here is what I
did.
We first upgraded to the latest stable version of mod_perl for CentOS
5.2.
Second, we changed to custom cleanup code to use IPC::System::Simple
and usied a systemx() call, rather than system(). The advantage is
that systemx() does not invoke a new shell and swallows all stdout/
stderr and return values from the invoked binary. This seems to keep
mod_perl happy as well as RT. Here is the new custom cleanup code:
{
use IPC::System::Simple qw(system systemx);
my $myId = $self-TicketObj-EffectiveId;
my $mySubject = $self-TicketObj-Subject;
my $binret = '';
my $binary = '/home/alarmpoint/alarmpointsystems/integrationagent/
bin/APClient.bin';
$binret = systemx($binary, '--map-data', 'vanderbilt', 'Cluster
Group', $mySubject, 'RT', RT $myId);
1;
}
I hope this helps someone else. It works for us.
Cheers--
Charles
On Jun 24, 2010, at 2:38 PM, Kevin Falcone wrote:
On Thu, Jun 24, 2010 at 11:19:00AM -0500, Charles Johnson wrote:
Badly needing help. This is a script to call a binary that sends
data to a webservice. The binary simply accepts the data and
returns.
rt version: 3.8.1
OS version CentOS 5.2
If you're using mod_perl, Ruslan found some really excellent bugs with
running system commands under it. If you can come up to 3.8.8, that
may fix it for you
-kevin
First, here is the error message:
Jun 24 10:51:32 helpdesk RT: Ticket 9261 created in queue
'ClusterSupport' by johns276
(/opt/rt3/bin/../lib/RT/Ticket_Overlay.pm:659)
Jun 24 10:51:32 helpdesk RT: Attempted to commit a transaction with
none in progress at
/usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 747
DBIx
::SearchBuilder::Handle::EndTransaction('RT::Handle=HASH(0xba695a0)',
'Action', 'commit', 'Force', 'undef') called at /usr/lib/perl5/
site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 780
DBIx::SearchBuilder::Handle::Commit('RT::Handle=HASH(0xba695a0)')
called at /opt/rt3/bin/../lib/RT/Ticket_Overlay.pm line 675
RT::Ticket::Create('RT::Ticket=HASH(0xc8b8798)', 'Requestor',
'ARRAY(0xc8a4df4)', 'DependsOn', 'ARRAY(0xc8bb6b8)', 'Cc',
'ARRAY(0xc8c1034)', 'RefersTo', 'ARRAY(0xc8bb7f0)', ...) called at /
opt/rt3/bin/../local/lib/RT/Interface/Email/Filter/TakeAction.pm
line 501
RT::Interface::Email::Filter::TakeAction::GetCurrentUser('Message',
'MIME::Entity=HASH(0xc8af7fc)', 'RawMessageRef',
'SCALAR(0xc8afdc0)', 'CurrentUser',
'RT::CurrentUser=HASH(0xc862d80)', 'AuthLevel', 1, 'Action', ...)
called at /opt/rt3/bin/../lib/RT/Interface/Email.pm line 1274 RT::
The ticket is created but the commit fails. An attempt to view the
ticket produces this error message: Could not load ticket 9261
Here is the scrip. It is attached to a particular queue
(CustomerSupport).
# Condition: User defined
if ($self-TransactionObj-Type eq 'Create') {
return (1);
}
# Action: User Defined
# Custom action preparation code: Do nothing with the ticket
1;
# Custom action cleanup code:
{
my $myId = $self-TicketObj-EffectiveId;
my $mySubject = $self-TicketObj-Subject;
my $binary =
'/home/alarmpoint/alarmpointsystems/integrationagent/
bin/APClient.bin';
system($binary, '--map-data', 'vanderbilt', 'Cluster Group',
$mySubject, 'RT', RT $myId);
1;
}
#Template: Global Template: Blank
Any suggestions would be appreciated. The message is actually send
to the webservice, since we can log in to the remote server and see
that the data was sent appropriately. However, RT balks.
Thanks.
~Charles~
--
Charles Johnson, Vanderbilt University
Advanced Computing Center for Research and Education
Office: 615-343-4134
Cell: 615-478-5743
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
--
Charles Johnson, Vanderbilt University
Advanced Computing Center for Research Education
Mailing Address: Peabody #34, 230 Appleton Place, Nashville, TN 37203
Shipping Address: 1231 18th Avenue South, Hill Center, Suite 143,
Nashville, TN 37212
Office: 615-343-4134
Cell: 615-478-5743
Fax: 615-343-7216
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Upgrading from RT 3.6.5
Ok, I'm getting closer and closer to getting this to work but having a problem with the Apache setup. I have created the config for Apache as shown by numerous examples but no matter which example I follow, I get the following error trying to start Apache: Can't load Perl file: /opt/rt3/bin/webmux.pl If I uncomment the PerlRequire line apache will start and I get the website with the Your Almost There! message. Here is the config info I'm using for Apache VirtualHost * ServerName nethealth DocumentRoot /opt/rt3/share/html AddDefaultCharset UTF-8 PerlModule Apache2 Apache::compat PerlModule Apache::DBI PerlRequire /opt/rt3/bin/webmux.pl ErrorLog /opt/rt3/var/log/apache2.error Location / SetHandler perl-script PerlHandler RT::Mason /Location /VirtualHost OS: Ubuntu 8.04.0 MySQL 5.0.51 PostFix Mail 2.54 Apache 2.28 Request Tacker: 3.8.8 -Original Message- From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Patton, Brandon Sent: Tuesday, June 29, 2010 10:43 AM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Upgrading from RT 3.6.5 I'm in the process of trying to upgrade now and I've gotten to the part of updating the database and I get the following error. Can anyone help me? r...@nethealth:/opt/rt3/sbin# ./rt-setup-database --dba root --prompt-for-dba-password --action upgrade In order to create or update your RT database, this script needs to connect to your mysql instance on localhost as root Please specify that user's database password below. If the user has no database password, just press return. Password: Working with: Type: mysql Host: localhost Name: rtdb User: rtuser DBA:root Couldn't finish 'upgrade' step. ERROR: Couldn't read dir './etc/upgrade' with upgrade data The upgrade directory is there, not sure why it can't read it. Of course, I'm not an expert on permissions either. r...@nethealth:/opt/rt3/etc# ls -l total 196 -r 1 root www 90 2010-06-28 15:53 acl.Informix -r 1 root www 859 2010-06-28 15:53 acl.mysql -r 1 root www 27 2010-06-28 15:53 acl.Oracle -r 1 root www1912 2010-06-28 15:53 acl.Pg -r 1 root www 232 2010-06-28 15:53 acl.Sybase -r 1 root www 22776 2010-06-28 15:53 initialdata -r--r- 1 root www 46335 2010-06-28 15:53 RT_Config.pm -rw-r- 1 root www1027 2010-06-28 16:11 RT_SiteConfig.pm -r 1 root www 10518 2010-06-28 15:53 schema.Informix -r 1 root www 13236 2010-06-28 15:53 schema.mysql-4.0 -r 1 root www 14164 2010-06-28 15:53 schema.mysql-4.1 -r 1 root www 11776 2010-06-28 15:53 schema.Oracle -r 1 root www 13904 2010-06-28 15:53 schema.Pg -r 1 root www 10769 2010-06-28 15:53 schema.SQLite -r 1 root www 11550 2010-06-28 15:53 schema.Sybase drwxr-xr-x 25 administrator administrator 4096 2010-06-28 15:52 upgrade -Original Message- From: Jerrad Pierce [mailto:jpie...@cambridgeenergyalliance.org] Sent: Friday, June 25, 2010 2:14 PM To: Patton, Brandon Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Upgrading from RT 3.6.5 Ungh, Ubuntu as a server. Leaving that aside, simply use the package manager (something like Synaptic in the GUI) to check where the files for the rt package are installed. Back those up if you have concerns about possible customizations done to core instead of local code. Backup your database. Then: A) Update your system to something more modern, and install the corresponding rt package B) Download the source tarball from Best Practical, and follow the enclosed directions P.S. /opt/rt3 is the default path, for some reason several distributions like Ubuntu like to shove stuff under /usr/local/packageName and give users longer pathnames to deal with. Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] RTFM issue.
I have RTFM 2.4.2 installed and seems to be mostly working correctly. But I can't finish setting it up to see. I don't have a place to put comments into the FAQ, so the notes that I found was to create a custom field. I have a Custom field called Body, Fill in one text area, applies to RTFM, and group rights are all set up. When I click on the Applies to and get the error: could not find component for path '/Elements/RT__FM__ClassCollection/ColumnMap' Thanks! Mark Jenks Network Administrator iod incorporated mark.je...@iodincorporated.com mailto:mark.je...@iodincorporated.com 920-406-3702 CONFIDENTIALITY NOTICE: The information contained in this email message, including any attachments, may be privileged, confidential and otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this message, including any attachments, is strictly prohibited. If you have received this email message in error, please notify the sender by reply email and delete/destroy the email message, including attachments, and any copies thereof. Although we have taken precautions to minimize the risk of transmitting viruses via email and attachments thereto, we do not guarantee that either is virus-free, and we accept no liability for any damages sustained as a result of any such viruses. Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] QuickSpamHandler.tgz
Do anybody have a copy of the QuickSpamHandler.tgz tarball that is referenced from http://wiki.bestpractical.com/view/SpamFiltering ? I have used it before and I was hoping to install it on a new RT instance but unfortunately I can't find the tarball anywhere :( Cheers, Francois Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
