On 9/13/2010 11:51 PM, Scot Hetzel wrote:
On Sat, Sep 11, 2010 at 9:33 AM, Ion-Mihai Tetcu<[email protected]> wrote:
On Sat, 11 Sep 2010 22:29:02 +0900
Norikatsu Shigemura<[email protected]> 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/
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
