[389-devel] Please Review: Remove instance initconfig script when removing an instance

[Nathan Kinder]

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