Hi,
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?
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?
Many thanks, Jerry
Hi,
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?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?Many thanks, Jerry
You could use one source install with many databases and FastCGI.
-Todd
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).
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.
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 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@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 :
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).
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@lei.net.au
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 :)))
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…)
Adrian Carter wrote:
I just wanted to add something regarding my interpretations here. Yes, you can run Multiple Instances, *BUT*, and this is aBIIIIIGGGGGG but… Its NOT Virtual.
Virtual infers you can run a common and SINGLE backend (ala sayApache) yet had numerous complete and independant configurations that
all interact with that same common backend (just like tags
inside that Apache config).Now, configuring FastCGI and setting lots of instances withslightly 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 completlyseperately 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 ofApache for each Virtual Server??? Thats the difference between
‘multiple’ and ‘virtual’.Just my experience with RT. I ended up discussing this with Jesseat 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:
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 :
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).
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 InternetWeb http://www.lei.net.au http://support.lei.net.au
Direct +61 2 6163 6162 Support 1 300 662 415
E-mail cartera@lei.net.au
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@lei.net.au
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
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.bobgVirtual 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 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:
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 :
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).
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 InternetWeb http://www.lei.net.au http://support.lei.net.au
Direct +61 2 6163 6162 Support 1 300 662 415
E-mail cartera@lei.net.au--------------050707070605030201040206
I just wanted to add something regarding my interpretations here.
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Yes, you can run Multiple Instances, *BUT*, and this is a *BIIIIIGGGGGG* but... Its *NOT* Virtual.
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@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 :
Request Tracker Wiki<
/a>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?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/list
info/rt-usersBe 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 InternetWeb http://
www.lei.net.au http://support.lei.net.au
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
--------------050707070605030201040206–
–===============1849822656==
Content-Type: text/plain; charset=“us-ascii”
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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==–
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@lei.net.au
Many thanks for your response. What I was getting at was utilizing a single
DB for multiple Request instances, as opposed to apache instances. I was
thinking along the lines of a membership view where groups of members could
have their own “queue” I guess you would call it, and it could be managed
reasonably. I am thinking like a list server I am familiar with (lyris)
where any number of lists can be associated with a user and various domains
and email addresses can be used to manage the lists. When a list owner logs
in they see their lists, unique global and list configurations, etcetera.
List (queue) delivery is handled by the list application and not by the MTA.
That sort of thing. It looks like you have addressed all of this and more.
Jerry.From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Adrian Carter
Sent: Monday, September 26, 2005 8:57 AM
To: Bob Goldstein; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Virtual RT
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).