Solving: samba registry with client programs

[Stef Walter]

I posted earlier about this, but figured some background might be handy.

I'm building an on demand DBus service which makes it simple to enroll a
machine in an AD domain, set up domain logins, manage shares and so on.
It would be called from gnome-control-center and other bits of UI.

The samba registry is a really great fit for this, for reasons detailed
below. But I ran into the problem that using the registry then prevents
samba client programs (like smbclient) from working. They get an 'access
denied' error when trying to load the config because registry.tdb is not
readable.

It has already been established that making registry.tdb world readable
is a bad idea. So here are the various other options. I'd like to try
option (3) unless that has problems, in which case option (4) seems like
the best alternative.


Option 1. Don't use the registry

   Adding a file share by modifying smb.conf and restarting smbd
   seems like it would disconnect clients. This would be really
   broken behavior for desktop users or server admins using a
   config tool.

   In addition for machine generated config it's always awkward
   and brittle to deal with modifying a text file: Locking issues,
   user modifications, testing config etc... So registry config
   is a nice to have for machine generated configuration, at least
   for shares.

   Seems like these are some of the main points of the samba registry
   based config was to solve. Not sure how else to solve the problem
   of kicking clients when reconfiguring smbd.

Option 2. Have client programs ignore failures loading the registry

   Client apps would just use smb.conf and not use the registry.
   They would ignore failures to load the registry, and just use
   the configuration available in smb.conf.

   This works well if the registry is deployed mainly as a way to
   configure shares, and much of the other stuff lives in smb.conf.

   This only really makes sense with 'include = registry' in smb.conf.
   I could create a patch which implements this.

Option 3. Mirror config from the registry

   As Volker suggested, on each commit to the config parts of the
   registry, the registry config would be exported to a read-only
   file in the "lock directory".

   Client apps would detect an access failure when loading the
   registry and silently include this file in their config
   instead of using the registry.

   I could try and create a patch which implement this.

Option 4. Have a smb-client.conf

   As Simo suggested, have clients use smb-client.conf when that file
   is present. This would be instead of reading the smb.conf file and
   thus the registry.

   I could try and create a patch which implements this.

Option 5. Use a daemon to read config

   As Simo suggested there might be a daemon which runs and makes
   the config available to the clients using RPC.

   Seems resource intensive, and out of my current time and
   capabilities.


Cheers,

Stef