Nicolas Williams' source environment variables

[Nicolas Williams]

On Sat Jan 29 2000, David Collier-Brown wrote:
>   I've been wondering about what programming primitives one needs 
> in and smb.conf ile fro a long time, and Mr. Williams' patch 
> re-raises this question. 
>   In a very early version of the O'Reilly book, I described the 
> smb.conf file as having all the basic primitives of a programming 
> language: 
>         variable assignment 
>         conditional code ("include" and "copy" using a %-variable) 
>         blocks (files, sections) 
> but lacking a way of setting a %-variable. 
> 
>   This was too academic, and promptly disappeard from the book, 
> but it is a decent question of the development team: how much 
> programmability should there be in the main smb.conf file? 

Wow. I've thought about this as well.

>   I've seen two proposal to extend the language: 
>   One was from a site with a very large .conf file that contained 
> the definition of all the shares for a cloud of servers. They wanted 
> a way to ignore inappropriaste shares, and save memory thereby. 

Actually, that would be useful: a share ignore parameter. It's value
might be a % token followed by a value such that if it does not match
the token's value the share would be ignored.

>   The other is Mr. Williams' proposal, to do conditionals on 
> netbios names, and to provide a general ${env-var} construct, which 
> they use for Samba-failover on a Veritas HA server. 
> 
>   On the other hand, smb.conf is a much easier language to read and 
> maintain than, say, tcl. We may well want to keep it that way! 
> 
>   So: what about a way to set a variable (environment or %)? Does 
> that buy enough to make it worth the extra complexity? 

The problem is that smb.conf is way too static to really be seen as a
language. Once smb.conf has been read (assuming it doesn't change), the
only things that change are some % tokens which one can use with
includes to play some magic tricks. Whatever value there might be to
having a more generalized variable system would require more dynamism
to be truly useful.

That said, there's a patch for implementing 'open command' and 'close
command' parameters which allow one to define commands to run when files
are opened or closed. That is a very neat feature I plan to use and
which essentially fixes the problems with that awful 'magic script'
parameter. BUT, I'm still concerned about using % tokens to expand into
the given filename in the open/close commands; similar concerns apply to
the standard print parameters.

What I would like, and may patch the open/close command patch to do, is
to have smbd put the given filename in an environment variable or make
%f expand to the heax/base64 encoded file path name to avoid any
trickery a client might play with speical characters in file names.

Perhaps this can be generalized to a 'setenv encoded' parameter that is
evaluated everytime a % token's value changes. This would require
significant changes to Samba though, wouldn't it.

Also, Luke's idea of storing % tokens in a tdb indexed by <PID vuid>
tuples is really neat.Not only will it allow the DCE/RPC daemons to
implement standard_sub_basic() correctly, but it could even be used by
user commands run via the preexec/postexec/open/close/etc... parameters
(this would require a user-level program for retrieving data from a TDB
as well as a separate library for C programs to use to access the TDB in
question).

Hmmmm...

In fact, I think that would be a tremendous improvement.

> --dave 
> 
> -- 
> David Collier-Brown,  | Always do right. This will gratify
> 185 Ellerslie Ave.,   | some people and astonish the rest.
> Willowdale, Ontario,  |                      -- Mark Twain
> CANADA. 416-223-8968  | davecb at canada.sun.com
> 


Nico

PS: Back in the days before online DVD rentals I used to rent videos at
    a certain video rental chain. Not too long ago they decided to start
    referring to their customers by their first names ("Here's your card
    Nicolas", "That'll be $X.Y Nicolas"); I guess they thought that this
    would make them "friendlier" to their customers. I absolutely hated
    this. I used to be "Mr. Williams" to them and it should have stayed
    that way.

    But this forum is not a store where some people serve others. So you
    need not call me "Mr. Williams".

    :)

-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.