[rt-users] Stripping e-mail signatures and quoted messages
Hi Is there a way to automatically remove signatures and corporate disclaimers garbage from e-mails that get fed into an RT queue? Also, is there a way to automatically remove quoted mail bodies stemming from previous messages? Thanks! Silvano RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] WOW !
Vikas, We don't use self-service. Can't help you there. Sorry. Kenn LBNL On Tue, Sep 21, 2010 at 5:11 PM, Vikas Srivastava vikas.k.srivast...@gmail.com wrote: WOW !! That's Amazing ...!! I removed it and after service restart it was gone ! ... Its is still there on the /SelfService page . (The CC: field) How do I remove that . Also is there a way I could remove it system wide .. Thanks Vikas Date: Mon, 20 Sep 2010 11:23:22 -0700 From: Kenneth Crocker kfcroc...@lbl.gov To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Hiding CC: Admin CC: Fields on new ticket creation Message-ID: aanlktinke8bnc9ivzweyfvgdbt75=trqb085zwl4f...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Vikas, Yes. We removed AdminCc from the Ticket Create because we use the AdminCc role as the Queue manager (Queue Watcher) and therefore will get all notifications needed due to Global scrips and we don't want anyone adding an AdminCc to any notifications going out. You need to create a local version of the Create.html file (copy /opt/rt3/share/html/Ticket/Create.html to /opt/rt3/local/html/Ticket/Create.html) and make your modifications there. Hope this helps. Kenn LBNL Kind Regards Vikas Srivastava Mobile : +91-665501 RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT! RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
[rt-users] Outlook 2007 inserting multiple blank lines
Hello, I've been having problems with people that send emails into RT from Outlook 2007 or 2010. If they reply to a message it keeps adding blank lines, overtime there are extremely large gaps in the email thread. I searched around on Google and found this thread http://www.gossamer-threads.com/lists/rt/users/94042 which mentions the problem. I followed Jesse's advice and copied the latest EmailParser.pm from git 3.8-trunk to /opt/rt3/lib/RT/EmailParser.pm however blank lines keep getting added to the messages. I have cleaned the mason cache as well as restarting postfix and apache. Thanks for the help. Dustin RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] WOW !
Vikas, We don't use self-support so I have no idea. Sorry. Kenn LBNL On Wed, Sep 22, 2010 at 9:02 AM, Kenneth Crocker kfcroc...@lbl.gov wrote: Vikas, We don't use self-service. Can't help you there. Sorry. Kenn LBNL On Tue, Sep 21, 2010 at 5:11 PM, Vikas Srivastava vikas.k.srivast...@gmail.com wrote: WOW !! That's Amazing ...!! I removed it and after service restart it was gone ! ... Its is still there on the /SelfService page . (The CC: field) How do I remove that . Also is there a way I could remove it system wide .. Thanks Vikas Date: Mon, 20 Sep 2010 11:23:22 -0700 From: Kenneth Crocker kfcroc...@lbl.gov To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Hiding CC: Admin CC: Fields on new ticket creation Message-ID: aanlktinke8bnc9ivzweyfvgdbt75=trqb085zwl4f...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Vikas, Yes. We removed AdminCc from the Ticket Create because we use the AdminCc role as the Queue manager (Queue Watcher) and therefore will get all notifications needed due to Global scrips and we don't want anyone adding an AdminCc to any notifications going out. You need to create a local version of the Create.html file (copy /opt/rt3/share/html/Ticket/Create.html to /opt/rt3/local/html/Ticket/Create.html) and make your modifications there. Hope this helps. Kenn LBNL Kind Regards Vikas Srivastava Mobile : +91-665501 RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT! RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] How to Re-size the TextBox created when putting a custom field on CreateTicket
Vikas,
Same thing. Create a local version of
/opt/rt3/share/Elements/EditCustomField. Then make your changes there.
We use the following code to change the size of *text* boxes as well as turn
*select lists* into drop-down lists:
if ($Type eq Text) {
$Rows = 8;
$Cols = 50;
} elsif ($Type eq Wikitext) {
$Rows = 8;
$Cols = 50;
} elsif ($Type eq Select and $MaxValues == 1) {
$Rows = 1;
$Cols = 30;
}
Hope this helps.
Kenn
LBNL
On Tue, Sep 21, 2010 at 5:14 PM, Vikas Srivastava
vikas.k.srivast...@gmail.com wrote:
Hi All ,
I added a custom field , name Problem Description (TextBox) ..
It comes on the page fine but I would like to re-size it .. and
reposition it . ..
Is there a way we could achieve that ...
Thanks Regards
Vikas ..
RT Training in Washington DC, USA on Oct 25 26 2010
Last one this year -- Learn how to get the most out of RT!
RT Training in Washington DC, USA on Oct 25 26 2010
Last one this year -- Learn how to get the most out of RT!
[rt-users] Slow PostgreSQL perf with 3.8.7
Please bear with my ignorance on this topic. I realize this isn't a PostgreSQL tuning forum, but since it's RT-related I thought I'd ask here. RT 3.8.7 (and RTFM) with PostgreSQL 8.1.18 via RHELv5 running as a VM. We're experiencing significant delays today with various PostgreSQL statements taking longer than 1000ms to complete. We have 10,000 tickets, 1300 of which are 'open' Can anyone throw out any ideas, things to check, etc? Is this just Viewing a single ticket results in the following, showing only those longer than 1000ms: LOG: duration: 1496.023 ms LOG: duration: 1496.023 ms statement: EXECUTE unnamed [PREPARE: SELECT DISTINCT main.Id AS id, main.Filename AS filename, main.Headers AS headers, main.Subject AS subject, main.Parent AS parent, main.ContentEncoding AS contentencoding, main.ContentType AS contenttype, main.TransactionId AS transactionid, main.Created AS created FROM Attachments main JOIN Transactions Transactions_1 ON ( Transactions_1.id = main.TransactionId ) JOIN Tickets Tickets_2 ON ( Tickets_2.id = Transactions_1.ObjectId ) WHERE (Tickets_2.EffectiveId = '35803') AND (Transactions_1.ObjectType = 'RT::Ticket') ORDER BY main.id ASC ] LOG: duration: 2207.968 ms LOG: duration: 2207.968 ms statement: EXECUTE unnamed [PREPARE: SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_4 JOIN Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN CachedGroupMembers CachedGroupMembers_2 ON ( CachedGroupMembers_2.MemberId = Principals_1.id ) JOIN Groups Groups_3 ON ( Groups_3.id = CachedGroupMembers_2.GroupId ) WHERE (Principals_1.Disabled = '0') AND (ACL_4.PrincipalType = Groups_3.Type) AND (Principals_1.id != '1') AND (Principals_1.PrincipalType = 'User') AND (ACL_4.RightName = 'OwnTicket' OR ACL_4.RightName = 'SuperUser') AND (Groups_3.Domain = 'RT::Queue-Role' AND Groups_3.Instance = '1') AND ((ACL_4.ObjectType = 'RT::Queue' AND ACL_4.ObjectId = 1) OR (ACL_4.ObjectType = 'RT::System')) ORDER BY main.Name ASC ] LOG: duration: 3363.967 ms LOG: duration: 3363.967 ms statement: EXECUTE unnamed [PREPARE: SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_2 JOIN Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN CachedGroupMembers CachedGroupMembers_3 ON ( CachedGroupMembers_3.MemberId = Principals_1.id ) WHERE (Principals_1.Disabled = '0') AND (ACL_2.PrincipalId = CachedGroupMembers_3.GroupId) AND (Principals_1.id != '1') AND (ACL_2.PrincipalType = 'Group') AND (Principals_1.PrincipalType = 'User') AND (ACL_2.RightName = 'OwnTicket' OR ACL_2.RightName = 'SuperUser') AND ((ACL_2.ObjectType = 'RT::Queue' AND ACL_2.ObjectId = 1) OR (ACL_2.ObjectType = 'RT::System')) ORDER BY main.Name ASC ] LOG: duration: 1482.014 ms LOG: duration: 1482.014 ms statement: EXECUTE unnamed [PREPARE: SELECT DISTINCT main.id AS id, main.Content AS content, main.ContentType AS contenttype, main.TransactionId AS transactionid, main.ContentEncoding AS contentencoding FROM Attachments main JOIN Transactions Transactions_1 ON ( Transactions_1.id = main.TransactionId ) JOIN Tickets Tickets_2 ON ( Tickets_2.id = Transactions_1.ObjectId ) WHERE (Tickets_2.EffectiveId = '35803') AND (Transactions_1.ObjectType = 'RT::Ticket') AND (main.ContentType = 'text/plain' OR main.ContentType LIKE 'message/%' OR main.ContentType = 'text') ORDER BY main.id ASC ] LOG: duration: 1329.789 ms LOG: duration: 1329.789 ms statement: EXECUTE unnamed [PREPARE: SELECT DISTINCT main.* FROM Transactions main JOIN Tickets Tickets_1 ON ( Tickets_1.id = main.ObjectId ) WHERE (main.ObjectType = 'RT::Ticket') AND (Tickets_1.EffectiveId = '35803') ORDER BY main.Created ASC, main.id ASC ] # /sbin/sysctl kernel.shmmax kernel.shmall kernel.shmmni kernel.sem kernel.shmmax = 4294967296 kernel.shmall = 2097152 kernel.shmmni = 4096 kernel.sem = 25032000 100 128 # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU X5365 @ 3.00GHz stepping: 1 cpu MHz : 2992.499 cache size : 4096 KB fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx lm constant_tsc up pni ssse3 cx16 lahf_lm bogomips: 5984.99 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: # cat /proc/meminfo MemTotal: 2059588 kB MemFree:664456 kB Buffers: 21620 kB Cached: 612024 kB SwapCached: 25724 kB Active:1164032 kB Inactive: 116264 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 2059588 kB LowFree:664456 kB SwapTotal: 2064376 kB SwapFree: 1997364 kB Dirty: 400 kB Writeback: 0 kB AnonPages:
Re: [rt-users] Slow PostgreSQL perf with 3.8.7
Hi Jeff, Wow, is that version of PostgreSQL old. Certainly there have been many, many performance improvements since v8.1.x. While upgrading would help, you really need to run an EXPLAIN ANALYZE for your slow queries to see if there is a problem area. Also, you should check to wiki to see if you have all of the recommended PostgreSQL indexes. Some things to check. Ken On Wed, Sep 22, 2010 at 12:12:59PM -0400, Jeff Blaine wrote: Please bear with my ignorance on this topic. I realize this isn't a PostgreSQL tuning forum, but since it's RT-related I thought I'd ask here. RT 3.8.7 (and RTFM) with PostgreSQL 8.1.18 via RHELv5 running as a VM. We're experiencing significant delays today with various PostgreSQL statements taking longer than 1000ms to complete. We have 10,000 tickets, 1300 of which are 'open' Can anyone throw out any ideas, things to check, etc? Is this just Viewing a single ticket results in the following, showing only those longer than 1000ms: LOG: duration: 1496.023 ms LOG: duration: 1496.023 ms statement: EXECUTE unnamed [PREPARE: SELECT DISTINCT main.Id AS id, main.Filename AS filename, main.Headers AS headers, main.Subject AS subject, main.Parent AS parent, main.ContentEncoding AS contentencoding, main.ContentType AS contenttype, main.TransactionId AS transactionid, main.Created AS created FROM Attachments main JOIN Transactions Transactions_1 ON ( Transactions_1.id = main.TransactionId ) JOIN Tickets Tickets_2 ON ( Tickets_2.id = Transactions_1.ObjectId ) WHERE (Tickets_2.EffectiveId = '35803') AND (Transactions_1.ObjectType = 'RT::Ticket') ORDER BY main.id ASC ] LOG: duration: 2207.968 ms LOG: duration: 2207.968 ms statement: EXECUTE unnamed [PREPARE: SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_4 JOIN Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN CachedGroupMembers CachedGroupMembers_2 ON ( CachedGroupMembers_2.MemberId = Principals_1.id ) JOIN Groups Groups_3 ON ( Groups_3.id = CachedGroupMembers_2.GroupId ) WHERE (Principals_1.Disabled = '0') AND (ACL_4.PrincipalType = Groups_3.Type) AND (Principals_1.id != '1') AND (Principals_1.PrincipalType = 'User') AND (ACL_4.RightName = 'OwnTicket' OR ACL_4.RightName = 'SuperUser') AND (Groups_3.Domain = 'RT::Queue-Role' AND Groups_3.Instance = '1') AND ((ACL_4.ObjectType = 'RT::Queue' AND ACL_4.ObjectId = 1) OR (ACL_4.ObjectType = 'RT::System')) ORDER BY main.Name ASC ] LOG: duration: 3363.967 ms LOG: duration: 3363.967 ms statement: EXECUTE unnamed [PREPARE: SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_2 JOIN Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN CachedGroupMembers CachedGroupMembers_3 ON ( CachedGroupMembers_3.MemberId = Principals_1.id ) WHERE (Principals_1.Disabled = '0') AND (ACL_2.PrincipalId = CachedGroupMembers_3.GroupId) AND (Principals_1.id != '1') AND (ACL_2.PrincipalType = 'Group') AND (Principals_1.PrincipalType = 'User') AND (ACL_2.RightName = 'OwnTicket' OR ACL_2.RightName = 'SuperUser') AND ((ACL_2.ObjectType = 'RT::Queue' AND ACL_2.ObjectId = 1) OR (ACL_2.ObjectType = 'RT::System')) ORDER BY main.Name ASC ] LOG: duration: 1482.014 ms LOG: duration: 1482.014 ms statement: EXECUTE unnamed [PREPARE: SELECT DISTINCT main.id AS id, main.Content AS content, main.ContentType AS contenttype, main.TransactionId AS transactionid, main.ContentEncoding AS contentencoding FROM Attachments main JOIN Transactions Transactions_1 ON ( Transactions_1.id = main.TransactionId ) JOIN Tickets Tickets_2 ON ( Tickets_2.id = Transactions_1.ObjectId ) WHERE (Tickets_2.EffectiveId = '35803') AND (Transactions_1.ObjectType = 'RT::Ticket') AND (main.ContentType = 'text/plain' OR main.ContentType LIKE 'message/%' OR main.ContentType = 'text') ORDER BY main.id ASC ] LOG: duration: 1329.789 ms LOG: duration: 1329.789 ms statement: EXECUTE unnamed [PREPARE: SELECT DISTINCT main.* FROM Transactions main JOIN Tickets Tickets_1 ON ( Tickets_1.id = main.ObjectId ) WHERE (main.ObjectType = 'RT::Ticket') AND (Tickets_1.EffectiveId = '35803') ORDER BY main.Created ASC, main.id ASC ] # /sbin/sysctl kernel.shmmax kernel.shmall kernel.shmmni kernel.sem kernel.shmmax = 4294967296 kernel.shmall = 2097152 kernel.shmmni = 4096 kernel.sem = 25032000 100 128 # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU X5365 @ 3.00GHz stepping: 1 cpu MHz : 2992.499 cache size : 4096 KB fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx lm constant_tsc up pni ssse3 cx16 lahf_lm bogomips: 5984.99 clflush size: 64
Re: [rt-users] replacing/eliminating undisclosed recipients
Joseph, Have you read the info in RT_Config.pm? I believe it shows how to create your *friendly* To: format. Kenn LBNL On Tue, Sep 21, 2010 at 2:11 PM, Joseph Spenner joseph85...@yahoo.comwrote: --- On Tue, 9/21/10, Kevin Falcone falc...@bestpractical.com wrote: On Tue, Sep 21, 2010 at 12:04:28PM -0700, Joseph Spenner wrote: I'm using RT 3.8.8 with postfix 2.3.3, on CentOS 5.4 64bit. Are you sure about the postfix part (See below)? I noticed the sendmail messages in the logs as well (both postfix and sendmail messages), even though postfix is the only one running. So, I just now removed the sendmail packages from the system, and updated the RT_SiteConfig.pm with: Set($UseFriendlyToLine, 1); I no longer see sendmail messages/errors in the log. However, now the To: address (directed to watchers), looks like this: to: AdminCc of rtbox.mydomain.com Ticket #7:; instead of undisclosed recipients. It's different, but still suboptimal. :) Any more help would be great. Thanks! RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT! RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] Slow PostgreSQL perf with 3.8.7
We have this in place: CREATE INDEX ObjectCustomFieldValues3 ON ObjectCustomFieldValues (ObjectId,ObjectType); And I don't see any other suggested indexes in the wiki. Maybe I am missing a certain page? Should I add these: http://wiki.bestpractical.com/view/DatabaseIndexes Here's the EXPLAIN for one of the slow statements: rt3=# EXPLAIN ANALYZE SELECT DISTINCT main.id AS id, main.Content AS content, main.ContentType AS contenttype, main.TransactionId AS transactionid, main.ContentEncoding AS contentencoding FROM Attachments main JOIN Transactions Transactions_1 ON ( Transactions_1.id = main.TransactionId ) JOIN Tickets Tickets_2 ON ( Tickets_2.id = Transactions_1.ObjectId ) WHERE (Tickets_2.EffectiveId = '35339') AND (Transactions_1.ObjectType = 'RT::Ticket') AND (main.ContentType = 'text/plain' OR main.ContentType LIKE 'message/%' OR main.ContentType = 'text') ORDER BY main.id ASC; QUERY PLAN -- Unique (cost=1033.85..1033.86 rows=1 width=396) (actual time=3720.579..3720.579 rows=1 loops=1) - Sort (cost=1033.85..1033.85 rows=1 width=396) (actual time=3720.373..3720.373 rows=1 loops=1) Sort Key: main.id, main.content, main.contenttype, main.transactionid, main.contentencoding - Nested Loop (cost=17.77..1033.84 rows=1 width=396) (actual time=3569.107..3719.649 rows=1 loops=1) - Nested Loop (cost=14.13..383.55 rows=1 width=4) (actual time=3562.353..3717.041 rows=28 loops=1) - Bitmap Heap Scan on transactions transactions_1 (cost=14.13..154.48 rows=38 width=8) (actual time=159.630..1185.953 rows=75440 loops=1) Recheck Cond: ((objecttype)::text = 'RT::Ticket'::text) - Bitmap Index Scan on transactions1 (cost=0.00..14.13 rows=38 width=0) (actual time=156.409..156.409 rows=133079 loops=1) Index Cond: ((objecttype)::text = 'RT::Ticket'::text) - Index Scan using tickets4 on tickets tickets_2 (cost=0.00..6.02 rows=1 width=4) (actual time=0.026..0.026 rows=0 loops=75440) Index Cond: (tickets_2.id = outer.objectid) Filter: (effectiveid = 35339) - Bitmap Heap Scan on attachments main (cost=3.63..648.02 rows=181 width=396) (actual time=0.078..0.082 rows=0 loops=28) Recheck Cond: (outer.id = main.transactionid) Filter: (((contenttype)::text = 'text/plain'::text) OR ((contenttype)::text ~~ 'message/%'::text) OR ((contenttype)::text = 'text'::text)) - Bitmap Index Scan on attachments2 (cost=0.00..3.63 rows=181 width=0) (actual time=0.011..0.011 rows=1 loops=28) Index Cond: (outer.id = main.transactionid) Total runtime: 3722.252 ms (18 rows) rt3=# On 9/22/2010 12:24 PM, Kenneth Marshall wrote: Hi Jeff, Wow, is that version of PostgreSQL old. Certainly there have been many, many performance improvements since v8.1.x. While upgrading would help, you really need to run an EXPLAIN ANALYZE for your slow queries to see if there is a problem area. Also, you should check to wiki to see if you have all of the recommended PostgreSQL indexes. Some things to check. Ken On Wed, Sep 22, 2010 at 12:12:59PM -0400, Jeff Blaine wrote: Please bear with my ignorance on this topic. I realize this isn't a PostgreSQL tuning forum, but since it's RT-related I thought I'd ask here. RT 3.8.7 (and RTFM) with PostgreSQL 8.1.18 via RHELv5 running as a VM. We're experiencing significant delays today with various PostgreSQL statements taking longer than 1000ms to complete. We have 10,000 tickets, 1300 of which are 'open' Can anyone throw out any ideas, things to check, etc? Is this just Viewing a single ticket results in the following, showing only those longer than 1000ms: LOG: duration: 1496.023 ms LOG: duration: 1496.023 ms statement: EXECUTEunnamed [PREPARE: SELECT DISTINCT main.Id AS id, main.Filename AS filename, main.Headers AS headers, main.Subject AS subject, main.Parent AS parent, main.ContentEncoding AS contentencoding, main.ContentType AS contenttype, main.TransactionId AS transactionid, main.Created AS created FROM Attachments main JOIN Transactions Transactions_1 ON ( Transactions_1.id = main.TransactionId ) JOIN Tickets Tickets_2 ON ( Tickets_2.id = Transactions_1.ObjectId ) WHERE (Tickets_2.EffectiveId = '35803') AND (Transactions_1.ObjectType = 'RT::Ticket') ORDER BY main.id ASC ] LOG: duration: 2207.968 ms LOG: duration: 2207.968 ms statement: EXECUTEunnamed [PREPARE: SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_4 JOIN Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN CachedGroupMembers CachedGroupMembers_2 ON (
[rt-users] ICal showing as plain text.
There was another post, with the same problem but no resolution was given. I've tried the Rt demo site, and it works fine. My system RT 3.8.8 show it in plain text. I compared the URLs between the Demo site and my site and they seem identical, so I'm guessing it's an apache config issue. I check the mime-types in apache and the text/calendar type resolves to ics. I double checked my apache config and it appears consistent with all of the instructions I found. Did anyone solve this? Thanks, Steve RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] Slow PostgreSQL perf with 3.8.7
Hi Jeff, Just a quick glance at your plan seems to indicate that there is a fairly wide discrepency between how many results a query returns and what the planner thinks the query should return. Have you already bumped the planner statistics target to 100 or 200 and then re-analyzed the database. I do not think that 8.1 had autovacuum enabled by default so you should enable it to keep the statistics updated and run a full database-wide re-analyze to update the stats. Then try your query again. Regards, Ken On Wed, Sep 22, 2010 at 12:57:58PM -0400, Jeff Blaine wrote: We have this in place: CREATE INDEX ObjectCustomFieldValues3 ON ObjectCustomFieldValues (ObjectId,ObjectType); And I don't see any other suggested indexes in the wiki. Maybe I am missing a certain page? Should I add these: http://wiki.bestpractical.com/view/DatabaseIndexes Here's the EXPLAIN for one of the slow statements: rt3=# EXPLAIN ANALYZE SELECT DISTINCT main.id AS id, main.Content AS content, main.ContentType AS contenttype, main.TransactionId AS transactionid, main.ContentEncoding AS contentencoding FROM Attachments main JOIN Transactions Transactions_1 ON ( Transactions_1.id = main.TransactionId ) JOIN Tickets Tickets_2 ON ( Tickets_2.id = Transactions_1.ObjectId ) WHERE (Tickets_2.EffectiveId = '35339') AND (Transactions_1.ObjectType = 'RT::Ticket') AND (main.ContentType = 'text/plain' OR main.ContentType LIKE 'message/%' OR main.ContentType = 'text') ORDER BY main.id ASC; QUERY PLAN -- Unique (cost=1033.85..1033.86 rows=1 width=396) (actual time=3720.579..3720.579 rows=1 loops=1) - Sort (cost=1033.85..1033.85 rows=1 width=396) (actual time=3720.373..3720.373 rows=1 loops=1) Sort Key: main.id, main.content, main.contenttype, main.transactionid, main.contentencoding - Nested Loop (cost=17.77..1033.84 rows=1 width=396) (actual time=3569.107..3719.649 rows=1 loops=1) - Nested Loop (cost=14.13..383.55 rows=1 width=4) (actual time=3562.353..3717.041 rows=28 loops=1) - Bitmap Heap Scan on transactions transactions_1 (cost=14.13..154.48 rows=38 width=8) (actual time=159.630..1185.953 rows=75440 loops=1) Recheck Cond: ((objecttype)::text = 'RT::Ticket'::text) - Bitmap Index Scan on transactions1 (cost=0.00..14.13 rows=38 width=0) (actual time=156.409..156.409 rows=133079 loops=1) Index Cond: ((objecttype)::text = 'RT::Ticket'::text) - Index Scan using tickets4 on tickets tickets_2 (cost=0.00..6.02 rows=1 width=4) (actual time=0.026..0.026 rows=0 loops=75440) Index Cond: (tickets_2.id = outer.objectid) Filter: (effectiveid = 35339) - Bitmap Heap Scan on attachments main (cost=3.63..648.02 rows=181 width=396) (actual time=0.078..0.082 rows=0 loops=28) Recheck Cond: (outer.id = main.transactionid) Filter: (((contenttype)::text = 'text/plain'::text) OR ((contenttype)::text ~~ 'message/%'::text) OR ((contenttype)::text = 'text'::text)) - Bitmap Index Scan on attachments2 (cost=0.00..3.63 rows=181 width=0) (actual time=0.011..0.011 rows=1 loops=28) Index Cond: (outer.id = main.transactionid) Total runtime: 3722.252 ms (18 rows) rt3=# On 9/22/2010 12:24 PM, Kenneth Marshall wrote: Hi Jeff, Wow, is that version of PostgreSQL old. Certainly there have been many, many performance improvements since v8.1.x. While upgrading would help, you really need to run an EXPLAIN ANALYZE for your slow queries to see if there is a problem area. Also, you should check to wiki to see if you have all of the recommended PostgreSQL indexes. Some things to check. Ken On Wed, Sep 22, 2010 at 12:12:59PM -0400, Jeff Blaine wrote: Please bear with my ignorance on this topic. I realize this isn't a PostgreSQL tuning forum, but since it's RT-related I thought I'd ask here. RT 3.8.7 (and RTFM) with PostgreSQL 8.1.18 via RHELv5 running as a VM. We're experiencing significant delays today with various PostgreSQL statements taking longer than 1000ms to complete. We have 10,000 tickets, 1300 of which are 'open' Can anyone throw out any ideas, things to check, etc? Is this just Viewing a single ticket results in the following, showing only those longer than 1000ms: LOG: duration: 1496.023 ms LOG: duration: 1496.023 ms statement: EXECUTEunnamed [PREPARE: SELECT DISTINCT main.Id AS id, main.Filename AS filename, main.Headers AS headers, main.Subject AS subject, main.Parent AS parent, main.ContentEncoding AS contentencoding, main.ContentType
[rt-users] ExternalAuth and bounced Emails
I have had great luck implementing ExternalAuth and having all my users authenticating from AD, but here is where I have a problem. I have a Companywide intranet web site that is used to fill out new user forms and submit them via email to our RT system. The From: field on these emails are filled out with a generic intranetadmin email address. Since RT now uses ExternalAuth for usernames this account is not in my AD directory and the email is bounced back. I have the queue setup for everyone : create ticket yet the email is bounced every time. Is there a specific setting in RT_SiteConfig that I need to set to allow this? Thanks in advance. -- Peter Barton RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] Slow PostgreSQL perf with 3.8.7
Ken, Thanks for the replies. I don't see any planner settings in postgresql.conf (so no I've not changed that). I've turned on autovacuum as well as log_planner_stats (on a whim that it might provide useful info based on your lead). Hmm... given how long 'VACUUM FULL;' is taking now, maybe I was connected to the default database when I ran it before starting this thread instead of 'rt3' *fingers crossed* On 9/22/2010 3:25 PM, Kenneth Marshall wrote: Hi Jeff, Just a quick glance at your plan seems to indicate that there is a fairly wide discrepency between how many results a query returns and what the planner thinks the query should return. Have you already bumped the planner statistics target to 100 or 200 and then re-analyzed the database. I do not think that 8.1 had autovacuum enabled by default so you should enable it to keep the statistics updated and run a full database-wide re-analyze to update the stats. Then try your query again. Regards, Ken On Wed, Sep 22, 2010 at 12:57:58PM -0400, Jeff Blaine wrote: We have this in place: CREATE INDEX ObjectCustomFieldValues3 ON ObjectCustomFieldValues (ObjectId,ObjectType); And I don't see any other suggested indexes in the wiki. Maybe I am missing a certain page? Should I add these: http://wiki.bestpractical.com/view/DatabaseIndexes Here's the EXPLAIN for one of the slow statements: rt3=# EXPLAIN ANALYZE SELECT DISTINCT main.id AS id, main.Content AS content, main.ContentType AS contenttype, main.TransactionId AS transactionid, main.ContentEncoding AS contentencoding FROM Attachments main JOIN Transactions Transactions_1 ON ( Transactions_1.id = main.TransactionId ) JOIN Tickets Tickets_2 ON ( Tickets_2.id = Transactions_1.ObjectId ) WHERE (Tickets_2.EffectiveId = '35339') AND (Transactions_1.ObjectType = 'RT::Ticket') AND (main.ContentType = 'text/plain' OR main.ContentType LIKE 'message/%' OR main.ContentType = 'text') ORDER BY main.id ASC; QUERY PLAN -- Unique (cost=1033.85..1033.86 rows=1 width=396) (actual time=3720.579..3720.579 rows=1 loops=1) - Sort (cost=1033.85..1033.85 rows=1 width=396) (actual time=3720.373..3720.373 rows=1 loops=1) Sort Key: main.id, main.content, main.contenttype, main.transactionid, main.contentencoding - Nested Loop (cost=17.77..1033.84 rows=1 width=396) (actual time=3569.107..3719.649 rows=1 loops=1) - Nested Loop (cost=14.13..383.55 rows=1 width=4) (actual time=3562.353..3717.041 rows=28 loops=1) - Bitmap Heap Scan on transactions transactions_1 (cost=14.13..154.48 rows=38 width=8) (actual time=159.630..1185.953 rows=75440 loops=1) Recheck Cond: ((objecttype)::text = 'RT::Ticket'::text) - Bitmap Index Scan on transactions1 (cost=0.00..14.13 rows=38 width=0) (actual time=156.409..156.409 rows=133079 loops=1) Index Cond: ((objecttype)::text = 'RT::Ticket'::text) - Index Scan using tickets4 on tickets tickets_2 (cost=0.00..6.02 rows=1 width=4) (actual time=0.026..0.026 rows=0 loops=75440) Index Cond: (tickets_2.id = outer.objectid) Filter: (effectiveid = 35339) - Bitmap Heap Scan on attachments main (cost=3.63..648.02 rows=181 width=396) (actual time=0.078..0.082 rows=0 loops=28) Recheck Cond: (outer.id = main.transactionid) Filter: (((contenttype)::text = 'text/plain'::text) OR ((contenttype)::text ~~ 'message/%'::text) OR ((contenttype)::text = 'text'::text)) - Bitmap Index Scan on attachments2 (cost=0.00..3.63 rows=181 width=0) (actual time=0.011..0.011 rows=1 loops=28) Index Cond: (outer.id = main.transactionid) Total runtime: 3722.252 ms (18 rows) rt3=# On 9/22/2010 12:24 PM, Kenneth Marshall wrote: Hi Jeff, Wow, is that version of PostgreSQL old. Certainly there have been many, many performance improvements since v8.1.x. While upgrading would help, you really need to run an EXPLAIN ANALYZE for your slow queries to see if there is a problem area. Also, you should check to wiki to see if you have all of the recommended PostgreSQL indexes. Some things to check. Ken On Wed, Sep 22, 2010 at 12:12:59PM -0400, Jeff Blaine wrote: Please bear with my ignorance on this topic. I realize this isn't a PostgreSQL tuning forum, but since it's RT-related I thought I'd ask here. RT 3.8.7 (and RTFM) with PostgreSQL 8.1.18 via RHELv5 running as a VM. We're experiencing significant delays today with various PostgreSQL statements taking longer than 1000ms to complete. We have 10,000 tickets, 1300 of which are 'open' Can anyone throw out any ideas, things to check, etc? Is this
Re: [rt-users] Slow PostgreSQL perf with 3.8.7
On 9/22/2010 4:16 PM, Kenneth Marshall wrote: It should be called default_statistics_target according to the PostgreSQL 8.1 documentation. I would set it to 100 like the current 8.4 default and re-analyze the database: vacuumdb -a -z You could add a '-v' for more information while it is running. You may not have heeded the VACUUM documentation, but you should almost never use VACUUM FULL but just a simple VACUUM. The FULL variant can cause serious index bloating which can only be fixed by running REINDEX. Good luck. Hm, I don't see such a warning here: http://www.postgresql.org/docs/8.1/static/sql-vacuum.html Maybe it's officially-undocumented knowledge of yours from experience? The Notes do say the following, but from what I can tell the only hangup on FULL is that it takes longer and exclusively locks. The FULL option is not recommended for routine use, but may be useful in special cases. An example is when you have deleted most of the rows in a table and would like the table to physically shrink to occupy less disk space. VACUUM FULL will usually shrink the table more than a plain VACUUM would. We *did* in fact RT-Shredder-ify 50% of the tickets 4 weeks ago (bogus tickets from the user's misconfigured code). At any rate, VACUUM FULL ANALYZE solved the problem, which should be addressed going forward by auto-vacuum. Thanks again Cheers, Ken On Wed, Sep 22, 2010 at 04:08:08PM -0400, Jeff Blaine wrote: Ken, Thanks for the replies. I don't see any planner settings in postgresql.conf (so no I've not changed that). I've turned on autovacuum as well as log_planner_stats (on a whim that it might provide useful info based on your lead). Hmm... given how long 'VACUUM FULL;' is taking now, maybe I was connected to the default database when I ran it before starting this thread instead of 'rt3' *fingers crossed* On 9/22/2010 3:25 PM, Kenneth Marshall wrote: Hi Jeff, Just a quick glance at your plan seems to indicate that there is a fairly wide discrepency between how many results a query returns and what the planner thinks the query should return. Have you already bumped the planner statistics target to 100 or 200 and then re-analyzed the database. I do not think that 8.1 had autovacuum enabled by default so you should enable it to keep the statistics updated and run a full database-wide re-analyze to update the stats. Then try your query again. Regards, Ken On Wed, Sep 22, 2010 at 12:57:58PM -0400, Jeff Blaine wrote: We have this in place: CREATE INDEX ObjectCustomFieldValues3 ON ObjectCustomFieldValues (ObjectId,ObjectType); And I don't see any other suggested indexes in the wiki. Maybe I am missing a certain page? Should I add these: http://wiki.bestpractical.com/view/DatabaseIndexes Here's the EXPLAIN for one of the slow statements: rt3=# EXPLAIN ANALYZE SELECT DISTINCT main.id AS id, main.Content AS content, main.ContentType AS contenttype, main.TransactionId AS transactionid, main.ContentEncoding AS contentencoding FROM Attachments main JOIN Transactions Transactions_1 ON ( Transactions_1.id = main.TransactionId ) JOIN Tickets Tickets_2 ON ( Tickets_2.id = Transactions_1.ObjectId ) WHERE (Tickets_2.EffectiveId = '35339') AND (Transactions_1.ObjectType = 'RT::Ticket') AND (main.ContentType = 'text/plain' OR main.ContentType LIKE 'message/%' OR main.ContentType = 'text') ORDER BY main.id ASC; QUERY PLAN -- Unique (cost=1033.85..1033.86 rows=1 width=396) (actual time=3720.579..3720.579 rows=1 loops=1) -Sort (cost=1033.85..1033.85 rows=1 width=396) (actual time=3720.373..3720.373 rows=1 loops=1) Sort Key: main.id, main.content, main.contenttype, main.transactionid, main.contentencoding -Nested Loop (cost=17.77..1033.84 rows=1 width=396) (actual time=3569.107..3719.649 rows=1 loops=1) -Nested Loop (cost=14.13..383.55 rows=1 width=4) (actual time=3562.353..3717.041 rows=28 loops=1) -Bitmap Heap Scan on transactions transactions_1 (cost=14.13..154.48 rows=38 width=8) (actual time=159.630..1185.953 rows=75440 loops=1) Recheck Cond: ((objecttype)::text = 'RT::Ticket'::text) -Bitmap Index Scan on transactions1 (cost=0.00..14.13 rows=38 width=0) (actual time=156.409..156.409 rows=133079 loops=1) Index Cond: ((objecttype)::text = 'RT::Ticket'::text) -Index Scan using tickets4 on tickets tickets_2 (cost=0.00..6.02 rows=1 width=4) (actual time=0.026..0.026 rows=0 loops=75440) Index Cond: (tickets_2.id = outer.objectid) Filter: (effectiveid = 35339) -Bitmap Heap Scan on attachments main
Re: [rt-users] Slow PostgreSQL perf with 3.8.7
Did you performance problem go away? You may want to run a REINDEX on your tables to clear out any bloat which will degrade lookup performance, though. Ken On Wed, Sep 22, 2010 at 04:29:40PM -0400, Jeff Blaine wrote: On 9/22/2010 4:16 PM, Kenneth Marshall wrote: It should be called default_statistics_target according to the PostgreSQL 8.1 documentation. I would set it to 100 like the current 8.4 default and re-analyze the database: vacuumdb -a -z You could add a '-v' for more information while it is running. You may not have heeded the VACUUM documentation, but you should almost never use VACUUM FULL but just a simple VACUUM. The FULL variant can cause serious index bloating which can only be fixed by running REINDEX. Good luck. Hm, I don't see such a warning here: http://www.postgresql.org/docs/8.1/static/sql-vacuum.html Maybe it's officially-undocumented knowledge of yours from experience? The Notes do say the following, but from what I can tell the only hangup on FULL is that it takes longer and exclusively locks. The FULL option is not recommended for routine use, but may be useful in special cases. An example is when you have deleted most of the rows in a table and would like the table to physically shrink to occupy less disk space. VACUUM FULL will usually shrink the table more than a plain VACUUM would. We *did* in fact RT-Shredder-ify 50% of the tickets 4 weeks ago (bogus tickets from the user's misconfigured code). At any rate, VACUUM FULL ANALYZE solved the problem, which should be addressed going forward by auto-vacuum. Thanks again Cheers, Ken On Wed, Sep 22, 2010 at 04:08:08PM -0400, Jeff Blaine wrote: Ken, Thanks for the replies. I don't see any planner settings in postgresql.conf (so no I've not changed that). I've turned on autovacuum as well as log_planner_stats (on a whim that it might provide useful info based on your lead). Hmm... given how long 'VACUUM FULL;' is taking now, maybe I was connected to the default database when I ran it before starting this thread instead of 'rt3' *fingers crossed* On 9/22/2010 3:25 PM, Kenneth Marshall wrote: Hi Jeff, Just a quick glance at your plan seems to indicate that there is a fairly wide discrepency between how many results a query returns and what the planner thinks the query should return. Have you already bumped the planner statistics target to 100 or 200 and then re-analyzed the database. I do not think that 8.1 had autovacuum enabled by default so you should enable it to keep the statistics updated and run a full database-wide re-analyze to update the stats. Then try your query again. Regards, Ken On Wed, Sep 22, 2010 at 12:57:58PM -0400, Jeff Blaine wrote: We have this in place: CREATE INDEX ObjectCustomFieldValues3 ON ObjectCustomFieldValues (ObjectId,ObjectType); And I don't see any other suggested indexes in the wiki. Maybe I am missing a certain page? Should I add these: http://wiki.bestpractical.com/view/DatabaseIndexes Here's the EXPLAIN for one of the slow statements: rt3=# EXPLAIN ANALYZE SELECT DISTINCT main.id AS id, main.Content AS content, main.ContentType AS contenttype, main.TransactionId AS transactionid, main.ContentEncoding AS contentencoding FROM Attachments main JOIN Transactions Transactions_1 ON ( Transactions_1.id = main.TransactionId ) JOIN Tickets Tickets_2 ON ( Tickets_2.id = Transactions_1.ObjectId ) WHERE (Tickets_2.EffectiveId = '35339') AND (Transactions_1.ObjectType = 'RT::Ticket') AND (main.ContentType = 'text/plain' OR main.ContentType LIKE 'message/%' OR main.ContentType = 'text') ORDER BY main.id ASC; QUERY PLAN -- Unique (cost=1033.85..1033.86 rows=1 width=396) (actual time=3720.579..3720.579 rows=1 loops=1) -Sort (cost=1033.85..1033.85 rows=1 width=396) (actual time=3720.373..3720.373 rows=1 loops=1) Sort Key: main.id, main.content, main.contenttype, main.transactionid, main.contentencoding -Nested Loop (cost=17.77..1033.84 rows=1 width=396) (actual time=3569.107..3719.649 rows=1 loops=1) -Nested Loop (cost=14.13..383.55 rows=1 width=4) (actual time=3562.353..3717.041 rows=28 loops=1) -Bitmap Heap Scan on transactions transactions_1 (cost=14.13..154.48 rows=38 width=8) (actual time=159.630..1185.953 rows=75440 loops=1) Recheck Cond: ((objecttype)::text = 'RT::Ticket'::text) -Bitmap Index Scan on transactions1 (cost=0.00..14.13 rows=38 width=0) (actual time=156.409..156.409 rows=133079 loops=1) Index Cond: ((objecttype)::text = 'RT::Ticket'::text) -Index Scan using
[rt-users] CommandByMail - Not send commands to the requester?
Right now, I've got CommandByMail setup and functioning with my RT. The only issue I have, is that if I send a command like status: resolved, it sends the requesting user a copy of that email AND the email saying Your ticket is closed (the second email being expected, of course). If there any way to prevent RT from sending along an email that is CommandByMail commands only? IE If I were to send commands that the ticket is assigned to X helpdesk agent, I wouldn't want the end user to get that also. Thanks! -Jon RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] ExternalAuth and bounced Emails
Peter, Have you tried simply adding that email address (some kind of name for ID) as a Privileged user manually? That might work. We use LDAP, but we also allow our production job scheduler to send emails to an RT Queue when a job abends and we have no problems. We manually added a new user with That info to RT as a Privileged user and put that Id into a Group and gave that Group CreateTicket rights for those particular Queues. Kenn LBNL On Wed, Sep 22, 2010 at 12:52 PM, Peter Barton pbar...@iesi.com wrote: I have had great luck implementing ExternalAuth and having all my users authenticating from AD, but here is where I have a problem. I have a Companywide intranet web site that is used to fill out new user forms and submit them via email to our RT system. The From: field on these emails are filled out with a generic “intranetadmin” email address. Since RT now uses ExternalAuth for usernames this account is not in my AD directory and the email is bounced back. I have the queue setup for everyone : create ticket yet the email is bounced every time. Is there a specific setting in RT_SiteConfig that I need to set to allow this? Thanks in advance. -- Peter Barton RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT! RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] replacing/eliminating undisclosed recipients
On Wed, Sep 22, 2010 at 10:49:20AM -0700, Joseph Spenner wrote: --- On Wed, 9/22/10, Kenneth Crocker kfcroc...@lbl.gov wrote: From: Kenneth Crocker kfcroc...@lbl.gov Subject: Re: [rt-users] replacing/eliminating undisclosed recipients To: rt-users@lists.bestpractical.com Date: Wednesday, September 22, 2010, 10:28 AM Joseph, Have you read the info in RT_Config.pm? I believe it shows how to create your friendly To: format. Kenneth: I saw that, but the syntax wasn't very clear to me. I see where I should set: Set($UseFriendlyToLine, 1); You could use the Format defined about 5 lines later in the config file, or see my earlier email in this thread about how to set a To: line for certain kinds of notifications. -kevin pgp75Y7afHcB9.pgp Description: PGP signature RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] CommandByMail - Not send commands to the requester?
On Wed, Sep 22, 2010 at 01:50:38PM -0700, Jon Davis wrote: Right now, I've got CommandByMail setup and functioning with my RT. The only issue I have, is that if I send a command like status: resolved, it sends the requesting user a copy of that email AND the email saying Your ticket is closed (the second email being expected, of course). If there any way to prevent RT from sending along an email that is CommandByMail commands only? IE If I were to send commands that the ticket is assigned to X helpdesk agent, I wouldn't want the end user to get that also. Use the comment address for RT instead? -kevin pgppeots2KomE.pgp Description: PGP signature RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
