Installation of suPHP using Apache2 & PHP5

suPHP is a nice tool for executing PHP scripts with the permissions of their owners. It’s comparable to suexec (which is for perl scripts). When using this tool, you don’t need SafeMode any longer, etc…

Tested on: SuSE 10.0, openSuSE 10.1
Prerequisites: php5-fastcgi, autoconf, gcc

in openSuSE 10.1, I had to (soft)link some files:
ln -s /usr/include/apr-1/* /usr/include/apache2

configure in openSuSE 10.1:
./configure --with-apxs=/usr/sbin/apxs2 --with-php=/usr/bin/php5 \
--with-logfile=/var/log/apache2/suphp.log --with-min-uid=30 \
--with-min-gid=30 --with-apache-user=wwwrun \
--with-apr=/usr/bin/apr-1-config --with-setid-mode=owner \
--prefix=/usr --sysconfdir=/etc


configure in SuSE 10.0:
./configure --with-apxs=/usr/sbin/apxs2 --with-php=/usr/bin/php5 \
--with-logfile=/var/log/apache2/suphp.log --with-min-uid=30 \
--with-min -gid=30 --with-apache-user=wwwrun \
--with-apr=/usr/bin/apr-config --with-setid-mode=owner \
--prefix=/usr --sysconfdir=/etc


After that, usual way:
make; make install

Check your configuration at /etc/suphp.conf. For me, it looks someway like this:
[global]
logfile=/var/log/apache2/suphp.log
loglevel=info
webserver_user=wwwrun
docroot=/srv/www/htdocs
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false
check_vhost_docroot=false
errors_to_browser=false
env_path=/bin:/usr/bin
umask=0022
min_uid=30
min_gid=30
;
[handlers]
;Handler for php-scripts
x-httpd-php=php:/srv/www/cgi-bin/php5
;Handler for CGI-scripts
x-suphp-cgi=execute:!self


Add suPHP module to your apache config (/etc/sysconfig/apache2):
APACHE_MODULES="access .... php5 suphp"

Create a new file to tell apache to use suPHP:
/etc/apache2/httpd.conf.local
<Directory "/srv/www/htdocs">
php_admin_value engine off
suPHP_Engine on
AddHandler x-httpd-php .php .php3 .php4 .php5
suPHP_AddHandler x-httpd-php
</Directory>


Include that in your apache configuration (/etc/sysconfig/apache2):
APACHE_CONF_INCLUDE_FILES="httpd.conf.local"

After restarting apache, it should be done ; )

exim / implementing greylisting without db

I had greylisting running for a while with a little perl script, that only worked with ip-addresses. As spam is growing an growing, I wanted to use the whole triplet (ip/sender/recipient) for the filter.

As I did not want to use a database backend, the decision led to greylistd – an easy configurable daemon. I needed the packages for (open)SuSE, that can be found in openSuSE’s software repository.

After installing it and checking the basics at /etc/greylistd/config, you have to add a little code to your acls in exim.conf, i.e.:

defer message = greylisted $sender_host_address. please try again later
condition = ${readsocket{/var/run/greylistd/socket}\
{--grey $sender_host_address $sender_address $local_part@$domain} {5s}{}{false}}


That was all I had to do to get it working. It’s advisable to add some hosts, that are known for problems with greylisting, not to be checked. Therefor you have to extend your acl:

defer message = greylisted $sender_host_address. please try again later
!hosts = : ${if exists {/etc/greylistd/whitelist-hosts}\
{/etc/greylistd/whitelist-hosts}{}} : \
${if exists {/var/lib/greylistd/whitelist-hosts}\
{/var/lib/greylistd/whitelist-hosts}{}}
condition = ${readsocket{/var/run/greylistd/socket}\
{--grey $sender_host_address $sender_address $local_part@$domain} {5s}{}{false}}


Many thanks for the documentations from Arne Schirmacher and Ben Charlton.

exim / remove (all) frozen messages from queue

Just a quick & dirty hack to delete frozen messages for a single / some recipient(s)…

#!/bin/bash
#
# what are we searching for?
# (part of the email-address)
SEARCH="anyrecipient.tld"
#
# exim-bin
EXIM=`which exim`
#
# execute (frozen messages only)..
$EXIM -Mrm $(mailq | grep $SEARCH -B1 | grep frozen |cut -c 11-27)


Thanks to Mark -> this can be done a lot of easier if you want to kill all frozen messages:

exiqgrep -z -i | xargs exim -Mrm

If you want to do this only for some domains / email-addresses, use the first example.

PAM-Authentication & MySQL (v5) / b1gMail

Enviroment:

  • SuSE Linux 10.1
    • pam-0.99.3.0-29.3, pam-modules-10.1-7
    • postfix-2.2.9-10
    • mysql-5.0.18-20.8, mysql-client-5.0.18-16

I was trying to implement SASL-authentication via PAM (which is using a mysql-backend) in a postfix installation.
Output from maillog:

postfix/smtpd: warning: SASL authentication failure: Password verification failed
postfix/smtpd: warning: [x.x.x.x]: SASL PLAIN authentication failed


Checking the syslog:

saslauthd: pam_b1gmail: cannot connect to mysql database
(Access denied for user 'xx'@'localhost' (using password: YES))
saslauthd: DEBUG: auth_pam: pam_authenticate failed: Permission denied
saslauthd: do_auth : auth failure: [user=xx] [service=smtp]
[realm=domain.tld] [mech=pam] [reason=PAM auth error]


Reason:
The PAM module is using a deprecated way to connect to the MySQL-DB.

Solution:
Set the MySQL-Password to OLD_PASSWORD:

SET PASSWORD FOR user'@'localhost' = OLD_PASSWORD('password');

VMware / time sync with linux guests

In my default configuration, time was running way too fast in VMware linux guests. After spending hours of searching howto solve the problem, I finally found a few different points that might work as a solution.

Enviroment:
Host: SuSE Linux 10.1
Guest: SuSE Linux 10.1
VMware Server: 1.0.2

  • Install the vmware-tools on the guest.
    Don’t forget to install the kernel-sources if you have to recompile some modules.
  • Insert clock=pit into the guest’s kernel boot options.
    When you’re using grub, it kinda looks like this:
    kernel /vmlinuz root=/dev/sda3 apm=off acpi=off clock=pit
  • Set tools.syncTime = “TRUE” in your virtual machine .vmx-file
    (found on the host machine [default in /var/lib/vmware/..])

    Your guest has to be rebooted to activate this setting.
  • Finally, I had to change a little thing on the host machine:
    Disable powersaved (or powernowd or whatever applies to you)

From that time on, my guests are perfectly in sync with the host’s time.

Note: Nov, 23th 2007: .. or not … time is still too fast on some virtual machines : (

Next thing I tried right now is to add the following lines in /etc/vmware/config:
host.cpukHz = 2200000
host.noTSC = TRUE
ptsc.noTSC = TRUE

Where 2200000 (2,2 GHz) is the max speed of the host cpu.

+ Updated to VMware Server 1.0.4
^^ At first sight, this works perfectly for me : )

Useful Links: