[otrs] Horrible performance problem
Hi all Hopefully some light can be shed on the problem we're experiencing - otrs is rapidly becoming unusable in our case (and we *really* don't want to abandon it). This is either a database/sql issue, or some other issue related to otrs. Scenario: agent has approx. 315 locked tickets, with 292-odd tickets in 'new messages' queue. Clicking on the 'locked tickets' queue (to display the tickets) results in a delay of 30-60 minutes... Opening a normal queue with 17 tickets results in a delay of about 45 seconds. So, quite a problem. The following is our setup: apache 1.3.31, mod_perl, mod_php, mod_* etc. Documented mod_perl/otrs setup was followed. Using Postgres 7.4.2. With Postgresql config: log_statement = true log_duration = true I see zillions of the following: SELECT sdt.name, sa.create_by, st.until_time FROM article_sen der_type sdt, article sa, ticket st WHERE st.id = 3604 AND sa.ticket_id = st.id AND sdt.id = sa.article_sender_type_id ORDER BY sa.create_time LOG: duration: 533.672 ms - 800ms SELECT sa.ticket_id, sa.a_from, sa.a_to, sa.a_cc, sa.a_subject, sa.a_reply_to, sa. a_message_id, sa.a_body, st.create_time_unix, t.ticket_state_id, st.queue_id, sa.create_time, sa.a_content_type, sa.create_by, st.tn, article_sender_type_id, st.customer_id, st.until_time, st.ticket_priority_id, st.customer_user_id, st.user_id, su.login, sa.article_type_id, sa.a_freekey1, sa.a_freetext1, sa.a_freekey2, sa.a_freetext2, sa.a_freekey3, sa.a_freetext3, st.ticket_answered, sa.incoming_time, sa.id, st.freekey1, st.freetext1, st.freekey2, st.freetext2, st.freekey3, st.freetext3, st.freekey4, st.freetext4, st.freekey5, st.freetext5, st.freekey6, st.freetext6, st.freekey7, st.freetext7, st.freekey8, st.freetext8 FROM article sa, ticket st, system_user su where sa.id = 44681 AND sa.ticket_id = st.id AND st.user_id = su.id ORDER BY sa.id ASC LOG: duration: 809.421 ms - 1000ms Is otrs performing single and seperate selects for every blimming ticket in the set in question? Tweaking PG parameters really has no impact on this. The server in question is reasonably busy, with lots of memory, a fast processor, etc. Load avg varies between .3 - 1.5. The same server handles bugzilla with stellar performance. What the hell am I missing here? I refuse to give up on otrs just yet. Any help would be appreciated. Henry This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R73. Free Web Accelerator, WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails, 100MB personal webspace, and more! Phone Now! 086 11 11 440 ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
[otrs] Help Regarding the OTRS
Hai Friends, I am very interesterd to learn the OTRS functionalities and desiging. Please some one help me in expline me OTRS functionalities, desiging, database design and database structures. Thanks and Regrads, Ramesh Kumar ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
[otrs] (no subject)
Hai Friends, I am Ramesh Kumar . I am very interested to Know about the OTRS database design and functional arch. Please help me in give me a detail explination. Thanks and Regrads, Ramesh Kumar ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
[otrs] Re: Horrible performance problem
* Henry Combrinck apache 1.3.31, mod_perl, mod_php, mod_* etc. Documented mod_perl/otrs setup was followed. Using Postgres 7.4.2. With Postgresql config: log_statement = true log_duration = true I see zillions of the following: SELECT sdt.name, sa.create_by, st.until_time FROM article_sen der_type sdt, article sa, ticket st WHERE st.id = 3604 AND sa.ticket_id = st.id AND sdt.id = sa.article_sender_type_id ORDER BY sa.create_time LOG: duration: 533.672 ms - 800ms This might not solve all your issues, but I'd suggest changing the types of the serial number columns so that your indexes actually come into play. You might want to ask postgres to explain its plan for the query above to confirm that this is a problem for you (EXPLAIN SELECT sdt.name...), but I'll bet it is. Se also the thread http://thread.gmane.org/gmane.comp.otrs.devel/530, where Robert Mathews outlines a way to change the type of these columns in-place. (He does this to harmonize the columns to bigint; I'd suggest going from bigint to conventional int.) Arne. ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
Re: [otrs] Re: Horrible performance problem
This might not solve all your issues, but I'd suggest changing the types of the serial number columns so that your indexes actually come into play. You might want to ask postgres to explain its plan for the query above to confirm that this is a problem for you (EXPLAIN SELECT sdt.name...), but I'll bet it is. Se also the thread http://thread.gmane.org/gmane.comp.otrs.devel/530, where Robert Mathews outlines a way to change the type of these columns in-place. (He does this to harmonize the columns to bigint; I'd suggest going from bigint to conventional int.) Thanks for the info Arne. Here's pg's explain output: Sort (cost=7132.87..7132.87 rows=1 width=3062) Sort Key: sa.id - Nested Loop (cost=1716.31..7132.86 rows=1 width=3062) Join Filter: (outer.ticket_id = inner.id) - Seq Scan on article sa (cost=0.00..5379.65 rows=2 width=1485) Filter: (id = 44681) - Materialize (cost=1716.31..1724.51 rows=820 width=1581) - Hash Join (cost=1.19..1716.31 rows=820 width=1581) Hash Cond: (outer.user_id = inner.id) - Seq Scan on ticket st (cost=0.00..1652.28 rows=10928 width=1513) - Hash (cost=1.15..1.15 rows=15 width=72) - Seq Scan on system_user su (cost=0.00..1.15 rows=15 width=72) It does appear to be using the index article_pkey (sa.id) unless I'm reading the above incorrectly... I'll give the other link (bigint-int) a try and see, but I doubt this will have a major impact on the problem. Henry This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R73. Free Web Accelerator, WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails, 100MB personal webspace, and more! Phone Now! 086 11 11 440 ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
Re: [otrs] Hex ticket numbers
Hi Martin, Martin Edenhofer wrote: Hi Frederik, On Tue, Jul 27, 2004 at 01:31:28AM +0200, Frederik Seiffert wrote: We're currently using the DateChecksum module to generate ticket numbers, but I always felt that the numbers are way too long. As I don't see any reason for the date or the checksum in the ticket number, I changed the Random module to generate random _hex_ numbers, 8 digits long (plus system ID). Before configuring our system to use the new module, I just wanted to ask if there are any potential problems here. I've written the GetTNByString sub to recognize old numbers generated by the DateChecksum module, as we want to change the module in a live system. If the GetTNByString() is also matching old ticket numbers, then it's no problem. I noticed that my GetTNByString() function in my last mail wouldn't match numbers from the DateChecksum module, because it matched the SystemID at the beginning of the ticket number. After removing this, all should work fine. PS: Nice module! :) Well, it's mostly based on your work from Random.pm. Feel free to use it or add it to your distribution. You may also remove my copyright at the top. -Frederik ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
[otrs] Re: Horrible performance problem
* Henry Combrinck It does appear to be using the index article_pkey (sa.id) unless I'm reading the above incorrectly... Well, no, it's doing sequential scans (Seq Scan) on both article and ticket, and you really want to avoid that. Here's what it would look like (modulo other local configuration issues that might influence the plan layout) if the indexes were used: Sort (cost=10.70..10.72 rows=7 width=26) Sort Key: sa.create_time - Nested Loop (cost=4.31..10.60 rows=7 width=26) - Index Scan using ticket_pkey on ticket st (cost=0.00..3.07 rows=1 width=8) Index Cond: (id = 3604) - Merge Join (cost=4.31..7.46 rows=7 width=26) Merge Cond: (outer.id = inner.article_sender_type_id) - Index Scan using article_sender_type_pkey on article_sender_type sdt (cost=0.00..3.03 rows=3 width=14) - Sort (cost=4.31..4.33 rows=7 width=18) Sort Key: sa.article_sender_type_id - Index Scan using article_ticket_id on article sa (cost=0.00..4.22 rows=7 width=18) Index Cond: (ticket_id = 3604) As you can se, even Postgres' theoretical cost is several orders of magnitude lower. (This is with 7k/28k tickets/articles however, it seems you've got a tad more tickets in your database.) I'll give the other link (bigint-int) a try and see, but I doubt this will have a major impact on the problem. I'll be surprised if you don't see a noticeable improvement, but there might of course be other issues as well. Remember to tell postgres to analyze. (Why this isn't done automatically is beyond me.) Arne. ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
Re: [otrs] Re: Horrible performance problem
* Henry Combrinck It does appear to be using the index article_pkey (sa.id) unless I'm reading the above incorrectly... Well, no, it's doing sequential scans (Seq Scan) on both article and ticket, and you really want to avoid that. Here's what it would look like (modulo other local configuration issues that might influence the plan layout) if the indexes were used: aah, crap, you're right! I had no idea pg7.4 ignored indexes if the types weren't *exactly* the same. system_user.id is integer... crikey, will need to monitor this and see what other tables are buggered. thanks for the pointers. Regards Henry This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R73. Free Web Accelerator, WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails, 100MB personal webspace, and more! Phone Now! 086 11 11 440 ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
Re: [otrs] Hex ticket numbers
Hi Frederik, On Thu, Jul 29, 2004 at 12:33:06PM +0200, Frederik Seiffert wrote: Before configuring our system to use the new module, I just wanted to ask if there are any potential problems here. I've written the GetTNByString sub to recognize old numbers generated by the DateChecksum module, as we want to change the module in a live system. If the GetTNByString() is also matching old ticket numbers, then it's no problem. I noticed that my GetTNByString() function in my last mail wouldn't match numbers from the DateChecksum module, because it matched the SystemID at the beginning of the ticket number. After removing this, all should work fine. Oh. Sorry. So if GetTNByString() isn't matching the old foramt, the no email follow up for tickets with old ticket numbers is possible. PS: Nice module! :) Well, it's mostly based on your work from Random.pm. Feel free to use it or add it to your distribution. You may also remove my copyright at the top. Thanks for it Frederik. But I'm not sure what better is. We want to open a http://modules.otrs.org/ section. So (IMO) it would be a very good module for that! :) Would be greate if could put it on there. :) -Frederik Martin -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication! ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
Re: [otrs] Active Directory as customer backend
Has anyone been able to configure OTRS to use Windows 2003 Active Directory as the customer backend? If so, are there any quick and dirty guides? The install documents reference using LDAP as the backend, but I'm not quite sure how AD == LDAP mappings would look. See the cvs version of the docs, the following chapter 11 is about AD integration: http://doc.otrs.org/cvs/en/html/ldap-integration.html hth, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388 ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
Re: [otrs] Help Regarding the OTRS
Hello, I am Ramesh Kumar . I am very interested to Know about the OTRS database design and functional arch. Please help me in give me a detail explination. I hope you can get enough information about OTRS Starting from Installation upto the Troubleshooting and more!!! from the Manual..use this Link. http://doc.otrs.org/1.2/en/html/ With Best Regards! Kamal ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
[otrs] Patch for OTRS not using References header
Martin, Attached is a patch for making OTRS use the email headers to choose the TicketNumber. When the patch is applied, PostMaster looks for the TicketNumber in the subject [as it used to]. If the TicketNumber is not found, it will look at the References and In-Reply-To headers and try to lookup the TicketNumber for those headers. Would appreciate it if you can take a look at it give some feedback. Reading: http://www.jwz.org/doc/threading.html http://search.cpan.org/src/SIMON/Mail-Thread-2.5/Thread.pm Warning: The Article table is not indexed on a_message_id. The lookup for ticketnumber given the message-id could be expensive. Right now we dont have too many entries in the DB. So it seems to behave fine. Food for thought: o The alternative strategy I was thinking was that the message id is composed by otrs as [EMAIL PROTECTED]. Maybe we can use this information to get the ticket number. If no OTRS generated message IDs are found in the message headers, then we can look at the current brute force algo. o Using the headers instead of Subject should probably go into the Config.pm? Martin Edenhofer wrote: Hi Rajiv, On Wed, Jul 28, 2004 at 07:06:41AM +, Rajiv wrote: This is probably right out of the FAQ, but I couldnt find it there. I am trying to get OTRS use the References email header to thread messages. As far as I can see, it seems to be using the Ticket number in the Subject line to thread the messages. Is there some configuration change required to enable header based threading instead of subject based threading? Thanks in advance for any pointers you can provide! There is currently just the subject based threading in ticket zoom possible. Sorry. Martin Edenhofer PostMaster.pm.patch Description: Binary data ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
[otrs] Re: Horrible performance problem
* Henry Combrinck using a cast on the literal number: where sa.id = 44681::bigint AND sa.ticket_id= st.id AND st.user_id = su.id yields a far better result: Sort (cost=16.34..16.34 rows=3 width=2928) Sort Key: sa.id - Hash Join (cost=1.19..16.31 rows=3 width=2928) Hash Cond: (outer.user_id = inner.id) - Nested Loop (cost=0.00..15.08 rows=3 width=2917) - Index Scan using article_pkey on article sa (cost=0.00..3.04 rows=2 width=1624) Index Cond: (id = 44681::bigint) - Index Scan using ticket_pkey on ticket st (cost=0.00..6.01 rows=1 width=1301) Index Cond: (outer.ticket_id = st.id) - Hash (cost=1.15..1.15 rows=15 width=15) - Seq Scan on system_user su (cost=0.00..1.15 rows=15 width=15) It seems Postgres 7.4.2 is able to use indexes when comparing two columns of type int/bigint; but not under all circumstances: testdb= \d foo Table public.foo Column | Type | Modifiers +-+--- a | integer | Indexes: foo_a btree (a) testdb= \d bar Table public.bar Column | Type | Modifiers ++--- a | bigint | Indexes: bar_a btree (a) testdb= explain select * from foo, bar where foo.a = bar.a; QUERY PLAN --- Nested Loop (cost=0.00..301630.10 rows=9732096 width=12) Join Filter: (inner.a = outer.a) - Index Scan using bar_a on bar (cost=0.00..61.85 rows=3168 width=8) - Index Scan using foo_a on foo (cost=0.00..56.79 rows=3072 width=4) (4 rows) testdb= explain select * from foo, bar where foo.a = bar.a and bar.a = 2; QUERY PLAN - Nested Loop (cost=1.00..10057.62 rows=1 width=12) - Index Scan using foo_a on foo (cost=0.00..2.01 rows=1 width=4) Index Cond: (2 = a) - Seq Scan on bar (cost=1.00..10055.60 rows=1 width=8) Filter: (a = 2) (5 rows) testdb= explain select * from foo, bar where foo.a = bar.a and bar.a = int8(2); QUERY PLAN - Nested Loop (cost=1.00..10054.42 rows=1 width=12) - Seq Scan on foo (cost=1.00..10052.40 rows=1 width=4) Filter: (2::bigint = a) - Index Scan using bar_a on bar (cost=0.00..2.01 rows=1 width=8) Index Cond: (a = 2::bigint) (5 rows) testdb= explain select * from foo, bar where foo.a = int4(bar.a) and bar.a = int8(2); QUERY PLAN - Merge Join (cost=2.02..74.35 rows=16 width=12) Merge Cond: (outer.?column2? = inner.a) - Sort (cost=2.02..2.03 rows=1 width=8) Sort Key: int4(bar.a) - Index Scan using bar_a on bar (cost=0.00..2.01 rows=1 width=8) Index Cond: (a = 2::bigint) - Index Scan using foo_a on foo (cost=0.00..56.79 rows=3072 width=4) (7 rows) testdb= If one of the terms in the int/bigint clause is also compared to a literal somewhere else, this apparently also affects the way the first clause is being planned. Not always to good effect, it would seem. To get back on topic: in my view the root of the problem is the int4 literals, and I don't see any good way of getting around that which doesn't involve a lot of changes all over the OTRS code base. In addition, just casting literals to bigint all over is not going to be a good solution, since much of the code is supposed to be sql-dialect- neutral. I still think the easy (and correct, but that's perhaps more subjective) way out is to convert bigint to int all over the Postgres schema. Arne. ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
Re: [otrs] Re: Horrible performance problem
* Henry Combrinck
You don't have a nice little alter...table(s) script you can paste
herein,
do you? ;-)
I think Robert Mathews' snippet should work, but I havent tested it
myself. If I generalize his code a bit, to change column bar in
table foo to int4, something like this would be required:
BEGIN;
LOCK TABLE foo;
ALTER TABLE foo ADD COLUMN new_col int;
UPDATE foo SET new_col = bar;
ALTER TABLE foo DROP COLUMN bar;
ALTER TABLE foo RENAME COLUMN new_col TO bar;
ALTER TABLE foo ADD PRIMARY KEY (bar);
ALTER TABLE foo ALTER COLUMN bar SET DEFAULT
nextval('foo_bar_seq'::text);
COMMIT;
ANALYZE;
The exact contents of nextval(...) should probably be copied from
\d foo beforehand.
Keep your backups handy, and if you have the luxury to do so, try it
on your test systems first...
Yup - that would work; too much work though.
My 600MB dump has just finished. I'm going to dump the schema seperately
and replace all bigint's with int, and restore.
This message was sent using MetroWEB's AirMail service.
http://www.metroweb.co.za/ - full access for only R73.
Free Web Accelerator, WebMail, Calendar, Anti-Virus,
Anti-Spam, 10 emails, 100MB personal webspace, and more!
Phone Now! 086 11 11 440
___
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
Support oder Consulting für Ihr OTRS System?
= http://www.otrs.de/
Re: [otrs] Re: Horrible performance problem
Yup - that would work; too much work though. My 600MB dump has just finished. I'm going to dump the schema seperately and replace all bigint's with int, and restore. To play it safe, I also replaced all smallint's with int - stuff it. Performance is now as it should be. Instead of 45 MINUTES, the queue now (a queue of 250+ tickets) displays in 10-15 seconds. Even merely closing tickets is faster now (3s instead of almost a minute). This thread should give other postgres/otrs users hope! Henry This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R73. Free Web Accelerator, WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails, 100MB personal webspace, and more! Phone Now! 086 11 11 440 ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
[otrs] 'owner' problem
Hi, question is - if a customer sends a reply to the ticket, it automatically goes to the original owner, but nobody else knows such mail has arrived. So is it possible to set some timeout - if the owner doesn't answer this email in a certain amount of time, then the message loses the owner. I hope i expressed myself clearly. Any idea ? N. ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
Re: [otrs] (no subject)
Hai Friends, I am Ramesh Kumar . I am very interested to Know about the OTRS database design and functional arch. Please help me in give me a detail explination. I am desperately trying not to sound rude but did you ever bother to RTFM or even better look at the actual database itself? If you are not comfortable analyzing the database from command promt, just do a search for frontends on sourceforge or freshmeat. You will find good tools that'll do all the work for you. --Turi ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
RE: [otrs] Can't Access AdminArea
I haven't recieved any replies back from you since sending that bitmap of my
groups table. Did you recieve the e-mail that was zipped and had the
group.bmp inside? I was hoping you could help me by taking a look at this
and comparing it to what is supposed to be in the groups table. I wasn't
sure what to compare it with in the initial_insert.sql file. Let me know if
you want me to resend that bitmap.
Finally, if I have to revert to old settings can I just revert to the old
groups/users? What does the backup restore? What would you recommend trying
to get my old settings back?
thanks
marshall
-Original Message-
From: Marshall28 [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 27, 2004 1:51 PM
To: User questions and discussions about OTRS.
Subject: RE: [otrs] Can't Access AdminArea
Here is the error I get when trying to add root as admin:
ticket:/opt/otrs/bin # ./otrs.addUser2Group root admin
GID 2
UID 1
Use of uninitialized value in concatenation (.) or string at
/opt/otrs/Kernel/System/Log.pm line 134.
ERROR: otrs.addUser2Group-10 Perl: 5.8.1 OS: linux Time: Tue Jul 27 13:58:45
2004
Message: Need Permission!
Traceback (2728):
Module: Kernel::System::Group::GroupMemberAdd (v1.19) Line: 130
Module: ./otrs.addUser2Group (v) Line: 72
I'm not sure if I renamed any groups. Could I find this out through
phpmyadmin. If so what table do I look under and what groups should I verify
are named correctly?
thanks
marshall
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Robert Kehl
Sent: Tuesday, July 27, 2004 1:03 PM
To: User questions and discussions about OTRS.
Subject: RE: [otrs] Can't Access AdminArea
It's logging to /opt/otrs/otrs.log. But there is no otrs.log file.
That's not possible, because OTRS needs to be able to log. It will
certainly yike if it can't.
Can it be that you've got this in Config.pm?
$Self-{LogModule} = 'Kernel::System::Log::SysLog';
$Self-{LogModule::LogFile} = 'OTRS_HOME/otrs.log';
In the above case, there is a log file specified, but logging nonetheless
would got to syslog.
In terms
of backup I do an rsync 4 times a day to another hard drive stored on the
machine as well as running the backup.sh script which has been doing daily
backups since 06-10-04. We don't have a lot of tickets on our system and
haven't had any today.
So, you're best prepared to step back to a previous version. Good.
Running the otrs.adduser2group script will add the
root user back into the admin group, correct? How damaging can that be?
I guess it won't do a thing to the situation, just try.
You may additionally think about having a look at the raw db with a tool
like phpMyAdmin or similar.
Did you eventually rename some groups?
Regards,
Robert Kehl
--
((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg
http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
___
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
Support oder Consulting für Ihr OTRS System?
= http://www.otrs.de/
___
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
Support oder Consulting für Ihr OTRS System?
= http://www.otrs.de/
RE: [otrs] Can't Access AdminArea
I haven't recieved any replies back from you since sending that bitmap of
my
groups table. Did you recieve the e-mail that was zipped and had the
group.bmp inside?
I do not receive any zips due to the recent virii storms, sorry.
Additionally, please send such attachements to me via PM only when asked
for it. Thank you.
I was hoping you could help me by taking a look at this
and comparing it to what is supposed to be in the groups table. I wasn't
sure what to compare it with in the initial_insert.sql file. Let me know
if you want me to resend that bitmap.
No, sorry. Don't get me wrong, but we'd get into personal support then.
This is the appropriate part from initial_insert.sql.
-- groups
INSERT INTO groups
(name, valid_id, create_by, create_time, change_by, change_time)
VALUES
('users', 1, 1, current_timestamp, 1, current_timestamp);
INSERT INTO groups
(name, valid_id, create_by, create_time, change_by, change_time)
VALUES
('admin', 1, 1, current_timestamp, 1, current_timestamp);
INSERT INTO groups
(name, valid_id, create_by, create_time, change_by, change_time)
VALUES
('stats', 1, 1, current_timestamp, 1, current_timestamp);
INSERT INTO groups
(name, valid_id, create_by, create_time, change_by, change_time)
VALUES
('faq', 1, 1, current_timestamp, 1, current_timestamp);
In your case, you have to be sure to have the group with ID 2.
Finally, if I have to revert to old settings can I just revert to the old
groups/users? What does the backup restore? What would you recommend
trying to get my old settings back?
To get you to work again, you could try restoring a backup of the time it
was working, if you cannot repair the installation.
With kind regards,
Robert Kehl
--
((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg
http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
___
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
Support oder Consulting für Ihr OTRS System?
= http://www.otrs.de/
RE: [otrs] Can't Access AdminArea
Thanks a lot man. I finally figured it out. I realized that the admin groups
valid_id was set on 2 not 1. Once I changed this I recieved the Admin access
back again. I really appreciate all your help and the willingness you have
to help. I do have another question for you. How is the escalation time
triggered on a ticket? At what point is it reset? Is this when an agent
zooms in on the ticket or if they just view the small details of the ticket?
Where is the reset point for escalation on a ticket?
thanks
marshall
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Robert Kehl
Sent: Thursday, July 29, 2004 9:46 AM
To: [EMAIL PROTECTED]
Subject: RE: [otrs] Can't Access AdminArea
I haven't recieved any replies back from you since sending that bitmap of
my
groups table. Did you recieve the e-mail that was zipped and had the
group.bmp inside?
I do not receive any zips due to the recent virii storms, sorry.
Additionally, please send such attachements to me via PM only when asked
for it. Thank you.
I was hoping you could help me by taking a look at this
and comparing it to what is supposed to be in the groups table. I wasn't
sure what to compare it with in the initial_insert.sql file. Let me know
if you want me to resend that bitmap.
No, sorry. Don't get me wrong, but we'd get into personal support then.
This is the appropriate part from initial_insert.sql.
-- groups
INSERT INTO groups
(name, valid_id, create_by, create_time, change_by, change_time)
VALUES
('users', 1, 1, current_timestamp, 1, current_timestamp);
INSERT INTO groups
(name, valid_id, create_by, create_time, change_by, change_time)
VALUES
('admin', 1, 1, current_timestamp, 1, current_timestamp);
INSERT INTO groups
(name, valid_id, create_by, create_time, change_by, change_time)
VALUES
('stats', 1, 1, current_timestamp, 1, current_timestamp);
INSERT INTO groups
(name, valid_id, create_by, create_time, change_by, change_time)
VALUES
('faq', 1, 1, current_timestamp, 1, current_timestamp);
In your case, you have to be sure to have the group with ID 2.
Finally, if I have to revert to old settings can I just revert to the old
groups/users? What does the backup restore? What would you recommend
trying to get my old settings back?
To get you to work again, you could try restoring a backup of the time it
was working, if you cannot repair the installation.
With kind regards,
Robert Kehl
--
((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg
http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
___
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
Support oder Consulting für Ihr OTRS System?
= http://www.otrs.de/
___
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
Support oder Consulting für Ihr OTRS System?
= http://www.otrs.de/
RE: [otrs] Can't Access AdminArea
Thanks a lot man. I finally figured it out. I realized that the admin groups valid_id was set on 2 not 1. Once I changed this I recieved the Admin access back again. I really appreciate all your help and the willingness you have to help. You're welcome, glad to hear it's working again! I do have another question for you. It's always best to start a new thread for new questions. This way users not intwerested in this thread get notice of your new question. How is the escalation time triggered on a ticket? At what point is it reset? Is this when an agent zooms in on the ticket or if they just view the small details of the ticket? Where is the reset point for escalation on a ticket? A ticket escalates if it's unlocked and not answered and the escalation time duration is over the specified value. Please do search on this lists archives, you'll find more info there. With kind regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388 ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
RE: [otrs] Can't Access AdminArea
So basically if the ticket is locked and someone owns it then it will never escalate? This is rough because sometimes an agent will claim a ticket and may not address the ticket till far after the escalation time. But since there's an owner the ticket remains stale with no escalation? thanks marshall -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Robert Kehl Sent: Thursday, July 29, 2004 10:38 AM To: [EMAIL PROTECTED] Subject: RE: [otrs] Can't Access AdminArea Thanks a lot man. I finally figured it out. I realized that the admin groups valid_id was set on 2 not 1. Once I changed this I recieved the Admin access back again. I really appreciate all your help and the willingness you have to help. You're welcome, glad to hear it's working again! I do have another question for you. It's always best to start a new thread for new questions. This way users not intwerested in this thread get notice of your new question. How is the escalation time triggered on a ticket? At what point is it reset? Is this when an agent zooms in on the ticket or if they just view the small details of the ticket? Where is the reset point for escalation on a ticket? A ticket escalates if it's unlocked and not answered and the escalation time duration is over the specified value. Please do search on this lists archives, you'll find more info there. With kind regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388 ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/ ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
RE: [otrs] Can't Access AdminArea
So basically if the ticket is locked and someone owns it then it will never escalate? This is rough because sometimes an agent will claim a ticket and may not address the ticket till far after the escalation time. But since there's an owner the ticket remains stale with no escalation? That's why we invented the 'unlock time' feature. The lazy bones of your agents will notive that they cannot lock the ticket forever if you set the unlock time to something higher than 0. You do so for each queue(!) separately. With kind regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388 ___ 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 Support oder Consulting für Ihr OTRS System? = http://www.otrs.de/
[otrs-de] Wie funktioniert das genau mit den TicketFreeText Feldern?
Gibt es irgendeine andere Lösung, damit man in der Telefonansicht genauere Kundendaten aufnehmen kann, sodaß diese dann auch wie bei einem registrierten Kunden bei der Betrachtung eines Tickets rechts am Bildschirm sichtbar sind? Grüße Caroline -- NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler! GMX DSL = supergünstig kabellos http://www.gmx.net/de/go/dsl ___ OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? = http://www.otrs.de/
