March 2004 - otrs-de - OTRS mailing lists

Re: Umlaut-Probleme bei LDAP-Anfrage Folgefehler
by Jonas Wendland 17 Mar '04

17 Mar '04

Hallo Robert, wir benutzen hier den IE 6... Quellcodedarstellung mit folgenden Einstellungen: SourceCharset => 'utf-8', DestCharset => 'iso-8859-1', # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP) Params => { port => 389, timeout => 120, async => 0, version => 3, }, $Self->{DefaultLanguage} = 'de'; $Self->{DefaultCharset} = 'utf-8'; ------------------------------------------------------------------------------------------------------ Kundensuche nach 'lüdtke': ...... <table border="0" width="100%"> <tr> <td width="20%">Von:</td> <td width="60%"><input type="text" name="From" value=""Andreas Lüdtke " <Andreas.Luedtke(a)eplus.de>" size="70"> <font color="red" size="-2"></font><br> [ <a href="" onclick="document.compose.ExpandCustomerName.value='1'; document.compose.submit(); return false;" onmouseout="window.status='';" onmouseover="window.status='Kunden suchen'; return true;">Kunden suchen</a> ] [ <a href="javascript:clear_field();" onmouseout="window.status='';" onmouseover="window.status='Von: löschen'; return true;">Von: löschen</a> ] </td> <td width="20%" rowspan="10" valign="top"> <p align="left"><b>Kunden-Info</b>:<br><table><tr><td><b>Vorname:</b></td><td><div title="Andreas Lüdtke">Andreas Lüdtke</div></td></tr><tr><td><b>Nachname:</b></td><td><div title="Lüdtke">Lüdtke</div></td> ..... --------------------------------------------------------------------------------------------------- Nach Zuweisung einer Queue: ...... <tr> <td width="20%">Von:</td> <td width="60%"><input type="text" name="From" value=""Andreas Lüdtke " <Andreas.Luedtke(a)eplus.de>" size="70"> <font color="red" size="-2"></font><br> [ <a href="" onclick="document.compose.ExpandCustomerName.value='1'; document.compose.submit(); return false;" onmouseout="window.status='';" onmouseover="window.status='Kunden suchen'; return true;">Kunden suchen</a> ] [ <a href="javascript:clear_field();" onmouseout="window.status='';" onmouseover="window.status='Von: löschen'; return true;">Von: löschen</a> ] </td> <td width="20%" rowspan="10" valign="top"> <p align="left"><b>Kunden-Info</b>:<br><table><tr><td><b>Vorname:</b></td><td><div title="Andreas LÃ¼dtke">Andreas LÃ¼dtke</div></td></tr><tr><td><b>Nachname:</b></td><td><div title="LÃ¼dtke">LÃ¼dtke</div></td></tr> ..... Gruß Jonas

2 1

Antwort: Re: Umlaut-Probleme bei LDAP-Anfrage Folgefehler
by Jonas Wendland 17 Mar '04

17 Mar '04

$Self->{DefaultCharset} = 'iso-8859-1'; sollte das natürlich heißen... copy-paste - Meister werd ich wohl nicht werden... :-) Gruß Jonas

1 0

Antwort: Re: Umlaut-Probleme bei LDAP-Anfrage Folgefehler
by Jonas Wendland 17 Mar '04

17 Mar '04

Nachtrag: Diese Einstellung hier unten liefert gar kein Ergebnis vom LDAP-Server, selbst wenn ich ohne Umlaute frage. Auch nicht wenn ich SourceCharset und DestCharset zusätzlich auskommentiere. *verwirr* Viele Gruesse Jonas >$Self->{DefaultCharset} = 'utf-8'; >$Self->{CustomerUser} = {># [...] # ># SourceCharset => 'utf-8', ># DestCharset => 'utf-8', ># [...] # >}, Jonas Wendland An: otrs-de(a)otrs.org 17.03.2004 13:33 Kopie: Thema: Re: Umlaut-Probleme bei LDAP-Anfrage Folgefehler(Document link: Jonas Wendland) Hallo Robert, ja, diese Einstellungen funktionieren alle, wenn ich auf 'Kunden suchen' klicke und dann ertstmalig ein Ergebnis angezeigt bekomme. Und dann wirds eben 'komisch'. Und irgendwie weiß ich auch gar nicht mehr so richtig weiter. wir haben hier auch schon ein wenig OTRS-Code analysiert, aber das ist gar nicht so einfach, wenn mans nicht selber gebastelt hat. Nun fasse ich mal zusammen, was mich so verwundert: Wenn die unten beschriebenen Konfigurationen prinzipiell dazu führen, das unser Notes-LDAP antwortet und sogar bei der ersten Antwort Umlaute als Umlaute liefert, warum werden die Umlaute nach Queue-Zuweisung und damit verbundenem Fensterneuaufbau im Browser fehlinterpretiert. Entweder unser LDAP liefert richtig oder nicht. Halbrichtig kann doch nicht an der Konfiguration des LDAP-Servers liegen. Wir haben herausgefunden, dass eine Parameter 'ExpandCustomerUserName' in den beiden Fällen (Erstabfrage und Queue-Wechsel) mit unterschiedlichen Werten (1,3) belegt wird. Dies führt zu einer unterschiedlichen Suche nach Kundendaten. Unser Latein war hier jedoch am Ende. Aber vielleicht fällt den 'Machern' dazu noch was ein... Umlauthassend Gruest Jonas >Diese Einstellungen sollten funktionieren: ># $Self->{DefaultCharset} = 'iso-8859-15'; # iso-8859-15 ist default >$Self->{CustomerUser} = { ># [...] # >SourceCharset => 'utf-8', >DestCharset => 'iso-8859-15', ># [...] # >}, >ODER: >$Self->{DefaultCharset} = 'utf-8'; >$Self->{CustomerUser} = {># [...] # ># SourceCharset => 'utf-8', ># DestCharset => 'utf-8', ># [...] # >}, >Für iso-8859-1: >$Self->{DefaultCharset} = 'iso-8859-1'; >$Self->{CustomerUser} = { ># [...] # >SourceCharset => 'utf-8', >DestCharset => 'iso-8859-1', ># [...] #

1 0

Re: Umlaut-Probleme bei LDAP-Anfrage Folgefehler
by Jonas Wendland 17 Mar '04

17 Mar '04

Hallo Robert, ja, diese Einstellungen funktionieren alle, wenn ich auf 'Kunden suchen' klicke und dann ertstmalig ein Ergebnis angezeigt bekomme. Und dann wirds eben 'komisch'. Und irgendwie weiß ich auch gar nicht mehr so richtig weiter. wir haben hier auch schon ein wenig OTRS-Code analysiert, aber das ist gar nicht so einfach, wenn mans nicht selber gebastelt hat. Nun fasse ich mal zusammen, was mich so verwundert: Wenn die unten beschriebenen Konfigurationen prinzipiell dazu führen, das unser Notes-LDAP antwortet und sogar bei der ersten Antwort Umlaute als Umlaute liefert, warum werden die Umlaute nach Queue-Zuweisung und damit verbundenem Fensterneuaufbau im Browser fehlinterpretiert. Entweder unser LDAP liefert richtig oder nicht. Halbrichtig kann doch nicht an der Konfiguration des LDAP-Servers liegen. Wir haben herausgefunden, dass eine Parameter 'ExpandCustomerUserName' in den beiden Fällen (Erstabfrage und Queue-Wechsel) mit unterschiedlichen Werten (1,3) belegt wird. Dies führt zu einer unterschiedlichen Suche nach Kundendaten. Unser Latein war hier jedoch am Ende. Aber vielleicht fällt den 'Machern' dazu noch was ein... Umlauthassend Gruest Jonas >Diese Einstellungen sollten funktionieren: ># $Self->{DefaultCharset} = 'iso-8859-15'; # iso-8859-15 ist default >$Self->{CustomerUser} = { ># [...] # >SourceCharset => 'utf-8', >DestCharset => 'iso-8859-15', ># [...] # >}, >ODER: >$Self->{DefaultCharset} = 'utf-8'; >$Self->{CustomerUser} = {># [...] # ># SourceCharset => 'utf-8', ># DestCharset => 'utf-8', ># [...] # >}, >Für iso-8859-1: >$Self->{DefaultCharset} = 'iso-8859-1'; >$Self->{CustomerUser} = { ># [...] # >SourceCharset => 'utf-8', >DestCharset => 'iso-8859-1', ># [...] #

2 1

AW: [otrs-de]apache-httpd.include.conf:Perlrequire...-->ComilationFailed, AgentBounce
by Maibaum, Volker 17 Mar '04

17 Mar '04

Hallo, Ich habe gerade die apache-perl-startup.pl verändert (folgendes auskommentiert): #use DBI (); #use DBD::mysql (); #use Kernel::System::DB; ... danach lässt sich apache ohne Fehler starten. Wenn ich bei DBD::mysql (), oder DBI () den Kommentar entferne bekomme ich wieder einen Segmentation fault. Liegt es eventuell daran, dass ich folgende Packages selbst kompiliert habe? perl-Msql-Mysql-modules-1.2219-153.s390x.rpm perl-Data-ShowTable-3.3-372.s390x.rpm Wenn ja, hat jemand vielleicht einen Tipp, was ich beim Kompilieren beachten muss, damit das nicht passiert? Ich hoffe ich nerve nicht langsam mit meinen Problemen... Grüßle, Volker -----Ursprüngliche Nachricht----- Von: Maibaum, Volker Gesendet: Mittwoch, 17. März 2004 08:26 An: User questions and discussions about OTRS in German. Betreff: AW: [otrs-de]apache-httpd.include.conf:Perlrequire...-->ComilationFailed,Age ntBounce Hallo, zunächst vielen Dank für die schnellen und ausführlichen Antworten!! >welche Version hat Deine /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm? $VERSION = "2.20"; >> perl -w bin/CheckDB.pl >> linuxmnt:~/ >> ---------------- >Da sollte erscheinen "It looks Ok!" - tut es das wirklich nicht? Steht da auch, ich hab's leider abgeschnitten, sorry. Ich habe gerade auf einem zweiten Linux-Gast mal nachgeschaut, was dort für eine Version von /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm installiert ist. Komischerweise ist diese Datei dort nicht vorhanden - OTRS, läuft dort allerdings (mal abgesehen von den Performance-Problemen) einwandfrei. Ich vermute, dass die Format.pm mit den Suse Servicepacks (2+3) hinzugekommen sind, die sind auf dem zweiten Linux-Gast nicht installiert. Ich habe dort nun mal in der apache-httpd.include.conf das Perlrequire eingeschaltet und dort taucht das beschriebene Problem nicht mehr auf! :-) Leider taucht gleichzeitig ein neues auf :-( und zwar folgendes: ------------ otrs:/usr/lib/perl5/site_perl/5.8.0 # rcapache start Starting httpd [ Mailman PERL PHP4 Python ]/usr/sbin/rcapache: line 206: 8997 Segmentation fault $HTTPD_BIN $INET6 -t -f /etc/httpd/httpd.conf $MODULES >/var/log/httpd/rcapache.log 2>&1 Syntax OK failed ------------ Gibt es dafür eine Lösung? (Zeile 206 in rcapache ist das Ende einer case Anweisung "esac") Das sieht nicht nach einem OTRS-Problem aus... Grüßle aus dem sonnigen Baden Würtemberg, Volker _______________________________________________ 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/

2 1

AW: [otrs-de]apache-httpd.include.conf:Perlrequire...-->ComilationFailed, AgentBounce
by Maibaum, Volker 17 Mar '04

17 Mar '04

Hallo, zunächst vielen Dank für die schnellen und ausführlichen Antworten!! >welche Version hat Deine /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm? $VERSION = "2.20"; >> perl -w bin/CheckDB.pl >> linuxmnt:~/ >> ---------------- >Da sollte erscheinen "It looks Ok!" - tut es das wirklich nicht? Steht da auch, ich hab's leider abgeschnitten, sorry. Ich habe gerade auf einem zweiten Linux-Gast mal nachgeschaut, was dort für eine Version von /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm installiert ist. Komischerweise ist diese Datei dort nicht vorhanden - OTRS, läuft dort allerdings (mal abgesehen von den Performance-Problemen) einwandfrei. Ich vermute, dass die Format.pm mit den Suse Servicepacks (2+3) hinzugekommen sind, die sind auf dem zweiten Linux-Gast nicht installiert. Ich habe dort nun mal in der apache-httpd.include.conf das Perlrequire eingeschaltet und dort taucht das beschriebene Problem nicht mehr auf! :-) Leider taucht gleichzeitig ein neues auf :-( und zwar folgendes: ------------ otrs:/usr/lib/perl5/site_perl/5.8.0 # rcapache start Starting httpd [ Mailman PERL PHP4 Python ]/usr/sbin/rcapache: line 206: 8997 Segmentation fault $HTTPD_BIN $INET6 -t -f /etc/httpd/httpd.conf $MODULES >/var/log/httpd/rcapache.log 2>&1 Syntax OK failed ------------ Gibt es dafür eine Lösung? (Zeile 206 in rcapache ist das Ende einer case Anweisung "esac") Das sieht nicht nach einem OTRS-Problem aus... Grüßle aus dem sonnigen Baden Würtemberg, Volker

1 0

Group-Login
by Nora Bernhard 16 Mar '04

16 Mar '04

Hallo, Koennte mir bitte jemand einen Tip zur Konfiguration des OTRS-Logins fuer eine bestimmte Gruppe geben? Ich moechte, dass saemtliche User im Customer-Interface einloggen koennen (das funktioniert). Zusaetzlich sollen manche aber, die auch administrative Taetigkeiten zu erfuellen haben, im Agent-Interface einloggen koennen (dzt. koennen alle Customer dort einloggen). Ich habe also im LDAP eine posixGroup 'otrsallow' angelegt, wie es schon so schoen im Beispiel steht :) Ich habe testweise meinen eigenen User dieser Gruppe hinzugefuegt (meine uid bei memberUid der Gruppe eingetragen). Nun versteh ich aber etwas nicht ganz: Wenn ich - zusaetzlich zur allgemeinen GroupBaseDN-Definition - den folgenden Eintrag aktiviere > $Self->{'AuthModule::LDAP::UserAttr'} = 'UID'; koennen nach wie vor _alle_ User einloggen. Wenn ich entweder stattdessen oder zusaetzlich dies aktiviere > $Self->{'AuthModule::LDAP::AccessAttr'} = 'gidNumber'; dann kann keiner der User mehr im Agent-Interface einloggen. Im Logfile findet sich folgendes: > [Mon Mar 15 15:53:12 2004][Notice][Kernel::System::Auth::LDAP::Auth] User: 'nber' tried to login with Pw: 'XXX' (REMOTE_ADDR: 127.0.0.1) > [Mon Mar 15 15:53:12 2004][Notice][Kernel::System::Auth::LDAP::Auth] check for groupdn! > [Mon Mar 15 15:53:12 2004][Notice][Kernel::System::Auth::LDAP::Auth] User: nber login failed, no LDAP group entry foundGroupDN='cn=otrsallow,ou=groups,dc=efkon,dc=com', Filter='(gidNumber=uid=nber,ou=people,dc=efkon,dc=com)'! (REMOTE_ADDR: 127.0.0.1). Mich wundert das: gidNumber=uid=nber Die gidNumber ist doch numerisch, wieso wird hier mit dem uid-String verglichen? Das kann dann doch nicht funktionieren - oder hab ich da einen Denkfehler? Schoenen Nachmittag! -- Nora Bernhard Systems Administrator - Linux A vivid and creative mind characterizes you.

2 7

AW: [otrs-de] apache-httpd.include.conf: Perlrequire...-->ComilationFailed, AgentBounce
by Maibaum, Volker 16 Mar '04

16 Mar '04

> Du hast also einen Apache1 auf einem SLES8. _Mit_ mod_perl_1_0, richtig? ja, ich habe allerdings auch eine Test-Installation unter Suse 8.2 Professional, bei der die selben Meldungen kommen. > Wo kommt Dein Perl her, aus RPMs? Ja: mod_perl-1.27-27 perl-5.8.0-120 apache-1.3.26-38 Für die Installation habe ich folgende RPMs aus SRPMs bauen müssen: perl-Msql-Mysql-modules-1.2219-153.s390x.rpm perl-Data-ShowTable-3.3-372.s390x.rpm otrs-1.2.2-01.s390x.rpm (natürlich) > Was sagen (alle in /opt/otrs/ auszuführen) > # perl -cw bin/cgi-bin/index.pl > # perl -cw bin/PostMaster.pl > # perl -w bin/otrs.checkModules > # perl -w bin/CheckDB.pl ----------------------- perl -cw bin/cgi-bin/index.pl Using an array as a reference is deprecated at /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm line 88. Using an array as a reference is deprecated at /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm line 217. bin/cgi-bin/index.pl syntax OK perl -cw bin/PostMaster.pl Using an array as a reference is deprecated at /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm line 88. Using an array as a reference is deprecated at /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm line 217. bin/PostMaster.pl syntax OK perl -w bin/otrs.checkModules CGI ... ok Date::Pcalc ... ok DBI ... ok DBD::mysql ... ok Digest::MD5 ... ok Email::Valid ... ok IO::Scalar ... ok IO::Wrap ... ok MIME::Base64 ... ok MIME::Tools ... ok Mail::Internet ... ok Net::DNS ... ok Net::POP3 ... ok Net::LDAP ... ok Net::SMTP ... ok Authen::SASL ... ok GD ... ok GD::Text ... not installed! (for stats - not required) GD::Graph ... not installed! (for stats - not required) GD::Graph::lines ... not installed! (for stats - not required) GD::Text::Align ... not installed! (for stats - not required) perl -w bin/CheckDB.pl linuxmnt:~/ ---------------- Welchen Performance gewinn kann man denn mit Perlrequire erwarten? Ich habe das Problem, dass die einzelnen Seiten etwa 1-3 Sekunden (manchmal auch über 5 Sekunden) zum Laden benötigen. Wenn ich 10 oder 20 Requests auf einmal abschicke (durch wildes rumklickern), dann schafft es apache nicht mehr die Request in annehmbarer Zeit abzuarbeiten (> 10 Sekunden). Die virtuelle Maschine unter zVM hat IMHO genug Ressourcen 500MB real, >600 Swap, ich habe ihr sogar zu Testzwecken mehr CPU-Share zugeteilt als unseren SAP-Application-Servern. top sagt folgendes dazu: ----------- top - 14:51:43 up 1 day, 1:06, 1 user, load average: 2.22, 2.93, 3.32 Tasks: 68 total, 15 running, 53 sleeping, 0 stopped, 0 zombie Cpu(s): 89.6% user, 10.4% system, 0.0% nice, 0.0% idle Mem: 505008k total, 216996k used, 288012k free, 3848k buffers Swap: 644296k total, 62432k used, 581864k free, 17112k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5834 wwwrun 23 0 20360 13m 5500 R 9.8 2.8 0:00.61 httpd 5835 wwwrun 23 0 22024 15m 5520 R 9.8 3.2 0:00.76 httpd 5840 wwwrun 22 0 20876 14m 5500 R 9.8 2.9 0:00.62 httpd 5842 wwwrun 22 0 20516 14m 5500 R 9.8 2.8 0:00.61 httpd 1188 wwwrun 21 0 42192 21m 11m S 8.8 4.4 1:02.35 httpd 5839 wwwrun 23 0 20780 14m 5500 R 7.8 2.9 0:00.64 httpd 5841 wwwrun 23 0 19392 12m 5508 R 6.8 2.6 0:00.52 httpd 5828 wwwrun 25 0 22880 16m 5520 R 4.9 3.3 0:00.91 httpd 5830 wwwrun 23 0 20048 13m 5500 R 4.9 2.8 0:00.61 httpd 5831 wwwrun 23 0 20672 14m 5500 R 4.9 2.9 0:00.61 httpd 5833 wwwrun 23 0 20216 13m 5500 R 4.9 2.8 0:00.61 httpd 5836 wwwrun 23 0 18472 11m 5556 R 4.9 2.4 0:00.46 httpd 5837 wwwrun 22 0 20368 13m 5500 R 4.9 2.8 0:00.61 httpd 5838 wwwrun 22 0 19392 12m 5508 R 4.9 2.6 0:00.53 httpd 5749 root 15 0 1192 1192 908 R 2.3 0.2 0:08.92 top 1200 wwwrun 21 0 42512 21m 10m S 0.3 4.4 0:41.20 httpd 1 root 15 0 88 64 44 S 0.0 0.0 0:00.34 init 2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration_CPU0 ------------- Gibt es noch andere Performance-Einstellungen die mir weiterhelfen könnten? An MySQL sollte es nicht liegen - es sind etwa 20 Tickets in der DB. Grüße, Volker -----Ursprüngliche Nachricht----- Von: Robert Kehl [mailto:robert.kehl@otrs.de] Gesendet: Dienstag, 16. März 2004 14:10 An: User questions and discussions about OTRS in German. Betreff: Re: [otrs-de] apache-httpd.include.conf: Perlrequire...-->ComilationFailed, AgentBounce On Tuesday, March 16, 2004 11:36 AM Maibaum, Volker <Volker.Maibaum(a)eberspaecher.com> wrote: > Apache2 ist im Moment keine Option, da ich OTRS unter Suse SLES8 > unter zVM am laufen habe. Und bei unserer Distribution kein Apache2 > mitgeliefert wird. Ich habe schon 1 1/2 Tage gebraucht um MySQL4 zu > kompilieren und zum Laufen zu bringen und bin dann letztendlich doch > wieder auf die Version 3 zurückgegangen. Ich habe keine besonders > große Lust das Selbe bei Apache durchzumachen... hehe, was unweigerlich schlimmer werden würde... Lass es, gute Entscheidung. > Gibt es vielleicht noch die Möglichkeit in der apache-perl-startup.pl > die Module zu entfernen, welche Nein, ohne Date::Format läuft OTRS nicht. > /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm verwenden? Falls ja - > wie bekomme ich heraus welche Module das sind? # fgrep -r "use Date::Format" /opt/otrs /opt/otrs/Kernel/cpan-lib/Mail/Field/Date.pm:use Date::Format qw(time2str); Du hast also einen Apache1 auf einem SLES8. _Mit_ mod_perl_1_0, richtig? Wo kommt Dein Perl her, aus RPMs? Was sagen (alle in /opt/otrs/ auszuführen) # perl -cw bin/cgi-bin/index.pl # perl -cw bin/PostMaster.pl # perl -w bin/otrs.checkModules # perl -w bin/CheckDB.pl Gruß, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388 _______________________________________________ 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/

2 1

Re: [otrs-de] 3 Fragen zu 1.2
by Jonas Wendland 16 Mar '04

16 Mar '04

>>> Was bedeutet der Punkt sperren unten in der Ansicht? Wenn ich einen >>> neuen Fall anlege und einem Benutzer zuweise ist der doch sowieso >>> gesperrt oder? >> >> Mit 'Sperren' sperrst Du das Ticket für Dich, nicht für jemand >> anderen. Danach steht das Ticket so lange nicht mehr anderen Agenten >> in der QueueView zur Verfügung, bis Du selber oder ein Automatismus >> es freigibst. >> >Das verstehe ich noch nicht. >Wenn ein Fall neu aufgenommen wird und ich einen Bearbeiter zuweise >heisst das dann das der Fall nicht automatisch gesperrt ist? Hallo Jürgen, kann ich vielleicht auch was zu sagen, Ich denke es gibt hier verschiedene Strategien. Wenn jeder Agent in einer Queue alleine bestimmte Bereiche abdecken soll, macht es Sinn, diese sofort automatisch für ihn sperren zu lassen. Was machst du aber , wenn dieser Agent krank ist, Urlaub hat...etc. Im allgemeinen hast du dann keine Kontrolle über diese Tickets, da sie ja nur für diesen einen Agenten sichtbar sind. Wir hier bei uns haben mehrere Agenten pro Queue. Alle neu erstellten Tickets werden als ungesperrt ohne Agentenzuweisung in die Queues zugewiesen. Dabei ist für uns das neue Feature - sperren, nicht sperren - bei der Ticketanlage durchaus sinnvoll, weil wir eben nicht automatisch Tickets gesperrt haben wollen. Und wenn hier jeder sein System anders benutzt, muß der (die) Entwickler entsprechend reagieren und dies als Option anbieten. Viele Grüße Jonas

3 3

AW: [otrs-de] apache-httpd.include.conf: Perlrequire ... -->ComilationFailed, AgentBounce
by Maibaum, Volker 16 Mar '04

16 Mar '04

Hallo, also mein Apache startet nicht, auch wenn das nur Warnungen sind: linuxmnt:~/tux # rcapache status Checking for httpd: unused Apache2 ist im Moment keine Option, da ich OTRS unter Suse SLES8 unter zVM am laufen habe. Und bei unserer Distribution kein Apache2 mitgeliefert wird. Ich habe schon 1 1/2 Tage gebraucht um MySQL4 zu kompilieren und zum Laufen zu bringen und bin dann letztendlich doch wieder auf die Version 3 zurückgegangen. Ich habe keine besonders große Lust das Selbe bei Apache durchzumachen... Gibt es vielleicht noch die Möglichkeit in der apache-perl-startup.pl die Module zu entfernen, welche /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm verwenden? Falls ja - wie bekomme ich heraus welche Module das sind? Gruß, Volker -----Ursprüngliche Nachricht----- Von: Robert Kehl [mailto:robert.kehl@otrs.de] Gesendet: Dienstag, 16. März 2004 11:03 An: User questions and discussions about OTRS in German. Betreff: Re: [otrs-de] apache-httpd.include.conf: Perlrequire ... -->ComilationFailed, AgentBounce On Tuesday, March 16, 2004 9:51 AM Maibaum, Volker <Volker.Maibaum(a)eberspaecher.com> wrote: > da meine OTRS-Installation nicht sonderlich performant ist, möchte > ich gerne > die Performance-Stellschraube in der apache-httpd.include.conf > ausprobieren. > Ich habe hierzu in folgender Zeile den Kommentar entfernt: > > Perlrequire /opt/otrs/scripts/apache-perl-startup.pl [...] > [Tue Mar 16 09:39:46 2004] Format.pm: Using an array as a reference > is deprecated at /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm line > 88. > [Tue Mar 16 09:39:46 2004] Format.pm: Using an array as a reference > is deprecated at /usr/lib/perl5/site_perl/5.8.0/Date/Format.pm line > 217. > Syntax OK failed > > Gibt es dazu schon ein Fix? Kann ich Apache so konfigurieren, dass er > trotzdem startet, auch wenn > als deprecated markierte Funktionen verwendet werden? Dein Apache läuft schon, denke ich. Das sind lediglich Warnungen, dass in der verwendeten Perl-Routine wer schlampig programmiert hat. Du bist Dir sicher, dass Du nicht zufällig einen Apache2 installieren möchtest, mit mod_perl2. Wenn wir schon von Performanz reden, dann richtig, oder? Fröhlich grüßt Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388 _______________________________________________ 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/

2 1