Announcement

Collapse
No announcement yet.

Probleme seit letztem Update

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Probleme seit letztem Update

    Hallo,
    ich habe seit dem letzten Update auf Debian vor zwei Tagen (neue Version der Debia-Pakete ist 6.10) große Schwierigkeiten mit dem Open-Xchange-System.

    Die Umgebung ist wie folgt:
    - Debian testing server
    - Open-Xchange open source edition
    - mysql
    - cyrus2.2
    - saslauthd mit Zugriff auf die OX-Datenbank zwecks Anmeldung
    - saslauthd zustaendig fuer Imap und OX

    Bisher war es so, dass ca. einmal im Monat die Meldung "503-Service Unavailable" kam. Dann war die Maschine seitens Arbeitsspeicher vollgelaufen und musste neu gestartet werden.

    Seit diesem Update war das Problem aehnlich, und zwar haengt sich die gesamte Mail-Umgebung einmal am Tag auf. Dergestalt, dass weder per Imap noch per OX ein Anmelden auf dem Server moeglich war. Ich habe das Problem hier zurueckverfolgt und gesehen, dass scheinbar der saslauthd nicht mehr reagiert.

    Heute habe ich erneut ein dselect-update gemacht und gesehen, dass die cyrus-Umgebung aktualisiert wurde. Seit diesem Update geht zwar Imap wieder, aber in OX funktioniert gar nichts mehr.

    Nach dem Aufruf der Webseite https://www.gridcon.de/ox6 kommt sofort die Autologin-Maske und bleibt dort bei 10% haengen. Keine Meldung im Syslog.

    Ich habe im Browser alle Cookies geloescht, aber dennoch geht die Webseite sofort auf Autologin.

    Was ist da los?

    Bitte bitte bitte um schnelle Hilfe


    Gruß


    Gunnar Stahl

  • #2
    Einen Schritt weiter

    Ok, ich bin einen Schritt weiter. Ich habe den Server auf die Login-Seite gezwungen, indem ich den groupware-Service via /etc/init.d/open-xchange-groupware gestoppt habe und dann die OX-Anmeldeseite neu aufgerufen habe. Dadurch bekam ich eine normale Anmelde-Maske.

    Anschließend habe ich den Service gestartet, meine Anmelde-Informationen eingegeben und abgeschickt und lande wieder auf der 10%-Huerde.

    In /var/log/messages erscheint die folgende Meldung:
    Code:
    Aug 14 13:33:18 localhost 2009-08-14 13:33:18,685 open-xchange-groupware WARN  [com.openexchange.ajp13.najp.AJPv13RequestHandlerImpl][AJPListener-0000002]: com.openexchange.ajp13.najp.AJPv13RequestHandlerImpl,processPackage AJP-0007 Category=6 Message=Unknown Request Prefix Code: 0 exceptionID=905133603-2 
    Aug 14 13:33:18 localhost AJP-0007 Category=6 Message=Unknown Request Prefix Code: 0 exceptionID=905133603-2
    Aug 14 13:33:18 localhost     at com.openexchange.ajp13.najp.AJPv13RequestHandlerImpl.processPackage(AJPv13RequestHandlerImpl.java:184)
    Aug 14 13:33:18 localhost     at com.openexchange.ajp13.najp.AJPv13ConnectionImpl.processRequest(AJPv13ConnectionImpl.java:176)
    Aug 14 13:33:18 localhost     at com.openexchange.ajp13.najp.AJPv13Task.run(AJPv13Task.java:257)
    Aug 14 13:33:18 localhost     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
    Aug 14 13:33:18 localhost     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
    Aug 14 13:33:18 localhost     at java.util.concurrent.FutureTask.run(FutureTask.java:123)
    Aug 14 13:33:18 localhost     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
    Aug 14 13:33:18 localhost     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
    Aug 14 13:33:18 localhost     at java.lang.Thread.run(Thread.java:595)
    Aug 14 13:33:18 localhost 2009-08-14 13:33:18,687 open-xchange-groupware WARN  [com.openexchange.ajp13.najp.AJPv13RequestHandlerImpl][AJPListener-0000002]: com.openexchange.ajp13.najp.AJPv13RequestHandlerImpl,processPackage Corresponding AJP package: ^M 0000    12 34 00 21 00 1F 6E 61 6D 65 3D 6F 78 74 65 73^M 0010    74 26 70 61 73 73 77 6F 72 64 3D 46 6F 6F 39 71^M 0020    75 6F 6F 63 68
    Immer noch: Ich benoetige hier Hilfe.

    Gruß


    Gunnar Stahl

    Comment


    • #3
      That's quite likely because Debian Testing ships with an apache containing some changes which do not work with OX.

      That will be fixed within the next OX release.

      I can just recommend everybody NOT to use unstable code in production.

      Extract from our internal bug:

      [...]
      Since version 2.2 of apache its module mod_proxy provides an AJP interface. This is currently
      not working. The intention of this bug is to get our AJP interface working with mod_proxy of
      apache 2.2 to have an alternative for mod_jk.
      [...]

      Comment


      • #4
        Thanks for the reply - although I do not know how to handle this now. So what can I do now to fix this?

        Comment


        • #5
          Hi,

          could you please verify that an apache version prior to 2.2.12 is running? They changed the behavior of proxy_ajp with 2.2.12 which is incompatible with OX 6.10. We already made a fix for this with 6.11 which will become the next stable release (6.12). If possible, please downgrade apache to 2.2.11 or earlier. Debian testing ships 2.2.12-1, stable ships 2.2.10.

          Corresponding change at the apache sources:


          Entry at the apache changelog:

          *) mod_proxy_ajp: Forward remote port information by default.


          Greetings
          Last edited by Martin Heiland; 08-14-2009, 02:20 PM.

          Comment


          • #6
            Thanks for the replies, finally fixed it. Here is the solution to the problem which I guess not only affects me.

            To avoid this problem when using debian testing you have to pin the apache packages to the stable release. "Pin"ning is a mechanism in apt which defines which packages to take from which repository.

            To do this the file /etc/apt/preferences is used. Mine now looks like the following:
            Code:
            Package: apache2 apache2-doc apache2-mpm-worker apache2-mpm-prefork apache2-mpm-itk apache2-mpm-event apache2-utils apache2.2-bin apache2.2-common libapr1 libaprutil1
             libaprutil1-dbd-mysql libaprutil1-ldap
            Pin: release a=stable
            Pin-Priority: 1001
            
            Package: subversion libapache2-svn libsvn1
            Pin: release a=stable
            Pin-Priority: 1001
            
            
            Package: libapache2-mod-php5 php5 php5-adodb php5-apache2-mod-bt php5-auth-pam php5-cgi php5-clamavlib php5-cli php5-common php5-curl php5-dbg php5-dev php5-exactimag
            e php5-ffmpeg php5-gd php5-geoip php5-gmp php5-gpib php5-idn php5-imagick php5-imap php5-interbase php5-json php5-lasso php5-ldap php5-librdf php5-mapscript php5-maxd
            b php5-mcal php5-mcrypt php5-memcache php5-mhash php5-ming php5-mssql php5-mysql php5-mysqli php5-odbc php5-pgsql php5-ps php5-pspell php5-radius php5-recode php5-rem
            ctl php5-sasl php5-snmp php5-sqlite php5-sqlite3 php5-sqlrelay php5-suhosin php5-svn php5-sybase php5-syck php5-symfony php5-symfony1.0 php5-tidy php5-timezonedb php5
            -uuid php5-xapian php5-xcache php5-xdebug php5-xmlrpc php5-xsl
            Pin: release a=stable
            Pin-Priority: 1001
            
            Package: *
            Pin: release a=testing
            Pin-Priority: 700
            
            Package: *
            Pin: release a=stable
            Pin-Priority: 650
            
            Package: *
            Pin: release a=unstable
            Pin-Priority: 600
            These lines are seperated into blocks, beginning with a "Package" tag, followed by a "Pin"-tag and ending with the "Pin-Priority"-tag.
            - The package-tag obviously describes which packages have to be pinned.
            - The "Pin"-tag defines to which release or version these packages are pinned
            - The "Pin-Priority"-tag defines the priority, in which these packages are used.

            In my case the last three blocks define, that at first all packages are taken from release testing, then from release stable and then from release unstable. So a package existing in all three releases is normally taken from release testing.

            The first three blocks have the highest priority number, so these overrule all other blocks. They define the packages relevant for my system dealing with the apache webserver. These are the apache packages, the php-packages and the subversion-packages. All three are pinned to release stable.

            And since they have a pin-priority above 1000 they not only overrule the last three blocks, they even get downgraded to the stable release if they were formerly installed from the testing repository.

            Finally you have to make sure that you have the stable sourcelines in /etc/apt/sources.list. Mine looks as following:

            Code:
            deb ftp://ftp.de.debian.org/debian/ stable main non-free contrib
            # deb-src ftp://ftp.de.debian.org/debian/ testing  main non-free contrib
            
            deb ftp://ftp.de.debian.org/debian/ testing main non-free contrib
            # deb-src ftp://ftp.de.debian.org/debian/ testing  main non-free contrib
            
            deb ftp://ftp2.de.debian.org/debian/ testing main non-free contrib
            deb-src ftp://ftp2.de.debian.org/debian/ testing  main non-free contrib
            
            deb ftp://ftp2.de.debian.org/debian/ stable main non-free contrib
            deb-src ftp://ftp2.de.debian.org/debian/ stable main non-free contrib
            
            deb http://security.debian.org/ testing/updates main contrib non-free
            deb-src http://security.debian.org/ testing/updates main contrib non-free
            
            # Open Xchange
            deb http://software.open-xchange.com/OX6/stable/DebianEtch/ /
            What did cost me some serious time was figuring out which packages I had to pin. It is defintely not sufficient to only pin "apache2". Since the other packages which apache2 depends on would still be taken from the testing repositiory the apache2-package would still be taken from testing. So you have to find out which packages depend on the packages you want to pin and vice versa.

            Happy hunting,

            Gunnar Stahl

            Comment


            • #7
              Thank you very much for the how-to

              Comment

              Working...
              X