summaryrefslogtreecommitdiffstats
path: root/ldap/admin/src/scripts/SetupLog.pm
Commit message (Collapse)AuthorAgeFilesLines
* Resolves: bug 480869Rich Megginson2009-02-271-1/+4
| | | | | | | | | | | | Bug Description: DS console: Can not delete DS instance Reviewed by: nkinder (Thanks!) Fix Description: As it turns out, my assumption that ds_remove in CGI mode also did the unregistration was false. It is the console that does the unregistration, only after the ds_remove CGI returns success. So, ds_remove needs to run with AdminSDK off, just like the other "special" CGI programs. In addition, ds_remove needs to be more robust - if there is an error during ds_remove, you should be allowed to try again after fixing something. However, the way the error handling worked did not differentiate between fatal errors and errors that could be ignored. In order to do this properly, we need to propagate the errors back up to the top level (oh how I wish perl had real exception handling . . .). The main type of error we need to ignore is file not found or process not found. If we attempted to remove before and that attempt failed for some reason, and left a partial instance, we need to be able to run the remove command again, skipping over the things we shutdown or removed already, and clean up the stuff we need to remove. This can also happen if you use the console to create a ds instance, and remove-ds.pl to remove the instance. The instance will still show up in the console. We need to be able to use the Remove Server in the console to remove the instance from the console, even through there is no physical instance on disk any more. Since the console will only do the unregistration if the CGI returns success, we need to make sure the CGI returns success even though there is no instance on disk. When ds_remove is run via ds_removal, it will do the unregistration. I also took this opportunity to refactor the remove code, creating a removeDSInstance method in DSCreate.pm, and moving some of the other removal helper functions to Util.pm. That simplified the code in both ds_remove and remove-ds.pl. I added a remove-ds-admin.pl script - one of the problems that users have is that they run setup-ds-admin.pl, then hit some error (e.g. bad DNS setup), then find that they cannot restore the system to the state before they ran setup-ds-admin.pl. remove-ds-admin.pl does this. Finally, I added some man pages to the admin package for those commonly used commands. Platforms tested: RHEL4 Flag Day: no Doc impact: no
* Resolves: bug 245815Rich Megginson2007-06-291-1/+2
| | | | | | | | | | | Description: DS Admin Migration framework Reviewed by: nhosoi (Thanks!) Fix Description: Created a Migration class that is very similar to the Setup class - to act as a sort of global context for the migration process. Moved most of the guts of migrateTo11 into the new DSMigration class and the new migrate-ds.pl - we should deprecate migrateTo11 in favor of migrate-ds.pl. I had to enhance the check_and_add_entry function to handle pseudo-LDIF change records - pseudo because mozilla perldap LDIF has no real LDIF change record support. Fixed a bug in create_instance.c - creating an instance without starting it was not working if the port number of an existing directory server was supplied. Added a new method createDSInstance to Util - this just wraps ds_newinst.pl for now. Platforms tested: RHEL4 Doc: Yes. We will need to document the migration procedures. Flag day: Yes. Autotool file changes.
* Resolves: bug 237356Rich Megginson2007-06-081-0/+99
Description: Move DS Admin Code into Admin Server Fix Description: This adds the setup related perl modules, scripts, and resource files to the DS base code. This will allow a user to interactively setup (create an instance of) a directory server. This will also form the base of the work to add the console and admin server related setup code. New files/directories: $libdir/fedora-ds/perl - this is where the perl modules (Setup.pm, etc.) will be installed. $bindir/setup-ds.pl - the script to use to interactively create an instance of directory server. This has use lib '$libdir/fedora-ds/perl' hard coded into it at build time, in order to find the "private" setup perl modules. If you invoke this script in silent mode (setup-ds.pl -s) then it is exactly the same as just using ds_newinst.pl. $sysconfdir/fedora-ds/property/setup-ds.res - Resources for setup-ds.pl and the associated modules. I also fixed a problem with the libns-dshttpd linkage. Platforms tested: RHEL4 Flag Day: no Doc impact: Yes. All of these new items will need to be documented.