Description of problem: To activate SASL/GSSAPI authentication so that kerberos tickets can be used, currently a user has to modify the init script to provide an environment variable to set the keytab file location Version-Release number of selected component (if applicable): latest in F7 How reproducible: always Steps to Reproduce: N/A Actual results: A user have to modify the init script Expected results: It is better if a user could modify a sysconfig file and leave alone the init scripts Additional info: Patch attached With this patch the user can add a line like the following in /etc/sysconfig/fedora-ds: export KRB5_KTNAME=/etc/fedora-ds/fds.keytab
Created attachment 159210 [details] init script patch
A couple of thoughts: 1) There may be multiple instances of directory server - the init script is able to start all of them, or the one specified on the service line. So we need to have an instance specific config file. Maybe have the init script source /etc/fedora-ds/slapd-instance/initconfig or something like that? 2) It would be nice if we could come up with a cross platform way to do this - /etc/sysconfig is a linux thing - it doesn't exist on Solaris or HP-UX.
True, many instances can co-exist, so splitting make sense, but init scripts are platform specific so I don't see why we should diverge from the well known meaning of /etc/sysconfig on fedora. I'd implement something like /etc/sysconfig/fedora-ds/init-instance on fedora and maybe remap it to just /etc/fedora-ds/init-instance on other systems
Setting priority to High. Karl M. says this is critical for IPA and must be in DS 8.0.
My proposal is that /etc/sysconfig/dirsrv will set values that are shared among all directory server instances e.g. LD_LIBRARY_PATH or ulimit or etc. /etc/sysconfig/slapd-instance will set instance specific variables e.g. the keytab (unless you can share a keytab among several servers? I suppose that's possible since they could all have the same fqdn). So the initscript will do something like test -f /etc/sysconfig/dirsrv && . /etc/sysconfig/dirsrv Then for each instance in the loop: test -f /etc/sysconfig/slapd-$instance && . /etc/sysconfig/slapd-$instance We'll also need to do the same thing for the admin server - in the dirsrv-admin init script: test -f /etc/sysconfig/dirsrv-admin && . /etc/sysconfig/dirsrv-admin The directory /etc/sysconfig will be set in configure.ac. On Solaris, /etc/default is used. Looks like other linux distros (e.g. Debian, SuSE) use /etc/default, and there seems to be some indication in the FHS that /etc/default is appropriate for conffiles sourced by initscripts. So configure will do this: if -d /etc/sysconfig then use /etc/sysconfg else if -d /etc/default then use /etc/default else use /etc/dirsrv/config Does this sound ok?
Should the package provide a default init config file? One thing that concerns me about that would be that it will mess up existing installations that have already hacked the init script and already use /etc/sysconfig/dirsrv. If the rpm has marked %config for this file, will it be ok?
Created attachment 217951 [details] diffs - ldapserver
Created attachment 217961 [details] diffs - adminserver
Do not pollute sysconfig directly please. It is probably better to add an /etc/sysconfig/dirsrv-instances/ directory which contains the <instance> files Providing a default file is not a problem, you mark it as config and make sure that on installation an .rpmnew file is created if an existing one is found.
Created attachment 218031 [details] diffs - ldapserver
Created attachment 218041 [details] diffs - adminserver
(In reply to comment #11) > Do not pollute sysconfig directly please. > It is probably better to add an /etc/sysconfig/dirsrv-instances/ directory which > contains the <instance> files Hmm. I'd rather not have to create another directory in the package, which might not be used at all. In the vast majority of cases, there will only be one instance of directory server running, so /etc/sysconfig/dirsrv will be the only one used. What about dirsrv-slapd-instance for the filename? The only one doing the polluting will be the system administrator - the package will not create any dirsrv or slapd-instance files in this directory, nor will instance creation. > > Providing a default file is not a problem, you mark it as config and make sure > that on installation an .rpmnew file is created if an existing one is found. Should I create the file /etc/sysconfig/dirsrv when the package is installed? I notice there are other packages that do that - e.g. /etc/sysconfig/vncservers is empty except for a lot of comments explaining how to use the file. Should I do the same? Note that I'm proposing only to create /etc/sysconfig/dirsrv and /etc/sysconfig/dirsrv-admin, not any instance specific config files. If there is already a file /etc/sysconfig/dirsrv, that was created for an earlier version of Fedora DS 1.1 because it was not in the package, will that file be preserved when installing the new Fedora DS 1.1 package that does include that file?
Created attachment 218101 [details] diffs - ldapserver adds default dirsrv init config file - use dirsrv-instance instead of slapd-instance for instance specific init file config
Created attachment 218121 [details] diffs - adminserver
Created attachment 218201 [details] cvs commit log - ldapserver Reviewed by: nhosoi (Thanks!) Fix Description: I just took Simo's initial patch and ran with it. The initconfigdir parameter is the directory containing the config file for the init script. configure will first try to use $(sysconfdir)/sysconfig, then $(sysconfdir)/default (Solaris and Debian, among others), then the package config directory (the default on HP-UX), for this parameter. The init script and startup script will look in the initconfigdir to find the init config file to source. For directory server, an instance specific file can be used, named e.g. dirsrv-localhost which will apply to the slapd-localhost instance only. A default init config file is provided for dirsrv and dirsrv-admin, with some examples of how it could be used. Platforms tested: RHEL5 x86_64 Flag Day: Yes - autotool file changes Doc impact: Yes. We will need to document how the user can supply environment to the servers at startup time without having to edit the init scripts or the startup scripts. QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none
Created attachment 218211 [details] cvs commit log - adminserver