Setting up CTDB on OCFS2 and VMs ...

[Rowland Penny]

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:
>
>> I have investigated ctdb on my system and have come to the conclusion
>> that ctdb is a *MESS*, don't believe me ? then consider this:
>> root at cluster1:~# ls /var/ctdb
>> iptables-ctdb.flock  persistent  state
>> root at cluster1:~# ls /var/lib/ctdb
>> iptables-ctdb.flock  persistent  state
>> root at cluster1:~# ls /var/lib/lib/ctdb
>> brlock.tdb.1           iptables-ctdb.flock  persistent
>> smbXsrv_open_global.tdb.1     smbXsrv_version_global.tdb.1
>> dbwrap_watchers.tdb.1  locking.tdb.1        printer_list.tdb.1
>> smbXsrv_session_global.tdb.1  state
>> g_lock.tdb.1           notify_index.tdb.1   serverid.tdb.1
>> smbXsrv_tcon_global.tdb.1
>> root at cluster1:~# ls /var/ctdb/persistent/
>> root at cluster1:~# ls /var/ctdb/state/
>> failcount  interface_modify_eth0.flock    service_state
>> root at cluster1:~# ls /var/lib/ctdb/persistent/
>> root at cluster1:~# ls /var/lib/ctdb/state/
>> failcount  interface_modify_eth0.flock    service_state
>> root at cluster1:~# ls /var/lib/lib/ctdb/persistent/
>> account_policy.tdb.1  ctdb.tdb.0  ctdb.tdb.1  group_mapping.tdb.1
>> passdb.tdb.1  registry.tdb.1  secrets.tdb.1    share_info.tdb.1
>> root at cluster1:~# ls /var/lib/lib/ctdb/state
>> failcount  interface_modify_eth0.flock    persistent_health.tdb.1
>> recdb.tdb.1  service_state
>>
>> 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. I cannot find any documentation to tell me this (note 
I am not saying it doesn't exist, just that I cannot find it). changing 
the line in smb.conf to point to the hardcoded socket, allows samba to 
join the domain and subsequently samba to start, 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.

Rowland

> peace & happiness,
> martin