Posts Tagged ‘SLES’

26. November 2012


In: Allgemein, Tech

Kommentare deaktiviert für No Bullshit #1: Apache vhost config AllowOverride All does not activate mod_rewrite

This is beginner’s talk, but I have seen it too many times anyway.

A lot of tutorials on the web claim that you have to state „AllowOverride All“ in an apache config and it magically activates mod_rewrite somehow.

This is all bullshit. Your mileage may vary, you may be lucky on debianish systems. It’s not very secure anyway.

Here’s what you do instead:


yourserver:# /etc/apache2/conf.d # a2enmod rewrite
yourserver:# /etc/apache2/conf.d # vim /etc/apache2/vhosts.d/

 DocumentRoot /srv/www/
  Options +FollowSymlinks
  RewriteEngine On
  ## put your rewriting-related .htaccess file content here, for example wordpress
  RewriteBase /
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
  ## end put stuff here
  ## ... more vhost stuff to follow

  ## finally
  Order allow,deny
  Allow from all
 yourserver:# rcapache2 reload


yourserver:~# /etc/apache2/conf.d # a2enmod rewrite
yourserver:~# vim /etc/apache2/sites-available/ 

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/

                Options FollowSymLinks
                AllowOverride None

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
                Options Indexes +FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
     ## more debianish vhost stuff
     ## ...
     ## finally
yourserver:/etc/apache2/conf.d # a2ensite
yourserver:/etc/init.d/apache2 reload

Here’s the explanation why:

AllowOverride allows a special hidden file .htaccess in any directory of your vhost to override settings from your apache vhost configs, especially security-related stuff like URL rewriting and symlink behaviour. This is fine for your hacky development setup but you do not want this in production. First, it’s slow because every lookup has to check for a .htaccess file and parse it if present. Second, it’s a hassle to debug once something screws up. Something will screw up at some point. Usually you are better off configuring your vhost properly.

Why does it work on debian?

Debian systems often have mod_rewrite enabled (loaded) but not active (working) in the default config. Allowing .htaccess files to magically activate them will work in many cases and provide a confusing problem for the rest.

Why doesn’t it work on openSUSE 12 and SLES 11??

SLES is optimized for enterprise environments where security counts. If you don’t enable overriding, it’s usually turned off. If you don’t enable mod_rewrite globally or for the site, it won’t magically be loaded later on. This leads to more tedious work but also a more predictable environment for admins under fire.

Stop confusing people. Tell them how to do it right and make them understand why it works. It will spare you trouble.

15. März 2012


In: OpenSUSE

Kommentare deaktiviert für php5.3 packages in SLES 11 SP2

SLES 11 SP2 ships php5.3 binaries but the default package php5 still installs php5.2 which already has reached upstream end of life and should be considered unsupported by any means. Recent versions of phpunit and other developer tools won’t provide all features on php5.2 any more.
You must use apache2-mod_php53, php53, php53-mysql and so on if you want to use php on SLES.

26. Oktober 2010


In: horde, Tech

Kommentare deaktiviert für Horde Updates: Base module 3.3.10 RPMs for SLES and OpenSUSE

New Horde Version available as OpenSUSE package

Horde just released version 3.3.10 of their base application along with some minor updates to imp and dimp. After 3.3.9 had some regressions that caused trouble editing preferences, I decided to upgrade the horde RPMs for OpenSUSE and SLES 11 to the new release. This also removed the dependency on PHP versions lower than 5.3 as the package is now working with the default openSUSE 11.3 php package.

Splitting  into vanilla horde and Kolab patched version

Releases of the horde rpm and some application packages contained some dated patches for working together with the Kolab groupware server. I asked upstream Kolab author Gunnar Wrobel and he suggest a clean split between a standard and a kolab version of the horde package. Beginning with the next updates of the package I will implement this split offering two conflicting versions.

Turba LDAP driver patch

The LDAP backend driver for the Turba Contact Manager makes some optimistic assumptions on the privileges (ACLs) 0f the binding LDAP user. By default, it assumes it can add new contacts (which is not true for typical company addressbooks) and if you have ACLs to only some attributes of an entry, for example your own work phone but not your name or job title, Turba tries to write the whole entry.
I submitted a patch for the Turba LDAP driver which makes Turba only try to write attributes which have actually changed.