Setting up CTDB on OCFS2 and VMs ...

[Michael Adam]

On 2014-12-31 at 23:06 +0000, Rowland Penny wrote:
> On 31/12/14 22:34, Martin Schwenke wrote:
> >On Wed, 31 Dec 2014 15:46:30 +0000, Rowland Penny
> ><repenny241155 at gmail.com> wrote:
> >
> >>
> >>Why have very similar data in 3 places ? why have the conf (which
> >>incidentaly isn't called a conf file) in a different place from the
> >>other ctdb files in /etc ?
> >Everything should be in /var/lib/ctdb/.
> >
> >/var/lib/lib/ctdb/ is due to the Debian packaging bug that has already
> >been discussed.  This is not CTDB's fault.
> 
> OK, I can accept that
> >
> >/var/ctdb/ is an old location that we still support as a fallback.
> >Unfortunately, until the daemon gets to a particular point
> >where /var/lib/ctdb/ is created, CTDB attempts to maintain backward
> >compatibility by using /var/ctdb/.  That's clearly something we need to
> >clean up.  However, it is superficial.
> 
> This, in my opinion, is stupid, shouldn't the daemon check/create
> /var/lib/ctdb at the start, it is not superficial, it is spraying the HD
> with totally unrequired directories and files.
> 
> >
> >I don't think that makes CTDB a *MESS*.  I think it means that CTDB has
> >a superficial bug.  You're basing most of your evaluation on a Debian
> >packaging bug that we discussed weeks ago.  :-(
> 
> I hit another problem, that, until Michael Adam posted, I was unaware of, It
> seems that ctdb is hardcoded to put the socket in /var/lib/run/ctdb.

There is of course a hard-coded *default* in ctdb. And this is
usually /var/run/ctdb/ctdbd.socket. Of course packagers can change
that hard coding of the default to another value.
And it has by accident been changed to var/lib/run... in the
debian packages. See the bug report martin posted:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773016

> I cannot find any documentation to tell me this (note I am not saying it
> doesn't exist, just that I cannot find it).

Look for socket in "man ctdbd.conf"

> changing the line in smb.conf to
> point to the hardcoded socket, allows samba to join the domain and
> subsequently samba to start,

That is just a band aid for bad packaging.
If you compile samba against the proper ctdb,
this setting is not needed.
The smb.conf setting is also useful in case
you choose (as the admin of the cluster) to chang
ctdb's socket location by the CTDB_SOCKET variable.

> but I still do not have a lock on ctdb, if I
> set the lockfile location in /etc/default/ctdb, ctdb mostly refuses to start
> and when it does start, there is only one healthy node.

> Now I don't know whose fault this is, debian or ctdb, but you seem to know
> that there are problems and seem to be pointing the finger at debian and
> seem to be asking me to help fix it by reporting bugs to debian. Well, it is
> your software, so it is your responsibility to get it fixed.

You misunderstand: If there is a problem inside ctdb proper,
this is ours to fix, and Martin certainly did not suggest to
report propoer ctdb bugs to debian packaging! But if the packaging
adds a problem, that is beyond our reach. And someone should report
that to the debian folks, ideally someone who has experienced
the problem himself. :) As you can see, Martin himself has
already reported several bugs to debian packaging...

And regarding your reclock problem:
As indicated earlier, I am inclined to think that
this is a problem with your CusterFs-Setup or ctdb's
configuration. We need more details here.

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150101/819eebfd/attachment.pgp>