[ERLEDIGT] EGroupware + ispCP => Error 500

[joximu]

(04-08-2010 10:10 AM)the3rdBIT Wrote:  

(04-07-2010 06:14 PM)joximu Wrote:  die Rechte stimmen

Na gut, die Verwendung von Root als Besitzer ist nicht unbedingt schön. Aber da Aptitude dies beim nächsten Update natürlich wieder diesen Besitzer setzt, habe ich keine Wahl. Es ist natürlich auch unschön die Konfigurationsdatei des VirtualHosts von Hand zusammenzustellen, aber dies geschieht nur einmal und schon funktioniert's. Das gefällt mir eigentlich besser als immer die Aktualisierungen von Hand einspielen zu müssen.

eben...
gut geeignet für einen Server inhouse (Firma oder privat), nicht aber für Kundenhosting.

(04-08-2010 10:10 AM)the3rdBIT Wrote:  

(04-07-2010 06:14 PM)joximu Wrote:  Das ist einer der Gründe, warum ich bei solchen Projekten nicht die Distri-Version benutze sondern das Original, welches ich dann dort habe, wo ich will.

Was sind denn weitere Gründe?

Meine Erfahrung: man bekommt mit den Distris zwar korrigierte Pakete aber nicht immer die aktuellsten.

(04-08-2010 10:10 AM)the3rdBIT Wrote:  

(04-08-2010 04:14 AM)Jones007 Wrote:  Wir nutzen auch eGroupWare und haben keine Probleme allerdings haben wir auch nicht die von Debian genommen sondern gleich die Original runtergeladen, tuts Prima und ist auch leicht upzudaten

Wofür besitzen denn nach deiner Meinung die meisten Distris zentrale Paketverwaltungssysteme?

Um die Systemdateien bzw. das Betriebssystem aktuell zu halten.
Das beisst sich, sobald man ein Paket/eine Software anders verwenden will, als vom Paketersteller erdacht - und das ist nunmal bei Web-applikationen, die man seinen Kunden zur Verfügung stellen will, der Fall.

Du kannst natürlich ein Skript schreiben, das die Repo-Variante nach einem Update wieder kompatibel zum VHosting macht... (Rechte setzen, Symlinks etc)

aber eben - lohnt es sich dann noch?

/J

[the3rdBIT]

(04-08-2010 06:01 PM)joximu Wrote:  Meine Erfahrung: man bekommt mit den Distris zwar korrigierte Pakete aber nicht immer die aktuellsten.

Richtig, dies ist die Strategie der meisten Distris. Jedoch haben viele Entwickler wie die von EGroupware ein eigenes Repository für diverse Distributionen.
Für Debian müsste z.B. das in die sources.list eingetragen werden:

Code:

deb http://download.opensuse.org/repositories/server:/eGroupWare/Debian_5.0/ ./

(04-08-2010 06:01 PM)joximu Wrote:  Um die Systemdateien bzw. das Betriebssystem aktuell zu halten.
Das beisst sich, sobald man ein Paket/eine Software anders verwenden will, als vom Paketersteller erdacht - und das ist nunmal bei Web-applikationen, die man seinen Kunden zur Verfügung stellen will, der Fall.

Du kannst natürlich ein Skript schreiben, das die Repo-Variante nach einem Update wieder kompatibel zum VHosting macht... (Rechte setzen, Symlinks etc)

aber eben - lohnt es sich dann noch?

Dies ist anscheinend Geschmackssache. Ich mag einfach nicht immer auf allen Websites nachschauen ob nun für meine Programme eine neue Version verfügbar ist und diese dann manuell updaten. Bereits mit ispCP ist das schon genug zu tun. Ich werde dann halt eine halbwegs von ispCP unabhängige Subdomain mit der entsprechenden Config für diverse Tools einrichten. Mal schauen welche erfahrungen ich damit mache und poste dann bei Interesse meine Scripts.

edit: Da das ispCP 1.0.5 Pakete benötigt, die mit benötigten von EGroupware kollidieren, habe ich mich doch entschieden die Updates via SVN zu machen.

[drumlover]

Hey, sorry aber ich habe nicht ganz verstanden, wie du das Problem jetzt lösen konntest...
Vielleicht wäre nochmal eine kurze Zusammenfassung sinnvoll...

Gruß drumlover

[drumlover]

Das ist meine suexec.log

Code:

[2010-08-05 15:34:39]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-05 15:34:40]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: index.php
[2010-08-05 15:34:40]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-05 15:34:49]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: index.php
[2010-08-05 15:34:49]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-05 15:34:50]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: index.php
[2010-08-05 15:34:50]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-05 15:34:51]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: index.php
[2010-08-05 15:34:51]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-05 15:34:52]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: index.php
[2010-08-05 15:34:52]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-05 15:35:01]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: index.php
[2010-08-05 15:35:01]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-05 15:35:02]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: index.php
[2010-08-05 15:35:02]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-05 15:35:03]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: index.php
[2010-08-05 15:35:03]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-05 15:35:04]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: index.php
[2010-08-05 15:35:04]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-05 16:52:23]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: index.php
[2010-08-05 16:52:23]: command not in docroot (/usr/share/egroupware/setup/index.php)
[2010-08-06 19:58:16]: uid: (2000/vu2000) gid: (2000/vu2000) cmd: php5-fcgi-starter

Hoffe, mir kann jemand helfen...

Nutze php 5...

Gruß drumlover

[joximu]

lies mal "command not in docroot".

Das docroot bei ispcp-Customers liegt in /var/www/virtual/domain.tld/htdocs.

Und suexec hat nochmals eigene Regeln, wo etwas sein soll.

Ich weiss nun nicht, wie du vom einen zum anderen verbindest (alias oder location oder was) - jedenfalls wird es nicht akzeptiert.

Ich würds mal mit nem Symlink versuchen oder egroupware zum Kunden verschieben (also eher die original-Version statt der Distriversion - siehe oben...).

Gruss
Joxi