Re: [otrs] wrong timezone in DATE email header, OTRS 4.0.7

[Roman Ovchinnikov]

Hello!
Any ideas about this?

Ovchinnikov Roman, Paymantix
Cell +7 (926) 262-40-05 | Email: r.ovchinni...@paymantix.com| Skype: 
rovchinnikov.mm

On 30.04.2015 13:13, Roman Ovchinnikov wrote:
> Hello!
> Recently we have installed otrs 4.0.7 and found that emails being sent
> from system has wrong timezone settings in Date field, for example:
>
> Received: from mail.paymantix.com (LHLO mail.paymantix.com) (78.140.183.180)
>  by mail.paymantix.com with LMTP; Thu, 30 Apr 2015 09:30:28 + (UTC)
> Received: from mail.paymantix.com (localhost [127.0.0.1])
>   by mail.paymantix.com (Postfix) with ESMTPS id 9962116113E
>   for ; Thu, 30 Apr 2015 09:30:28 + (UTC)
> Received: from localhost (localhost [127.0.0.1])
>   by mail.paymantix.com (Postfix) with ESMTP id 8C8AA161198
>   for ; Thu, 30 Apr 2015 09:30:28 + (UTC)
> X-Virus-Scanned: amavisd-new at paymantix.com
> Received: from mail.paymantix.com ([127.0.0.1])
>   by localhost (mail.paymantix.com [127.0.0.1]) (amavisd-new, port 10026)
>   with ESMTP id BT8gD6m4-Jxz for ;
>   Thu, 30 Apr 2015 09:30:28 + (UTC)
> Received: from otrs.paymantix.net (unknown [78.140.183.183])
>   by mail.paymantix.com (Postfix) with ESMTPS id 778EA16113E
>   for ; Thu, 30 Apr 2015 09:30:28 + (UTC)
> Received: from otrs.paymantix.net (localhost [127.0.0.1])
>   by otrs.paymantix.net (Postfix) with ESMTP id 5FF5F93
>   for ; Thu, 30 Apr 2015 09:30:03 + (UTC)
> MIME-Version: 1.0
> Subject: [Ticket#0100341] RE: test
> X-Powered-BY: OTRS - Open Ticket Request System (http://otrs.org/)
> X-Mailer: OTRS Mail Service (4.0.7)
> Date: Thu, 30 Apr 2015 12:30:03 +
>
>
> as you can see, date in mail server messages are ok
> 09:30:28 + (UTC)), while
> Date: Thu, 30 Apr 2015 12:30:03 +
>
> so, offset is wrong. Server itself has UTC timezone, OTRS is configured as 
> UTC +3 .
>
> Not sure what else should be tweaked, googling didn't give me any insights on 
> this.
>

-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] wrong timezone in DATE email header, OTRS 4.0.7

[Gerald Young]

This is more about your MTA/SMTP server than it is about OTRS. OTRS doesn't
really do anything more than use mailing APIs to adjust offset.

But yes, offset on "Date" is wrong, but 9:30 UTC= 12:30 UTC+3.

https://www.google.com/search?q=smtp+header+utc+offset+date

On Thu, May 7, 2015 at 4:40 AM, Roman Ovchinnikov <
r.ovchinni...@paymantix.com> wrote:

> Hello!
> Any ideas about this?
>
> Ovchinnikov Roman, Paymantix
> Cell +7 (926) 262-40-05 | Email: r.ovchinni...@paymantix.com| Skype:
> rovchinnikov.mm
>
> On 30.04.2015 13:13, Roman Ovchinnikov wrote:
> > Hello!
> > Recently we have installed otrs 4.0.7 and found that emails being sent
> > from system has wrong timezone settings in Date field, for example:
> >
> > Received: from mail.paymantix.com (LHLO mail.paymantix.com)
> (78.140.183.180)
> >  by mail.paymantix.com with LMTP; Thu, 30 Apr 2015 09:30:28 + (UTC)
> > Received: from mail.paymantix.com (localhost [127.0.0.1])
> >   by mail.paymantix.com (Postfix) with ESMTPS id 9962116113E
> >   for ; Thu, 30 Apr 2015 09:30:28
> + (UTC)
> > Received: from localhost (localhost [127.0.0.1])
> >   by mail.paymantix.com (Postfix) with ESMTP id 8C8AA161198
> >   for ; Thu, 30 Apr 2015 09:30:28
> + (UTC)
> > X-Virus-Scanned: amavisd-new at paymantix.com
> > Received: from mail.paymantix.com ([127.0.0.1])
> >   by localhost (mail.paymantix.com [127.0.0.1]) (amavisd-new, port
> 10026)
> >   with ESMTP id BT8gD6m4-Jxz for ;
> >   Thu, 30 Apr 2015 09:30:28 + (UTC)
> > Received: from otrs.paymantix.net (unknown [78.140.183.183])
> >   by mail.paymantix.com (Postfix) with ESMTPS id 778EA16113E
> >   for ; Thu, 30 Apr 2015 09:30:28
> + (UTC)
> > Received: from otrs.paymantix.net (localhost [127.0.0.1])
> >   by otrs.paymantix.net (Postfix) with ESMTP id 5FF5F93
> >   for ; Thu, 30 Apr 2015 09:30:03
> + (UTC)
> > MIME-Version: 1.0
> > Subject: [Ticket#0100341] RE: test
> > X-Powered-BY: OTRS - Open Ticket Request System (http://otrs.org/)
> > X-Mailer: OTRS Mail Service (4.0.7)
> > Date: Thu, 30 Apr 2015 12:30:03 +
> >
> >
> > as you can see, date in mail server messages are ok
> > 09:30:28 + (UTC)), while
> > Date: Thu, 30 Apr 2015 12:30:03 +
> >
> > so, offset is wrong. Server itself has UTC timezone, OTRS is configured
> as UTC +3 .
> >
> > Not sure what else should be tweaked, googling didn't give me any
> insights on this.
> >
>
> -
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Storing of large/binary data in Non-MySQL databases

[David Boyes]

> These are handled differently by OTRS - for
> databases other than MySQL, OTRS stores them in BASE64 encoding. The
> conversion can be done with Postgres using encode(column, 'base64').

I'd rather see MySQL use base64 too. All the world isn't Intel-based, and at 
least base64 is not ambiguous what the byte values really are. 

> My question is: Why do the other databases use character objects for all the
> LONGBLOBs including those that really contain binary data, so that for these
> databases, a BASE64 encoding is necessary, which costs performance when
> encoding and decoding and 33% more storage? Wouldn't it be much better
> and easier if OTRS used BLOBs consistently across all databases for the binary
> columns, and TEXT for the other large columns?

It would make it much more difficult to move data cross-platform. Try setting 
up a OTRS install on a Linux on POWER big-endian machine and moving the 
database from your Intel system. Those binary blobs are a royal pain. The 
base64 columns move perfectly and without any action on the admin's part.

> Also, would it be possible to use BYTEA in PostgreSQL instead of TEXT for the
> binary data columns, changing the database scheme accordingly and setting
> the DB::DirectBlob flag to 1 so that OTRS stops BASE64 encoding these
> columns?

Are you storing attachments in the database? If so, you might consider changing 
that. Most of the big blobs are related to that, and the non-existence of those 
big opaque blobs in the database makes this issue a lot less relevant (to the 
point of being almost not measurable). (in fact, I think that should be the 
default...)
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] wrong timezone in DATE email header, OTRS 4.0.7

[Roman Ovchinnikov]

Thank you Gerald!
I've just checked several hours ago this idea about SMTP MTA is doing
weird things, so I captured traffic (tcpdump on localhost, port 25) and
I see that MTA is not problem here, see below cut of the dump in text
viewable format by tcpflow, highlighted Date with red:

127.000.000.001.00025-127.000.000.001.36526: 220 otrs.paymantix.net ESMTP 
Postfix

127.000.000.001.36526-127.000.000.001.00025: EHLO otrs.paymantix.net

127.000.000.001.00025-127.000.000.001.36526: 250-otrs.paymantix.net

250-PIPELINING

250-SIZE 1024

250-VRFY

250-ETRN

250-STARTTLS

250-ENHANCEDSTATUSCODES

250-8BITMIME

250 DSN

127.000.000.001.36526-127.000.000.001.00025: MAIL FROM:<>

127.000.000.001.00025-127.000.000.001.36526: 250 2.1.0 Ok

127.000.000.001.36526-127.000.000.001.00025: RCPT 
TO:

127.000.000.001.00025-127.000.000.001.36526: 250 2.1.5 Ok

127.000.000.001.36526-127.000.000.001.00025: DATA

127.000.000.001.00025-127.000.000.001.36526: 354 End data with .

127.000.000.001.36526-127.000.000.001.00025: MIME-Version: 1.0

Subject: [Ticket#0101297] RE: test message, do not reply

X-Powered-BY: OTRS - Open Ticket Request System (http://otrs.org/)

X-Mailer: OTRS Mail Service (4.0.7)

*Date: Thu, 7 May 2015 14:15:03 +*

Precedence: bulk

X-Loop: yes

Auto-Submitted: auto-generated

Message-ID: <1431008103.834083.466920457.131...@otrs.paymantix.net>

To: Roman Ovchinnikov 

Organization: Paymantix

From: supp...@ecommpay.com 

In-Reply-To: <554b48ae.2090...@paymantix.com>

Content-Type: multipart/alternative; boundary="--=_1430997303-3991-2"


As you can see, message received by MTA is already with DATE header, so,
from my point of view the problem is on OTRS' side somehow. I can even
add the dump file itself if needed.

Ovchinnikov Roman, Paymantix
Cell +7 (926) 262-40-05 | Email: r.ovchinni...@paymantix.com| Skype: 
rovchinnikov.mm

On 07.05.2015 15:58, Gerald Young wrote:
> This is more about your MTA/SMTP server than it is about OTRS. OTRS
> doesn't really do anything more than use mailing APIs to adjust offset. 
>
> But yes, offset on "Date" is wrong, but 9:30 UTC= 12:30 UTC+3.
>
> https://www.google.com/search?q=smtp+header+utc+offset+date
>
> On Thu, May 7, 2015 at 4:40 AM, Roman Ovchinnikov
> mailto:r.ovchinni...@paymantix.com>> wrote:
>
> Hello!
> Any ideas about this?
>
> Ovchinnikov Roman, Paymantix
> Cell +7 (926) 262-40-05  |
> Email: r.ovchinni...@paymantix.com
> | Skype: rovchinnikov.mm
> 
>
> On 30.04.2015 13:13, Roman Ovchinnikov wrote:
> > Hello!
> > Recently we have installed otrs 4.0.7 and found that emails
> being sent
> > from system has wrong timezone settings in Date field, for example:
> >
> > Received: from mail.paymantix.com 
> (LHLO mail.paymantix.com ) (78.140.183.180)
> >  by mail.paymantix.com  with LMTP;
> Thu, 30 Apr 2015 09:30:28 + (UTC)
> > Received: from mail.paymantix.com 
> (localhost [127.0.0.1])
> >   by mail.paymantix.com 
> (Postfix) with ESMTPS id 9962116113E
> >   for  >; Thu, 30 Apr 2015 09:30:28
> + (UTC)
> > Received: from localhost (localhost [127.0.0.1])
> >   by mail.paymantix.com 
> (Postfix) with ESMTP id 8C8AA161198
> >   for  >; Thu, 30 Apr 2015 09:30:28
> + (UTC)
> > X-Virus-Scanned: amavisd-new at paymantix.com 
> > Received: from mail.paymantix.com 
> ([127.0.0.1])
> >   by localhost (mail.paymantix.com
>  [127.0.0.1]) (amavisd-new, port 10026)
> >   with ESMTP id BT8gD6m4-Jxz for
> mailto:r.ovchinni...@paymantix.com>>;
> >   Thu, 30 Apr 2015 09:30:28 + (UTC)
> > Received: from otrs.paymantix.net 
> (unknown [78.140.183.183])
> >   by mail.paymantix.com 
> (Postfix) with ESMTPS id 778EA16113E
> >   for  >; Thu, 30 Apr 2015 09:30:28
> + (UTC)
> > Received: from otrs.paymantix.net 
> (localhost [127.0.0.1])
> >   by otrs.paymantix.net 
> (Postfix) with ESMTP id 5FF5F93
> >   for  >; Thu, 30 Apr 2015 09:30:03
> + (UTC)
> > MIME-Version: 1.0
> > Subject: [Ticket#0100341] RE: test
> > X-Powered-BY: OTRS - Open Ticket Request System (http://otrs.org/)
> > X-Mailer: OTRS Mail Service (4.0.7)
> > Date: Thu, 30 Apr 2015 12:30:03 +
> >
> >
> > as you can see, date in mail server messages are ok
> > 09

Re: [otrs] Storing of large/binary data in Non-MySQL databases

[Christoph Zwerschke]

Am 07.05.2015 um 15:02 schrieb David Boyes:
>> These are handled differently by OTRS - for
>> databases other than MySQL, OTRS stores them in BASE64 encoding. The
>> conversion can be done with Postgres using encode(column, 'base64').
>

I'd rather see MySQL use base64 too. All the world isn't Intel-based,
and at least base64 is not ambiguous what the byte values really are.


LONGBLOBs are just streams of bytes. Intel or not (endianness) should 
not matter when you fetch and store the data using database methods. 
BLOBs are good for storing binary objects such as attachments or emails 
that you want to keep in their original encoding. Everything else should 
be stored as (unicode) text. Storing binary data BASE64 encoded is not 
optimal when the database supports BLOBs.



It would make it much more difficult to move data cross-platform.
Try setting up a OTRS install on a Linux on POWER big-endian machine
and moving the database from your Intel system. Those binary blobs
are a royal pain. The base64 columns move perfectly and without any
action on the admin's part.


I had no difficulties moving the data from the MySQL LONGBLOBs columns 
to PostgreSQL BYTEA columns. They were exported as byte streams and 
imported as byte streams. The difficulties only appeared because OTRS 
treats Postgres and the other databases differently from MySQL, as if 
they would not support binary data, for no apparent reason.



Are you storing attachments in the database? If so, you might
consider changing that.


Thanks for mentioning that, I'll consider it. Found the script 
ArticleStorageSwitch.pl which should make this possible. However, it may 
also have disadvantages. You need to backup database and filesystem 
separately, and consistency between the two is not automatically 
guaranteed through foreign keys. Also, there are some other BASE64 
encoded columns besides those for storing the attachments.


-- Christoph
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] wrong timezone in DATE email header, OTRS 4.0.7

[Gerald Young]

This is only for reference. Perhaps it might help.

Kernel/System/Email.pm sends mail.
https://github.com/OTRS/otrs/blob/rel-4_0/Kernel/System/Email.pm#L308

# add date header $Header{Date} = 'Date: ' . $Kernel::OM->Get('
Kernel::System::Time')->MailTimeStamp(); MailTimeStamp is defined here:
https://github.com/OTRS/otrs/blob/rel-4_0/Kernel/System/Time.pm#L363

offsite defined:
# calculate offset - should be '+0200', '-0600', '+' or '+0530' my $Diff
= Time::Local::timegm_nocheck( localtime( time() ) ) - time();
Time::Local
http://search.cpan.org/~drolsky/Time-Local-1.2300/lib/Time/Local.pm

perl localtime
http://perldoc.perl.org/functions/localtime.html

I have to step away for a bit, but maybe someone else can step in.

On Thu, May 7, 2015 at 10:44 AM, Roman Ovchinnikov <
r.ovchinni...@paymantix.com> wrote:

>  Thank you Gerald!
> I've just checked several hours ago this idea about SMTP MTA is doing
> weird things, so I captured traffic (tcpdump on localhost, port 25) and I
> see that MTA is not problem here, see below cut of the dump in text
> viewable format by tcpflow, highlighted Date with red:
>
> 127.000.000.001.00025-127.000.000.001.36526: 220 otrs.paymantix.net ESMTP 
> Postfix
>
> 127.000.000.001.36526-127.000.000.001.00025: EHLO otrs.paymantix.net
>
> 127.000.000.001.00025-127.000.000.001.36526: 250-otrs.paymantix.net
>
> 250-PIPELINING
>
> 250-SIZE 1024
>
> 250-VRFY
>
> 250-ETRN
>
> 250-STARTTLS
>
> 250-ENHANCEDSTATUSCODES
>
> 250-8BITMIME
>
> 250 DSN
>
> 127.000.000.001.36526-127.000.000.001.00025: MAIL FROM:<>
>
> 127.000.000.001.00025-127.000.000.001.36526: 250 2.1.0 Ok
>
> 127.000.000.001.36526-127.000.000.001.00025: RCPT 
> TO: 
>
> 127.000.000.001.00025-127.000.000.001.36526: 250 2.1.5 Ok
>
> 127.000.000.001.36526-127.000.000.001.00025: DATA
>
> 127.000.000.001.00025-127.000.000.001.36526: 354 End data with 
> .
>
> 127.000.000.001.36526-127.000.000.001.00025: MIME-Version: 1.0
>
> Subject: [Ticket#0101297] RE: test message, do not reply
>
> X-Powered-BY: OTRS - Open Ticket Request System (http://otrs.org/)
>
> X-Mailer: OTRS Mail Service (4.0.7)
>
> *Date: Thu, 7 May 2015 14:15:03 +*
>
> Precedence: bulk
>
> X-Loop: yes
>
> Auto-Submitted: auto-generated
>
> Message-ID: <1431008103.834083.466920457.131...@otrs.paymantix.net> 
> <1431008103.834083.466920457.131...@otrs.paymantix.net>
>
> To: Roman Ovchinnikov  
> 
>
> Organization: Paymantix
>
> From: supp...@ecommpay.com  
>
> In-Reply-To: <554b48ae.2090...@paymantix.com> <554b48ae.2090...@paymantix.com>
>
> Content-Type: multipart/alternative; boundary="--=_1430997303-3991-2"
>
>
> As you can see, message received by MTA is already with DATE header, so,
> from my point of view the problem is on OTRS' side somehow. I can even add
> the dump file itself if needed.
>
> Ovchinnikov Roman, Paymantix
> Cell +7 (926) 262-40-05 | Email: r.ovchinni...@paymantix.com| Skype: 
> rovchinnikov.mm
>
> On 07.05.2015 15:58, Gerald Young wrote:
>
> This is more about your MTA/SMTP server than it is about OTRS. OTRS
> doesn't really do anything more than use mailing APIs to adjust offset.
>
>  But yes, offset on "Date" is wrong, but 9:30 UTC= 12:30 UTC+3.
>
>  https://www.google.com/search?q=smtp+header+utc+offset+date
>
> On Thu, May 7, 2015 at 4:40 AM, Roman Ovchinnikov <
> r.ovchinni...@paymantix.com> wrote:
>
>> Hello!
>> Any ideas about this?
>>
>> Ovchinnikov Roman, Paymantix
>> Cell +7 (926) 262-40-05 | Email: r.ovchinni...@paymantix.com| Skype:
>> rovchinnikov.mm
>>
>>  On 30.04.2015 13:13, Roman Ovchinnikov wrote:
>> > Hello!
>> > Recently we have installed otrs 4.0.7 and found that emails being sent
>> > from system has wrong timezone settings in Date field, for example:
>> >
>> > Received: from mail.paymantix.com (LHLO mail.paymantix.com)
>> (78.140.183.180)
>> >  by mail.paymantix.com with LMTP; Thu, 30 Apr 2015 09:30:28 + (UTC)
>> > Received: from mail.paymantix.com (localhost [127.0.0.1])
>> >   by mail.paymantix.com (Postfix) with ESMTPS id 9962116113E
>> >   for ; Thu, 30 Apr 2015 09:30:28
>> + (UTC)
>> > Received: from localhost (localhost [127.0.0.1])
>> >   by mail.paymantix.com (Postfix) with ESMTP id 8C8AA161198
>> >   for ; Thu, 30 Apr 2015 09:30:28
>> + (UTC)
>> > X-Virus-Scanned: amavisd-new at paymantix.com
>> > Received: from mail.paymantix.com ([127.0.0.1])
>> >   by localhost (mail.paymantix.com [127.0.0.1]) (amavisd-new, port
>> 10026)
>> >   with ESMTP id BT8gD6m4-Jxz for ;
>> >   Thu, 30 Apr 2015 09:30:28 + (UTC)
>> > Received: from otrs.paymantix.net (unknown [78.140.183.183])
>> >   by mail.paymantix.com (Postfix) with ESMTPS id 778EA16113E
>> >   for ; Thu, 30 Apr 2015 09:30:28
>> + (UTC)
>> > Received: from otrs.paymantix.net (localhost [127.0.0.1])
>> >   by otrs.paymantix.net (Postfix) with ESMTP id 5FF5F93
>> >   for ; Thu, 30 Apr 2015 09:30:03
>> + (UTC)
>> > MIME-Version: 1.0
>> > Subject: [Ticket#0100341] RE: test
>> > X-Powered

Re: [otrs] Storing of large/binary data in Non-MySQL databases

[David Boyes]

> LONGBLOBs are just streams of bytes. Intel or not (endianness) should not
> matter when you fetch and store the data using database methods.
> BLOBs are good for storing binary objects such as attachments or emails that
> you want to keep in their original encoding. Everything else should be stored
> as (unicode) text. Storing binary data BASE64 encoded is not optimal when
> the database supports BLOBs.

No argument that it's not optimal, but at least it's the *same* representation 
regardless of database engine or platform. And base64 encoding guarantees that 
the same input string is interpreted identically on all platforms and all 
databases. I have a few sites that deal in full 32 bit ISO 10646 character 
sets, which add a whole another dimension to the annoyance of dealing with 
binary blobs. Use of base64 also allows databases on non-ASCII platforms to 
deliver and store the data in a portable form (for example, z/OS DB/2 makes a 
really nice OTRS back end if you have it, and DFSMShsm knows what to do with 
USS files, so automatic recall from tape works like a champ. I don't have to 
worry about attachment file sizes at all. 8-)). 

> The difficulties only appeared because OTRS
> treats Postgres and the other databases differently from MySQL, as if they
> would not support binary data, for no apparent reason.

I think we're arguing for the same point, but from different starting 
positions. I agree that there shouldn't be a difference between how MySQL and 
the other databases store the data. Given that the parsing is (and should be) 
done in the application logic, the overhead should be fairly minimal, and 
distributed. 
> 
> > Are you storing attachments in the database? If so, you might consider
> > changing that.
> 
> Thanks for mentioning that, I'll consider it. Found the script
> ArticleStorageSwitch.pl which should make this possible. However, it may
> also have disadvantages. You need to backup database and filesystem
> separately, and consistency between the two is not automatically
> guaranteed through foreign keys. Also, there are some other BASE64
> encoded columns besides those for storing the attachments.

Yes,  you're correct, but the vast majority of the performance impact you're 
commenting on is going to be dealing with the attachment blobs. The other 
columns are tiny in comparison. 

I also think you'll find that your backup load is much smaller with attachments 
outside the database -- every time you change the database, the whole file has 
to get dumped (unless you have a fairly smart backup system and are doing 
table-level backups from inside the database). Having the attachments outside 
the database will significantly reduce the amount of data backed up, in that 
change detection is much more effective with external files. Most databases are 
really not optimized for use as opaque object stores.

Keep in mind that the attachments are referenced only when opened. It's just 
opening an opaque object reference, so I don't see what consistency guarantees 
(other than the correct file gets opened when clicked on) you need. The object 
exists, or it doesn't. If it doesn't, you know what to do, and it's 
operationally a lot easier to manage whether a file exists or not. It also 
allows you to use much more intelligent object stores (such as Ceph or DFSMShsm 
on z/OS) with corresponding improvements in storage performance and compliance 
auditing capabilities.

-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Storing of large/binary data in Non-MySQL databases

[Christoph Zwerschke]

Am 07.05.2015 um 18:17 schrieb David Boyes:
> I also think you'll find that your backup load is much smaller with
> attachments outside the database -- every time you change the
> database, the whole file has to get dumped (unless you have a fairly
> smart backup system and are doing table-level backups from inside the
> database).

That's a good point, sure. You only must make sure that the backup 
intervals of the database and the filesystem are similar to get a 
consistent system from recovery.


> Keep in mind that the attachments are referenced only when opened.
> It's just opening an opaque object reference, so I don't see what
> consistency guarantees (other than the correct file gets opened when
> clicked on) you need. The object exists, or it doesn't.

I mainly want to make sure that no stale files (files which have no 
corresponding tickets in the database) accumulate over time. But you're 
right, as tickets and articles are usually not deleted in OTRS (or 
cannot even be deleted by users) that should be no problem.


-- Christoph
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs