Solving: samba registry with client programs
jra at samba.org
Wed Apr 18 13:40:24 MDT 2012
On Wed, Apr 18, 2012 at 09:34:23PM +0200, Volker Lendecke wrote:
> On Wed, Apr 18, 2012 at 03:02:37PM -0400, simo wrote:
> > On Wed, 2012-04-18 at 18:23 +0200, Stef Walter wrote:
> > > On 04/17/2012 10:14 PM, Volker Lendecke wrote:
> > > > On Tue, Apr 17, 2012 at 03:08:35PM -0400, simo wrote:
> > > >> 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.
> > > >
> > > > We've also had repeated requests for an lgpl library to
> > > > access samba's registry. Doing it via some form of RPC would
> > > > IMHO be the right way to do it. Simo is right, smbd already
> > > > supports registry access. It should be simple to add a
> > > > unix-domain socket only mode for smbd, just to access the
> > > > registry. The major piece that's missing is the NDR support
> > > > library required to do the RPC marshalling. That's only
> > > > available as GPL code.
> > >
> > > Until someone has time to implement that, attached is a patch which
> > > implements the registry mirroring suggested.
> > >
> > > It mirrors the global settings of the smbconf registry to a file next to
> > > registry.tdb called registry-mirror.conf. This is seamlessly used when
> > > running from an smbclient that is not root.
> > >
> > > What do you think?
> > Sounds like a good start, but I wonder if we shouldn't rather use tevent
> > and schedule a write out later on (like no more often than every 5
> > seconds or so.
> > This way we can gather a set of changes and only output a new file when
> > they get all in.
> Well, this does not work too well for "net conf". And, I
> don't think that registry smb.conf modifications are
> so frequent that this really hurts. The fsyncs on the
> registry.tdb are probably much, much more expensive.
The only problem with this is if we mirror this data somewhere
else we'll never fix the problem correctly - which is to have
a library that asks smbd.
Is half-a-loaf better than none in this case ?
More information about the samba-technical