Setting up CTDB on OCFS2 and VMs ...
repenny241155 at gmail.com
Thu Jan 1 12:30:03 MST 2015
On 01/01/15 18:53, Michael Adam wrote:
> 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:
>> 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"
OK, tried to do as you advised, turns out there isn't a ctdbd.conf
manpage on debian, mind you ctdbd.conf doesn't exist either.
I finally find the reference in 'man ctdbd'
>> 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.
More information about the samba-technical