Fedora directory users - Nov 2006 - Infinite loop during installation process

Hi all,

I am trying to set up a new FDS v1.0.3 install under RHEL4, adding this 
server to an existing configuration domain.

About half way through the install, I am asked if I would like to add 
sample entries to my server.

I say "No". The screen clears. After a while I press "enter"
to see if
there is any progress on the install. The screen clears again and the 
same "Do you want to install the sample entries?" appears.

I say "No". Rinse repeat.

Has anyone encountered this before? Is there a workaround for this? So 
far it seems the installer is terminally broken.

Regards,
Graham
--

Graham Leggett wrote:
> Hi all,
>
> I am trying to set up a new FDS v1.0.3 install under RHEL4, adding 
> this server to an existing configuration domain.
>
> About half way through the install, I am asked if I would like to add 
> sample entries to my server.
Choose Typical installation mode instead of Advanced or Express.  Then 
you should not get this question.
>
> I say "No". The screen clears. After a while I press
"enter" to see if
> there is any progress on the install. The screen clears again and the 
> same "Do you want to install the sample entries?" appears.
>
> I say "No". Rinse repeat.
>
> Has anyone encountered this before? Is there a workaround for this? So 
> far it seems the installer is terminally broken.
>
> Regards,
> Graham
> -- 
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

On Mon, November 6, 2006 4:21 am, Richard Megginson wrote:
>> About half way through the install, I am asked if I would like to add
>> sample entries to my server.
> Choose Typical installation mode instead of Advanced or Express.  Then
> you should not get this question.
I would if I could.

"Typical" installation mode assumes the name of the admin domain is
the
domain part of the machine name. If it''s not (in this case, it is not),
then setup goes through an infinite loop, asking for the configuration
directory details over and over again, rather than doing the most obvious
thing - ask for the name of the admin domain.

The only workaround at this point is to choose "advanced", but then
you
cannot get past the sample entries part.

As I said, seems the installer is terminally broken.

Regards,
Graham
--

Graham Leggett wrote:
> On Mon, November 6, 2006 4:21 am, Richard Megginson wrote:
>
>   
>>> About half way through the install, I am asked if I would like to
add
>>> sample entries to my server.
>>>       
>> Choose Typical installation mode instead of Advanced or Express.  Then
>> you should not get this question.
>>     
>
> I would if I could.
>
> "Typical" installation mode assumes the name of the admin domain
is the
> domain part of the machine name. If it''s not (in this case, it is
not),
> then setup goes through an infinite loop, asking for the configuration
> directory details over and over again, rather than doing the most obvious
> thing - ask for the name of the admin domain.
>
> The only workaround at this point is to choose "advanced", but
then you
> cannot get past the sample entries part.
>   
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214243

This will be fixed in FDS 1.0.4

The installer is written such that in Typical mode, the admin domain is 
hard coded.  So you have to use Custom/Advanced mode to enter
it.
> As I said, seems the installer is terminally broken.
>   
The last resort is to just create a silent install file and just use 
setup -s -f silent.inf - see 
http://directory.fedora.redhat.com/wiki/Install_Guide#inf_File_Format_for_core_directory_server_installation
> Regards,
> Graham
> --
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Richard Megginson wrote:
> The last resort is to just create a silent install file and just use 
> setup -s -f silent.inf - see 
>
http://directory.fedora.redhat.com/wiki/Install_Guide#inf_File_Format_for_core_directory_server_installation
A workaround I found was to roll back to v1.0.2, this at the very least 
gets the server installed.

The admin server on the new DS is toast though - it''s up and running 
(confirmed with telnet) but according to the console, the admin server 
is down. No explanation is given for how the admin console reaches this 
conclusion, so troubleshooting options are limited.

The trouble started when an attempt was made to install the security 
certificates on the machine, something that cannot be done during setup.

Keep getting this message:

org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: 
(-5938) Encountered end of file.

No idea what it means :(

Regards,
Graham
--

Graham Leggett wrote:
> Richard Megginson wrote:
>
>> The last resort is to just create a silent install file and just use 
>> setup -s -f silent.inf - see 
>>
http://directory.fedora.redhat.com/wiki/Install_Guide#inf_File_Format_for_core_directory_server_installation
>
>
> A workaround I found was to roll back to v1.0.2, this at the very 
> least gets the server installed.
>
> The admin server on the new DS is toast though - it''s up and
running
> (confirmed with telnet) but according to the console, the admin server 
> is down. No explanation is given for how the admin console reaches 
> this conclusion, so troubleshooting options are limited.
Can you confirm with your web browser?  Try both http:// and https://  
The admin server, unlike the DS, will only speak one protocol at a time, 
either http or https.
>
> The trouble started when an attempt was made to install the security 
> certificates on the machine, something that cannot be done during setup.
>
> Keep getting this message:
>
> org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: 
> (-5938) Encountered end of file.
When you attempt to start the console?
>
> No idea what it means :(
>
> Regards,
> Graham
> -- 
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Richard Megginson wrote:
> Can you confirm with your web browser?  Try both http:// and https://  
> The admin server, unlike the DS, will only speak one protocol at a time, 
> either http or https.
The admin server was configured http.
>> org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: 
>> (-5938) Encountered end of file.
> When you attempt to start the console?
It appears when an attempt is made to select "manage certificates",
and
a number of other places.

The cert8.db and key3.db files have been created successfully using 
certutil and pk12util (manage certificates refuses to run until these 
files are created manually, with the correct names, and certificates 
added manually to them).

It also happens when you click on the "encryption" tab inside the 
directory server configuration (after the server was reinstalled from 
scratch, and the cn=server.domain.com,o=NetscapeRoot had been manually 
deleted).

Regards,
Graham
--

Graham Leggett wrote:
> Richard Megginson wrote:
>
>> Can you confirm with your web browser?  Try both http:// and 
>> https://  The admin server, unlike the DS, will only speak one 
>> protocol at a time, either http or https.
>
> The admin server was configured http.
>
>>> org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: 
>>> (-5938) Encountered end of file.
>> When you attempt to start the console?
>
> It appears when an attempt is made to select "manage
certificates",
> and a number of other places.
I think this means it''s trying to talk SSL.  It could be attempting to 
open an https connection to the admin server which is only listening to 
http.  You could try starting the console using
startconsole -D 9 > file 2>&1
to capture the detailed debug log to file.  This should give us more 
information about what it''s doing when it gets that
exception.
>
> The cert8.db and key3.db files have been created successfully using 
> certutil and pk12util (manage certificates refuses to run until these 
> files are created manually, with the correct names, and certificates 
> added manually to them).
>
> It also happens when you click on the "encryption" tab inside the
> directory server configuration (after the server was reinstalled from 
> scratch, and the cn=server.domain.com,o=NetscapeRoot had been manually 
> deleted).
>
> Regards,
> Graham
> -- 
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Richard Megginson wrote:
>> It appears when an attempt is made to select "manage
certificates",
>> and a number of other places.
> I think this means it''s trying to talk SSL.  It could be
attempting to
> open an https connection to the admin server which is only listening to 
> http.  You could try starting the console using
> startconsole -D 9 > file 2>&1
> to capture the detailed debug log to file.  This should give us more 
> information about what it''s doing when it gets that exception.
Using tcplow to sniff the admin console port, the admin server is 
definitely trying to talk ssl.

Is there a method of telling the admin server _not_ to use SSL? I have 
searched high and low inside the directory, and all the config I can 
find has the admin server defined with SSL disabled.

Alternatively, is there a way to switch SSL on on the admin server 
without using the console?

Regards,
Graham
--

Is "passwordRetryCount" replicated in a multimaster setup?  Or, when
replication copies a "userPassword" change, is
"passwordRetryCount"
reset to 0 in the consumer, by the consumer?

I just helped a user whose retry count was 0 on one of our replicated
LDAPs, but stuck at maximum on the other, *after* multiple password
changes.  I didn''t think that would be possible!

Thanks,
Justin

Justin Crawford wrote:
> Is "passwordRetryCount" replicated in a multimaster setup?  Or,
when
> replication copies a "userPassword" change, is
"passwordRetryCount"
> reset to 0 in the consumer, by the consumer?
>
> I just helped a user whose retry count was 0 on one of our replicated
> LDAPs, but stuck at maximum on the other, *after* multiple password
> changes.  I didn''t think that would be possible!
>   
Are these read-only replicas or masters?  If you want password attempts 
to a read-only replica to be forwarded to other servers, you must use 
something like chaining of bind requests.  See 
http://directory.fedora.redhat.com/wiki/Howto:ChainOnUpdate
> Thanks,
> Justin
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Graham Leggett wrote:
> Richard Megginson wrote:
>
>>> It appears when an attempt is made to select "manage
certificates",
>>> and a number of other places.
>> I think this means it''s trying to talk SSL.  It could be
attempting
>> to open an https connection to the admin server which is only 
>> listening to http.  You could try starting the console using
>> startconsole -D 9 > file 2>&1
>> to capture the detailed debug log to file.  This should give us more 
>> information about what it''s doing when it gets that exception.
>
> Using tcplow to sniff the admin console port, the admin server is 
> definitely trying to talk ssl.
>
> Is there a method of telling the admin server _not_ to use SSL? I have 
> searched high and low inside the directory, and all the config I can 
> find has the admin server defined with SSL disabled.
>
> Alternatively, is there a way to switch SSL on on the admin server 
> without using the console?
1) edit admin-serv/config/console.conf and change NSSEngine from "on"
to
"off"
2) find the cn=configuration entry for the admin server:
ldapsearch -x -D "cn=directory manager" -w password -s sub -b 
o=netscaperoot "nsserversecurity=on"
3) If this returns the config entry for the admin server, use ldapmodify 
to turn security off:
ldapmodify -x -D "cn=directory manager" -w password
dn: dn returned above
changetype: modify
replace: nsServerSecurity
nsServerSecurity: off

4) restart admin server - restart-admin

This should cause admin server to use http instead of
https.
>
> Regards,
> Graham
> -- 
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

> 
> Justin Crawford wrote:
> > Is "passwordRetryCount" replicated in a multimaster setup?  
> Or, when 
> > replication copies a "userPassword" change, is
"passwordRetryCount"
> > reset to 0 in the consumer, by the consumer?
> >
> > I just helped a user whose retry count was 0 on one of our 
> replicated 
> > LDAPs, but stuck at maximum on the other, *after* multiple password 
> > changes.  I didn''t think that would be possible!
> >   
> Are these read-only replicas or masters?  
These are both masters in a multimaster setup.  Changing the password on
ldap1 changes the password and passwordExpirationTime on ldap2.  But
passwordRetryCount on ldap2 remains unchanged.  I''ve usually seen
passwordRetryCount reset to 0 when userPassword changes, no matter how
the password change occurs.  Is it different with multimaster
replication?

Richard Megginson wrote:
> 1) edit admin-serv/config/console.conf and change NSSEngine from
"on" to
> "off"
> 2) find the cn=configuration entry for the admin server:
> ldapsearch -x -D "cn=directory manager" -w password -s sub -b 
> o=netscaperoot "nsserversecurity=on"
> 3) If this returns the config entry for the admin server, use ldapmodify 
> to turn security off:
> ldapmodify -x -D "cn=directory manager" -w password
> dn: dn returned above
> changetype: modify
> replace: nsServerSecurity
> nsServerSecurity: off
> 
> 4) restart admin server - restart-admin
> 
> This should cause admin server to use http instead of https.
In this case the admin server was already http.

I tried to switch the admin server SSL on, by manually editing the 
directory.

Now the admin server won''t start at all, and no error message is logged
to the console or error log.

A couple of questions at this point:

- How does the console know whether to contact the admin server using 
SSL or clear?

- How do you reset the state of the console entirely?

In the case of the admin server:

- Which files in the config directory can be edited by a human and have 
an actual effect?

- How do you refresh the files in the config directory, so that they 
reflect changes you''ve made in the directory itself?

- How do you completely and entirely flush a server out of the directory 
and the console so that you can start the process from scratch yet again?

Regards,
Graham
--

Justin Crawford wrote:
>> Justin Crawford wrote:
>>     
>>> Is "passwordRetryCount" replicated in a multimaster
setup?
>>>       
>> Or, when 
>>     
>>> replication copies a "userPassword" change, is
"passwordRetryCount"
>>> reset to 0 in the consumer, by the consumer?
>>>
>>> I just helped a user whose retry count was 0 on one of our 
>>>       
>> replicated 
>>     
>>> LDAPs, but stuck at maximum on the other, *after* multiple password
>>> changes.  I didn''t think that would be possible!
>>>   
>>>       
>> Are these read-only replicas or masters?  
>>     
>
> These are both masters in a multimaster setup.  Changing the password on
> ldap1 changes the password and passwordExpirationTime on ldap2.  But
> passwordRetryCount on ldap2 remains unchanged.  I''ve usually seen
> passwordRetryCount reset to 0 when userPassword changes, no matter how
> the password change occurs.  Is it different with multimaster
> replication?
>   
Yes.  You have to enable global password policy.  By default, password 
policy is local to each host.  You have to enable global password policy 
to replicate the password policy op attrs.
In the entry cn=config, set the attribute passwordisglobalpolicy to the 
value "on".
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Graham Leggett wrote:
> Richard Megginson wrote:
>
>> 1) edit admin-serv/config/console.conf and change NSSEngine from
"on"
>> to "off"
>> 2) find the cn=configuration entry for the admin server:
>> ldapsearch -x -D "cn=directory manager" -w password -s sub -b
>> o=netscaperoot "nsserversecurity=on"
>> 3) If this returns the config entry for the admin server, use 
>> ldapmodify to turn security off:
>> ldapmodify -x -D "cn=directory manager" -w password
>> dn: dn returned above
>> changetype: modify
>> replace: nsServerSecurity
>> nsServerSecurity: off
>>
>> 4) restart admin server - restart-admin
>>
>> This should cause admin server to use http instead of https.
>
> In this case the admin server was already http.
>
> I tried to switch the admin server SSL on, by manually editing the 
> directory.
>
> Now the admin server won''t start at all, and no error message is 
> logged to the console or error log.
There''s more to making it use ssl than disabling ssl.  The easiest way 
is to use the script at 
http://directory.fedora.redhat.com/wiki/Howto:SSL to generate the 
keys/certs, then use the console.  You first have to go to 
Directory->Configuration->Data->Security and check the button that
tells
the console to use SSL.  Then, go to Admin 
Server->Configuration->Security and tell Admin Server to use
SSL.
>
> A couple of questions at this point:
>
> - How does the console know whether to contact the admin server using 
> SSL or clear?
It should go off the url you specify when using startconsole, either 
http or https.
>
> - How do you reset the state of the console entirely?
>
> In the case of the admin server:
>
> - Which files in the config directory can be edited by a human and 
> have an actual effect?
Only local.conf is read-only.  It is basically a cache of the 
information under the admin server instance entry under o=NetscapeRoot.

http://directory.fedora.redhat.com/wiki/AdminServer#Admin_Server_Config_Files
>
> - How do you refresh the files in the config directory, so that they 
> reflect changes you''ve made in the directory itself?
The surest way to make the Admin Server refresh its config based on 
changes made in the DS is to restart the admin server.
>
> - How do you completely and entirely flush a server out of the 
> directory and the console so that you can start the process from 
> scratch yet again?
>
> Regards,
> Graham
> -- 
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Richard Megginson wrote:
>> Now the admin server won''t start at all, and no error message
is
>> logged to the console or error log.
> There''s more to making it use ssl than disabling ssl.  The easiest
way
> is to use the script at 
> http://directory.fedora.redhat.com/wiki/Howto:SSL to generate the 
> keys/certs, then use the console.  You first have to go to 
> Directory->Configuration->Data->Security and check the button that
tells
> the console to use SSL.  Then, go to Admin 
> Server->Configuration->Security and tell Admin Server to use SSL.
Trouble is, if you''ve made the smallest config error, the console is 
left in a corrupt state. There seems to be no way to correct an error 
once its been made.

I managed to get this right once, then made a config error somewhere, 
and the directory config for this member of the cluster has been corrupt 
ever since.
>> A couple of questions at this point:
>>
>> - How does the console know whether to contact the admin server using 
>> SSL or clear?
> It should go off the url you specify when using startconsole, either 
> http or https.
Ok... the URL I used in startconsole pointed at the configuration 
directory''s admin server, not the new admin server I am trying to set
up.

Is the startconsole somehow assuming that because the admin server 
belonging to the configuration directory is secure, then all other admin 
servers are secure too?

Should I point startconsole at the new admin server, rather than the 
configuration admin server, when I want to edit the new admin server?
>> - Which files in the config directory can be edited by a human and 
>> have an actual effect?
> Only local.conf is read-only.  It is basically a cache of the 
> information under the admin server instance entry under o=NetscapeRoot.
> 
>
http://directory.fedora.redhat.com/wiki/AdminServer#Admin_Server_Config_Files
If I delete all the files in the admin server config directory, will the 
restart-admin script rebuild these files from the directory?
>> - How do you refresh the files in the config directory, so that they 
>> reflect changes you''ve made in the directory itself?
> The surest way to make the Admin Server refresh its config based on 
> changes made in the DS is to restart the admin server.
The behaviour I was seeing was that after modifying the directory and 
restarting the admin server, the only file that changed was local.conf.

All other files remained untouched, meaning that despite the directory 
having been modified, the admin server did not pick up the changes.

Regards,
Graham
--

Graham Leggett wrote:
> Richard Megginson wrote:
>
>>> Now the admin server won''t start at all, and no error
message is
>>> logged to the console or error log.
>> There''s more to making it use ssl than disabling ssl.  The
easiest
>> way is to use the script at 
>> http://directory.fedora.redhat.com/wiki/Howto:SSL to generate the 
>> keys/certs, then use the console.  You first have to go to 
>> Directory->Configuration->Data->Security and check the button
that
>> tells the console to use SSL.  Then, go to Admin 
>> Server->Configuration->Security and tell Admin Server to use SSL.
>
> Trouble is, if you''ve made the smallest config error, the console
is
> left in a corrupt state. There seems to be no way to correct an error 
> once its been made.
Yes, this is poorly documented, and scattered about in a half dozen 
config files, as well as several entries under
o=netscaperoot
>
> I managed to get this right once, then made a config error somewhere, 
> and the directory config for this member of the cluster has been 
> corrupt ever since.
>
>>> A couple of questions at this point:
>>>
>>> - How does the console know whether to contact the admin server 
>>> using SSL or clear?
>> It should go off the url you specify when using startconsole, either 
>> http or https.
>
> Ok... the URL I used in startconsole pointed at the configuration 
> directory''s admin server, not the new admin server I am trying to
set up.
>
> Is the startconsole somehow assuming that because the admin server 
> belonging to the configuration directory is secure, then all other 
> admin servers are secure too?
No, once it uses the url you type in to bootstrap, it reads the security 
settings for the other servers from the config ds
o=netscaperoot.
>
> Should I point startconsole at the new admin server, rather than the 
> configuration admin server, when I want to edit the new admin server?
You could try that.
>
>>> - Which files in the config directory can be edited by a human and 
>>> have an actual effect?
>> Only local.conf is read-only.  It is basically a cache of the 
>> information under the admin server instance entry under o=NetscapeRoot.
>>
>>
http://directory.fedora.redhat.com/wiki/AdminServer#Admin_Server_Config_Files
>
>
> If I delete all the files in the admin server config directory, will 
> the restart-admin script rebuild these files from the directory?
No.  Only local.conf will be rebuilt.
>
>>> - How do you refresh the files in the config directory, so that
they
>>> reflect changes you''ve made in the directory itself?
>> The surest way to make the Admin Server refresh its config based on 
>> changes made in the DS is to restart the admin server.
>
> The behaviour I was seeing was that after modifying the directory and 
> restarting the admin server, the only file that changed was local.conf.
Right.  console.conf, adm.conf, and shared/config/dbswitch.conf are 
modified via console operations, via CGI programs.  They are not 
modified via LDAP operations, and the admin server + console code has to 
jump through some hoops to keep the data stored in LDAP in sync with the 
corresponding data in those config files.
>
> All other files remained untouched, meaning that despite the directory 
> having been modified, the admin server did not pick up the changes.
>
> Regards,
> Graham
> -- 
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users