That troublemaker again (replace domain logons =, domain mast
don_mccall at hp.com
Mon Nov 12 07:44:25 GMT 2001
You know, it's really heartening to see this much participation in a topic
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'
- 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,
From: Gerald (Jerry) Carter [mailto:jerry at samba.org]
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 :)
www.samba.org SAMBA Team jerry_at_samba.org
--"I never saved anything for the swim back." Ethan Hawk in Gattaca--
More information about the samba-technical