Setting up CTDB on OCFS2 and VMs ...

Rowland Penny repenny241155 at gmail.com
Thu Jan 1 12:43:05 MST 2015


On 01/01/15 19:10, Rowland Penny wrote:
> 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:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773016
>
> Why not just do it like samba & smb.conf, it is set at compile time 
> but can also be changed at ctdb startup by using -s /path/to/smb.conf
>
>>
>>> 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, will do.
>
>>> 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...
>
> I will look into the bug reports

OK, I have looked at the Debian bug report referred  to above and have a 
couple of questions:

the bug report title is: ctdb: Starting CTDB fails with "Unable to open 
/var/lib/run/ctdb/.socket_lock". What is '.socket_lock' ? all I have in 
the ctdb directory is 'ctdbd.socket'.

There is no mention of samba under 'Versions of packages ctdb depends 
on:'. If ctdb relies on the version of samba it is compiled against, 
then shouldn't it be mentioned there, or has no one explained this to 
debian ?

Rowland

>
>> 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.
>
> I have posted how I set up the cluster, if you want to know anything 
> else, just ask.
>
> Rowland
>
>> Michael
>>
>



More information about the samba-technical mailing list