auto-loading of smb.conf
davecb at Canada.Sun.COM
Wed Sep 9 12:27:42 GMT 1998
> >I've actually been tempted to change smbd and nmbd to only reload on
> >HUP and when a new connection is established (ie. when the daemon
> >forks). What do other people think about this?
Reloading when a service is created will still
trigger the (admittedly unusual) case the initial
Utterly-least-surprise for a non-inetd daemon is
ONLY on hup. For an inetd deamon, utterly would
increase to on daemon-creation and HUP [but see 1
Conversely, right now it's ``whenever the config file
changes''. This is surprising, but it's not a bad thing.
I see only two dangers in the whole system:
1) Different states of different daemons.
An inetd-started daemon, unless it polls for
updates, could easily end up running from a
different config file than the next one started.
This argues against dropping the poll.
2) Unexpected change during production operation.
If the daemons all reread changed files, some things
could blow up right under users. This is the
general case of the printer problem mentioned.
This argues (on first glance) against any updating.
I'm a former security person: B2 systems react
**immediately** to any change in someone's permissions.
This means the security officer (sysadmin) has to be careful.
It's not an onerous requirement. I run production
and test systems, and test on the test system, where the
immediate change is A Real Good Thing. I just have
(well, had) to be careful when changing the production
system, because I know the change will happen **now**.
In summary: I think the file should be checked **at least**
on HUP or new connection. I like the current model,
as it approaches `whenever the config file changes''.
They only reason I'd back off from that is performance.
David Collier-Brown, | Cherish your enemies. They're harder to
185 Ellerslie Ave., | come by than friends and more motivated.
Willowdale, Ontario | davecb at canada.sun.com, hobbes.ss.org
N2M 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb
More information about the samba-technical