Bug 190222 - setup/upgrade fails if password syntax checking is on
setup/upgrade fails if password syntax checking is on
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Install/Uninstall (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Viktor Ashirov
:
Depends On:
Blocks: 152373 240316 FDS1.1.0
  Show dependency treegraph
 
Reported: 2006-04-28 17:38 EDT by Rich Megginson
Modified: 2015-12-07 11:51 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 11:51:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output from user (4.23 KB, text/plain)
2006-04-28 17:38 EDT, Rich Megginson
no flags Details

  None (edit)
Description Rich Megginson 2006-04-28 17:38:37 EDT
Apparently something during upgrade install tries to change the password?
Comment 1 Rich Megginson 2006-04-28 17:38:37 EDT
Created attachment 128380 [details]
output from user
Comment 2 Noriko Hosoi 2006-06-20 21:25:13 EDT
My test result is actually worse... :)
I installed 7.2 and upgraded it to 7.2 (identical), then "ds_create -r -f
<inffile>" crashed because in the upgrade case, the section for [slapd] in the
inffile is just 2 lines w/o any useful info for the DS instance:
  [slapd]
  Components=   slapd,slapd-client

Ds_create expects to go through the slapd instances, which are not available due
to the above reason.
#0  0x0804d72f in sanity_check (cf=0xbfecd1f0, param_name=0xbfeccd90 "")
    at create_instance.c:456
456         for(x=0; cf->servid[x]; x++)  {
(gdb) bt
#0  0x0804d72f in sanity_check (cf=0xbfecd1f0, param_name=0xbfeccd90 "")
    at create_instance.c:456
#1  0x0804e946 in update_server (cf=0xbfecd1f0) at create_instance.c:1404
#2  0x0804c9ff in main (argc=4, argv=0xbfecd344) at instindex.cpp:142
Current language:  auto; currently c
(gdb) p cf->servid
$1 = 0x0

I know this problem was introduced with the fix for [185364].
To fix this crash problem, we somehow need to gather slapd info either from the
user input or dse.ldif.  The problem for the latter would be the Directory
Manager password, which cannot be retrieved from dse.ldif.

It's ugly, but could it be acceptable to add some code in the script ns-update
when it's running as upgrade mode to ask for the Directory Manager password,
then add the necessary info to the inf file?  Also, when multiple DS instances
need to be upgraded, it's not supported for now (see [185364]).  It'd be nice
that ns-update handles the case, too.

I added complete info to the <inffile>, then ran ds_create -r with the file. 
Then, ds_create itself was successfully finished. 
  $ ./ds_create -r -f  /tmp/upgrade.inf
  Start Slapd Starting Slapd server reconfiguration.
  Info Slapd No old nsperl references found

The last message "No old nsperl references found" makes me puzzled, though. 
There should be some nsperl ghost hiding...
Comment 3 Rich Megginson 2006-06-20 23:11:27 EDT
What information does ds_create need?  We ask the user for the admin
user/password during upgrade - could we use that instead of the dirmgr password?

We should get rid of that nsperl stuff . . .
Comment 4 Noriko Hosoi 2006-06-21 12:17:50 EDT
I guess we need both passwords: admin user and dirmgr.
If there are multiple DS instances, we need the dirmgr password for each...

I'm going to investigate who is still referring nsperl. :)

Note You need to log in before you can comment on or make changes to this bug.