Ηλεκτρονικές Εκλογές ΤΕΕ – part 1

Σήμερα ξεκίνησαν οι εκλογές του ΤΕΕ. Το εκλογικό σώμα είναι περίπου το 1% του πληθυσμού της χώρας και με δώδεκα (12) κάλπες πρόκειται για την πιο πολύπλοκη εκλογική διαδικασία στη χώρα. Αν όλα πάνε καλά με το ηλεκτρονικό κομάτι των εκλογών θα έχουμε γράψει ιστορία.

Διευκρίνηση: Η καταμέτρηση είναι ηλεκτρονική, όχι η ψηφοφορία. Η ψηφοφορία γίνεται παραδοσιακά.

Πρέπει να ζητήσω συγνώμη από τη γυναίκα και το νεογέννητο γιό μου γιατί στο πρώτο του ΣΚ στο σπίτι μας εγώ είμαι μακριά του.

Update: Αποτελέσματα των εκλογών όπως κλείνουν τα διάφορα εκλογικά τμήματα

(part 2)

Migrating thousands of mailboxes to a new mailbox storage

Years ago we were faced with the following situation: We had thousands of mailboxes that were being served by a proprietary and unsupported version of email software. So we decided to move to a new architecture. While researching I selected a very good (IMHO) commercial product. But for reasons outside the scope of the post I opted for a F/OSS solution, and specifically the UW-IMAP toolkit. For those rushing to judge that price was the decisive factor I only have to reiterate Vladimir Butenko‘s words:

“Bottom line: you always pay. You need a simple thing – you pay a small amount, you need a big thing – you pay more.” (plain message and comp.mail.imap thread)

OK and now for the real question: How do you move thousands of mailboxes without your users noticing?

Since you do not know (and do not want to know) your users’ passwords the only thing you can do is to hack into the source code of your POP3 server (we do not offer IMAP yet). Whether it is the UW-IMAP toolkit, Cucipop, popa3d or any other server that you have access to its source, the server knows the correct password for your users when they authenticate. So when the authentication succeeds you fork(2) a program that logs into the old server and fetches the mailbox from the old server to the new one that runs the F/OSS software that you have selected. This can be fetchmail or any similar program. However I have found out that Net::POP3 is a better choice:

#!/usr/bin/perl
use Sys::Syslog;
use Net::POP3;
use DB_File;
$host = shift or die;
$user = shift or die;
$pass = shift or die;
tie %d, 'DB_File', "/etc/pop3.users.db", O_CREAT|O_RDWR, 0640, $DB_BTREE or die;
if ($d{$user}) {
        untie %d;
        exit 0;
}
$pop = Net::POP3->new($host) or die;
if ($pop->login($user, $pass) >= 0) {
        openlog("pop3cat-tmail", 'pid', 'mail') or die;
        syslog('info', 'fetching mail for user %s', $user);
        closelog();
        $msgnums = $pop->list or die;
        foreach $msgnum (keys %$msgnums) {
                $msg = $pop->get($msgnum);
                open T, "| /usr/bin/tmail $user" or die;
                print T @$msg;
                $pop->delete($msgnum);
                close T;
        }
        $d{$user} = "OK";
        untie %d;
}
$pop->quit;
exit 0;

Where exactly in the server code you fork(2), exec(3) and wait(2) for the script depends on the source code. You need to find where in the server code the authentication procedure succeeds and patch from there, before the server actually opens the user’s mailbox.

This script basically checks whether it has already moved a user’s mailbox from the old server. If it has, then the user is found in /etc/pop3.users.db and the script exits. If not, then the mailbox is moved and the user is inserted in /etc/pop3.users.db. Simply using Net::POP3 allows you to move the old mailbox to the Unix traditional mailbox format. That is why we fork tmail, since I have chosen the mbx mailbox format to store messages (I compile UW-IMAP with CREATEPROTO=mbxproto). If your server supports a format like Maildir, then you have to customize the above script accordingly, since it is written for mbx, which means that the user’s mailbox is a single file.

Όλα όσα θα χρειαστείτε για μια άνετη και επιτυχημένη θητεία

Ένας φίλος ξεκινάει τη στρατιωτική του θητεία σε λίγες μέρες και με την ευκαιρία του δείξαμε μια λίστα με πράγματα που πρέπει να έχει μαζί του. Με την άδεια του φίλου Γιώργου που την ανέπτυξε.

Καλή θητεία Κ.

[via]

smrsh and Debian sendmail

If you run sendmail from the Debian (Etch) packages and you use FEATURE(`smrsh’) then you must put the symlinks of the commands that you want smrsh to execute under /etc/mail/smrsh and not under /usr/lib/sm.bin . The Debian manpage is not particularly helpful on this.

From sendmail’s configuration README:

smrsh		Use the SendMail Restricted SHell (smrsh) provided
		with the distribution instead of /bin/sh for mailing
		to programs.  This improves the ability of the local
		system administrator to control what gets run via
		e-mail.  If an argument is provided it is used as the
		pathname to smrsh; otherwise, the path defined by
		confEBINDIR is used for the smrsh binary -- by default,
		/usr/libexec/smrsh is assumed.

Μονόζυγο

Αν ο εργασιακός σας χώρος το επιτρέπει (κοινώς δεν είναι ένας αχανής χώρος χωρισμένος σε cubicles) βάλτε κάπου ένα μονόζυγο (εμείς το βάλαμε στην πόρτα της τουαλέτας).

Απομακρύνει τα νεύρα1 και ισιώνει την πλάτη .

Επόμενο project: Ένας επιτοίχιος σάκος του μποξ.

(In-Reply-To:)

[1] Είχα πάρει από το Jumbo και ένα πιστολάκι με βεντούζες, αλλά δεν έφερε τα προσδοκώμενα αποτελέσματα.

check_dnsbl: a simple Nagios plugin

One way to deal with rogue virus spamming client machines is to do what AOL does. In our case this is not an acceptable choice. Therefore we redirect all rogue port 25/tcp traffic to a relay server1 where we simply check for virii in the outgoing email messages. Such a method has the side effect that this server sometimes ends up in bl.spamcop.net. In order to know when this happens I wrote this simple Nagios plugin, check_dnsbl:

#!/usr/bin/perl -w
#
# yiorgos, Fri Oct 13 16:09:52 EEST 2006
# Normally this *must* follow the Nagios plugin guidelines:
# http://nagiosplug.sourceforge.net/developer-guidelines.html
#

# Yes these three lines are needed because of the embedded Perl interpreter
use vars;
use strict;
my($revip, $dnsbl, $ans);

$revip = shift or die "you must give a reversed IP address";
$dnsbl = shift or die "you must give a DNSBL";

open DNSBL, "/usr/bin/dig -4 $revip.$dnsbl a |" or die;
while(<DNSBL>) {
  chop;
  if (m/^;; ANSWER SECTION:/) {
    $ans = <DNSBL>
    close DNSBL;
    print "$dnsbl STATUS: ", $ans;
    exit 2;
  }
}
close DNSBL;

print "$dnsbl STATUS: OK";
exit 0;

Of course you can hack check_dnsbl to include more DNSBLs. This is simply a proof-of-concept that does the job fine. It is not a complete plugin. If you want to make a more complete plugin you have to read through the Nagios plugin developer guidelines.

Update: A final version of the check_dnsbl plugin can be downloaded from here.  The final version checks for $HOSTNAME$ being listed in various DNSBLs specified in an array (Yes @dnsbl_list is specified inside the source.  You can use an external file to specify the array and have the Perl interpreter require it if you don’t like it this way).  It also uses Net::DNS instead of opening a pipe to dig which makes it considerably faster.

[1] in Greek

sendmailX renamed to MeTA1

From Claus Assmann:

Here's the latest status update:

For various reasons, the software has been renamed to MeTA1.
The mailing lists will be renamed accordingly:

domain:
	sendmailx.org	-> MeTA1.org
localparts:
	smx-developers	-> MeTA1-developers
	smx-design	-> MeTA1-design

For now, I just copy all addresses from the old lists to the new
list. If you don't want to participate any longer, please contact
me directly.

As you probably noticed, I took some time off from working on the
MTA (only fixing bugs if a problem showed up), but now I'm back and
one of my current projects is to look into integrating Arena as
scripting language (see some earlier mails about this topic).

I will send out some more information "soon" on the new list,
hopefully you will adjust your filters by then.

More information about MeTA1 and the Arena scripting language.