Re: [rt-users] RT4 - mod_perl problem with apache2
Dnia 2011-05-31, wto o godzinie 11:00 -0400, Kevin Falcone pisze: Unfortunately, it's difficult to try replicating without a perl/apache/mod_perl2/plack version list Everything was from Debian Lenny, after dist-upgrade to squeeze there is no longer any problem. -- Robert Wysocki CONTIUM S.A., http://www.contium.pl
Re: [rt-users] RT4 slowness
I tried jsmin and I have the same bug as Chris with the javascript menubar, plus some weird boxes display. Anyway, browsing is still slow when I go in a ticket from a page to another (such as Basics or Peoples). Either there is some js minified each time I access a page (how can I check that?) or this problem has nothing to do with js minifiers. -- L.B.
Re: [rt-users] RT4 slowness
This amazing patch fixed the issue, so it has something to do with the minifier:
--- lib/RT/Squish/JS.pm.orig2011-06-01 07:50:27.510862133 +
+++ lib/RT/Squish/JS.pm 2011-06-01 07:45:55.096115642 +
@@ -110,7 +110,7 @@
$RT::Logger-debug(can't load JavaScript::Minifier: $@);
}
else {
-$content = JavaScript::Minifier::minify( input = $content );
+#$content = JavaScript::Minifier::minify( input = $content );
}
}
return $content;
--
L.B.
Re: [rt-users] RT4 slowness
Dnia 2011-05-31, wto o godzinie 12:59 -0400, Kevin Falcone pisze: On Tue, May 31, 2011 at 12:56:46PM -0400, Chris Hall wrote: Just for the record I'm having the same issues as L.B. I attempted loading jsmin, and for a time it appeared that this was going to be a bigtime home run. In fact, it did fix the issues I was having with speed! However, jsmin seemed to also break several aspects of the RT interface. Immediately I noticed the javascript dropdowns were gone.. no big deal, switched to the ballard interface as the default. However, opening a new ticket.. everything was jumbled around... dropdowns were permanently opened, the minimize links for the different zones wouldn't work anymore.. it was generally a bad day. :( So I've turned it back off. This does however shed some light on what may be the cause of.. at least.. my speed issues. The search continues... RT only builds the squished css/js once per child process. If you're actually seeing it built on each request, something is horribly wrong and isn't something we've seen or been able to replicate. The same for me - 7 second delay befor loading any page. The obvious fix for it - after reading this thread, was to remove references to JavaScript::Minifier in lib/RT/Squish/JS.pm. Now the delay isn't greater than 4 seconds and since we're using RT almost exclusively on LAN it's OK for us. -- Robert Wysocki CONTIUM S.A., http://www.contium.pl
Re: [rt-users] RT4 slowness
On Wed, Jun 1, 2011 at 9:52 AM, L B bertig...@gmail.com wrote:
This amazing patch fixed the issue, so it has something to do with the
minifier:
--- lib/RT/Squish/JS.pm.orig 2011-06-01 07:50:27.510862133 +
+++ lib/RT/Squish/JS.pm 2011-06-01 07:45:55.096115642 +
@@ -110,7 +110,7 @@
$RT::Logger-debug(can't load JavaScript::Minifier: $@);
}
else {
- $content = JavaScript::Minifier::minify( input = $content );
+ #$content = JavaScript::Minifier::minify( input = $content );
}
}
return $content;
--
L.B.
But it doesn't solve the slowness for Display.html page. Displaying a
ticket still need the 7seconds.
--
L.B.
[rt-users] just some clarifications
Hi in old RT relesess I get following files fastcgi_server fastcgi_server.in mason_handler.fcgi mason_handler.fcgi.in mason_handler.scgi mason_handler.scgi.in mason_handler.svc mason_handler.svc.in rt rt-crontool rt-crontool.in rt.in rt-mailgate rt-mailgate.in standalone_httpd standalone_httpd.in webmux.pl webmux.pl.in [root@iilrt bin]# pwd Under /home/RT_installs/rt-3.8.8/bin directory and in newer releases like RT 4 there is only rt rt-crontool rt-crontool.in rt.in rt-mailgate rt-mailgate.in why? Don’t we require rest of the files any more Thanks and Best Regards
[rt-users] dashboard chart sizes
Hi all, Here is a low priority question, but I'm wondering if anyone knows how to scale down the size of the charts in RT 4.0. I have a number of charts that I've saved to a dashboard, but the charts appear so large that I have to do a bit of horizontal scrolling to see the whole page. I know I could line them up vertically, but I think it looks nicer/is more functional to have some charts side by side. Thanks, Dan
Re: [rt-users] just some clarifications
Hi Some files migrated to sbin dir. Some are not required because of Plack. Read web_deployments in docs dir. Regards, Ruslan. From phone. 01.06.2011 15:27 пользователь Asanka Gunasekera asanka_gunasek...@yahoo.co.uk написал: Hi in old RT relesess I get following files fastcgi_server fastcgi_server.in mason_handler.fcgi mason_handler.fcgi.in mason_handler.scgi mason_handler.scgi.in mason_handler.svc mason_handler.svc.in rt rt-crontool rt-crontool.in rt.in rt-mailgate rt-mailgate.in standalone_httpd standalone_httpd.in webmux.pl webmux.pl.in [root@iilrt bin]# pwd Under /home/RT_installs/rt-3.8.8/bin directory and in newer releases like RT 4 there is only rt rt-crontool rt-crontool.in rt.in rt-mailgate rt-mailgate.in why? Don’t we require rest of the files any more Thanks and Best Regards
Re: [rt-users] RT4 slowness
On Wed, Jun 01, 2011 at 11:43:30AM +0200, L B wrote:
On Wed, Jun 1, 2011 at 9:52 AM, L B bertig...@gmail.com wrote:
This amazing patch fixed the issue, so it has something to do with the
minifier:
--- lib/RT/Squish/JS.pm.orig 2011-06-01 07:50:27.510862133 +
+++ lib/RT/Squish/JS.pm 2011-06-01 07:45:55.096115642 +
@@ -110,7 +110,7 @@
$RT::Logger-debug(can't load JavaScript::Minifier: $@);
}
else {
- $content = JavaScript::Minifier::minify( input = $content );
+ #$content = JavaScript::Minifier::minify( input = $content );
}
}
return $content;
--
L.B.
But it doesn't solve the slowness for Display.html page. Displaying a
ticket still need the 7seconds.
All this patch will do is solve the once per child slowness of
squishing the JS by reverting to simple concatenation. Children
should be answering multiple requests before being reaped and needing
to resquish.
If you're seeing this JS related slowness on every page, it points to
other problems.
Please provide details about your installation such as your apache
versions and configuration otherwise it's quite difficult to
test. We've tried replicating in house, but haven't seen this in any
of our test or production RT4 instances.
If you're seeing particular slowness on a given page, RT4 contains a
new feature to allow you (as an admin) to see if there are particular
SQL statements causing problems. Because it is debugging, it will
cause other slowness in RT and should not be left on, but StatementLog
will expose queries in the admin UI and allow you to see if something
needs indexing or optimization.
-kevin
pgpxjB694h4gH.pgp
Description: PGP signature
Re: [rt-users] RT4 slowness
Hi Kevin, But it doesn't solve the slowness for Display.html page. Displaying a ticket still need the 7seconds. All this patch will do is solve the once per child slowness of squishing the JS by reverting to simple concatenation. Children should be answering multiple requests before being reaped and needing to resquish. If you're seeing this JS related slowness on every page, it points to other problems. I checked some pages and I have these 7 seconds on at least: - Login page - Search/Simple.html - Search/Build.html - Tools/MyDay.html - Admin/Users - Admin/Tools/Configuration.html Applying the patch above remove the slowness on all the pages except the Display.html (showing ticket #1 with only one correspondance inside, no attachments) Please provide details about your installation such as your apache versions and configuration otherwise it's quite difficult to test. We've tried replicating in house, but haven't seen this in any of our test or production RT4 instances. Apache 2.2.15, first email of the thread has all the details. If you're seeing particular slowness on a given page, RT4 contains a new feature to allow you (as an admin) to see if there are particular SQL statements causing problems. Because it is debugging, it will cause other slowness in RT and should not be left on, but StatementLog will expose queries in the admin UI and allow you to see if something needs indexing or optimization. We monitored at the database level the SQL statements and we didn't find anything wrong. -- L.B.
Re: [rt-users] RT4 slowness
On Wed, Jun 01, 2011 at 04:19:44PM +0200, L B wrote: I checked some pages and I have these 7 seconds on at least: - Login page - Search/Simple.html - Search/Build.html - Tools/MyDay.html - Admin/Users - Admin/Tools/Configuration.html Applying the patch above remove the slowness on all the pages except the Display.html (showing ticket #1 with only one correspondance inside, no attachments) This implies you're requishing JS on every page, which points to a misconfiguration. Please provide details about your installation such as your apache versions and configuration otherwise it's quite difficult to test. We've tried replicating in house, but haven't seen this in any of our test or production RT4 instances. Apache 2.2.15, first email of the thread has all the details. Your first email had differing paths in your preload and psgi_app lines, so I assumed it was a copy and paste error, so was hoping to get a clean full copy of your config. Other things that would be useful are your sanitized RT_SiteConfig or the System Configuration from the Admin UI. -kevin pgpWSvifPWwDl.pgp Description: PGP signature
Re: [rt-users] RT4 slowness
Your first email had differing paths in your preload and psgi_app lines, so I assumed it was a copy and paste error, so was hoping to get a clean full copy of your config. Sorry, copy/paste error. Paths are the same. Other things that would be useful are your sanitized RT_SiteConfig or the System Configuration from the Admin UI. RT_SiteConfig.pm : Set($rtname, 'X'); Set($WebDomain, '10.0.xx.xx'); Set($WebBaseURL, http://10.0.xx.xx;); Set($LogDir, /opt/rt4/var/log); Set($LogToFile , 'debug'); Set($LogToScreen, 'debug'); Set($LogToSyslog, 'debug'); # Added when testing a remote database Set($DatabaseHost , ); Set($DatabasePort , 5432); Set($DatabaseName , 'x'); Set($DatabaseUser , x); Set($DatabasePassword , 'x'); # Added because debug mode complained Set($RTAddressRegexp, 'x...@xxx.com'); Set(%GnuPG, Enable = 0, OutgoingMessagesFormat = RFC, # Inline AllowEncryptDataInDB = 0, RejectOnMissingPrivateKey = 1, RejectOnBadData = 1, ); 1; Attached a sanitized httpd.conf: it's the the default redhat httpd.conf without the comments, and with my configuration at the end (overriding previous variables) -- L.B. httpd.conf Description: Binary data
Re: [rt-users] RT4 slowness
On Wed, Jun 01, 2011 at 04:52:13PM +0200, L B wrote: Your first email had differing paths in your preload and psgi_app lines, so I assumed it was a copy and paste error, so was hoping to get a clean full copy of your config. Sorry, copy/paste error. Paths are the same. Other things that would be useful are your sanitized RT_SiteConfig or the System Configuration from the Admin UI. You seem to be loading a lot of caching modules, are any of them enabled in Include conf.d/*.conf ? -kevin pgpvJtZIwfKxa.pgp Description: PGP signature
Re: [rt-users] scrip to change subject for tickets created w/rt-mailgate
Sorry for the delay. The condition isn't an issue here as the scrip will apply to everything that comes into the queue. I know I can change the subject easily with: $self-TicketObj-SetSubject( EXTRACTED VALUE ); Where I'm stumbling is in extracting the desired info from the history on the ticket and turning that into a usable for the SetSubject string. Tx, Rob -Original Message- From: ruslan.zaki...@gmail.com [mailto:ruslan.zaki...@gmail.com] On Behalf Of Ruslan Zakirov Sent: Tuesday, May 24, 2011 4:42 PM To: Sullivan, Rob Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] scrip to change subject for tickets created w/rt-mailgate Hi, You need scrips for sure. Start writing required condition. Put something trivial as action, for example log a string into log files with $RT::Logger object. As condition you need something like: on create and subject is event active!. Wiki has snippets for all of that. Try. Return back if you fail with more questions. On Tue, May 24, 2011 at 11:00 PM, Sullivan, Rob rsulli...@peerlessnetwork.com wrote: Management here has requested that all major and critical alarms from our monitoring system are emailed to RT as well as the pagers so that we can run daily reports on the tickets and provide a high level view of what's happened overnight for engineering. The monitoring package sends out email with the subject line Event Active! and the vendor has informed us this can't change. Subsequently we'd like to have the event message which is currently contained in the message body show up in the subject field on the ticket so that the queue view and subsequent reports will show the nature of each ticket without having to open it. For instance, a ticket which currently looks like this: Sub: Event Active! Body: 110524 06:34:00 ISD4000 LVL=Maj 10.31.50.11 Redundant card in slot 4 is active, check health of client modules - Active! Would look like this: Sub: LVL=Maj 10.31.50.11 Redundant card in slot 4 is active, check health of client modules - Active! Body: 110524 06:34:00 ISD4000 LVL=Maj 10.31.50.11 Redundant card in slot 4 is active, check health of client modules - Active! I'm not sure where to start as far as the scrip and template go. Any suggestions? Thanks, Rob Sullivan Systems Engineer, Peerless Network Inc rsulli...@peerlessnetwork.com 312-506-0948 -- Best regards, Ruslan.
[rt-users] Setting TimeWorked in lifecycle
In our RT3.8.9 setup, I had customized the Tickets/Elements/Tabs to have a
QuickResolve for when you could just look at a ticket and resolve it with no
further action: for example, a known false positive virus alert, using:
if ( $can{'ModifyTicket'} ) {
if ( $Ticket-Status ne 'resolved' ) {
$actions-{'Acc'} = {
path =
Ticket/Display.html?Status=resolvedid=$idUpdateTimeWorked=1,
title = loc('Quick Resolve'),
};
}
}
Now that RT 4 uses lifecycles, I'm not sure how to accomplish this same thing
using lifecycles in RT_SiteConfig.pm. The documentation in RT_Config is less
than helpful for anything but stock behavior: show the update page or just
change a status, but it isn't very flexible beyond that. Am I missing
something? Even a wiki page addressing lifecycles in some fashion?
Thanks in advance for any help someone can give.
Drew Barnes
Applications Analyst
Network Resources Dept.
Raymond Walters College
