That troublemaker again (replace domain logons =, domain mast er=)

MCCALL,DON (HP-USA,ex1) don_mccall at
Mon Nov 12 07:44:25 GMT 2001

Hi Everyone,
You know, it's really heartening to see this much participation in a topic
like this.
I wanted to comment on the whole concept of 'cleaning up' smb.conf
parameters - not just 
for new functionality, but to give us a more concise, clear configuration
base to work with.
I think this is way overdue - and 3.0 seems a GOOD place to introduce this.
YES - removing 'redundant' or 'synonym' parameters is going to cause some
problems for folks
upgrading from a previous samba.  But I can tell you from a support
standpoint, that it would SURE
reduce the complexity of supporting samba, AND configuring it in the first
place.  Not to mention
streamlining the doco's somewhat.
Some of the problems I see (and possible solutions) are as follows:

1. smb.conf files using parameters that had been removed/'replaced with
clearer parameters'  would have
   to be modified after an update.

   - As someone already mentioned, many of the installation methods (HP-UX
included) has 'post-install'
     scripts that could handle this quite nicely.
   - For those that DON'T,  I would think it would be a simple matter to
modify loadparms so that it 
     sent a msg to stdout/stderr for smbd/nmbd  when it hit an 'illegal'
parameter in smb.conf, referencing
     a 'migration script' to be run by hand to 'fix' the problem before the
user attempts to start samba
     again.  I know from unfortunate experience that many sysadmins DON't
think of the sambalog files when
     looking at a problem, but will check syslog as a matter of course.
(hence the stderr, etc output).

     I've done work in this area for other products in the past, and would
be glad to volunteer to build
     a migration script to handle this, once we nail down WHAT parameters
are going to go away or be 
     replaced with new/changed parameters.

2.  Some distributions (Including HP-UX) also contain some sort of
configuration/startup tool that queries
    the sysadm IN ENGLISH (or whatever other human language it has been
coded for) for his preferences, like
    whether he wants Samba to run in Domain/Server/User level security, etc,
and then modifies the smb.conf
    file appropriate parameters based on these answers.  Removing/changing
smb.conf parameters will 'break'
    these utilities.

    - Post-install scripts are not going to help in this matter, since these
utilities are run at the 
      sysadmins disgression, and not necessarily tied to installation.
    - IMHO, scripts that are part of a distribution are the responsibility
of the vendor, and any vendor
      should be savvy enough (If we document the changes appropriately, and
LOUD enough) to modify their
      utilities as part of the introduction of a 'new release'.  However,
assuming the existence of a
      'migration script', A vendor who needs a QUICK turnaround to get the
new release out the door, could
      simply leave his utility pretty much unchanged, and just add a call to
this script to 'fix up' the
      smb.conf after his utility had done it's 'oldstyle' changes.  This
would be a SHORT term quickfix,
      until the vendor modified his utilities to match the new release
actual smb.conf changed parameters. 

BOTTOM LINE:  I think that in the case where we are still providing
backwards compatibility as far as 
              FUNCTIONALITY is concerned, and just changing the user
interface CONFIGURATION of that 
              functionality (smb.conf parameters, etc), that the
post-install and migration script
              path is reasonable and sufficient.

              In the case where we are actually REMOVING functionality, or
changing it significantly,
              I think that it is our responsibility to give very clear and
detailed 'upgrade' documentation
              to the community to highlight this.  In a major new release,
for instance, I would advocate
              a PRE install script that would parse thru  the existing Samba
configuration files (like
              smb.conf, usermap, etc) and report to the potential upgrader
any functionality loss or change
              he could expect based on the parameters & values he is
currently using.  I have seen several
              instances of this approach taken, and while somewhat
complicated to deliver, it saved the 
              support community a lot of time, and the sysadmins a lot of
headache, to know what to look
              out for BEFORE the switchover to a new version...

Just a thought,

-----Original Message-----
From: Gerald (Jerry) Carter [mailto:jerry at]
Sent: Monday, November 12, 2001 1:24
To: Andrew Bartlett
Cc: Tim Potter; Multiple recipients of list SAMBA-TECHNICAL
Subject: Re: That troublemaker again (replace domain logons =, domain

On Mon, 12 Nov 2001, Andrew Bartlett wrote:

> > > It should decrese the overhead, becouse the option is clear.  No more
> > > 'domain logons = pdc, but not if domain master = no, then its a bdc'
> > > kind of stuff.
> > >
> > > Table:
> > >                    PDC        BDC       Standalone (also member)
> > > domain master =     Y          N                 N
> > > domain logons =     Y          Y                 N
> >
> > There's at least one other entry that needs to go in this table:
> >
> >   encrypt passwords = Y          Y                Y/N
> And enforcing this would reduce the number of bug reports, because the
> error messages you get are not exactly helpful...

But the chart is wrong :)

cheers, jerry
 ---------------------------------------------------------------------              SAMBA  Team                                 Hewlett-Packard
 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--

More information about the samba-technical mailing list