<!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 thought it prudent to add, I have no problem that such
extensions cost money.. None at all.. I was just pointing out its not
even something on the 'free' horizons.... Im currently pestering the
'powers that are' to fork out the cash to achieve exactly what we want
:)))<br>
<br>
Maybe that would change if lots of people where to show cause to need
it, but so far, I think mine was one of the first times Jesse had had a
request for something truly 'virtual' that most people can't just solve
using Multiple Instances (I have an issue where I want to easily slide
tickets between ISPs as well as having a global RTFM and search
functions.... something that you can kind of work around using Subject
regex's but that doesn't solve teh RTFM and Search issues.. which only
a common database would solve....)<br>
<br>
Adrian Carter wrote:
<blockquote cite="mid43380215.20906@lei.net.au" type="cite">
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
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@free.fr" type="cite">
<blockquote type="cite">
<pre wrap="">Jerry <a class="moz-txt-link-rfc2396E"
href="mailto:Jerry@cockatoos.com"><Jerry@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 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?
</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/listinfo/rt-users</a>
Be sure to check out the RT Wiki at <a class="moz-txt-link-freetext"
href="http://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="http://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.net.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@lei.net.au">cartera@lei.net.au</a>
</pre>
<pre wrap=""><hr size="4" width="90%">
_______________________________________________
<a class="moz-txt-link-freetext"
href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a>
Be sure to check out the RT Wiki at <a class="moz-txt-link-freetext"
href="http://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="http://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.net.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@lei.net.au">cartera@lei.net.au</a>
</pre>
</body>
</html>