[Fedora-directory-commits] ldapserver/man/man8 remove-ds.pl.8, 1.1, 1.2 migrate-ds.pl.8, 1.1, 1.2

Fri Feb 27 14:33:14 UTC 2009

Author: rmeggins

Update of /cvs/dirsec/ldapserver/man/man8
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21533/ldapserver/man/man8

Modified Files:
	remove-ds.pl.8 migrate-ds.pl.8 
Log Message:
Resolves: bug 480869
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 



Index: remove-ds.pl.8
===================================================================
RCS file: /cvs/dirsec/ldapserver/man/man8/remove-ds.pl.8,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2

--- remove-ds.pl.8	13 Feb 2009 20:05:59 -0000	1.1
+++ remove-ds.pl.8	27 Feb 2009 14:33:12 -0000	1.2
@@ -19,7 +19,7 @@
 remove\-ds.pl \- Remove an instance of Directory Server
 .SH SYNOPSIS
 .B remove-ds.pl
-[\-f] \-i \fIinstance\fR
+[\-f] [\-d \-d ... \-d] \-i \fIinstance\fR
 .SH DESCRIPTION
 Removes a Directory Server instance from the system.  The instance
 will be shutdown and the files will be removed.  The certificate
@@ -36,6 +36,9 @@
 .B \fB\-f\fR
 Force removal
 .TP
+.B \fB\-d\fR
+Enable debugging - adding more -d will make output more verbose
+.TP
 .B \fB\-i\fR \fIinstance\fR
 The full name of the instance to remove (e.g. slapd-example)
 .br


Index: migrate-ds.pl.8
===================================================================
RCS file: /cvs/dirsec/ldapserver/man/man8/migrate-ds.pl.8,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- migrate-ds.pl.8	15 Jul 2008 15:50:56 -0000	1.1
+++ migrate-ds.pl.8	27 Feb 2009 14:33:12 -0000	1.2
@@ -125,14 +125,23 @@
 the same name as the database instance directory, with a ".ldif".  For
 example, if you have
 .IP
-/opt/fedora\-ds/slapd\-instance/db/userRoot/ and
+.ad l
+.nf
+/opt/fedora\-ds/slapd\-instance/db/userRoot/
+and
 /opt/fedora\-ds/slapd\-instance/db/NetscapeRoot/
+.na
+.fi
 .PP
 you must first use db2ldif to export these databases to LDIF e.g.
 .IP
+.ad l
+.nf
 cd /opt/fedora\-ds/slapd\-instance
 \&./db2ldif \fB\-n\fR userRoot \fB\-a\fR /opt/fedora\-ds/slapd\-instance/db/userRoot.ldif and
 \&./db2ldif \fB\-n\fR NetscapeRoot \fB\-a\fR /opt/fedora\-ds/slapd\-instance/db/NetscapeRoot.ldif
+.fi
+.na
 .PP
 Then you must somehow make your old server root directory available on
 the destination machine, either by creating a tar archive on the source


