Logwatch is a great program, used by sysadmins everywhere. As part of it’s output, it shows any packets logged by iptables.

I have iptables set to log dropped packets, as it makes it FAR easier to debug server access issues. However, logwatch on RHEL/CentOS (and possibly other distributions) likes to report a nice big list of every single access attempt. As an example:

Logged 152 packets on interface eth2
  From 8.31.57.109 - 1 packet to udp(1026)
  From 10.128.75.2 - 1 packet to udp(1434)
  From 21.197.212.79 - 1 packet to udp(1026)
  From 24.64.176.243 - 3 packets to udp(1026,1027,1028)
  From 24.64.178.77 - 3 packets to udp(1026,1027,1028)

This can get annoying if you have lots of packets dropped (eg: junk coming off my cable modem), as you have to scroll down 5 pages of log.

If you want to turn off this long list, and just see “Logged 152 packets on interface eth2”, you can make a minor tweak to the logwatch script to do this.

CentOS 4
Open the file “/etc/log.d/scripts/services/kernel”, and turn line 250 (or the line near there) into a comment by adding a # in front of it. Eg:

Line 250:   # print $outputMain;

CentOS 5
Open the file “/usr/share/logwatch/scripts/services/iptables”, and change line 217 (or the one near there) into a comment by adding a # in front of it. Eg:

Line 217:   # print $outputMain;

Other?
Using another distribution? See if either of the above applies for you, otherwise just look around for either a kernel or iptables service in the logwatch scripts directory. Use your package manager to help find where the files are. :-)

If you use smokeping and need to move your data from one computer to another with a different architecture, please check out my Smokeping Arch Converter.

Well, time for another status report I think….

Development is a bit stalled at a moment, which is mostly culprit of all the work I’m putting into getting my business started.

I have the base built and tweaked, but I need to sort out the package manager modifications and get the installer written. Once that is done, I can at least release a test build, and then work on adding the rest of the packages for the distro.

Things should be settled down by June, so hopefully I will have a test build available by July. :-)

Redhat have released an interesting report into the security risks associated with Redhat Enterprise Linux 4 over the past 2 years.

It’s interesting to notice that almost all of the critical flaws were with GUI-based applications (in particular Mozilla products), which shows that a Linux server not running user GUI apps, is pretty damn secure.

In fact, in a server Linux install, there were only 2 exploits that would permit a remote user to gain local privileges without requiring user interaction – one in sendmail and the other in mod_auth_pgsql!

LWN also have some commentary on this report.

CentOS 5 has been out for about a week now, and in this time I’ve installed 3 new servers with it – one i386 and two x86_64.

Again, the CentOS developers have done an excellent job of rebuilding Redhat’s SRPMs, and as usual Redhat have developed an outstanding distribution.

I’ve found a few quirks in the new release, as well as a few interesting changes from CentOS 4. This post just details some of my notes, from the perspective as a server administrator (ie: some of this isn’t relevant for a desktop user).

Installation
You will note that there are a large number of CDROMs to download – 6CDs for i386 and 7CDs for x86_64. Don’t be alarmed, you can get by with much less.

The installer will tell you want CDROMs you need at install time – I found for a typical LAMP build, I needed #1, #2, #3 (with only a few packages taken from #2 & #3)

However, you may find it easier & less data-cap hungry to download just CD #1, and perform a minimal installation, and then download everything else you need via yum. Plus, remember that you will also get any updates installed at the same time this way.

Speaking of updates… there are also quite a few updates for download, due to the freeze time before release. I was setting up an x86_64 mirror, and downloaded 1.3GB in updates! Fortunately most people will have far less than that. :-)

Note about OpenOffice.org
OpenOffice.org now has x86_64 RPMs, so there is no need to install i386 RPMs to support it on 64bit systems.*

* TBH, I haven’t installed it myself, but I’ve seen the RPM list showing it.

Yum & Repositories
I noticed this issue with both CentOS 4 and 5 – Yum will often choose bad mirrors from the mirrorlist file – for example, choosing overseas servers, when an official NZ server exists. And in some cases, the servers it has chosen are horribly slow.

You will probably find that you get better download speeds by editing /etc/yum.repos.d/CentOS-Base.repo and commenting out the mirrorlist lines and setting the baseurl line to point to your preferred local mirror.

Yum-updatesd
CentOS 5 has a new daemon called yum-updatesd, which replaces the old cron job yum update scripts. This script will check frequently for updates, and can be configured to download and/or install them.

However, this daemon is bad for a server, since it doesn’t run at a fixed time – I really don’t want my server downloading and updating software during the busiest time of day thank-you-very-much!

So, it’s bad for a server. Let’s disable it with:

service yum-updatesd stop
chkconfig --level 2345 yum-updatesd off

Plus I don’t like the idea of having a full blown daemon where a simple cronjob will do the trick perfectly fine – seems like overkill. (although it appears yum-updatesd has some useful features like dbus integration for desktop users)

So, I replace it with my favorite cronjob script approach, by running the following (as root of course):

cat << "EOF" > /etc/cron.daily/yumupdate
 #!/bin/sh
 # install any yum updates
/usr/bin/yum -R 10 -e 0 -d 1 -y update yum > /var/log/yum.cron.log 2>&1
/usr/bin/yum -R 120 -e 0 -d 1 -y update  >> /var/log/yum.cron.log 2>&1
if [ -s /var/log/yum.cron.log ]; then
        /bin/cat /var/log/yum.cron.log | mail root -s "Yum update information" 2>&1
fi
EOF

and if you want to clear up the package cache every week:

cat << "EOF" > /etc/cron.weekly/yumclean
 #!/bin/sh
 # remove downloaded packages
/usr/bin/yum -e 0 -d 0 clean packages
EOF

(please excuse the leading space infront of the comments ( #) – it is to work around a limitation in my site, which I will fix shortly. Just copy the lines into a text editor and remove the space, before pasting into the terminal)

This will install 2 scripts that get run around 4:00am (as set in /etc/crontab) which will check for updates and download and install any automatically. If there were any updates, it will send out an email, if there were none, it doesn’t send anything.

(of course, you need sendmail/whatever_fucking_email_server_you_like configured correctly to get the alerts!)

You can change yum to just download and not install the updates (just RTFM), but I’ve never had a update break anything – update compatibility and quality is always very high – so I use automatic updates.

CentOS 4 had something very similar to this, with the addition of a bootscript to turn the cronjobs on and off.

* Please check out the update at the bottom of this page for futher information on this.

Apache Quirks
If you are using indexing in apache (indexing is when you can browse folders/files), you may find that the browsing page looks small and nasty.

The fix is to edit /etc/httpd/conf/httpd.conf and change the following line:

IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable

to

IndexOptions FancyIndexing VersionSort NameWidth=*

This should make the index full screen again. I’m not sure if this is an apache bug, a distro bug or some other weird issue, because I’m sure HTMLTable isn’t supposed to be all small like that.

(FYI: CentOS 4 did not have the HTMLTable option active)

SSL Certificates
Redhat have moved things around with SSL certificates a lot. What it seems like happened (I have only had a quick look into this), is that they were going to provide a new tool to generate SSL certificates called “genkey” but pulled it out before release.

To make things more fun, they also removed the good old Makefile that was in /etc/httpd/conf/ that allowed you to generate SSL certificates & keys.

However, I found the same Makefile again in /etc/pki/tls/certs/

Vi vs. Vim
If you use vi/vim, you should check this posting out.

That’s all the issues that I’ve come across for now – if I find any more things to note, I’ll update this page with the information and put a note on my blog.

UPDATE – 1st May 2007

A reader has informed me that the old RHEL 4 style cronjobs can be found in a package called ‘yum-cron’. Just like in RHEL 4, it installs a service called “yum” which you can enable with:

chkconfig --level 2345 yum on
service yum start

However, I will point out a small difference with the Redhat cron script vs. my cron script – the Redhat one will send the list of updates as an email from cron (as cron simply emails the output the script produces). My version allows you to change the subject, and the destination email address. This may/may not be useful to you.

The same reader also points out that there is another package in the CentOS extras repository called ‘yum-updateonboot’, which installs bootscripts which update your system when you boot it, and will then reboot if there are any kernel updates needed.

You should be able to (I haven’t tried myself) enable it with:

chkconfig --level 2345 yum-updateonboot on

Here’s a useful tip for CentOS/RHEL (and possibly other distros) – by default, a lightweight version of vim is installed to /bin/vi, which is enough to get basic administration done, but doesn’t have a lot of useful features, like being able to copy data from one instance to another.

The solution is to install the vim-enhanced RPM, which installs vim to /usr/bin/vim. However, this introduces a new problem, since when you run “vi” you will get a different program to running “vim”.

Some people remove /bin/vi and replace it with a symlink to /usr/bin/vim – which works, but will be a nasty problem if the system ever boots without mounting /usr, and needs some administration. It’s also impossible to do if you don’t have root access to the system.

The best fix, is to add an alias to your bash config, by adding the following lines to ~/.bashrc:

if [ -f /usr/bin/vim ]; then
         alias vi='vim'
fi

Then run “source ~/.bashrc” to update your current terminal, or open a new terminal to take advantage of the change.

You will now find that if you run the vi command, the alias will actually run vim! Nice and easy, and it doesn’t require root privileges to setup, as it only changes a local user config file.

UPDATE – 30 Apr 2007

As pointed out by a reader, Redhat does infact provides an alias at installation time to accomplish this, in the file /etc/profile.d/vim.sh.

However, the alias will only be setup for users with an ID larger than 100 (excludes root which is ID 0), and the alias also does not check for the presence of the vim executable.

You could edit the file, and change the following:

if [ -n "$BASH_VERSION" -o -n "$KSH_VERSION" -o -n "$ZSH_VERSION" ]; then
  [ -x /usr/bin/id ] || return
  [ `/usr/bin/id -u` -le 100 ] && return
  # for bash and zsh, only if no alias is already set
  alias vi >/dev/null 2>&1 || alias vi=vim
fi

Into:

if [ -n "$BASH_VERSION" -o -n "$KSH_VERSION" -o -n "$ZSH_VERSION" ];then
  if [ -f /usr/bin/vim ]; then
         alias vi='vim'
  fi
fi

This would make a vim alias that would work for all users, and which would check for the existence of the vim binary first.

Recently I configured a server for a client, which uses chrootssh to provide locked down access to various SSH users.

In the process, I wrote a little script to make it a bit easier to setup the chroot directories, and you can download the script here.

Chroot Generation Script

Today, I’m pleased to announce the formation of my new company, Amberdms Ltd. This is where a lot of my free time has been going lately (and will do for quite a while…)

I’m still working at Prophecy Networks full time (& enjoying it), but have created Amberdms to market some of software products that I have been developing.

At this stage I’m working on a web-based data management system for educational institutes to be released around May/June 2007 (More details will be available then), but in the future I intend to expand to offer other products and services.

Finally! A truly brilliant internet solution that can be installed by anyone, and eliminates the need for expensive infrastructure construction.

Introducing Google TiSP

This is clearly an ideal replacement for New Zealand’s bad broadband offerings! ;-)

Ever seen anything like this in your logs?

/home/username/.forward.hostname: Group writable directory: 675 Time(s)
/home/username/.forward: Group writable directory: 675 Time(s)

The problem is caused if you have a mailserver setup, it looks in your home directory for a forward file. However, if your home directory permissions has strange privileges (such as being group writable) it complains about it, which gives you these harmless (but annoying) messages.