Yum update check script – runs via crontab and emails when new updates are available
Here's a quick script that will check yum updates and email you when there are new updates available.
Split into two sections, one script is for all package updates, and the other script is for letting us know if we need to reboot when a new kernel package has been installed.
Script to check for updates:
check-yum-updates.sh
#!/bin/bash
#
# check-yum-updates.sh
#
# checks for yum updates and emails if there are any available
#
#
# Eric Thern
# Zoidial Incorporated
# http://www.zoidial.com
#
# last update:
# Dec 30, 2008
##
# change this to your email
#
email="youremail@youremail.com"#
# no need to change anything below here
#yumtmp="/tmp/yum-check-update.$$"
yum="/usr/bin/yum"$yum check-update >& $yumtmp
yumstatus="$?"
hostname=$(/bin/hostname)
case $yumstatus in
0)
# no updates!
exit 0
;;
*)
date=$(date)
number=$(cat $yumtmp | egrep '(.i386|.x86_64|.noarch|.src)' | wc -l)
updates=$(cat $yumtmp | egrep '(.i386|.x86_64|.noarch|.src)')
echo "
There are $number updates available on host $hostname at $dateThe available updates are:
$updates
" | /bin/mail -s "UPDATE: $number updates available for $hostname" $email
;;
esac# clean up
rm -f /tmp/yum-check-update.*
Script to check kernel (here we use 'ovzkernel' since we're running with an openvz kernel, if you have a stock centos kernel, change this to 'kernel')
check-yum-kernel.sh
#!/bin/bash
email=youremail@youremail.com
latestkernel=$(rpm -q ovzkernel |tail -n1|sed -e 's/kernel-//')echo "$latestkernel"
if uname -a | grep -qv "$latestkernel"; then
echo "Running Kernel is" `uname -r` "but latest installed rpm is ${latestkernel}" |\
mail -s "UPDATE: ${HOSTNAME} reboot required" $email
fi;
Crontab entries:
30 21 * * * /root/bin/check-yum-updates.sh >/dev/null 2>&1
30 21 * * * /root/bin/check-yum-kernel.sh >/dev/null 2>&1
Run at 9:30 every night. Change times and paths to suit.
logrotate tweaks to enhance rsync backups
logrotate, by default (at least on CentOS as of 3, 4, and 5.x), rotates logs by incrementing all numbers on previous logs by one, and moving the current log to log.0
This is all fine and good if you like your logs to all be rotated in order, and have a certain number backed up:
secure --> secure.0.gz --> secure.1.gz --> secure.2.gz ...
the next 'logrotate' will move secure.0.gz to secure.1.gz, secure.1.gz to secure.2.gz, secure.2.gz to secure.3.gz ...
This is very problematic when you use rsync to back up files, and when you include logs in your backups. The issue is that rsync will see all rotated files as "brand new" files, and thus have to download all of them again and again, wasting time, disk I/O, bandwidth, etc.
To alleviate this issue, you can add 'dateext' to /etc/logrotate.conf - which will now back up all logs with a date extension, rather than just an incrementing number. This causes rotated logs to be static, and rsync will not have to download them again and again and again based on their file name changing and their 'contents' differing.
From the logrotate manpage:
dateext
Archive old versions of log files adding a daily extension like YYYYMMDD instead of simply adding a number.
Now your logs look like this:
secure, secure-20091120.gz, secure-20091020.gz, secure-20090920.gz ...
the next 'logrotate' will only add a new file 'secure-20091220.gz' and leave all the others the same.
This means rsync will only have to download a single new file (and the partial "secure" log file which is currently being written to by syslog) rather than having to download the entire list of rotated logs, saving tons of time on backups when you've got lots of logs.
Further Reading
A good article about the problems related to "hindsight log rotation schemes", although with the addition (in 2005?) of the logrotate 'dateext' feature, their suggestion to use syslog-ng is not the only good option. Since a lot of the popular server distros (Redhat/CentOS/Debian) ship with syslogd/rsyslogd and logrotate, most people won't replace their syslog with syslog-ng just for time-based log rotation.
Upgrading MailScanner
Easy Upgrading of MailScanner - RPM version
(For Redhat/Centos - updated from the MailScanner documentation)
1) Make a backup copy of your current MailScanner (Linux):
cp -a /etc/MailScanner /etc/MailScanner.$(date +%Y%m%d)
cp -a /usr/lib/MailScanner /usr/lib/MailScanner.$(date +%Y%m%d)
cp -a /usr/sbin/MailScanner /usr/sbin/MailScanner.$(date +%Y%m%d)
2) Download the latest version and extract
http://mailscanner.info/downloads.html
Check the changelog for upgrade notes and new features:
http://mailscanner.info/ChangeLog
Check the integrity of the downloaded file
untar the archive (tar xzf) X/
cd into the created directory
3) Upgrade MailScanner
run the install script (./install)
inspect the output for errors
manage the .rmpnew files
4) Upgrade the configuration files
upgrade_MailScanner_conf
cd /etc/MailScanner
upgrade_MailScanner_conf MailScanner.conf MailScanner.conf.rpmnew > MailScanner.new
mv -f MailScanner.conf MailScanner.old
mv -f MailScanner.new MailScanner.conf
upgrade_languages_conf
cd /etc/MailScanner/reports/en
upgrade_languages_conf languages.conf languages.conf.rpmnew > languages.new
mv -f languages.conf languages.old
mv -f languages.new languages.conf
Don’t forget to upgrade other components periodically as well (SA, DCC, Pyzor, Razor)
5) Restart MailScanner service
service MailScanner restart
6) Check for errors
Check the maillog for errors:
tail -F /var/log/maillog
Run MailScanner with --lint to make sure there are no configuration errors:
MailScanner --lint
Run SpamAssassin with --lint to make sure there are no config errors there either:
spamassassin --lint
- or -
spamassassin --lint -D
(shows output of --lint)
Run check_mailscanner to make sure MailScanner processes are running:
check_mailscanner
7) Send a test mail
If you're really concerned, and want to make sure everything works, it's a good idea to send a couple test mails from external servers to see if they get through your newly updated MailScanner server.