[rt-users] Virtual RT
Bob Goldstein
bobg at uic.edu
Mon Sep 26 11:34:22 EDT 2005
>
> I just wanted to add something regarding my interpretations here.
> Yes, you can run Multiple Instances, *BUT*, and this is a
>*BIIIIIGGGGGG* but... Its *NOT* Virtual.
I'm curious what you're driving at, and I'm not clear what
"virtual" means in your context.
You said you want different Signatures/Priorities/Templates
between the virtual RTs. I think you said you wanted
different queues, users, and customer fields, too.
You didn't say if you wanted completely independent *tickets*.
Nor did you say if anything in the database should be held
in common, or if you ever need to transfer tickets between
virtual RTs.
If you want the RT items (users, tickets, queues, ...)
separate, but you just want to minimize the admin cost of
maintaining RT, then why not use different mysql databases
(within the same mysql server/engine)? You would have each
database dealt with by a separate set of fcgi processes, all
running from the same code base on the same apache server. The
"virtual" part would mean one apache install, one RT code
install, one mysql install, but a separate RT_SiteConfig and
separate mysql database per virtual RT. (After all, each
virtual RT has to have something that is different.)
However, if you don't want everything separate, then
I'm really not clear on what parts are common and what parts
are not. For example, if the tickets are to be common,
then are you suggesting that ticket #10 (uniquely identified
among all virtual RTs) might be in Queue_xyz in RT_A
and in Queue_abc in RT_B ? If an admin for RT_A wanted
to restrict privs to view a given queue, would that stop
the admin for RT_B from assigning tickets in this queue
to some public queue visibile in his virtual RT?
I suppose this is idle curiosity, I'm just trying to
understand what you are asking.
bobg
>
> Virtual infers you can run a common and SINGLE backend (ala say
>Apache) yet had numerous complete and independant configurations that
>all interact with that same common backend (just like <Virtual> tags
>inside that Apache config).
>
> Now, configuring FastCGI and setting lots of instances with slightly
>different RT_SiteConfigs etc is *not* a 'Virtual' solution, becuase the
>Database backend is common, and thus, the Queues, Users (Privelged, and
>worse Unprivliged) and Customer Fields etc etc are common.
>
> I have a classic scenario where I have techs working two completly
>seperately branded ISPs. This results in two completly seperate installs
>of RT due to the differing requirements for
>Signatures/Priorities/Templates . There is no way to maintain a common
>single database backend yet maintain seperate versions of these/
>
> Can you imagine having to setup complete independant versions of
>Apache for each Virtual Server??? Thats the difference between
>'multiple' and 'virtual'.
>
> Just my experience with RT. I ended up discussing this with Jesse at
>length, and it would in fact cost money (in the order of $1000's) to
>have such a system to support multiple signatures and multiple queues
>and privleges within one database instance (which it must do to be
>considered 'virtual').
>
>Cheers
>
>Adrian
>
>
>Laurent GAUTROT wrote:
>
>>>Jerry <Jerry at cockatoos.com> wrote :
>>>Is it possible to configure RT in such a way that one installation can
>>>be virtual for many domains, such as you might do for an ISP, with
>>>separate administrators and users for each domain?
>>>
>>>
>>
>>In fact, yes, it is.
>>
>>Maybe you should give this page a read :
>>
>>http://wiki.bestpractical.com/index.cgi?MultipleInstances
>>
>>
>>
>>>Alternatively, could it be configured that you could have separate
>>>administrators and users for hundreds or groups at one domain? Would
>>>these be queues? If so, can they be managed with conditional code, or
>>>does each one have to be setup at the mail server and/or other areas?
>>>
>>>
>>
>>With FastCGI you can have separate environments, so you can setup variables.
>>
>>By this mean, each RT site can have its own customisations.
>>
>>The databases are independant. Notice that if you use MySQL you should take
>>care of the naming of the databases. « - » in database names will lead
>>rt-setup-database to fail (only for MySQL).
>>_______________________________________________
>>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>
>>Be sure to check out the RT Wiki at http://wiki.bestpractical.com
>>
>>Buy your copy of our new book, RT Essentials, today!
>>
>>Download a free sample chapter from http://rtbook.bestpractical.com
>>
>>
>>
>>
>
>--
>Adrian Carter
>Technical Manager
>Leading Edge Internet
>
>Web http://www.lei.net.au http://support.lei.net.au
>Direct +61 2 6163 6162 Support 1 300 662 415
>E-mail cartera at lei.net.au
>
>
>--------------050707070605030201040206
>Content-Type: text/html; charset=ISO-8859-15
>Content-Transfer-Encoding: 8bit
>
><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
><html>
><head>
> <meta content="text/html;charset=ISO-8859-15"
> http-equiv="Content-Type">
></head>
><body bgcolor="#ffffff" text="#000000">
> I just wanted to add something regarding my interpretations here.<br>
> Yes, you can run Multiple Instances, *BUT*, and this is a
>*BIIIIIGGGGGG* but... Its *NOT* Virtual.<br>
><br>
> Virtual infers you can run a common and SINGLE backend (ala say
>Apache) yet had numerous complete and independant configurations that
>all interact with that same common backend (just like <Virtual>
>tags inside that Apache config).<br>
><br>
> Now, configuring FastCGI and setting lots of instances with
>slightly different RT_SiteConfigs etc is *not* a 'Virtual' solution,
>becuase the Database backend is common, and thus, the Queues, Users
>(Privelged, and worse Unprivliged) and Customer Fields etc etc are
>common.<br>
><br>
> I have a classic scenario where I have techs working two completly
>seperately branded ISPs. This results in two completly seperate
>installs of RT due to the differing requirements for
>Signatures/Priorities/Templates . There is no way to maintain a common
>single database backend yet maintain seperate versions of these/<br>
><br>
> Can you imagine having to setup complete independant versions of
>Apache for each Virtual Server??? Thats the difference between
>'multiple' and 'virtual'.<br>
><br>
> Just my experience with RT. I ended up discussing this with Jesse
>at length, and it would in fact cost money (in the order of $1000's) to
>have such a system to support multiple signatures and multiple queues
>and privleges within one database instance (which it must do to be
>considered 'virtual').<br>
><br>
>Cheers<br>
><br>
>Adrian<br>
><br>
><br>
>Laurent GAUTROT wrote:
><blockquote cite="mid200509251014.23746.l.gautrot at free.fr" type="cite">
> <blockquote type="cite">
> <pre wrap="">Jerry <a class="moz-txt-link-rfc2396E" href="mailto:Jerry at coc
>katoos.com"><Jerry at cockatoos.com></a> wrote :
>Is it possible to configure RT in such a way that one installation can
>be virtual for many domains, such as you might do for an ISP, with
>separate administrators and users for each domain?
> </pre>
> </blockquote>
> <pre wrap=""><!---->
>In fact, yes, it is.
>
>Maybe you should give this page a read :
>
><a class="moz-txt-link-freetext" href="http://wiki.bestpractical.com/index.cgi
>?MultipleInstances">http://wiki.bestpractical.com/index.cgi?MultipleInstances<
>/a>
>
> </pre>
> <blockquote type="cite">
> <pre wrap="">Alternatively, could it be configured that you could have sep
>arate
>administrators and users for hundreds or groups at one domain? Would
>these be queues? If so, can they be managed with conditional code, or
>does each one have to be setup at the mail server and/or other areas?
> </pre>
> </blockquote>
> <pre wrap=""><!---->
>With FastCGI you can have separate environments, so you can setup variables.
>
>By this mean, each RT site can have its own customisations.
>
>The databases are independant. Notice that if you use MySQL you should take
>care of the naming of the databases. « - » in database names will lead
>rt-setup-database to fail (only for MySQL).
>_______________________________________________
><a class="moz-txt-link-freetext" href="http://lists.bestpractical.com/cgi-bin/
>mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/list
>info/rt-users</a>
>
>Be sure to check out the RT Wiki at <a class="moz-txt-link-freetext" href="htt
>p://wiki.bestpractical.com">http://wiki.bestpractical.com</a>
>
>Buy your copy of our new book, RT Essentials, today!
>
>Download a free sample chapter from <a class="moz-txt-link-freetext" href="htt
>p://rtbook.bestpractical.com">http://rtbook.bestpractical.com</a>
>
>
> </pre>
></blockquote>
><br>
><pre class="moz-signature" cols="72">--
>Adrian Carter
>Technical Manager
>Leading Edge Internet
>
>Web <a class="moz-txt-link-freetext" href="http://www.lei.net.au">http://
>www.lei.net.au</a> <a class="moz-txt-link-freetext" href="http://support.lei.n
>et.au">http://support.lei.net.au</a>
>Direct +61 2 6163 6162 Support 1 300 662 415
>E-mail <a class="moz-txt-link-abbreviated" href="mailto:cartera at lei.net.au"
>>cartera at lei.net.au</a>
></pre>
></body>
></html>
>
>--------------050707070605030201040206--
>
>
>--===============1849822656==
>Content-Type: text/plain; charset="us-ascii"
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>_______________________________________________
>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
>Be sure to check out the RT Wiki at http://wiki.bestpractical.com
>
>Buy your copy of our new book, RT Essentials, today!
>
>Download a free sample chapter from http://rtbook.bestpractical.com
>--===============1849822656==--
>
More information about the rt-users
mailing list