On 10/29/2009 03:31 PM, John Dennis wrote:
Hmm... leaving an init script around after package removal is a bug I
recently reported against dogtag (Certificate Management System).
Init scripts should be an actual file belonging to the rpm listed in
the %files section of the rpm spec file.
Out initconfig script (/etc/sysconfig/dirsrv) is a part of the package,
as is our init script (/etc/rc.d/init.d/dirsrv). The files that this
patch is referring to are instance specific initconfig scripts. An
instance is created after the RPM is installed, and hence can't be owned
by the package itself.
In dogtag the init script was being dynamically generated when the rpm
was installed. That's not good for two reasons, one is the init script
should be available for review and inspection, secondly it's a
critical file which is not known to rpm nor is it possible for rpm to
accord it config status with special config handing.
I have not looked at the 389 installation scripts or spec file but
this patch suggests 389 is doing the same thing dogtag is. Is 389
hiding it's init script in a perl generation step at installation?
Nope. It's a file generated at build time and is static once packaged.
The file we are referring to is sourced by the init script to set some
instance speficic paths. A example looks like this:
SERVER_DIR=/usr/lib/dirsrv ; export SERVER_DIR
SERVERBIN_DIR=/usr/sbin ; export SERVERBIN_DIR
CONFIG_DIR=/etc/dirsrv/slapd-foo ; export CONFIG_DIR
INST_DIR=/usr/lib/dirsrv/slapd-foo ; export INST_DIR
RUN_DIR=/var/run/dirsrv ; export RUN_DIR
DS_ROOT= ; export DS_ROOT
PRODUCT_NAME=slapd ; export PRODUCT_NAME
--
389-devel mailing list
389-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
