Richard Megginson wrote:
> 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.
>
> }
>
>
Hi Richard,
I have upgraded yesterday the last of my ldap servers. The most
difficult problem there is described in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213626
And this problem with ownership and permission denied was reproduced
once more. I have screenlog of the session, and logs of admin and ldap
servers. Also I see a file /opt/fedora-ds/setup/myinstall.inf with the
following contents:
---
[General]
FullMachineName= <hostname>
SuiteSpotUserID= root
SuitespotGroup= root
ServerRoot= /opt/fedora-ds
ConfigDirectoryLdapURL= \ ldap://<hostname>.<domainname>:389/o=NetscapeRoot
ConfigDirectoryAdminID= admin
AdminDomain= <domainname>
ConfigDirectoryAdminPwd= <password>
[admin]
ServerAdminID= admin
ServerAdminPwd= <password>
SysUser= root
Port= 18080
ServerIpAddress=
---
Is this 'root' in [admin] part of this file connected to the problem?
I also attach a snippet from screen session log, with ip addresses,
passwords and host/domain names replaced.
--
With best regards,
Sergey Ivanov.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.txt
Url: http://lists.fedoraproject.org/pipermail/389-users/attachments/20061102/2a1134ff/attachment.txt
