Using Meta-packages to Standardize Servers

Both Ubuntu and Red Hat offer meta-packages which have no files of their own, but depend on others – thus requiring a set of packages to be present. You can use these packages to require a set of software to be present on a server, especially those that are not normally installed by the vendor’s install process.

A meta-package can save you time – you don’t have to install each package one at a time. A meta-package can also be included as part of a Puppet environment, so that all servers will be kept up-to-date with the current set of packages. A meta-package can also be a part of an automatic install process, also bringing in all necessary software and simplifying the installation steps.

In Ubuntu, creating your own meta-packages is made easy by using the equivs package. With RPM, you’ll have to create a meta-package using rpm-build and the appropriate SPEC file.

The only way that using a meta-package will truly save time is if you are using a program like APT or YUM to do installations because they will automatically compute the dependencies required and install them automatically when the meta-package is installed.

With a meta-package, you can require a set of packages that should be on every server – as well as force some packages to be removed. You can create a meta-packages that includes all packages that should be on a server, but aren’t usually installed (like gawk, logrotate, sysstate, ntp, logwatch, make, and m4 for instance). When the package server-main is then installed, all of its dependencies will also be installed. Any packages that are listed as conflicting packages will also be removed: packages like unattended-upgrades and command-not-found for instance.

Meta-packages could be created for packages that are from the Ubuntu Main repository, and for those packages that are in the Ubuntu Universe repository. This makes it simple to only include software from the Main repository and preclude those packages that are from the Universe repository.

These meta-packages could then be added to a local repository and added to a system during installation; this simplifies the package installation part of the install process and allows you to update any currently installed systems simply.

As an example, here’s my list for requirements (put into server-main) from the Ubuntu Main Repository:

• lvm2
• byobu
• ruby
• vim
• snmpd
• snmp
• mlocate
• postfix
• ltrace
• strace
• wget
• ntp
• m4
• make
• ifenslave
• dnsutils
• procps
• sysstat
• logrotate
• logwatch
• sharutils
• pdksh
• dc
• bsd-mailx
• nut
• finger
• xfsdump
• xfsprogs

And from the Universe repository, these are my suggested requirements (used as dependencies for server-universe):

• iperf
• jwhois
• apt-file
• chkconfig
• atop
• dstat
• maatkit

Log Rotation for MySQL using logrotate

The logrotate utility is a powerful and underrated utility used to rotate logs. It is one of Red Hat’s lesser known utilities; even so, it is available for a number of platforms, including Ubuntu.

However, its set up for MySQL is missing on Red Hat and incomplete on Ubuntu.

For Ubuntu, there is no rotation of the slow query logs. To rotate these logs, just add them to the standard Ubuntu logrotate file for MySQL – that is, /etc/logrotate.d/mysql-server. Add the logs to rotate to the beginning of the file, adding to the list of files already present there.

For Red Hat, a complete MySQL log rotation file is needed as there is none at all. The MySQL logrotation script was removed as part of a security update to Fedora Core 4 back on 17 May 2006, and later removed from Red Hat Enterprise Linux 4 Update 4. The reasoning was detailed in Bug #180639 (not available?) and Bug #182025. Since then, this missing logrotate file has been the subject of several bugs (such as Bug #547007) and also of message threads like this one from Red Hat’s rhelv5-list in July of 2007.

The response to all these queries is that the MySQL logrotate script is broken and it’s up to MySQL to fix it. However, this does not seem to take into account the new FLUSH LOGS command, and admins everywhere are creating their own scripts.

Over at Question Defense, Alex has a fabulous description of the entire process – from enabling logging through implementing log rotation. However, this process uses ~/.my.cnf to automatically log in; better is to use a file like /etc/mysql/maint.cnf the way that Debian (and Ubuntu) does it. In that case, Debian creates a special user and a password to go with it, and puts these into a file /detc/mysql/debian.cnf; here is a sample debian.cnf:

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = debian-sys-maint
password = i5Px6N4SZ9UhfSWa
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = i5Px6N4SZ9UhfSWa
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

For most purposes, only the [client] section is needed, along with the first three entries (host, user, and password). You could also specify the section as [mysqladmin] instead, which would limit the username and password to being used for mysqladmin only – which is the tool used during log rotation.

The critical command is this one:

/usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate.cnf

…where logrotate.cnf contains username and password details as described above. All the rest of the logrotate file is settings and script-bulletproofing:

# Modified Ubuntu logrotate script for MySQL server
#
# Untested under Red Hat, but should work: filenames will have to be changed
/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
        daily
        rotate 7
        missingok
        create 640 mysql adm
        compress
        sharedscripts
        postrotate
                test -x /usr/bin/mysqladmin || exit 0
                MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate.cnf"
                if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
                  if killall -q -s0 -umysql mysqld; then
                    exit 1
                  fi
                else
                  $MYADMIN flush-logs
                fi
        endscript
}