Aliases only in winbind and then...

Fri Mar 5 09:34:25 GMT 2004

here are some discusion for the #samba-technical irc.freenode.net channel:

[09:39:09] <konold> is there any way to avoid the blocking of the 
winbind service when too many request come simultaneously? E.g. forking 
some extra winbindd
[09:39:13] <konold> is there any way to avoid the blocking of the 
winbind service when too many request come simultaneously? E.g. forking 
some extra winbindd?
[09:39:27] <konold> sorry for the duplicate
[09:39:47] <@abartlet> konold: sort of.  In samba 3.0, we are in 'dual 
deamon' mode by default
[09:40:01] <@abartlet> but we are single-threaded, when data is not in 
the cache
[09:47:10] <vl> abartlet: What exeptions to the 'smdb does only 
algorithmic' do you see?
[09:50:00] <metze> I think we should really have selecable modules for 
idmapping in smbd
[09:51:39] <metze> so that we could select between, algorithmic, and 
asking winbind or asking passdb and getpw*, or a custom module that does 
algorithmic mapping together with some hardcored expections
[09:52:36] <@abartlet> also on idmap, we need to ensure that we can do 
the 'right thing' on domain members, identical to what we do on domain 
servers
[09:53:11] <@abartlet> that is, when there is a valid SID->UID mapping 
on the PDC, all domain members should pick it up without fuss or bother
[09:53:32] <@abartlet> vl: is that 'smbd only does algorithmic, unless 
winbind knows better'?
[09:54:10] <@abartlet> the main problem is the need for 'smbd does 
getpwnam() based name matching', which jerry revived after I killed it :-)
[09:54:43] <@abartlet> idra: I fully agree with all the points in your 
post to the list
[09:54:51] <@abartlet> (there is a first time for everything ;-)
[10:03:55] <metze> but there's one thing I still thinking about, and 
that the winbind layout
[10:04:41] <metze> but I fear we cannot do anything against it since the 
nss module has to be LGPL or something like this and winbind is GPL
[10:05:28] <metze> so we always need to talk to the winbindd daemon and 
cannot access the account backend directly with the nss_winbind module
[10:06:09] <@idra> abartlet, tx
[10:06:19] <vl> abartlet: Ok, I meant 'smbd local' is to ask winbind, 
and if that fails, then do algorithmic.
[10:06:39] <@idra> metze, no, read my mail
[10:07:00] <@idra> metze, selectable methods are veil, it should be 
either algorithmic or mapped
[10:07:22] <@idra> metze, mixing the 2 case should be an exception to 
support old systems
[10:07:59] <metze> yep
[10:08:42] <@idra> ok than we agree (have you read my mail) ?
[10:08:43] <metze> as I understand your mails for new systems we would 
have one central user,group,trust ... storage backend
[10:09:06] <metze> and then let smbd and winbind use this
[10:09:09] <@idra> vl, what do you think about my mail? (feel free to 
answer on the list, I would prefer to keep all the samba tech community 
involved)
[10:09:10] <metze> right?
[10:09:18] <@idra> metze, right
[10:09:47] <@idra> metze, but that's nothing new, just passdb that get a 
more consistent/enriched functionalty/interface
[10:09:56] <@idra> I'm not planning anything advanced like gums
[10:10:00] <@idra> that's for samba 4
[10:10:12] <@idra> (with all the needed modifications, first of all ldb)
[10:10:20] <metze> but that's nothing new, just passdb that get a more 
consistent/enriched functionalty/interface...
[10:10:28] <metze> this is what I like!
[10:11:12] <metze> but we need nss_winbind->winbindd->passdb_backend to 
access the nss data, right?
[10:11:24] <@idra> metze, the nss_module must never access directly the 
passdb
[10:11:36] <metze> why?
[10:11:43] <@idra> metze, they must go through winbind (yes we can make 
a triple daemon of it if necessary)
[10:11:56] <@idra> metze, because nss_winbind need a stable interface
[10:12:06] <@idra> winbind need to expose a stable interface
[10:12:15] <@idra> and samba internals can change at will
[10:12:32] <@idra> plus the licencing issues
[10:12:36] <metze> we can define a stable interface without using a 
seperate deamon
[10:12:49] <metze> yep, the license issues are the problem
[10:12:57] <@idra> metze, there's no way to change the winbindd license 
(And I would oppose that for all the code I contributed)
[10:13:09] <metze> yep
[10:13:29] <@idra> metze, anyway the interface beetween nss_winbind and 
winbindd may be stable
[10:13:39] <metze> yep
[10:13:54] <@idra> metze,  as we saw the passdb interface changes a lot 
with time, so it is not suitable for direct connection with nss_winbind 
anyway
[10:14:47] <@idra> AND you do not consider running nss_winbind against a 
remote winbindd ;-) (not possible right now I know, but there's people 
that have produced patches for that)
[10:15:06] <metze> does I understand it right, that we would have smbd 
directly access passdb and idmap backends, without getpw*() or winbind 
askings
[10:15:30] <@idra> only in full sam mode
[10:15:37] <@idra> in full sam mode you trust the passdb
[10:15:53] <metze> ok, nice
[10:15:54] <@idra> in compatibility mode you can't and smbd will have to 
use getpw* functions
[10:16:02] <metze> yep
[10:16:24] <@idra> you trust the passdb in full sam mode because you 
know it is the source of information for nss_winbindd so there is no 
need for double check
[10:16:26] <metze> all I want is to have a runtime config for selecting this
[10:16:34] <@idra> metze, yeah definitively
[10:16:47] <@idra> we need a compatibility mode = yes/no parameter
[10:16:50] <@idra> default to yes
[10:17:06] <@idra> if set to yes winbindd_passdb is disabled
[10:17:15] <@idra> and smbd ues getpw* for acciunts
[10:17:21] <metze> I think not, I would like a module based interface
[10:17:33] <metze> not just yes/no
[10:17:36] <@idra> if enabled winbindd_passdb is used and you better 
have nss_winbind running on the system ;-)
[10:17:51] <@idra> module based? please explain
[10:17:53] <@abartlet> metze: modules are good internally, but give the 
user's a fighting chance of configuring it
[10:18:08] <@abartlet> so, the user needs to see the minimum possible 
configuration options
[10:18:33] <@idra> metze, modules need to support both methods, and the 
minimum is to support compatibility mode only (eg. smbpasswd)
[10:19:09] <@idra> of course if you use smbpasswd and select 
compatibility mode = no, that will be simply ignored nad a warning 
printed in the logs
[10:19:17] <metze> can't we do it like the auth backend, and have a 
default list selected by other options
[10:19:32] <@idra> NOTE: current winbindd functionality for domain 
members will not be affected by this change
[10:19:51] <@idra> metze, don't see why or how that fits the design
[10:20:00] <metze> ?
[10:21:13] <@abartlet> metze: lets not tie ourselves down with details. 
  We all love modules as much as you do, but that's not the point here
[10:21:14] <metze> in smbd/uid.c we have functions like uid_to_sid()... 
and I want to be able to replace them with custom function
[10:21:41] ab [~ab at 217.21.35.34] has joined #samba-technical
[10:21:42] <@idra> metze, ahh you're speking of idmap modules?
[10:21:42] <@abartlet> metze: that's a sub issue, and we have idmap 
backend for exactly that anyway
[10:22:00] <@idra> metze, we already have idmap modules, no need to have 
something different
[10:22:19] <metze> abartlet: ok , yep, but only used in winbind and not 
in smbd
[10:22:29] <metze> and I don't want smbd to ask winbind
[10:22:54] <metze> at least if I have a algorithmic idmap module
[10:25:05] <@idra> metze, yeah that's a detail we need to sort out
[10:25:26] <metze> ok, then I think we're on the right way:-)
[10:25:28] <@idra> metze, we have to make a very great job this time, as 
idmap has been banned from smbd by jeremy+jerry last time :-)
[10:25:46] <ab> hi all
[10:25:50] <metze> hi ab
[10:25:53] <@idra> metze, mee too, but jerry and jeremy will have to be 
convinced that idmap in smbd is ok ;-)
[10:25:56] <@idra> hello ab
[10:27:41] <metze> I think we should only merge a completely ful working 
code to the release branch!
[10:28:03] <metze> tested in each corner:-)

-- 
metze

Stefan Metzmacher <metze at samba.org> www.samba.org