Re: [rt-users] S/MIME signed emails are detected as non-plaintext

2014-08-25 Thread ms
On 20/08/2014 18:33, Alex Vandiver wrote:
 On 08/18/2014 11:12 AM, m...@fv-berlin.de wrote:
 we're running RT 4.2.5 and have noticed a minor annoyance.

 When you send an S/MIME-signed (not encrypted!) mail to RT to create a
 ticket, the email body will be added as quoted text because it's not
 plain text. You can click on the quoted text to read it perfectly fine,
 but this is still somewhat of an annoyance. Is this behaviour something
 I can configure, maybe in a list of acceptable content-types or something?
 
 Can you try enabling RT's S/MIME support, and see how that improves
 things?  See:
 
 http://docs.bestpractical.com/RT_Config.html#Cryptography
 http://docs.bestpractical.com/RT/Crypt.html#CONFIGURATION
 http://docs.bestpractical.com/RT/Crypt/SMIME.html#CONFIGURATION
 
 The following should be a minimal implementation:
 
 Set( %SMIME,
 Enable = 1,
 AcceptUntrustedCAs = 1,
 );
 
 Set(@MailPlugins, 'Auth::MailFrom', 'Auth::Crypt' );
 
 
  - Alex
 
 

That does seem to work, although I had to add the keyring and CAPath
options because otherwise the rt-fulltext-indexer cron job would send an
error email every 5 minutes indicating it didnt find the keyring. Now
there's no log entries regarding s/mime whatsoever. This is good and bad:

- good because emails in RT show up perfectly fine now. The change is
not retroactive, but I didn't expect that, thats fine.

- bad because if you try to sign outgoing response emails, the sent
emails are empty (if Sign is left unchecked, they are fine). It is
entirely possible this is an error on my end putting a wrong/incomplete
keyfile there, but at least I wouldv'e hoped to find some
INFO/WARN/ERR-type log entries regarding that, but sadly not. I might
enable debug-logging and see what's going on later.


Thanks for the help!

-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training


[rt-users] S/MIME signed emails are detected as non-plaintext

2014-08-18 Thread ms
Hi,

we're running RT 4.2.5 and have noticed a minor annoyance.

When you send an S/MIME-signed (not encrypted!) mail to RT to create a
ticket, the email body will be added as quoted text because it's not
plain text. You can click on the quoted text to read it perfectly fine,
but this is still somewhat of an annoyance. Is this behaviour something
I can configure, maybe in a list of acceptable content-types or something?

Such mails may look like this:

MIME-Version: 1.0
Content-Type: multipart/signed;
protocol=application/x-pkcs7-signature;
micalg=2.16.840.1.101.3.4.2.1;
boundary==_NextPart_000_001C_01CFBB05.63DBBF10

This is a multipart message in MIME format.

--=_NextPart_000_001C_01CFBB05.63DBBF10
Content-Type: multipart/related;
boundary==_NextPart_001_001D_01CFBB05.63DBBF10


--=_NextPart_001_001D_01CFBB05.63DBBF10
Content-Type: multipart/alternative;
boundary==_NextPart_002_001E_01CFBB05.63DBBF10


--=_NextPart_002_001E_01CFBB05.63DBBF10
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

(The actual message body starts here)
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training


Re: [rt-users] File attachments corrupted after DB migration (Was: Mailgate doesnt generate tickets after Upgrade)

2014-05-08 Thread ms
On 07/05/2014 16:40, Kevin Falcone wrote:
 On Wed, May 07, 2014 at 12:51:07AM +0200, m...@fv-berlin.de wrote:
 used rt-serializer to dump the database,
 used rt-importer.
 
 Yeah - those are the relevant steps you didn't mention.
 You're running into this bug I expect
 http://issues.bestpractical.com/Ticket/Display.html?id=29158
 
 -kevin

Yes that was the issue indeed and the posted SQL queries fixed it, thanks!


With that out of the way we have found a new issue from the migration
(hence the new subject): the attached files that were migrated are garbled.

With that I mean:

- TXT files are fine, even the charset is correct
- ANY kind of file with binary in it (we tested jpg, pdf, doc, zip)
appears to be corrupted. The plaintext bits of these files are identical
(like a jpg has the plaintext string JFIF in its header), but
everything else is completely messed up to the point where even the jpg
header becomes invalid.

I have attached 2 files (~40kb for both): -new from the migrated system
and -old from the old system. The differences in a hex editor are pretty
apparent, everything that's not plaintext is just wrong.


Are there maybe any command line switches to rt-serializer and
rt-importer that I missed?

Thanks for the help!



-- 
RT Training - Dallas May 20-21
http://bestpractical.com/training

[rt-users] Mailgate doesnt generate tickets after Upgrade

2014-05-06 Thread ms
Hi,

I just updated an old 3.8.4 RT to 4.2.3 and from what I can tell the
actual RT system works fine, fulltext search is up and running... but
the mailgate seems to unable to create tickets. heres the
apache2/error.log section:

[warning]: Use of uninitialized value $domain in pattern match (m//) at
/opt/rt4/sbin/../lib/RT/Group.pm line 659.
(/opt/rt4/sbin/../lib/RT/Group.pm:659)

[error]: Couldn't create a role group of type 'AdminCc' for RT::Ticket
1: Gruppe konnte nicht erstellt werden
(/opt/rt4/sbin/../lib/RT/Record/Role/Roles.pm:587)

[critical]: Couldn't create ticket groups for ticket 1. aborting Ticket
creation. (/opt/rt4/sbin/../lib/RT/Ticket.pm:433)

[crit]: Ticket creation failed: test2: Anfrage konnte aufgrund eines
internen Fehlers nicht angelegt werden
(/opt/rt4/sbin/../lib/RT/Interface/Email.pm:245)

[error]: Could not record email: Ticket creation From: [redacted]
u...@example.com[redacted] failed: Anfrage konnte aufgrund eines
internen Fehlers nicht angelegt werden
(/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway:75)

[warning]: DBD::Pg::st execute failed: ERROR:  duplicate key value
violates unique constraint principals_pkey
DETAIL:  Key (id)=(3) already exists. at
/usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 589.
(/usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm:589)

[warning]: RT::Handle=HASH(0x7dacfb0) couldn't execute the query 'INSERT
INTO Principals (ObjectId, PrincipalType) VALUES (?, ?)' at
/usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 602.

DBIx::SearchBuilder::Handle::SimpleQuery(RT::Handle=HASH(0x7dacfb0),
INSERT INTO Principals (ObjectId, PrincipalType) VALUES (?, ?), 0,
Group) called at
/usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 352
[...]

To me this looks like the mailgate tries to create tickets with IDs
starting from 1 instead of using an unused ID and subsequently
everything else associated to this ticket creation (Role/Group creation)
fails too, but maybe I am looking at this the wrong way. In any case,
feedback is greatly appreciated.
-- 
RT Training - Dallas May 20-21
http://bestpractical.com/training


Re: [rt-users] Mailgate doesnt generate tickets after Upgrade

2014-05-06 Thread ms
On 06/05/2014 22:26, Kevin Falcone wrote:
 On Tue, May 06, 2014 at 02:34:32PM +0200, m...@fv-berlin.de wrote:
 Hi,

 I just updated an old 3.8.4 RT to 4.2.3 and from what I can tell the
 actual RT system works fine, fulltext search is up and running... but
 the mailgate seems to unable to create tickets. heres the
 apache2/error.log section:
 
 This looks like your sequences are wrong.
 Did you do just an upgrade, or an upgrade and a database migration.
 If a database migration, how?
 
 -kevin
 
 
 
I mysqldump'd the 3.8.4 system,
imported it into mysql on a different system (VM) that had RT 4.0.4
installed,
upgraded to 4.0.4,
ran the additional steps mentioned in the UPGRADE docs
(vulnerable-passwords, shrink_transactions_table, shrink_cgm_table),
mysqldump'd the result,
imported that into yet another system into mysql,
upgraded to 4.2.3,
ran rt-validator --check --resolve,
used rt-serializer to dump the database,
ran ./configure (--with-db-type=Pg), make testdeps, make fixdeps, make
install again to get pgsql-support,
changed RT_SiteConfig to set it to pgsql,
used rt-importer.


I have also since I posted this initially, found out that I can browse
the RT just fine, but it seems I cannot write to the database in any way
(by say creating a new ticket) because I'd get the same internal error
and either the apache errorlog or syslog saying

[933] DBD::Pg::st execute failed: ERROR:  duplicate key value violates
unique constraint principals_pkey DETAIL:  Key (id)=(7) already
exists. at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm
line 589.


as if RT had lost track of the highest occupied ticket ID along the way
and just started from 1 again.
-- 
RT Training - Dallas May 20-21
http://bestpractical.com/training


[rt-users] rt-importer in 4.2.2 with a typo?

2014-02-10 Thread ms
Hi,

I was trying to migrate from mysql to pgsql with a 4.2.2 installation.

The 4.2.2 installation ran just fine.

I then had to run ./configure again with --with-db-type=Pg to get the
missing dependencies via 'make fixdeps'.

I then ran rt-serializer --clone --directory /root/rt422-mysql/
which completed just fine after bumping up the VM to 2gigs of memory

Next up I prepared the pgsql database:

rt-setup-database --action=create,acl,schema
#as per documentation, no action=init for a clone

Now I tried to import that:

rt-importer /root/rt422-mysql/

However, this almost immediately fails with:

[11764] [Mon Feb 10 18:12:01 2014] [warning]:
Can't read /root/rt422-mysql/root/rt422-mysql/001.dat: No such file or
directory at /opt/rt4/sbin/../lib/RT/Migrate/Importer/File.pm line 102.
(/opt/rt4/sbin/../lib/RT/Migrate/Importer/File.pm:97)


As you can see it doubles the path because its looking for 001.dat in
the wrong place. Is this a typo somewhere within the rt-importer script
or did I do something wrong?


Kind regards,
ms


[rt-users] Real time fulltext search/indexing with sphinx

2014-01-17 Thread ms
Hi,

as you can see on these slides:
http://www.slideshare.net/AdrianNuta1/real-time-fulltext-search-with-sphinx

... it is now possible with sphinx to allow for actual realtime
searching, something that I have come to realize while researching, not
even postgresql allows for. There is a caveat to this though: this
functionality is not transparent to the application, meaning that RT
would need to be modified to support this. Is this being worked on
already, or is this something that could be suggested?

Regards, ms


Re: [rt-users] RES: RE: RES: Sphinx fulltext index v4.0.4

2013-12-17 Thread ms
Hi,

didn't get a response there. Is there a way to solve this? Possibly
through debugging RT4 to see how its actually trying to connect to
searchd instead of how the config looks like it should?

Regards

On 04/12/2013 13:45, m...@fv-berlin.de wrote:
 On Jan 5 09:55:28 EST 2012, Luciano Ernesto da Silva wrote:
 
 Hi,
 
 did you ever receive an answer to your problem because I am encountering
 the same thing (searchd running on 0.0.0.0:3312 but RT reporting it cant
 connect to it / resolve localhost).
 
 Additionally to what you already posted, I made sure /etc/hosts connects
 127.0.0.1 to localhost and commented out the ::1 line because I
 suspected RT4 might not be IPv6-aware, but that didnt help.
 
 KR
 
 Hello,

 This is my configuration on sphinx.conf, seems that even I change the
 name of sql_host, RT still says : failed to resolve searchd host
 (name=localhost). Seems that RT isn't looking to the right  connection.


 Luciano


 vi /etc/sphinxsearch/sphinx.conf


 source rt {
 type= mysql

 sql_host= localhost
 sql_db  = rt4
 sql_user= rt4
 sql_pass= secret

 sql_query_pre   = SET NAMES utf8
 sql_query   = \
 SELECT a.id, a.content FROM Attachments a \
 JOIN Transactions txn ON a.TransactionId = txn.id AND
 txn.ObjectType = 'RT::Ticket' \
 JOIN Tickets t ON txn.ObjectId = t.id \
 WHERE a.ContentType = 'text/plain' AND t.Status != 'deleted'
 sql_query_info  = SELECT * FROM Attachments WHERE id=$id
 }

 index rt {
 source  = rt
 path= /opt/rt4/var/sphinx/index
 docinfo = extern
 charset_type= utf-8
 }

 indexer {
 mem_limit   = 32M
 }

 searchd {
 port= 3312
 log = /opt/rt4/var/sphinx/searchd.log
 query_log   = /opt/rt4/var/sphinx/query.log
 read_timeout= 5
 max_children= 30
 pid_file= /opt/rt4/var/sphinx/searchd.pid
 max_matches = 1
 seamless_rotate = 1
 preopen_indexes = 1
 unlink_old  = 1
 compat_sphinxql_magics  = 0
 }

 Sphinx is running OK:

 netstat -ntlp | grep searchd
 tcp0  0 0.0.0.0:33120.0.0.0:*
 LISTEN  10762/searchd

 ps -eaf |grep searchd 
 root 10762 1  0 09:17 pts/000:00:00 searchd

 The table AttachmentsIndex seems OK:

 mysql show create table AttachmentsIndex; 
 +--+
 
 
 ---+
 | Table| Create Table
 |
 +--+
 
 
 ---+
 | AttachmentsIndex | CREATE TABLE `AttachmentsIndex` (
   `id` int(10) unsigned NOT NULL,
   `weight` int(11) NOT NULL,
   `query` varchar(3072) NOT NULL,
   KEY `query` (`query`(1024))
 ) ENGINE=SPHINX DEFAULT CHARSET=utf8
 CONNECTION='sphinx://localhost:3312/rt' |
 +--+
 
 
 ---+
 1 row in set (0.00 sec)

 -Mensagem original-
 De: Poulter, Dale [mailto:dale.poulter at Vanderbilt.Edu] 
 Enviada em: quinta-feira, 5 de janeiro de 2012 10:50
 Para: Luciano Ernesto da Silva; rt-users at lists.bestpractical.com
 Assunto: RE: [rt-users] RES: Sphinx fulltext index v4.0.4

 Sounds like it cannot connect to the sphinx server.  Can you confirm
 that sphinx is running (ps -eaf |grep searchd ) and that it is running
 on the port specified in the attachmentsindex create statement (mysql
 show create table AttachmentsIndex; )?   I believe the default port is
 9312 but the documents at
 http://blog.bestpractical.com/2011/06/full-text-searching.html indicate
 that the port is 3312.

 -Original Message-
 From: rt-users-bounces at lists.bestpractical.com
 [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Luciano
 Ernesto da Silva
 Sent: Thursday, January 05, 2012 5:24 AM
 To: rt-users at lists.bestpractical.com
 Subject: [rt-users] RES: Sphinx fulltext index v4.0.4

 Hello,

 I installed everything as described here by Dale/ documentation from
 docs/full_text_indexing.podc  ,  documentarion by sphinxsearch but i got
 this error:

 RT: DBD::mysql::st execute failed: Unable to connect to foreign data
 source: failed to resolve searchd host (name=localhost) at
 

Re: [rt-users] RES: RE: RES: Sphinx fulltext index v4.0.4

2013-12-04 Thread ms
On Jan 5 09:55:28 EST 2012, Luciano Ernesto da Silva wrote:

Hi,

did you ever receive an answer to your problem because I am encountering
the same thing (searchd running on 0.0.0.0:3312 but RT reporting it cant
connect to it / resolve localhost).

Additionally to what you already posted, I made sure /etc/hosts connects
127.0.0.1 to localhost and commented out the ::1 line because I
suspected RT4 might not be IPv6-aware, but that didnt help.

KR

 Hello,
 
 This is my configuration on sphinx.conf, seems that even I change the
 name of sql_host, RT still says : failed to resolve searchd host
 (name=localhost). Seems that RT isn't looking to the right  connection.
 
 
 Luciano
 
 
 vi /etc/sphinxsearch/sphinx.conf
 
 
 source rt {
 type= mysql
 
 sql_host= localhost
 sql_db  = rt4
 sql_user= rt4
 sql_pass= secret
 
 sql_query_pre   = SET NAMES utf8
 sql_query   = \
 SELECT a.id, a.content FROM Attachments a \
 JOIN Transactions txn ON a.TransactionId = txn.id AND
 txn.ObjectType = 'RT::Ticket' \
 JOIN Tickets t ON txn.ObjectId = t.id \
 WHERE a.ContentType = 'text/plain' AND t.Status != 'deleted'
 sql_query_info  = SELECT * FROM Attachments WHERE id=$id
 }
 
 index rt {
 source  = rt
 path= /opt/rt4/var/sphinx/index
 docinfo = extern
 charset_type= utf-8
 }
 
 indexer {
 mem_limit   = 32M
 }
 
 searchd {
 port= 3312
 log = /opt/rt4/var/sphinx/searchd.log
 query_log   = /opt/rt4/var/sphinx/query.log
 read_timeout= 5
 max_children= 30
 pid_file= /opt/rt4/var/sphinx/searchd.pid
 max_matches = 1
 seamless_rotate = 1
 preopen_indexes = 1
 unlink_old  = 1
 compat_sphinxql_magics  = 0
 }
 
 Sphinx is running OK:
 
 netstat -ntlp | grep searchd
 tcp0  0 0.0.0.0:33120.0.0.0:*
 LISTEN  10762/searchd
 
 ps -eaf |grep searchd 
 root 10762 1  0 09:17 pts/000:00:00 searchd
 
 The table AttachmentsIndex seems OK:
 
 mysql show create table AttachmentsIndex; 
 +--+
 
 
 ---+
 | Table| Create Table
 |
 +--+
 
 
 ---+
 | AttachmentsIndex | CREATE TABLE `AttachmentsIndex` (
   `id` int(10) unsigned NOT NULL,
   `weight` int(11) NOT NULL,
   `query` varchar(3072) NOT NULL,
   KEY `query` (`query`(1024))
 ) ENGINE=SPHINX DEFAULT CHARSET=utf8
 CONNECTION='sphinx://localhost:3312/rt' |
 +--+
 
 
 ---+
 1 row in set (0.00 sec)
 
 -Mensagem original-
 De: Poulter, Dale [mailto:dale.poulter at Vanderbilt.Edu] 
 Enviada em: quinta-feira, 5 de janeiro de 2012 10:50
 Para: Luciano Ernesto da Silva; rt-users at lists.bestpractical.com
 Assunto: RE: [rt-users] RES: Sphinx fulltext index v4.0.4
 
 Sounds like it cannot connect to the sphinx server.  Can you confirm
 that sphinx is running (ps -eaf |grep searchd ) and that it is running
 on the port specified in the attachmentsindex create statement (mysql
 show create table AttachmentsIndex; )?   I believe the default port is
 9312 but the documents at
 http://blog.bestpractical.com/2011/06/full-text-searching.html indicate
 that the port is 3312.
 
 -Original Message-
 From: rt-users-bounces at lists.bestpractical.com
 [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Luciano
 Ernesto da Silva
 Sent: Thursday, January 05, 2012 5:24 AM
 To: rt-users at lists.bestpractical.com
 Subject: [rt-users] RES: Sphinx fulltext index v4.0.4
 
 Hello,
 
 I installed everything as described here by Dale/ documentation from
 docs/full_text_indexing.podc  ,  documentarion by sphinxsearch but i got
 this error:
 
 RT: DBD::mysql::st execute failed: Unable to connect to foreign data
 source: failed to resolve searchd host (name=localhost) at
 /usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm line 587.
 (/usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm:587)
 Jan  5 08:45:16 rt4 RT: RT::Handle=HASH(0x7faacbf8ec58) couldn't execute
 the query 'SELECT COUNT(DISTINCT main.id) FROM Tickets 

[rt-users] Having trouble upgrading: Unknown column 'm.LastUpdatedBy' in 'on clause' at /usr/sbin/rt-validator

2013-12-02 Thread ms
Hi,

I'm trying to upgrade a 3.6.1-4 (don't ask) RT to 4.0.4-2 and I ran into
issues.

First of all: I am doing this upgrade (test) on a duplicate of the
actual production system, so no worries.

As part of the preparation before running the actual database upgrade, I ran

rt-validator --check

Which produced messages for about 20 occurrences like Record #175 in
Groups has the same set of values as 191

... but. After that, its also saying this:

[warning]: DBD::mysql::st execute failed: Unknown column
'm.LastUpdatedBy' in 'on clause' at /usr/sbin/rt-validator line 1078.
(/usr/sbin/rt-validator:1078)
[crit]: DBD::mysql::st execute failed: Unknown column 'm.LastUpdatedBy'
in 'on clause' at /usr/sbin/rt-validator line 1078.
(/usr/share/request-tracker4/lib/RT.pm:351)
DBD::mysql::st execute failed: Unknown column 'm.LastUpdatedBy' in 'on
clause' at /usr/sbin/rt-validator line 1078.



It is entirely possible, that I have missed an essential upgrade step,
but I couldn't find anything in UPGRADE-3.8 or UPGRADE-4.0 mentioning
LastUpdatedBy...?

Now, this warning+error also occur when trying to run --check --resolve,
so I assume it doesn't actually resolve these conflicts.

At least that's how I explained the following error, that occurs when
running the actual database upgrade afterwards:

[...]
Processing 3.7.81
Now populating database schema.
[crit]: DBD::mysql::st execute failed: Duplicate key name
'CachedGroupMembers3' at /usr/share/request-tracker4/lib/RT/Handle.pm
line 515. (/usr/share/request-tracker4/lib/RT.pm:351)
DBD::mysql::st execute failed: Duplicate key name 'CachedGroupMembers3'
at /usr/share/request-tracker4/lib/RT/Handle.pm line 515.


Any pointers towards fixing this would be greatly appreciated!



Regards,
ms