Bug 243205

Created attachment 156518 [details]
diffs

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?

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

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

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.

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

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

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.