Announcement

**gstahl** · 08-14-2009, 01:37 PM

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

**Carsten Hoeger** · 08-14-2009, 02:04 PM

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.
[...]

**gstahl** · 08-14-2009, 02:13 PM

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

**Martin Heiland** · 08-14-2009, 02:18 PM

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:

http://mail-archives.apache.org/mod_mbox/httpd-cvs/200904.mbox/%3C20090417134009.D14CC23889DD@eris.apache.org%3E

Entry at the apache changelog:

404 Not Found

http://www.apache.org/dist/httpd/CHANGES_2.2

*) mod_proxy_ajp: Forward remote port information by default.

Greetings

**gstahl** · 08-14-2009, 04:32 PM

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

**Martin Heiland** · 08-14-2009, 05:56 PM

Thank you very much for the how-to

Announcement

Probleme seit letztem Update

Probleme seit letztem Update

Comment

Comment

Comment

Comment

Comment

Comment