https://bugzilla.redhat.com/show_bug.cgi?id=487831
Resolves: bug 487831
Bug Description: Tabbed Panel display throws NullPointerException
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: A couple of panels were defining an isValid method to
use for clean/dirty validation. However, the Component class which
these panels inherit from also defines the isValid method for a
different purpose. Our code must not use the isValid method, so I
renamed those methods to something more meaningful in their context. I
also found another problem with a null pointer access in some schema code.
Platforms tested: RHEL5
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=333586&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=487725
Resolves: bug 487725
Bug Description: Performing a MOD operation to bring an entry into
the scope of a DNA managed range doesn't trigger DNA to generate
a new value. This happens since we check the DNA filter against
the existing entry instead of the resulting entry after the mods
are applied.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: This patch handles modify operations that bring entries
into or out of scope of a managed range. If you bring an entry into scope
(say by adding the appropriate objectclass), this will assign a value from
the range if the magic value or no value is supplied for the managed type.
Platforms tested: F9
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=333521&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=486402
Resolves: bug 486402
Bug Description: Using setup-ds.pl and then registering the instance with
an admin server using register-ds-admin.pl does not add the proper ACI's
to allow admin to manage the instance.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: Add the appropriate aci's when running
register-ds-admin.pl.
There were a few other issues to deal with in addition to the missing ACIs.
The PTA plug-in was not being configured since the LDIF template that
was used
was an entire new PTA plug-in entry, which never gets added since it
already
exists. I changed this to a LDIF mod template. We also only want to
configure
PTA if it is not already configured, or if we are switching the config DS.
This will prevent overwriting any custom tweaks to the PTA plug-in, such as
using LDAPS to communicate with the config DS.
I found another issue during testing with the ldapStart parameter in
adm.conf
getting set incorrectly after running register-ds-admin.pl. This
parameter is
supposed to point to the start-slapd script of the config DS, but
register-ds-admin.pl was always changing this to the last instance that it
registered (which will never be the config DS if you have more than one
instance). We need to ensure that the slapd info in the inf is the
config DS
before updating the Admin Server config files.
Platforms tested: F9
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=333508&action=diffhttps://bugzilla.redhat.com/attachment.cgi?id=333503
https://bugzilla.redhat.com/show_bug.cgi?id=450575
Resolves: bug 450575
Bug Description: unbind or abandon with unsupported critical controls
does not close connection
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: When an unbind request is received that has controls
marked as critical, and we do not support those controls, we must treat
them as non-critical controls and continue processing.
Platforms tested: RHEL4, RHEL5
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=333434&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=487574
Resolves: bug 487574
Bug Description: A crash occurs in the DNA plug-in when you delete an
existing
value of a managed attribute.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The DNA code was always expecting a value to be present
when
processing a modify operation. The delete and replace modify
operations can
be issues with no values. These operations were an oversight in the
DNA code.
The fix adds cases to handle delete and replace modify operations.
For a replace,
we check if we are replacing all values with nothing, and generate a
new value from
the range. If we're processing a delete with no values specified, we
also generate
a new value. If the delete has values specified, we check to see if
the operation
leaves any values in the existing entry. If no existing values would
remain after
the operation, we generate a new value.
Platforms tested: F9
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=333386&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=480869
Resolves: bug 480869
Bug Description: DS console: Can not delete DS instance
Reviewed by: ???
Files: see diff
Branch: HEAD
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
https://bugzilla.redhat.com/attachment.cgi?id=333382&action=diffhttps://bugzilla.redhat.com/attachment.cgi?id=333383&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=486402
Resolves: bug 486402
Bug Description: Using setup-ds.pl and then registering the instance with
an admin server using register-ds-admin.pl does not add the proper ACI's
to allow admin to manage the instance.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: Add the appropriate aci's when running
register-ds-admin.pl/
Platforms tested: F9
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=333215&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=486474
Resolves: bug 486474
Bug Description: overriding arguments to setup causes setup to fail
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: Parameters specified on the command line should
override and replace (not add to) any parameters specified in a given
.inf file. I refactored the code a little too - I moved the argv
processing into the Inf module out of the Setup and Migration modules.
The code will first process the args and store the values in a temporary
hash ref. Then it will process the temp hash ref, replacing the values
in the main inf with the values from the hash.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=333059&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=468474
Resolves: bug 468474
Bug Description: migration results in incomplete admin server sie
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: This is a redesign of one of the core pieces of the
setup/migration code - the code that adds the LDAP entries in various
places. For starters, I removed the code that would implicitly delete
existing trees. This is the root cause of this bug, and other similar
problems with setup/instance creation that have been reported. We
should never implicitly delete entries. Instead, we should explicitly
delete entries by using the changetype: delete in an LDIF template file.
Another source of problems was that to update an entry, we would delete
it and add it back. This caused some configuration settings to be wiped
out (e.g. encryption settings). We cannot do this any more. The LDIF
template entries have been modified to have two sets of information for
each entry that requires update - the entry to add if no entry exists
(the full entry) or the changes to make to the entry if it does exist.
The code in Util.pm has been changed to ignore duplicate entries and to
ignore changes made to entries that do not exist.
Another source of problems with migration is that the error checking was
not adequate, especially with FileConn and dse.ldif reading. The fix is
to add better error checking and reporting in these areas of code,
including error messages.
Yet another problem is the run_dir handling. On many platforms the
run_dir is shared among all DS instances and the admin server. Older
versions of the software allowed you to run the servers as root. We
have to make sure run_dir is usable by the least privileged user of all
of the servers.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=332973&action=diffhttps://bugzilla.redhat.com/attachment.cgi?id=332974&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=482892
Resolves: bug 482892
Bug Description: Passsync service start and stop messages in Windows
event viewer are not logged correctly
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: Looks like someone had started to tie in the message
catalog/resources, but didn't get far enough.
1) I used rc to compile the .rc file into a .res file - this new .res
file is being added to CVS (cvs add -kb)
2) I added dssynchmsg.res to the link line
3) I made sure the passsync.exe main called the Install() method which
installs the message catalog where the Event Viewer can find it. I had
to make that code smarter, so it would not attempt to create/install
something that was already there.
Platforms tested: Windows 2003 Server
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=331886&action=diff