Bug 243205 - allow instance creation with no .inf file; allow pre-hashed RootDNPwd
allow instance creation with no .inf file; allow pre-hashed RootDNPwd
Status: CLOSED ERRATA
Product: 389
Classification: Community
Component: Install/Uninstall (Show other bugs)
1.1.0beta
All Linux
low Severity low
: ---
: ---
Assigned To: Rich Megginson
Orla Hegarty
:
Depends On:
Blocks: 152373 FDS1.1.0
  Show dependency treegraph
 
Reported: 2007-06-07 17:31 EDT by Rich Megginson
Modified: 2008-01-03 12:59 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.1.0-0.3.20070720.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-23 11:47:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
diffs (15.64 KB, patch)
2007-06-07 17:42 EDT, Rich Megginson
no flags Details | Diff
cvs commit log (538 bytes, text/plain)
2007-06-07 18:43 EDT, Rich Megginson
no flags Details

  None (edit)
Description Rich Megginson 2007-06-07 17:31:44 EDT
It is a pain for users to have to provide a .inf file for instance creation.  It
would be better to allow users to just pass in the required parameters as
command line arguments to ds_newinst.pl.  Also, ds_newinst.pl should accept a
pre-hashed password for the RootDNPwd to avoid passing the clear text directory
manager password around.
Comment 1 Rich Megginson 2007-06-07 17:42:40 EDT
Created attachment 156518 [details]
diffs
Comment 2 Noriko Hosoi 2007-06-07 18:14:14 EDT
Looks good to me.

I am going to eliminate cfg_sspt.[ch] in the bug 237356 (comment #38), but there
should be no essential "conflicts" there...

Let me ask one thing...: In the setup.pl scenario, install.inf file is still
created and the server register script can expect to see them in the
/usr/share/fedora-ds/inf directory?  Most likely the dynamically generated
install.inf is removed at the end of setup.pl (as setup from SetupUtil used to
do), but it exists during the installation, doesn't it?
Comment 3 Rich Megginson 2007-06-07 18:19:49 EDT
(In reply to comment #2)
> Let me ask one thing...: In the setup.pl scenario, install.inf file is still
> created and the server register script can expect to see them in the
> /usr/share/fedora-ds/inf directory?

Perhaps not in that directory.  setup.pl should pass in the full path and
filename of the install.inf file to the server register script.  (And btw, we
should refer to it as setup.inf instead of install.inf - install implies that we
are still doing things the old way i.e. installing the files).

> Most likely the dynamically generated
> install.inf is removed at the end of setup.pl (as setup from SetupUtil used to
> do), but it exists during the installation, doesn't it?

Yes.  It exists during setup, and is optionally removed or kept (setup -k) at
the end.
Comment 4 Noriko Hosoi 2007-06-07 18:41:15 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > Let me ask one thing...: In the setup.pl scenario, install.inf file is still
> > created and the server register script can expect to see them in the
> > /usr/share/fedora-ds/inf directory?
> 
> Perhaps not in that directory.  setup.pl should pass in the full path and
> filename of the install.inf file to the server register script.  
Okay.  Sounds good to me.  (I'll add the option to the server register script. 
For now, it expects to see it in the /usr/share/fedora-ds/inf dir with the
static .inf files.)

> (And btw, we
> should refer to it as setup.inf instead of install.inf - install implies that we
> are still doing things the old way i.e. installing the files).
How about other static inf files: setup.inf, admin.inf, and slapd.inf?  Can they
be in /usr/share/fedora-ds/inf?  If the dynamic .inf file is stored somewhere
else, it does not matter sharing the same file name.  It makes me a little
worried if the dynamic setup.inf overrides the static one, it could lose some
info...
Comment 5 Rich Megginson 2007-06-07 18:43:12 EDT
Created attachment 156523 [details]
cvs commit log

Reviewed by: nhosoi (Thanks!)
Fix Description: You can now use ds_newinst.pl without (or with) a .inf file
like this:
 ds_newinst.pl General.SuiteSpotUserID=nobody slapd.ServerPort=3890 ....
The parameters can be supplied via the command line.  The format of the
parameter is section.param=value.  Normal shell quoting rules apply, so you
still have to do something like this:
 ds_newinst.pl "slapd.Suffix=dc=example, dc=com"
for embedded spaces and the like.  If you supply a filename (or '-'), it must
be the first argument after ds_newinst.pl.  If you then supply additional
arguments after the filename, these will override the settings in the given inf
file.  So, for example, you could reuse the same .inf file, except provide a
different hostname:
 ds_newinst.pl basefile.inf General.FullMachineName=bar.example.com
This allows you to use the same base .inf file for several machines, and only
change certain parameters on a per-machine basis.
ds_newinst.pl will now fill in some default values - it will use
Net::Domain::hostfqdn for FullMachineName, and your login ID for
SuiteSpotUserID (however, not if running ds_newinst.pl as root), and will
construct the Suffix and ServerIdentifier based on the FullMachineName.  RootDN
will default to cn=Directory Manager.  ServerRoot is no longer required.
Another enhancement is the ability to provide a pre-hashed password for the
RootDNPwd parameter, to avoid having to pass around the clear text directory
manager password.  However, some caveats apply.  If the password begins with
one of the well known hash algorithms (e.g. {SHA, {SSHA, etc.), ds_newinst will
assume it is already hashed.  This may cause problems if users expect to be
able to provide a clear text password such as {SSHA}text, but I seriously doubt
anyone does that (famous last words . . .).  Another problem is that the code
as it currently stands uses the clear text password to bind to the server after
starting the server to add some additional entries and ACIs.  This cannot be
done if a pre-hashed password is provided (but we're working on a solution to
that problem too).
write_ldap_info() is no longer needed.
Finally, a couple of minor bug fixes.
Platforms tested: RHEL4
Flag Day: no
Doc impact: Yes.  There will be some documentation changes required.
Comment 6 Rich Megginson 2007-06-07 18:44:57 EDT
(In reply to comment #4)
> How about other static inf files: setup.inf, admin.inf, and slapd.inf?  Can they
> be in /usr/share/fedora-ds/inf?  If the dynamic .inf file is stored somewhere
> else, it does not matter sharing the same file name.  It makes me a little
> worried if the dynamic setup.inf overrides the static one, it could lose some
> info...

I'm not sure what you mean.  The dynamic one will usually be either a tmp file
(e.g. /tmp/setupXXXXX.inf) or the user will provide it.  In either case it will
be different than the static setup.inf file.
Comment 7 Noriko Hosoi 2007-06-07 18:57:35 EDT
(In reply to comment #6)
> I'm not sure what you mean.  The dynamic one will usually be either a tmp file
> (e.g. /tmp/setupXXXXX.inf) or the user will provide it.  In either case it will
> be different than the static setup.inf file.

Good.  I missed the "tmp file" part.  Now, I have no objection at all...
Comment 8 Fedora Update System 2007-07-23 11:47:37 EDT
fedora-ds-base-1.1.0-0.3.20070720.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

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