I-Doit OTRS Verbindung schlägt fehl



  • Hallo zusammen,

    ich versuche gerade i-Doit open 1.4.8 mit OTRS open 3.3.14 zu verbinden.
    Diese befinden sich auf zwei verschiedenen Servern.

    Unter i-Doit habe ich in den Einstellungen für das TTS folgendes als URL/Protokoll eingegeben:
    http://otrs.meinedomain.com/otrs

    Wenn ich in der Infrastructure einen Server auswähle, und dann auf "Create Ticket" klicke, erscheint die Meldung "General error: SOAP call failed: Bad Gateway–-Please check your configuration settings, especially credentials and protocol (e. g. http) in service url."
    Laut der Beschreibungen im Netz soll der Link jedoch so OK sein.

    Wenn ich in den Einstellungen für das TTS folgendes als URL/Protokoll eingegebe:
    http://otrs.meinedomain.com/otrs/rpc.pl oder
    http://otrs.meinedomain.com/otrs/index.pl eingebe,
    dann erscheint die Meldung "General error: SOAP call failed: Forbidden---Please check your configuration settings, especially credentials and protocol (e. g. http) in service url."
    Warum "forbidden"? Muss ich noch im OTRS irgendwelche Rechte einstellen?



  • Hi Montt,

    hast du auf der OTRS Seite das Plugin installiert?

    Wenn NEIN:
    https://bitbucket.org/synetics/otrs-opm-referenceidoitobjects

    Eine recht gute Erklärung zum Einrichten der Schnittstelle hat Quentitux hier im Forum gepostet:
    http://forum.i-doit.org/index.php/topic,3471.msg11469.html#msg11469

    Wenn JA:
    hast du es schon mit einem AJAX Proxy versucht?

    ReferenceIDoitObjects::API
    Please be aware of browsers' Same Origin Policy! This module uses AJAX requests access i-doit's API. If OTRS and i-doit are not available under the same domain name (or IP address), AJAX calls will fail.
    To avoid this "problem" (actually this policy is very useful) you can setup an AJAX proxy. This module already provides such a proxy located in the project repository under scripts/i-doit_api_proxy.php. It's written in PHP, so you have to install PHP 5.4 or higher and the PHP extension curl on the same machine where OTRS is installed. Make this little script available through your Web server and edit the script by setting $l_url to the URL of i-doit's API, e. g.
    http://example.org/i-doit/index.php?api=jsonrpc
    In OTRS' site configuration ReferenceIDoitObjects::API has to be set to this script, e. g.
    http://otrs.example.org/path/to/i-doit_api_proxy.php
    Note: You may test the proxy by simple calling it via your Web browser. It should display an error describing this is not a proper API call.

    Gruß
    daffodil



  • Danke fürs kümmern, daffodil,

    Ja, ich habe das Plugin 0.8 installiert und habe die Einstellungen von Quentitux fast 1:1 übernommen.

    Der Ajax Progy dürfte gar nicht funktionieren wegen der Same Origin Policy…

    Der Zugriff von I-DoIt zu OTRS und damit verbundene Bad Gateway Fehler müsste doch unabhängig davon sein, was im OTRS eingestellt ist, oder? Im Log von NGINX ist folgender Pfad zu sehen:

    x.x.x.x - - [16/Jun/2015:11:57:08 +0200] "POST /otrs/nph-genericinterface.pl/Webservice/GenericTicketConnector HTTP/1.1" 502 28 "-" "PHP-SOAP/5.5.9-1ubuntu4.9"

    Auf die nph-genericinterface.pl kann man per Browser zugreifen und es kommt auch ein Bad Gateway zurück.
    Auch versuche ich per Browser auf die index.pl zuzugreifen, die sich im gleichen Verzeichnis befindet, und dort offnet sich ganz normal die Anmeldeseite. Also scheint es keine Fehlkonfiguration vom NGINX zu sein, sondern das Perl Script nph-genericinterface.pl selbst kommt irgendwie nicht weiter, wenn man /otrs/nph-genericinterface.pl/Webservice/GenericTicketConnector anspricht…



  • Ich glaube bereits einen Schritt weiter gekommen zu sein.

    in der NGINX Konfiguration stand folgendes:

    server {
    
        server_name  otrs.betago.com;
        listen otrs.betago.com:80;
        access_log  /var/log/nginx/otrs_access.log;
        # These 2 lines were necessary to prevent buffer problems in OTRS
        fastcgi_buffers 8 16k;
        fastcgi_buffer_size 32k;
        fastcgi_read_timeout 300;
        # Enter your htdocs path here, e.g. /opt/otrs/var/httpd/htdocs
        root /opt/otrs/var/httpd/htdocs;
    
        # Do not log favicon access
        location = /favicon.ico {
            access_log     off;
            log_not_found  off;
        }
    
        location ^~ /otrs-web/ {
             alias /opt/otrs/var/httpd/htdocs/;
        }
    
        location ~ ^/otrs/(.*\.pl)(/.*)?$ {
            gzip off;
            # Enter your fcgiwrap socket here
            fastcgi_pass  unix:/var/run/fcgiwrap.socket;
            fastcgi_index index.pl;
            # Enter your OTRS cgi-bin path, e.g. <your_otrs_path>/bin/cgi-bin
            fastcgi_param  SCRIPT_FILENAME /opt/otrs/bin/cgi-bin/$1;
            include fastcgi_params;
        }
    }</your_otrs_path> 
    

    Ich habe jedoch auch folgende Konfiguration ergoogeln können:

    server {
    
        server_name  otrs.betago.com;
        listen otrs.betago.com:80;
        access_log  /var/log/nginx/otrs_access.log;
        # These 2 lines were necessary to prevent buffer problems in OTRS
        fastcgi_buffers 8 16k;
        fastcgi_buffer_size 32k;
        fastcgi_read_timeout 300;
        # Enter your htdocs path here, e.g. /opt/otrs/var/httpd/htdocs
        root /opt/otrs/var/httpd/htdocs;
    
        # Do not log favicon access
        location = /favicon.ico {
            access_log     off;
            log_not_found  off;
        }
    
        location ^~ /otrs-web/ {
             alias /opt/otrs/var/httpd/htdocs/;
        }
    
      location ~ ^/otrs/(.*\.pl)(/.*)?$ {
        gzip off;
    fastcgi_pass unix:/var/run/fcgiwrap.socket;
    fastcgi_index index.pl;
    fastcgi_param SCRIPT_FILENAME   /opt/otrs/bin/fcgi-bin/$1;
    fastcgi_param QUERY_STRING      $query_string;
    fastcgi_param REQUEST_METHOD    $request_method;
    fastcgi_param CONTENT_TYPE      $content_type;
    fastcgi_param CONTENT_LENGTH    $content_length;
    fastcgi_param GATEWAY_INTERFACE CGI/1.1;
    fastcgi_param SERVER_SOFTWARE   nginx;
    fastcgi_param SCRIPT_NAME       $fastcgi_script_name;
    fastcgi_param REQUEST_URI       $request_uri;
    fastcgi_param DOCUMENT_URI      $document_uri;
    fastcgi_param DOCUMENT_ROOT     $document_root;
    fastcgi_param SERVER_PROTOCOL   $server_protocol;
    fastcgi_param REMOTE_ADDR       $remote_addr;
    fastcgi_param REMOTE_PORT       $remote_port;
    fastcgi_param SERVER_ADDR       $server_addr;
    fastcgi_param SERVER_PORT       $server_port;
    fastcgi_param SERVER_NAME       $server_name;
    }
    
    }
    
    

    Mit der zweiten Version kommt die Fehlermeldung Bad Gateway nicht mehr, aber dafür schon folgende Fehlermeldung:

    General error: SOAP call failed: looks like we got no XML document–-Please check your configuration settings, especially credentials and protocol (e. g. http) in service url.

    Ich suche weiter ;c)


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.