Re: [otrs] Need to set customers/agents's auth witn LDAP.

[Israel Garcia]

>>

>> From the manual, I see I have to add all these lines to get agents and
>> customers authenticating with ldap (AD), but not sure if we have to add it
>> to /opt/otrs/Kernel/Config.pm or /opt/otrs/Kernel/Config/Default.pm? Or in
>> other place.

>/opt/otrs/Kernel/Config.pm - your settings/overrides go in here
>/opt/otrs/Kernel/Config/Default.pm - you should not modify this config
>file *at all*

OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings, 
restart OTRS and volia!?
Also, I have seen in Admin/SysConfig/Frontend::Customer::Auth the same 
parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them using 
this web page or editing directly the /opt/otrs/Kernel/Config.pm  file?

Thaanks!

Regards,
Israel.-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[Steven Carr]

On 8 February 2013 13:05, Israel Garcia  wrote:
> OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings,
> restart OTRS and volia!?
> Also, I have seen in Admin/SysConfig/Frontend::Customer::Auth the same
> parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them
> using this web page or editing directly the /opt/otrs/Kernel/Config.pm
> file?

Don't quite know about the "voila", more like cross your fingers and
hope it doesn't collapse in a heap.

One of my big issues with OTRS is the configuration is utter crap. Too
many places to configure things, everything should really be just
configured through Sysconfig instead of having to mess about with text
files (and perl based text files at that), and ideally stored in the
database to make upgrades a lot easier than worrying about which
config files you need and don't need.

I'm not sure the order in which the settings are applied but I would
guess that anything you put in Kernel/Config.pm will override anything
you configure in SysConfig (someone can correct me if I'm wrong).

So just make your changes in one place and one place only and they
will be added to the overall config.

Steve
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[Vadim S. Goncharov]

On 08.02.2013 17:21, Steven Carr wrote:

On 8 February 2013 13:05, Israel Garcia  wrote:

OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings,
restart OTRS and volia!?
Also, I have seen in Admin/SysConfig/Frontend::Customer::Auth the same
parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them
using this web page or editing directly the /opt/otrs/Kernel/Config.pm
file?


Don't quite know about the "voila", more like cross your fingers and
hope it doesn't collapse in a heap.

One of my big issues with OTRS is the configuration is utter crap. Too


There are many places in OTRS which are crappy. E.g. different conflicting 
notification systems (see e.g. bug #8953), and, on-topic, customer groups. 
We have group attibute in LDAP for customers, and simple intuitive and 
SCALABLE solution would be just use that word of customer to regulate 
access. But "My Company tickets" in OTRS requires comma-delimited list of 
"user1,user2,...user100500" for EVERY user. Brain-damaged.



many places to configure things, everything should really be just
configured through Sysconfig instead of having to mess about with text
files (and perl based text files at that), and ideally stored in the
database to make upgrades a lot easier than worrying about which
config files you need and don't need.

I'm not sure the order in which the settings are applied but I would
guess that anything you put in Kernel/Config.pm will override anything
you configure in SysConfig (someone can correct me if I'm wrong).


Yes. Actually, Config.pm is applied TWO times: before SysConfig, and once 
again after.



So just make your changes in one place and one place only and they
will be added to the overall config.


That's not always possible :)

--
Vadim GoncharovRU-Center
NET Departmenthttp://www.nic.ru
NET-SYS Group phone:+7(495)737-7646  (ext.4019)
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[Gerald Young]

"My Company Tickets"  -- everyone who needs them should have the same
CustomerId.
http://forums.otterhub.org/viewtopic.php?f=60&t=7531

For instance: Everyone in a department has the same CustomerId.
Multi-department managers have a CustomerIds of depta,deptb,deptc.
Done.

With regard to the conflicting notification systems, you did that to
yourself. Or, more accurately, your corporate policy did that to you.

"We need the following behaviour: when one agent replies something to
customer

in a ticket via Web-interface - that is, 'SendAnswer' via
'AgentTicketCompose'
page - then all agents subscribed to this queue must receive mail
notification
with that text"

Really? That's not OTRS fault. Who does that? You might as well yell at
Microsoft because distribution group members don't receive emails sent by
one of the distribution group member to someone who's not a distribution
group member. Speaking of -- that is the solution to your problem. Create
an email distribution group for each of the queues and cc or bcc that
queue's distribution group when sending the Answer.

It won't stop doubling, though. Turn off notifications in agent preferences.



On Fri, Feb 8, 2013 at 9:03 AM, Vadim S. Goncharov wrote:

> On 08.02.2013 17:21, Steven Carr wrote:
>
>> On 8 February 2013 13:05, Israel Garcia  wrote:
>>
>>> OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP
>>> settings,
>>> restart OTRS and volia!?
>>> Also, I have seen in Admin/SysConfig/Frontend::**Customer::Auth the same
>>> parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them
>>> using this web page or editing directly the /opt/otrs/Kernel/Config.pm
>>> file?
>>>
>>
>> Don't quite know about the "voila", more like cross your fingers and
>> hope it doesn't collapse in a heap.
>>
>> One of my big issues with OTRS is the configuration is utter crap. Too
>>
>
> There are many places in OTRS which are crappy. E.g. different conflicting
> notification systems (see e.g. bug #8953), and, on-topic, customer groups.
> We have group attibute in LDAP for customers, and simple intuitive and
> SCALABLE solution would be just use that word of customer to regulate
> access. But "My Company tickets" in OTRS requires comma-delimited list of
> "user1,user2,...user100500" for EVERY user. Brain-damaged.
>
>
>  many places to configure things, everything should really be just
>> configured through Sysconfig instead of having to mess about with text
>> files (and perl based text files at that), and ideally stored in the
>> database to make upgrades a lot easier than worrying about which
>> config files you need and don't need.
>>
>> I'm not sure the order in which the settings are applied but I would
>> guess that anything you put in Kernel/Config.pm will override anything
>> you configure in SysConfig (someone can correct me if I'm wrong).
>>
>
> Yes. Actually, Config.pm is applied TWO times: before SysConfig, and once
> again after.
>
>
>  So just make your changes in one place and one place only and they
>> will be added to the overall config.
>>
>
> That's not always possible :)
>
> --
> Vadim GoncharovRU-Center
> NET Departmenthttp://www.nic.ru
> NET-SYS Group phone:+7(495)737-7646  (ext.4019)
>
> --**--**-
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: 
> http://lists.otrs.org/**pipermail/otrs
> To unsubscribe: 
> http://lists.otrs.org/cgi-bin/**listinfo/otrs
>
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[Israel Garcia]

OK.. Thanks!!





 De: Gerald Young 
Para: User questions and discussions about OTRS.  
Enviado: Viernes 8 de febrero de 2013 15:20
Asunto: Re: [otrs] Need to set customers/agents's auth witn LDAP.
 

"My Company Tickets"  -- everyone who needs them should have the same 
CustomerId. 
http://forums.otterhub.org/viewtopic.php?f=60&t=7531


For instance: Everyone in a department has the same CustomerId. 
Multi-department managers have a CustomerIds of depta,deptb,deptc.
Done.

With regard to the conflicting notification systems, you did that to yourself. 
Or, more accurately, your corporate policy did that to you.
"We need the following behaviour: when one agent replies something to customer

in a ticket via Web-interface - that is, 'SendAnswer' via 'AgentTicketCompose'
page - then all agents subscribed to this queue must receive mail notification
with that text"

Really? That's not OTRS fault. Who does that? You might as well yell at 
Microsoft because distribution group members don't receive emails sent by one 
of the distribution group member to someone who's not a distribution group 
member. Speaking of -- that is the solution to your problem. Create an email 
distribution group for each of the queues and cc or bcc that queue's 
distribution group when sending the Answer.

It won't stop doubling, though. Turn off notifications in agent preferences.




On Fri, Feb 8, 2013 at 9:03 AM, Vadim S. Goncharov  wrote:

On 08.02.2013 17:21, Steven Carr wrote:
>
>On 8 February 2013 13:05, Israel Garcia  wrote:
>>
>>OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings,
>>>restart OTRS and volia!?
>>>Also, I have seen in Admin/SysConfig/Frontend::Customer::Auth the same
>>>parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them
>>>using this web page or editing directly the /opt/otrs/Kernel/Config.pm
>>>file?
>>>
>>Don't quite know about the "voila", more like cross your fingers and
>>hope it doesn't collapse in a heap.
>>
>>One of my big issues with OTRS is the configuration is utter crap. Too
>>
>
There are many places in OTRS which are crappy. E.g. different conflicting 
notification systems (see e.g. bug #8953), and, on-topic, customer groups. We 
have group attibute in LDAP for customers, and simple intuitive and SCALABLE 
solution would be just use that word of customer to regulate access. But "My 
Company tickets" in OTRS requires comma-delimited list of 
"user1,user2,...user100500" for EVERY user. Brain-damaged.
>
>
>
>many places to configure things, everything should really be just
>>configured through Sysconfig instead of having to mess about with text
>>files (and perl based text files at that), and ideally stored in the
>>database to make upgrades a lot easier than worrying about which
>>config files you need and don't need.
>>
>>I'm not sure the order in which the settings are applied but I would
>>guess that anything you put in Kernel/Config.pm will override anything
>>you configure in SysConfig (someone can correct me if I'm wrong).
>>
>
Yes. Actually, Config.pm is applied TWO times: before SysConfig, and once again 
after.
>
>
>
>So just make your changes in one place and one place only and they
>>will be added to the overall config.
>>
>
That's not always possible :)
>
>-- 
>Vadim Goncharov                RU-Center
>NET Department                            http://www.nic.ru
>NET-SYS Group             phone:+7(495)737-7646  (ext.4019)
>
>-
>OTRS mailing list: otrs - Webpage: http://otrs.org/
>Archive: http://lists.otrs.org/pipermail/otrs
>To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>

-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[David Boyes]

> One of my big issues with OTRS is the configuration is utter crap. Too many
> places to configure things, everything should really be just configured
> through Sysconfig instead of having to mess about with text files (and perl
> based text files at that), and ideally stored in the database to make upgrades
> a lot easier than worrying about which config files you need and don't need.

Amen, brother. 

Software this complex needs to have settings in one, migrateable place with 
clear exit points for customized processing of those settings. The database is 
the only logical place for that information to live. 

-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[Gerald Young]

>The database is the only logical place for that information to live
Static connection information? Maybe not. Configuration? ... I'd be
inclined to concur. The problem with the database method with a table based
data source is the freeform data. Move it to something non-sql, like
perhaps ldap or other NoSQL, and this should be much better handled as
desired.


On Fri, Feb 8, 2013 at 10:29 AM, David Boyes  wrote:

> > One of my big issues with OTRS is the configuration is utter crap. Too
> many
> > places to configure things, everything should really be just configured
> > through Sysconfig instead of having to mess about with text files (and
> perl
> > based text files at that), and ideally stored in the database to make
> upgrades
> > a lot easier than worrying about which config files you need and don't
> need.
>
> Amen, brother.
>
> Software this complex needs to have settings in one, migrateable place
> with clear exit points for customized processing of those settings. The
> database is the only logical place for that information to live.
>
> -
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

[otrs] I have lost otrs crontab..pls help!

[Israel Garcia]

Hi again, 

Sorry if I'm writing continue to the list, but I have realiza that for an 
unknow reason user otrs have not crontab. How can I recover this file? I have 
not yet a backup installed.Can any send me the /var/spool/cron/otrs file?

Thanks much!!!
Apreciate your help..

Regards,
Israel.
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] I have lost otrs crontab..pls help!

[Gerald Young]

otrs crontab comes from running
bin/Cron.sh start otrs
it concatenates all files in var/cron/* that do not have .dist appended.




On Fri, Feb 8, 2013 at 11:01 AM, Israel Garcia  wrote:

> Hi again,
>
> Sorry if I'm writing continue to the list, but I have realiza that for an
> unknow reason user otrs have not crontab. How can I recover this file? I
> have not yet a backup installed.Can any send me the /var/spool/cron/otrs
> file?
>
> Thanks much!!!
> Apreciate your help..
>
> Regards,
> Israel.
>
> -
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] I have lost otrs crontab..pls help!

[Israel Garcia]

nice!!

Thanks tons





 De: Carlos Andrés Gallego Arboleda 
Para: Israel Garcia ; User questions and discussions about 
OTRS.  
Enviado: Viernes 8 de febrero de 2013 17:11
Asunto: Re: [otrs] I have lost otrs crontab..pls help!
 

Hi

You can use this.

cd /opt/otrs/var/cron
for foo in *.dist; do cp $foo `basename $foo .dist`; done 
cd /opt/otrs
bin/Cron.sh start otrs

From OTRS WIKI 
http://wiki.otterhub.org/index.php?title=Installation_on_Ubuntu_Lucid_Lynx_(10.4)

2013/2/8 Israel Garcia 

Hi again, 
>
>Sorry if I'm writing continue to the list, but I have realiza that for an 
>unknow reason user otrs have not crontab. How can I recover this file? I have 
>not yet a backup installed.Can any send me the /var/spool/cron/otrs file?
>
>Thanks much!!!
>Apreciate your help..
>
>Regards,
>Israel.
>-
>OTRS mailing list: otrs - Webpage: http://otrs.org/
>Archive: http://lists.otrs.org/pipermail/otrs
>To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[Steven Carr]

On 8 February 2013 15:55, Gerald Young  wrote:
>>The database is the only logical place for that information to live
> Static connection information? Maybe not. Configuration? ... I'd be inclined
> to concur. The problem with the database method with a table based data
> source is the freeform data. Move it to something non-sql, like perhaps ldap
> or other NoSQL, and this should be much better handled as desired.

Yes I agree that there does need to be a level of configuration that
needs to be maintained like database for the initial connection, but
other than that I don't really care what is used as the backend
storage for the config. They can continue to use flat files, but it
must be a single location: db, single file or folder (containing live
config and live config only, no other random backup or crap files)
that can be picked up and dropped into another system to make upgrades
"easier".

I've fallen into the pit of despair in v2.x by customising OTRS
heavily then spend 3 months trying to upgrade it and fix the previous
customisation, so now with v3 I tend to stick with "stock" OTRS, but
even then it's still a right PITA to upgrade as it's so intertwined
with the data and config that it consumed, no clear boundary.

Steve
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[David Boyes]

Actually, it's not that bad.

At the most basic level, you can treat the static info as an array of text 
lines and read/interpret them sequentially. That at least doesn't bind the 
information to a file on a specific server and gives you much more granular 
control of configuration management on operating systems that have essentially 
only two privilege levels (root/non-root).

As an interim step on that clustered OTRS system I mentioned in another thread, 
we've stored the config files in git and modified the OTRS startup script to 
check out the configuration files from the git server based on the node id at 
startup and a "current configuration" tag. The basic principle is sound (and 
you get very detailed configuration control) - it wouldn't be too hard to 
migrate to storing the static info in a table.

Where do you see the big problems?

From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Gerald 
Young
Sent: Friday, February 08, 2013 10:56 AM
To: User questions and discussions about OTRS.
Subject: Re: [otrs] Need to set customers/agents's auth witn LDAP.

>The database is the only logical place for that information to live
Static connection information? Maybe not. Configuration? ... I'd be inclined to 
concur. The problem with the database method with a table based data source is 
the freeform data. Move it to something non-sql, like perhaps ldap or other 
NoSQL, and this should be much better handled as desired.
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Resetting a Dynamic Field when Escalation Update timer resets

[Praneeth Katru]

Can somebody help me on this, I really need this.

 

Praneeth Katru

 

 

From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of
Praneeth Katru
Sent: Thursday, February 07, 2013 7:39 PM
To: otrs@otrs.org
Subject: [otrs] Resetting a Dynamic Field when Escalation Update timer
resets

 

Hello,

 

I have created a Dynamic Field for managing multiple escalation levels which
is working fine. 

 

But I want to change its value to a preset value whenever escalation update
timer is reset. How can this be accomplished?

 

Thanks

Praneeth Katru

-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[Steve Clark]

On 02/08/2013 11:22 AM, Steven Carr wrote:

On 8 February 2013 15:55, Gerald Young  wrote:

The database is the only logical place for that information to live

Static connection information? Maybe not. Configuration? ... I'd be inclined
to concur. The problem with the database method with a table based data
source is the freeform data. Move it to something non-sql, like perhaps ldap
or other NoSQL, and this should be much better handled as desired.

Yes I agree that there does need to be a level of configuration that
needs to be maintained like database for the initial connection, but
other than that I don't really care what is used as the backend
storage for the config. They can continue to use flat files, but it
must be a single location: db, single file or folder (containing live
config and live config only, no other random backup or crap files)
that can be picked up and dropped into another system to make upgrades
"easier".

I've fallen into the pit of despair in v2.x by customising OTRS
heavily then spend 3 months trying to upgrade it and fix the previous
customisation, so now with v3 I tend to stick with "stock" OTRS, but
even then it's still a right PITA to upgrade as it's so intertwined
with the data and config that it consumed, no clear boundary.

Steve


It is a real problem that some config data is in both places. States for 
instance are defined
in the database but are also in Sysconfig based on the "text" of the state. So 
you can
change the state "new" to "New" and now suddenly when you go to create a ticket
since the default state in Sysconfig is "new" things break.

--
Stephen Clark

-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Resetting a Dynamic Field when Escalation Update timer resets

[David Boyes]

Can somebody help me on this, I really need this.

You should probably look into a paid support contract with a vendor if you have 
time-critical requirements for responses. This is a volunteer forum, and 
there's no guarantees.  You also just posted your note yesterday, so you might 
want to give people time to even have *read* it, let alone think about good 
answers.

What have you tried so far?
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[Steven Carr]

On 8 February 2013 16:37, David Boyes  wrote:
> Actually, it’s not that bad.
>
> At the most basic level, you can treat the static info as an array of text
> lines and read/interpret them sequentially. That at least doesn’t bind the
> information to a file on a specific server and gives you much more granular
> control of configuration management on operating systems that have
> essentially only two privilege levels (root/non-root).
>
> As an interim step on that clustered OTRS system I mentioned in another
> thread, we’ve stored the config files in git and modified the OTRS startup
> script to check out the configuration files from the git server based on the
> node id at startup and a “current configuration” tag. The basic principle is
> sound (and you get very detailed configuration control) – it wouldn’t be too
> hard to migrate to storing the static info in a table.
>
> Where do you see the big problems?

With all due respect David your system is highly customised and you
must have the people power (or skills) to maintain your custom setup.
I don't want to have to do any of that custom piece, and more to the
point I shouldn't have to do that.

I want OTRS to focus on putting an enterprise/more
manageable/maintainable slant on things, rather than it still feeling
very much like a pet project that needs constant nurturing. And yes
there is the argument that it is "free"/open source so take it or
leave it, but even the paid version doesn't really offer any
advantages other than 101 unnecessary add-ons and someone on the end
of a phone to answer questions, and I'm technically competent enough
not to need to pay someone for that.

Since the change of hands it's beginning to feel very much like a
closed application they just happen to release the code to, the
community development side of the project has gone leaving very little
ability to request/influence development.

Steve
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[David Boyes]

> -Original Message-
> From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of
> Steven Carr
> Sent: Friday, February 08, 2013 12:48 PM
> To: User questions and discussions about OTRS.
> Subject: Re: [otrs] Need to set customers/agents's auth witn LDAP.
> 
> On 8 February 2013 16:37, David Boyes  wrote:
> > Actually, it’s not that bad.
> >
> > At the most basic level, you can treat the static info as an array of
> > text lines and read/interpret them sequentially. That at least doesn’t
> > bind the information to a file on a specific server and gives you much
> > more granular control of configuration management on operating systems
> > that have essentially only two privilege levels (root/non-root).
> >
> > As an interim step on that clustered OTRS system I mentioned in
> > another thread, we’ve stored the config files in git and modified the
> > OTRS startup script to check out the configuration files from the git
> > server based on the node id at startup and a “current configuration”
> > tag. The basic principle is sound (and you get very detailed
> > configuration control) – it wouldn’t be too hard to migrate to storing the
> static info in a table.
> >
> > Where do you see the big problems?
> 
> With all due respect David your system is highly customised and you must
> have the people power (or skills) to maintain your custom setup.
> I don't want to have to do any of that custom piece, and more to the point I
> shouldn't have to do that.
> 
> I want OTRS to focus on putting an enterprise/more
> manageable/maintainable slant on things, rather than it still feeling very
> much like a pet project that needs constant nurturing. And yes there is the
> argument that it is "free"/open source so take it or leave it, but even the 
> paid
> version doesn't really offer any advantages other than 101 unnecessary add-
> ons and someone on the end of a phone to answer questions, and I'm
> technically competent enough not to need to pay someone for that.
> 
> Since the change of hands it's beginning to feel very much like a closed
> application they just happen to release the code to, the community
> development side of the project has gone leaving very little ability to
> request/influence development.
> 
> Steve
> -
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Need to set customers/agents's auth witn LDAP.

[David Boyes]

> On 8 February 2013 16:37, David Boyes  wrote:
> > Actually, it’s not that bad.
> With all due respect David your system is highly customised and you must
> have the people power (or skills) to maintain your custom setup.
> I don't want to have to do any of that custom piece, and more to the point I
> shouldn't have to do that.

I think you misinterpreted my reply. I was replying to Gerard's note on the 
difficulty level of storing connection info with the "not that bad" comment to 
illustrate that a solution like we're discussing wouldn't be that hard to 
implement. I'm totally with you on the "we shouldn't have to invent hacks like 
this" -- that idea with git is a workaround, and for enterprise-grade 
infrastructure such as OTRS purports to be, hacks like that shouldn't be 
necessary. We're not breaking new ground here; most of what we're discussing 
has long ago been done in other tools, and there's little excuse for not 
learning from the past. (I'm coming from a mainframe background, so the fact we 
have to do any of this HA stuff at the application level continues to amaze -- 
the mainframe world had this kind of basic system integrity stuff in 1982 for 
*everything*, not just single apps inventing it as they go along. ) 

I tossed out the git idea as one way we worked around the problem. It's fugly, 
but it does work as a stopgap solution. There is some unavoidable formalism 
that it assumes in terms of administrative practice, but nothing that you 
wouldn't expect from good practice where downtime has a substantial price 
attached to it. We built it on git precisely because we didn't have to invent 
the management of the configuration versioning, and we used it elsewhere, and 
it didn't require modifying OTRS beyond a simple init script change, which is 
easily managed (in fact, if I were doing it now, I'd pull that step out of the 
OTRS init script and put it into a new script with appropriate dependencies). 
It shouldn't be necessary, but it lets us cope with the problem without 
rewriting the universe.

There are a lot of things I'd like to see added for HA and system resilience in 
OTRS. Matter of time and resources, I'd say. It probably would be a good idea 
to discuss it here, and help them define some requirements for what a really 
resilient enterprise OTRS system would look like. 

My "starter" list would be: 

1) tolerate/exploit clustered database engines
2) explicit interaction with load balancing solutions (start with LVS, move on 
to the hardware solutions later)
3) rationalization of configuration data
4) management of configuration data
5) work on lock management in the database (there are a lot of places where a 
table-level lock is used by default that could be much more efficiently use 
row-level locks)
6) More work on index definition for high-use tables
7) Allow explicit use of different database extent storage pools in the 
database scripts to tune data placement (indexes on SSD, data on slower disk, 
for example).
8) More formal work on the SOAP interface. XML-RPC only goes so far. 
9) a instrumentation interface to determine how well the application is 
performing (per-request timing, transaction overhead would be a good start)

-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Multiple Customers on a ticket?

[Atom Powers]

During a service interruption we often have many people reporting the
same problem, each creating a ticket. Is there a way to merge the
tickets in such a way that every customer will still receive replies and
updates to the ticket? This would make it easier for our agents to
manage communication about the interruption.

From what I can see, the current behaviour is that when you merge
tickets only the customer of the ticket you merged into receives messages.

--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--
Director of IT
DigiPen Institute of Technology
+1 (425) 895-4443
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs