From owner-freebsd-ports@FreeBSD.ORG Wed Sep 15 01:22:17 2010 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 136D31065674 for ; Wed, 15 Sep 2010 01:22:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id AC0188FC1D for ; Wed, 15 Sep 2010 01:22:16 +0000 (UTC) Received: (qmail 15912 invoked by uid 399); 15 Sep 2010 01:22:15 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Sep 2010 01:22:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C901FD0.5000304@FreeBSD.org> Date: Tue, 14 Sep 2010 18:22:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Scot Hetzel References: <20100911222902.bb57444a.nork@FreeBSD.org> <20100911173359.68d71af6@it.buh.tecnik93.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, Ion-Mihai Tetcu , Norikatsu Shigemura Subject: Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 01:22:17 -0000 On 9/13/2010 11:51 PM, Scot Hetzel wrote: > On Sat, Sep 11, 2010 at 9:33 AM, Ion-Mihai Tetcu wrote: >> On Sat, 11 Sep 2010 22:29:02 +0900 >> Norikatsu Shigemura 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/