Hi,
I’m investigating the possibilities of splitting out bits of RT onto
different hosts, for security purposes.
I figure it’s trivial to run the database on a separate host to the Web
UI/mailgate, but is it possible to run the mailgate on a separate host to
the UI?
My impression of the way attachments are handled by the mailgate is they
get split out onto the local filesystem, so the UI would need to be on the
same host (or you’d need to remotely mount part of the mailgate host’s
filesystem onto the UI host (which I don’t want to do)).
So in terms of multi-tiering, is separating the database from the
UI/mailgate about the end of it?
Andrew
Andrew Pollock wrote:
I figure it’s trivial to run the database on a separate host to the Web
UI/mailgate, but is it possible to run the mailgate on a separate host to
the UI?
It should be…
My impression of the way attachments are handled by the mailgate is they
get split out onto the local filesystem, so the UI would need to be on the
same host (or you’d need to remotely mount part of the mailgate host’s
filesystem onto the UI host (which I don’t want to do)).
The attachments are all thrown into the DB, no filesystem access
should be required (but, I haven’t done it, so I could be wrong.)
(In 1.0 days, attachments were stored on the filesystem instead of
in the DB, but this is not the case in 2.x.)
In 3.x, the mailgate merely does a post-to-web-form, so it can reside
pretty much anywhere.
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances
The attachments are all thrown into the DB, no filesystem access
should be required (but, I haven’t done it, so I could be wrong.)
(In 1.0 days, attachments were stored on the filesystem instead of
in the DB, but this is not the case in 2.x.)
In 3.x, the mailgate merely does a post-to-web-form, so it can reside
pretty much anywhere.
I didn’t see any evidence that the attachments were in the database with
2.0.14 on PostgreSQL, but I’ll toddle off and reinspect the schema.
Andrew
On Fri, 17 Jan 2003, A BIT of an Andrew Pollock wrote something about
splitting RT:> On Fri, Jan 17, 2003 at 02:56:31PM +1000, Phil Homewood wrote:
The attachments are all thrown into the DB, no filesystem access
should be required (but, I haven’t done it, so I could be wrong.)
I didn’t see any evidence that the attachments were in the database with
2.0.14 on PostgreSQL, but I’ll toddle off and reinspect the schema.
In our setup, we have 4 distinct machines, and a plethora of desktops that
are able to directly access the SQL servers. The maintainance of this is
eased by having our install directory, /home/rt2, NFS shared across the
machines.
/----------\
| mailserver |-----\
\----------/ \
\
/----------\ \ /-----------\
| webserver |----------> MySQL access -----| MySQL-grunt |
\----------/ \ / \-----------/
\--/-\ |
/----------\ / \ /-----------\
| desktops |-->--*----- Intended Query ---| Backup Serv |
\----------/ Only Access \-----------/
I haven’t gotten around to the ‘Intended Query Only Access’ functionality,
but one day, one day. The connection between the MySQL grunt machine and
the Backup Serv(er) is standard MySQL replication.
Regards,
Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations/Security
On Fri, 17 Jan 2003, A BIT of an Andrew Pollock wrote something about
splitting RT:
The attachments are all thrown into the DB, no filesystem access
should be required (but, I haven’t done it, so I could be wrong.)
I didn’t see any evidence that the attachments were in the database with
2.0.14 on PostgreSQL, but I’ll toddle off and reinspect the schema.
I stand corrected, they go into the attachments table, just not as BLOBs
like I expected…
In our setup, we have 4 distinct machines, and a plethora of desktops that
are able to directly access the SQL servers. The maintainance of this is
eased by having our install directory, /home/rt2, NFS shared across the
machines.
NFS is evil and can’t be used in the environment that I’m looking at
deploying RT2 into.
/----------\
| mailserver |-----\
\----------/ \
\
/----------\ \ /-----------\
| webserver |----------> MySQL access -----| MySQL-grunt |
\----------/ \ / \-----------/
\--/-\ |
/----------\ / \ /-----------\
| desktops |-->--*----- Intended Query ---| Backup Serv |
\----------/ Only Access \-----------/
I haven’t gotten around to the ‘Intended Query Only Access’ functionality,
but one day, one day. The connection between the MySQL grunt machine and
the Backup Serv(er) is standard MySQL replication.
What are you sharing via NFS anyway, just the RT (config) files and
whatnot to keep them all in sync?
Andrew
In our setup, we have 4 distinct machines, and a plethora of desktops that
are able to directly access the SQL servers. The maintainance of this is
eased by having our install directory, /home/rt2, NFS shared across the
machines.
NFS is evil and can’t be used in the environment that I’m looking at
deploying RT2 into.
So have a master tree for the RT libraries, and remember to sync them when
you do an upgrade. (Note that this is for RT 2.x . RT 3.x changes
slightly.
What are you sharing via NFS anyway, just the RT (config) files and
whatnot to keep them all in sync?
For RT, just the perl scripts, the libraries and a small setuid proggie
(swiped from the majordomo dist) to make sure the enquiring little buggers
can’t get the actual MySQL password.
NFS is used because our backend data storage is a Netapp filer… Snapshots
are Goooood 
Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations/Security