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

This is a discussion on CTDB by default in Debina lenny? (was: [Pkg-samba-maint] Situationof various samba packages) - Samba ; Hi, On Wed, Jul 9, 2008 at 7:27 AM, Christian Perrier wrote: > (snip) > > ctdb: good support by Mathieu (who just began the NM process) > Should we consider it for testing? yes ! ctdb is even usefull ...

+ Reply to Thread
Results 1 to 6 of 6

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

  1. CTDB by default in Debina lenny? (was: [Pkg-samba-maint] Situationof various samba packages)

    Hi,

    On Wed, Jul 9, 2008 at 7:27 AM, Christian Perrier 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?

    I'm forwarding this question to samba-technical.

    >
    > (snip)



    Mathieu Parent


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

    Hi,

    Thanks for your quick reply.

    On Wed, Jul 9, 2008 at 11:39 PM, ronnie sahlberg
    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...ile&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


    > On Wed, Jul 9, 2008 at 11:40 PM, Mathieu PARENT wrote:
    >> Hi,
    >>
    >> On Wed, Jul 9, 2008 at 7:27 AM, Christian Perrier 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)/



    Mathieu Parent


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

    On Thu, Jul 10, 2008 at 5:04 PM, Mathieu PARENT wrote:
    > Hi,
    >
    > Thanks for your quick reply.
    >
    > On Wed, Jul 9, 2008 at 11:39 PM, ronnie sahlberg
    > 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...ile&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 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 ort> ort>" 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
    ort> "
    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 "
    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 wrote:
    >>> Hi,
    >>>
    >>> On Wed, Jul 9, 2008 at 7:27 AM, Christian Perrier 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
    >


    regards
    ronnie sahlberg


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

    Hi,

    On Thu, Jul 10, 2008 at 5:04 PM, Mathieu PARENT wrote:
    > Hi,
    >
    > Thanks for your quick reply.
    >
    > On Wed, Jul 9, 2008 at 11:39 PM, ronnie sahlberg
    > 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...ile&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 do not like this patch.
    It is very small and trivial but it does mean that debian and rhel
    would now have different event scripts which I would like to avoid.

    May I propose a slightly different approach?

    If you have a look at /etc/ctdb/functions
    you will see that the "service" we call from the event script is not
    your normal /sbin/service executable but rather our
    own shell function called "service" :
    ################################################## ####
    # simulate /sbin/service on platforms that don't have it
    service() {
    service_name="$1"
    op="$2"
    if [ -x /sbin/service ]; then
    /sbin/service "$service_name" "$op"
    elif [ -x /etc/init.d/$service_name ]; then
    /etc/init.d/$service_name "$op"
    elif [ -x /etc/rc.d/init.d/$service_name ]; then
    /etc/rc.d/init.d/$service_name "$op"
    fi
    }


    Instead of patching the eventscripts, please enhance this service() function to
    1, detect if this is a debian system
    2, if so, translate httpd -> apache2 etc.

    I would be happy to apply such a patch to upstream.


    It may sound like a very trivial nitpicking request but it would allow
    us to have the exact same eventscripts for both debian and rhel.
    That would have great value.


    regards
    ronnie sahlberg


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

    Quoting ronnie sahlberg (ronniesahlberg@gmail.com):

    > I dont have any systems running debian, but If someone sends me a DVD
    > with debian i can build a virtual cluster and test.


    That is not very likely to happen..:-))

    The easiest way is installing the system with one of our ISO images.

    I think the best is to pick up a "netinst" image from
    http://www.debian.org/devel/debian-installer

    Pick a "Debian Installer beta 2" image, which is about 130Mb download.

    There are also ISO images for Debian "lenny" on cdimage.debian.org but
    I can't describe the exact path to reach them there..just go and see
    if you prefer that way.

    That will install a Debian "lenny" system (which is the version we're
    currentlmy preparing). Just install a "standard system" and choose the
    "File and Print server" task, not "desktop system". That will install
    a fairly minimal system with samba packages included (which you might
    want to replace later by custom packages if that's needed to test ctdb
    stuff).


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkh28+MACgkQ1OXtrMAUPS3HFwCfVFmyB2EjXq mJwazOfiXN6Q0X
    6+AAn2CaZR41603vKBhzZ8OfalqVWVdD
    =qCUV
    -----END PGP SIGNATURE-----


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

    hi,


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


    I put this on my TODO list, but won't test it soon. Maybe someone else
    can take it?

    >
    > 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 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 ort> ort>" 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
    > ort> "
    > This time the other end of the TCP connection should have been killed.


    I've tested both 4& and 4b and it works! Great...

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


    They seems to be valid. Just note that I had problem with ipv6 (solved
    this by disabling the unneeded ipv6 interfaces).

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

    I don't have STGT iscsi, and even any iscsi. I use FC channel SAN
    which doesn't seems to require a ctdb managgement.

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

    This one will probably take more time...

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


    Will do this after a complete test of samba.

    >
    > regards
    > ronnie sahlberg
    >


    Mathieu Parent


+ Reply to Thread