-------- 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!
Month: November 2012
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.