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