Andryan’s Random Notes

Since I have always used ClamAV’s clamd as the virus filter of my email servers along with qmail-scanner, I noticed that crash-hat’s clamav RPM packages use logrotate to rotate the logs files. qmail-scanner runs as its own user (qscand), so clamd has to run under the same user. When the RPM package was first installed, it created these directories: /var/run/clamav/ and /var/log/clamav/. Chown these 2 directories to qscand (this assumes that User directives in freshclam.conf and clamd.conf have been changed to qscand), otherwise clamd and freshclam wouldn’t be able to write any logs and pid file and neither service would start.

As for the logrotate configuration, edit clamd and freshclam in /etc/logrotate.d/ to change the log files’ ownership to qscand instead of clamav. Modify line 8 where it says:

create 640 clamav clamav

to

create 640 qscand clamav

That should do the trick.

Since Fedora Core 5, pppoe-server that comes with rp-pppoe RPM package has always been broken. Someone actually filed a bug report, but unfortunately there was no response. Apparently the problem is caused by ppp conflicting with syslogd. If you stop syslogd and klogd, then pppoe-server will run properly. Fedora Core 4 does not have this problem though. I’m not sure if the newly released Fedora 7 has got this issue sorted out. I’m guessing that they haven’t.

If you have installed Fedora 7 and found out that the issue has been fixed, please let me know ASAP. Thanks!

Update (Jul 03, 2007): Problem confirmed in Fedora 7.

Update (Mar 14, 2008): Problem fixed as stated on bugzilla ticket.

I was just compiling an updated version of HTB-tools a few minutes ago then I noticed that either I forgot to make a note about removing a line from q_show.c or the addition of bitops.h is new in the latest version of HTB-tools (0.3.0a). If you don’t remove the following line in q_show.c:

#include <asm/bitops.h>

the compilation process will fail with the following error:

sys/q_show.c:40:24: error: asm/bitops.h: No such file or directory

I found this on Google to explain why bitops.h is missing in Fedora Core 6.

This script will create port forwarding rules on port 36xxx to 192.168.1.xxx:36xxx.

I was going to write about ETHTOOL_OPTS a couple of months ago, but unfortunately I’m a forgetful person.

If you use Fedora Core (or some Fedora-driven distributions) which uses ifcfg-DEVNAME files in /etc/sysconfig/network-scripts/ and you wish to alter your ethernet cards’ default configuration, ETHTOOL_OPTS is basically all you need! Look no further, no need to add anything in rc.local or write your own rc scripts just to force your ethernet cards to a certain configuration (be it 100Mbps full duplex or 10Mbps half duplex). Simply add this line to your ifcfg file, e.g. for eth0, edit /etc/sysconfig/network-scripts/ifcfg-eth0 and append:

ETHTOOL_OPTS=”speed 100 duplex full autoneg off”

To put this change into effect, do service network restart.

Use mii-tool to verify whether the ethernet cards apply the new configuration.

References:
http://www.redhat.com/archives/broadcom-list/2003-December/msg00002.html

I’m a big fan of tcptraceroute. It’s a very useful tool for network administrators (in addition to the traditional traceroute). I had tcptraceroute installed on my MacBook via MacPorts, but later it stopped working (”libnet_write failed? Attempted to write 40 bytes, only wrote -1″ error message) due to libnet compatibility problem. I couldn’t find a fix to that problem so I searched for a similar tool to replace tcptraceroute for my MacBook. I found lft on Google. Apparently lft is more flexible and advanced than tcptraceroute. What makes lft even better than tcptraceroute? lft is included in Fedora Extras! Since I use Fedora Core for my servers, this is much better than having to use third-party repository (e.g. dries, dag, etc.)

Normally, I use the following syntax for lft:

lft -C -z -n -E -S google.com

There are so many Linux bandwidth monitoring software available out there. Many of these software are just showing the current upload and download speed of each network interface, pretty much similar to iptraf’s “General interface statistics”. I was looking for something that plots TUI graphs. I found nload after spending a few minutes on Google. It doesn’t produce pretty graphs like rrdtool, but at least it does what I need.

UPDATE: I just noticed that ifstatus is similar to nload. ifstatus is capable of producing colored TUI graphs.

If you have multiprocessor Linux systems, top does not show individual CPU load by default. Press ‘1′ while top is running to change the default behavior and show each processor’s current load. Another utility is mpstat of the sysstat package, it is also capable of showing each processor’s current load.

Now you get to see which processor gets more load.

http://htb-tools.arny.ro/

For the last few days I have been looking for a bandwidth monitoring tool that is more efficient, accurate, and complete than IPFM. I found so many bandwidth monitoring tools (bandwidthd, ipband, darkstat, and a few others) on Google but couldn’t find one that fits what I want. In fact, IPFM suits me better than the others.

While I was reading iptables’ man page, I accidentally came across ‘account’ under ‘MATCH EXTENSIONS’. After reading the brief description and example, I got excited! This iptables match extension provides exactly what I need! With the flexibility of iptables’ rules plus the account match extension, this has to be the best solution for my new bandwidth monitoring system. There is one problem though. Fedora Core doesn’t have it.

With some experience I got from installing ipp2p by hand, I started trying to make this iptables match extension work on my Fedora Core 6 server. First, I used Google to locate ipt_account’s website. Then I used Google to search for some install guides on ipt_account but couldn’t find any, so I went through its website and found something.

Since I have prepared my system with kernel & iptables source tree, rpmbuild, etc. (basically everything required to build ipp2p modules), I will not go over the “ingredients” again. Sorry!

Download the kernel and iptables patches from this page. Patch the kernel tree:

• cd /usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i386/
• patch -p1 < path_to_kernel_patch

You should see the following:

patching file include/linux/netfilter_ipv4/ipt_account.h
patching file net/ipv4/netfilter/ipt_account.c
patching file net/ipv4/netfilter/Kconfig
patching file net/ipv4/netfilter/Makefile

OK, now the kernel tree is patched. Now do make oldconfig. You will be asked:

account match support (IP_NF_MATCH_ACCOUNT) [N/m/?] (NEW)

Since this will be a kernel module, hit m. Once the process has finished, do make scripts/kconfig/ (if you haven’t previously during ipp2p module build process). Create a temporary directory somewhere (e.g. /tmp/ipt). Copy /usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i386/net/ipv4/netfilter/ipt_account.c into that directory and create a file named Makefile. Paste the following into Makefile:

obj-m := ipt_account.o
KDIR := /usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i386/
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

Make sure that there is a tab before $(MAKE). Save the file and execute make. If the compile process goes well, there will be a file named ipt_account.ko in the directory. Load the module by using insmod. Check lsmod to see the newly loaded module.

If you have got this far, that means your kernel now supports ipt_account. Now we will add ipt_account extension for iptables. To see if your iptables has ipt_account support, do iptables -m account. If it prints out something like “Couldn’t load match `account’: …”, that means there is no iptables account extension yet.

Let’s patch iptables source tree:

• cd /usr/src/redhat/BUILD/iptables-1.3.5
• patch -p1 < path_to_iptables_patch

Expect the following:

patching file extensions/libipt_account.c

Open extensions/Makefile, on line 8, add account before ah. Then compile the ipt_account’s extension:

cc -O2 -Wall -Wunused -I/usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i386/include -Iinclude/ -DIPTABLES_VERSION=\”1.3.5\” -fPIC -o extensions/libipt_account_sh.o -c extensions/libipt_account.c
cc -shared -o extensions/libipt_account.so extensions/libipt_account_sh.o

Copy extensions/libipt_account.so to /lib/iptables and verify the extension: iptables -m account. That’s it! Pretty easy, eh?

Read this page to test the new iptables account match extension. Enjoy!