Intense Life

The last weeks I investigated server side optimization (not application optimization) issues further because our Joomla based web portal scales quite poorly. The server is still sufficient for our current load but I want to have some more resources for usage peaks and future development. I thought it would be nice to share my thoughts and experiences as appropriate tutorials are scattered all over the web. I will describe the main steps in brief and will link to further documentation at the web if possible and needed.

So far so good. Currently our application uses the following server software:

• Joomla 1.5 as web application
• PHP 5.2 with ZendOptimizer 3.3 as our only must have PHP extension
• Apache httpd 2.2 as web server
• Varnish 2 as reverse caching proxy for Java and PHP apps.
• MySQL 5.0 as database management system
• Gentoo Linux as server OS

Our website makes intensive use of Joomla extensions. Some of them were developed by our own IT department. The start page is news oriented and contains several extensions and also many images. Apart from that we have quite a few registered users which use interactive parts of the site like forums or lotteries. Additionally some content of the site is only available to privileged users.

With this information you should have a rough overview of our web site and the application comprehending my optimization efforts. The next part of the series will contain information about bringing MySQL to speed.

Comments are as always welcome
Phillip

Ah. Silly me. I experimented with the drupal caching options just before installing the WYSIWYG module and wondered why the editor was not showing up.

The solution was as obvious as simple: I had to disable or clear Drupal's JavaScript and CSS cache after installing the WYSIWYG plugin.

Hopefully you read this before long searching. Additional clues can be found in this drupal forum post ( http://drupal.org/node/426398 ).

I am very happy to announce that my enhancements to the Grails Spring Security Plug-in (Acegi Security Plug-in http://grails.org/plugin/acegi) based on Stephan February's work were integrated into the main Plug-in source tree. Burt Beckwith, the Plug-In maintainer, did the integration including further features (e.g. annotation based configuration) and polishing.

The official announcement including an example application can be found on his blog (http://burtbeckwith.com/blog/?p=287).

Thank you for your great work Burt!

I recently stumbled upon a problem of a big evolutionary grown qmail/vpopmail installation when we moved the installation to a new server.

Virtual accounts created years ago were created with a different vpopmail installation located in a different filesystem path. For this reason accounts had different paths set up in the /var/vpopmail/domains/domain.tld/vpasswd.cdb file. Regrettably there is (at least afaik) no possibility to change these paths with vpopmail commands like vmoduser or similar.

To avoid always creating symbolic links from the old directories to the new account directories I found a way to modify/update these paths. Normally values in the plain text vpasswd (not the .cdb one mentioned before) file get overwritten every time you update/delete or create accounts with the values from the vpasswd.cdb file. However if only the vpasswd file and not its .cdb counterpart is present the vpasswd.cdb file will be regenerated with the values from the vpasswd file.

So if you want to change paths, do the following:

#copy old vpasswd to a new location
cp vpasswd vpasswd.new
# edit vpasswd.new to suit your needs
vim vpasswd.new
# shutdown your mailserver services for some seconds to prevent regeneration of the vpasswd.cdb file before you are ready (check if you may do this before!)
/etc/init.d/svscan stop
cp vpasswd.new vpasswd
#remove cdb file
rm vpasswd.cdb
# create a testuser for the appropriate domain, to regenerate cdb file
vadduser testuser[the at char]domain[the dot char]tld
# delete testuser
vdeluser testuser[the at char]domain[the dot char]tld
# start mailserver services again
/etc/init.d/svscan start

Normally a shutdown time of a few seconds should not be critical for a mailserver, because sending servers normally have queue lifetimes much longer than this and sending users can wait a few seconds anyway, eh ;-)?

You should however check this first!

If you put the lines above in a appropriately changed script downtime can be less than 5 seconds.

Hope this helps,
Regards,
Phillip

Wegen eines unfallbedingten Schadens musste ich mein Notebook am 12.11.2009 zum Lenovo Support/Geodis Gmbh in Heppenheim einschicken. Da der Schaden unfallbedingt war, fiel er nicht unter die Garantie. Auf Nachfrage nannte mir der Lenovo Mitarbeiter eine ungefähre Bearbeitungsdauer von 4-7 Werktagen.
Leider kam das Notebook erst am 1.12.2009 wieder bei mir an, was einer Bearbeitungsdauer (bei Eingang am 13.11. und Ausgang am 30.11.) von 12 Werktagen entspricht. Also fast doppelt so viel wie angekündigt.
Bisher war mir der Support auch aus eigener Erfahrung nur als tadellos bekannt. Ich hoffe mal, dass sich Derartiges nicht wiederholt. Als Informatiker in seinem Studium auf sein Notebook verzichten zu müssen, macht einen nämlich nicht unbedingt produktiver :-).

Grüße
Phillip

A few days before I stumbled upon a problem with our OpenSSH (net-misc/openssh-5.2_p1-r3) based SFTP solution. Although passwords were not changed SFTP logins did not work any longer whereas normal SSH logins with the same accounts continued working.

The concerning - now working - SSHD config looks like this (except AllowUsers):

Port 22
Protocol 2
LogLevel INFO
SyslogFacility AUTH
LoginGraceTime 60
PermitRootLogin no
PasswordAuthentication yes
KeepAlive yes
# this must be set to no and PasswordAuthentication to yes. Otherwise SFTP will not work!!!!
UsePAM no
PrintMotd no
PrintLastLog no
ClientAliveInterval 30
ClientAliveCountMax 10
Subsystem       sftp    internal-sftp
Match Group sftponly
    ChrootDirectory /home/%u
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTcpForwarding no

After more than one hour of trial and error I found out, that UsePAM must be set to no and PasswordAuthentication must be set to yes. All other combinations of these two options kill sftp authentication (sys-auth/pambase-20090620.1-r1 with ssh USE flag enabled).

As I am not using pam's advanced authentication functions this deactivation is not a problem to me.
So, finally, if you encounter strange authentication issues with sftp try to disable pam auth and see if sftp authentication is working again afterwards.

Regards,
Phillip

PS If you know another solution to this problem or if I somehow messed up my config please let me know.

Recently I created a gentoo ebuild for the 0.4 version of the KDE 4.3 service menu manager (http://www.kde-apps.org/content/show.php/Service+Menu+Manager?content=94996):

# Copyright 1999-2008 Gentoo Foundation
# Author Phillip Merensky
# Distributed under the terms of the GNU General Public License v2
 
EAPI="2"
 
inherit kde4-base
 
DESCRIPTION="This app is a System Settings module to manage service menus."
HOME_PAGE="http://www.kde-look.org/content/show.php/Service+Menu+Manager?content=94996"
KEYWORDS="amd64 x86"
IUSE=""
SRC_URI="http://linux.wuertz.org/dists/sid/main/source/kcm-servicemenus_${PV}.tar.gz"
SLOT="4.3"
 
DEPEND="kde-base/kdelibs:${SLOT}"
 
S="${WORKDIR}/kcm-servicemenu"
 
src_unpack() {
    unpack ${A}
    cd "${S}_build"
}
 
src_compile() {
    S="${WORKDIR}/kcm-servicemenu_build"
    cd "$S"
    emake || die "Make failed!"
}

Save it as service-menu-manager-0.4.ebuild in your favorite category (I prefer kde-misc) in your custom overlay, execute

ebuild service-menu-manager-0.4.ebuild digest

While customizing this homepage I came across the following problem: I wanted to rewrite every request which accesses the root of this page to access the subfolder "drupal". This way t is possible to use "www.phillme.de" to see the blog and additionally allow subfolders on the same level as the "drupal" directory.

My first guess was to use the following in a .htaccess-file in the document root:

RewriteEngine on
RewriteRule	^/$	/drupal/

Sadly enough it did not work although the url rewriting guide of apache at http://httpd.apache.org/docs/2.2/rewrite/rewrite_guide.html exactly mentions the same solution for a moved document root.

The solution described there is the following, which is very similar to my initial yet not working attempt:

RewriteEngine on
RewriteRule   ^/$  /about/  [R]

Of course I also tried the "[R]" for redirect with the same problem. The redirect was not triggered. Fortunately I found another site with "very common mistakes" about rewrite rules (http://rewriterule.alantait.com/4/). It mentions that the RewriteRule does NOT have the beginning "/" which transforms my initial solution to

RewriteEngine on
RewriteRule	^$	/drupal/

I am wondering if this is an error in the apache documentation or if I just got something wrong. Maybe someone can brighten the for me. All others may consider the solution above ;-).

Hello folks.

Finally I found the time to start my own blog/website. I will blog about technical problems and other things that keep me busy hoping to help other people with similar problems.

So stay tuned

Regards,
phillme