Solving: samba registry with client programs

[simo]

On Tue, 2012-04-17 at 20:52 +0200, Stef Walter wrote: 
> 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.

Stef, FWIW, you do not need to code up a new daemon, running smbd would
suffice as it provides access to the registry RPC enpoint over NCACN_NP
or the new NCALRPC. But you would need to write some client logic to do
that and you would require smbd running.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>