Sergey Ivanov wrote:
For me it was a problem with ownership of directories in
/opt/fedora-ds/slapd-<name>/ tree. logs, locks and config ownership was
changed by upgrade process to root. So the ns-slpad process was unable
to start. Also the file
/opt/fedora-ds/slapd-<name>/config/dse.ldif.startOK was there in the
way, being unable to deleted, - lack of permissions.
Very odd. It doesn't appear that setup does this, the chown is done in
the server itself:
main.c:
fix_ownership()
{
struct passwd* pw=NULL;
char dirname[MAXPATHLEN + 1];
slapdFrontendConfig_t *slapdFrontendConfig = getFrontendConfig();
if ( slapdFrontendConfig->localuser != NULL ) {
if ( (pw = getpwnam( slapdFrontendConfig->localuser )) ==
NULL )
return;
localuser should be "nobody" or the uid of the server user. So one
possible problem is that if this is set to "root" for some reason.
}
else {
return;
}
/* The instance directory needs to be owned by the local user */
slapd_chown_if_not_owner( slapdFrontendConfig->instancedir,
pw->pw_uid, -1 );
instancedir is "/opt/fedora-ds/slapd-instance"
PR_snprintf(dirname,sizeof(dirname),"%s/config",slapdFrontendConfig->instancedir);
chown_dir_files(dirname, pw, PR_FALSE); /* config directory */
chown_dir_files(slapdFrontendConfig->accesslog, pw, PR_TRUE); /* do
access log directory */
chown_dir_files(slapdFrontendConfig->auditlog, pw, PR_TRUE); /* do
audit log directory */
chown_dir_files(slapdFrontendConfig->errorlog, pw, PR_TRUE); /* do
error log directory */
chown_dir_files chowns the directory and all of the files in it (does
not recurse). If given a file name, it will strip off the file name
(PR_TRUE).
It would appear that the only way this can happen is if either
slapdFrontendConfig->localuser is "root" or getpwnam(
slapdFrontendConfig->localuser ) returns uid 0. If someone can come up
with a reproducible test case, please let me know. So far, I've just
done simple fds102 install followed by upgrade to fds103 on RHEL4 using
the default values. I cannot reproduce this problem.
}