Re: What is policy about auto-editing config files on port install / deinstall?
On Thu, Jan 3, 2013 at 3:49 PM, Miroslav Lachman 000.f...@quip.cz wrote: What errors are you getting when re-installing an Apache module? Apache modules are not enabled by default. I am talking about 3rd party modules. In some cases, they do nothing with httpd.conf, in other cases, they are adding commented line and I must manualy uncomment this line, so it is my will to have this module loaded / enabled. But upgrade or reinstall or deinstall of this module causes commenting this line out. It is undesirable. If I enable this module and this module will be updated 10 times a year, why am I forced to re-enable it 10 times again? Real world example follows: root@spare ~/# uname -srmi FreeBSD 8.3-RC2 amd64 GENERIC ___ Only Apache is installed, no 3rd party modules root@spare ~/# pkg_info -E ap22\* apache22-\* apache22-2.2.23_4 ___ Copy the config file for later comparision root@spare ~/# cp -P /usr/local/etc/apache22/httpd.conf httpd.conf.orig ___ Install mod_xsendfile root@spare ~/# portmaster www/mod_xsendfile === Installation of www/mod_xsendfile (ap22-mod_xsendfile-0.12_2) complete ___ There is commented LoadModule line after install added to httpd.conf root@spare ~/# diff -U 2 httpd.conf.orig /usr/local/etc/apache22/httpd.conf --- httpd.conf.orig 2013-01-03 12:56:22.0 +0100 +++ /usr/local/etc/apache22/httpd.conf 2013-01-03 21:25:03.0 +0100 @@ -75,4 +75,5 @@ LoadModule rewrite_module libexec/apache22/mod_rewrite.so LoadModule php5_modulelibexec/apache22/libphp5.so +#LoadModule xsendfile_module libexec/apache22/mod_xsendfile.so ___ I must manually uncomment the line (which is OK, I don't need to modules be auto enabled as services are not enabled in rc.conf) root@spare ~/# vi /usr/local/etc/apache22/httpd.conf LoadModule xsendfile_module libexec/apache22/mod_xsendfile.so ___ Then I added some configuration to VirtualHost root@spare ~/# vi /usr/local/etc/apache22/vhosts/available/www.example.com.conf XSendFile on XSendFilePath /vol0/web/test ___ Diff shows that module is enabled root@spare ~/# diff -U 2 httpd.conf.orig /usr/local/etc/apache22/httpd.conf --- httpd.conf.orig 2013-01-03 12:56:22.0 +0100 +++ /usr/local/etc/apache22/httpd.conf 2013-01-03 21:26:46.0 +0100 @@ -75,4 +75,5 @@ LoadModule rewrite_module libexec/apache22/mod_rewrite.so LoadModule php5_modulelibexec/apache22/libphp5.so +LoadModule xsendfile_module libexec/apache22/mod_xsendfile.so ___ Syntax check root@spare ~/# httpd -t Syntax OK ___ Reinstallation of the module (same as upgrading) root@spare ~/# portmaster ap22-mod_xsendfile-0.12_2 === Creating a backup package for old version ap22-mod_xsendfile-0.12_2 === Package saved to /usr/ports/packages/portmaster-backup Don't forget to remove all mod_xsendfile-related directives in your httpd.conf === Installing for ap22-mod_xsendfile-0.12_2 === Generating temporary packing list === Checking if www/mod_xsendfile already installed /usr/local/share/apache22/build/instdso.sh SH_LIBTOOL='/usr/local/share/apr/build-1/libtool' /usr/ports/www/mod_xsendfile/work/mod_xsendfile-0.12/mod_xsendfile.la /usr/local/libexec/apache22 /usr/local/share/apr/build-1/libtool --mode=install cp /usr/ports/www/mod_xsendfile/work/mod_xsendfile-0.12/mod_xsendfile.la /usr/local/libexec/apache22/ libtool: install: cp /usr/ports/www/mod_xsendfile/work/mod_xsendfile-0.12/.libs/mod_xsendfile.so /usr/local/libexec/apache22/mod_xsendfile.so libtool: install: cp /usr/ports/www/mod_xsendfile/work/mod_xsendfile-0.12/.libs/mod_xsendfile.lai /usr/local/libexec/apache22/mod_xsendfile.la libtool: install: cp /usr/ports/www/mod_xsendfile/work/mod_xsendfile-0.12/.libs/mod_xsendfile.a /usr/local/libexec/apache22/mod_xsendfile.a libtool: install: chmod 644 /usr/local/libexec/apache22/mod_xsendfile.a libtool: install: ranlib /usr/local/libexec/apache22/mod_xsendfile.a chmod 755 /usr/local/libexec/apache22/mod_xsendfile.so [preparing module `xsendfile' in /usr/local/etc/apache22/httpd.conf] === Registering installation for ap22-mod_xsendfile-0.12_2 === Creating a package for new version ap22-mod_xsendfile-0.12_2 === Package saved to /usr/ports/packages/All === Re-installation of ap22-mod_xsendfile-0.12_2 complete ___ And there is a problem - syntax error, because module was disabled (commented out on deinstall) and some directives remained in
Re: What is policy about auto-editing config files on port install / deinstall?
On Fri, Jan 4, 2013 at 2:12 AM, Scot Hetzel swhet...@gmail.com wrote:
Why am I forced to manualy re-enable all 3rd party modules on each upgrade?
Modules should not disable something that is explicitly enabled by user /
system administrator.
I found the cause of your issue, the www/mod_sendfile/Makefile has
AP_GENPLIST= yes defined. This causes the port to use this code to
create the packing list:
Mk/bsd.apache.mk
451 ap-gen-plist:
452 .if defined(AP_GENPLIST)
453 . if !exists(${PLIST})
454 @${ECHO} === Generating apache plist
455 # apache22
456 @${ECHO} @unexec ${SED} -i '' -E
'/LoadModule[[:blank:]]+%%AP_NAME%%_module/d'
%D/%%APACHEETCDIR%%/httpd.conf ${PLIST}
Found the reason for this sed line, as it is used to remove the
LoadModule line from the httpd.conf file so that when Apache is
uninstalled, the httpd.conf could be removed, if there were no changes
from the original.
see http://svnweb.freebsd.org/ports?view=revisionrevision=194395
I still think it is better to disable the module on uninstall, and
enable the module on install.
457 @${ECHO} %%APACHEMODDIR%%/%%AP_MODULE%% ${PLIST}
458 @${ECHO} @exec %D/sbin/apxs -e -A -n %%AP_NAME%% %D/%F ${PLIST}
459 @${ECHO} @unexec echo \Don't forget to remove all
${MODULENAME}-related directives in your httpd.conf\ ${PLIST}
460 . endif
461 .else
462 @${DO_NADA}
463 .endif
464 .endif
As well as adding the module disabled in the httpd.conf file:
472 do-install:
473 @${APXS} -i -A -n ${SHORTMODNAME}
${WRKSRC}/${MODULENAME}.${AP_BUILDEXT}
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
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: What is policy about auto-editing config files on port install / deinstall?
On 2013-01-04 09:51, Scot Hetzel wrote:
On Fri, Jan 4, 2013 at 2:12 AM, Scot Hetzel swhet...@gmail.com wrote:
Why am I forced to manualy re-enable all 3rd party modules on each upgrade?
Modules should not disable something that is explicitly enabled by user /
system administrator.
I found the cause of your issue, the www/mod_sendfile/Makefile has
AP_GENPLIST= yes defined. This causes the port to use this code to
create the packing list:
Mk/bsd.apache.mk
451 ap-gen-plist:
452 .if defined(AP_GENPLIST)
453 . if !exists(${PLIST})
454 @${ECHO} === Generating apache plist
455 # apache22
456 @${ECHO} @unexec ${SED} -i '' -E
'/LoadModule[[:blank:]]+%%AP_NAME%%_module/d'
%D/%%APACHEETCDIR%%/httpd.conf ${PLIST}
Found the reason for this sed line, as it is used to remove the
LoadModule line from the httpd.conf file so that when Apache is
uninstalled, the httpd.conf could be removed, if there were no changes
from the original.
see http://svnweb.freebsd.org/ports?view=revisionrevision=194395
I still think it is better to disable the module on uninstall, and
enable the module on install.
Hi Scot,
have you also read the commit log?
- Fix leftover httpd.conf for AP_GEN_PLIST using ports. The problem is that
apxs does not remove module line from httpd.conf, it merely comments it out.
Later, on Apache deinstall, the file differs from stock httpd.conf and is not
deleted.
The issue is the following.
In case the LoadModule line is not removed from httpd.conf the port will be
marked as broken by the ports build system.
I'm thinking about an parameter which change the semantic in bsd.apache.mk so
the module can be installed enabled.
For example the following will do that (quick hack)
Index: bsd.apache.mk
===
--- bsd.apache.mk (revision 309921)
+++ bsd.apache.mk (working copy)
@@ -455,7 +445,11 @@
# apache22
@${ECHO} @unexec ${SED} -i '' -E
'/LoadModule[[:blank:]]+%%AP_NAME%%_module/d' %D/%%APACHEETCDIR%%/httpd.conf
${PLIST}
@${ECHO} %%APACHEMODDIR%%/%%AP_MODULE%% ${PLIST}
+.if defined(AP_MODENABLE)
+ @${ECHO} @exec %D/sbin/apxs -e -a -n %%AP_NAME%% %D/%F ${PLIST}
+.else
@${ECHO} @exec %D/sbin/apxs -e -A -n %%AP_NAME%% %D/%F ${PLIST}
+.endif
@${ECHO} @unexec echo \Don't forget to remove all
${MODULENAME}-related directives in your httpd.conf\ ${PLIST}
. endif
.else
--
Regards,
olli
___
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: What is policy about auto-editing config files on port install / deinstall?
olli hauer wrote:
On 2013-01-04 09:51, Scot Hetzel wrote:
On Fri, Jan 4, 2013 at 2:12 AM, Scot Hetzelswhet...@gmail.com wrote:
Why am I forced to manualy re-enable all 3rd party modules on each upgrade?
Modules should not disable something that is explicitly enabled by user /
system administrator.
I found the cause of your issue, the www/mod_sendfile/Makefile has
AP_GENPLIST= yes defined. This causes the port to use this code to
create the packing list:
Mk/bsd.apache.mk
451 ap-gen-plist:
452 .if defined(AP_GENPLIST)
453 . if !exists(${PLIST})
454 @${ECHO} === Generating apache plist
455 # apache22
456 @${ECHO} @unexec ${SED} -i '' -E
'/LoadModule[[:blank:]]+%%AP_NAME%%_module/d'
%D/%%APACHEETCDIR%%/httpd.conf ${PLIST}
Found the reason for this sed line, as it is used to remove the
LoadModule line from the httpd.conf file so that when Apache is
uninstalled, the httpd.conf could be removed, if there were no changes
from the original.
see http://svnweb.freebsd.org/ports?view=revisionrevision=194395
I still think it is better to disable the module on uninstall, and
enable the module on install.
Hi Scot,
have you also read the commit log?
- Fix leftover httpd.conf for AP_GEN_PLIST using ports. The problem is that
apxs does not remove module line from httpd.conf, it merely comments it out.
Later, on Apache deinstall, the file differs from stock httpd.conf and is not
deleted.
The issue is the following.
In case the LoadModule line is not removed from httpd.conf the port will be
marked as broken by the ports build system.
I'm thinking about an parameter which change the semantic in bsd.apache.mk so
the module can be installed enabled.
For example the following will do that (quick hack)
Index: bsd.apache.mk
===
--- bsd.apache.mk (revision 309921)
+++ bsd.apache.mk (working copy)
@@ -455,7 +445,11 @@
# apache22
@${ECHO} @unexec ${SED} -i '' -E '/LoadModule[[:blank:]]+%%AP_NAME%%_module/d'
%D/%%APACHEETCDIR%%/httpd.conf ${PLIST}
@${ECHO} %%APACHEMODDIR%%/%%AP_MODULE%% ${PLIST}
+.if defined(AP_MODENABLE)
+ @${ECHO} @exec %D/sbin/apxs -e -a -n %%AP_NAME%% %D/%F ${PLIST}
+.else
@${ECHO} @exec %D/sbin/apxs -e -A -n %%AP_NAME%% %D/%F ${PLIST}
+.endif
@${ECHO} @unexec echo \Don't forget to remove all ${MODULENAME}-related directives
in your httpd.conf\ ${PLIST}
. endif
.else
According to what was said in previous e-mails, there are several ways
to handle install / deinstall:
1] add #LoadModule line commented on install and remove this line only
if it is still commented (no user change made)
2] do not add anything, print the LoadModule line as pkg-message on
install (this is standard way used by another ports to inform users what
changes must be made to activate some port), do not remove anything on
deinstall, print info message to remove line (similar to @unexec message
above)
3] add LoadModule line uncommented on install (enable modul by default)
and remove the line on uninstall
I prefere second or first variant. Somebody may not be happy to have
modules enabled by default (the same policy as for not enabling services
in rc.conf, not adding cronjobs or changes in periodic.conf)
My first try was to change @unexec sed line to:
@${ECHO} @unexec ${SED} -i '' -E
'/^#LoadModule[[:blank:]]+%%AP_NAME%%_module/d'
%D/%%APACHEETCDIR%%/httpd.conf ${PLIST}
It will produce following line in +CONTENTS
@unexec /usr/bin/sed -i '' -E
'/^#LoadModule[[:blank:]]+xsendfile_module/d' %D/etc/apache22/httpd.conf
The problem is, that apxs line is working as switch:
@exec %D/sbin/apxs -e -A -n xsendfile %D/%F
First call adds LoadModule line and second removes it. So if the line is
still there on next install, apxs is removing the line instead of left
it untouched.
I don't have time to track it down right know. I will try to investigate
it later today or tomorrow.
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: What is policy about auto-editing config files on port install / deinstall?
On Fri, Jan 4, 2013 at 3:25 AM, olli hauer oha...@gmx.de wrote:
456 @${ECHO} @unexec ${SED} -i '' -E
'/LoadModule[[:blank:]]+%%AP_NAME%%_module/d'
%D/%%APACHEETCDIR%%/httpd.conf ${PLIST}
Found the reason for this sed line, as it is used to remove the
LoadModule line from the httpd.conf file so that when Apache is
uninstalled, the httpd.conf could be removed, if there were no changes
from the original.
see http://svnweb.freebsd.org/ports?view=revisionrevision=194395
I still think it is better to disable the module on uninstall, and
enable the module on install.
Hi Scot,
have you also read the commit log?
- Fix leftover httpd.conf for AP_GEN_PLIST using ports. The problem is that
apxs does not remove module line from httpd.conf, it merely comments it out.
Later, on Apache deinstall, the file differs from stock httpd.conf and is
not
deleted.
I had read the commit log and still think it is wrong to remove the
LoadModule lines from the httpd.conf file, as the LoadModule line may
not be the only change to the httpd.conf file for that module.
How difficult would it be to create 2 temp files by striping all the
comments out of the httpd.conf* files, then compare those files to
determine if httpd.conf should be removed.
The issue is the following.
In case the LoadModule line is not removed from httpd.conf the port will be
marked as broken by the ports build system.
I'm thinking about an parameter which change the semantic in bsd.apache.mk so
the module can be installed enabled.
For example the following will do that (quick hack)
Index: bsd.apache.mk
===
--- bsd.apache.mk (revision 309921)
+++ bsd.apache.mk (working copy)
@@ -455,7 +445,11 @@
# apache22
@${ECHO} @unexec ${SED} -i '' -E
'/LoadModule[[:blank:]]+%%AP_NAME%%_module/d' %D/%%APACHEETCDIR%%/httpd.conf
${PLIST}
@${ECHO} %%APACHEMODDIR%%/%%AP_MODULE%% ${PLIST}
+.if defined(AP_MODENABLE)
+ @${ECHO} @exec %D/sbin/apxs -e -a -n %%AP_NAME%% %D/%F ${PLIST}
+.else
@${ECHO} @exec %D/sbin/apxs -e -A -n %%AP_NAME%% %D/%F ${PLIST}
+.endif
@${ECHO} @unexec echo \Don't forget to remove all
${MODULENAME}-related directives in your httpd.conf\ ${PLIST}
. endif
.else
That could work, how about putting a .if !defined(AP_MODENABLE) ..
.endif around the SED line, and adding @unexec %D/sbin/apxs -e -A -n
%%AP_NAME%% %D/%F ${PLIST} in the .if defined(AP_MODENABLE) ..
.else.
Of course the do-install target would also need to be changed to have
.if defined(AP_MODENABLE) enable module .else disable module .endif
upon install.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
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: What is policy about auto-editing config files on port install / deinstall?
Scot Hetzel swhet...@gmail.com wrote: On Wed, Jan 2, 2013 at 2:37 PM, Miroslav Lachman 000.f...@quip.cz wrote: Is somewhere written policy or portmgr recommendation about ports behavior on install / deinstall? My impression is that every maintainer has her own undocumented policy although the approaches taken could be grouped into a few categories. I am talking about some ports doing nasty things. Some ports are stopping services on deinstall, some not. I prefer that when a port is uninstalled, that the service is stopped. As long as it is optional and doesn't happen automatically I could live with that. At least to me uninstalling a port (with pkg or pkg_delete) means removing the files it installed and does not necessary imply also kill whatever process is related to these files. If it isn't stopped, it could pose a security risk to the system at a later time. Stopping a service can pose a security risk as well, so I don't think that's a good argument as it depends on the port. Some ports are editing my config files on deinstall, so even on upgrade procedure I must check if port did some changes before I can restart target daemon. Most ports don't edit the config files as they install the original config file to a different name. In my opinion ports shouldn't mess with user-modified files unless they properly parse them and can be expected not to break them. And even then I don't think it should be done automatically without user interaction. I believe that's currently up to the maintainer as well, though. Fabian signature.asc Description: PGP signature
Re: What is policy about auto-editing config files on port install / deinstall?
On 3 January 2013 12:12, Fabian Keil freebsd-lis...@fabiankeil.de wrote: Scot Hetzel swhet...@gmail.com wrote: On Wed, Jan 2, 2013 at 2:37 PM, Miroslav Lachman 000.f...@quip.cz wrote: Is somewhere written policy or portmgr recommendation about ports behavior on install / deinstall? My impression is that every maintainer has her own undocumented policy although the approaches taken could be grouped into a few categories. There is as far as I know no portmgr recommendation about stopping services etc; one may suggest that the inclusion of @stopdaemon support is encouragement, but also it's only supposed to be used if stopping the service is vital upon deinstall according to many. I am talking about some ports doing nasty things. Some ports are stopping services on deinstall, some not. I prefer that when a port is uninstalled, that the service is stopped. As long as it is optional and doesn't happen automatically I could live with that. Having this configurable with the current pkg_install suite is basically a non-starter. Allegedly this is a feature planned for pkgng. Currently, it is generally discouraged to put @stopdaemon into your pkg-plist unless something will probably break leaving your service running. 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: What is policy about auto-editing config files on port install / deinstall?
--On January 3, 2013 1:12:43 PM +0100 Fabian Keil
freebsd-lis...@fabiankeil.de wrote:
Scot Hetzel swhet...@gmail.com wrote:
On Wed, Jan 2, 2013 at 2:37 PM, Miroslav Lachman 000.f...@quip.cz
wrote:
Is somewhere written policy or portmgr recommendation about ports
behavior on install / deinstall?
My impression is that every maintainer has her own undocumented
policy although the approaches taken could be grouped into a few
categories.
This is likely true, however the Porters Handbook describes the preferred
methods for doing things.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html
I am talking about some ports doing nasty things.
Some ports are stopping services on deinstall, some not.
I prefer that when a port is uninstalled, that the service is stopped.
According to the Porters Handbook, this is not the preferred method:
6.24.1 Stopping Services at Deinstall
It is possible to have a service stopped automatically as part of the
deinstall routine. We advise using this feature only when it is absolutely
necessary to stop a service before its files go away. Usually, it is up to
the administrator's discretion to decide, whether to stop the service on
deinstall or not. Also note this affects upgrades, too.
A line like this goes in the pkg-plist:
@stopdaemon doormand
The argument must match the content of USE_RC_SUBR variable.
Some ports are editing my config files on deinstall, so even on
upgrade procedure I must check if port did some changes before I can
restart target daemon.
Most ports don't edit the config files as they install the original
config file to a different name.
In my opinion ports shouldn't mess with user-modified files unless
they properly parse them and can be expected not to break them.
The Porters Handbooks explicitly states this:
7.3 Configuration Files
If your port installs configuration files to PREFIX/etc (or elsewhere) do
not simply list them in the pkg-plist. That will cause pkg_delete(1) to
remove the files carefully edited by the user, and a re-installation will
wipe them out.
Instead, install sample file(s) with a filename.sample suffix. Then copy
the sample file to the real configuration file name, if it does not already
exist. On deinstall delete the configuration file, but only if it is
identical to the .sample file. You need to handle this both in the port
Makefile, and in the pkg-plist (for installation from the package).
Example of the Makefile part:
post-install:
@if [ ! -f ${PREFIX}/etc/orbit.conf ]; then \
${CP} -p ${PREFIX}/etc/orbit.conf.sample
${PREFIX}/etc/orbit.conf ; \
fi
For each configuration file, create the following three lines in pkg-plist:
@unexec if cmp -s %D/etc/orbit.conf.sample %D/etc/orbit.conf; then rm -f
%D/etc/orbit.conf; fi
etc/orbit.conf.sample
@exec if [ ! -f %D/etc/orbit.conf ] ; then cp -p %D/%F %B/orbit.conf; fi
The order of these lines is important. On deinstallation, the sample file
is compared to the actual configuration file. If these files are identical,
no changes have been made by the user and the actual file can be safely
deleted. Because the sample file must still exist for the comparison, the
@unexec line comes before the sample configuration file name. On
installation, if an actual configuration file is not already present, the
sample file is copied to the actual file. The sample file must be present
before it can be copied, so the @exec line comes after the sample
configuration file name.
To debug any issues, temporarily remove the -s flag to cmp(1) for more
output.
See pkg_create(1) for more information on %D and related substitution
markers.
If there is a very good reason not to install a working configuration file
by default, leave the @exec line out of pkg-plist and add a message
pointing out that the user must copy and edit the file before the software
will work.
And even then I don't think it should be done automatically without
user interaction.
I believe that's currently up to the maintainer as well, though.
Not if they are properly following the Porters Handbook and the committers
are verifying that they are doing so.
As with any system where humans are involved, the process is flawed.
However, there is a right way to do things. Refer to the Porters Handbook
and follow its instructions as much as is humanly possible.
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead. Thomas Jefferson
There are some ideas so wrong that only a very
intelligent person could believe in them. George Orwell
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To
Re: What is policy about auto-editing config files on port install / deinstall?
Scot Hetzel wrote: On Wed, Jan 2, 2013 at 2:37 PM, Miroslav Lachman000.f...@quip.cz wrote: Is somewhere written policy or portmgr recommendation about ports behavior on install / deinstall? I am talking about some ports doing nasty things. Some ports are stopping services on deinstall, some not. I prefer that when a port is uninstalled, that the service is stopped. If it isn't stopped, it could pose a security risk to the system at a later time. Only if it will be optional. I am the god in my world (my system) and I should know better than anybody else if I need to stop the daemon at any time. The maintainer of any port can't know all the dependencies on my system and my workflow with updating ports. Somebody can consider stopping (or restarting) Apache on upgrade as good thing, but it can be just a small piece of bigger upgrade process with lot of dependencies like Apache modules, PHP, PHP extensions and libraries used by both Apache and PHP extensions. So if for example Apache is upgraded and it will made upgrade of PCRE with different library version number, then restart of Apache will fail on PHP not loading missing old PCRE library. So the Apache should be restarted after upgrade of all the modules and libraries, not after upgrade of it self. We still need to come up with a way of restarting the service after the upgrade. Currently, it has to be done manually to start the service. Some ports are editing my config files on deinstall, so even on upgrade procedure I must check if port did some changes before I can restart target daemon. Most ports don't edit the config files as they install the original config file to a different name. For example some Apache modules (mod_bw, mod_xsendfile...) are commenting out load_module lines in httpd.conf so I got syntax error on Apache restart after upgrade of mentioned module and Apache failed to start. Apache 2.x is an exception, as the installation of a Apache module requires apachectl to add/re-enable the module in the httpd.conf file. Upon deinstallation, apachectl is used to disable the module in the httpd.conf file. It doesn't remove the LoadModule directive, it just adds a '# sign in front of it. When the port is re-installed, all apachectl has to do is remove the '#' sign. A restart of Apache should then load the module again. What errors are you getting when re-installing an Apache module? Apache modules are not enabled by default. I am talking about 3rd party modules. In some cases, they do nothing with httpd.conf, in other cases, they are adding commented line and I must manualy uncomment this line, so it is my will to have this module loaded / enabled. But upgrade or reinstall or deinstall of this module causes commenting this line out. It is undesirable. If I enable this module and this module will be updated 10 times a year, why am I forced to re-enable it 10 times again? Real world example follows: root@spare ~/# uname -srmi FreeBSD 8.3-RC2 amd64 GENERIC ___ Only Apache is installed, no 3rd party modules root@spare ~/# pkg_info -E ap22\* apache22-\* apache22-2.2.23_4 ___ Copy the config file for later comparision root@spare ~/# cp -P /usr/local/etc/apache22/httpd.conf httpd.conf.orig ___ Install mod_xsendfile root@spare ~/# portmaster www/mod_xsendfile === Installation of www/mod_xsendfile (ap22-mod_xsendfile-0.12_2) complete ___ There is commented LoadModule line after install added to httpd.conf root@spare ~/# diff -U 2 httpd.conf.orig /usr/local/etc/apache22/httpd.conf --- httpd.conf.orig 2013-01-03 12:56:22.0 +0100 +++ /usr/local/etc/apache22/httpd.conf 2013-01-03 21:25:03.0 +0100 @@ -75,4 +75,5 @@ LoadModule rewrite_module libexec/apache22/mod_rewrite.so LoadModule php5_modulelibexec/apache22/libphp5.so +#LoadModule xsendfile_module libexec/apache22/mod_xsendfile.so ___ I must manually uncomment the line (which is OK, I don't need to modules be auto enabled as services are not enabled in rc.conf) root@spare ~/# vi /usr/local/etc/apache22/httpd.conf LoadModule xsendfile_module libexec/apache22/mod_xsendfile.so ___ Then I added some configuration to VirtualHost root@spare ~/# vi /usr/local/etc/apache22/vhosts/available/www.example.com.conf XSendFile on XSendFilePath /vol0/web/test ___ Diff shows that module is enabled root@spare ~/# diff -U 2 httpd.conf.orig /usr/local/etc/apache22/httpd.conf --- httpd.conf.orig 2013-01-03 12:56:22.0 +0100 +++ /usr/local/etc/apache22/httpd.conf 2013-01-03 21:26:46.0 +0100 @@ -75,4 +75,5 @@ LoadModule rewrite_module
Re: What is policy about auto-editing config files on port install / deinstall?
On 2013-01-03 22:49, Miroslav Lachman wrote: Scot Hetzel wrote: On Wed, Jan 2, 2013 at 2:37 PM, Miroslav Lachman000.f...@quip.cz wrote: Is somewhere written policy or portmgr recommendation about ports behavior on install / deinstall? I am talking about some ports doing nasty things. Some ports are stopping services on deinstall, some not. I prefer that when a port is uninstalled, that the service is stopped. If it isn't stopped, it could pose a security risk to the system at a later time. Only if it will be optional. I am the god in my world (my system) and I should know better than anybody else if I need to stop the daemon at any time. The maintainer of any port can't know all the dependencies on my system and my workflow with updating ports. Somebody can consider stopping (or restarting) Apache on upgrade as good thing, but it can be just a small piece of bigger upgrade process with lot of dependencies like Apache modules, PHP, PHP extensions and libraries used by both Apache and PHP extensions. So if for example Apache is upgraded and it will made upgrade of PCRE with different library version number, then restart of Apache will fail on PHP not loading missing old PCRE library. So the Apache should be restarted after upgrade of all the modules and libraries, not after upgrade of it self. We still need to come up with a way of restarting the service after the upgrade. Currently, it has to be done manually to start the service. Some ports are editing my config files on deinstall, so even on upgrade procedure I must check if port did some changes before I can restart target daemon. Most ports don't edit the config files as they install the original config file to a different name. For example some Apache modules (mod_bw, mod_xsendfile...) are commenting out load_module lines in httpd.conf so I got syntax error on Apache restart after upgrade of mentioned module and Apache failed to start. Apache 2.x is an exception, as the installation of a Apache module requires apachectl to add/re-enable the module in the httpd.conf file. Upon deinstallation, apachectl is used to disable the module in the httpd.conf file. It doesn't remove the LoadModule directive, it just adds a '# sign in front of it. When the port is re-installed, all apachectl has to do is remove the '#' sign. A restart of Apache should then load the module again. What errors are you getting when re-installing an Apache module? Apache modules are not enabled by default. I am talking about 3rd party modules. In some cases, they do nothing with httpd.conf, in other cases, they are adding commented line and I must manualy uncomment this line, so it is my will to have this module loaded / enabled. But upgrade or reinstall or deinstall of this module causes commenting this line out. It is undesirable. If I enable this module and this module will be updated 10 times a year, why am I forced to re-enable it 10 times again? Real world example follows: root@spare ~/# uname -srmi FreeBSD 8.3-RC2 amd64 GENERIC ___ Only Apache is installed, no 3rd party modules root@spare ~/# pkg_info -E ap22\* apache22-\* apache22-2.2.23_4 ___ Copy the config file for later comparision root@spare ~/# cp -P /usr/local/etc/apache22/httpd.conf httpd.conf.orig ___ Install mod_xsendfile root@spare ~/# portmaster www/mod_xsendfile === Installation of www/mod_xsendfile (ap22-mod_xsendfile-0.12_2) complete ___ There is commented LoadModule line after install added to httpd.conf root@spare ~/# diff -U 2 httpd.conf.orig /usr/local/etc/apache22/httpd.conf --- httpd.conf.orig 2013-01-03 12:56:22.0 +0100 +++ /usr/local/etc/apache22/httpd.conf 2013-01-03 21:25:03.0 +0100 @@ -75,4 +75,5 @@ LoadModule rewrite_module libexec/apache22/mod_rewrite.so LoadModule php5_modulelibexec/apache22/libphp5.so +#LoadModule xsendfile_module libexec/apache22/mod_xsendfile.so ___ I must manually uncomment the line (which is OK, I don't need to modules be auto enabled as services are not enabled in rc.conf) root@spare ~/# vi /usr/local/etc/apache22/httpd.conf LoadModule xsendfile_module libexec/apache22/mod_xsendfile.so ___ Then I added some configuration to VirtualHost root@spare ~/# vi /usr/local/etc/apache22/vhosts/available/www.example.com.conf XSendFile on XSendFilePath /vol0/web/test ___ Diff shows that module is enabled root@spare ~/# diff -U 2 httpd.conf.orig /usr/local/etc/apache22/httpd.conf --- httpd.conf.orig 2013-01-03 12:56:22.0 +0100 +++
RE: What is policy about auto-editing config files on port install / deinstall?
So, what is the general recommended policy on the network services ports in regard to /etc/rc.conf file ? If I install a port that creates a service foodbank, then which choice is better: 1) Automatically edit /etc/rc.conf in the port installation script to include the line: foodbank_enable=YES, or: 2) Display a message to the user like you must edit /etc/rc.conf to add line foodbank=YES file ? The same question applies to the port de-installation. Thanks ! Oleg -Original Message- From: owner-freebsd-po...@freebsd.org [mailto:owner-freebsd- po...@freebsd.org] On Behalf Of Miroslav Lachman Sent: Thursday, January 03, 2013 1:49 PM To: Scot Hetzel Cc: freebsd-ports@freebsd.org Subject: Re: What is policy about auto-editing config files on port install / deinstall? Scot Hetzel wrote: On Wed, Jan 2, 2013 at 2:37 PM, Miroslav Lachman000.f...@quip.cz wrote: Is somewhere written policy or portmgr recommendation about ports behavior on install / deinstall? I am talking about some ports doing nasty things. Some ports are stopping services on deinstall, some not. I prefer that when a port is uninstalled, that the service is stopped. If it isn't stopped, it could pose a security risk to the system at a later time. Only if it will be optional. I am the god in my world (my system) and I should know better than anybody else if I need to stop the daemon at any time. The maintainer of any port can't know all the dependencies on my system and my workflow with updating ports. Somebody can consider stopping (or restarting) Apache on upgrade as good thing, but it can be just a small piece of bigger upgrade process with lot of dependencies like Apache modules, PHP, PHP extensions and libraries used by both Apache and PHP extensions. So if for example Apache is upgraded and it will made upgrade of PCRE with different library version number, then restart of Apache will fail on PHP not loading missing old PCRE library. So the Apache should be restarted after upgrade of all the modules and libraries, not after upgrade of it self. We still need to come up with a way of restarting the service after the upgrade. Currently, it has to be done manually to start the service. Some ports are editing my config files on deinstall, so even on upgrade procedure I must check if port did some changes before I can restart target daemon. Most ports don't edit the config files as they install the original config file to a different name. For example some Apache modules (mod_bw, mod_xsendfile...) are commenting out load_module lines in httpd.conf so I got syntax error on Apache restart after upgrade of mentioned module and Apache failed to start. Apache 2.x is an exception, as the installation of a Apache module requires apachectl to add/re-enable the module in the httpd.conf file. Upon deinstallation, apachectl is used to disable the module in the httpd.conf file. It doesn't remove the LoadModule directive, it just adds a '# sign in front of it. When the port is re-installed, all apachectl has to do is remove the '#' sign. A restart of Apache should then load the module again. What errors are you getting when re-installing an Apache module? Apache modules are not enabled by default. I am talking about 3rd party modules. In some cases, they do nothing with httpd.conf, in other cases, they are adding commented line and I must manualy uncomment this line, so it is my will to have this module loaded / enabled. But upgrade or reinstall or deinstall of this module causes commenting this line out. It is undesirable. If I enable this module and this module will be updated 10 times a year, why am I forced to re-enable it 10 times again? Real world example follows: root@spare ~/# uname -srmi FreeBSD 8.3-RC2 amd64 GENERIC ___ Only Apache is installed, no 3rd party modules root@spare ~/# pkg_info -E ap22\* apache22-\* apache22-2.2.23_4 ___ Copy the config file for later comparision root@spare ~/# cp -P /usr/local/etc/apache22/httpd.conf httpd.conf.orig ___ Install mod_xsendfile root@spare ~/# portmaster www/mod_xsendfile === Installation of www/mod_xsendfile (ap22-mod_xsendfile-0.12_2) complete ___ There is commented LoadModule line after install added to httpd.conf root@spare ~/# diff -U 2 httpd.conf.orig /usr/local/etc/apache22/httpd.conf --- httpd.conf.orig 2013-01-03 12:56:22.0 +0100 +++ /usr/local/etc/apache22/httpd.conf 2013-01-03 21:25:03.0 +++ +0100 @@ -75,4 +75,5 @@ LoadModule rewrite_module libexec/apache22/mod_rewrite.so LoadModule php5_modulelibexec/apache22/libphp5.so +#LoadModule xsendfile_module libexec/apache22
Re: What is policy about auto-editing config files on port install / deinstall?
On 2013-01-03 23:14, Oleg Moskalenko wrote: So, what is the general recommended policy on the network services ports in regard to /etc/rc.conf file ? If I install a port that creates a service foodbank, then which choice is better: 1) Automatically edit /etc/rc.conf in the port installation script to include the line: foodbank_enable=YES, or: 2) Display a message to the user like you must edit /etc/rc.conf to add line foodbank=YES file ? The same question applies to the port de-installation. Thanks ! Oleg Hi Oleg, the file /etc/rc.conf(.local) should be never touched by an install script. In case you will enable the network service you have to do this explicit by yourself. For the rc system it doesn't matter later if the line is present but the port no longer installed. -- Regards, olli ___ 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: What is policy about auto-editing config files on port install / deinstall?
On 03/01/2013 22:14, Oleg Moskalenko wrote: So, what is the general recommended policy on the network services ports in regard to /etc/rc.conf file ? If I install a port that creates a service foodbank, then which choice is better: 1) Automatically edit /etc/rc.conf in the port installation script to include the line: foodbank_enable=YES, or: 2) Display a message to the user like you must edit /etc/rc.conf to add line foodbank=YES file ? The same question applies to the port de-installation. That's a rather different question to the original. In this case, the policy is clear: always choice 2 -- advise the admin about what to do, where necessary. Installing a port does not reliably imply intent to run it as a service and hence automatically enabling it in rc.conf is simply wrong. Although adding 'foodbank_enable=YES' to /etc/rc.conf is such a routine action that you probably don't really need to mention it. The original question was more along the lines of 'should installing or deinstalling the port mean automatically editing /usr/local/etc/foodbank.conf ?' Well, maybe. Editing the port on deinstall only makes sense if there are several different ported applications that all use the same configuration file. Otherwise, there's no point editing the config file, since deleting the port means there's nothing left to read it. The classic example of automatically editing a config file occurs with httpd.conf when installing/deinstalling apache modules. That fulfils the multiple ports using the same config file criterion in an exemplary way. Customising a config file used exclusively by one port at install time (but only if there isn't a pre-existing config file) is more of a grey area. On the whole ports tend not to do this, citing the 'Tools not Policy' mantra. But I don't think it is actually forbidden. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: What is policy about auto-editing config files on port install / deinstall?
olli hauer wrote: The point is at the moment the port is uninstalled the port has no knowledge about the reason (uninstall permanent / reinstall / upgrade ) so the assumption is permanent. What I really don't get is users complaining about critical machines, special workflow and then thy do builds on that *critical* system with a script that can be interrupted by fill in several reasons. You totally missed the point. I didn't talk about critical machines, but about ports infrastructure doing wrong things. It doesn't matter if it is some home machine or some supercritical server in datacenter. The point is that port modifies configuration in a wrong way. Have you ever thought about a tinderbox, poudriere or simmilar which builds customized packages all the time in a clean environment? If the build is finished you have all the sort of buildlogs and can do an package upgrade in seconds on a prod machine ( it takes me 10min to update a hand full of machines ). Did you tried installing / deinstalling mod_xsendfile from package instead of these empty words? The behavior is very similar to installation from ports. Tinderbox, pourdrier or anything else doesn't change what I am talking about. It always ends with modified (non-working) httpd.conf. After the upgrade all I have to do is for services like apache an svn diff and maybe an svn revert httpd.conf then fire my daemon_restart scrip and go to the next machine. So you are recommending home-grown tools to fix ports / packages wrong behavior. Really nice solution! 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: What is policy about auto-editing config files on port install / deinstall?
On Wed, Jan 2, 2013 at 2:37 PM, Miroslav Lachman 000.f...@quip.cz wrote: Is somewhere written policy or portmgr recommendation about ports behavior on install / deinstall? I am talking about some ports doing nasty things. Some ports are stopping services on deinstall, some not. I prefer that when a port is uninstalled, that the service is stopped. If it isn't stopped, it could pose a security risk to the system at a later time. We still need to come up with a way of restarting the service after the upgrade. Currently, it has to be done manually to start the service. Some ports are editing my config files on deinstall, so even on upgrade procedure I must check if port did some changes before I can restart target daemon. Most ports don't edit the config files as they install the original config file to a different name. For example some Apache modules (mod_bw, mod_xsendfile...) are commenting out load_module lines in httpd.conf so I got syntax error on Apache restart after upgrade of mentioned module and Apache failed to start. Apache 2.x is an exception, as the installation of a Apache module requires apachectl to add/re-enable the module in the httpd.conf file. Upon deinstallation, apachectl is used to disable the module in the httpd.conf file. It doesn't remove the LoadModule directive, it just adds a '# sign in front of it. When the port is re-installed, all apachectl has to do is remove the '#' sign. A restart of Apache should then load the module again. What errors are you getting when re-installing an Apache module? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ 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
