Re: [rt-users] Multi-Tenant Users
Matt Wells mosaic451.com> writes: > > > > Hi all, first let me say thanks for all the great data on this list. It's one of the most active I'm on. Thank you all. > I have a question on a multi-tenant system I'm bringing up in dev. In testing the isolation of queues and tickets was easy enough; however one item within the ticket became an issue. > > Bob example.com can use the auto-fill on in the users field to gather data on other users outside of his group on the system. > I fished around in the global menu but failed to find a place to disable this. Can anyone point me in the right direction? > I'm on 4.2.9. > > > > - > RT 4.4 and RTIR Training Sessions https://bestpractical.com/training > * Washington DC - May 23 & 24, 2016 > Hi Matt, I'm looking for implementing a multi tenant RT system, where we can host the queues of multiple customer. 1. Although I did not find any option to disable the auto-fill option, will limiting the search to the group of users for that particular tenant help?. A couple of doubts from my end. 1. There might be a scenario, where different tenants will be having same queue name or user name (both having unique constraint at the DB level). What approach would you suggest to handle that scenario? 2. Is adding an an additional column to hold the tenant id a good idea? Or handling through custom field at queue, User and group level will be a better approach. Thanks - RT 4.4 and RTIR Training Sessions https://bestpractical.com/training * Los Angeles - September, 2016
[rt-users] Multi-Tenant Users
Hi all, first let me say thanks for all the great data on this list. It's one of the most active I'm on. Thank you all. I have a question on a multi-tenant system I'm bringing up in dev. In testing the isolation of queues and tickets was easy enough; however one item within the ticket became an issue. b...@example.com can use the auto-fill on in the users field to gather data on other users outside of his group on the system. I fished around in the global menu but failed to find a place to disable this. Can anyone point me in the right direction? I'm on 4.2.9. - RT 4.4 and RTIR Training Sessions https://bestpractical.com/training * Washington DC - May 23 & 24, 2016
[rt-users] Multi-tenant / multi smtp servers
Hi all, I hope everyone is getting ready for a good weekend. I have a questions about multi-tenant and white labeling. We have a need for a few customers to be white labeled and I've been searching all over for the best way to get this done. Just to be clear by white labeling I'm mean that our customers do not wish to expose to their customers that we perform the work. Essentially Our customer Example.com get's support requests from their customers at supp...@example.com that in turn forwards to "exa-qu...@us.ticketsvoodoo.com " ( an RT queue; this forward had led to it's own unique issue of auto replies but I'm that's another cane of worms hehe ) When we reply to the tickets here we need those replies to go through their SMTP servers thus obfuscating us and leaving Example.com's customers believing they are working on these issues. I have 50 queues so I can't route all of postfix; not that I think anyone would have suggested that one. What I'm looking at now is the use of a canonical name mapping and header checks but I figure their must be a more elegant way to get this done. I truly appreciate this communities help. RT community has always been one of the best. Thank you so very much for your time.
Re: [rt-users] Multi-tenant
> On Wed, Dec 12, 2012 at 09:05:34AM -0800, Thomas Sibley wrote: > > On 12/12/2012 08:12 AM, CB wrote: > > > 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. We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
> 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 We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
On 12/13/2012 12:26 PM, Rainer Duffner wrote: >> 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. 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. :) We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
Am 13.12.2012 um 21:20 schrieb Thomas Sibley : > On 12/13/2012 10:42 AM, Shuvam Misra wrote: >> 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. We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
On 12/13/2012 10:42 AM, Shuvam Misra wrote: > 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. We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
> 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 We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
On 12/13/2012 02:33 AM, Shuvam Misra wrote: >>> 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. We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
On 13 Dec 2012, at 10:56, Shuvam Misra wrote: >> 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. We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
> 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 We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
On Thu, 13 Dec 2012, Shuvam Misra wrote: ... > (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 \ 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/ We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
> > 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 We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
On Wed, Dec 12, 2012 at 09:05:34AM -0800, Thomas Sibley wrote: > On 12/12/2012 08:12 AM, CB wrote: > > 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 Description: Digital signature We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
On 12/12/2012 08:12 AM, CB wrote: > 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? We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Multi-tenant
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. Cameron From: Kenneth Crocker [mailto:kenn.croc...@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 On Tue, Dec 11, 2012 at 9:33 AM, CB wrote: 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 We're hiring! http://bestpractical.com/jobs We're hiring! http://bestpractical.com/jobs
[rt-users] Multi-tenant
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 <> We're hiring! http://bestpractical.com/jobs
