Setting up CTDB on OCFS2 and VMs ...

[Martin Schwenke]

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.

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

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

peace & happiness,
martin