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).

A quick search on the net pointed me to this bug.

'Nuff said.

As reported in this thread from the Linux Kernel Mailing List, seems that the ACPI support is somehow broken, and this causes a thermal shutdown nearly immediately after the boot process has finished.

Booting the laptop with the 2.6.25 kernel still works fine, except that the only connectivity available is the wireless one - the built-in ethernet stopped to work - so I'll just wait for some kind of updated package, hoping it will hit the repositories before Lenny gets released :)

Update

Loading the 2.6.26 kernel with the noacpi option seems to work fine as well, and the ethernet connection works again.

[2008-09-12] Solved

Install the following packages:

• madwifi-tools
• eeepc-acpi-modules-2.6.26-1-686

This solves the issue, at least on my EeePC.

encfs provides an encrypted filesystem in user space, which means you don't need to encrypt a full partition, but rather you can create an encrypted filesystem on the fly.

Creating an encfs filesystem

$ mkdir /home/adotti/.work /home/adotti/work
$ encfs /home/adotti/.work /home/adotti/work
Creating new encrypted volume.
Please choose from one of the following options:
enter "x" for expert configuration mode,
enter "p" for pre-configured paranoia mode,
anything else, or an empty line will select standard mode.

Pre-configured paranoia mode was enough for my needs, so I simply typed p.

Paranoia configuration selected.

Configuration finished.  The filesystem to be created has
the following properties:
Filesystem cipher: "ssl/aes", version 2:1:1
Filename encoding: "nameio/block", version 3:0:1
Key Size: 256 bits
Block Size: 512 bytes, including 8 byte MAC header
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File data IV is chained to filename IV.

New Encfs Password: 
Verify Encfs Password:

Using the encrypted filesystem

At this point my new encrypted filesystem is ready to be used:

$ encfs /home/adotti/.work /home/adotti/work
EncFS Password:

Note that while files are encrypted, files metadata are not. Size, permissions and the number of files remain visible.

From the man page:

NAME
    rename - renames multiple files

SYNOPSIS
    rename [ -v ] [ -n ] [ -f ] perlexpr [ files ]

DESCRIPTION
    "rename" renames the filenames supplied according to the
    rule specified as the first argument.  The perlexpr argument
    is a Perl expression which is expected to modify the $_ string
    in Perl for at least some of the filenames specified.
    If a given filename is not modified by the expression, it will
    not be renamed. If no filenames are given on the command line,
    filenames will be read via standard input.

Prerequisites

It seems that only JDK is needed to get things working, so a simple

$ aptitude install sun-java5-sdk

will suffice.

Installing JBoss

The following instructions are just a compact rewrite of the information found in this useful post: JBoss on Debian quickstart.

$ cd /opt
$ unzip /home/adotti/jboss-4.2.2.GA.zip
$ mv jboss-4.2.2.GA jboss
$ jboss/bin/run.sh -b 192.168.10.13

A lot of logging output will flood your terminal... as soon as you see the following line:

INFO  [Server] JBoss (MX MicroKernel)
      [4.2.2.GA (build:SVNTag=JBoss_4_2_2_GA date=200710221139)] Started in 50s:564ms

you can point your browser to http://192.168.10.13:8080/ (the address specified after the -b option) and check if everything is working as expected.

Usually, getting rid of these monstrous sized logs is the quickest way to get some free space back, but I am not inclined to delete logs. A better approach, in my opinion, is to force a log rotation, which usually led, more or less, to the same result.

On a Debian system you can trigger the following cron script manually:

$ /etc/cron.daily/sysklogd

and your system logs get immediately rotated.

As a quick fix, you can edit the my.cnf configuration file, add the following line:

old_passwords = 1

and then restart the service.

A detailed discussion about this matter, with a list of possible solutions can be found in the MySQL reference manual.

Some days ago I received an email reminder for one of my several online accounts; I was asked to perform a password change, as a new password expiration policy was enforced.

I went on-line, supplied the information required in a web form and clicked on the "Confirm" button. The connection was unencrypted - I guess some more policies should have been enforced too ;). Few minutes later I received a confirmation email: the processes was successfully completed and I'd have been able to log in with the new password. I tried several times, using both the new and the old ones. No way.

I then decided to try the "I forgot my password, oh stupid moron I am" way... I got the password emailed to me and I noticed that all uppercase letters were lover cased!

I suggest this nice reading for further policy related decisions.

When I have to upgrade the hard disk of my system, I usually plug the new hdd in the machine, partition it, copy the data, install the boot loader, remove the old disk and reboot.

But, what if there are some oddities that prevent your boot loader to be manually installed on the new disk, and you don't have time/will/opportunity to sort out the issue? Well, this is just another way of performing the disk upgrade, at least with debian.

1. plug the new disk into the machine and unplug all other disks (if present)
2. boot with the Debian net install cd
3. install a minimal debian on the new disk (this step allows partitioning and installs the boot loader)
4. plug the old disk(s) back and reboot the system using the old installation; go into single user mode
5. wipe the newly created file systems and copy all data to the new disk
6. edit the files that need to (if any)
7. remove the old disk and reboot

Having a B-plan is a must. With unix it is easy :)

Yesterday I took some time to upgrade my NetBSD test server packages collection to pkgsrc-2007Q3.

I updated the source tree:

$ cvs updated -dP -r pkgsrc-2007Q3

then I perform a bulk upgrade of all installed packages (not many to be honest):

# /usr/pkg/sbin/pkg_chk -g
# /usr/pkg/sbin/pkg_chk -us

It wasn't that smooth. I encountered two different kinds of problems:

• some makefiles needed to be manually edited, since cvs was not able to merge all changes automatically
• some packages couldn't be installed as part of the bulk process. I haven't completely understand the problem, so I just got rid of it by manually installing the new version of each problematic package

In the end I got it running, and everything seems fine. I had the feeling of a logical approach after all, so I am quite comfortable with this.

After performing a source-way upgrade of my NetBSD system, I decided to try out a different approach using the binary sets.

I got all the sets I needed from a handy mirror, then I performed the following steps:

$ tar zcvf etc-backup.tar.gz /etc
$ cp /netbsd /netbsd.old

$ tar zxvpf kern-GENERIC.tgz -C /
$ tar zxvpf base.tgz -C /
$ tar zxvpf comp.tgz -C /
$ tar zxvpf man.tgz -C /
$ tar zxvpf text.tgz -C /
$ tar zxvpf games.tgz -C /

$ mkdir /tmp/tmproot
$ tar zxvpf etc.tgz -C /tmp/tmproot
$ etcupdate -s /tmp/tmproot/etc

After all the modifications needed to the configuration files were done, I just rebooted the system.

After upgrading my NetBSD system, I decided to upgrade the packages collection. These are the step I've done.

Set cvs environment variables

Put in my .bashrc the following lines:

export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot"
export CVS_RSH="ssh"

Updated the sources

$ cvs -q update -dP

Upgraded the packages

Refreshed the list of installed packages:

$ pkg_chk -g

The list was saved in /usr/pkgsrc/pkgchk.conf.

Updated the packages:

$ pkg_chk -us

Yesterday I finally find the time to upgrade wolverine, my NetBSD test server. I was in the mood to try something new, so I decided to perform the upgrade starting from sources.

It was really smooth, although it took a lot of time to compile everything (wolverine is a PIII 500Mhz). Here are the steps performed.

Backup data (/etc):

$ tar zcvf etc-3.0.tar.gz /etc

Prepare the directories (as root):

% mkdir /usr/src
% mkdir /usr/obj
% mkdir -p /usr/builds/i386
% mkdir -p /usr/releases/i386

Change the ownership of those directories to you user.

Get the sources:

$ wget ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-3.0.2/source/sets/*.tgz

Unpack the sources:

$ for file in *.tgz; do tar zxvf $file -C /; done

Build or update the crosscompiler:

$ cd /usr/src
$ ./build.sh -D /usr/builds/i386 -R /usr/releases/i386 -u -m i386 tools

Crosscompile the kernel:

$ ./build.sh -D /usr/builds/i386 -R /usr/releases/i386 -u -m i386 kernel=GENERIC

Install the new kernel (as root):

% cd /
% mv netbsd netbsd-3.0
% cp /usr/src/sys/arch/i386/compile/obj/GENERIC/netbsd .

Reboot the system.

Crosscompile the userland:

$ build.sh -D /usr/builds/i386/ -R /usr/releases/i386/ -U -u -m i386 build

Install (as root):

% build.sh -D /usr/builds/i386/ -R /usr/releases/i386/ -U -u -m i386 install=/

Review postinstall failed checks and fix things accordingly.

Update /etc (as root):

% /usr/sbin/etcupdate

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.

Final steps for my etch upgrade. On the test machine I just had to perform two tasks to tune the system.

Filesystem tuning

I added the dir_index flag to all non volatile filesystems. The dir_index option force the use of hashed b-trees to speed up lookups in large directories.

$ tune2fs -O +dir_index /dev/hda1

the previous operation was repeated for all filesystems.

Old kernels removal

I used aptitude to remove any old 2.4 kernel installed on the system.

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...

I got gargoyle, the etch upgraded testing box, ready from a week or so; it was time to do the job.

I just followed the etch release notes step by step. For the impatient - remembering that this a standard sarge headless box - this is what I did:

• changed the sources for apt
• updated the package list (aptitude update)
• performed an upgrade (aptitude upgrade)
• installed intitrd-tools to get libc6 and locales updated (other things will be updated as well)
• performed a dist upgrade (aptitude dist-upgrade)
• edited any configuration file that needs to be fixed or updated
• updated the package list again
• removed obsolete packages
• rerun lilo (/sbin/lilo -v)
• rebooted

Etched :)

Before following the step outlined above, keep in mind that you might have to perform some more or different steps, depending on your setup. Definitely read the release notes!

You have been warned...

I'm just an occasional user of phpmyadmin, but some colleagues who heavily works on databases told me that they were really annoyed by the fact that after a quite short amount of time they needed to authenticate again.

The problem is that the cookie authentication set the lifetime of the cookie itself to 1800 seconds (30 minutes); after 30 minutes you need to login again.

If you like to change this behavior, edit the file /etc/phpmyadmin/config.inc.php and add the following line:

$cfg['LoginCookieValidity'] = 18000;

this will set the lifetime of the cookie to 5 hours (18000 seconds).

I took the chance of a quiet Saturday morning to start testing the upgrade path from sarge to etch. The target machine was gargoyle, a FTP server with a minimum set of packages installed, and it was chosen to discover the most relevant problems I could encounter with the other boxes I own (my setups are quite similar).

The only mayor issue outlined in the release notes is the need to upgrade the kernel before the full upgrade takes place. The box run a 2.4.27 kernel, so I needed to upgrade to a 2.6.8 kernel. As far as I could test, the via_rhine driver shipped with the official debian kernel sources is broken, so I used a vanilla 2.6.8.1 kernel to have my D-Link network card working.

Now that everything is in place, I'm ready...

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.

Come d'abitudine, ogni anno provvedo alla sostituzione dell'hard disk del mio server casalingo. Quest'anno ho posticipato un po' l'intervento, ed alla fine mi sono ritrovato con nuovo hardware da utilizzare. Anzichè cambiare il disco come al solito, ho cambiato tutta la macchina.

Essendo una persona estremamente pigra rispetto a questo genere di attività, ho cercato di minimizzare il peso della cosa. Quattro ore sono state sufficienti a ripristinare le cose esattamente come erano prima, eccezzion fatta per il ferro che fa girare il tutto.

Ecco una breve check list delle cose che ho fatto; sai mai che possa tornare utile.

• montata la macchina con disco nuovo
• installata una debian minimale via rete
• compilato un kernel ad hoc (cosa perfettamente superflua ma sono abituato così).
• installati un po' di orpelli per amministrare meglio il sistema (editor, file manager e altri tool vari)
• configurato il firewall ed eseguito l'hardening di base
• inserito il disco che uso per i backup, contenente anche i dati del vecchio server
• installati i servizi necessari
• ripristinate le configurazioni dei servizi e gli altri dati

Tutto come prima, solo più veloce.

Inutile dirvi di avere un buon backup a mano, dato che questo evento viene spesso generato da problemi hardware. Se siete fortunati, si tratta solo del file boot.ini corrotto, e questo è un possibile rimedio (grazie a Simone Bacciglieri che me lo ha segnalato).

Fate reboot usando il CD di WindowsXP, ed entrate nella console di ripristino. A questo punto digitate:

COPY D:\i386\ntldr C:
COPY D:\i386\ntdetect.com C:
ATTRIB -H -R -S C:\boot.ini
DEL C:\boot.ini
BootCfg /Rebuild

Fate ore un riavvio del computer (senza usare il cd-rom di XP). Se non ci sono altri problemi, il vostro sistema sarà di nuovo funzionante.

Considerate che, nella maggior parte dei casi, le installazioni di Windows 98 sono sporche da fare paura: personalizzazioni di ogni tipo (cursori, icone, temi etc.), software di varia origine installato e rimosso, incuria generale nel fare pulizia. Garantito che il pc un tempo performante ora sembra Budda in meditazione.

Per ripulire un'installazione del genere esiste un unico modo sicuro:

• backup dei dati
• formattazione del disco
• reinstallazione del sistema
• ripristino delle applicazioni
• ripristino dei dati

Non tutte queste operazioni sono banali, specie se l'incauto utente ha hardware particolare e non ha più i driver a disposizione.

In quest'ultimo caso, l'approccio manuale è l'unico percorribile. Operazione lenta e di compromesso; parecchia sporcizia resterà in giro, ma almeno si riacquisterà una qualche parvenza di performance.

Le cose da fare in realtà sono abbastanza lineari:

• rimuovere tutte le applicazioni inutili (nella speranza che si riesca a farlo in automatico, altrimenti si deve andare di scalpello e toglierle a mano)
• togliere tutti i temi, cursori e altre amene quanto inutili personalizzazioni
• togliere tutto ciò che non serve dall'avvio automatico
• usare msconfig per dare un'ulteriore limata alla configurazione di sistema (e agire su quei file di cui non si conosceva nemmeno l'esistenza)
• mettere mano al registro di sistema usando regedit, cosa che inevitabilmente dovrete fare dato l'alto numero di porcherie che rimarranno in giro dopo i passi precedenti

Ovviamente questa è poco più di una check-list; per una trattazione completa consiglio di fare ricerche in internet, specie se non siete esperti.

Consiglio anche di assumere caffeina e somministrare un ansiolitico all'utente che, quasi sempre, sarà molto preoccupato mentre gli fate a fette il sistema :)

Ecco, alla fine, forse funzionerà tutto.

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.

Installazione

Non mi dilungherò sulla procedura di installazione; in Debian si riduce ad un:

apt-get install munin munin-node

Terminato il download e l'installazione dei pacchetti, munin è già pronto per essere utilizzato. Vengono infatti rilevati tutti i servizi presenti sulla macchina ed installati tutti i plugin necessari (se disponibili).

Puntate il vostro browser all'indirizzo http://localhost/munin/ e potrete redervi conto di persona di cosa si tratta.

Nota: vi consiglio di verificare anche i pacchetti che vengono indicati come "raccomandati" e "suggeriti"; qualche plugin potrebbe averne bisogno.

Plugin

La quantità disponibile di plugin è notevole. Non tutto viene attivato in automatico, ma attivare plugin supplementari è molto semplice, basta creare dei link simbolici nella cartella contente i file di configurazione di munin. Unica eccezione, fra le cose che ho provato, riguarda apache. Per poterlo monitorare occorre agire sulla sua configurazione (niente di complicato).

Altre cose

Un paio di altre cose che giudico interessanti ma che non ho avuto ancora il tempo di testare riguardano l'impostazione di allarmi al verificarsi di condizioni critiche o comunque di attenzione - a quanto pare gli allarmi possono essere inviati per e-mail o integrati con nagios - e la creazione di grafici personalizzati.

Per chi fosse interessato ad approfondire, rimando al sito ufficiale. Troverete tutta la documentazione che desiderate.

    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

Integrità dei database

La prima cosa da verificare prima di effettuare i dump veri e propri dei dati è che i singoli database siano integri. Utilizzo il comando:

$ mysqlcheck -u root --password=<password> \
        --all-databases --analyze --check --optimize --auto-repair

che agisce su tutti i database del sistema, effettuando l'analisi delle tabelle, la verifica della presenza di errori e l'ottimizzazione. Nel caso vengano rilevate delle tabelle corrotte, le inconsistenze verranno sistemate in automatico.

Dump completo del sistema

La configurazione di default di Debian attiva l'uso dei log binari di MySQL; un apposito cron job si occupa della loro rotazione e di ripulire quelli troppo vecchi.

Non avendo particolari motivi per disabilitarli, non ho modificato l'impostazione di default, ma mi sono premurato di disabilitare la gestione automatica della loro rotazione, preferendo gestirla a mano una volta fatto il dump completo del sistema.

Per disabilitare la rotazione dei log binari va modificato il file /etc/mysql/debian-log-rotate.conf impostando:

KEEP_BINARY_LOGS=0

A questo punto, per effettuare un dump completo del sistema, si possono usare i comandi:

$ echo "SET FOREIGN_KEY_CHECKS=0;" > mysql-dump
$ mysqldump -u root --password=<password> \
    --single-transaction --all-databases \
    --flush-logs --master-data=2 --delete-master-logs >> mysql-dump
$ echo "SET FOREIGN_KEY_CHECKS=1;" >> mysql-dump

Il primo e l'ultimo comando si occupano di disabilitare, e riabilitare, i controlli sulle chiavi esterne delle tabelle - cosa indispensabile in caso di recovery. mysqldump invece provvede a fare il dump vero e proprio, includendo tutti i database e generando un nuovo log binario (eliminando i log binari vecchi, ormai inutili).

Dump di ciascun database

Accanto al dump completo di tutti il sistema, trovo utile avere anche un dump separato per ciascun database:

    $ echo "SET FOREIGN_KEY_CHECKS=0;" > [database]-dump
    $ echo "USE [database];" >> [database]-dump
    $ mysqldump -u root --password=<password> --opt [database] >> [database]-dump
    $ echo "SET FOREIGN_KEY_CHECKS=1;" >> [database]-dump

Sostituite a [database] il nome del database di cui volete fare il dump.

Recovery

Nella sciagurata ipotesi in cui serva un recovery, potete procedere come segue.

Ripristinate il sistema usando il dump completo:

$ mysql -u root --password <password> < mysql-dump

A questo punto potete usare i log binari per recuperare tutte le modifiche fatte sul sistema successivamente al dump:

$ mysqlbinlog logfile1 logfile2 ... | mysql -u root --password=<password>

oppure:

$ mysqlbinlog logfile1 logfile2 ... > mysql-log
$ mysql -u root --password=<password> < mysql-log

La seconda opzione è utile se si vuole esaminare il log prima di effettuare il ripristino.

E' anche possibile fare un ripristino parziale del contenuto del log usando le opzioni --start-datetime/--stop-datetime e --start-position/--stop-position di mysqlbinlog

Per effettuare il ripristino di un singolo database, invece, potete usare il comando:

$ mysql -u root --password=<password> < [database]-dump

Ringraziamenti

Un grosso ringraziamento a Maurizio Lemmo - Tannoiser per le utili quanto esaurienti spiegazioni.

Se vi trovate a gestire diverse macchine, magari con configurazione hardware identica, oppure se qualcuna di esse è particolarmente datata - come mi capita abbastanza di frequente - converrete che avere la possibilità di compilare un kernel configurato secondo gusto altrove, e generare un pacchetto deb pronto per essere installato ovunque serva, è molto comodo.

Oltre che molto comodo è anche molto facile. Basta avere i sorgenti del kernel a portata di mano ed installare il pacchetto kernel-package.

Spacchettate i sorgenti del kernel:

$> tar jxvf kernel-source-2.4.27.tar.bz2

Configuratelo come più vi piace:

$> cd kernel-source-2.4.27/
$> make menuconfig

Compilate:

$> make-kpkg --revision 01 --append-to-version -adc kernel_image

A questo punto il vostro pacchetto è pronto per essere installato nel solito modo ovunque vi serva:

$> dpkg -i kernel-image-2.4.27-adc_01_i386.deb

Due note sulle opzioni che ho usato:

--revision

Imposta il revision number del kernel da compilare. Preferisco specificarlo a mano dato che il default altrimenti usato non mi piace.

--append-to-version

Imposta la variabile EXTRAVERSION nel Makefile del kernel. La valorizzo sempre, per fare in modo che ogni versione diversa del kernel abbia il proprio albero di moduli in /lib/modules/ (evitando così aggiunte e rimozioni incontrollate dopo ogni nuova compilazione).

Ci sono moltissime altre opzioni disponibili; vi consiglio caldamente di leggere la man page di make-kpkg.