Fedora directory users - Oct 2006 - Problems Setting up 1.0.3

Stephen C. Rigler wrote:
> I''m attempting to install 1.0.3 on an x86_64 machine running
CentOS 4.4.
> Once the rpm is installed, I run the setup script, answer the questions
> and then the setup script does nothing (currently it''s sitting at
a

Some problems here as well:


[slapd-netauth]: starting up server ...
[slapd-netauth]:        Fedora-Directory/1.0.3 B2006.303.1848
[slapd-netauth]:        laptop.netauth.com:389 
(/opt/fedora-ds/slapd-netauth)
[slapd-netauth]:
[slapd-netauth]: [31/Oct/2006:20:50:57 +0200] - Fedora-Directory/1.0.3 
B2006.303.1848 starting up
[slapd-netauth]: [31/Oct/2006:20:50:57 +0200] - slapd started. 
Listening on All Interfaces port 389 for LDAP requests

NMC_Status: 0
NMC_Description: Success! The server has been started.

Start Slapd Starting Slapd server reconfiguration.
Fatal Slapd ERROR: Could not find Directory Server Configuration
URL ldap://laptop.netauth.com:389/o=NetscapeRoot user id admin DN 
cn=laptop.netauth.com, ou=netauth.com, o=NetscapeRoot (153:Unknown error)
Configuring Administration Server...
InstallInfo: Apache Directory "ApacheDir" is missing.
/opt/fedora-ds/slapd-netauth/config/dse.ldif: SSL on ...
Restarting Directory Server: /opt/fedora-ds/slapd-netauth/start-slapd
Server failed to start !!! Please check errors log for problems

You can now use the console.  Here is the command to use to start the 
console:
cd /opt/fedora-ds
./startconsole -u admin -a http://laptop.netauth.com:1500/

INFO Finished with setup, logfile is setup/setup.log


hmm....


--
mike

I''m attempting to install 1.0.3 on an x86_64 machine running CentOS
4.4.
Once the rpm is installed, I run the setup script, answer the questions
and then the setup script does nothing (currently it''s sitting at a
screen that says "Fedora Project Directory
Installation/Uninstallation"
and nothing else).

I can see the following processes:

root      4916  4820  0 11:07 pts/0    00:00:00 /bin/sh /opt/fedora-
ds/setup/setup
root      5004  4916  0 11:07 pts/0    00:00:00 ./ns-config -
f /tmp/setupyd4964 -l /tmp/logMS4919 -m 3

I''m not sure what else to look for at this point.  I had previously
been
running 1.0.2 on this machine without any issues.

Thanks,
Steve

Stephen C. Rigler wrote:
> I''m attempting to install 1.0.3 on an x86_64 machine running
CentOS 4.4.
> Once the rpm is installed, I run the setup script, answer the questions
> and then the setup script does nothing (currently it''s sitting at
a
> screen that says "Fedora Project Directory
Installation/Uninstallation"
> and nothing else).
>
> I can see the following processes:
>
> root      4916  4820  0 11:07 pts/0    00:00:00 /bin/sh /opt/fedora-
> ds/setup/setup
> root      5004  4916  0 11:07 pts/0    00:00:00 ./ns-config -
> f /tmp/setupyd4964 -l /tmp/logMS4919 -m 3
>
> I''m not sure what else to look for at this point.  I had
previously been
> running 1.0.2 on this machine without any issues.
>   
try strace -p 5004

Maybe it''s waiting for input?  Also do tail /tmp/logMS4919 to see if it
has printed a prompt that looks like it is waiting for
input.
> Thanks,
> Steve
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

On Tue, 2006-10-31 at 12:01 -0700, Richard Megginson
wrote:
>   
> try strace -p 5004
> 
> Maybe it''s waiting for input?  Also do tail /tmp/logMS4919 to see
if it
> has printed a prompt that looks like it is waiting for input.
It looks like it is waiting for input.  When I hit <enter> it brings me
back to the prompt asking if I want to install sample entries.  However,
it seems to be stuck in a loop because any answer brings me back to the
same prompt.

-Steve

Stephen C. Rigler wrote:
> On Tue, 2006-10-31 at 12:01 -0700, Richard Megginson wrote:
>   
>>   
>> try strace -p 5004
>>
>> Maybe it''s waiting for input?  Also do tail /tmp/logMS4919 to
see if it
>> has printed a prompt that looks like it is waiting for input.
>>     
>
> It looks like it is waiting for input.  When I hit <enter> it brings
me
> back to the prompt asking if I want to install sample entries.  However,
> it seems to be stuck in a loop because any answer brings me back to the
> same prompt.
>   
Hmm - what install mode did you choose?  Sounds like you chose Advanced 
- try it again with Typical.
> -Steve
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

On Tue, 2006-10-31 at 13:02 -0700, Richard Megginson wrote:
> > It looks like it is waiting for input.  When I hit <enter> it
brings me
> > back to the prompt asking if I want to install sample entries. 
However,
> > it seems to be stuck in a loop because any answer brings me back to
the
> > same prompt.
> >   
> Hmm - what install mode did you choose?  Sounds like you chose Advanced 
> - try it again with Typical.
Tried it with "typical" and it''s working now.  Thanks!

-Steve

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.
-- 
	Sergey.

Mike Jackson wrote:
> Start Slapd Starting Slapd server reconfiguration.
> Fatal Slapd ERROR: Could not find Directory Server Configuration
> URL ldap://laptop.netauth.com:389/o=NetscapeRoot user id admin DN
> cn=laptop.netauth.com, ou=netauth.com, o=NetscapeRoot (153:Unknown error)
> Configuring Administration Server...
> InstallInfo: Apache Directory "ApacheDir" is missing.
> /opt/fedora-ds/slapd-netauth/config/dse.ldif: SSL on ...
> Restarting Directory Server: /opt/fedora-ds/slapd-netauth/start-slapd
> Server failed to start !!! Please check errors log for problems
>

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.

}

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.

Sergey Ivanov wrote:
> 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
>   
This is a great clue.  The setup script uses the following command to 
determine these values:
        suitespotuser=`ls -l 
/opt/fedora-ds/slapd-instance/config/dse.ldif | awk ''{print
$3}''`
        suitespotgroup=`ls -l 
/opt/fedora-ds/slapd-instance/config/dse.ldif | awk ''{print
$4}''`
So somehow the ownership of dse.ldif was changed from nobody:nobody to 
root:root.  Either that, or the above command is not working.  Is it 
possible that it is not using /bin/ls?
> 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.
>   
> ------------------------------------------------------------------------
>
> [root@<hostname> fedora-ds]# netstat -tlpn |grep 636
> tcp        0      0 ::ffff:10.0.0.<ip>:636      :::*                 
LISTEN      15481/ns-slapd
> [root@<hostname> fedora-ds]# netstat -tlpn |grep 389
> tcp        0      0 ::ffff:10.0.0.<ip>:389      :::*                 
LISTEN      15481/ns-slapd
> [root@<hostname> opt]# rpm -Uvh
/data/users/seriv/fedora-ds/downloads/fedora-ds-1.0.3-1.RHEL4.x86_64.opt.rpm
> Preparing...                ###########################################
[100%]
>         package fedora-ds-1.0.3-1.RHEL4 is already installed
> [root@<hostname> opt]# rpm -Uvh
/data/users/seriv/fedora-ds/downloads/fedora-ds-1.0.3-1.RHEL4.x86_64.opt.rpm
--force
> Preparing...                ###########################################
[100%]
>    1:fedora-ds              ###########################################
[100%]
>
> Upgrade finished.  Please run /opt/fedora-ds/setup/setup to complete the
upgrade.
> [root@<hostname> opt]# netstat -tlpn |grep 636
> [root@<hostname> opt]# netstat -tlpn |grep 389
> [root@<hostname> opt]# pwd
> /opt
> [root@<hostname> opt]# cd fedora-ds
> [root@<hostname> fedora-ds]# setup/setup
> INFO Begin Setup . . .
>
>
>
> LICENSE AGREEMENT AND LIMITED PRODUCT WARRANTY
> FEDORA(TM) DIRECTORY SERVER
> [contents skipped]
>
> Do you accept the license terms? (yes/no) yes
> ======================================================================> 
Fedora Directory Server 1.0.3
> ======================================================================>
> The Fedora Directory Server is subject to the terms detailed in the
> license agreement file called LICENSE.txt.
>
> Late-breaking news and information on the Fedora Directory Server is
> available at the following location:
>
>     http://directory.fedora.redhat.com
>
> Continue? (yes/no) yes
> No ns-slapd PID file found. Server is probably not running
> /opt/fedora-ds/slapd-<hostname>/config/dse.ldif: SSL off ...
> In order to reconfigure your installation, the Configuration Directory
> Administrator password is required.  Here is your current information:
>
> Configuration Directory:
ldap://<hostname>.<domainname>:389/o=NetscapeRoot
> Configuration Administrator ID: admin
>
> At the prompt, please enter the password for the Configuration
Administrator.
>
> administrator ID: admin
> Password: <password>
> Converting slapd-<hostname> to new format password file . . .
> Copying new schema ldiffiles . . .
> Starting slapd-<hostname> . . .
>
> [slapd-<hostname>]: starting up server ...
> [slapd-<hostname>]: [01/Nov/2006:22:36:26 -0500] -
Fedora-Directory/1.0.3 B2006.303.1845 starting up
> [slapd-<hostname>]: [01/Nov/2006:22:36:26 -0500]
NSMMReplicationPlugin - agmt="cn=ballexta" (<hostname>:389):
Simple bind failed, LDAP sdk error 91 (Can''t connect to the LDAP
server), Netscape Portable Runtime error -5961 (TCP connection reset by peer.)
> [slapd-<hostname>]: [01/Nov/2006:22:36:26 -0500] - slapd started. 
Listening on 10.0.0.<ip> port 389 for LDAP requests
>
> NMC_Status: 0
> NMC_Description: Success! The server has been started.
>
> Start Slapd Starting Slapd server reconfiguration.
> Fatal Slapd ERROR: Could not find Directory Server Configuration
> URL ldap://<hostname>.<domainname>:389/o=NetscapeRoot user id
admin DN cn=<hostname>.<domainname>, ou=<domainname>,
o=NetscapeRoot (153:Unknown error)
> Configuring Administration Server...
> InstallInfo: Apache Directory "ApacheDir" is missing.
> /opt/fedora-ds/slapd-<hostname>/config/dse.ldif: SSL on ...
> Restarting Directory Server:
/opt/fedora-ds/slapd-<hostname>/start-slapd
> Server failed to start !!! Please check errors log for problems
>
> You can now use the console.  Here is the command to use to start the
console:
> cd /opt/fedora-ds
> ./startconsole -u admin -a
http://<hostname>.<domainname>:18080/
>
> INFO Finished with setup, logfile is setup/setup.log
> [root@<hostname> fedora-ds]# netstat -tlpn |grep 636
> [root@<hostname> fedora-ds]# netstat -tlpn |grep 389
> [root@<hostname> fedora-ds]# slapd-<hostname>/restart-slapd
> No ns-slapd PID file found. Server is probably not running
> Server failed to start !!! Please check errors log for problems
> [root@<hostname> fedora-ds]# tail -n 22
slapd-<hostname>/logs/errors
> [01/Nov/2006:22:34:31 -0500] - slapd shutting down - closing down internal
subsystems and plugins
> [01/Nov/2006:22:34:35 -0500] - Waiting for 4 database threads to stop
> [01/Nov/2006:22:34:36 -0500] - All database threads now stopped
> [01/Nov/2006:22:34:38 -0500] - slapd stopped.
> [01/Nov/2006:22:36:26 -0500] - Fedora-Directory/1.0.3 B2006.303.1845
starting up
> [01/Nov/2006:22:36:26 -0500] NSMMReplicationPlugin -
agmt="cn=ballexta" (<hostname>:389): Simple bind failed, LDAP
sdk error 91 (Can''t connect to the LDAP server), Net
> scape Portable Runtime error -5961 (TCP connection reset by peer.)
> [01/Nov/2006:22:36:26 -0500] - slapd started.  Listening on
10.0.0.<ip> port 389 for LDAP requests
> [01/Nov/2006:22:36:27 -0500] - slapd shutting down - signaling operation
threads
> [01/Nov/2006:22:36:27 -0500] - slapd shutting down - waiting for 29 threads
to terminate
> [01/Nov/2006:22:36:27 -0500] - slapd shutting down - closing down internal
subsystems and plugins
> [01/Nov/2006:22:36:27 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:28 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:29 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:30 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:31 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:32 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:32 -0500] - Waiting for 4 database threads to stop
> [01/Nov/2006:22:36:33 -0500] - All database threads now stopped
> [01/Nov/2006:22:36:33 -0500] - slapd stopped.
> [01/Nov/2006:22:36:34 -0500] - Fedora-Directory/1.0.3 B2006.303.1845
starting up
> [01/Nov/2006:22:36:34 -0500] dse - Cannot copy DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif" to
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.startOK" OS
>  error 17 (File exists)
> [01/Nov/2006:22:37:08 -0500] - Fedora-Directory/1.0.3 B2006.303.1845
starting up
> [01/Nov/2006:22:37:08 -0500] dse - Cannot copy DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif" to
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.startOK" OS
>  error 17 (File exists)
> [root@<hostname> fedora-ds]# ls -al slapd-<hostname>/config/
> total 424
> drwxr-xr-x   4 root   root    4096 Nov  1 22:37 .
> drwxr-xr-x  12 nobody root    4096 Nov  1 22:37 ..
> -rw-r--r--   1 nobody root   57967 Nov  1 22:36 dse.ldif
> -rw-r--r--   2 nobody root   57969 Nov  1 22:36 dse.ldif.bak
> -rw-r--r--   2 nobody root   57969 Nov  1 22:36 dse.ldif.startOK
> -rw-------   1 nobody root   33781 Aug 29 11:17 dse_original.ldif
> drwxr-xr-x   2 nobody root    4096 Nov  1 22:37 schema
> drwxr-xr-x   2 nobody root    4096 Nov  1 01:43 schema-bak
> -rw-r--r--   1 nobody root    5400 Aug 29 11:17 slapd-collations.conf
> [root@<hostname> fedora-ds]# chown nobody
slapd-<hostname>/config
> [root@<hostname> fedora-ds]# mv
slapd-<hostname>/config/dse.ldif.startOK .
> [root@<hostname> fedora-ds]# slapd-<hostname>/restart-slapd
> No ns-slapd PID file found. Server is probably not running
> Server failed to start !!! Please check errors log for problems
> [root@<hostname> fedora-ds]# tail -n 22
slapd-<hostname>/logs/errors
> [01/Nov/2006:22:36:26 -0500] - Fedora-Directory/1.0.3 B2006.303.1845
starting up
> [01/Nov/2006:22:36:26 -0500] NSMMReplicationPlugin -
agmt="cn=ballexta" (<hostname>:389): Simple bind failed, LDAP
sdk error 91 (Can''t connect to the LDAP server), Net
> scape Portable Runtime error -5961 (TCP connection reset by peer.)
> [01/Nov/2006:22:36:26 -0500] - slapd started.  Listening on
10.0.0.<ip> port 389 for LDAP requests
> [01/Nov/2006:22:36:27 -0500] - slapd shutting down - signaling operation
threads
> [01/Nov/2006:22:36:27 -0500] - slapd shutting down - waiting for 29 threads
to terminate
> [01/Nov/2006:22:36:27 -0500] - slapd shutting down - closing down internal
subsystems and plugins
> [01/Nov/2006:22:36:27 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:28 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:29 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:30 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:31 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:32 -0500] dse - Cannot open temporary DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.tmp" for
update: OS error 13 (Permission denied)
> [01/Nov/2006:22:36:32 -0500] - Waiting for 4 database threads to stop
> [01/Nov/2006:22:36:33 -0500] - All database threads now stopped
> [01/Nov/2006:22:36:33 -0500] - slapd stopped.
> [01/Nov/2006:22:36:34 -0500] - Fedora-Directory/1.0.3 B2006.303.1845
starting up
> [01/Nov/2006:22:36:34 -0500] dse - Cannot copy DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif" to
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.startOK" OS
>  error 17 (File exists)
> [01/Nov/2006:22:37:08 -0500] - Fedora-Directory/1.0.3 B2006.303.1845
starting up
> [01/Nov/2006:22:37:08 -0500] dse - Cannot copy DSE file
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif" to
"/opt/fedora-ds/slapd-<hostname>/config/dse.ldif.startOK" OS
>  error 17 (File exists)
> [01/Nov/2006:22:38:49 -0500] - Fedora-Directory/1.0.3 B2006.303.1845
starting up
> [root@<hostname> fedora-ds]# netstat -tlpn |grep 389
> [root@<hostname> fedora-ds]# netstat -tlpn |grep 636
> [root@<hostname> fedora-ds]# ls -al slapd-<hostname>/logs/
> total 32468
> drwx------   2 root   root       4096 Nov  1 22:36 .
> drwxr-xr-x  12 nobody root       4096 Nov  1 22:38 ..
> -rw-------   1 nobody root   33124743 Nov  1 22:36 access
> -rw-------   1 nobody root         63 Oct 31 23:40 access.rotationinfo
> -rw-------   1 nobody root          0 Oct 31 23:40 audit
> -rw-------   1 nobody root         63 Oct 31 23:40 audit.rotationinfo
> -rw-------   1 nobody root      18211 Nov  1 22:38 errors
> -rw-------   1 nobody root         63 Oct 31 23:40 errors.rotationinfo
> -rw-r--r--   1 nobody nobody     1952 Nov  1 22:36 slapd.stats
> [root@<hostname> fedora-ds]# chown nobody:nobody
slapd-<hostname>/logs
> [root@<hostname> fedora-ds]# chown nobody:nobody
slapd-<hostname>/logs/*
> [root@<hostname> fedora-ds]# slapd-<hostname>/restart-slapd
> No ns-slapd PID file found. Server is probably not running
> [root@<hostname> fedora-ds]# netstat -tlpn |grep 636
> tcp        0      0 ::ffff:10.0.0.<ip>:636      :::*                 
LISTEN      15481/ns-slapd
> [root@<hostname> fedora-ds]# netstat -tlpn |grep 389
> tcp        0      0 ::ffff:10.0.0.<ip>:389      :::*                 
LISTEN      15481/ns-slapd
>   
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Richard Megginson wrote:
> Sergey Ivanov wrote:
[skip]
>> 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
>>   
> This is a great clue.  The setup script uses the following command to
> determine these values:
>        suitespotuser=`ls -l
> /opt/fedora-ds/slapd-instance/config/dse.ldif | awk ''{print
$3}''`
>        suitespotgroup=`ls -l
> /opt/fedora-ds/slapd-instance/config/dse.ldif | awk ''{print
$4}''`
> So somehow the ownership of dse.ldif was changed from nobody:nobody to
> root:root.  Either that, or the above command is not working.  Is it
> possible that it is not using /bin/ls?
Not looking like this. I did at this host:
---
# which ls
alias ls=''ls --color=tty''
        /bin/ls
# ls -l /opt/fedora-ds/slapd-instance/config/dse.ldif | awk ''{print
$3}''
nobody
# ls -l /opt/fedora-ds/slapd-instance/config/dse.ldif | awk ''{print
$4}''
nobody
May be, ownership was changed to root''s in rpm -Uvh or in the very
first
steps of setup/setup.
-- 
	Sergey.


[skip]

It appears that the permission problem only happens with servers that 
were configured to use SSL in fds102 and upgraded to fds103.  Can anyone 
confirm the problem occurred in a system not using SSL?

Rich--

As I mentioned on IRC, I got about 90% of the way through the SSL
setup before my deadline hit and I had to go live without SSL fully
working.  My machines are all listening on port 636, but don''t do SSL
properly.  As far as I can tell/remember, I provisioned the boxes
identically, so they all should be equally far along in the
SSL-enabling process, but only one of them demonstrated the
permissions problem.

I guess you did say, though, that the problem _only_ happens to
SSL-enabled machines, not that it _always_ happens to SSL-enabled
machines.  Still, hope this helps you root out the problem.

Good luck!

Chris St. Pierre
Unix Systems Administrator
Nebraska Wesleyan University

On Thu, 2 Nov 2006, Richard Megginson wrote:
> It appears that the permission problem only happens with servers that were
> configured to use SSL in fds102 and upgraded to fds103.  Can anyone confirm
the
> problem occurred in a system not using SSL?
>