Attachments table of RT's Mysql database

Hello everybody.

We’ve been using RT for more than three months as part of our
customer concern processes. Overall, things have been going well.
The configuration includes Mysql, Apache2 and Postfix running on Ubuntu
6.06. I’ve made no modifications to the databases.
The primary concern at this point is that the Attachments table of the
Mysql database is growing significantly. Our CSR’s want to attach
PDFs, jpegs, etc. to the tickets with the jpegs usually created by our
customers. The digital photos are the main culprit. I’ve read about
scaling back the photos, creating thumbnails, etc. and we need to find a
way to limit the attachment size prior to attachment.

Has anyone else using RT had this type of problem?

What are the best approaches for minimizing and controlling the size
of the Attachments table?

Any information, feedback and guidance are appreciated.

thanks - Gregory Harper , Stevens Industries

We actually had to disable the attachment feature as we were having our customers attach enormous files and killed our DB processing. Ultimately we are looking into rewriting the attachment feature to store the attachments on the web server to alleviate this overhead from the DB. I understand that the attachment table also stores all updates to a ticket, not just the attachments.

Justin Brodley -----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Gregory Harper
Sent: Wednesday, August 01, 2007 12:41 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Attachments table of RT’s Mysql database

Hello everybody.

We’ve been using RT for more than three months as part of our
customer concern processes. Overall, things have been going well.
The configuration includes Mysql, Apache2 and Postfix running on Ubuntu
6.06. I’ve made no modifications to the databases.
The primary concern at this point is that the Attachments table of the
Mysql database is growing significantly. Our CSR’s want to attach
PDFs, jpegs, etc. to the tickets with the jpegs usually created by our
customers. The digital photos are the main culprit. I’ve read about
scaling back the photos, creating thumbnails, etc. and we need to find a
way to limit the attachment size prior to attachment.

Has anyone else using RT had this type of problem?

What are the best approaches for minimizing and controlling the size
of the Attachments table?

Any information, feedback and guidance are appreciated.

thanks - Gregory Harper , Stevens Industries

http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Justin Brodley wrote:

We actually had to disable the attachment feature as we were having our customers attach enormous files and killed our DB processing. Ultimately we are looking into rewriting the attachment feature to store the attachments on the web server to alleviate this overhead from the DB. I understand that the attachment table also stores all updates to a ticket, not just the attachments.

Justin Brodley

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Gregory Harper
Sent: Wednesday, August 01, 2007 12:41 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Attachments table of RT’s Mysql database

Hello everybody.

We’ve been using RT for more than three months as part of our
customer concern processes. Overall, things have been going well.
The configuration includes Mysql, Apache2 and Postfix running on Ubuntu
6.06. I’ve made no modifications to the databases.
The primary concern at this point is that the Attachments table of the
Mysql database is growing significantly. Our CSR’s want to attach
PDFs, jpegs, etc. to the tickets with the jpegs usually created by our
customers. The digital photos are the main culprit. I’ve read about
scaling back the photos, creating thumbnails, etc. and we need to find a
way to limit the attachment size prior to attachment.

Has anyone else using RT had this type of problem?

What are the best approaches for minimizing and controlling the size
of the Attachments table?

Any information, feedback and guidance are appreciated.

thanks - Gregory Harper , Stevens Industries


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Thanks Justin for the feedback. Anyone else have input regarding their
experiences with Attachments and RT?

thanks - Greg

I wrote a patch that allows to store non-text attachments to be
stored out of DB - in my case it greatly reduced DB swelling.
Just for now it uses constant string in Attachments->Content to
indicate that file is written to FS.

You will need to specify some variables in RT_Siteconfig.pm:
Set($AttachmentsDirectory, ‘/var/RT/attachments’);
Set($LogAttachmentsLoading, “1”);
Set($LogAttachmentsSaving, “1”);
Set($StoreNonTextAttachmensInDB, undef);
#Set($StoreNonTextAttachmensInDB, “1”);

A new share/html/Ticket/Attachment/dhandler and attach.patch for
rest of RT distribution is in attachment.

Gregory Harper, you can find more complex set of patches allowing to
produce & show image thumbs automaticly in attachment too.
Some more variables must be specified in RT_Siteconfig.pm

Set($ShowTransactionImages, 1);
Set($ProduceImageThumbs, 1);
Set($ImageThumbsDirectory, ‘/var/RT/thumbs’);

I wonder why bestprcactical is not interested in intergating these
patches into RT:From: Jesse Vincent
Sent: 21 march 2007 г., 23:53
To: lytochkin
Subject: [RT 3.6] Storing attachments away from DB
Hi Boris,

Thanks very much for the mail, but I think we’re not really
interested in offering this feature within RT.
Best,
Jesse

Boris Lytochkin,
JSC e-port, Moscow
web: www.e-port.ru, wap: wap.e-port.ru
tel: +7 (495) 777 1872, ext. 251

Date: Mon, 06 Aug 2007 12:31:31 -0500
From: Gregory Harper gregh@stevensind.com
Subject: Re: [rt-users] Attachments table of RT’s Mysql database
To: Justin Brodley jbrodley@sumtotalsystems.com
Cc: rt-users@lists.bestpractical.com
Message-ID: 46B75AF3.3080200@stevensind.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Justin Brodley wrote:

We actually had to disable the attachment feature as we were having our customers attach enormous files and killed our DB processing. Ultimately we are looking
into rewriting the attachment feature to store the attachments on the web server to alleviate this overhead from the DB. I understand that the attachment table also
stores all updates to a ticket, not just the attachments.

Justin Brodley

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Gregory Harper
Sent: Wednesday, August 01, 2007 12:41 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Attachments table of RT’s Mysql database

Hello everybody.

We’ve been using RT for more than three months as part of our
customer concern processes. Overall, things have been going well.
The configuration includes Mysql, Apache2 and Postfix running on Ubuntu
6.06. I’ve made no modifications to the databases.
The primary concern at this point is that the Attachments table of the
Mysql database is growing significantly. Our CSR’s want to attach
PDFs, jpegs, etc. to the tickets with the jpegs usually created by our
customers. The digital photos are the main culprit. I’ve read about
scaling back the photos, creating thumbnails, etc. and we need to find a
way to limit the attachment size prior to attachment.

Has anyone else using RT had this type of problem?

What are the best approaches for minimizing and controlling the size
of the Attachments table?

Any information, feedback and guidance are appreciated.

thanks - Gregory Harper , Stevens Industries


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Thanks Justin for the feedback. Anyone else have input regarding their
experiences with Attachments and RT?

thanks - Greg

Message: 3
Date: Mon, 6 Aug 2007 11:53:13 -0700 (PDT)
From: Ed Matthews g8orade@yahoo.com
Subject: [rt-users] Kwiki Table Rendering?
To: rt-users@lists.bestpractical.com
Message-ID: 569062.32875.qm@web51102.mail.re2.yahoo.com
Content-Type: text/plain; charset=us-ascii

Happy Monday.

Does anyone know why Kwiki renders tables on this page,
http://wiki.bestpractical.com/view/ManualScrips

but not on this page
http://wiki.bestpractical.com/view/ManualRights
nor in my personal page .

I tried copy pasting the first ManualScrips table wiki markup into another edit page and saving, and it wouldn’t render there either after save.

Ed Matthews
g8orade@yahoo.com

Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC

Message: 4
Date: Tue, 7 Aug 2007 10:20:33 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: [rt-users] Trying to change the logo. Fedora Core 7, RT3.6.3
yum install
To: rt-users@lists.bestpractical.com
Message-ID:
OF74585201.1DEBE7DD-ON80257330.003044E6-80257330.0033159C@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

I’m sure I’m just missing something simple, but I cannot seem to change the
BP logo on my install of RT 3.6.3 on Fedora Core 7.
I’ve installed RT using yum (lazy I know, but it works apart from this
issue).

It has been installed into
/usr/share/rt3
I’ve created /usr/local/rt3/html/Elements/
and copied the Logo file into that directory.

I’ve added the logo I want to use into /usr/share/rt3/html/NoAuth/images
It is a 92x50pixels jpeg.

Following suggestions from the wiki and the mailing list archives, I put
this line into the Logo file :
Intranet

I have modified by RT_SiteConfig.pm file.
If I log into the web interface, under tools, choose system configuration,
the following variables are set :
RT::LogoLinkURL http://192.168.66.1
RT::LogoURL /rt3/NoAuth/images/mtllogo.jpg
RT::LogoWidth 92
RT::LogoHeight 50
RT::MasonDataDir /var/cache/rt3/mason_data

I’ve tried stopping the webserver, deleting Logo.obj from
/var/cache/rt3/mason_data/obj/3989424063/standard
When I restart apache, and refresh the RT page, Logo.obj is recreated with
the best practical logo in it.

Where am I going wrong ? Can anyone point me in the right direction please
?

Thanks in advance

Luke

This email message may contain privileged/confidential information and/or
copyright material. It is intended only for the use of the person(s) to whom
it is addressed and any unauthorised use may be unlawful. If you receive this
email by mistake, please advise the sender immediately by using the reply
facility in your email software and delete the material from your computer.

The material contained in this message does not constitute a binding
contract with any company within the MTL Instruments Group plc. Opinions,
conclusions and other information in this email that do not relate to the official
business of this organisation shall be understood as neither given nor endorsed
by it. Registered in England No. 1871978, VAT Reg. No 449343040,
MTL Instruments Ltd, Power Court, Luton, LU1 3JJ

-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/37bbd464/attachment-0001.htm

Message: 5
Date: Tue, 7 Aug 2007 12:39:04 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: Re: {Disarmed} [rt-users] Trying to change the logo. Fedora
Core 7, RT3.6.3 yum install
To: Boris Jordanov jordanov@brg.bg
Cc: rt-users@lists.bestpractical.com
Message-ID:
OF7F7C160E.3A42C7E0-ON80257330.003EF00C-80257330.003FC412@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed…
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/graycol.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: pic05705.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/pic05705.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/ecblank.gif

RT-Users mailing list
RT-Users@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

End of RT-Users Digest, Vol 41, Issue 20

attach.patch (5.24 KB)

dhandler (4.33 KB)

attach_and_thumbs.patch2.diff (5.5 KB)

attach_and_thumbs.patch1.diff (6.61 KB)

Dear Mr. Lytochkin,

There are two very good reasons to not store attachments outside
of the database. First, if everything is inside a database, then a
simple backup of the database will get everything related to a
particular RT instance. Second, in many cases you would like to
isolate the front-end from the back-end information store. Once
you need access to the filesystem, everything becomes much more
involved. I am certain that there are other reasons, but those
two are certainly enough for me. I have appreciated the ease of
generating a consistent backup of my RT information store.

KenOn Tue, Aug 07, 2007 at 04:15:02PM +0400, Boris Lytochkin wrote:

I wrote a patch that allows to store non-text attachments to be
stored out of DB - in my case it greatly reduced DB swelling.
Just for now it uses constant string in Attachments->Content to
indicate that file is written to FS.

You will need to specify some variables in RT_Siteconfig.pm:
Set($AttachmentsDirectory, ‘/var/RT/attachments’);
Set($LogAttachmentsLoading, “1”);
Set($LogAttachmentsSaving, “1”);
Set($StoreNonTextAttachmensInDB, undef);
#Set($StoreNonTextAttachmensInDB, “1”);

A new share/html/Ticket/Attachment/dhandler and attach.patch for
rest of RT distribution is in attachment.

Gregory Harper, you can find more complex set of patches allowing to
produce & show image thumbs automaticly in attachment too.
Some more variables must be specified in RT_Siteconfig.pm

Set($ShowTransactionImages, 1);
Set($ProduceImageThumbs, 1);
Set($ImageThumbsDirectory, ‘/var/RT/thumbs’);

I wonder why bestprcactical is not interested in intergating these
patches into RT:
From: Jesse Vincent
Sent: 21 march 2007 ?., 23:53
To: lytochkin
Subject: [RT 3.6] Storing attachments away from DB
Hi Boris,

Thanks very much for the mail, but I think we’re not really
interested in offering this feature within RT.
Best,
Jesse


Boris Lytochkin,
JSC e-port, Moscow
web: www.e-port.ru, wap: wap.e-port.ru
tel: +7 (495) 777 1872, ext. 251


Date: Mon, 06 Aug 2007 12:31:31 -0500
From: Gregory Harper gregh@stevensind.com
Subject: Re: [rt-users] Attachments table of RT’s Mysql database
To: Justin Brodley jbrodley@sumtotalsystems.com
Cc: rt-users@lists.bestpractical.com
Message-ID: 46B75AF3.3080200@stevensind.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Justin Brodley wrote:

We actually had to disable the attachment feature as we were having our customers attach enormous files and killed our DB processing. Ultimately we are looking
into rewriting the attachment feature to store the attachments on the web server to alleviate this overhead from the DB. I understand that the attachment table also
stores all updates to a ticket, not just the attachments.

Justin Brodley

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Gregory Harper
Sent: Wednesday, August 01, 2007 12:41 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Attachments table of RT’s Mysql database

Hello everybody.

We’ve been using RT for more than three months as part of our
customer concern processes. Overall, things have been going well.
The configuration includes Mysql, Apache2 and Postfix running on Ubuntu
6.06. I’ve made no modifications to the databases.
The primary concern at this point is that the Attachments table of the
Mysql database is growing significantly. Our CSR’s want to attach
PDFs, jpegs, etc. to the tickets with the jpegs usually created by our
customers. The digital photos are the main culprit. I’ve read about
scaling back the photos, creating thumbnails, etc. and we need to find a
way to limit the attachment size prior to attachment.

Has anyone else using RT had this type of problem?

What are the best approaches for minimizing and controlling the size
of the Attachments table?

Any information, feedback and guidance are appreciated.

thanks - Gregory Harper , Stevens Industries


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Thanks Justin for the feedback. Anyone else have input regarding their
experiences with Attachments and RT?

thanks - Greg


Message: 3
Date: Mon, 6 Aug 2007 11:53:13 -0700 (PDT)
From: Ed Matthews g8orade@yahoo.com
Subject: [rt-users] Kwiki Table Rendering?
To: rt-users@lists.bestpractical.com
Message-ID: 569062.32875.qm@web51102.mail.re2.yahoo.com
Content-Type: text/plain; charset=us-ascii

Happy Monday.

Does anyone know why Kwiki renders tables on this page,
ManualScrips - Request Tracker Wiki

but not on this page
ManualRights - Request Tracker Wiki
nor in my personal page .

I tried copy pasting the first ManualScrips table wiki markup into another edit page and saving, and it wouldn’t render there either after save.

Ed Matthews
g8orade@yahoo.com


Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC


Message: 4
Date: Tue, 7 Aug 2007 10:20:33 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: [rt-users] Trying to change the logo. Fedora Core 7, RT3.6.3
yum install
To: rt-users@lists.bestpractical.com
Message-ID:
OF74585201.1DEBE7DD-ON80257330.003044E6-80257330.0033159C@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

I’m sure I’m just missing something simple, but I cannot seem to change the
BP logo on my install of RT 3.6.3 on Fedora Core 7.
I’ve installed RT using yum (lazy I know, but it works apart from this
issue).

It has been installed into
/usr/share/rt3
I’ve created /usr/local/rt3/html/Elements/
and copied the Logo file into that directory.

I’ve added the logo I want to use into /usr/share/rt3/html/NoAuth/images
It is a 92x50pixels jpeg.

Following suggestions from the wiki and the mailing list archives, I put
this line into the Logo file :
Intranet

I have modified by RT_SiteConfig.pm file.
If I log into the web interface, under tools, choose system configuration,
the following variables are set :
RT::LogoLinkURL http://192.168.66.1
RT::LogoURL /rt3/NoAuth/images/mtllogo.jpg
RT::LogoWidth 92
RT::LogoHeight 50
RT::MasonDataDir /var/cache/rt3/mason_data

I’ve tried stopping the webserver, deleting Logo.obj from
/var/cache/rt3/mason_data/obj/3989424063/standard
When I restart apache, and refresh the RT page, Logo.obj is recreated with
the best practical logo in it.

Where am I going wrong ? Can anyone point me in the right direction please
?

Thanks in advance

Luke


This email message may contain privileged/confidential information and/or
copyright material. It is intended only for the use of the person(s) to whom
it is addressed and any unauthorised use may be unlawful. If you receive this
email by mistake, please advise the sender immediately by using the reply
facility in your email software and delete the material from your computer.

The material contained in this message does not constitute a binding
contract with any company within the MTL Instruments Group plc. Opinions,
conclusions and other information in this email that do not relate to the official
business of this organisation shall be understood as neither given nor endorsed
by it. Registered in England No. 1871978, VAT Reg. No 449343040,
MTL Instruments Ltd, Power Court, Luton, LU1 3JJ

-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/37bbd464/attachment-0001.htm


Message: 5
Date: Tue, 7 Aug 2007 12:39:04 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: Re: {Disarmed} [rt-users] Trying to change the logo. Fedora
Core 7, RT3.6.3 yum install
To: Boris Jordanov jordanov@brg.bg
Cc: rt-users@lists.bestpractical.com
Message-ID:
OF7F7C160E.3A42C7E0-ON80257330.003EF00C-80257330.003FC412@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed…
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/graycol.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: pic05705.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/pic05705.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/ecblank.gif



RT-Users mailing list
RT-Users@lists.bestpractical.com
The rt-users Archives

End of RT-Users Digest, Vol 41, Issue 20



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Ken,

First, if everything is inside a database, then a
simple backup of the database will get everything related to a
particular RT instance.
Wrong. We stopped backup process of RT database due to LARGE amount
data every day. We have no such amount of tape to store DB’s everyday
backups.
Now, DB backup is done every day and attachment backup is done
separately. As a result we have everyday SQL-backup of DB and
incremental backup for attachments. It uses much less space.

Second, in many cases you would like to
isolate the front-end from the back-end information store. Once
you need access to the filesystem, everything becomes much more
involved.

I understand that storing attachments out of RT involves much more
than DB-only solution, BUT 10 Gb DB with 9.5 Gb of images involves much more.

Anyway, it is up to admin to decide whether to store attachments
separate or not.

Tuesday, August 7, 2007, 4:22:49 PM, you wrote:

Dear Mr. Lytochkin,

There are two very good reasons to not store attachments outside
of the database. First, if everything is inside a database, then a
simple backup of the database will get everything related to a
particular RT instance. Second, in many cases you would like to
isolate the front-end from the back-end information store. Once
you need access to the filesystem, everything becomes much more
involved. I am certain that there are other reasons, but those
two are certainly enough for me. I have appreciated the ease of
generating a consistent backup of my RT information store.

Ken

I wrote a patch that allows to store non-text attachments to be
stored out of DB - in my case it greatly reduced DB swelling.
Just for now it uses constant string in Attachments->Content to
indicate that file is written to FS.

You will need to specify some variables in RT_Siteconfig.pm:
Set($AttachmentsDirectory, ‘/var/RT/attachments’);
Set($LogAttachmentsLoading, “1”);
Set($LogAttachmentsSaving, “1”);
Set($StoreNonTextAttachmensInDB, undef);
#Set($StoreNonTextAttachmensInDB, “1”);

A new share/html/Ticket/Attachment/dhandler and attach.patch for
rest of RT distribution is in attachment.

Gregory Harper, you can find more complex set of patches allowing to
produce & show image thumbs automaticly in attachment too.
Some more variables must be specified in RT_Siteconfig.pm

Set($ShowTransactionImages, 1);
Set($ProduceImageThumbs, 1);
Set($ImageThumbsDirectory, ‘/var/RT/thumbs’);

I wonder why bestprcactical is not interested in intergating these
patches into RT:
From: Jesse Vincent
Sent: 21 march 2007 ?., 23:53
To: lytochkin
Subject: [RT 3.6] Storing attachments away from DB
Hi Boris,

Thanks very much for the mail, but I think we’re not really
interested in offering this feature within RT.
Best,
Jesse


Boris Lytochkin,
JSC e-port, Moscow
web: www.e-port.ru, wap: wap.e-port.ru
tel: +7 (495) 777 1872, ext. 251


Date: Mon, 06 Aug 2007 12:31:31 -0500
From: Gregory Harper gregh@stevensind.com
Subject: Re: [rt-users] Attachments table of RT’s Mysql database
To: Justin Brodley jbrodley@sumtotalsystems.com
Cc: rt-users@lists.bestpractical.com
Message-ID: 46B75AF3.3080200@stevensind.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Justin Brodley wrote:

We actually had to disable the attachment feature as we were having our customers attach enormous files and killed our DB processing. Ultimately we
are looking
into rewriting the attachment feature to store the attachments on the web server to alleviate this overhead from the DB. I understand that the
attachment table also
stores all updates to a ticket, not just the attachments.

Justin Brodley

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Gregory Harper
Sent: Wednesday, August 01, 2007 12:41 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Attachments table of RT’s Mysql database

Hello everybody.

We’ve been using RT for more than three months as part of our
customer concern processes. Overall, things have been going well.
The configuration includes Mysql, Apache2 and Postfix running on Ubuntu
6.06. I’ve made no modifications to the databases.
The primary concern at this point is that the Attachments table of the
Mysql database is growing significantly. Our CSR’s want to attach
PDFs, jpegs, etc. to the tickets with the jpegs usually created by our
customers. The digital photos are the main culprit. I’ve read about
scaling back the photos, creating thumbnails, etc. and we need to find a
way to limit the attachment size prior to attachment.

Has anyone else using RT had this type of problem?

What are the best approaches for minimizing and controlling the size
of the Attachments table?

Any information, feedback and guidance are appreciated.

thanks - Gregory Harper , Stevens Industries


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Thanks Justin for the feedback. Anyone else have input regarding their
experiences with Attachments and RT?

thanks - Greg


Message: 3
Date: Mon, 6 Aug 2007 11:53:13 -0700 (PDT)
From: Ed Matthews g8orade@yahoo.com
Subject: [rt-users] Kwiki Table Rendering?
To: rt-users@lists.bestpractical.com
Message-ID: 569062.32875.qm@web51102.mail.re2.yahoo.com
Content-Type: text/plain; charset=us-ascii

Happy Monday.

Does anyone know why Kwiki renders tables on this page,
ManualScrips - Request Tracker Wiki

but not on this page
ManualRights - Request Tracker Wiki
nor in my personal page .

I tried copy pasting the first ManualScrips table wiki markup into another edit page and saving, and it wouldn’t render there either after save.

Ed Matthews
g8orade@yahoo.com


Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC


Message: 4
Date: Tue, 7 Aug 2007 10:20:33 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: [rt-users] Trying to change the logo. Fedora Core 7, RT3.6.3
yum install
To: rt-users@lists.bestpractical.com
Message-ID:
OF74585201.1DEBE7DD-ON80257330.003044E6-80257330.0033159C@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

I’m sure I’m just missing something simple, but I cannot seem to change the
BP logo on my install of RT 3.6.3 on Fedora Core 7.
I’ve installed RT using yum (lazy I know, but it works apart from this
issue).

It has been installed into
/usr/share/rt3
I’ve created /usr/local/rt3/html/Elements/
and copied the Logo file into that directory.

I’ve added the logo I want to use into /usr/share/rt3/html/NoAuth/images
It is a 92x50pixels jpeg.

Following suggestions from the wiki and the mailing list archives, I put
this line into the Logo file :
Intranet

I have modified by RT_SiteConfig.pm file.
If I log into the web interface, under tools, choose system configuration,
the following variables are set :
RT::LogoLinkURL http://192.168.66.1
RT::LogoURL /rt3/NoAuth/images/mtllogo.jpg
RT::LogoWidth 92
RT::LogoHeight 50
RT::MasonDataDir /var/cache/rt3/mason_data

I’ve tried stopping the webserver, deleting Logo.obj from
/var/cache/rt3/mason_data/obj/3989424063/standard
When I restart apache, and refresh the RT page, Logo.obj is recreated with
the best practical logo in it.

Where am I going wrong ? Can anyone point me in the right direction please
?

Thanks in advance

Luke


This email message may contain privileged/confidential information and/or
copyright material. It is intended only for the use of the person(s) to whom
it is addressed and any unauthorised use may be unlawful. If you receive this
email by mistake, please advise the sender immediately by using the reply
facility in your email software and delete the material from your computer.

The material contained in this message does not constitute a binding
contract with any company within the MTL Instruments Group plc. Opinions,
conclusions and other information in this email that do not relate to the official
business of this organisation shall be understood as neither given nor endorsed
by it. Registered in England No. 1871978, VAT Reg. No 449343040,
MTL Instruments Ltd, Power Court, Luton, LU1 3JJ

-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/37bbd464/attachment-0001.htm


Message: 5
Date: Tue, 7 Aug 2007 12:39:04 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: Re: {Disarmed} [rt-users] Trying to change the logo. Fedora
Core 7, RT3.6.3 yum install
To: Boris Jordanov jordanov@brg.bg
Cc: rt-users@lists.bestpractical.com
Message-ID:
OF7F7C160E.3A42C7E0-ON80257330.003EF00C-80257330.003FC412@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed…
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/graycol.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: pic05705.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/pic05705.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/ecblank.gif



RT-Users mailing list
RT-Users@lists.bestpractical.com
The rt-users Archives

End of RT-Users Digest, Vol 41, Issue 20



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards,
Boris Lytochkin mailto:lytochkin@e-port.ru

I personally agree with Boris on this. This should be a configuration option to either store attachments in the database or on the web front end.

In most enterprise applications you don’t store files or session state in the database unless you have a really good reason too. The overhead added by sessions and files results in increased reads from the web server to verify session or large database sizes to store the files in blobs.

Justin Brodley From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Boris Lytochkin
Sent: Tuesday, August 07, 2007 6:31 AM
To: rt-users@lists.bestpractical.com
Subject: Re[2]: [rt-users] Attachments table of RT’s Mysql database

Ken,

First, if everything is inside a database, then a
simple backup of the database will get everything related to a
particular RT instance.
Wrong. We stopped backup process of RT database due to LARGE amount
data every day. We have no such amount of tape to store DB’s everyday
backups.
Now, DB backup is done every day and attachment backup is done
separately. As a result we have everyday SQL-backup of DB and
incremental backup for attachments. It uses much less space.

Second, in many cases you would like to
isolate the front-end from the back-end information store. Once
you need access to the filesystem, everything becomes much more
involved.

I understand that storing attachments out of RT involves much more
than DB-only solution, BUT 10 Gb DB with 9.5 Gb of images involves much more.

Anyway, it is up to admin to decide whether to store attachments
separate or not.

Tuesday, August 7, 2007, 4:22:49 PM, you wrote:

Dear Mr. Lytochkin,

There are two very good reasons to not store attachments outside
of the database. First, if everything is inside a database, then a
simple backup of the database will get everything related to a
particular RT instance. Second, in many cases you would like to
isolate the front-end from the back-end information store. Once
you need access to the filesystem, everything becomes much more
involved. I am certain that there are other reasons, but those
two are certainly enough for me. I have appreciated the ease of
generating a consistent backup of my RT information store.

Ken

I wrote a patch that allows to store non-text attachments to be
stored out of DB - in my case it greatly reduced DB swelling.
Just for now it uses constant string in Attachments->Content to
indicate that file is written to FS.

You will need to specify some variables in RT_Siteconfig.pm:
Set($AttachmentsDirectory, ‘/var/RT/attachments’);
Set($LogAttachmentsLoading, “1”);
Set($LogAttachmentsSaving, “1”);
Set($StoreNonTextAttachmensInDB, undef);
#Set($StoreNonTextAttachmensInDB, “1”);

A new share/html/Ticket/Attachment/dhandler and attach.patch for
rest of RT distribution is in attachment.

Gregory Harper, you can find more complex set of patches allowing to
produce & show image thumbs automaticly in attachment too.
Some more variables must be specified in RT_Siteconfig.pm

Set($ShowTransactionImages, 1);
Set($ProduceImageThumbs, 1);
Set($ImageThumbsDirectory, ‘/var/RT/thumbs’);

I wonder why bestprcactical is not interested in intergating these
patches into RT:
From: Jesse Vincent
Sent: 21 march 2007 ?., 23:53
To: lytochkin
Subject: [RT 3.6] Storing attachments away from DB
Hi Boris,

Thanks very much for the mail, but I think we’re not really
interested in offering this feature within RT.
Best,
Jesse


Boris Lytochkin,
JSC e-port, Moscow
web: www.e-port.ru, wap: wap.e-port.ru
tel: +7 (495) 777 1872, ext. 251


Date: Mon, 06 Aug 2007 12:31:31 -0500
From: Gregory Harper gregh@stevensind.com
Subject: Re: [rt-users] Attachments table of RT’s Mysql database
To: Justin Brodley jbrodley@sumtotalsystems.com
Cc: rt-users@lists.bestpractical.com
Message-ID: 46B75AF3.3080200@stevensind.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Justin Brodley wrote:

We actually had to disable the attachment feature as we were having our customers attach enormous files and killed our DB processing. Ultimately we
are looking
into rewriting the attachment feature to store the attachments on the web server to alleviate this overhead from the DB. I understand that the
attachment table also
stores all updates to a ticket, not just the attachments.

Justin Brodley

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Gregory Harper
Sent: Wednesday, August 01, 2007 12:41 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Attachments table of RT’s Mysql database

Hello everybody.

We’ve been using RT for more than three months as part of our
customer concern processes. Overall, things have been going well.
The configuration includes Mysql, Apache2 and Postfix running on Ubuntu
6.06. I’ve made no modifications to the databases.
The primary concern at this point is that the Attachments table of the
Mysql database is growing significantly. Our CSR’s want to attach
PDFs, jpegs, etc. to the tickets with the jpegs usually created by our
customers. The digital photos are the main culprit. I’ve read about
scaling back the photos, creating thumbnails, etc. and we need to find a
way to limit the attachment size prior to attachment.

Has anyone else using RT had this type of problem?

What are the best approaches for minimizing and controlling the size
of the Attachments table?

Any information, feedback and guidance are appreciated.

thanks - Gregory Harper , Stevens Industries


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Thanks Justin for the feedback. Anyone else have input regarding their
experiences with Attachments and RT?

thanks - Greg


Message: 3
Date: Mon, 6 Aug 2007 11:53:13 -0700 (PDT)
From: Ed Matthews g8orade@yahoo.com
Subject: [rt-users] Kwiki Table Rendering?
To: rt-users@lists.bestpractical.com
Message-ID: 569062.32875.qm@web51102.mail.re2.yahoo.com
Content-Type: text/plain; charset=us-ascii

Happy Monday.

Does anyone know why Kwiki renders tables on this page,
ManualScrips - Request Tracker Wiki

but not on this page
http://wiki.bestpractical.com/view/ManualRights
nor in my personal page .

I tried copy pasting the first ManualScrips table wiki markup into another edit page and saving, and it wouldn’t render there either after save.

Ed Matthews
g8orade@yahoo.com


Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC


Message: 4
Date: Tue, 7 Aug 2007 10:20:33 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: [rt-users] Trying to change the logo. Fedora Core 7, RT3.6.3
yum install
To: rt-users@lists.bestpractical.com
Message-ID:
OF74585201.1DEBE7DD-ON80257330.003044E6-80257330.0033159C@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

I’m sure I’m just missing something simple, but I cannot seem to change the
BP logo on my install of RT 3.6.3 on Fedora Core 7.
I’ve installed RT using yum (lazy I know, but it works apart from this
issue).

It has been installed into
/usr/share/rt3
I’ve created /usr/local/rt3/html/Elements/
and copied the Logo file into that directory.

I’ve added the logo I want to use into /usr/share/rt3/html/NoAuth/images
It is a 92x50pixels jpeg.

Following suggestions from the wiki and the mailing list archives, I put
this line into the Logo file :
Intranet

I have modified by RT_SiteConfig.pm file.
If I log into the web interface, under tools, choose system configuration,
the following variables are set :
RT::LogoLinkURL http://192.168.66.1
RT::LogoURL /rt3/NoAuth/images/mtllogo.jpg
RT::LogoWidth 92
RT::LogoHeight 50
RT::MasonDataDir /var/cache/rt3/mason_data

I’ve tried stopping the webserver, deleting Logo.obj from
/var/cache/rt3/mason_data/obj/3989424063/standard
When I restart apache, and refresh the RT page, Logo.obj is recreated with
the best practical logo in it.

Where am I going wrong ? Can anyone point me in the right direction please
?

Thanks in advance

Luke


This email message may contain privileged/confidential information and/or
copyright material. It is intended only for the use of the person(s) to whom
it is addressed and any unauthorised use may be unlawful. If you receive this
email by mistake, please advise the sender immediately by using the reply
facility in your email software and delete the material from your computer.

The material contained in this message does not constitute a binding
contract with any company within the MTL Instruments Group plc. Opinions,
conclusions and other information in this email that do not relate to the official
business of this organisation shall be understood as neither given nor endorsed
by it. Registered in England No. 1871978, VAT Reg. No 449343040,
MTL Instruments Ltd, Power Court, Luton, LU1 3JJ

-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/37bbd464/attachment-0001.htm


Message: 5
Date: Tue, 7 Aug 2007 12:39:04 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: Re: {Disarmed} [rt-users] Trying to change the logo. Fedora
Core 7, RT3.6.3 yum install
To: Boris Jordanov jordanov@brg.bg
Cc: rt-users@lists.bestpractical.com
Message-ID:
OF7F7C160E.3A42C7E0-ON80257330.003EF00C-80257330.003FC412@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed…
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/graycol.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: pic05705.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/pic05705.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/ecblank.gif



RT-Users mailing list
RT-Users@lists.bestpractical.com
The rt-users Archives

End of RT-Users Digest, Vol 41, Issue 20



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards,
Boris Lytochkin mailto:lytochkin@e-port.ru

http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

I personally agree with Boris on this. This should be a configuration option to either store attachments in the database or on the web front end.
So do I.
Moreover, it might be very convenient to store only unique attachments and to have a counter of ‘uniqueness’ for each one. After all, RT is a tracker. Some users may tend to send the same files repeatedly (for instance, request handlers might send the same patch to a limited number of RT users).
A configuration option to store attachments in server’s local FS instead of any DBMS would be nice for some configurations.

We currently have RT configuration with ~50Gb pgsql database!

In most enterprise applications you don’t store files or session state in the database unless you have a really good reason too. The overhead added by sessions and files results in increased reads from the web server to verify session or large database sizes to store the files in blobs.

Good point, but for DB transactions facility…

I guess it all comes down to “different strokes for different folks”.
Perhaps this could be put up on the wiki and then if someone needs this
capability they can easily get it?

DB

Boris Lytochkin wrote:

Ken,

First, if everything is inside a database, then a
simple backup of the database will get everything related to a
particular RT instance.

Wrong. We stopped backup process of RT database due to LARGE amount
data every day. We have no such amount of tape to store DB’s everyday
backups.
Now, DB backup is done every day and attachment backup is done
separately. As a result we have everyday SQL-backup of DB and
incremental backup for attachments. It uses much less space.

Second, in many cases you would like to
isolate the front-end from the back-end information store. Once
you need access to the filesystem, everything becomes much more
involved.

I understand that storing attachments out of RT involves much more
than DB-only solution, BUT 10 Gb DB with 9.5 Gb of images involves much more.

Anyway, it is up to admin to decide whether to store attachments
separate or not.

Tuesday, August 7, 2007, 4:22:49 PM, you wrote:

Dear Mr. Lytochkin,

There are two very good reasons to not store attachments outside
of the database. First, if everything is inside a database, then a
simple backup of the database will get everything related to a
particular RT instance. Second, in many cases you would like to
isolate the front-end from the back-end information store. Once
you need access to the filesystem, everything becomes much more
involved. I am certain that there are other reasons, but those
two are certainly enough for me. I have appreciated the ease of
generating a consistent backup of my RT information store.

Ken

I wrote a patch that allows to store non-text attachments to be
stored out of DB - in my case it greatly reduced DB swelling.
Just for now it uses constant string in Attachments->Content to
indicate that file is written to FS.

You will need to specify some variables in RT_Siteconfig.pm:
Set($AttachmentsDirectory, ‘/var/RT/attachments’);
Set($LogAttachmentsLoading, “1”);
Set($LogAttachmentsSaving, “1”);
Set($StoreNonTextAttachmensInDB, undef);
#Set($StoreNonTextAttachmensInDB, “1”);

A new share/html/Ticket/Attachment/dhandler and attach.patch for
rest of RT distribution is in attachment.

Gregory Harper, you can find more complex set of patches allowing to
produce & show image thumbs automaticly in attachment too.
Some more variables must be specified in RT_Siteconfig.pm

Set($ShowTransactionImages, 1);
Set($ProduceImageThumbs, 1);
Set($ImageThumbsDirectory, ‘/var/RT/thumbs’);

I wonder why bestprcactical is not interested in intergating these
patches into RT:
From: Jesse Vincent
Sent: 21 march 2007 ?., 23:53
To: lytochkin
Subject: [RT 3.6] Storing attachments away from DB
Hi Boris,

Thanks very much for the mail, but I think we’re not really
interested in offering this feature within RT.
Best,
Jesse


Boris Lytochkin,
JSC e-port, Moscow
web: www.e-port.ru, wap: wap.e-port.ru
tel: +7 (495) 777 1872, ext. 251


Date: Mon, 06 Aug 2007 12:31:31 -0500
From: Gregory Harper gregh@stevensind.com
Subject: Re: [rt-users] Attachments table of RT’s Mysql database
To: Justin Brodley jbrodley@sumtotalsystems.com
Cc: rt-users@lists.bestpractical.com
Message-ID: 46B75AF3.3080200@stevensind.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Justin Brodley wrote:

We actually had to disable the attachment feature as we were having our customers attach enormous files and killed our DB processing. Ultimately we

are looking

into rewriting the attachment feature to store the attachments on the web server to alleviate this overhead from the DB. I understand that the

attachment table also

stores all updates to a ticket, not just the attachments.

Justin Brodley

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Gregory Harper
Sent: Wednesday, August 01, 2007 12:41 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Attachments table of RT’s Mysql database

Hello everybody.

We’ve been using RT for more than three months as part of our
customer concern processes. Overall, things have been going well.
The configuration includes Mysql, Apache2 and Postfix running on Ubuntu
6.06. I’ve made no modifications to the databases.
The primary concern at this point is that the Attachments table of the
Mysql database is growing significantly. Our CSR’s want to attach
PDFs, jpegs, etc. to the tickets with the jpegs usually created by our
customers. The digital photos are the main culprit. I’ve read about
scaling back the photos, creating thumbnails, etc. and we need to find a
way to limit the attachment size prior to attachment.

Has anyone else using RT had this type of problem?

What are the best approaches for minimizing and controlling the size
of the Attachments table?

Any information, feedback and guidance are appreciated.

thanks - Gregory Harper , Stevens Industries


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Thanks Justin for the feedback. Anyone else have input regarding their
experiences with Attachments and RT?

thanks - Greg


Message: 3
Date: Mon, 6 Aug 2007 11:53:13 -0700 (PDT)
From: Ed Matthews g8orade@yahoo.com
Subject: [rt-users] Kwiki Table Rendering?
To: rt-users@lists.bestpractical.com
Message-ID: 569062.32875.qm@web51102.mail.re2.yahoo.com
Content-Type: text/plain; charset=us-ascii

Happy Monday.

Does anyone know why Kwiki renders tables on this page,
ManualScrips - Request Tracker Wiki

but not on this page
ManualRights - Request Tracker Wiki
nor in my personal page .

I tried copy pasting the first ManualScrips table wiki markup into another edit page and saving, and it wouldn’t render there either after save.

Ed Matthews
g8orade@yahoo.com


Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC


Message: 4
Date: Tue, 7 Aug 2007 10:20:33 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: [rt-users] Trying to change the logo. Fedora Core 7, RT3.6.3
yum install
To: rt-users@lists.bestpractical.com
Message-ID:
OF74585201.1DEBE7DD-ON80257330.003044E6-80257330.0033159C@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

I’m sure I’m just missing something simple, but I cannot seem to change the
BP logo on my install of RT 3.6.3 on Fedora Core 7.
I’ve installed RT using yum (lazy I know, but it works apart from this
issue).

It has been installed into
/usr/share/rt3
I’ve created /usr/local/rt3/html/Elements/
and copied the Logo file into that directory.

I’ve added the logo I want to use into /usr/share/rt3/html/NoAuth/images
It is a 92x50pixels jpeg.

Following suggestions from the wiki and the mailing list archives, I put
this line into the Logo file :
Intranet

I have modified by RT_SiteConfig.pm file.
If I log into the web interface, under tools, choose system configuration,
the following variables are set :
RT::LogoLinkURL http://192.168.66.1
RT::LogoURL /rt3/NoAuth/images/mtllogo.jpg
RT::LogoWidth 92
RT::LogoHeight 50
RT::MasonDataDir /var/cache/rt3/mason_data

I’ve tried stopping the webserver, deleting Logo.obj from
/var/cache/rt3/mason_data/obj/3989424063/standard
When I restart apache, and refresh the RT page, Logo.obj is recreated with
the best practical logo in it.

Where am I going wrong ? Can anyone point me in the right direction please
?

Thanks in advance

Luke


This email message may contain privileged/confidential information and/or
copyright material. It is intended only for the use of the person(s) to whom
it is addressed and any unauthorised use may be unlawful. If you receive this
email by mistake, please advise the sender immediately by using the reply
facility in your email software and delete the material from your computer.

The material contained in this message does not constitute a binding
contract with any company within the MTL Instruments Group plc. Opinions,
conclusions and other information in this email that do not relate to the official
business of this organisation shall be understood as neither given nor endorsed
by it. Registered in England No. 1871978, VAT Reg. No 449343040,
MTL Instruments Ltd, Power Court, Luton, LU1 3JJ

-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/37bbd464/attachment-0001.htm


Message: 5
Date: Tue, 7 Aug 2007 12:39:04 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: Re: {Disarmed} [rt-users] Trying to change the logo. Fedora
Core 7, RT3.6.3 yum install
To: Boris Jordanov jordanov@brg.bg
Cc: rt-users@lists.bestpractical.com
Message-ID:
OF7F7C160E.3A42C7E0-ON80257330.003EF00C-80257330.003FC412@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed…
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/graycol.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: pic05705.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/pic05705.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/ecblank.gif



RT-Users mailing list
RT-Users@lists.bestpractical.com
The rt-users Archives

End of RT-Users Digest, Vol 41, Issue 20



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Drew Barnes
Applications Analyst
Network Resources Department
Raymond Walters College
University of Cincinnati

Wiki would be enough, but there is a problem in current patch state:
it uses special constant string inplace of real content to indicate
that file is located out of DB.
Right way is to use flag in table. I do not think that changing scheme
witch patching is a good idea, that is why this patch must be merged into RT.

Now about “different strokes for different folks”.
This way of storing attachments is reasonable when you get 50Mb+ of mail
each week (scans, faxes, documents, etc).

Boris Lytochkin,
JSC e-port, Moscow
web: www.e-port.ru, wap: wap.e-port.ru
tel: +7 (495) 777 1872, ext. 251From: Drew Barnes
Sent: 7 пїЅпїЅпїЅпїЅпїЅпїЅпїЅ 2007 пїЅ., 21:08
To: Boris Lytochkin
Subject: [rt-users] Attachments table of RT’s Mysql database
I guess it all comes down to “different strokes for different folks”.
Perhaps this could be put up on the wiki and then if someone needs this
capability they can easily get it?

DB

Boris Lytochkin wrote:

Ken,

First, if everything is inside a database, then a
simple backup of the database will get everything related to a
particular RT instance.

Wrong. We stopped backup process of RT database due to LARGE amount
data every day. We have no such amount of tape to store DB’s everyday
backups.
Now, DB backup is done every day and attachment backup is done
separately. As a result we have everyday SQL-backup of DB and
incremental backup for attachments. It uses much less space.

Second, in many cases you would like to
isolate the front-end from the back-end information store. Once
you need access to the filesystem, everything becomes much more
involved.

I understand that storing attachments out of RT involves much more
than DB-only solution, BUT 10 Gb DB with 9.5 Gb of images involves much more.

Anyway, it is up to admin to decide whether to store attachments
separate or not.

Tuesday, August 7, 2007, 4:22:49 PM, you wrote:

Dear Mr. Lytochkin,

There are two very good reasons to not store attachments outside
of the database. First, if everything is inside a database, then a
simple backup of the database will get everything related to a
particular RT instance. Second, in many cases you would like to
isolate the front-end from the back-end information store. Once
you need access to the filesystem, everything becomes much more
involved. I am certain that there are other reasons, but those
two are certainly enough for me. I have appreciated the ease of
generating a consistent backup of my RT information store.

Ken

I wrote a patch that allows to store non-text attachments to be
stored out of DB - in my case it greatly reduced DB swelling.
Just for now it uses constant string in Attachments->Content to
indicate that file is written to FS.

You will need to specify some variables in RT_Siteconfig.pm:
Set($AttachmentsDirectory, ‘/var/RT/attachments’);
Set($LogAttachmentsLoading, “1”);
Set($LogAttachmentsSaving, “1”);
Set($StoreNonTextAttachmensInDB, undef);
#Set($StoreNonTextAttachmensInDB, “1”);

A new share/html/Ticket/Attachment/dhandler and attach.patch for
rest of RT distribution is in attachment.

Gregory Harper, you can find more complex set of patches allowing to
produce & show image thumbs automaticly in attachment too.
Some more variables must be specified in RT_Siteconfig.pm

Set($ShowTransactionImages, 1);
Set($ProduceImageThumbs, 1);
Set($ImageThumbsDirectory, ‘/var/RT/thumbs’);

I wonder why bestprcactical is not interested in intergating these
patches into RT:
From: Jesse Vincent
Sent: 21 march 2007 ?., 23:53
To: lytochkin
Subject: [RT 3.6] Storing attachments away from DB
Hi Boris,

Thanks very much for the mail, but I think we’re not really
interested in offering this feature within RT.
Best,
Jesse


Boris Lytochkin,
JSC e-port, Moscow
web: www.e-port.ru, wap: wap.e-port.ru
tel: +7 (495) 777 1872, ext. 251


Date: Mon, 06 Aug 2007 12:31:31 -0500
From: Gregory Harper gregh@stevensind.com
Subject: Re: [rt-users] Attachments table of RT’s Mysql database
To: Justin Brodley jbrodley@sumtotalsystems.com
Cc: rt-users@lists.bestpractical.com
Message-ID: 46B75AF3.3080200@stevensind.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Justin Brodley wrote:

We actually had to disable the attachment feature as we were having our customers attach enormous files and killed our DB processing. Ultimately we

are looking

into rewriting the attachment feature to store the attachments on the web server to alleviate this overhead from the DB. I understand that the

attachment table also

stores all updates to a ticket, not just the attachments.

Justin Brodley

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Gregory Harper
Sent: Wednesday, August 01, 2007 12:41 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Attachments table of RT’s Mysql database

Hello everybody.

We’ve been using RT for more than three months as part of our
customer concern processes. Overall, things have been going well.
The configuration includes Mysql, Apache2 and Postfix running on Ubuntu
6.06. I’ve made no modifications to the databases.
The primary concern at this point is that the Attachments table of the
Mysql database is growing significantly. Our CSR’s want to attach
PDFs, jpegs, etc. to the tickets with the jpegs usually created by our
customers. The digital photos are the main culprit. I’ve read about
scaling back the photos, creating thumbnails, etc. and we need to find a
way to limit the attachment size prior to attachment.

Has anyone else using RT had this type of problem?

What are the best approaches for minimizing and controlling the size
of the Attachments table?

Any information, feedback and guidance are appreciated.

thanks - Gregory Harper , Stevens Industries


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Thanks Justin for the feedback. Anyone else have input regarding their
experiences with Attachments and RT?

thanks - Greg


Message: 3
Date: Mon, 6 Aug 2007 11:53:13 -0700 (PDT)
From: Ed Matthews g8orade@yahoo.com
Subject: [rt-users] Kwiki Table Rendering?
To: rt-users@lists.bestpractical.com
Message-ID: 569062.32875.qm@web51102.mail.re2.yahoo.com
Content-Type: text/plain; charset=us-ascii

Happy Monday.

Does anyone know why Kwiki renders tables on this page,
ManualScrips - Request Tracker Wiki

but not on this page
ManualRights - Request Tracker Wiki
nor in my personal page .

I tried copy pasting the first ManualScrips table wiki markup into another edit page and saving, and it wouldn’t render there either after save.

Ed Matthews
g8orade@yahoo.com


Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC


Message: 4
Date: Tue, 7 Aug 2007 10:20:33 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: [rt-users] Trying to change the logo. Fedora Core 7, RT3.6.3
yum install
To: rt-users@lists.bestpractical.com
Message-ID:
OF74585201.1DEBE7DD-ON80257330.003044E6-80257330.0033159C@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

I’m sure I’m just missing something simple, but I cannot seem to change the
BP logo on my install of RT 3.6.3 on Fedora Core 7.
I’ve installed RT using yum (lazy I know, but it works apart from this
issue).

It has been installed into
/usr/share/rt3
I’ve created /usr/local/rt3/html/Elements/
and copied the Logo file into that directory.

I’ve added the logo I want to use into /usr/share/rt3/html/NoAuth/images
It is a 92x50pixels jpeg.

Following suggestions from the wiki and the mailing list archives, I put
this line into the Logo file :
Intranet

I have modified by RT_SiteConfig.pm file.
If I log into the web interface, under tools, choose system configuration,
the following variables are set :
RT::LogoLinkURL http://192.168.66.1
RT::LogoURL /rt3/NoAuth/images/mtllogo.jpg
RT::LogoWidth 92
RT::LogoHeight 50
RT::MasonDataDir /var/cache/rt3/mason_data

I’ve tried stopping the webserver, deleting Logo.obj from
/var/cache/rt3/mason_data/obj/3989424063/standard
When I restart apache, and refresh the RT page, Logo.obj is recreated with
the best practical logo in it.

Where am I going wrong ? Can anyone point me in the right direction please
?

Thanks in advance

Luke


This email message may contain privileged/confidential information and/or
copyright material. It is intended only for the use of the person(s) to whom
it is addressed and any unauthorised use may be unlawful. If you receive this
email by mistake, please advise the sender immediately by using the reply
facility in your email software and delete the material from your computer.

The material contained in this message does not constitute a binding
contract with any company within the MTL Instruments Group plc. Opinions,
conclusions and other information in this email that do not relate to the official
business of this organisation shall be understood as neither given nor endorsed
by it. Registered in England No. 1871978, VAT Reg. No 449343040,
MTL Instruments Ltd, Power Court, Luton, LU1 3JJ

-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/37bbd464/attachment-0001.htm


Message: 5
Date: Tue, 7 Aug 2007 12:39:04 +0100
From: Luke E Morgan lmorgan@mtl-inst.com
Subject: Re: {Disarmed} [rt-users] Trying to change the logo. Fedora
Core 7, RT3.6.3 yum install
To: Boris Jordanov jordanov@brg.bg
Cc: rt-users@lists.bestpractical.com
Message-ID:
OF7F7C160E.3A42C7E0-ON80257330.003EF00C-80257330.003FC412@mtl-inst.com

Content-Type: text/plain; charset=“us-ascii”

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed…
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/graycol.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: pic05705.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/pic05705.gif
-------------- next part --------------
A non-text attachment was scrubbed…
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20070807/910b3d6a/ecblank.gif



RT-Users mailing list
RT-Users@lists.bestpractical.com
The rt-users Archives

End of RT-Users Digest, Vol 41, Issue 20



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Drew Barnes
Applications Analyst
Network Resources Department
Raymond Walters College
University of Cincinnati

Wiki would be enough, but there is a problem in current patch state:
it uses special constant string inplace of real content to indicate
that file is located out of DB.
Right way is to use flag in table. I do not think that changing scheme
witch patching is a good idea, that is why this patch must be
merged into RT.

This might be a good place to use the ContentEncoding field to
describe an ‘ondisk’ encoding.

-jesse

PGP.sig (186 Bytes)

Wednesday, August 8, 2007, 6:22:31 PM, you wrote:

This might be a good place to use the ContentEncoding field to
describe an ‘ondisk’ encoding.

How do you expect to use this filed?
Something like ‘(ondisk|inDB),(base64|quoted-printable|…)’?> On Aug 8, 2007, at 5:17 AM, Boris Lytochkin wrote:

Wiki would be enough, but there is a problem in current patch state:
it uses special constant string inplace of real content to indicate
that file is located out of DB.
Right way is to use flag in table. I do not think that changing scheme
witch patching is a good idea, that is why this patch must be
merged into RT.

This might be a good place to use the ContentEncoding field to
describe an ‘ondisk’ encoding.

-jesse

Best regards,
Boris Lytochkin mailto:boris.lytochkin@e-port.ru

You could do that or just have ‘ondisk’ be a new encoding type added at
the end of the list.
The Content field of the data base could store the path to the file
relative to a config option.

I would suggest a file size threshold option if RT starts using the file
system to store attachements.

The folowing config options could be added:
Set( $AttachmentLocation, ‘indb’|‘ondisk’|‘size’ ) ;
Set( $AttachmentDiskStorageThreshhold, 4096 ) ;
Set( $AttachmentDiskPath, ‘/some/location’ ) ;

KeithFrom: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Boris
Lytochkin
Sent: Wednesday, August 08, 2007 9:48 AM
To: Jesse Vincent
Cc: rt-users@lists.bestpractical.com
Subject: Re[4]: [rt-users] Attachments table of RT’s Mysql database

Wednesday, August 8, 2007, 6:22:31 PM, you wrote:

This might be a good place to use the ContentEncoding field to
describe an ‘ondisk’ encoding.

How do you expect to use this filed?
Something like ‘(ondisk|inDB),(base64|quoted-printable|…)’?

Wednesday, August 8, 2007, 6:22:31 PM, you wrote:

This might be a good place to use the ContentEncoding field to
describe an ‘ondisk’ encoding.

How do you expect to use this filed?
Something like ‘(ondisk|inDB),(base64|quoted-printable|…)’?

I think I was envisioning “ondisk” as a new encoding meaning "the
content is the path to the attachment’s content on disk (presumably
named as a sha1 sum of its content) and not a prefox to the existing
encodings. There’s not much sense in storing stuff on disk in
something other than raw binary format.

Best,
Jesse

PGP.sig (186 Bytes)

Wednesday, August 8, 2007, 7:45:08 PM, you wrote:

I think I was envisioning “ondisk” as a new encoding meaning "the
content is the path to the attachment’s content on disk (presumably
named as a sha1 sum of its content) and not a prefox to the existing
encodings. There’s not much sense in storing stuff on disk in
something other than raw binary format.

It’s better to use my variant of attachment naming:

  1. Attachment.Content = NULL, this saves disk space.
  2. TransactionId.AttachmentId naming is familiar with download links in Web
    interface.

So, your idea is to move selection of storage to
RT::Record::_EncodeLOB, where encoding format is selected.
But this function is used by ObjectCustomFieldValue_Overlay.pm, that
will be confused when it get ‘ondisk’.

So, ContentEncoding seems to be not very good field to store ‘ondisk’
flag since ‘ondisk’ means storage scheme, not encoding. Mixing it will
produce awkward result.

Best regards,
Boris Lytochkin mailto:boris.lytochkin@e-port.ru