Is it possible to set up RT 4 in a multi-tenant environment? Each tenant
would have their own domain name/look/queues/scrips etc without requiring a
separate RT install.
Cameron
winmail.dat (7.32 KB)
Thanks. I understand that it’s possible to have multiple queues. Is it
possible to have a multi-tenant setup i.e. one RT install with each “tenant”
having its own environment e.g. domain, users, admin rights etc. Each tenant
can log in to its own domain and administer the system (for themselves
without affecting anyone else). From what I can see there is one local
config file for all of RT and it’s not possible to specify multiple domains.
CameronFrom: Kenneth Crocker [mailto:kenn.crocker@gmail.com]
Sent: Wednesday, 12 December 2012 4:14 p.m.
To: CB
Subject: Re: [rt-users] Multi-tenant
Cameron,
That’s the whole point of RT being so flexible. I have set up several
clients with different workflows for different Queues via Queue-based scrips
and templates, etc.
One domain, many Queues and each Queue has it’s own set of processes, Custom
Fields, scrips, templates, etc.
Kenn
Thanks. I understand that it’s possible to have multiple queues. Is it
possible to have a multi-tenant setup i.e. one RT install with each “tenant”
having its own environment e.g. domain, users, admin rights etc. Each tenant
can log in to its own domain and administer the system (for themselves
without affecting anyone else). From what I can see there is one local
config file for all of RT and it’s not possible to specify multiple domains.
Short answer: No.
Why would you prefer a single monolithic RT instance rather than a
handful of separate ones?
Thanks. I understand that it’s possible to have multiple queues. Is it
possible to have a multi-tenant setup i.e. one RT install with each “tenant”
having its own environment e.g. domain, users, admin rights etc. Each tenant
can log in to its own domain and administer the system (for themselves
without affecting anyone else). From what I can see there is one local
config file for all of RT and it’s not possible to specify multiple domains.Short answer: No.
Slightly longer answer: maybe, depending on definitions?
Whilst RT has a notion of a single domain, you are free to route emails
from other domains into the system (and have queues set up to respond
with those addresses). Together with the fine-grained permissions model,
and the subject tags on queues it may be possible to configure a single
RT instance which would meet the OP’s requirements (although I guess
user admin would be the one sticking point, so it might be necessary
to arrange for a separate user provisioning add-on to support the
specific use cases).
Why would you prefer a single monolithic RT instance rather than a
handful of separate ones?
Efficiencies in administration overhead and hardware requirements
(depending on the relative volume of transactions, of course) are two
that spring to mind immediately.
Dominic Hargreaves, Systems Development and Support Section
IT Services, University of Oxford
signature.asc (198 Bytes)
Why would you prefer a single monolithic RT instance rather than a
handful of separate ones?Efficiencies in administration overhead and hardware requirements
(depending on the relative volume of transactions, of course) are two
that spring to mind immediately.
Would tend to agree. In fact, I was quite taken aback by the earlier
question. If one needs to run half a dozen separate RT installations
(separate domains, separate user lists, etc) and the software allows
you to run all of them from a single database and on a single server
(i.e. multi-tenant support), will anyone want to set up separate servers
then? I would have thought the reverse question is the natural one.
Shuvam
…
(i.e. multi-tenant support), will anyone want to set up separate servers
then? I would have thought the reverse question is the natural one.
Having read only the last thee mails and not much time now,
I only want to tell, we did exactly tht, we did split a
multi-tenant RT into (only!) two sepearte instances.
Here were some more inssues than simply multi-versus-sigle
group usage. But one of the reasons might be important.
The overall-rights-matrix on only-one-userbase makes it
difficult to wall in each of the groups, so they never
see or notice one of the others. It is possible, but
error-prone, if the ‘groups’ try to administer their own
‘set of queues’. One wrong click or ‘right’ and information
leaks will happen. In sigle-tenant-setups this stays
impossible and virtual hosts are relatively cheap.
Stucki
Christoph von Stuckrad * * |nickname |Mail stucki@mi.fu-berlin.de
Freie Universitaet Berlin |/_*|‘stucki’ |Tel(Mo.,Mi.):+49 30 838-75 459|
Mathematik & Informatik EDV |\ *|if online| (Di,Do,Fr):+49 30 77 39 6600|
Takustr. 9 / 14195 Berlin * * |on IRCnet|Fax(home): +49 30 77 39 6601/
The overall-rights-matrix on only-one-userbase makes it
difficult to wall in each of the groups, so they never
see or notice one of the others. It is possible, but
error-prone, if the ‘groups’ try to administer their own
‘set of queues’. One wrong click or ‘right’ and information
leaks will happen. In sigle-tenant-setups this stays
impossible and virtual hosts are relatively cheap.
An application has to be designed to be multi-tenanted from the ground up
to avoid these dangers. I guess RT is not.
When we design multi-tenant apps, we get so paranoid that we add a
“clientID” column to each table, without exception. Don’t want to mess
with leaks across these walls – clients will disappear before we know
it.
Shuvam
The overall-rights-matrix on only-one-userbase makes it
difficult to wall in each of the groups, so they never
see or notice one of the others. It is possible, but
error-prone, if the ‘groups’ try to administer their own
‘set of queues’. One wrong click or ‘right’ and information
leaks will happen. In sigle-tenant-setups this stays
impossible and virtual hosts are relatively cheap.An application has to be designed to be multi-tenanted from the ground up
to avoid these dangers. I guess RT is not.
Indeed; there are several places where this is obvious; the principal ones, in my view, being Scrips and Templates. Both of these allow essentially arbitrary perl code. RT’s access control lists don’t apply here - everything essentially happens as the RT::System user, so if a user has the ability to write Mason templates, or to write Scrips, they can automatically access anything in the database, even if the ACLs formally forbid it.
Even if you had the client id column, you’d still have security issues to do with arbitrary perl, since you can always find the appropriate database handle and just do things to the database willy nilly.
In order to make multi-tenant even remotely sensible, you’d have basically completely ban users from making custom scrips and templates. And then, in my view, re-architect the way things work. You’d probably need:
a) Several RT::System style users for the different tenants (or possibly)
b) Database level permissions using those users
Row-based authentication isn’t available in MySQL, so you’d probably have to use something like Oracle, if you wanted it really bullet proof.
Personally, I’d do multi-tenant through virtualisation. Still only one piece of hardware, but you’re keeping the data more effectively segregated. You could simplify and centralise your configuration through scripts, so you didn’t have to configure each tenant by hand.
Tim
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Why would you prefer a single monolithic RT instance rather than a
handful of separate ones?Efficiencies in administration overhead and hardware requirements
(depending on the relative volume of transactions, of course) are two
that spring to mind immediately.Would tend to agree. In fact, I was quite taken aback by the earlier
question. If one needs to run half a dozen separate RT installations
(separate domains, separate user lists, etc) and the software allows
you to run all of them from a single database and on a single server
(i.e. multi-tenant support), will anyone want to set up separate servers
then? I would have thought the reverse question is the natural one.
Perhaps it’s our different perspectives. 
Multi-tenant support (as
you can start to see from the followups in this thread already) is full
of thorny issues that add an astonishing amount of development and
maintenance complexity and overhead. It’s much simpler from many
perspectives to avoid that complexity by relying on physical separations
(VMs, virtual hosts, etc) to achieve separate instances.
There’s no reason you have to setup entirely separate servers for each
tenant (although you may want to for other reasons); you can run
multiple copies of RT on the same server just fine.
Personally, I’d do multi-tenant through virtualisation. Still only
one piece of hardware, but you’re keeping the data more effectively
segregated. You could simplify and centralise your configuration through
scripts, so you didn’t have to configure each tenant by hand.
I too was wondering what would I do if I took a browser-based app like RT
and needed to run multi-tenant setups on a single physical server. One
option is of course virtualisation, but another could be just running an
Apache with multiple virtualhost setups. Can one install multiple copies
of RT in multiple directories, and make them connect to the same PG or
MySQL database server but use various different databases? So, in short,
we will have one Apache daemon listening on five different domains using
its VirtualHost feature, then redirecting accesses to five different
physical copies of RT running on five different port numbers and storing
their config files etc in five different directories. And at the
back-end, all five RT instances would talk to the same database server on
the same database port number, but would connect to five different
databases.
Will this work?
Shuvam
I too was wondering what would I do if I took a browser-based app like RT
and needed to run multi-tenant setups on a single physical server. One
option is of course virtualisation, but another could be just running an
Apache with multiple virtualhost setups. Can one install multiple copies
of RT in multiple directories, and make them connect to the same PG or
MySQL database server but use various different databases? So, in short,
we will have one Apache daemon listening on five different domains using
its VirtualHost feature, then redirecting accesses to five different
physical copies of RT running on five different port numbers and storing
their config files etc in five different directories. And at the
back-end, all five RT instances would talk to the same database server on
the same database port number, but would connect to five different
databases.Will this work?
Yup, works great. That’s essentially what we do. You’ll want a
mod_fcgid, mod_fastcgi, or reverse proxy deployment. You can’t use
mod_perl to run multiple copies of RT because of the global Perl
interpreter state.
I too was wondering what would I do if I took a browser-based app like RT
and needed to run multi-tenant setups on a single physical server. One
option is of course virtualisation, but another could be just running an
Apache with multiple virtualhost setups. Can one install multiple copies
of RT in multiple directories, and make them connect to the same PG or
MySQL database server but use various different databases? So, in short,
we will have one Apache daemon listening on five different domains using
its VirtualHost feature, then redirecting accesses to five different
physical copies of RT running on five different port numbers and storing
their config files etc in five different directories. And at the
back-end, all five RT instances would talk to the same database server on
the same database port number, but would connect to five different
databases.Will this work?
Yup, works great. That’s essentially what we do. You’ll want a
mod_fcgid, mod_fastcgi, or reverse proxy deployment. You can’t use
mod_perl to run multiple copies of RT because of the global Perl
interpreter state.
I think it would be possible, if you ran multiple instances of the whole Apache:
http://wiki.apache.org/httpd/RunningMultipleApacheInstances
(on various 127.0.0.x aliases) and then run yet-another apache with mod_proxy in front of them).
Would be interesting to know how well that actually scales - and how to limit the CPU consumption of each instance.
Yup, works great. That’s essentially what we do. You’ll want a
mod_fcgid, mod_fastcgi, or reverse proxy deployment. You can’t
use mod_perl to run multiple copies of RT because of the global
Perl interpreter state.I think it would be possible, if you ran multiple instances of the
whole Apache:RunningMultipleApacheInstances - HTTPD - Apache Software Foundation
(on various 127.0.0.x aliases) and then run yet-another apache with
mod_proxy in front of them).Would be interesting to know how well that actually scales - and how
to limit the CPU consumption of each instance.
There’s no benefit from mod_perl that isn’t also had via one of the
FastCGI implementations or a lighter weight server (Starman, for
instance) behind an Apache reverse proxy. And there are downsides to
mod_perl as well as having to run multiple Apache instances. So,
possible, but not close to worth it.
Yup, works great. That’s essentially what we do. You’ll want a
mod_fcgid, mod_fastcgi, or reverse proxy deployment. You can’t use
mod_perl to run multiple copies of RT because of the global Perl
interpreter state.
Thanks for that tip – I’d never have figured that one out.
Shuvam
Thanks. I understand that it’s possible to have multiple queues. Is
it possible to have a multi-tenant setup i.e. one RT install with
each “tenant”
having its own environment e.g. domain, users, admin rights etc.
Each tenant can log in to its own domain and administer the system
(for themselves without affecting anyone else). From what I can see
there is one local config file for all of RT and it’s not possible
to specify multiple domains.Short answer: No.
Slightly longer answer: maybe, depending on definitions?
Whilst RT has a notion of a single domain, you are free to route emails
from other domains into the system (and have queues set up to respond
with those addresses). Together with the fine-grained permissions model,
and the subject tags on queues it may be possible to configure a single
RT instance which would meet the OP’s requirements (although I guess
user admin would be the one sticking point, so it might be necessary to
arrange for a separate user provisioning add-on to support the specific
use cases).
Thanks. It seems that to do this properly RT is not the tool - it’s just not
architected in that way. Multi-tenant systems I’m familiar with (e.g. Oracle
E-Business Suite) have “striped” data so each tenant is logically separated.
Subject tags, a very basic feature set and a new UI with limited
functionality could possibly get us most of the way there.
Why would you prefer a single monolithic RT instance rather than a
handful of separate ones?Efficiencies in administration overhead and hardware requirements
(depending on the relative volume of transactions, of course) are two
that spring to mind immediately.
For a handful I agree however it is not scalable beyond that in my view.