CVS update: samba/source/include (fwd)

[Norman Weathers]

Gerald Carter wrote:

> Luke Kenneth Casson Leighton wrote:
> >
> > if you don't speak up in favour, start/stop services as remote
> > administrator certainly won't ever get added.  if you are just
> > a unix admin and do not touch NT or do not use any remote unix
> > administrative tools with the similar capability [to start/stop
> > services], please say so, and your opinion will be noted but
> > given less weight.
>
> Luke,
>
> I've stated this before, but I've really got to agree with
> Andrew.  I think this is a bad idea in production.  This is
> a gut feeling.  Just for the record, bad idea....
>
> Cheers,
> jerry
> ________________________________________________________________________
>                             Gerald ( Jerry ) Carter
> Engineering Network Services                           Auburn University
> jerry at eng.auburn.edu            http://www.eng.auburn.edu/users/cartegw
>
>        "...a hundred billion castaways looking for a home."
>                                   - Sting "Message in a Bottle" ( 1979 )

I have been lurking for awhile, and I guess I have a comment here.

It would indeed be helpful to have instances where services where either
denied, made
unavailable, or just plain turned off, but is the best answer to split
these services up into
many different components on the system?  I happen to think that the
current approach
of two daemons (smbd and nmbd) is pretty good.  But what about the
following as ideas
to enhance the daemons...

1)  Leave the smbd daemon as the master for the smb code, including the
rpc's that Luke
is now creating.  It makes more sense to some people migrating from M$ to
other platforms
because this "appears" as a "server" service.  From within this daemon, we
the users can
insert "modules" such as the ones Luke has made.  By default, all modules
are included.

2)  In smb.conf, all services are on by default.  If we have services that
we know that we
don't want to ever use or broadcast, we can set a global service parameter
to no in this
file.  That way, at initialization, only those services that we want our
users to use can
are available.  Also, during runtime, it may be helpful to create a utility
to "remove" or
"deny" services by runtime changing certain codes within the running smbd
program.
This allows users to remain connected and uninterrupted at work in the
event of a
change (upgrade) of a module,  a service change, or even some fancier
things like
a cron job to cancel login services at a certain time but leaving users
currently logged
in uniterrupted (by denying the login service within the SAM module).

Well, these are just thoughts.  I am by no means a very astute programmer,
but I think
that these ideas may be doable.  And I think that they may even be helpful
to alot
of people who may be "mystified" by the current state of samba.

Other than that, have to say "Great Product, Guys!!!"  I use it in our
small departmental
workgroup, and it has been solid.  Thanks alot.

--

-------------------------------------------------------------------
Norman Weathers
Technology Coordinator ETS
University of Arkansas, Fayetteville

phone: (501) 575-3553 or (501) 575-4344
email: nweathe at comp.uark.edu or norman at lithe.uark.edu

"It's not that I 'prefer' to do this without an NT server.... I
just 'prefer' to do it where it will work..."
-------------------------------------------------------------------