[rt-users] Virtual RT

Adrian Carter cartera at lei.net.au
Mon Sep 26 11:57:06 EDT 2005 

Bob Goldstein wrote:

>>   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.
>  
>
Yeah, I realised that, and I also realised I sounded a bit like a 
demanding person. I totally understand I have a bit of a unique 
proposal, hence why I went to the length of getting Jesse to have an 
engineer look at it commercially. I realise I could cobble it together 
using lots of nasty hacks, but the multiple signature bit but common 
tickets and better 'access' control is a bit of a major hack. Hence my 
attempts at getting the funds authorised! :) :)

To try and clarify, I would have one mysql database with common tickets. 
This also extends to a common RTFM, and for most Operators, (admins, 
which we will call 'Operators') global access to queus labelled as 
(XYZ_Support, XYZ_Admin, ABC_Support, ABC_Admin). They also require 
different signatures based on which queue they are responding to or 
creating a ticket in.. XYZ or ABC. If a ticket was to be 'migrated' to 
an alternative queue, previous history can remain the same but obviously 
new responses can utilise the appropriate signature. Then there is a 
subest of these operators, well call them SecondaryOperators. These guys 
have privlidged access only to XYZ_* or ABC_* independantly, but not 
both. They also need only their 'own' signature (just one). Then there 
is 'Users', who can access their own tickets, and only their own, 
regardless of what Queue it lives in. They also dont have any signature, 
as their tickets are created via e-mail and their access is designed 
soely for status checking and RTFM reference.

RTFM Articles can be referenced by any operators, and accessed by any user.

Logo's also change based on SecondaryOperators (XYZ see's XYZ logo, ABC 
see's ABC logo) but Operators need only see the 'primary' logo.

As stated, tickets would be 'global', so that searching for ticket 
contents could be done globally by Operators, but searches by 
SecondaryOperators was limited within XYZ or ABC queues.

Tickets would regularly probably 'escalate' and 'return' from XYZ or ABC 
to the Primary Queues (just called say, Admin and Support with no 
prefixes).

>   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==--
>>
>>    
>>
>_______________________________________________
>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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20050927/32b9ccd3/attachment.htm>

More information about the rt-users mailing list