[PATCH] New external idmap module

[simo]

Sorry,
I am experimenting locally with bzr trees and forgot to merge a couple
of files.

Attached there is a working patch.

On Tue, 2006-05-30 at 15:01 -0400, simo wrote:
> Recently I have been involved in making it easier to provide custom id
> mapping for samba. In some situations it is preferable to do the mapping
> from outside samba to keep control on what get mapped.
> 
> One of the goals was also to make it easier to provide such mapping
> without the need to change the source and keep it in sync at each new
> samba version.
> 
> The idmap interface has not changed much if at all since we introduced
> it in 3.0 and I do not see it changing much in future, so I decided to
> make a module that forwards mapping calls to an external daemon using
> either a unix socket or eventually a tcp socket.
> 
> Actually I tested only the unix socket, but I added the tcp transport
> too because I think it is a great idea to be able to use this module to
> keep multiple samba server in sync without requiring to set up an ldap
> server just to keep the shared map. (The tcp socket may also help the
> architectures that does not have a viable unix socket facility if any).
> 
> This is the smb.conf syntax to use this module:
> 
> idmap_backend = external:<local|remote>:<unix|tcp>:<path|address>
> 
> 1) Define whether it is a local or a remote store
> 
> You must be careful with this parameter, usually you will want to
> declare the external store as "remote", this will let samba use
> idmap_tdb to keep a local fixed cache, this also means that if your
> daemon dies, samba will be able to solve all the mapping that are
> already in the cache and you will loose only the capability to store new
> mappings.
> 
> Anyway in some cases you may want total control of the cache too, to be
> able to change mappings without the need to wipe out the tdb cache, you
> will just need to reconnect and spawn a new smbd process to see the new
> mappings, in this case you may declare the module as "local" and it will
> take the place of the idmap_tdb cache.
> 
> 2) Select the desired transport.
> 
> I advice you to use "unix" against "tcp", the tcp transport actually has
> no authentication mechanisms so you must use special care when using it
> (I advice to use stunnel if you need to use it between 2 machines, so
> that the communication is sealed and x509 certificates can be used for
> mutual authentication).
> The unix socket on the other side can rely on file system permissions
> and I strongly advice to keep the socket readable and writable by root
> only.
> 
> 3) either the path of the unix socket (remember that unix socket paths
> cannot exceed 108 characters), or the tcp address in the form:
> a.b.c.d:port
> 
> Jerry,
> if there are no objections I would like to commit this code into trunk
> and see it in 3.0.24, I think it will be of great use for many people
> that want better control on their mappings without being constrained by
> the current available modules. The communication mechanism (described in
> the module source code) is really simple and can be easily implemented.
> The example daemon uses an sqlite3 database to keep the maps just to
> show how it is easy to use alternative methods.
> 
> If there is real interest in the tcp support, let me know so that I can
> dedicate some energy in enhancing it.
> 
> Have fun,
> Simo.
> 
-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samba3_idmap_external.patch
Type: text/x-patch
Size: 44923 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060530/7e449075/samba3_idmap_external.bin