Jelmer Vernooij wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ok, grabbing together some emails. Mutt's join replies function is > cool :-) > > I figured I may as well ask: How would you like to be creditied in CVS > > commits? As 'ctrlsoft' or as 'Jelmer' or as '<[EMAIL PROTECTED]>' or > > ... ? > Please use 'Jelmer Vernooij' or 'Jelmer'; there's some weird > east-asian company out there that has called itself ctrlsoft so that > might be confusing.
OK, will do. > > I was talking to tpot recently, and he found an interesting bug in the > > current mulitple pdb code. > > > If we don't implment setsampwent() in a backend, and that is the only > > backend then we segfault... > > > Now the is relitivly easy to 'fix', but I wonder if there is a better > > way to do the design: > > > How about doing all the setsampwent() calls at the start, then storing > > the 'getsampwent' and 'endsampwent' fucntion pointers in some sort of > > list. This way we do all memory allocation etc during the 'set', and > > not implicitly halfway thought the 'get'. We can also ensure that we > > actually do the 'end' correctly, no matter what modules did/did not > > implement this. > > > I was thinking we should just have two linked lists, one of > > 'getsampwent' functions, another of 'endsampwent' functions and use them > > in the various loops. > > > How does this sound? > Sounds cool! One sidenote: in case someone calls endsampwent when > one hasn't retrieved all users, we might be calling some setsampwent > and endsampwent functions unnecessarily. What would you say? I have no problem with doing a few extra 'set' and 'end' if we don't finish the list - I would prefer them to the current setup, which would imply a lot of loops all over the getent code to get correct. > > > I figured I might just jot down some ideas for the future of the passdb > > subsystem, as well as some of the more immediate todo items: > > > Also, we need to get interface versioning going: We have just changed > > the interface, but we didn't tell anybody :-) (SID stuff). > > How would we do this? Like the VFS subsystem ? (have an int with > the number of functions in the pdb_methods struct?) Or only load > plugins that have the same version number as the samba binaries have? I quite like the way I saw in your pdb_xml, where the XML lib has a macro ensuring correct versions. Or just passing the version number as an arugment or (this one I quite like) having Samba read a global variable from the pdb module. > > I would like to get pdb_xml into Samba at some stage. What do people > > think of the idea? (Its a passdb that exports to XML in order to allow > > backups/hand updates pdb backends, tdbsam in particular.) I've not > > looked at it much, but it does require the basic stuff like new > > configure magic (to detect the XML lib etc). > > > http://people.nl.linux.org/~jelmer/downloads/ > > Maybe a directory 'plugins' could be added to the current CVS > repository? There are currently some plugins in 'examples', but I > think that's the wrong place. Or maybe add a directory source/plugins, > in case we want to have a Makefile generated for the plugins (which > could be quite necessary, seeing the dependencies on things like > libxml, libmysql, virusscanner, etc). > > I heard someone (tridge, ab?) was working on a tool that retrieves the > CFLAGS and LDFLAGS for samba plugins. Such a tool would be quite > useful, because that would also mean that plugin developers don't need > to have the samba sources on their system. Who knows more about it? I think ab was working on it. > Oh, another idea: have a way to easily select what to do with modules > : build them in static, build them as a plugin or don't build them at > all. This is very useful for people who: > > - - have a OS without dl support(they can even build 'foreign' modules > static) > - - packagers who don't want their package to depend on a lot of other > stuff (libldap, libxml, etc) but still can build packages with only > a plugin Sounds like a nice idea - I'll see what others think of it. Andrew Bartlett, -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
