Rif: Re: Rif: RE: Cluster backup

[Nicola Mauri]

>> use the interface (aka bind) option in xinetd to run multiple
>> instances of the amanda client each responding on a different address

TESTED. Configuring multiple amanda client seems to solve this issue!

My new /etc/xinet.d/amanda file has three entries:
 - The first entry binds to node physical interface.
 - The remaining entries bind to every virtual interface defined in the cluster.

I noticed only one problem: when xinetd starts, some virtual interfaces may not be defined on machine, as they are assigned to other cluster members; xinetd won't be listening on non-existent interfaces.
When a service is relocated to the node, along with its interface, xinetd must be somehow restarted to get it listening also on the new acquired interface.

Should I schedule a daily '/etc/init.d/xinetd restart'?
(that's not very smart, is it?)        


--------------------------/etc/xinet.d/amanda-----------------------
service amanda
{
        disable = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = amanda
        group                   = disk
        server                  = /usr/lib/amanda/amandad
        bind = 10.0.10.1
}

service amanda
{
        disable = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = amanda
        group                   = disk
        server                  = /usr/lib/amanda/amandad
        bind = 10.0.10.5
}

service amanda
{
        disable = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = amanda
        group                   = disk
        server                  = /usr/lib/amanda/amandad
        bind = 10.0.10.6
}

--------------------------/etc/xinet.d/amanda-----------------------