| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=523476
Resolves: bug 523476
Bug Description: 389-ds-base/glibmm24: conflicting perl provides
Reviewed by: nhosoi (Thanks!)
Files: see diff
Fix Description: Rename "Util" to "DSUtil"
Platforms tested: Fedora 11 x86_64
Flag Day: no
Doc impact: no
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updates are implemented in:
perl - code that plugs in to setup - scriptlets that are imported into
the setup perl interpreter and executed in process, giving access to all
of the packages and context provided by setup
ldif - applied to instances, in the same manner as ConfigFile directives
to setup
other - any executable file, shell script, etc. can be invoked, with a limited
amount of context from the setup process
An update directory is added to the package - /usr/share/dirsrv/update - this
directory contains the update files - the update filenames begin with two digits
and are executed in numeric order (00 first, then 01, etc. up to 99) which
should provide enough flexibility
In addition, there are 5 stages of update:
pre - invoked before any instance specific code
preinst, runinst, postinst - invoked for each instance
post - invoked after any instance specific code
Example files are provided which demonstrate how to get the context.
There are two different modes of operation for update:
online - must supply a bind dn and password for each instance - servers must
be up and running
offline - operates directly on the dse.ldif - servers must be shutdown first
A new section is added to the .inf file that can be passed in
[slapd-instancename]
RootDN = binddn
RootDNPwd = bindpw
The RootDN is optional - if not supplied, it will get the nsslapd-rootdn attribute from the dse.ldif for the instance.
I also fixed some problems with error messages.
The pam pta plugin entry was giving object class violations, so I added the
missing attributes - note that these are replaced by the plugin code when
the plugin is loaded - they are only needed during setup.
Fixed usage of $_ - $_ behaves like a dynamically scoped variable - which
means if you use it in an outer context, you cannot use it in an inner
context, even if it is used in a different function. Rather than attempting
to figure out how to use $_ safely in lower level functions, I just removed
the use of it altogether, which also makes the code easier to read.
Reviewed by: nhosoi (Thanks!) - fixed minor issues found
Platforms tested: Fedora 11
|
| |
|
|
|
|
|
|
|
| |
Description: Bug 480869 - DS console: Can not delete DS instance
Fix Description: Create instance was broken, so no instances could be created for purposes of deletion. Create instance was printing the following error:
Unable to find Pass Through Authentication Plug-In config entry.
This is because the search for this entry in AdminUtil.pm was getting an incorrect error message - something other than "Success"
This is because the FileConn->getErrorString() method was returning "0" instead of "Success".
Platforms tested: RHEL4
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: migration results in incomplete admin server sie
Reviewed by: nkinder (Thanks!)
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: Show-Stopper - Migration from HP-PARISC DS 6.21 to DS80 on HP-Itaninum
Reviewed by: nhosoi (Thanks!)
Fix Description: 1) The temp file created to fix nsroot was not owned by the server user, and ldif2db could not open it.
2) The perldap LDIF parser/writer did not correctly handle the version: 1 line in the LDIF file. It outputs dn\nversion: 1 which causes ldif2db to crash.
3) The migrate script could not start the server because it wasn't looking in the fhs-opt location. The real solution is to just have migration start the servers after it migrates them. This assumes the old servers are all shutdown first, which they must be, in order to have a consistent database for migration.
These last two were found and fixed by nhosoi
4) If we transform an attribute to an empty value, this means we want to remove it from the migrated entry. We use the remove method to remove the attribute.
5) The remove method in FileConn was not working. We have to make a clone of the entry that we have removed the attribute from. The process of iterating over the attributes skips deleted ones because of the way the Tie::Hash functions in the Entry class work.
Platforms tested: HP-UX 11.23 IPF64
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: Replace ds_newinst binary with perl script
Reviewed by: nhosoi (Thanks!)
Fix Description: The time has come. We can finally get rid of the instance creation C code
once and for all. I've created a DSCreate module that has all of the functionality of the old
create_instance.c code, along with a few items from ldap/admin/lib. The way it works is
this: it first creates the dse.ldif file using template-dse.ldif and the suffix-db template to
create the initial db and suffix. It then adds additional optional configuration depending
on what optional features have been enabled. It creates other config files and copies in
the schema. It then initializes the database. It uses a template file based on the type of
entry implied by the suffix, then adds the default ACIs. If the user chose to do so, it
will also create the ou=people, ou=groups, etc. entries. The user can also supply an LDIF
file which will be used to populate the initial database, in which case none of the default
entries or ACIs will be used. It then starts the server (if desired).
I had to create a function makePaths that works like mkdir -p except that it will chown,
chgrp, and chmod all paths created.
I had to change the other places where instance creation was called to use the new
calling semantics. ds_create changed quite a bit, since it can just use an Inf to pass in the
information instead of calling ds_newinst as a CGI program.
I had to change FileConn to add support for namingContexts (i.e. entries with no parent),
and to have it write each change each time, and to return copies of entries when searching,
to avoid modifying the tree in place. This makes it act much more like LDAP.
I found and fixed a few bugs in Migration along the way that were revealed while integrating
the new DSCreate code.
Platforms tested: RHEL4, FC6
Flag Day: Yes. New instance creation code and autotool changes.
Doc impact: no
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: DS Admin Migration framework - cross platform support
Reviewed by: nhosoi (Thanks!)
Fix Description: There are basically three parts to cross platform support
1) Allow a different physical server root than the logical server root. This allows you to copy the old server root directory to the target machine, either by making a tarball or by a network mount. Then you can migrate from e.g. /mnt/opt/fedora-ds, and specify that the real old server root was /opt/fedora-ds. This is the distinction between the --oldsroot and --actualsroot parameters.
2) Cross platform database migration requires the old data is converted to LDIF first. Migration makes the simplifying assumption that the database LDIF file is in the old db directory and has the name of <old backend name>.ldif e.g. userRoot.ldif
3) Cross platform replication migration doesn't preserve the state, so the changelog nor other associated state information can be migrated.
I rewrote the old migration script to use the FileConn - this theoretically will allow us to support migration using an LDAP::Conn as well.
I had to make some fixes to FileConn, primarily to support the root DSE.
Platforms tested: RHEL4
Flag Day: no
Doc impact: Yes, along with the rest of the new migration framework.
|
|
|
Bug Description: Reimplement ds_create without setuputil code
Reviewed by: nhosoi (Thanks!)
Fix Description: ds_create was a CGI program that would create a new instance, set it up to be managed by console, and register it with the config ds. The new ds_create CGI perl script does just that. One tricky part was that, rather than enabling the pass through auth plugin and having to restart the server, the new server is created without being started, then the modification is done to the new server dse.ldif file directly, using the new FileConn.pm module, which simulates a Mozilla::LDAP::Conn on an LDIF file. This also allows us to create a new instance with a pre-hashed rootdn password, rather than having to send the cleartext password.
I had to move around some code in AdminServer and AdminUtil so that I could use it from ds_create. I also implemented support for the admin server PASSWORD_PIPE in perl so we could use it in other CGI perl scripts.
Finally, the error handling was not consistent in our code, so I made explicit the passing of error messages up and down the stack. Oh how I wish we could just do this in python and use exception handling . . .
I added a test for ds_create.
Platforms tested: RHEL4
Flag Day: Yes - autotool changes
Doc impact: No. Should work the same way as the old ds_create.
|
