Seems like good advice:
Wednesday, January 13, 2010
More SpamAssassin
Just noticed this on the SARE (SpamAssassin Rules Emporium) at www.rulesemporium.com
Seems like good advice:
Seems like good advice:
Tuesday, January 12, 2010
Today's date
Among the things that I rarely in public is the fact that although the platform I'm using is RHEL5.4 Linux, the code I'm writing is... COBOL. I brought Denman's first computer online in 1980, and there just weren't a lot of other choices. And in the intervening years, there really hasn't been a compelling reason to switch languages, so I've kept writing.
Anyway, I was in the debugger this morning, and had to maniuplate the date in YYMMDD form. It came out
100111
which is right - but I had to look at it a whole bunch of times. It still looks like 47 octal to me.
Anyway, I was in the debugger this morning, and had to maniuplate the date in YYMMDD form. It came out
100111
which is right - but I had to look at it a whole bunch of times. It still looks like 47 octal to me.
Friday, January 8, 2010
kvm disk comparison
I used bonnie++ to get some disk benchmarks. The virtual io is supposed to be much faster than the ide emulation, so let's take a look.
virtio (loop):
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
buran.denmantire 3G 8321 27 16886 13 13128 9 30720 46 15277 2 538.5 4
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 14308 94 +++++ +++ +++++ +++ 7738 58 +++++ +++ +++++ +++
buran.denmantire.com,3G,8321,27,16886,13,13128,9,30720,46,15277,2,538.5,4,16,14308,94,+++++,+++,+++++,+++,7738,58,+++++,+++,+++++,+++
ide (loop):
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
buran.denmantire 3G 8164 12 16475 3 19955 7 45174 68 71586 6 992.4 13
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 15543 90 +++++ +++ +++++ +++ 15183 84 +++++ +++ +++++ +++
buran.denmantire.com,3G,8164,12,16475,3,19955,7,45174,68,71586,6,992.4,13,16,15543,90,+++++,+++,+++++,+++,15183,84,+++++,+++,+++++,+++
Hmmm. Slightly faster, yes, but not the huge increase I was expecting. Of course, that's with loop disks. I'll try it sometime next week with a physical partition.
virtio (loop):
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
buran.denmantire 3G 8321 27 16886 13 13128 9 30720 46 15277 2 538.5 4
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 14308 94 +++++ +++ +++++ +++ 7738 58 +++++ +++ +++++ +++
buran.denmantire.com,3G,8321,27,16886,13,13128,9,30720,46,15277,2,538.5,4,16,14308,94,+++++,+++,+++++,+++,7738,58,+++++,+++,+++++,+++
ide (loop):
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
buran.denmantire 3G 8164 12 16475 3 19955 7 45174 68 71586 6 992.4 13
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 15543 90 +++++ +++ +++++ +++ 15183 84 +++++ +++ +++++ +++
buran.denmantire.com,3G,8164,12,16475,3,19955,7,45174,68,71586,6,992.4,13,16,15543,90,+++++,+++,+++++,+++,15183,84,+++++,+++,+++++,+++
Hmmm. Slightly faster, yes, but not the huge increase I was expecting. Of course, that's with loop disks. I'll try it sometime next week with a physical partition.
Thursday, January 7, 2010
Making chkrootkit a little more readable
I use cron to daily run a couple of rootkit checkers, rkhunter (http://www.rootkit.nl/) and chkroot
(http://www.chkrootkit.org/). chkrootkit is nice, but it's a bit paranoid about weird and hidden files. On the other hand, I probably want my rootkit checker to be a bit paranoid.
It's got a line of code to look for hidden files:
files=`${find} ${DIR} -name ".[A-Za-z]*" -o -name "...*" -o -name ".. *"`
and so on, and so on.
I made a simple change:
and it prints the file out one line at a time. Much nicer:
Suspicious files =
-rw-r--r-- 1 root root 0 Dec 3 11:05 /usr/lib/firefox-3.0.16/.autoreg
-rw-r--r-- 1 root root 4622 Dec 11 2007 /usr/lib/gtk-2.0/immodules/.relocation-tag
lrwxrwxrwx 1 root root 27 Sep 14 07:58 /usr/lib/.libfipscheck.so.1.hmac -> .libfipscheck.so.1.1.0.hmac
-rw-r--r-- 1 root root 65 Apr 7 2009 /usr/lib/.libgcrypt.so.11.hmac
-rw-r--r-- 1 root root 110 Apr 7 2009 /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Term/ReadLine/.packlist
-rw-r--r-- 1 root root 363 Apr 7 2009 /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Term/ReadKey/.packlist
(http://www.chkrootkit.org/). chkrootkit is nice, but it's a bit paranoid about weird and hidden files. On the other hand, I probably want my rootkit checker to be a bit paranoid.
It's got a line of code to look for hidden files:
files=`${find} ${DIR} -name ".[A-Za-z]*" -o -name "...*" -o -name ".. *"`
and then it just does an echo to display them. Well, that's fine if you've got one or two, but if you've got a couple of dozen this is almost unreadable. See, displaying like that will display all of the filenames with a space between them, and no newline, like so:
/usr/lib/firefox-3.0.16/.autoreg /usr/lib/gtk-2.0/immodules/.relocation-tag /usr/lib/.libfipscheck.so.1.hmac /usr/lib/.libgcrypt.so.11.hmac /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Term/ReadLine/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Term/ReadKey/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/YAML/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/GD/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/GD/Text/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/GD/Graph/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/File/Which/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/File/Tail/.packlist /usr/lib/perl5/site_perl/5.
and so on, and so on.
I made a simple change:
if test -n "$files"; then
echo "Suspicious files = "
for i in ${files}; do ls -la $i; done
fi
echo "Suspicious files = "
for i in ${files}; do ls -la $i; done
fi
and it prints the file out one line at a time. Much nicer:
Suspicious files =
-rw-r--r-- 1 root root 0 Dec 3 11:05 /usr/lib/firefox-3.0.16/.autoreg
-rw-r--r-- 1 root root 4622 Dec 11 2007 /usr/lib/gtk-2.0/immodules/.relocation-tag
lrwxrwxrwx 1 root root 27 Sep 14 07:58 /usr/lib/.libfipscheck.so.1.hmac -> .libfipscheck.so.1.1.0.hmac
-rw-r--r-- 1 root root 65 Apr 7 2009 /usr/lib/.libgcrypt.so.11.hmac
-rw-r--r-- 1 root root 110 Apr 7 2009 /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Term/ReadLine/.packlist
-rw-r--r-- 1 root root 363 Apr 7 2009 /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Term/ReadKey/.packlist
...
Wednesday, January 6, 2010
kvm virtio disk mystery solved
I suppose this is what I get for depending on a GUI - something I normally never do.
kvm stores its guest definitions in an xml file in /etc/libvirt/qemu. So to see what adding a new drive would look like in that file, I went to virt-manager, fired up the server, clicked the 'hardware' tab, and installed a virtio disk. Then, I went looked at the file, and...
No difference. I even saved it and did a diff. No difference. OK, it must need a reboot - makes sense, kinda. Rebooted the machine; no vda disk, no change to the .xml. All right, I shut the guest down completely, get out of virt-manager, get back in... nada. The disk is showing up in the hardware tab, but not in the .xml. Nothing in the logs.
Feeling mightily confused, I fired off a support request to Red Hat and started messing around. I removed the disk from the guest, shut the guest down, added the disk - AHA! That did it! Started up the guest; the disk shows up. All is well.
This sure doesn't sound like the behavior I'd expect. I mean, if you're going to have a GUI, why not an error message if you try to do this? I think I'll submit a bug report.
kvm stores its guest definitions in an xml file in /etc/libvirt/qemu. So to see what adding a new drive would look like in that file, I went to virt-manager, fired up the server, clicked the 'hardware' tab, and installed a virtio disk. Then, I went looked at the file, and...
No difference. I even saved it and did a diff. No difference. OK, it must need a reboot - makes sense, kinda. Rebooted the machine; no vda disk, no change to the .xml. All right, I shut the guest down completely, get out of virt-manager, get back in... nada. The disk is showing up in the hardware tab, but not in the .xml. Nothing in the logs.
Feeling mightily confused, I fired off a support request to Red Hat and started messing around. I removed the disk from the guest, shut the guest down, added the disk - AHA! That did it! Started up the guest; the disk shows up. All is well.
This sure doesn't sound like the behavior I'd expect. I mean, if you're going to have a GUI, why not an error message if you try to do this? I think I'll submit a bug report.
Tuesday, January 5, 2010
Converting from Xen to kvm
So my Saturday/Sunday project, after all the good football games were over, was to convert from Xen to kvm here. I've got six virtual RHEL5 servers running on this host. Five were no problem at all, and took less than an hour total to convert and reboot. One more small hint: comment out
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
in /etc/inittab. It started respawning rapidly.
The sixth server caused all kinds of problems. It is, of course, our main production server.
First problem is that using the virt-install --import command imports all of the disks as hdx, on the ide bus. Fine - unless you have more than four, the maximum number that the ide bus can support. I'm working on getting these switch over to vdx-type virtio disks, but it's not as simple as I thought it should be, i.e., adding
to the .xml file. Ah, well, I'll keep working on it. Luckily, the disks that I don't have up are historical files; I've got at least a week.
The other problem was networking. The way I've got Denman set up is that all traffic goes through a central gateway machine. Only the inside virtual servers and the host are on the 192.168.1.0 network, and can talk to each other directly. But one of those six new kvm boxes was on the 0.0 network. In order to get that network up and running, I had to define it on the host. But if I defined it on the host, then the host could get to the 0.0 network directly, foiling my nice firewall scheme.
The solution took some head-scratching, but I finally came up with this:
and the secret is the netmask. It creates the bridge:
[root@defiant ~]# ifconfig
br0 Link encap:Ethernet HWaddr 00:19:B9:B8:95:F5
inet addr:192.168.0.130 Bcast:192.168.0.255 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
but doesn't route it anywhere:
[root@defiant ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 br1
default saratoga1.denma 0.0.0.0 UG 0 0 0 br1
so the traffic to the 0.0 network still has to go through the gateway.
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
in /etc/inittab. It started respawning rapidly.
The sixth server caused all kinds of problems. It is, of course, our main production server.
First problem is that using the virt-install --import command imports all of the disks as hdx, on the ide bus. Fine - unless you have more than four, the maximum number that the ide bus can support. I'm working on getting these switch over to vdx-type virtio disks, but it's not as simple as I thought it should be, i.e., adding
<disk device="disk" type="file">
...
<target bus="virtio" dev="vda">
</target>
to the .xml file. Ah, well, I'll keep working on it. Luckily, the disks that I don't have up are historical files; I've got at least a week.
The other problem was networking. The way I've got Denman set up is that all traffic goes through a central gateway machine. Only the inside virtual servers and the host are on the 192.168.1.0 network, and can talk to each other directly. But one of those six new kvm boxes was on the 0.0 network. In order to get that network up and running, I had to define it on the host. But if I defined it on the host, then the host could get to the 0.0 network directly, foiling my nice firewall scheme.
The solution took some head-scratching, but I finally came up with this:
DEVICE=br0
BROADCAST=192.168.0.255
IPADDR=192.168.0.130
NETMASK=255.255.255.255
BROADCAST=192.168.0.255
IPADDR=192.168.0.130
NETMASK=255.255.255.255
and the secret is the netmask. It creates the bridge:
[root@defiant ~]# ifconfig
br0 Link encap:Ethernet HWaddr 00:19:B9:B8:95:F5
inet addr:192.168.0.130 Bcast:192.168.0.255 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
but doesn't route it anywhere:
[root@defiant ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 br1
default saratoga1.denma 0.0.0.0 UG 0 0 0 br1
so the traffic to the 0.0 network still has to go through the gateway.
Friday, January 1, 2010
Happy New Year - check your SpamAssassin setup!
Just noticed this in all messages coming in:
3.2 is huge in SpamAssassin. Consider that the default threshold is 5.0 - this alone gets you most of the way to marking the message as spam.
72_active.cf shows:
72_active.cf:header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
It should be [2-9][0-9]. At least, it should be that now.
Happy new year!
3.2 FH_DATE_PAST_20XX The date is grossly in the future.
3.2 is huge in SpamAssassin. Consider that the default threshold is 5.0 - this alone gets you most of the way to marking the message as spam.
72_active.cf shows:
72_active.cf:header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
It should be [2-9][0-9]. At least, it should be that now.
Happy new year!
Subscribe to:
Posts (Atom)
Posts
