samba - Nov 2010 - [obnox@samba.org: 3.6:idmap:Q2: get rid of (all/most) idmap alloc parameters for idmap_ldap ?]

Hi Samba Users,

I forgot to send this mail to the samba ML, too.

The question is whether anyone is using the idmap alloc
config options for idmap_ldap. I would like to remove
them for Samba 3.6. Details below.

Thanks - Michael

----- Forwarded message from Michael Adam <obnox at samba.org> -----

Date: Wed, 10 Nov 2010 11:19:56 +0100
From: Michael Adam <obnox at samba.org>
To: samba-technical at lists.samba.org
Subject: 3.6:idmap:Q2: get rid of (all/most) idmap alloc parameters for
	idmap_ldap ?

Hi,

a second question about config-visible idmap changes I propose
for samba 3.6:

In my idmap rewrite, I kept the alloc related parameters for the
LDAP idmap backend for now:

- idmap alloc config : ldap_url
- idmap alloc config : ldap_base_dn
- idmap alloc config : ldap_user_dn

and the related idmap alloc secret.

I would like to get rid of these.

Therefore, I am asking here, if there is
anyone out there using these?
I can not imagine a reason why one would
want to use different server and/or user+password
for storing the uid/gid counter.

The only option that I would attest a certain, though minimal,
right to exist is the ldap_base_dn. But usually, it should
imho ok to store the uid/gid counter in the same location
as the mappings.

So, again: Are these options needed/used at all?
Or can I remove them for 3.6.0 ?

Cheers - Michael


Note: If we need to keep any of the options, the current form
(idmap alloc config : <option> = ...) would reference
the default config, but my idmap rewrite would enable us
to set these on a per-domain basis, which would call
for options like this "idmap config DOMAIN : alloc_<option>")




----- End forwarded message -----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/samba/attachments/20101110/d94ccb0e/attachment.pgp>

Hi Michael,

I, for one, am using config alloc because that is how things were done 
on 3.0.xx before I migrated data to a new box that uses 3.5.4. I do not 
care very much about the configuration changes. But I beg you that 
documentation regarding idmap_ldap is updated including how idmap_ldap 
works.

I had issues getting the configuration in 3.5.x to a state where I could 
run wbinfo --set-* successfully and I still have an outstanding issue 
where new accounts created in AD are not being automatically mapped by 
winbind and I have to manually create these mappings.

> In my idmap rewrite, I kept the alloc related parameters for the
> LDAP idmap backend for now:
>
> - idmap alloc config : ldap_url
> - idmap alloc config : ldap_base_dn
> - idmap alloc config : ldap_user_dn
>
> and the related idmap alloc secret.
>
> I would like to get rid of these.
Be my guest. I don't care so long as these changes are documented so 
that people will know what is going on. This will be the second time 
that I will have had to fight with changes in idmap ldap related 
configuration without notice.

>
> Therefore, I am asking here, if there is
> anyone out there using these?
> I can not imagine a reason why one would
> want to use different server and/or user+password
> for storing the uid/gid counter.
Right now there is nothing that actually explains to me what idmap_ldap 
does and so I don't have a clue as to what are you talking about.

>
> The only option that I would attest a certain, though minimal,
> right to exist is the ldap_base_dn. But usually, it should
> imho ok to store the uid/gid counter in the same location
> as the mappings.
>
> So, again: Are these options needed/used at all?
There is an awful lot of 'documentation' out there detailing the use of 
alloc. People go nuts just figuring out how to do winbind + ldap.

> Or can I remove them for 3.6.0 ?
Be my guest! Just update/provide documentation!

>
> Cheers - Michael
>
>
> Note: If we need to keep any of the options, the current form
> (idmap alloc config :<option>  = ...) would reference
> the default config, but my idmap rewrite would enable us
> to set these on a per-domain basis, which would call
> for options like this "idmap config DOMAIN :
alloc_<option>")
>
>
>
>
> ----- End forwarded message -----
>
>