February 2009 - 389-devel - Fedora Mailing-Lists

[Fedora-directory-devel] Please review: Bug 487831 - Tabbed Panel display throws NullPointerException

by Rich Megginson

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

14 years, 7 months

1
0
0 / 0

[Fedora-directory-devel] Please Review: (487725) modification of non-posix group to posix group doesn't catch magic number

by Nathan Kinder

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

14 years, 7 months

1
0
0 / 0

[Fedora-directory-devel] Please Review: (486402) setup-ds.pl + register-ds-admin.pl generates different aci's then setup-ds-admin.pl

by Nathan Kinder

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=diff https://bugzilla.redhat.com/attachment.cgi?id=333503

14 years, 7 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 450575 - unbind or abandon with unsupported critical controls does not close connection

by Rich Megginson

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

14 years, 7 months

1
0
0 / 0

[Fedora-directory-devel] Please review: (487574) Crash in DNA plug-in when deleting a value

by Nathan Kinder

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

14 years, 7 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 480869 - DS console: Can not delete DS instance

by Rich Megginson

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=diff https://bugzilla.redhat.com/attachment.cgi?id=333383&action=diff

14 years, 7 months

1
0
0 / 0

[Fedora-directory-devel] Please Review: (486402) setup-ds.pl + register-ds-admin.pl generates different aci's then setup-ds-admin.pl

by Nathan Kinder

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

14 years, 7 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 486474 - overriding arguments to setup causes setup to fail

by Rich Megginson

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

14 years, 7 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 468474 - migration results in incomplete admin server sie

by Rich Megginson

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=diff https://bugzilla.redhat.com/attachment.cgi?id=332974&action=diff

14 years, 7 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 482892 - Passsync service start and stop messages in Windows event viewer are not logged correctly

by Rich Megginson

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

14 years, 7 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel February 2009