Announcement
Collapse
No announcement yet.
Probleme seit letztem Update
Collapse
X
-
Guest repliedThanks 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
- 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/ /
Happy hunting,
Gunnar Stahl
Leave a comment:
-
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.
GreetingsLast edited by Martin Heiland; 08-14-2009, 02:20 PM.
Leave a comment:
-
Guest repliedThanks for the reply - although I do not know how to handle this now. So what can I do now to fix this?
Leave a comment:
-
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.
[...]
Leave a comment:
-
Guest repliedEinen 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
Gruß
Gunnar Stahl
Leave a comment:
-
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 StahlTags: None
Leave a comment: