configuration, ldap and NetInfo

Luke Kenneth Casson Leighton lkcl at regent.push.net
Thu Apr 16 12:52:40 GMT 1998


frank,

thanks for your comments / suggestions.

ok, shan't comment on smb.conf parameter formats: chris (mr parser), can i
leave that to you?

my feeling is that if you get to put in some "database" abstraction, then
the existing smb.conf system should just become another database, this in
the form of a text one.

i too have been thinking of optimising the load parameter system, and also
making sure that it's possible to support "personality changes" properly.
this by putting all the parameters that allow % substitution macros into a
structure.

i need this to support the SMBtrans2 NetUserGetInfo() and the
dce/rpc LsaSamLogon() calls properly, because at the moment they are not.

regarding the proposed password database functions, the API that is needed
should be Get/Set/Add/Del SamUser(SID, RID, SAM_USER_INFO_21).  this is
all that is needed.

oh, except that an equivalent set of group functions is also needed, which
at present doesn't exist at all in samba.

luke

"hey mickey, you're so fine, you're so fine you blow my mind HEY MICKEY!" <lkcl at samba.anu.edu.au>



On Thu, 16 Apr 1998, Robert Frank wrote:

> I had a look at the samba as of April 9th, in regards of adding NetInfo,
> ldap, or whatever else. I mainly looked through params.c and loadparams.c.
> 
> 
> I was a bit anoyed to see some non-samba related code (SWAT) in the
> sources. I think that samba and configuration managers must be completely
> decoupled (in regards to the source code).
> 
> Andrew, why add another field (union) for the defaults? A boolean
> specifying whether the value is a default or was loaded would suffice -
> no? In this way, you could add an option to testparm (e.g. -d, -n) which
> would output only the defaults, only the added values, or both.
> 
> 
> If I properly understood the mechanism of the parser, then line 333 in
> params.c (which sets a NULL character in the buffer) will force users to
> add a space after the = sign. If they don't, then the first character of
> the value will be lost.
> 
> 
> Now to the changes I have in mind: (Jean-Francois, do pipe in if this is
> totally inadequate for ldap!)
> 
> 
> First of all, NetInfo, and probalbly any other database interface,
> delivers lists as such (and not as a string of values), thus, I'd like to
> change the syntax of the smb.conf file (very slightly):
> 
> <nofill>
> - a string is a sequence of non-whitespace and non-comment characters or
>               a sequence of any characters except " enclosed in ".
> - escape characters are allowed:
>      \t for tab
>      \r for carriage return
>      \n for new line
>      \" for a single " within a string
>      \  (backslash space) for a space
>      \nnn for an octal value of a character (this if for forreign character sets!)
>      \# for a # within unquoted strings
>      \; for a ; within unquoted strings
>      \\ for a single \
>      \\n (backslash followed by a new line) for an extended line
> 
> - a parameter assignment is terminated by a semicolon 
>   (this blends nicely with the current notation of starting a comment 
>    and makes parsing significantly easier)
> </nofill>  The reason for this is to allow lists of values to be written accross
> several lines without
> 
>   having to use line extensions.
> 
> 
> Why all of this? I want to parse value lists at launch time, not each time
> the list is used, because NetInfo will provide such a list by default.
> Currently, I have to reconstruct the list for samba when retrieving values
> from NetInfo. I guess ldap has similar facilities.
> 
> 
> A list in a conf file would simply be a sequence of whitespace separated
> strings as defined above. Currently, list values are sperated by all kinds
> of different characters - this should be cleaned up.
> 
> 
> Of course I would provide a script (or, if really necessary, a program)
> which would do the necessary transformations.
> 
> <nofill>
> The database interface is a bit more trickey:
>   we basically have two options here:
>     - either we do a one-time lookup as if it were a flat file
>     - or we check the database for the value when it is used.
> </nofill>
> 
> The first has the same defeciancy as the conf file: changes aren't
> reflected (until the database is reread), but it is quite easy to
> implement and requires little changes to the code.
> 
> 
> The latter always uses uptodate values, but requires several changes to the code.
> 
> 
> The service and global structures:
> 
> Add a pointer 'dynamic' to the service structure (and also to the global
> structure) which will hold specific data for accessing the database (added
> via ifdefs). If this pointer is NULL, the parameter is retrieved from the
> structure as is done now. If this isn't NULL, then the appropriate lookup
> is done and the value is returned from the database, or, if no such value
> exists, or the database hasn't changed, from the structure.
> 
> 
> The functions for retrieving a parameter:
> 
> Add database access support. For this, it will be neccessary to add the
> parameter name to the defines (if no database is involved, this will be
> ignored), as the database lookups will use this to fetch the value (at
> least NetInfo will).
> 
> 
> 
> The samba password methods would also need changes in order to use the
> databases.  I'd like to have a scheme similar to SOLARIS nsswitch, which
> allows specifying an order of lookups. Of course, real databases such as
> NetInfo (ldap?) would retrieve even this from the database, not from a
> file.
> 
> 
> Phew, lots of suggestions, but before I go ahead and make changes, I'd
> like to hear some comments from you.
> 
> <nofill>
> -Robert
> -------------------------------------
> Institut fuer Informatik           tel  +41 (0)61 321 99 67
> Universitaet Basel                 fax. +41 (0)61 321 99 15
> Robert Frank                                        
> Mittlere Strasse 142    rfc822: frank at ifi.unibas.ch (NeXT,MIME mail ok)  
> CH-4056 Basel           (remove any no_spam_ from my return address)
> Switzerland  
> </nofill>
> 




More information about the samba-technical mailing list