First create the directory for storing logs:

# mkdir /var/log/bind
# chown bind.bind /var/log/bind

The add the following statements in named.conf:

logging {
channel b_log {
    file "/var/log/bind/bind.log" versions 9 size 1m;
    print-time yes;
    print-category yes;
    print-severity yes;
    severity info;
};
channel b_query {
    file "/var/log/bind/query.log" versions 4 size 1m;
    print-time yes;
    severity info;
};
category default { default_syslog; default_debug; b_log; };
category queries { b_query; };
};

All parameters are well explained in the Bind ARM, so I'll just add a quick note about version and size. version tells bind to keep a fixed numbers of backups of the log file (it acts like a rotation mechanism similar to logrotate), while size specifies the maximum size of the log file (once the size exceed, logs are rotated).

Here's another mind map about LDAP that tries to explain how sync replication actually works.

I've never had a good occasion to use custom chains with netfilter. The usual setups I had to prepare were simple enough to achieve the required results using the built-in chains.

Few days ago I had to configure another box to act as a firewall, so I decided to try out custom chains:

#===============================================================================
#
# CUSTOM CHAINS
#
#===============================================================================

# Chain for packets coming from the internet

$IPTABLES -N internet-allowed

$IPTABLES -A internet-allowed -p tcp -m state --state NEW --dport $SSH -j ACCEPT
$IPTABLES -A internet-allowed -p tcp -m state --state NEW --dport $MUNIN -s $MUNIN_MASTER -j ACCEPT

# Chain for packets coming from the wireless network

$IPTABLES -N wireless-allowed

$IPTABLES -A wireless-allowed -p tcp -m state --state NEW --dport $CHILLI -j ACCEPT
$IPTABLES -A wireless-allowed -p tcp -m state --state NEW -m multiport --destination-port $HTTP -j ACCEPT
$IPTABLES -A wireless-allowed -p udp --dport $DNS -j ACCEPT

# Chain for packets coming from the wireless network and forwarded to the
# internet

$IPTABLES -N wireless2internet

$IPTABLES -A wireless2internet -p tcp -m state --state NEW -m multiport --destination-port $HTTP -j ACCEPT

#===============================================================================
#
# INPUT CHAIN
#
#===============================================================================

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A INPUT -i $LOIF  -j ACCEPT

$IPTABLES -A INPUT -i $EXTIF -j internet-allowed
$IPTABLES -A INPUT -i $EXTIF -j LOG --log-prefix "IN EXT REJ: "

$IPTABLES -A INPUT -i $INTIF -j LOG --log-prefix "IN INT REJ: "

$IPTABLES -A INPUT -i $TUNIF -j wireless-allowed
$IPTABLES -A INPUT -i $TUNIF -j LOG --log-prefix "IN TUN REJ: "

#===============================================================================
#
# FORWARD CHAIN
#
#===============================================================================

$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -i $EXTIF -j LOG --log-prefix "FW EXT REJ: "

$IPTABLES -A FORWARD -i $INTIF -j LOG --log-prefix "FW INT REJ: "

$IPTABLES -A FORWARD -i $TUNIF -o $EXTIF -j wireless2internet
$IPTABLES -A FORWARD -i $TUNIF -j LOG --log-prefix "FW TUN REJ: "

Although they were not strictly needed, I think they are good to improve readability anyway, as you can see from the previous snippet of the firewall script.

If you need to know what OpenLDAP is, and don't have time to read the really good OpenLDAP Administrator's guide, I think the following mind map can be useful.

Some time ago I found another oddity diving in the big sea of spam messages. Suddenly, I started to receive the following errors:

From: Mail Delivery System <MAILER-DAEMON@xxxxx.xx>
To: postmaster@xxxxx.xx
Subject: Postmaster Copy: Undelivered Mail
Date: Tue, 12 Jun 2007 11:41:15 +0200 (CEST)

Content-Description: Notification

<scass@xxxxx.xx>: mail forwarding loop for scass@xxxxx.xx

Content-Description: Delivery report
Reporting-MTA: dns; mx.xxxxx.xx
X-Postfix-on-Linux--i386--Queue-ID: CEA9EB40F1
X-Postfix-on-Linux--i386--Sender: rfc822; gqmq@xxxxx.xx
Arrival-Date: Tue, 12 Jun 2007 11:41:14 +0200 (CEST)

Final-Recipient: rfc822; scass@xxxxx.xx
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix-on-Linux--i386-; mail forwarding loop for
    scass@xxxxx.xx

Content-Description: Undelivered Message Headers
Received: from catv-50636fd7.catv.broadband.hu (catv-50636fd7.catv.broadband.hu [80.
99.111.215])
        by mx.xxxxx.xx (Postfix on Linux (i386)) with SMTP id CEA9EB40F1
        for <scass@xxxxx.xx>; Tue, 12 Jun 2007 11:41:14 +0200 (CEST)
X-Original-To: scass@xxxxx.xx
Delivered-To: scass@xxxxx.xx
Received: from [80.99.111.215] (port=21760 helo=catv-50636fd7.catv.broadband.hu)
        by mx1.xxxxx.xx with esmtp 
        id 433054-433054-08
        for scass@xxxxx.xx; Tue, 12 Jun 2007 11:41:19 +0100 (EET)
Message-ID: <499701c7ace6$01c7ace6$d76f6350@xxxxx.xx>
From: "Gerry" <gqmq@xxxxx.xx>
To: "Duane" <scass@xxxxx.xx>
Subject: financier than ankara
Date: Tue, 12 Jun 2007 11:41:19 +0100 (EET)
MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="----=_NextPart_001_4994_01C7ACD5.D4476A10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028

Why there is a forwarding loop? I spent some time checking all the postfix's configuration file and everything looked good.

So I gave a closer loop at the email... it seems that the remote server sent an email with the Delivered-To: header set to the recipient, which then triggers the error notified.

From the local(8) manpage:

In order to stop mail forwarding loops early, the software
adds an optional Delivered-To: header with the final enve-
lope recipient address. If mail arrives  for  a  recipient
that is already listed in a Delivered-To: header, the mes-
sage is bounced.

Nothing to really worry about...

Recentemente abbiamo installato in azienda una VPN usando openvpn. Installazione pulita e grande beneficio di accedere alle risorse della rete aziendale anche quando non si è fisicamente presenti in loco.

Purtroppo però, nella mia personale situazione, mi sono trovato ad affrontare un piccolo problema di DNS.

A casa, le mie macchine sono collegate in rete e appartengono tutte al dominio home.local; ho un server DNS privato che provvede alla risoluzione dei nomi per questo dominio fasullo e mi permette di accedere ai vari servizi. Anche in ufficio i servizi sono raggruppati su server locali appartenenti ai dominii office.local ed office.dmz, ed un DNS provvede alle risoluzioni necessarie. Fare giochi con il file resolv.conf non ha portato ad alcun risultato - ed /etc/hosts non è nemmeno da prendere in considerazione - in quanto, comunque la si girasse, qualche dominio privato risultava comunque non raggiungibile.

Sfruttando il fatto che la macchina che crea il tunnel VPN ha anche un DNS (il solito bind), ho trovato questa soluzione, che probabilmente non è la migliore, ma nel mio caso si è rivelata decisamente efficiente.

Per i dominii privati dell'ufficio ho creato nel file di configurazione di bind delle zone di tipo forward:

zone "office.local" {
        type forward;
        forward only;
        forwarders {
                192.168.10.1;
        };
};

zone "10.168.192.in-addr.arpa" {
        type forward;
        forward only;
        forwarders {
                192.168.10.1;
        };
};

Questo mi ha permesso di sfruttare il DNS locale per le normali risoluzioni (casa/internet) e di appoggiarmi al DNS dell'ufficio solamente per le cose inerenti ai servizi aziendali.

Per chi utilizza postfix, la cose si risolve in modo abbastanza semplice. Nel mio caso, ho necessità di fare in modo che tutti i messaggi inviati automaticamente da tutte le macchine della mia rete privata risultino spediti dal mio indirizzo e-mail pubblico. Utilizzo un mail server unico per servire tutta la rete.

sender canonical maps

La prima cosa da fare è creare il file /etc/postfix/sender_canonical. Il mio contiene quanto segue:

/adotti\@.*.nowhere.local/      alessandro@hyboria.org

Una volta creato/modificato il file in questione, occorre trasformarlo in un formato utile per postfix:

$ postmap /etc/postfix/sender_canonical

Fate riferimento alla man page di canonical(5) per informazioni complete su come utilizzare le canonical_maps.

(ri)configurare postfix

Modificate il vostro /etc/postfix/main.cf aggiungendo la seguente riga:

sender_canonical_maps = pcre:/etc/postfix/sender_canonical

e riavviate il servizio.

NB: per mia comodità ho utilizzato nel file sender_canonical delle espressioni regolari perl-compatibili (pcre). Sono ovviamente supportate anche le espressioni regolari standard... basta sostituire pcre con regexp e modificare le regole contenute in sender_canonical di conseguenza. Potete fare riferimento alle man page pcre_table(5) e regexp_table(5) per maggiori dettagli.

    named[388]: none:0: open: /etc/bind/rndc.key: permission denied
    named[388]: couldn't add command channel 127.0.0.1#953: permission denied

Ovviamente, nessuna traccia di qualcosa in ascolto sulla porta 953 (la porta di default usata per il canale di controllo remoto da bind); altrettanto ovvio il problema di permessi.

Cercando in rete sono incappato in questo bug report di Debian (sul server in questione gira una sarge):

After applying the security update from DSA-1172 to two Sarge systems that I run the permissions of /etc/bind/rndc.key are set to bind:bind 0640. This prevents rndc from communicating with the daemon and leads to failure at the next time someone attempts to stop or reload the daemon via rndc.

The problem is fixed by reverting the permissions of /etc/bind/rndc.key to root:root 0640 as it was before the upgrade.

Rapido ed indolore da sistemare... applicate le modifiche all'ownership del file in questione e riavviato il servizio.

    ronin:~# rndc status
    number of zones: 7
    debug level: 0
    xfers running: 0
    xfers deferred: 0
    soa queries in progress: 0
    query logging is OFF
    server is up and running