Re: ports/162049: The Ports tree lacks a framework to restart services
On Mon, Oct 31, 2011 at 01:30:55PM +0100, Miroslav Lachman wrote:
> For me, it would be nice to be able to define "functions" with whatever
> content executed on particular action.
>
> short example:
>
> function_called_after_upgrade_of_authdaemon() {
> send notice to operator or write something to logfile
> chmod 0755 /var/run/authdaemond
> restart authdaemon
> execute "self-test" script to check SMTP auth is working
> }
>
> This in general is more useful than just call restart on installed rc.d
> script, but ofcourse, it is more complex task to implement and I am not
> sure, if it should be in ports or in some utility like portmaster.
Would something like the above in the port's rc.d/daemonscript
simplify things for the packages part of the problem space?
If the rc.d scripts had support for an "upgrade" option that defaulted
to doing nothing if the porter didn't put an upgrade function in
his/her ports rc.d/daemonscript, the package scripts and ports
infrastructure could unconditionally call "rc.d/daemonscript upgrade".
Then control of whether or not to do automatic upgrades could be
in /etc/rc.conf right below the "daemon_enable=YES".
daemon_autoupgrade=NO # Let the port's rc.d script automagically
# handle needed config changes and stop /
# restart the daemon when upgraded from pkgs or
# ports?
Maybe with a big default cover knob?
autoupgrade_default=NO # default to allowing ports / pkg tools to
# auto restart daemons and / or upgrade
# daemon configurations/databases/...
Would that be a way to make use of our existing automation / config
store infrastructure?
This would leave the complex logic for each port in the hands of
the porters who are most likely to know what corner cases need to
be treated with care. Individual porters could automate as much
as they want. Look at what depends on the current package, say PHP
since it was mentioned before, and see which if any web servers
might need to be restarted, then call the web server's rc.d/daemonscript
(upgrade|restart) as may be appropriate.
Of course, PHP probably won't have a php5_enable=YES in /etc/rc.conf.
But you could still have:
php5_autoupgrade=(YES|NO|WARN|EMAILUPGRADESCRIPTTOADMIN|...)
That could lead to a proliferation of rc.d/scripts which don't
actually control daemons. That might not be a good thing. Maybe
using the rc.d scripts is a bad idea?
--
Scott LambertKC5MLE Unix SysAdmin
lamb...@lambertfam.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On 10/31/2011 03:41, Dominic Fandrey wrote: > What has to be done after an update is often very specific, though. That's why I proposed that there should be a knob for the port maintainer to include the standard version of the script, or not. If there are more heavily customized things that need to be done for the particular service than a custom pkg-install/pkg-deinstall script is going to be needed. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On 31 October 2011 12:30, Miroslav Lachman <000.f...@quip.cz> wrote:
> Dominic Fandrey wrote:
>>
>> On 31/10/2011 09:37, Doug Barton wrote:
>>>
>>> On 10/31/2011 00:38, Dominic Fandrey wrote:
On 31/10/2011 07:28, Doug Barton wrote:
>
> On 10/27/2011 09:27, Scott Lambert wrote:
>>
>> On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
>>>
>>> What really bothers me when I use the FreeBSD Ports tree on one of my
>>> systems, is that the behaviour of dealing with services is quite
>>> inconsistent.
>>
>> If all of that is contingent upon a boolean knob the admin can set,
>> something like NO_RESTART_SERVICES, I suspect everyone could get
>> what they want and the bikeshed would be limitted to what the default
>> for that boolean should be.
>>
>> The people who don't want the services restarted automagically can
>> set it and, once things use the new ports framewoork properly, not
>> have to worry about suprises. The people who want everything to
>> restarted as soon as possible can set the knob the other way.
>>
>
>
> I think Scott's on the right track. The way that I envision it working
> would be a 3-knob system. One knob to always restart the services, one
> to never do it; and then asking on a per-port basis, which should be
> the
> default. I can imagine portmaster detecting this option in the
> pre-build
> phase similarly to how it detects and warns about IS_INTERACTIVE now,
> and giving the user a menu of options for how to handle it. I'm happy
> to
> add more details if people are interested.
I think this should be handled in the pkg-install script. Pkg based
upgrade tools _do_ exist.
>>>
>>> Yeah, that's what I said below. :)
>>
>> Sorry about that, I read the entire thread in one go, might have
>> overlooked
>> something. Ironic, because the purpose was to avoid posting redundant
>> feedback.
>>
> Where this actually becomes interesting is not in the ports
> build/install process, which is pretty easy to deal with, but with
> package installs/deinstalls. I definitely think it's doable, what we
> probably want to do is put a knob for this in the port's Makefile, and
> handle the stop/start for both the port and the package with a little
> script that can be included in the package, and run with @exec and
> @unexec.
Note the Porters' Handboock chapter 6.23.1. The knob to stop services is
already there.
>>>
>>> That feature as it exists currently isn't even close to adequate, and is
>>> causing more problems than it solves. Hence the discussion.
>
> Yes, and even if I would like to have possibility to restart some services
> after upgrade, I really hate this knob to just stop the service and leave it
> stopped. Can somebody add global knob to override this from make.conf?
>
>> Well, I am one of the people who see no need for this feature and my vote
>> is for default off, if it's implemented.
>
> I agree with default off.
>
>> I just wanted to hint that such a function is already in place and I don't
>> think it would be difficult to add the possibility to start a service.
>>
>> What has to be done after an update is often very specific, though.
>> I don't envy the person having to come up with an adequate implementation.
>> E.g. it's not always the service installed by the pkg that needs to be
>> restarted:
>>
>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/automounter/pkg-message?rev=1.2;content-type=text%2Fplain
>
> And that's why I propossed more general user scriptable hooks for
> before/after deinstall - install - upgrade actions. (It is on Doug's
> portmaster proposal list http://dougbarton.us/portmaster-proposal.html)
> Sometimes sysadmin needs more than just restart of the upgraded service.
> Sometimes we need to restart other service as well, or run some test script,
> send an alert, or for example change some file/directory permissions - real
> example is courier-authdaemon when used with Postfix for SMTP auth, we must
> change permissions of socket dir on each upgrade.
>
> For me, it would be nice to be able to define "functions" with whatever
> content executed on particular action.
>
> short example:
>
> function_called_after_upgrade_of_authdaemon() {
> send notice to operator or write something to logfile
> chmod 0755 /var/run/authdaemond
> restart authdaemon
> execute "self-test" script to check SMTP auth is working
> }
>
> This in general is more useful than just call restart on installed rc.d
> script, but ofcourse, it is more complex task to implement and I am not
> sure, if it should be in ports or in some utility like portmaster.
>
> I agree that whatever will be implemented as a result of this discussion, it
> should be optional feature off by default and ports system should not
> silently stop / restart / start services.
Yeah... though I've just remember the BI
Re: ports/162049: The Ports tree lacks a framework to restart services
Dominic Fandrey wrote:
On 31/10/2011 09:37, Doug Barton wrote:
On 10/31/2011 00:38, Dominic Fandrey wrote:
On 31/10/2011 07:28, Doug Barton wrote:
On 10/27/2011 09:27, Scott Lambert wrote:
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent.
If all of that is contingent upon a boolean knob the admin can set,
something like NO_RESTART_SERVICES, I suspect everyone could get
what they want and the bikeshed would be limitted to what the default
for that boolean should be.
The people who don't want the services restarted automagically can
set it and, once things use the new ports framewoork properly, not
have to worry about suprises. The people who want everything to
restarted as soon as possible can set the knob the other way.
I think Scott's on the right track. The way that I envision it working
would be a 3-knob system. One knob to always restart the services, one
to never do it; and then asking on a per-port basis, which should be the
default. I can imagine portmaster detecting this option in the pre-build
phase similarly to how it detects and warns about IS_INTERACTIVE now,
and giving the user a menu of options for how to handle it. I'm happy to
add more details if people are interested.
I think this should be handled in the pkg-install script. Pkg based
upgrade tools _do_ exist.
Yeah, that's what I said below. :)
Sorry about that, I read the entire thread in one go, might have overlooked
something. Ironic, because the purpose was to avoid posting redundant
feedback.
Where this actually becomes interesting is not in the ports
build/install process, which is pretty easy to deal with, but with
package installs/deinstalls. I definitely think it's doable, what we
probably want to do is put a knob for this in the port's Makefile, and
handle the stop/start for both the port and the package with a little
script that can be included in the package, and run with @exec and @unexec.
Note the Porters' Handboock chapter 6.23.1. The knob to stop services is
already there.
That feature as it exists currently isn't even close to adequate, and is
causing more problems than it solves. Hence the discussion.
Yes, and even if I would like to have possibility to restart some
services after upgrade, I really hate this knob to just stop the service
and leave it stopped. Can somebody add global knob to override this from
make.conf?
Well, I am one of the people who see no need for this feature and my vote
is for default off, if it's implemented.
I agree with default off.
I just wanted to hint that such a function is already in place and I don't
think it would be difficult to add the possibility to start a service.
What has to be done after an update is often very specific, though.
I don't envy the person having to come up with an adequate implementation.
E.g. it's not always the service installed by the pkg that needs to be
restarted:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/automounter/pkg-message?rev=1.2;content-type=text%2Fplain
And that's why I propossed more general user scriptable hooks for
before/after deinstall - install - upgrade actions. (It is on Doug's
portmaster proposal list http://dougbarton.us/portmaster-proposal.html)
Sometimes sysadmin needs more than just restart of the upgraded service.
Sometimes we need to restart other service as well, or run some test
script, send an alert, or for example change some file/directory
permissions - real example is courier-authdaemon when used with Postfix
for SMTP auth, we must change permissions of socket dir on each upgrade.
For me, it would be nice to be able to define "functions" with whatever
content executed on particular action.
short example:
function_called_after_upgrade_of_authdaemon() {
send notice to operator or write something to logfile
chmod 0755 /var/run/authdaemond
restart authdaemon
execute "self-test" script to check SMTP auth is working
}
This in general is more useful than just call restart on installed rc.d
script, but ofcourse, it is more complex task to implement and I am not
sure, if it should be in ports or in some utility like portmaster.
I agree that whatever will be implemented as a result of this
discussion, it should be optional feature off by default and ports
system should not silently stop / restart / start services.
Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On 31/10/2011 10:41, Dominic Fandrey wrote: > I just wanted to hint that such a function is already in place and I don't > think it would be difficult to add the possibility to start a service. Restarting a single service is no big deal. Trouble is there are a lot of cases where that just isn't the right thing to do. Suppose you have a very common situation: a web application written in PHP and using a RDBMS. * Upgrades to the RDBMS often require more than just a restart of the DB. Eg. changes to internal schemas require running some external script. (pg_upgrade, mysql_after_upgrade, etc.) * Upgrades to PHP -- given that PHP is modularized, then the sane way of restarting is to take the web app down at the point lang/php5 gets reinstalled, but not bring it up again until all the various php5 modules have been reinstalled. At minimum. If you use, say, eAccelerator, then you almost certainly need to rebuild that before restarting the php web-app. * Of course, how to restart a PHP based web-app is highly context dependent. Generally it means bouncing some other daemon: frequently a web server like apache, or is it lighttpd? Or some sort of FCGI daemon? * Certainly no one would ever write a DB based web-app that wouldn't cope gracefully with the temporary disappearance of its back-end DB. Why, such a thing would be clearly beyond the bounds of possibility, and it would be vanishingly improbable that anyone should ever need to worry about needing to restart a web-app as a consequence of restarting a DB. Basically, I think I can summarize by saying that as soon as you go beyond the simplest and most basic system configurations, there are so many different possibilities that it requires some sort of intelligent agent to manage the upgrade and restart process. Failing the widespread availability of practicable AI, this is where your sysadmins are going to earn their princely salaries. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: ports/162049: The Ports tree lacks a framework to restart services
On 31/10/2011 09:37, Doug Barton wrote: > On 10/31/2011 00:38, Dominic Fandrey wrote: >> On 31/10/2011 07:28, Doug Barton wrote: >>> On 10/27/2011 09:27, Scott Lambert wrote: On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote: > What really bothers me when I use the FreeBSD Ports tree on one of my > systems, is that the behaviour of dealing with services is quite > inconsistent. If all of that is contingent upon a boolean knob the admin can set, something like NO_RESTART_SERVICES, I suspect everyone could get what they want and the bikeshed would be limitted to what the default for that boolean should be. The people who don't want the services restarted automagically can set it and, once things use the new ports framewoork properly, not have to worry about suprises. The people who want everything to restarted as soon as possible can set the knob the other way. >>> >>> >>> I think Scott's on the right track. The way that I envision it working >>> would be a 3-knob system. One knob to always restart the services, one >>> to never do it; and then asking on a per-port basis, which should be the >>> default. I can imagine portmaster detecting this option in the pre-build >>> phase similarly to how it detects and warns about IS_INTERACTIVE now, >>> and giving the user a menu of options for how to handle it. I'm happy to >>> add more details if people are interested. >> >> I think this should be handled in the pkg-install script. Pkg based >> upgrade tools _do_ exist. > > Yeah, that's what I said below. :) Sorry about that, I read the entire thread in one go, might have overlooked something. Ironic, because the purpose was to avoid posting redundant feedback. >>> Where this actually becomes interesting is not in the ports >>> build/install process, which is pretty easy to deal with, but with >>> package installs/deinstalls. I definitely think it's doable, what we >>> probably want to do is put a knob for this in the port's Makefile, and >>> handle the stop/start for both the port and the package with a little >>> script that can be included in the package, and run with @exec and @unexec. >> >> Note the Porters' Handboock chapter 6.23.1. The knob to stop services is >> already there. > > That feature as it exists currently isn't even close to adequate, and is > causing more problems than it solves. Hence the discussion. Well, I am one of the people who see no need for this feature and my vote is for default off, if it's implemented. I just wanted to hint that such a function is already in place and I don't think it would be difficult to add the possibility to start a service. What has to be done after an update is often very specific, though. I don't envy the person having to come up with an adequate implementation. E.g. it's not always the service installed by the pkg that needs to be restarted: http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/automounter/pkg-message?rev=1.2;content-type=text%2Fplain Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On 31 October 2011 08:37, Doug Barton wrote: > On 10/31/2011 00:38, Dominic Fandrey wrote: >> On 31/10/2011 07:28, Doug Barton wrote: >>> On 10/27/2011 09:27, Scott Lambert wrote: On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote: > What really bothers me when I use the FreeBSD Ports tree on one of my > systems, is that the behaviour of dealing with services is quite > inconsistent. If all of that is contingent upon a boolean knob the admin can set, something like NO_RESTART_SERVICES, I suspect everyone could get what they want and the bikeshed would be limitted to what the default for that boolean should be. The people who don't want the services restarted automagically can set it and, once things use the new ports framewoork properly, not have to worry about suprises. The people who want everything to restarted as soon as possible can set the knob the other way. >>> >>> >>> I think Scott's on the right track. The way that I envision it working >>> would be a 3-knob system. One knob to always restart the services, one >>> to never do it; and then asking on a per-port basis, which should be the >>> default. I can imagine portmaster detecting this option in the pre-build >>> phase similarly to how it detects and warns about IS_INTERACTIVE now, >>> and giving the user a menu of options for how to handle it. I'm happy to >>> add more details if people are interested. >> >> I think this should be handled in the pkg-install script. Pkg based >> upgrade tools _do_ exist. > > Yeah, that's what I said below. :) > >>> Where this actually becomes interesting is not in the ports >>> build/install process, which is pretty easy to deal with, but with >>> package installs/deinstalls. I definitely think it's doable, what we >>> probably want to do is put a knob for this in the port's Makefile, and >>> handle the stop/start for both the port and the package with a little >>> script that can be included in the package, and run with @exec and @unexec. >> >> Note the Porters' Handboock chapter 6.23.1. The knob to stop services is >> already there. > > That feature as it exists currently isn't even close to adequate, and is > causing more problems than it solves. Hence the discussion. I'd be happy to code this; I've offered once before. However, I had a hard time convincing people that it wasn't something that portmaster/portupgrade should be doing instead... Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On 10/31/2011 00:38, Dominic Fandrey wrote: > On 31/10/2011 07:28, Doug Barton wrote: >> On 10/27/2011 09:27, Scott Lambert wrote: >>> On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote: What really bothers me when I use the FreeBSD Ports tree on one of my systems, is that the behaviour of dealing with services is quite inconsistent. >>> >>> If all of that is contingent upon a boolean knob the admin can set, >>> something like NO_RESTART_SERVICES, I suspect everyone could get >>> what they want and the bikeshed would be limitted to what the default >>> for that boolean should be. >>> >>> The people who don't want the services restarted automagically can >>> set it and, once things use the new ports framewoork properly, not >>> have to worry about suprises. The people who want everything to >>> restarted as soon as possible can set the knob the other way. >>> >> >> >> I think Scott's on the right track. The way that I envision it working >> would be a 3-knob system. One knob to always restart the services, one >> to never do it; and then asking on a per-port basis, which should be the >> default. I can imagine portmaster detecting this option in the pre-build >> phase similarly to how it detects and warns about IS_INTERACTIVE now, >> and giving the user a menu of options for how to handle it. I'm happy to >> add more details if people are interested. > > I think this should be handled in the pkg-install script. Pkg based > upgrade tools _do_ exist. Yeah, that's what I said below. :) >> Where this actually becomes interesting is not in the ports >> build/install process, which is pretty easy to deal with, but with >> package installs/deinstalls. I definitely think it's doable, what we >> probably want to do is put a knob for this in the port's Makefile, and >> handle the stop/start for both the port and the package with a little >> script that can be included in the package, and run with @exec and @unexec. > > Note the Porters' Handboock chapter 6.23.1. The knob to stop services is > already there. That feature as it exists currently isn't even close to adequate, and is causing more problems than it solves. Hence the discussion. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On 31/10/2011 07:28, Doug Barton wrote: > On 10/27/2011 09:27, Scott Lambert wrote: >> On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote: >>> What really bothers me when I use the FreeBSD Ports tree on one of my >>> systems, is that the behaviour of dealing with services is quite >>> inconsistent. >> >> If all of that is contingent upon a boolean knob the admin can set, >> something like NO_RESTART_SERVICES, I suspect everyone could get >> what they want and the bikeshed would be limitted to what the default >> for that boolean should be. >> >> The people who don't want the services restarted automagically can >> set it and, once things use the new ports framewoork properly, not >> have to worry about suprises. The people who want everything to >> restarted as soon as possible can set the knob the other way. >> > > > I think Scott's on the right track. The way that I envision it working > would be a 3-knob system. One knob to always restart the services, one > to never do it; and then asking on a per-port basis, which should be the > default. I can imagine portmaster detecting this option in the pre-build > phase similarly to how it detects and warns about IS_INTERACTIVE now, > and giving the user a menu of options for how to handle it. I'm happy to > add more details if people are interested. I think this should be handled in the pkg-install script. Pkg based upgrade tools _do_ exist. > Where this actually becomes interesting is not in the ports > build/install process, which is pretty easy to deal with, but with > package installs/deinstalls. I definitely think it's doable, what we > probably want to do is put a knob for this in the port's Makefile, and > handle the stop/start for both the port and the package with a little > script that can be included in the package, and run with @exec and @unexec. Note the Porters' Handboock chapter 6.23.1. The knob to stop services is already there. > > > hth, > > Doug > -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On 10/27/2011 09:27, Scott Lambert wrote:
> On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
>> Hi folks,
>>
>> As crees@ suggested, I'm sending an email to ports@ about this.
>>
>> What really bothers me when I use the FreeBSD Ports tree on one of my
>> systems, is that the behaviour of dealing with services is quite
>> inconsistent.
>>
>> My question is whether anyone has ever attempted to improve the
>> integration with rc-scripts? In the PR I propose something along these
>> lines:
>>
>> We know exactly which ports install rc scripts (USE_RC_SUBR).
>> Why not run `/usr/local/etc/rc.d/${FOO} status' and
>> `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
>> on the return value of the first, we can run
>> `/usr/local/etc/rc.d/${FOO} start' after installation.
>
> If all of that is contingent upon a boolean knob the admin can set,
> something like NO_RESTART_SERVICES, I suspect everyone could get
> what they want and the bikeshed would be limitted to what the default
> for that boolean should be.
>
> The people who don't want the services restarted automagically can
> set it and, once things use the new ports framewoork properly, not
> have to worry about suprises. The people who want everything to
> restarted as soon as possible can set the knob the other way.
>
> It could help keep our less sophisticated users from continuing to
> run vulerable versions of software after they think they have done
> what is needed to get the patched software. The sophisticated users
> would still be free to choose which foot to shoot.
>
> A side effect might, eventually, be to encourage ports maintainers
> to analyse their ported software for incompatible config changes
> so that they can programatically halt the install and output a
> warning message before attempting to stop the old daemon then
> upgrading while a likely un-usable config is in place.
>
> I see it as win, win, if there is a knob.
>
> I do not like either option without a knob, depending on the box
> we are talking about.
Speaking only for myself I hate the idea of stopping/starting services
automatically. However this feature is often requested, and is something
that is provided by many other package systems. If we have people who
are willing to do the work I think it's worth discussing how to do it
properly.
I think Scott's on the right track. The way that I envision it working
would be a 3-knob system. One knob to always restart the services, one
to never do it; and then asking on a per-port basis, which should be the
default. I can imagine portmaster detecting this option in the pre-build
phase similarly to how it detects and warns about IS_INTERACTIVE now,
and giving the user a menu of options for how to handle it. I'm happy to
add more details if people are interested.
Where this actually becomes interesting is not in the ports
build/install process, which is pretty easy to deal with, but with
package installs/deinstalls. I definitely think it's doable, what we
probably want to do is put a knob for this in the port's Makefile, and
handle the stop/start for both the port and the package with a little
script that can be included in the package, and run with @exec and @unexec.
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
Quoth Scott Lambert on Thursday, 27 October 2011:
> On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
> > Hi folks,
> >
> > As crees@ suggested, I'm sending an email to ports@ about this.
> >
> > What really bothers me when I use the FreeBSD Ports tree on one of my
> > systems, is that the behaviour of dealing with services is quite
> > inconsistent.
> >
> > My question is whether anyone has ever attempted to improve the
> > integration with rc-scripts? In the PR I propose something along these
> > lines:
> >
> > We know exactly which ports install rc scripts (USE_RC_SUBR).
> > Why not run `/usr/local/etc/rc.d/${FOO} status' and
> > `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
> > on the return value of the first, we can run
> > `/usr/local/etc/rc.d/${FOO} start' after installation.
>
> If all of that is contingent upon a boolean knob the admin can set,
> something like NO_RESTART_SERVICES, I suspect everyone could get
> what they want and the bikeshed would be limitted to what the default
> for that boolean should be.
>
> The people who don't want the services restarted automagically can
> set it and, once things use the new ports framewoork properly, not
> have to worry about suprises. The people who want everything to
> restarted as soon as possible can set the knob the other way.
>
> It could help keep our less sophisticated users from continuing to
> run vulerable versions of software after they think they have done
> what is needed to get the patched software. The sophisticated users
> would still be free to choose which foot to shoot.
>
> A side effect might, eventually, be to encourage ports maintainers
> to analyse their ported software for incompatible config changes
> so that they can programatically halt the install and output a
> warning message before attempting to stop the old daemon then
> upgrading while a likely un-usable config is in place.
>
> I see it as win, win, if there is a knob.
>
> I do not like either option without a knob, depending on the box
> we are talking about.
>
+1 for this idea.
+10 for "The sophisticated users would still be free to choose which foot
to shoot."
--
.O. | Sterling (Chip) Camden | http://camdensoftware.com
..O | sterl...@camdensoftware.com | http://chipsquips.com
OOO | 2048R/D6DBAF91 | http://chipstips.com
pgp8LT4IzHYN8.pgp
Description: PGP signature
Re: ports/162049: The Ports tree lacks a framework to restart services
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
> Hi folks,
>
> As crees@ suggested, I'm sending an email to ports@ about this.
>
> What really bothers me when I use the FreeBSD Ports tree on one of my
> systems, is that the behaviour of dealing with services is quite
> inconsistent.
>
> My question is whether anyone has ever attempted to improve the
> integration with rc-scripts? In the PR I propose something along these
> lines:
>
> We know exactly which ports install rc scripts (USE_RC_SUBR).
> Why not run `/usr/local/etc/rc.d/${FOO} status' and
> `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
> on the return value of the first, we can run
> `/usr/local/etc/rc.d/${FOO} start' after installation.
If all of that is contingent upon a boolean knob the admin can set,
something like NO_RESTART_SERVICES, I suspect everyone could get
what they want and the bikeshed would be limitted to what the default
for that boolean should be.
The people who don't want the services restarted automagically can
set it and, once things use the new ports framewoork properly, not
have to worry about suprises. The people who want everything to
restarted as soon as possible can set the knob the other way.
It could help keep our less sophisticated users from continuing to
run vulerable versions of software after they think they have done
what is needed to get the patched software. The sophisticated users
would still be free to choose which foot to shoot.
A side effect might, eventually, be to encourage ports maintainers
to analyse their ported software for incompatible config changes
so that they can programatically halt the install and output a
warning message before attempting to stop the old daemon then
upgrading while a likely un-usable config is in place.
I see it as win, win, if there is a knob.
I do not like either option without a knob, depending on the box
we are talking about.
--
Scott LambertKC5MLE Unix SysAdmin
lamb...@lambertfam.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote: > Hi folks, > > As crees@ suggested, I'm sending an email to ports@ about this. > > What really bothers me when I use the FreeBSD Ports tree on one of my > systems, is that the behaviour of dealing with services is quite > inconsistent. As mentioned in the PR: > > - If I upgrade Apache, MySQL or PostgreSQL, it does not restart the > service, meaning it won't use the freshly installed daemon. This has > potential security issues. > > - If I upgrade Dovecot, it shuts it down during the upgrade, but won't > restart it. This means that I have to watch portmaster to complete and > must not forget to restart Dovecot afterwards. > imho the consistency should be done by removing the autostopping stuff and auto-upgrading stuff. we have no way to be sure it will be safe at all as we don't know from which version of the previous software it has been upgraded, I can't imagine how much data corruption it would lead to. restarting the services is the goal of the system administrator it shouldn't been automated at all. I would hate that freebsd-update automatically reboot my box because it upgraded the kernel, the same way I don't want packages to restart my services, it can leads to more problem that it can solve. Administrators should know what they do, the only thing that maybe can be done is a recommandation to tell the upgrader that he should restart some services. My 2cts, Bapt pgpjIWvyhOs7B.pgp Description: PGP signature
Re: ports/162049: The Ports tree lacks a framework to restart services
Wesley Shields wrote:
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
Hi folks,
As crees@ suggested, I'm sending an email to ports@ about this.
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent. As mentioned in the PR:
I agree inconsistency is a problem that could be addressed, but I don't
particularly agree with some of your statements.
- If I upgrade Apache, MySQL or PostgreSQL, it does not restart the
service, meaning it won't use the freshly installed daemon. This has
potential security issues.
I'd prefer that no services are started or stopped automatically, unless
absolutely necessary for the upgrade.
- If I upgrade Dovecot, it shuts it down during the upgrade, but won't
restart it. This means that I have to watch portmaster to complete and
must not forget to restart Dovecot afterwards.
Also Smartd from SmartMonTools and MySQL are stopped during upgrade process.
- There are some ports touching user modified files on install /
uninstall. For example some Apache modules are touching httpd.conf which
is not good in some cases. If I upgrade mod_bw or mod_proctitle, it
removes (comment out) the LoadModule line on uninstall phase and not
enable it again on install phase of new version. So I must manually edit
httpd.conf after each upgrade before Apache restart.
Unless it is absolutely necessary to stop and restart dovecot during an
upgrade I would like to see this removed.
I think the main problem is that there is no difference between
Uninstall and Upgrade (from ports perspective).
It can be OK to shutdown daemon on uninstall. But somebody wants to
restart services on upgrade and somebody wants to keep them running.
Both have pros and cons.
As mentioned above with Apache modules case, if there will be way to
distinguish between uninstall and upgrade, then there will be ways to
handle this problems more carefully.
But intil then I vote for removing all custom "stop" / "restart" / "edit
files" on per port basis - because it is inconsistent and unpredictable.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
I'm of the opinion that ports/packages should not touch running services
unless absolutely necessary.
I think that the best would be to do some user configurable hooks on
install / uninstall / upgrade actions in similar way as portupgrade does
it. (e.g. somebody may want to stop another service before upgrade
[restart] of mysql-server)
Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On Thursday, October 27, 2011 11:15:00 AM Ed Schouten wrote:
> Hi folks,
>
> As crees@ suggested, I'm sending an email to ports@ about this.
>
> What really bothers me when I use the FreeBSD Ports tree on one of my
> systems, is that the behaviour of dealing with services is quite
> inconsistent. As mentioned in the PR:
>
> - If I upgrade Apache, MySQL or PostgreSQL, it does not restart the
> service, meaning it won't use the freshly installed daemon. This has
> potential security issues.
>
> - If I upgrade Dovecot, it shuts it down during the upgrade, but won't
> restart it. This means that I have to watch portmaster to complete and
> must not forget to restart Dovecot afterwards.
>
> My question is whether anyone has ever attempted to improve the
> integration with rc-scripts? In the PR I propose something along these
> lines:
>
> We know exactly which ports install rc scripts (USE_RC_SUBR).
> Why not run `/usr/local/etc/rc.d/${FOO} status' and
> `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
> on the return value of the first, we can run
> `/usr/local/etc/rc.d/${FOO} start' after installation.
portupgrade provides basic support for restarting services via pkgtools.conf:
BEFOREDEINSTALL = {
# Automatically stop the service for each package that has a
# rc script enabled
'*' => proc { |origin|
cmd_stop_rc(origin)
},
}
AFTERINSTALL = {
# Automatically start the server for each package that
# installs a rc file enabled
'*' => proc { |origin|
cmd_start_rc(origin)
},
}
Keeping a service running during/after upgrade is potentielly unsafe. E.g., it
might be looking for files that have just been removed or modified in an
incompatible way.
Keeping a service running after deletion (no reinstall) also seems like a
really bad idea to me.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On 27.10.2011 15:04, Wesley Shields wrote:
>
> I agree inconsistency is a problem that could be addressed, but I don't
> particularly agree with some of your statements.
>
Consistency is important, and I agree with Wesley that we should
consistently "do nothing", instead of consistently stopping/starting
daemons.
>
>> - If I upgrade Dovecot, it shuts it down during the upgrade, but won't
>> restart it. This means that I have to watch portmaster to complete and
>> must not forget to restart Dovecot afterwards.
> Unless it is absolutely necessary to stop and restart dovecot during an
> upgrade I would like to see this removed.
I have a hard time imagining a situation where this is the case,
and again I agree with Wesley, I would also like to see it removed.
The dovecot stopping thing has bitten me more than once.
>
>> My question is whether anyone has ever attempted to improve the
>> integration with rc-scripts? In the PR I propose something along these
>> lines:
>>
>> We know exactly which ports install rc scripts (USE_RC_SUBR).
>> Why not run `/usr/local/etc/rc.d/${FOO} status' and
>> `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
>> on the return value of the first, we can run
>> `/usr/local/etc/rc.d/${FOO} start' after installation.
This can fail in so many unexpected ways that IMO it is much better
to do nothing at all, and leave it up to the sysadmin to decide when
to restart the daemon.
If anything like this is needed, perhaps we could add a message after
upgrading a port which installs an RC script, mentioning that the
sysadmin needs to restart the daemon manually (whenever appropriate)
in order to run the new version.
Best regards,
Thomas Steen Rasmussen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
> Hi folks,
>
> As crees@ suggested, I'm sending an email to ports@ about this.
>
> What really bothers me when I use the FreeBSD Ports tree on one of my
> systems, is that the behaviour of dealing with services is quite
> inconsistent. As mentioned in the PR:
I agree inconsistency is a problem that could be addressed, but I don't
particularly agree with some of your statements.
> - If I upgrade Apache, MySQL or PostgreSQL, it does not restart the
> service, meaning it won't use the freshly installed daemon. This has
> potential security issues.
I'd prefer that no services are started or stopped automatically, unless
absolutely necessary for the upgrade.
> - If I upgrade Dovecot, it shuts it down during the upgrade, but won't
> restart it. This means that I have to watch portmaster to complete and
> must not forget to restart Dovecot afterwards.
Unless it is absolutely necessary to stop and restart dovecot during an
upgrade I would like to see this removed.
> My question is whether anyone has ever attempted to improve the
> integration with rc-scripts? In the PR I propose something along these
> lines:
>
> We know exactly which ports install rc scripts (USE_RC_SUBR).
> Why not run `/usr/local/etc/rc.d/${FOO} status' and
> `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
> on the return value of the first, we can run
> `/usr/local/etc/rc.d/${FOO} start' after installation.
I'm of the opinion that ports/packages should not touch running services
unless absolutely necessary.
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
On 10/27/11 11:15, Ed Schouten wrote: I believe you have a point there. What really bothers me when I use the FreeBSD Ports tree on one of my systems, is that the behaviour of dealing with services is quite inconsistent. As mentioned in the PR: - If I upgrade Apache, MySQL or PostgreSQL, it does not restart the service, meaning it won't use the freshly installed daemon. This has potential security issues. - If I upgrade Dovecot, it shuts it down during the upgrade, but won't restart it. This means that I have to watch portmaster to complete and must not forget to restart Dovecot afterwards. So does dhcpserver, unfortunately. I'll also add a *really minor* glitch: during upgrade, some ports will leave their daemons running, but somehow break the rc.d scripts, so that you need to manually kill them before you can correctly restart them (e.g. saslauthd). IMVVVHO, I'd be pleased to have the port upgrading process do nothing and leave it to me to restart anything required. I'm inclined to think that, if some port upgrade process stops a daemon, there must be a reason behind this: possibly the port wouldn't upgrade properly otherwise. In this case I'd really like the port to stop and wait for me to press enter just before doing this. The reason is simple: if I launch a "portupgrade -a", taking potentially days, services will stop over time without any way for me to predict when and I can't possibly watch for hours. If they just stopped before killing a service, I could look from time to time and be prepared to restart it in a few minutes (just the time for a single port's "make install"). Just my two cents... bye av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/162049: The Ports tree lacks a framework to restart services
hello
On Thu, Oct 27, 2011 at 11:15 AM, Ed Schouten wrote:
> We know exactly which ports install rc scripts (USE_RC_SUBR).
> Why not run `/usr/local/etc/rc.d/${FOO} status' and
> `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
> on the return value of the first, we can run
> `/usr/local/etc/rc.d/${FOO} start' after installation.
Here is a link to the PR, for people who want it easy:
http://www.freebsd.org/cgi/query-pr.cgi?pr=162049
Shouldn't you be using 'service FOO stop' instead? See service(8).
Personally, I prefer the port upgrade process to NOT touch my running
services at all.
In cases where it can't be avoided, I'm prepared to manually handle
services that needs to be restarted after an upgrade.
As you probably are aware of already, there are also security concerns
with automatically starting a newly installed version of a program.
I'm only running FreeBSD for my personal use, on a limited number of machines.
If I was working with a larger number of machines, or needed an
automated solution, I would look into tools like sysutils/cfengine3
HTH
--
Regards,
Torfinn Ingolfsen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
ports/162049: The Ports tree lacks a framework to restart services
Hi folks,
As crees@ suggested, I'm sending an email to ports@ about this.
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent. As mentioned in the PR:
- If I upgrade Apache, MySQL or PostgreSQL, it does not restart the
service, meaning it won't use the freshly installed daemon. This has
potential security issues.
- If I upgrade Dovecot, it shuts it down during the upgrade, but won't
restart it. This means that I have to watch portmaster to complete and
must not forget to restart Dovecot afterwards.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
--
Ed Schouten
WWW: http://80386.nl/
pgpPIcEFLSqiZ.pgp
Description: PGP signature
