CTDB by default in Debina lenny? (was: [Pkg-samba-maint] Situation of various samba packages)

ronnie sahlberg ronniesahlberg at gmail.com
Thu Jul 10 07:54:16 GMT 2008

On Thu, Jul 10, 2008 at 5:04 PM, Mathieu PARENT <math.parent at gmail.com> wrote:
> Hi,
> Thanks for your quick reply.
> On Wed, Jul 9, 2008 at 11:39 PM, ronnie sahlberg
> <ronniesahlberg at gmail.com> wrote:
>> Hi,
>> Can you please provide any patches you have for /etc/ctdb/functions
> none
>> and the scripts in /etc/ctdb/events.d
>> I am not sure that the mainline version of ctdb has fully debianized scripts.
> Sure: http://svn.debian.org/wsvn/pkg-samba/trunk/ctdb/debian/patches/06_services_names.diff?op=file&rev=0&sc=0
> (this is a very trivial patch, because some part is already merged,
> see https://bugzilla.samba.org/show_bug.cgi?id=5258).
> I've only done samba and httpd.
> ctdb and interface are working out of the box.
> Summary:
> 00.ctdb: no changes needed, tested -> OK
> 10.interface: no changes needed, tested -> OK
> 40.vsftpd:  not patched, not tested
> 41.httpd: patched and tested -> OK
> 50.samba: patched and tested -> OK
> 60.nfs:  not patched, not tested
> 61.nfstickle:  not patched, not tested
> 70.iscsi:  not patched, not tested (I don't have the hardware)
> 90.ipmux:  not patched, not tested
> 91.lvs:  not patched, not tested

90.ipmux is obsolete so dont bother with that one.
91.lvs is a way to make the entire cluster act as one single ip
address. This replaces 90.ipmux
(lvs used to emulate a layer-4 loadbalancing switch)
Please see the docs for what lvs is and how to set it up in the
manpages of the latest 1.0.46 version.

One critical thing is in /etc/ctdb/functions. That is to ensure that
the "tcp socketkiller" works correctly.
This is a tool that kills off tcp connections  when we do fast ip
failover between nodes.
A similar approach is also used to "kickstart" tcp connections that
may be in a retransmission timeout state
while we do failover (we call this tickle-ack)

Can you please verify that the socketkiller works?
This is how to do it :
1, Startup ctdb/samba.
2, Create a TCP connection to samba.   Just do "telnet <public address> 445"
3, On the ctdb node that is currently hosting this public address,
check with netstat -a -n and find this TCP connection.

4a, On this node, run "ctdb killtcp <srcip:port> <dstip:port>" for
that TCP connection.
     Now check with netstat -a -n on both this node and also on the client.
     On one of the sides, either the client or the node,  that TCP
connection should be killed and no longer in ESTABLISHED state.

4b, Do the same as before but this time run it as "ctdb killtcp
<dstip:port> <src:ip>"
     This time the other end of the TCP connection should have been killed.

This is the most important part. So if this work, there is nothing
else very vital that needs to be checked.
I tried to fixup the paths to executables a while ago    but that was
>6months ago  so there might have crept in some paths
to executables either in the eventscripts or in /etc/ctdb/functions
that are only valid on RHEL which i use.

70.iscsi only works with the STGT iscsi target. So if you dont ship
with an iSCSI target or you ship one of the other targets and not STGT
it wont work and you wont have to worry about that script.
(STGT is nice since it can emulate a huge jukebox with burnable DVD+R
disks in it.   Yeeehaaa)

Please also test that the NFS stuff works in some capacity.
Just configure it according to ctdb.samba.org and make sure that ctdb
does start and stop the nfs service correctly.

I dont have any systems running debian, but If someone sends me a DVD
with debian i can build a virtual cluster and test.
Othervise, to make sure NFS should work reasonably,  this needs a
cluster with at least 2 nodes and one nfs client.
1, Set up NFS with CTDB
2, Start a network trace on the client.
3, Mount an export from a public address of the cluster.
4, Do an ls on the client to make sure NFS works
5, check with netstat on the client and also on all the nodes that the
connection is ESTABLISHED on the correct node.
6, disable the node that is currently hosting that public address
("ctdb -n all ip" will tell you which node is holding that ip)
    by   "ctdb disable -n <nodeid>"
7, Use ls again and it should hopefully still work
8, Check with netstat -a -n again on the nodes,   the TCP connection
should now have moved to a different node.

Send the network trace to me and I can verify it looks good. I also
need the mac addresses for the public interface on all the ctdb nodes
to verify.

>> On Wed, Jul 9, 2008 at 11:40 PM, Mathieu PARENT <math.parent at gmail.com> wrote:
>>> Hi,
>>> On Wed, Jul 9, 2008 at 7:27 AM, Christian Perrier <bubulle at debian.org> wrote:
>>>> (snip)
>>>>      ctdb: good support by Mathieu (who just began the NM process)
>>>>            Should we consider it for testing?
>>> yes ! ctdb is even usefull without samba (it will replaces heartbeat
>>> in our particular setup). And it it easy to compile samba with ctdb.
>>> I will propose a new upload soon, probably the latest befor freeze.
>>>>            Will we build samba 3.2.0 with it?
>>> We first have to know the answer of this :
>>> Does enabling ctdb at compilation time changes samba behavior when
>>> "clustering = yes" is not set in smb.conf?
>> No it does not.
>> When clustering=yes is NOT set in smb.conf  you will have the exact
>> same behaviour as if samba was compiled without ctdb.
>> So, there is no need to provide both a "normal" and a "clustered"
>> version of samba.
> This is a good news. So we can enable clustering by default in debian
> by adding "--with-ctdb --with-cluster-support" to configure options
> (--enable-pie=no is already enabled)/

Yes. I hope that eventually the default will be --with-ctdb and
--with-cluster-support for all Samba builds.

> Mathieu Parent

ronnie sahlberg

More information about the samba-technical mailing list