| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
| |
Bug Description: The dsgw cookie directory needs to be writable by the admin server uid
Reviewed by: Nathan (Thanks!)
Fix Description: DS Gateway authentication breaks because the admin server uid cannot write to the bin/slapd/authck directory. This fix makes sure that directory is owned by the correct uid. I've also put a similar fix into the ds spec file %post section to fix this when upgrading from fds10 to fds101.
Platforms tested: Fedora Core 4
Flag Day: no
Doc impact: no
|
| |
|
|
|
|
|
|
|
| |
Bug Description: The BUILD_BOMB is on by default
Reviewed by: Nathan (Thanks!)
Fix Description: Move the pumpkin and build bomb stuff into the internal makefiles. If you want the build bomb on, you have to set BUILD_PUMPKIN=1 on the make command line. The diff also contains some of the versioning for 1.0 to 1.0.1.
Platforms tested: Fedora Core 4
Flag Day: no
Doc impact: no
|
| |
|
|
|
| |
If missing entry_id is found, skip it and continue reading the primary db to be
reindexed.
|
| | |
|
| |
|
|
| |
When reading a rotation info file, compare the contents with the files in the logs dir, if mismatch is found, update the rotation info file. Once the files arestored in the rotation info file, they will be the target of cleanup at the nextlog ration.
|
| | |
|
| |
|
|
| |
need to set localuser before creating/opening error log.
|
| |
|
|
|
| |
Modified to change the owner to the "localuser" if the error log file is not
owned by the user.
|
| |
|
|
|
|
|
|
|
|
| |
the contents. I'm not sure why we haven't caught this earlier, but
I believe it has something to do with the patch to make ds build on
Fedora Core 4 with gcc4. To do that, we turn off the -fwriteable-strings
argument to gcc. I suppose with it on, it moves those strings to
some sort of writeable memory location. With it off, constant strings
are definitely in the data section. There was one place in views that
used a constant string, and a couple of places in the windows sync code.
|
| |
|
|
|
|
| |
NSS/SSL init. For example, import needs to hash passwords, export of encrypted attrs needs encryption.
2) Only create, configure (for SSL) and bind TCP ports if running in regular or referral mode. Before, the code short circuited if doing import, export, etc. before getting to the port stuff. But since 1) above, the code needs to take care only to do network related stuff if in network mode.
|
| | |
|
| |
|
|
|
| |
related files are owned by the correct user, but make that happen before
the detach so we can ask for the pin on the terminal.
|
| | |
|
| |
|
|
| |
Fixed to get the adminid from the right place: adminpw
|
| |
|
|
|
|
| |
was due to the security CGI not being able to read the ds key/cert db files. They were owned by root instead of the server uid because they were being created by NSS_Initialize which was being called before the server did the setuid.
The fix is to move the NSS/SSL initialization code to just after the setuid call.
|
| |
|
|
|
| |
1) setup was not using the correct value for the config admin ID during reconfig. The fix is to get the correct uid from the admpw file.
2) It is often difficult to figure out the correct id/url for the admin server when running it for the first time. The fix is for setup to print out the correct command to use so the user can copy/paste it into the terminal. The commands are also saved to setup.log in case they close the terminal window.
|
| |
|
|
| |
tab. The solution is to chown the alias directory to the admin server uid so that the security CGI can create the key/cert dbs in that directory.
|
| |
|
|
| |
change the spec file to include the dependency only on RHEL, or just wait until gcj/classpath can run our stuff
|
| |
|
|
| |
generally compatible, they are compatible for this specific case
|
| | |
|
| |
|
|
| |
external builds
|
| |
|
|
|
|
| |
Fix: Put the dsml gateway and command line jar files in a package called
extjava.tar.gz so that users can choose to deploy these separately if they
want dsml functionality.
|
| |
|
|
|
|
|
| |
i1) For non-RHEL platforms, package cyrus sasl library and the supported plugins.
2) by default, cyrus sasl expects to see the plugins in /usr/lib/sasl2.
Instead, tell sasl to search "../../../lib/sasl2" (relative path from ns-slapd)
for the plugins.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: Allow ldapserver rpm to be made externally
Reviewed by: Noriko (Thanks!)
Fix Description: Just use a simple sed command to replace the tokens in
the spec.tmpl file. Just assume Fedora branding for this. For some
reason, on FC4, the setup -b step does not work unless I added a second
echo yes to the command. The tar command used by the rpmbuild step must
have all of the command line arguments before the directory to tar. I
moved some things around to make the rpm build process more dsbuild
friendly.
Platforms tested: FC4
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: sasl code needs to accomodate older versions of sasl
Reviewed by: Noriko (Thanks!)
Fix Description: 1) Change build to use -L/usr/kerberos/lib on RHEL3
since that's where gssapi_krb5 is on that platform 2) ifdef out the use
of SASL_AUX_PASSWORD_PROP - if it's not defined, we don't need to use it.
Platforms tested: RHEL3
Flag Day: no
Doc impact: no
|
| |
|
|
| |
Back off "%config line", which is not needed on DS7.2.
|
| |
|
|
|
|
| |
Added "cyrus-sasl >= 2.1.19" to the spec file:
+Requires: perl,java-1.4.2-ibm,cyrus-sasl >= 2.1.19
Note: this diff contains the upgrade pre operaton to shutdown the servers before unpacking the files.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: slapd crashes during SASL authentication
Reviewed by: Noriko (Thanks!)
Branch: HEAD and Directory71RtmBranch
Fix Description: When we build cyrus-sasl on RHEL, we tell it to use
berkeley db for its sasldb database. It uses whatever version of
berkeley db is installed in the system. On RHEL3, this is usually
libdb-4.1. However, at runtime, slapd uses 4.2, leading to conflicts.
This doesn't happen on RHEL4 because it already has 4.2 on it. The db
is used to lookup auxiliary properties (auxprop) related to the user,
such as password or whatever. This happens in sasl after the user is
looked up. In our server, the way we use it, we don't care about these
auxprops, or we get them in another way. If you don't tell sasl which
auxprop plugin you want to use, it tries to use all of them, which means
it will attempt to use the sasldb plugin, which will lead to the crash.
The solution is to add our own auxprop plugin which is just a dummy that
does nothing, and tell sasl to use our plugin.
Platforms tested: RHEL3, RHEL4
Flag Day: no
Doc impact: no
QA impact: retest
New Tests integrated into TET: none
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: Fix internal component versions and formats for initial
FDS 1.0 build
Reviewed by: Noriko (Thanks!)
Fix Description: Some of the naming conventions needed to change e.g.
/s/b/c/ldapconsole10ext became /fedora/components/directoryconsole/1.0.
Made the ds onlinehelp docs available to build externally. Perldap has
no zip file anymore, just the dirs we copy over. Adminserver includes
the unzipped directories - we need to fix that eventually, but in the
meantime, I made tar skip those unzipped directories. I also merged
Noriko's fix for the assecure.txt problem in setup into Fedora DS. Noriko also pointed out an unused Makefile variable.
Platforms tested: RHEL3
Flag Day: no
Doc impact: no
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: Change ldapserver version to 1.0
Reviewed by: Noriko (Thanks!)
Fix Description: This also fixes some lingering build issues involving
perldap, which is no longer a separate setup package, but just gets
included into DS in a similar manner to nspr, nss, etc.
Platforms tested: RHEL4
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: parameterize ldapjdk and crimson jar locations
Reviewed by: Noriko, Nathan (Thanks!)
Fix Description: This is also needed for GAR. The xmltools also
ldapjdk.jar, and needs crimson.jar. DSMLGW does not need crimson.jar.
It makes sense to separate these out of the dsmlgw jars. I changed the
dsmlgw build.xml to be able to pickup ldapjdk.jar from a different
location - defaults to the usual dist/classes.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none
Bug(s) fixed: 172005
Bug Description: Change ldapserver version to 1.0
Reviewed by: Noriko (Thanks!)
Fix Description: This also fixes some lingering build issues involving
perldap, which is no longer a separate setup package, but just gets
included into DS in a similar manner to nspr, nss, etc.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none
|
| |
|
|
| |
duplicate values for system-only multivalued attributes. This change just skips the dscorepropagationdata attibute when receiving a change from DirSync.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: Allow DSMLGW to build with GAR build scripts
Reviewed by: nhosoi@redhat.com (Thanks!)
Fix Description: Add a new macro DSMLGWJARS_BUILD_DIR which defaults to
dist/classes for internal builds. For external builds, the developer
can grab these jars from their respective locations, or grab the bundle
from the fds download site, which is what the GAR builds will do. The
location is then passed in on the make command line as
DSMLGWJARS_BUILD_DIR=/path/to/dsmlgwjars. Regular internal builds
should continue to work as always.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
|
| |
|
|
| |
Reporting the patch generation code to the trunk.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: Get rid of nsperl; use perldap with system perl
Reviewed by: Noriko, Rob, Nathan (Thanks!)
Branch: HEAD
Fix Description: All perl scripts are made executable by using the
#!/usr/bin/env perl *nix trick. This means that the correct version of
perl must be in the user's PATH e.g. 5.6.1 or later. This version is
either shipped with the OS or available on all platforms. On HP/ux, it
is available as a depot which is installed in /opt/perl. For CGI perl
scripts, the PATH can be set in the admserv.conf, so we may have to do
that for HP/ux. To make perldap work, some ugly hacks are involved.
Each perl script that uses perldap has a BEGIN section that figures out
where it is in the server root, sets a server root variable, and sets
LD_LIBRARY_PATH and SHLIB_PATH to point to serverroot/shared/lib.
Perldap will be installed under serverroot/lib/perl. This directory
will have 3 subdirectories: arch - containing the binary files; auto -
containing autoloaded perl modules; and Mozilla - containing the base
perldap .pm files. The BEGIN section also sets the perl INC path to
find those modules. The directory gets rid of nsperl plus a lot of old
crufty perl building code that we do not use anymore. Those are the
removed files. The admin server code also gets rid of the perl.c wrapper.
Noriko pointed out that this does not take care of upgrade install, so I
added several more files and diffs to take care of that case.
Basically, go through the tasks in o=netscaperoot and replace
perl?scriptname with just scriptname. Also, go through all of the
template generated scripts and replace the shebang line with
#!/usr/bin/env perl, and make sure they are chmod +x. I also found a
few more places that referenced nsperl and removed them.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
