[Fedora-directory-users] Problems Setting up 1.0.3
Richard Megginson
rmeggins at redhat.com
Tue Oct 31 21:21:19 UTC 2006
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.
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20061031/730f994b/attachment.bin>
More information about the Fedora-directory-users
mailing list