date:20120214

Re: [otrs] strange performance problems migrating otrs from a server to another one

2012-02-14 Thread Luca Domenella

Hi Steve,

 

i will give a look , thanks !

 

yes, the /tmp point to disk, b ut on both server… same architecture…

 

I will let you know

 

Br,

Luca Domenella

T: +39 0698962316
E:  luca.domene...@bwinparty.com

bwin Italia
Via Adolfo Ravà, 124
00142 Roma (RM)

  www.bwinparty.com

 

This email and any attachments are confidential, and may be legally privileged 
and protected by copyright. If you are not the intended recipient dissemination 
or copying of this email is prohibited. If you have received this in error, 
please notify the sender by replying by email and then delete the email 
completely from your system. 

Any views or opinions are solely those of the sender. This communication is not 
intended to form a binding contract unless expressly indicated to the contrary 
and properly authorised. Any actions taken on the basis of this email are at 
the recipient's own risk.

 

From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Steven 
Carr
Sent: martedì 14 febbraio 2012 15:35
To: User questions and discussions about OTRS.
Subject: Re: [otrs] strange performance problems migrating otrs from a server 
to another one

 

Where does tmpdir point to on the production server? is that also pointing at 
/tmp which is on disk? and are the disk architectures the same type and same 
speed? It definitely sounds like a disk I/O issue.

What version of MySQL is the production server running? What happens if you use 
the same my.cnf without making any unnecessary changes to it? (tweaking memory 
parameters can cause all sorts of I/O upsets if they aren't balanced correctly 
- regardless of how much RAM you have).

Have a look at https://github.com/rackerhacker/MySQLTuner-perl - it's a perl 
script which will analyse your MySQL installation and give pointers for 
increased performance and stability.

Steve




On 14 February 2012 12:48, Luca Domenella  wrote:

Hi Steve,

 

i said i customized, but its similar to the production server i  just changed 
some values because it have the double of memory, and the server is the same 
type.

 

The tmpdir point to /tmp

 

>From os:

FilesystemSize  Used Avail Use% Mounted on

/dev/sda3 125G   41G   77G  35% /

/dev/sda1 190M   24M  157M  14% /boot

tmpfs 3.9G 0  3.9G   0% /dev/shm

 

 

br,

Luca Domenella

T: +39 0698962316  
E:  luca.domene...@bwinparty.com

bwin Italia
Via Adolfo Ravà, 124
00142 Roma (RM)

  www.bwinparty.com

 

This email and any attachments are confidential, and may be legally privileged 
and protected by copyright. If you are not the intended recipient dissemination 
or copying of this email is prohibited. If you have received this in error, 
please notify the sender by replying by email and then delete the email 
completely from your system. 

Any views or opinions are solely those of the sender. This communication is not 
intended to form a binding contract unless expressly indicated to the contrary 
and properly authorised. Any actions taken on the basis of this email are at 
the recipient's own risk.

 

From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Steven 
Carr
Sent: martedì 14 febbraio 2012 13:11
To: User questions and discussions about OTRS.
Subject: Re: [otrs] strange performance problems migrating otrs from a server 
to another one

 

You say you have customised the my.cnf configuration, how does that compare 
with the production server, and has the production server been optimised? if it 
has then there is no guarantee the optimised configuration will work the same 
on a different server. Where is the 'tmpdir' variable pointing to? is that 
on-disk filesystem or memory?

Are the spec's of the servers the same? for disk I/O what type of disks are the 
production servers using and what is the new server? SAS/SATA?

Steve



On 14 February 2012 11:18, Luca Domenella  wrote:

Hi all,

im doing a migration of the otrs database from a server to another one. When
performing the database test I’ve got strange result when running a query: 5
minutes versus the actual production server : 17secs.

What I did is:
1) Newly centos installed server 5.7
2) Install mysql 5.5.20 (stable release from dev.mysql.com)
3) Backup the db on production server using mysqldump
4) Restore using canonical way: mysql –uroot –p otrs < mysql.sql
5) Customized the my.cnf

Looks normal…

This is the query that on my production server took 17 secs:
SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM  ticket st, queue sq
, article at WHERE sq.id = st.queue_id AND st.id = at.ticket_id AND
sq.group_id IN (1, 3, 4) AND ( LOWER(at.a_body) LIKE LOWER('%58674056830%'))
ORDER BY st.create_time_unix DESC LIMIT000;

I have got this from mysql-slowquery.log on the production server… on this
new server tooks: Empty set (5 min 11.28 sec)

This is the output of show profile;
+++

Re: [otrs] Changing auth type from local to ldap for agents

2012-02-14 Thread Roy Kaldung

On Tue, 14 Feb 2012 08:11:43 -0500, Ugo Bellavance  wrote:
> Hi,
> 
> I'm using OTRS only internally, so I use ldap backend for clients, but 
> at first I didn't know if it would cause problem with agents so the auth

> for agent is local.
> 
> I have a few questions about the possible transition to ldap auth for 
> agents.
> 
> - Can an agent be a customer as well if using the same AD for auth?  Of 
> course, I guess that agents would be in an extra AD group compared to 
> the users.

Yes this is possible, use Kernel::System::Auth:LDAP for agents and
Kernel::System::CustomerAuth::LDAP for customer. You can also specifiy
multiple
ADs for customer.

 
> - Will I lose agent history or will I break something if I go with ldap 
> auth instead of local eventually? The usernames and e-mail addresses are

> the same.
I saved my history with the change from local to ldap agents. As far as
your login and
e-mail addresses still remain unchanged there shouldn't be a problem.


hth,
Roy

-- 
Roy Kaldung
e-mail: r...@kaldung.com
-
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] strange performance problems migrating otrs from a server to another one

2012-02-14 Thread Steven Carr

Where does tmpdir point to on the production server? is that also pointing
at /tmp which is on disk? and are the disk architectures the same type and
same speed? It definitely sounds like a disk I/O issue.

What version of MySQL is the production server running? What happens if you
use the same my.cnf without making any unnecessary changes to it? (tweaking
memory parameters can cause all sorts of I/O upsets if they aren't balanced
correctly - regardless of how much RAM you have).

Have a look at https://github.com/rackerhacker/MySQLTuner-perl - it's a
perl script which will analyse your MySQL installation and give pointers
for increased performance and stability.

Steve



On 14 February 2012 12:48, Luca Domenella wrote:

> Hi Steve,
>
> ** **
>
> i said i customized, but its similar to the production server i  just
> changed some values because it have the double of memory, and the server is
> the same type.
>
> ** **
>
> The tmpdir point to /tmp
>
> ** **
>
> From os:
>
> FilesystemSize  Used Avail Use% Mounted on
>
> /dev/sda3 125G   41G   77G  35% /
>
> /dev/sda1 190M   24M  157M  14% /boot
>
> tmpfs 3.9G 0  3.9G   0% /dev/shm
>
> ** **
>
> ** **
>
> br,**
>
> *Luca Domenella*
>
> T: +39 0698962316
> E:  luca.domene...@bwinparty.com
>
> *bwin Italia*
> Via Adolfo Ravà, 124
> 00142 Roma (RM)
>
> www.bwinparty.com
>
>  
>
> This email and any attachments are confidential, and may be legally
> privileged and protected by copyright. If you are not the intended
> recipient dissemination or copying of this email is prohibited. If you have
> received this in error, please notify the sender by replying by email and
> then delete the email completely from your system.
>
> Any views or opinions are solely those of the sender. This communication
> is not intended to form a binding contract unless expressly indicated to
> the contrary and properly authorised. Any actions taken on the basis of
> this email are at the recipient's own risk.
>
> ** **
>
> *From:* otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] *On Behalf
> Of *Steven Carr
> *Sent:* martedì 14 febbraio 2012 13:11
> *To:* User questions and discussions about OTRS.
> *Subject:* Re: [otrs] strange performance problems migrating otrs from a
> server to another one
>
> ** **
>
> You say you have customised the my.cnf configuration, how does that
> compare with the production server, and has the production server been
> optimised? if it has then there is no guarantee the optimised configuration
> will work the same on a different server. Where is the 'tmpdir' variable
> pointing to? is that on-disk filesystem or memory?
>
> Are the spec's of the servers the same? for disk I/O what type of disks
> are the production servers using and what is the new server? SAS/SATA?
>
> Steve
>
>
> 
>
> On 14 February 2012 11:18, Luca Domenella 
> wrote:
>
> Hi all,
>
> im doing a migration of the otrs database from a server to another one.
> When
> performing the database test I’ve got strange result when running a query:
> 5
> minutes versus the actual production server : 17secs.
>
> What I did is:
> 1) Newly centos installed server 5.7
> 2) Install mysql 5.5.20 (stable release from dev.mysql.com)
> 3) Backup the db on production server using mysqldump
> 4) Restore using canonical way: mysql –uroot –p otrs < mysql.sql
> 5) Customized the my.cnf
>
> Looks normal…
>
> This is the query that on my production server took 17 secs:
> SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM  ticket st, queue
> sq
> , article at WHERE sq.id = st.queue_id AND st.id = at.ticket_id AND
> sq.group_id IN (1, 3, 4) AND ( LOWER(at.a_body) LIKE
> LOWER('%58674056830%'))
> ORDER BY st.create_time_unix DESC LIMIT000;
>
> I have got this from mysql-slowquery.log on the production server… on this
> new server tooks: Empty set (5 min 11.28 sec)
>
> This is the output of show profile;
> +++
> | Status | Duration   |
> +++
> | starting   |   0.23 |
> | Waiting for query cache lock   |   0.04 |
> | checking query cache for query |   0.98 |
> | checking permissions   |   0.05 |
> | checking permissions   |   0.03 |
> | checking permissions   |   0.05 |
> | Opening tables |   0.31 |
> | System lock|   0.14 |
> | Waiting for query cache lock   |   0.30 |
> | init   |   0.58 |
> | optimizing |   0.17 |
> | statistics |   0.44 |
> | preparing  |   0.27 |
> | Creating tmp table |   0.37 |
> | executing  |   0.04 |
> | Copying to tmp table   | 311.316596 |
> | Sorting result |   0.24 |
> |

[otrs] Changing auth type from local to ldap for agents

2012-02-14 Thread Ugo Bellavance


Hi,

I'm using OTRS only internally, so I use ldap backend for clients, but 
at first I didn't know if it would cause problem with agents so the auth 
for agent is local.


I have a few questions about the possible transition to ldap auth for 
agents.


- Can an agent be a customer as well if using the same AD for auth?  Of 
course, I guess that agents would be in an extra AD group compared to 
the users.


- Will I lose agent history or will I break something if I go with ldap 
auth instead of local eventually? The usernames and e-mail addresses are 
the same.


Thanks,

Ugo

-
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] strange performance problems migrating otrs from a server to another one

2012-02-14 Thread Luca Domenella

Hi Steve,

 

i said i customized, but its similar to the production server i  just changed 
some values because it have the double of memory, and the server is the same 
type.

 

The tmpdir point to /tmp

 

>From os:

FilesystemSize  Used Avail Use% Mounted on

/dev/sda3 125G   41G   77G  35% /

/dev/sda1 190M   24M  157M  14% /boot

tmpfs 3.9G 0  3.9G   0% /dev/shm

 

 

br,

Luca Domenella

T: +39 0698962316
E:  luca.domene...@bwinparty.com

bwin Italia
Via Adolfo Ravà, 124
00142 Roma (RM)

  www.bwinparty.com

 

This email and any attachments are confidential, and may be legally privileged 
and protected by copyright. If you are not the intended recipient dissemination 
or copying of this email is prohibited. If you have received this in error, 
please notify the sender by replying by email and then delete the email 
completely from your system. 

Any views or opinions are solely those of the sender. This communication is not 
intended to form a binding contract unless expressly indicated to the contrary 
and properly authorised. Any actions taken on the basis of this email are at 
the recipient's own risk.

 

From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Steven 
Carr
Sent: martedì 14 febbraio 2012 13:11
To: User questions and discussions about OTRS.
Subject: Re: [otrs] strange performance problems migrating otrs from a server 
to another one

 

You say you have customised the my.cnf configuration, how does that compare 
with the production server, and has the production server been optimised? if it 
has then there is no guarantee the optimised configuration will work the same 
on a different server. Where is the 'tmpdir' variable pointing to? is that 
on-disk filesystem or memory?

Are the spec's of the servers the same? for disk I/O what type of disks are the 
production servers using and what is the new server? SAS/SATA?

Steve




On 14 February 2012 11:18, Luca Domenella  wrote:

Hi all,

im doing a migration of the otrs database from a server to another one. When
performing the database test I’ve got strange result when running a query: 5
minutes versus the actual production server : 17secs.

What I did is:
1) Newly centos installed server 5.7
2) Install mysql 5.5.20 (stable release from dev.mysql.com)
3) Backup the db on production server using mysqldump
4) Restore using canonical way: mysql –uroot –p otrs < mysql.sql
5) Customized the my.cnf

Looks normal…

This is the query that on my production server took 17 secs:
SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM  ticket st, queue sq
, article at WHERE sq.id = st.queue_id AND st.id = at.ticket_id AND
sq.group_id IN (1, 3, 4) AND ( LOWER(at.a_body) LIKE LOWER('%58674056830%'))
ORDER BY st.create_time_unix DESC LIMIT000;

I have got this from mysql-slowquery.log on the production server… on this
new server tooks: Empty set (5 min 11.28 sec)

This is the output of show profile;
+++
| Status | Duration   |
+++
| starting   |   0.23 |
| Waiting for query cache lock   |   0.04 |
| checking query cache for query |   0.98 |
| checking permissions   |   0.05 |
| checking permissions   |   0.03 |
| checking permissions   |   0.05 |
| Opening tables |   0.31 |
| System lock|   0.14 |
| Waiting for query cache lock   |   0.30 |
| init   |   0.58 |
| optimizing |   0.17 |
| statistics |   0.44 |
| preparing  |   0.27 |
| Creating tmp table |   0.37 |
| executing  |   0.04 |
| Copying to tmp table   | 311.316596 |
| Sorting result |   0.24 |
| Sending data   |   0.15 |
| end|   0.010888 |
| removing tmp table |   0.11 |
| end|   0.05 |
| query end  |   0.04 |
| closing tables |   0.17 |
| freeing items  |   0.18 |
| Waiting for query cache lock   |   0.03 |
| freeing items  |   0.000283 |
| Waiting for query cache lock   |   0.05 |
| freeing items  |   0.02 |
| storing result in query cache  |   0.05 |
| logging slow query |   0.03 |
| logging slow query |   0.000137 |
| cleaning up|   0.05 |
+++
32 rows in set (0.03 sec)


What comes to eyes is the copying to tmp table that take all the time… when
I runt this query I also took an iostat on the server (local disks) and the
disk is 90% used with few iostat % (something like 1-5%) and 5-7MB/s reads…

No

Re: [otrs] strange performance problems migrating otrs from a server to another one

2012-02-14 Thread Steven Carr

You say you have customised the my.cnf configuration, how does that compare
with the production server, and has the production server been optimised?
if it has then there is no guarantee the optimised configuration will work
the same on a different server. Where is the 'tmpdir' variable pointing to?
is that on-disk filesystem or memory?

Are the spec's of the servers the same? for disk I/O what type of disks are
the production servers using and what is the new server? SAS/SATA?

Steve



On 14 February 2012 11:18, Luca Domenella wrote:

> Hi all,
>
> im doing a migration of the otrs database from a server to another one.
> When
> performing the database test I’ve got strange result when running a query:
> 5
> minutes versus the actual production server : 17secs.
>
> What I did is:
> 1) Newly centos installed server 5.7
> 2) Install mysql 5.5.20 (stable release from dev.mysql.com)
> 3) Backup the db on production server using mysqldump
> 4) Restore using canonical way: mysql –uroot –p otrs < mysql.sql
> 5) Customized the my.cnf
>
> Looks normal…
>
> This is the query that on my production server took 17 secs:
> SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM  ticket st, queue
> sq
> , article at WHERE sq.id = st.queue_id AND st.id = at.ticket_id AND
> sq.group_id IN (1, 3, 4) AND ( LOWER(at.a_body) LIKE
> LOWER('%58674056830%'))
> ORDER BY st.create_time_unix DESC LIMIT000;
>
> I have got this from mysql-slowquery.log on the production server… on this
> new server tooks: Empty set (5 min 11.28 sec)
>
> This is the output of show profile;
> +++
> | Status | Duration   |
> +++
> | starting   |   0.23 |
> | Waiting for query cache lock   |   0.04 |
> | checking query cache for query |   0.98 |
> | checking permissions   |   0.05 |
> | checking permissions   |   0.03 |
> | checking permissions   |   0.05 |
> | Opening tables |   0.31 |
> | System lock|   0.14 |
> | Waiting for query cache lock   |   0.30 |
> | init   |   0.58 |
> | optimizing |   0.17 |
> | statistics |   0.44 |
> | preparing  |   0.27 |
> | Creating tmp table |   0.37 |
> | executing  |   0.04 |
> | Copying to tmp table   | 311.316596 |
> | Sorting result |   0.24 |
> | Sending data   |   0.15 |
> | end|   0.010888 |
> | removing tmp table |   0.11 |
> | end|   0.05 |
> | query end  |   0.04 |
> | closing tables |   0.17 |
> | freeing items  |   0.18 |
> | Waiting for query cache lock   |   0.03 |
> | freeing items  |   0.000283 |
> | Waiting for query cache lock   |   0.05 |
> | freeing items  |   0.02 |
> | storing result in query cache  |   0.05 |
> | logging slow query |   0.03 |
> | logging slow query |   0.000137 |
> | cleaning up|   0.05 |
> +++
> 32 rows in set (0.03 sec)
>
>
> What comes to eyes is the copying to tmp table that take all the time… when
> I runt this query I also took an iostat on the server (local disks) and the
> disk is 90% used with few iostat % (something like 1-5%) and 5-7MB/s reads…
>
> Now, on the production server I don’t have any kind of disk usage… looks
> like its all in memory…
>
> Can anyone help me on this performace issue ? I don’t know how to reproduce
> the performances of the production server on this new one.
>
> Best regards,
>
> Luca Domenella
> T: +39 0698962316
> E:  luca.domene...@bwinparty.com
> bwin Italia
> Via Adolfo Ravà, 124
> 00142 Roma (RM)
> www.bwinparty.com
>
> This email and any attachments are confidential, and may be legally
> privileged and protected by copyright. If you are not the intended
> recipient
> dissemination or copying of this email is prohibited. If you have received
> this in error, please notify the sender by replying by email and then
> delete
> the email completely from your system.
>
> Any views or opinions are solely those of the sender. This communication is
> not intended to form a binding contract unless expressly indicated to the
> contrary and properly authorised. Any actions taken on the basis of this
> email are at the recipient's own risk.
>
>
>
> -
> 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 l

[otrs] strange performance problems migrating otrs from a server to another one

2012-02-14 Thread Luca Domenella

Hi all,

im doing a migration of the otrs database from a server to another one. When
performing the database test Ive got strange result when running a query: 5
minutes versus the actual production server : 17secs.

What I did is:
1) Newly centos installed server 5.7
2) Install mysql 5.5.20 (stable release from dev.mysql.com)
3) Backup the db on production server using mysqldump
4) Restore using canonical way: mysql uroot p otrs < mysql.sql
5) Customized the my.cnf

Looks normal 

This is the query that on my production server took 17 secs:
SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM  ticket st, queue sq
, article at WHERE sq.id = st.queue_id AND st.id = at.ticket_id AND
sq.group_id IN (1, 3, 4) AND ( LOWER(at.a_body) LIKE LOWER('%58674056830%'))
ORDER BY st.create_time_unix DESC LIMIT000;

I have got this from mysql-slowquery.log on the production server on this
new server tooks: Empty set (5 min 11.28 sec)

This is the output of show profile;
+++
| Status | Duration   |
+++
| starting   |   0.23 |
| Waiting for query cache lock   |   0.04 |
| checking query cache for query |   0.98 |
| checking permissions   |   0.05 |
| checking permissions   |   0.03 |
| checking permissions   |   0.05 |
| Opening tables |   0.31 |
| System lock|   0.14 |
| Waiting for query cache lock   |   0.30 |
| init   |   0.58 |
| optimizing |   0.17 |
| statistics |   0.44 |
| preparing  |   0.27 |
| Creating tmp table |   0.37 |
| executing  |   0.04 |
| Copying to tmp table   | 311.316596 |
| Sorting result |   0.24 |
| Sending data   |   0.15 |
| end|   0.010888 |
| removing tmp table |   0.11 |
| end|   0.05 |
| query end  |   0.04 |
| closing tables |   0.17 |
| freeing items  |   0.18 |
| Waiting for query cache lock   |   0.03 |
| freeing items  |   0.000283 |
| Waiting for query cache lock   |   0.05 |
| freeing items  |   0.02 |
| storing result in query cache  |   0.05 |
| logging slow query |   0.03 |
| logging slow query |   0.000137 |
| cleaning up|   0.05 |
+++
32 rows in set (0.03 sec)


What comes to eyes is the copying to tmp table that take all the time when
I runt this query I also took an iostat on the server (local disks) and the
disk is 90% used with few iostat % (something like 1-5%) and 5-7MB/s reads

Now, on the production server I dont have any kind of disk usage looks
like its all in memory

Can anyone help me on this performace issue ? I dont know how to reproduce
the performances of the production server on this new one.

Best regards,

Luca Domenella
T: +39 0698962316
E:  luca.domene...@bwinparty.com
bwin Italia
Via Adolfo Ravà, 124
00142 Roma (RM)
www.bwinparty.com
 
This email and any attachments are confidential, and may be legally
privileged and protected by copyright. If you are not the intended recipient
dissemination or copying of this email is prohibited. If you have received
this in error, please notify the sender by replying by email and then delete
the email completely from your system. 

Any views or opinions are solely those of the sender. This communication is
not intended to form a binding contract unless expressly indicated to the
contrary and properly authorised. Any actions taken on the basis of this
email are at the recipient's own risk.




smime.p7s
Description: S/MIME cryptographic signature
-
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] Svar: Re: Diff between PendingDate and Due date?

2012-02-14 Thread Martin Møller

I will give it a go next chance I get.

It seemed to happen a lot in cronjobs.
It also seemed to happen, when I opened a ticket from the Dashbord or
Ticket overview (in which case I also got a 500 error, as far as I
recall).
As far as I can tell, the changes to the database should not be able to
cause the issue, so most likely it is somewhere in the code...

I will report back when I have tried these suggestions.

/Martin.

>>> James Michael DuPont  11. februar 2012 08:49
>>>
Hi there,
You could easily rename the installed version of YAML and then perl
will use your version.
If you cannot find the problem, please post a detailed bug report with
files that I can look at and I will try and reproduce the problem.
thanks,
mike

On Fri, Feb 10, 2012 at 10:18 AM, Michiel Beijen
 wrote:

Hi Martin,

2012/2/8 Martin Møller :
> On my original 2.4 system, the previous administrator have installed
YAML
> through CPAN in site_perl. This version is 0.70
>
> Now, with 3.1, you package YAML yourselves, and I guess that the
site_perl
> catalog is checked before cpan-lib, so it sees the old version of
YAML, not
> version 0.73 that OTRS delivers.
>
> Would it sound reasonable that an older version of YAML might choke
on
> certain things in OTRS 3.1? It is working correctly on 3.0.11, where
you
> don't distribute your own YAML:

You don't mention which kind of issues you are experiencing, so it
would be very difficult to tell whether or not YAML causes these. We
bundle some Perl modules in Kernel/cpan-lib for two reasons: you'll
have to install less dependencies if you will set up OTRS, and second,
we can control the version that OTRS uses; we do not need to bother
about distribution X shipping version 0.1 and distribution Y shipping
with version 0.9 of the same module; it gives us more control.

Apart from that, typically OTRS will always use the version in
Kernel/cpan-lib, even if you have installed a different version on
your system using CPAN, yum or apt-get. Also, the rest of your system
(everything else but OTRS) will not use these modules, so you will not
have to worry that OTRS will break the rest of your system by shipping
its own set of libraries.

So that's why I think it would be very unlikely that the YAML version
you installed via CPAN and the version you'll get with OTRS will
actually cause issues here. Of course, it *could* be that somewhere in
the OTRS code we don't properly check Kernel/cpan-lib before searching
the rest of the system, but again, that would be unlikely I think.

Also, the YAML code is only used in few places; for instance in saving
the configuration for the new OTRS web services. So if you can share
the error message you ran in to, maybe we can help you pin-point the
exact cause.
--
Mike
-
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

-- 
James Michael DuPont
Custom Engineering/Research & Development 
OTRS AG
Norsk-Data-Straße 1
D-61352 Bad Homburg

T: +49 (0) 9421 56818 0
F: +49 (0) 9421 56818 18
I: http://www.otrs.com/

Geschäftssitz: Bad Homburg, Amtsgericht Bad Homburg, HRB 10751,
USt-Nr.: DE256610065
Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André
Mindermann (Vorsitzender), Christopher Kuhn

-
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] strange performance problems migrating otrs from a server to another one

Re: [otrs] Changing auth type from local to ldap for agents

Re: [otrs] strange performance problems migrating otrs from a server to another one

[otrs] Changing auth type from local to ldap for agents

Re: [otrs] strange performance problems migrating otrs from a server to another one

Re: [otrs] strange performance problems migrating otrs from a server to another one

[otrs] strange performance problems migrating otrs from a server to another one

Re: [otrs] Svar: Re: Diff between PendingDate and Due date?

8 matches

Site Navigation

Mail list logo

Footer information