HowTo SuSE 10.1 + Confixx 3.2 + suPHP

coolsoft

coolsoft

Registered User
Ich habe bei der Installation bei jeder Änderung paralell mitgeschrieben und es funktioniert mit den standart RPM's ohne PHP neu zu kompilieren.
Standart SuSE - PHP 5.1.2

Ich wollte eigentlich zuerst PHP 5.2.0 installieren, aber schon beim ./configure kam immer ein Fehler wenn ich die Option --with-mysql gewählt habe:
checking for mysql_close in -lmysqlclient... no
checking for mysql_error in -lmysqlclient... no
configure: error: mysql configure failed. Please check config.log for more information.

Und PHP ohne mySQL....? Nicht wirklich ratsam ;-)

--------------------------------------------------------------------------
ANLEITUNG


HOSTNAME
geändert von hotel123.server4you.de
nach srv4.mydomain.de
mit YaST
Netzwerkgeräte -> Netzwerkkarte -> Traditionelle.. -> [Bearbeiten] ->
[Hostname und Namenserver]
Hostname: srv4
Domainname: mydomain.de


Zusätzliche PHP Pakete über YaST installiert:
(braucht man / braucht man nicht...?)

php5-bcmath
php5-filepro
php5-ftp
php5-tokenizer
php5-wddx

apache2-mod_fcgid
apache2-debuginfo

libapr-util1-debuginfo
libapr1-debuginfo
apache2-mod_fcgid-debuginfo
majordomo

gcc-ada
libada



suPHP installieren
Download von http://www.suphp.org/download/suphp-0.6.2.tar.gz
nach /downloads/suPHP/

# cp -a /usr/lib/apr-1/build/* /usr/lib/build/
# cp -a /usr/include/apr-1/* /usr/include/apache2
# cd /downloads/suPHP
# ./configure --with-min-uid=30 --with-min-gid=30 --with-apache-user=wwwrun --prefix=/usr --with-php=/srv/www/cgi-bin/php5 --with-logfile=/var/log/apache2/suPHP.log --with-apxs=/usr/sbin/apxs2 --with-apr=/usr/bin/apr-1-config
# make
# make install



Confixx Update von Version 3.1 auf die Version 3.2.1

# cd /downloads

Download von: http://download1.swsoft.com/Confixx/ConfixxPro3.2/3.2.1/confixx_pro_3.2.1_update.tgz
# tar zxvf confixx_pro_3.2.1_update.tgz
# cp -a /usr/local/confixx/admin /usr/local/confixx/admin.STANDART (als Backup)
# cp –a admin /usr/local/confixx/
# cd /usr/local/confixx
.# admin/updates/update_3.x.pl
…. INSTALLATIONSROUTINE mit Standartvorgaben …
AWstats aktiviert
DNS deaktiviert

# /usr/local/confixx/admin/admin.pl
(2) Webserver -> (9) suPHP [X]

Standart-Einstellungen:
php.ini - /etc/php5/cli/php.ini
php.ini der User - /etc/apache2/confixx_phpini
php-Spezial verwenden? [JA]

(3) E-Mail -> (5) IMAP [X]
Wo befindet sich der Mailserver? [localhost]
Port [143]

Confixx registrieren wie in E-Mail von Server4You:
Ausführen von:
/usr/local/confixx/admin.STANDART/auto_reg.pl
UPDATE OK
Valid until: Sat Sep 22 13:55:03 2007

Apache config anpassen
In der Datei: /etc/sysconfig/apache2
Folgende Zeile einfügen:
APACHE_CONF_INCLUDE_FILES="/etc/apache2/httpd.conf.local"

Datei /etc/apache2/httpd.conf.local erstellen mit Inhalt:
LoadModule suphp_module /usr/lib/apache2/mod_suphp.so

*nicht in httpd.conf ändern*

==========================================================

e-mail von einem SWsoft Mitarbeiter:

Damit Confixx und alle anderen Seite angezeigt werden können, habe ich die folgenden Einträge in die Datei /etc/apache2/httpd.conf hinzugefügt:

<Directory "/srv/www">
Allow from all
</Directory>
(dieser Eintrag steht ganz am Ende der httpd.conf)

diese Einträge sind nötig, weil in apache 2.2 kein Modul 'mod_access' verfügbar ist, deshalb funktioniert diese Einstellung mehr nicht in Apache 2.2:

<IfModule mod_access.c>
Allow from all
</IfModule>


Wenn der Eintrag 'Include /etc/apache2/confixx_vhost.conf' in der confixx_mhost.conf
auskommentiert ist:

# Include /etc/apache2/confixx_vhost.conf
(Diese Zeile muss aktiviert sein OHNE Raute am Anfang)

funktioniert die Confixx-Oberfläche.

Wegen des Suexec Problems. Der Suexec Modul ist richtig in Apache aktiviert aber es sieht so aus, dass der Modul suexec mit einem anderen Apache Modul in Konflikt kommt, deshalb funktioniert nicht. *STIMMT NICHT*

Suexec Anpassung von mir:
chown root:www /usr/sbin/suexec2
chmod 4750 /usr/sbin/suexec2

Meine Antwort an swSoft
------------------------------------------------------------------------
Hallo Herr Mitarbeiter,

ich habe das suexec2 wie nachfolgend behandelt und die Fehlermeldung beim
Apache start ist nun verschwunden:

# chown root:www /usr/sbin/suexec2
# chmod 4750 /usr/sbin/suexec2

Ein Konflikt liegt also offenbar nicht vor. Ist das soweit ok oder sind
damit irgendwelche Sicherheitsrisiken verbunden?
------------------------------------------------------------------------

Rückantwort:
------------------------------------------------------------------------
Hallo Herr Sell,

ich habe die Rechte von suexec2 noch ein bisschen korrigiert:


# ls -l /usr/sbin/suexec2
-rwsr-xr-x 1 root root 12064 May 2 2006 /usr/sbin/suexec2

Apache wird erfolgreich gestartet und keine Fehlermeldung tritt dabei auf.


Suexec ist für suPHP und mod_php nötig.
Wenn suPHP läuft, werden alle Dateien, die über PHP-Skripte angelegt werden, zum
webX:webX gehören. Der Benutzer und die Gruppe wird von der Direktive
SuexecUserGroup festgelegt. Diese Direktive legt auch einen Benutzer und eine
Gruppe, zu den CGI-Skripte gehören müssen.

Wenn mod_php läuft, werden alle Dateien, die über PHP-Skripte angelegt werden, zum
apache_user:apache_group gehören, weil PHP-Skripte in diesem Fall von Apache
ausgeführt werden.


Mit freundlichen Grüßen,
--
Technical Support Engineer
SWsoft, Inc.
--------------------------------------------------------------------------

Weitere E-Mail von server4you

-------------------------------------------------------------------------
damit OpenSuSE die Änderung nicht nochmal rückgängig macht, sollten Sie diese Rechte
auch in /etc/permissions.secure eintragen. das von yast aufgerufene SuSEconfig setzt
die Rechte je nach in /etc/sysconfig/security eingetragener PERMISSION_SECURITY
anhand der Werte in dieser Datei.

---------------------------------------------------------------------------

Hinzufügen in /etc/permissions.secure

/usr/sbin/suexec2 root:root 4750


FERTIG.... und siehe da, es funktioiert!
 
Last edited by a moderator:
Hallo Coolsoft,

vielen Dank ersteinmal für deine Anleitung.
Ich habe das gleiche System bei dem selben *** Laden (S4U) Naja das ist ein anderes Thema ;)

Mir sind ein paar Sachen aufgefallen bei denen ich mich frage wie ich damit verfahren muss, bzw wie du oder ob du diese Sachen überhaupt auch gemacht hast... und zwar:

habe ich
1. suPHP kompiliert und installiert (ohne Fehler)

habe ich
2. Confixx upgrade gefahren (ohne Fehler)

und dann:
3. Einbinden von suPHP in Apache (hier kommen jetzt meine Fragen)

Frage 1 Hat es einen Grund, dass du mod_suPHP nicht direkt in /etc/sysconfig/apache2 in die Zeile APACHE_MODULES="..." mit einbindest, sondern per include aus der extra datei httpd.conf.local?

Frage 2 Was machst du mit mod_php5? Hast du es weiterhin laufen, oder hast du es "entladen" oder umkonfiguriert und wenn ja, wie?

Frage 3 Wieso kommst du ohne Angabe von suPHP_Engine on in den vhosts aus, oder soll suPHP bei dir garnicht für die Confixx Vhosts aktiviert sein?


Wenn ich deine Anleitung bis zum Schluss verfolge funktioniert mein Confixx nichtmehr, da ich auf Confixx 3.2.1 + applicationPack erweitert habe, das nur mit suPHP funktioniert und du ja suPHP garnicht in den Confixx Vhosts verwendest. Aber solange ich den apache das mod_php5 weiterhin laden lasse, dann interpretiert dieses modul weiterhin - wenn ich jetzt mod_php5 aus dem apachen rausnehme damit suPHP greifen soll, dann bekomme ich beim Aufruf von Confixx nur den Quellcode zum Download geboten. Hab ich irgendetwas überlesen!? :o

Dann hab ich gelesen, dass es eine config für suPHP gibt... wieso gibts die bei mir nicht?

Außerdem ist mir aufgefallen, dass bei mir keinerlei Logfiles angelegt werden... (/var/log/apache2/suPHP.log existiert nicht) auch im apache-log ist nichts zu finden...

Fragen über Fragen :)
Ich hoffe ich finde die passenden Antworten...

Bis dann und danke schon mal falls jemand mir bei diesem leidigen Thema helfen mag.

Robin
 
Hallo,

es tut mir leid, aber ich muss jetzt mal dein HowTo ein wenig auseinander nehmen...:
Apache config anpassen
In der Datei: /etc/sysconfig/apache2
Folgende Zeile einfügen:
APACHE_CONF_INCLUDE_FILES="/etc/apache2/httpd.conf.local"

Datei /etc/apache2/httpd.conf.local erstellen mit Inhalt:
LoadModule suphp_module /usr/lib/apache2/mod_suphp.so

*nicht in httpd.conf ändern*
Click to expand...
Das ist nicht üblich so!
Einfach /etc/sysconfig/apache2 öffnen und bei
Code: 
"APACHE_MODULES="rewrite access actions alias au..."
einfach "suphp" mit reinschreiben.
Das Modul sollte nach Möglichkeit nicht deaktiviert werden (mod_php), da es sonst zu Problemen mit Konfigurationsanweisungen kommen kann. Lieber mit engine off abschalten.
Suexec ist für suPHP und mod_php nötig.
Click to expand...
Das ist schlichtweg Bullshit und man sollte sich fragen, wieso der gute SwSoft-Mann überhaupt mit gutem Gewissen mit " Technical Support Engineer" unterschreiben kann.
Ich will jetzt nicht groß zu dem Thema suexec ausholen und deshalb fasse ich mich kurz:
suexec wird "lediglich" dazu benötigt ein entsprechendes CGI-Binary (z.B. Perl oder CGI) mit einem angegeben User auszuführen.
Bei mod_php spielt suexec keinerlei Rolle, da wie der SwSoft-Mitartbeiter schon beschrieben hat, die Scripte als Apache-User ausgeführt werden (interessant, wie er sich in seinen Aussagen widerspricht!).
Wenn suPHP "normal" installiert/kompiliert wird*, so spielt es auch keine Rolle ob und wie suexec installiert/aktiviert ist, da suPHP sozusagen das gleiche wie suexec macht.
Deshalb sollte uns das suexec-Modul für diesen Fall nicht wirklich interessieren.

So, nun ist also suPHP kompiliert und installiert. Wir haben es bereits aktiviert im Apachen.. aber jetzt kann es ja noch nicht losgehen ;)

Zuerst sollten wir uns um suphp.conf kümmern:
Hierzu einfach aus dem heruntergeladenen suPHP Tar-Paket die suphp.conf kopieren:
Code: 
cp suphp-0.6.2/doc/suphp.conf-example /etc/suphp.conf
Dann die /etc/suphp.conf noch anpassen.
Code: 
webserver_user=[B]wwwrun[/B]
dann noch:
Code: 
[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/bin/php5-cgi
Den Pfad zum Binary muss man natürlich den eigenen Wünschen entsprechend anpassen.
Ich muss dem HowTo-Ersteller leider widersprechen: es macht in diesem Fall schon Sinn PHP selbst zu kompilieren, denn z.B. heute wurde PHP5.2.1 released. Ich will den sehen, der mir für jede Distribution ein aktuelles Paket zeigen kann ;) Das ist natürlich bitte nicht als persönlicher Angriff zu werten.

So, nun gehts weiter.
Apache, bzw. suPHP muss ja wissen, wie es mit .php etc umspringen muss.
Code: 
<Directory "/srv/www">
php_admin_value engine off
suPHP_Engine on
AddHandler x-httpd-php .php .php3 .php4 .php5
suPHP_AddHandler x-httpd-php
</Directory>
Somit haben wir dann das Modul (PHP) ausgeschaltet, suPHP eingeschaltet.
Über admin.pl muss die Geschichte jetzt noch auf suPHP umgestellt werden.
Des Weiteren ist es von Vorteil, wenn man in der confixx_main.conf
Code: 
# optional if suphp is compiled with --paranoid option
# it adds suPHP_UserGroup ##user## ##user## directive to vhost
$suphp_paranoid = '';
auf 1 stellt.
Sprich:
Code: 
$suphp_paranoid = '1';
Somit wird suPHP_UserGroup ##user## ##user## bei jedem Host hinzugefügt. Damit weiß suPHP dann mit welchem User und welcher Gruppe Scripte ausgeführt werden sollen.

Ich hoffe ich konnte ein wenig zur Klärung beitragen.


*bei Serveradmin24 (Visas) von Strato wird eine gepatchte Version von suPHP eingesetzt. Hier ist suexec von Nöten, da der Patch aus suPHP, CGI und FastCGI besteht. Dies nur nebenbei.
 
Last edited by a moderator:
*edit* ich nehm alles zurück... es läuft doch noch nicht wie es soll ;)

Bei mir läuft php scheinbar nicht als cgi-version, daher habe ich beim handler in der suphp.conf
Code: 
x-httpd-php=php:/usr/bin/[B]php5[/B]
angegeben, das ist aber falsch oder?
php5-cgi existiert nicht.... Achso, woher weiß suPHP eigentlich dass die suphp.conf in etc liegt? (Hab sie da jetzt einfach angelegt, ohne irgendwo darauf zu verweisen...)


wenn ich jetzt ein php-script via http ansteuere bekomme ich nen 500er Fehler.

Im Apache-log steht folgendes:
Code: 
No user or group set - set suPHP_UserGroup
 
Last edited by a moderator:
Hallo.

Zu dem Fehler:
Du musst zuerst in der confixx_main.conf das auf 1 stellen und dann suPHP aktivieren. Und dann muss das Updatescript von Confixx da komplett drüber laufen. Dann wird bei jedem vHost das entsprechende hinzugefügt.

Good luck!
 
Abend,

es hat jetzt endlich funktioniert und suphp läuft jetzt anstandslos.... danke für die Unterstützung!

allerdings ist nun ein weiteres Problem hinzugekommen:
Sobald eine Session geschrieben werden soll, wird versucht diese in folgenden Pfad zu schreiben "/var/lib/php5". Durch suPHP wird das logischerweise verhindert.

Ich nutze ja Confixx - ich könnte doch wenn nun mod_php benutzt würde, einfach über httpd_spezial für jeden neu angelegten Kunden ein php_flag setzen, dass mir die "session.save_path"s für die einzelnen User in ihr eigenes Verzeichnis setzt. Wie aber mach ich das nun mit suPHP? Ich hab gesucht und gesucht, aber nichts vergleichbares wie die php_flags für suPHP gefunden... gibt es das überhaupt?
Die andere Alternative, die ich bevorzugen würde, wäre dass beim Erstellen der user-php.ini aus Confixx der session.save_path direkt richtig auf das user-tmp gesetzt wird, aber wie stell ich das an?

Viele Grüße,
Robin
 
Hallo.
Bitte Folgendes auf 1 stellen:
Code: 
#if 1 it parses httpd specials for php_admin_flag and php_admin_value
#and put the settings into the domain php.ini
#if 0 print it as is
$php_special = '';
Befindet sich in confixx_main.conf.

Dann wird es automatisch in die jeweilige php.ini vom Confixx-Updatescript geschrieben.

Dann sollte es gehen.
 
Hey Leute ich versuch seit heute morgen 11Uhr das blöde Confixx zum laufen zu bekommen!....

Jetzt sieht man schonmal die Oberfläche aber keine Buttons... Ich werd noch verrückt... :(

Confixx Professional

was hab ich falsch gemacht? achja es war eine confixx neuinstallation.. also kein update....
 
Hallo,

du hast hier wohl den falschen Thread erwischt.
Es sieht so aus, als ob du einen Hetzner-Server hast.

Eröffne doch bitte einen separaten Thread, der sich auf eine Confixx Installation bezieht.

Ich habe brauche für die Installation von Confixx auf einem Hetzner (Debian) ca. 1 Stunde.
 
server4downs said:
So, nun gehts weiter.
Apache, bzw. suPHP muss ja wissen, wie es mit .php etc umspringen muss.
Code: 
<Directory "/srv/www">
php_admin_value engine off
suPHP_Engine on
AddHandler x-httpd-php .php .php3 .php4 .php5
suPHP_AddHandler x-httpd-php
</Directory>
Somit haben wir dann das Modul (PHP) ausgeschaltet, suPHP eingeschaltet.
Über admin.pl muss die Geschichte jetzt noch auf suPHP umgestellt werden.
Click to expand...

Ich hätte dazu auch noch eine Frage.
Wo am besten schreibt man obige Zeilen rein?
Legt man dafür irgendwo am geschicktesten eine separate Datei an, oder benutzt man dafür eine bestehende.
Die Directive Directory "/srv/www" habe ich bei mir nirgends, aber in der default-server.conf habe ich ein "/srv/www/htdocs".
Ich denke mal, in der confixx_mhost oder den confixx_vhost Dateien sind manuelle Änderungen eher ungeschickt, da diese durch Confixx erstellt werden.

Ich frage deshalb, weil ich auch so meine Probleme habe, suphp unter Confixx-3.21pro (Suse Linux 9.2 bei webperoni) zum laufen zu bekommen.
Ich habe suphp ohne Fehler compiliert und installiert, das Modul in /etc/sysconfig/apache2 der Liste hinzugefügt, in admin.pl dann aktiviert und updatescript laufen gelassen.
Durch admin.pl und Updatescript wird in der confixx_mhost.conf die suphp Engine angeschalten und die ganzen php_admin Flag Geschichten wurden dann in separate php.ini Dateien übernommen.
Aber, es scheint so, dass php Dateien nicht mit suphp ausgeführt werden sondern immer noch mit mod_php4. Schmeisse ich das php4 Modul aus der Config raus, werden mir dann php Dateien zum Download angeboten.

Wo ich diesen Thread hier jetzt gelesen habe, bin ich nun auf den suphp_AddHandler aufmerksam geworden. Mit ist nur nicht ganz klar, wohin damit am geschicktesten. Reicht es diesen innerhalb einer Directory Direktive unterzubringen, oder muss der Eintrag dann auch in jede vhost rein?

Danke.

Gruss
Markus
 
Hallo,

einfach in die apache2.conf vor den Confixx-Include-Anweisungen.
Du musst halt auch noch schauen, wo deine Kunden liegen, falls sie eben nicht in /srv/www/htdocs liegen, sondern z.B. /var/www oder so, dann muss die Pfadangabe selbstverständlich entsprechend geändert werden.
Es ist nicht nötig diese Angaben für jede vHost-Datei zu machen.

Ich hoffe ich konnte weiterhelfen.

P.s: Wie bereits schon beschrieben: PHP4/5 als Modul darf nicht aus der Konfiguration entfernt werden, sondern nur per engine off deaktiviert werden. Ansonsten wirst du viel unnötige Handarbeit vollziehen müssen ;)
 
You must log in or register to reply here.
Back
Top