June 2008 Archives

I wanted a tool to show up network i/o statistics - just like iostat does for disk access. I used Sun::Solaris::Kstat in Perl, available in Solaris 10 package SUNWperl584core.

The only paramter my script accepts for now is the time delay between two measurements.

Example:

-bash-3.00$ knetstat 2
            network i/o statistics
       r/s        t/s        kr/s        kt/s  interface
            network i/o statistics
       r/s        t/s        kr/s        kt/s  interface
      1086       1916       91.75     2400.10  e1000g0
      45.5       48.5        6.78        8.51  e1000g1
            network i/o statistics
       r/s        t/s        kr/s        kt/s  interface
    1129.5       1921       99.30     2396.48  e1000g0
      17.5         18        2.46        2.59  e1000g1
            network i/o statistics
       r/s        t/s        kr/s        kt/s  interface
     706.5       1063       79.56     1199.68  e1000g0
        16         18        2.43        2.63  e1000g1

You may download the tiny perl script here.

[Update] Version 1.2.1 now accesses any attribute requested by SASL, so the use of cmusaslsecret* is possible. In this version the parameter "gl_attribute" has been omitted.

Downloadlinks in this article have been corrected to get the 1.2.1 version.


NOOOOO! Don't talk about saslauthd(8). Customer wanted CRAM-MD5 and DIGEST-MD5 as authentication mechanism for his Postfix authenticated SMTP service. No, not just PLAIN. So saslauthd is out of the game.

Customer has a "mail password" in cleartext in his LDAP structure [Update: he is using cmusaslsecretCRAM-MD5 now] - especially for this kind of thing. Is it possible to use Postfix with that?

First - this is not a postfix issue. Customer had Postfix linked with cyrus sasl. Not a bad idea - but to use these LDAP entries you have to have an appropriate cyrus sasl auxprop. Why?

CRAM-MD5 and DIGEST-MD5 are shared secret algorithms. The server MUST know the cleartext password or the mechanisms' secrets in order to validate the answer sent by the client.

At the first look, I saw a "ldapdb" auxprop plugin which should just do that - and it failed because we did not have a SASL enabled OpenLDAP so ldapdb authentication failed. "*cmusaslsecretCRAM-MD5" (in the case of CRAM-MD5, replace it with DIGEST-MD5 when using DIGEST-MD5) and userPassword are requested from the sasl auxprop.

So here it goes - I had to write my own ldap auxprop. You may use it if you want. I will expain the way to write SASL auxprops in the next days to come, but for now - here is the source.

Use syslogd(8) to get debug messages (loglevel debug, facility auth).

On  the other day, I wanted to access Postfix dbm: and hash:-tables, created by postmap, from Perl. I am setting up a greylisting system and my whitelist should be a postfix table, so I won't have to use another database format.

I used this as a test table:

test1   myentry
test2   yourentry
test3   funny

I saved it as "testmap". After that, I used:

postmap testmap

Result:

-rw-r--r-- 1 pascal users    42 2008-06-16 10:14 testmap
-rw-r--r-- 1 pascal users 12288 2008-06-16 10:14 testmap.db

You may access this hash-type postfix-db just by using DB_File:

#!/usr/bin/perl

use Fcntl;
use DB_File;

my %tab;
my $null=chr(0);

tie %tab,'DB_File','testmap.db',O_RDONLY,0400,$DB_HASH;

# Sample query
my $key='test2';

my $value=$tab{$key.$null};
chop $value;  # chop null byte

print $key." = ".$value."\n";

Result:

test2 = yourentry

As you can see, the key must be terminated by a null byte, and the result itself is also null-terminated.

In case you use the dbm:-Format in postmap:

-rw-r--r--   1 root     root          42 Jun 16 11:30 testmap
-rw-r--r--   1 root     root           0 Jun 16 11:30 testmap.dir
-rw-r--r--   1 root     root        1024 Jun 16 11:30 testmap.pag

In Perl, just use NDBM_File instead and use the filename without .dir or .pag:

#!/usr/bin/perl

use Fcntl;
use NDBM_File;

my %tab;
my $null=chr(0);

tie %tab,'NDBM_File','testmap',O_RDONLY,0400;

# Sample query
my $key='test2';

my $value=$tab{$key.$null};
chop $value;  # chop null byte

print $key." = ".$value."\n";

The Keys and values are also null-terminated in this case.

Result is the same as with our hash:-Postfix-Table:

test2 = yourentry

Some people are saying I am having too much spare time - at least I had enough time to pull an old LSI RAID out of trash to make some performance measurements with it - the same test suite as used on the Infortrend SATA RAID device testes some days earlier.

The results are quite impressive - a 6 year old device can compete with a new one - fiberchannel disks of 2002 were as fast as SATA disks nowadays are.

I will get a combined SATA and SAS device the next days, so I will do some tests to compare NEW SAS-disk packs compared with new SATA disk packs.

Results:

• LSI ProFibre 4000R, bought 2002.
• ADVUNI/Infortrend OXYGENRAID, bought 2007.