A simple munin plugin for graphing Ironport statistics. All it graphs is CPU, memory, disk IO and queue utilisation. It requires SNMP to be enabled on the Ironport (and assumes you’re using SNMP v3) and snmpwalk to be installed on the munin server. The plugin supports the following environment variables:
* snmp_community – by default set to v3get (default Ironport setting)
* snmp_password – you have to set it yourself
* snmp_oidbase – set to 1.3.6.1.4.1.15497.1.1.1 which points at Ironport’s MIBS.
Save it as ipstatus_ and link to it via ipstatus_yourironporthostname
Posted in other | No Comments »
I run most of the services in separate jails (that’s all easy to set up and maintain with ezjail) and quite often end up having 10+ jails even on simple mail/web server installations.
Installing portaudit, updating its database and running it every day in each jail seems to be a waste of space and resources. Instead I decided to check all jails from the host system during nightly security checks.
This should be saved as /usr/local/etc/periodic/security/420.jailportaudit (with chmod 555):
#!/bin/sh
RET_VAL=”"
get_jail_name()
{
jid=$1
RET_VAL=`jls | egrep “^ +$jid ” | awk ‘{print $3}’`
}
check_jail()
{
jid=$1
get_jail_name $jid
echo “==== checking jail :: ” $RET_VAL ” :: ====”
/usr/sbin/jexec $jid pkg_info | /usr/bin/awk ‘{print $1}’ | /usr/bin/xargs /usr/local/sbin/portaudit
echo
}
main()
{
param=$1
for i in `jls | tail +2 | awk ‘{print $1}’`
do
check_jail $i
done
}
main $@
Posted in bsd | No Comments »
Looks like there’s a hidden command you can use to fix queue problems similar to these:
Critical: Queue: Your queue has been corrupted; UNABLE TO REPAIR: unable to
mount queue: ‘(\’qstore/gcq.py get_time_sorted_gens|919\’, “
\'exceptions.OSError\'>“, “[Errno 2] No such file or directory:
\’/var/db/godspeed/gen/gen063.chk\’”, \’[qstore/gcq.py mount|1387]
[qstore/gcq.py load|996] [qstore/gcq.py get_time_sorted_gens|919]\’)’
Critical: Error while sending alert: Unable to send System/Critical alert to xxx@xxx.com with subject “Critical ironport: Queue: Your queue has been corrupted; UNABLE TO REPAIR: unab…”.
What it means is basically that the workqueue is corrupted and the ironport is unable to accept/deliver emails. Rebooting doesn’t help (doesn’t really change anything). There’s however a way of recovering your ironport from this problem. The hidden command is:
resetqueue
It deletes the broken queue, creates a new one, removes all messages in the system quarantines and reboots the ironport. After this clean up operation your ironport should be as new.
What’s interesting is that by looking at various error messages thrown by Ironports from time to time (especially when something breaks more seriously – doesn’t happen too often Ironports are quite solid) you can actually see what’s running under the hood. Other than it running on something derived from FreeBSD (can’t be that far off it as they actually contribute some code back to the OS) it looks like it’s mostly run by python scripts. That’s interesting from the performance perspective as even the queue management seems to be written in python. Also the database used internally seems to be some version of PostgreSQL. A very nice choice of software…
Haven’t seen anything yet that would suggest what MTA (if it’s not something created by Ironport) is used there. Sure the fact it can write qmail compatible log files doesn’t mean anything 
)
Posted in bsd, other, postgresql | No Comments »