[rt-users] ARF report parsing/handling - DMARC reports
Greetings, Have recently set up capability to receive DMARC aggregate reports from email providers and I believe they are delivered as zip'd ARF XML documents. Noticed the following blurb on RTIR features: we've written custom parsers to handle DMCA complaints and feedback loop emails conforming to the Abuse Reporting Format (ARF). Wanted to see if there's any of this code in public distribution at this point, or if anyone that has implemented this in a satisfactory way had anything they could share about their approach. Not sure what the possibilities are for handling reports with automation and finesse, but at the very least I thought it'd be interesting to automate Incident Report creation on receipt. -- Darren Spruell phatbuck...@gmail.com -- RT Training - Dallas May 20-21 http://bestpractical.com/training
[rt-users] FCGI module missing when configured for fastcgi handler
/site_perl /usr/libdata/perl5/i386-openbsd/5.12.2 /usr/libdata/perl5 /usr/local/libdata/perl5 .) at /usr/local/libdata/perl5/site_perl/Plack/Handler/FCGI.pm line 8. BEGIN failed--compilation aborted at /usr/local/libdata/perl5/site_perl/Plack/Handler/FCGI.pm line 8. Compilation failed in require at /usr/local/libdata/perl5/site_perl/Plack/Util.pm line 23. (/opt/rt4/sbin/../lib/RT.pm:393) Something went wrong while trying to run RT's standalone web server: Can't locate FCGI.pm in @INC (@INC contains: /opt/rt4/sbin/../local/lib /opt/rt4/sbin/../lib /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl /usr/libdata/perl5/i386-openbsd/5.12.2 /usr/libdata/perl5 /usr/local/libdata/perl5 .) at /usr/local/libdata/perl5/site_perl/Plack/Handler/FCGI.pm line 8. BEGIN failed--compilation aborted at /usr/local/libdata/perl5/site_perl/Plack/Handler/FCGI.pm line 8. Compilation failed in require at /usr/local/libdata/perl5/site_perl/Plack/Util.pm line 23.a Installing FCGI from cpan fixes this as expected, but is there a reason the dependency wasn't picked up at testdeps phase? -- Darren Spruell phatbuck...@gmail.com -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
[rt-users] API key support for RT REST API
Hi, Haven't found anything in searching for references, but I was wondering if RT currently has support for user authentication in the REST API using API keys/tokens. If not, is this something that has been discussed for future support? We maintain an RT setup where we authenticate via a corporate LDAP (via ExternalAuth) and users authenticate to RT using their corp credentials. We'd like to do some utility scripting against the API and would be far more comfortable using a key/token that is useful only for the purposes of interfacing with RT. This would prevent unintentional unsafe handling of some users' credentials that might want to hardcode them in scripts/tools. Also an API key can somewhat simplify the process of interacting over sessions of multiple requests, replacing auth exchange and cookie stashing with a more stateless mechanism. -- Darren Spruell phatbuck...@gmail.com
[rt-users] RT setup and Postgres object ownership
Recent user of RT on PostgreSQL backend (a couple of years on MySQL) and have been struggling to understand something related to DB access privileges under postgres with RT's setup. I don't understand how the default ownership/rights after the RT setup, done using the postgres superuser (DBA), allow the RT user to have read/write access to RT objects. What I got: # Database ownership set to Pg superuser. No privileges for other roles present. postgres=# \l+ Name| Owner | Encoding | Collate |Ctype| Access privileges | Size | Tablespace | Description ---++--+-+-+---+-++ rt4 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | 9061 kB | pg_default | # Only a single schema, public. Only Pg superuser granted explicit privileges; no privileges for other roles present. rt4=# \dn+ List of schemas Name | Owner | Access privileges | Description +--+--+ public | postgres | postgres=UC/postgres+| standard public schema | | =UC/postgres # Owner of all tables is also DB superuser (by inheritance, I'm assuming). rt4=# \dt+ List of relations Schema | Name | Type | Owner |Size| Description +-+---+--++- public | acl | table | postgres | 40 kB | public | articles| table | postgres | 8192 bytes | public | attachments | table | postgres | 72 kB | public | attributes | table | postgres | 96 kB | public | cachedgroupmembers | table | postgres | 48 kB | public | classes | table | postgres | 16 kB | public | customfields| table | postgres | 16 kB | public | customfieldvalues | table | postgres | 88 kB | public | groupmembers| table | postgres | 8192 bytes | public | groups | table | postgres | 48 kB | public | links | table | postgres | 16 kB | public | objectclasses | table | postgres | 8192 bytes | public | objectcustomfields | table | postgres | 40 kB | public | objectcustomfieldvalues | table | postgres | 16 kB | public | objecttopics| table | postgres | 0 bytes| public | principals | table | postgres | 40 kB | public | queues | table | postgres | 16 kB | public | scripactions| table | postgres | 16 kB | public | scripconditions | table | postgres | 16 kB | public | scrips | table | postgres | 48 kB | public | sessions| table | postgres | 160 kB | public | templates | table | postgres | 48 kB | public | tickets | table | postgres | 8192 bytes | public | topics | table | postgres | 8192 bytes | public | transactions| table | postgres | 48 kB | public | users | table | postgres | 16 kB | I'm guessing this is more a a postgres access privileges topic than a RT topic - but curious how the application DB user has privileges to these objects, and also why the default installation doesn't set the app user (rt_user) as the owner of the database and then allow inheritance to set ownership on child objects. -- Darren Spruell phatbuck...@gmail.com We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Dump all except tickets+attachments?
A bunch of people wrote: [...] This has been an informative thread, thanks for the responses. -- Darren Spruell phatbuck...@gmail.com RT Training Sessions (http://bestpractical.com/services/training.html) * Chicago, IL, USA September 26 27, 2011 * San Francisco, CA, USA October 18 19, 2011 * Washington DC, USA October 31 November 1, 2011 * Melbourne VIC, Australia November 28 29, 2011 * Barcelona, Spain November 28 29, 2011
Re: [rt-users] Dump all except tickets+attachments?
On Wed, Aug 17, 2011 at 8:01 AM, Jeff Blaine jbla...@kickflop.net wrote: Replying to my thread starter from a few months ago. On 6/23/2011 11:32 AM, Jeff Blaine wrote: If anyone has any clever advice as to how to about this, I'd love to hear it. RT 3.8.7 + security patches, PostgreSQL 8.1.23, RHEL5 We need to replicate our production RT instance's data to a development instance (yes, backward), but we don't want to carry the ~6GB of *ticket and attachment* data (what else?) over to development. Essentially, we want the same environment in development as production, but with empty queues. Warning: Do not try this. It seemed to work fine, then weird things started popping up. Instead, dump everything from production, restore everything on the dev server, then shred the tickets on the dev server. I had a use case similar to this (backporting production DB to a dev environment, wanting to drop all tickets and related data but preserve everything else). In my case I had tried to shred the tickets but ran into an error to the effect of too many tickets specified by the shredder resulting in too long of a GET request URI length for the server. I concluded that shredding that many tickets from the UI wasn't going to work and there must be a better way. Is this right, or is there some way of massaging a deployment to delete a largish number of tickets? (In our case it was something like ~3500 tickets in the four RTIR queues). Happy to post back with details if needed. -- Darren Spruell phatbuck...@gmail.com RT Training Sessions (http://bestpractical.com/services/training.html) * Chicago, IL, USA September 26 27, 2011 * San Francisco, CA, USA October 18 19, 2011 * Washington DC, USA October 31 November 1, 2011 * Melbourne VIC, Australia November 28 29, 2011 * Barcelona, Spain November 28 29, 2011
[rt-users] RT database table relations
Greetings, I was exploring some integration with the RT database from an external web framework and realized that there don't seem to be any key relations established between tables I'm looking at in the DB. Is this purposeful or something that just never made it in? E.g. tickets.queue as foreign key to queues.id tickets.owner as foreign key to users.id (etc.) Everything works fine without this of course; I'm just thinking that certain queries are likely to be simpler in some use cases. Would utilizing key relations be generally beneficial (referential integrity/etc.) or harmful in the ~current RT DB design? RT 3.8.8 with Postgresql 8.4.4. -- Darren Spruell phatbuck...@gmail.com
