[ports/net/isc-dhcp*] Don't stop DHCP related daemons

[Doug Barton]

On 9/13/2010 11:51 PM, Scot Hetzel wrote:
> On Sat, Sep 11, 2010 at 9:33 AM, Ion-Mihai Tetcu<itetcu at freebsd.org>  wrote:
>> On Sat, 11 Sep 2010 22:29:02 +0900
>> Norikatsu Shigemura<nork at FreeBSD.org>  wrote:
>>
>>> Hi wxs and jpaetzel.
>>>
>>>        I noticed that dhcpd server stoped after portupgrade,
>>> sometimes. It's a painful accident on my network.  Because I didn't
>>> notice some troubles:-(.
>>>
>>>        Why do you stop the daemons? Is it really absolutely necessary
>>>        to stop a service before it's files go away?

IMO the only time the ports infrastructure itself should do this is if 
it isn't possible to pkg_delete the port cleanly if it's running. For 
example, if there is a file being held open that cannot be deleted 
unless the service is stopped. But that's just my opinion, and how I 
maintain my ports. Reasonable minds could differ on this topic.

> The problem is that your using tools such as portupgrade, or
> portmaster, etc..  These tools don't check if the service was running
> when it started the upgrade process.   Instead they just pkg_delete
> the old port and then build or pkg_install the newest version of the
> port.

My understanding is that portupgrade has optional features to deal with 
this. To date I have not developed anything similar for portmaster. 
Partly because of a design choice (see below for more information about 
that), partly because of minimal interest expressed by portmaster users, 
and mostly for lack of time.

> Consider thess senarios:
>
> 1. A system admin installs package foo-1.3, adds the appropriate
> foo_enable to /etc/rc.conf, and then executes ${PREFIX}/etc/rc.d/foo
> start.  He tests the foo package and decides that it doesn't meet his
> requirements and wants to use bar-1.7 instead.  So he goes to
> uninstall foo-1.3 without stopping the service (pkg_delete foo-1.3)
> and installs bar-1.7.  Now, if the pkg-plist didn't have the @unexec
> %D/etc/rc.d/foo forcestop, the foo daemon would still be running until
> the system was rebooted.  So when he goes to starts the bar service,
> he gets a suprise because he is connecting to the foo daemon, and the
> bar daemon failed to start.
>
> 2. A system admin installs package foo-1.3, after running the service
> for a while a security hole is found in foo-1.3.  So he uses his
> favorite ports management tool (pkg_delete/pkg_install, portupgrade,
> or portmaster, ...) to upgrade to foo-1.4.  If the pkg-plist didn't
> have the @unexec %D/etc/rc.d/foo forcestop, the security vulnerable
> foo-1.3 daemon would still be running, even though the latest version
> has been installed.  This would cause the system to still be
> vulnerable to the security risk.

I can think of at least one more scenario off the top of my head. You 
want to run the new version of the service the next time the box is 
restarted for whatever reason, but the update is not so critical that it 
justifies restarting the system immediately.

> The main problem with upgrading ports that install daemon startup
> scripts is that the ports management tools are not checking if the
> service is running before they start the upgrade process.  These tools
> should print a warning at the end of the upgrade process that states
> which daemons were stopped due to the upgrade process.
>
> The ports management tools should not automatically restart the
> daemons that it had stopped.  The reason is that there could be a
> configuration change in the new ports sample config files that should
> be migrated to the old modified config files before restarting the
> service.

To be honest (and I'm sorry if this is off-putting), my knee-jerk 
reaction is that neither the ports infrastructure itself, nor the ports 
management tools should be doing the thinking _for_ the admin; and that 
they should be smart enough to know what services need to be stopped, 
and restarted all on their own.

HOWEVER, as I'm looking more and more closely at other systems to see 
how they do things I think we're really missing out in terms of not 
having a more comprehensive "system management" tool as opposed to the 
existing tools that do a bang-up job at ports management. Unfortunately 
the deeper I dig into this topic the more I see that "we" simply don't 
have the resources we need to do the bigger job properly. And by 
resources I mean the whole thing, infrastructure, personnel, funding, 
etc. We can continue to talk about bolting stuff on to the existing 
infrastructure, and I think there is some low-hanging fruit there; but 
ultimately I don't think we're going to get where we need to be in terms 
of either completeness or ease of use by building on the foundation we 
already have.


Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/