bookmark_borderHorde 3 End of Life after 8 years – It was a great time.

-------- Original-Nachricht --------
Betreff: [announce] End Of Life for Horde 3
Datum: Tue, 27 Nov 2012 13:21:17 +0100
Von: Jan Schneider <jan@horde.org>
Antwort an: core@lists.horde.org
An: announce@lists.horde.org, vendor@lists.horde.org, horde@lists.horde.org

The Horde Team is announcing the End Of Life (EOL) for the Horde 3
release series.

With the final release of Horde 5 the state of the following release
series is updated:

Horde 3: EOL
Horde 4: Security Fixes
Horde 5: Bug Fixes

Please see http://wiki.horde.org/Doc/Dev/ReleaseCycle for details
about the Horde release cycle and
http://www.horde.org/development/versions for the affected applications.

Horde 3 had been a huge milestone in Horde's history and has served us
well for 8 long years. We really hope you enjoyed it too. We know it's
still in use in many, many places, and we like to encourage everyone
to upgrade to the latest version which is such a huge improvement over
the now outdated Horde 3 line.

Thank you, Horde 3, and thank you, everyone who made it such a great
success!

bookmark_borderNo 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:best acquistare dianabol 25 mg online in italia

(suse)

yourserver:# /etc/apache2/conf.d # a2enmod rewrite
yourserver:# /etc/apache2/conf.d # vim /etc/apache2/vhosts.d/www.somesite.com.conf
<VirtualHost *>
 DocumentRoot /srv/www/somesite.com/wordpress
 ServerName www.somesite.com
 ServerAdmin ralf.lang@somesite.com
 <Directory /srv/www/somesite.com/wordpress>
  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
 </Directory>
</VirtualHost>
 yourserver:# rcapache2 reload

(debian)

yourserver:~# /etc/apache2/conf.d # a2enmod rewrite
yourserver:~# vim /etc/apache2/sites-available/www.somesite.com 
<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName  www.somesite.com
        DocumentRoot /var/www/somesite.com/www
        <Directory />

                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/somesite.com/>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>                Options Indexes +FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>
     ## more debianish vhost stuff
     ## ...
     ## finally
</VirtualHost>
yourserver:/etc/apache2/conf.d # a2ensite www.somesite.com
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.

Fondos de pantalla varón fisicoculturismo fitness entrenamiento músculos deporte descargar imagenes lo esencial winstrol ahorra en manualidades codigo promocional envio gratis: revisa los leggings deportivos top seller mujer push up leggings fitness patchwork y pantalones elásticos entrenamiento de culturismo pa.

bookmark_borderjappix needs php-mbstring and will fail on SLES11

jappix is a fine piece of xmpp (jabber) based community building software.
Sadly, its installer needs php-mbstring (for SLES 11 SP2, this is php5-mbstring or php53-mbstring depending on your php choice). Sadly, it hides any error messages before requiring this crucial library. You will never know until you investigate closely.

Or as some person on the web paraphrased in German: was meinst du mit testsuite?
Software should not behave that way. Test suites and installers like jappix’ setup.php should know how to handle missing dependencies and show them to users.

Debian is not affected. By luck or purpose, debian ships mbstring with the basic php package.