[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