At our company we run zimbra as our collaboration tool and we use zabbix as our monitoring solution. Almost every service we have is monitored nicely, but unfortunately our zimbra was not. Because zimbra exists out of several services you want to know the status of every service. For that I wrote a little script.

First of all the zabbix agent configuration:


UserParameter=zimbra.clamav,/etc/zabbix/check_zimbra.sh antivirus
UserParameter=zimbra.spam,/etc/zabbix/check_zimbra.sh antispam
UserParameter=zimbra.logger,/etc/zabbix/check_zimbra.sh logger
UserParameter=zimbra.mailbox,/etc/zabbix/check_zimbra.sh mailbox
UserParameter=zimbra.mta,/etc/zabbix/check_zimbra.sh mta
UserParameter=zimbra.snmp,/etc/zabbix/check_zimbra.sh snmp
UserParameter=zimbra.spell,/etc/zabbix/check_zimbra.sh spell
UserParameter=zimbra.stats,/etc/zabbix/check_zimbra.sh stats


This use the custom check_zimbra:

#!/bin/bash

check=$1
maxage=30
file='/tmp/zimbra_status'

#check if file exists
if [[ -e $file ]]
then
OLD=`stat -c %Z $file`
NOW=`date +%s`

export PATH=$PATH:/opt/zimbra/bin
# if older then maxage, update file
if [[ `expr $NOW - $OLD` -gt $maxage ]]
then
sudo -u zimbra zmcontrol status > $file
fi

else

export PATH=$PATH:/opt/zimbra/bin
sudo -u zimbra zmcontrol status > $file
fi

AVSTATUS=`cat $file |grep $check|awk '{ print $2 }'`

if [[ $AVSTATUS != "Running" ]]; then
echo 0
fi

echo 1

As you can see we store the output of the slow zmcontrol in a file for a configurable amount of time. This way you can cache that output and win some time.
For this to run you need to add the next rule to the /etc/sudoers file:


zabbix ALL=(zimbra) NOPASSWD:/opt/zimbra/bin/zmcontrol


Has anyone a clue on this one ?

sudo cat /proc/sys/fs/file-max
1048576

sudo cat /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576

sudo cat /etc/sysctl.conf
fs.file-max=1048576

ulimit -n
1048576

But yet when my service starts at boot:

sudo cat /proc/pid/limits | grep files
Max open files 1024 1024 files

Whenever I restart my service everything is ok:
sudo cat /proc/pid/limits | grep files
Max open files 1048576 1048576 files

This is running on a Debian Etch with kernel 2.6.28

On the openfire-forum and on a lot of others is this the subject of many threads, however it almost works out of the box.

I'm running 3 domains which all like jabber support. Lazy as I am, I just want to maintain one jabber-server instance. All 3 domains are being authenticated on the same LDAP-server.

Openfire version: 3.3.3

Result is that all users of all domains are able to login and chat with each other. Users of the not default domain are also able to use the groupchats. But not everything is ok, there are also some issues:

Users of the not default domain:

• aren't listed
• show up as member of the default domain
• Not only show up as those, but for access lists you have to use the default domain. So this could give a user conflict

At our new company we have a dedicated MySQL database machine and we use OTRS for ticketing.

The thing is when you use the packages provided by otrs, you end up installing mysql-server on the otrs-machine. And that's just what I didn't want to do. So instead of just complaining I edited the spec files, the rcotrs-config files and rebuilded the rpm.

Now you don't need to install mysql-server anymore and the otrs init file isn't checking anymore for a running database. However the otrs init still tests the connection to the database. Just what we want.

You can download the src rpm here and the normal rpm here. In the src rpm you also find the spec files for the other supported plaforms (redhat 7.x, redhat 8.0, suse from off 7.3)

These days if you are using the latest svn with berkely db, this is not one of your problems. Auto-recovery is build-in.

But for people like me that stick by their old svn for various reasons it is a waist of time for recovering every corrupted repository. For making it yourself easy, you make a script for that, that you hit when you noted that a repository was corrupted. But still, not easy enough. So you make a script that checks every repository configured and if one is corrupted, fixing it at the same time. Good, now we are getting there, but still. Sometimes the check will hang endlessly and so will your script. So what then?

Expect. Use expect to check your repository and add a timeout. So when the check will hang, kill it after the timeout is reached.
Expect expects various outputs of the command it executes, and for each expect rule you can do something. For instance giving it an exit-code.

I noted something quiet important, expect 5.42 only compares to the last line of a multi-line response of the command it executes.

You can find my script here.

Almost everything is configurable, even mail notification.

You can add this script to your cron tasks, so you just have to do nothing IF one fails.

All admins of advanced Apache setups will cross this problem someday. So did I :)

You have some nice reverse proxy setup, everything working just fine, except that one redirect that happens on one of the backend machines to a non default port.
You have no choice then redirect that to a default port. I searched long after this, and with me a collegue

Lets say when you surf to http://myhost.mydomain.com, you are proxied to backend server with ip 193.155.88.23. End for example that backend server redirects you to a non-default port like 8443. And you end up with your browser going to 193.155.88.23:8443 directly. If these ports aren't blocked already, you'll probably go to somewhere completely different.
Normal redirects are catched by your proxy and you'll not see a thing, but not these.

Everybody knows the mod_rewrite module, but that only handles request headers. For this you need to change to response headers. You could do this with some fancy stuff with something self written for using mod_perl or so, but the solution is by far more simplier.

mod_headers is the answer to this problem:

In your VirtualHost config for that machine on your proxy:

Header edit Location ^https://193.155.88.23:8443 https://myhost.mydomain.com

This will have as a result that the location header send by your backend server will be changed to https://myhost.mydomain.com if it starts with https://193.155.88.23:8443. Your browser directly go to https://myhost.mydomain.com and problem is solved.