| 797b7557ad71a61ffb72a68f4457a3d999e7e252 2428 |
|
18-Jul-2007 |
jvergara |
Fix for issue 1603 (quickInstall fails to register service on vista)
With the new user access control of Vista, even if we are administrators we are not allowed to do certain operations (such as writing in the service registry) in some circumstances. For instance if we launch net start <service_name> from a normal command prompt this will fail systematically. In order to be able to execute these "privileged" operations we have different alternatives:
Execute the binary that will do the operations using the "Run as Administrator" option in Vista (or launching them from a command prompt that has been started using that same option).
Add a manifest to the binary informing that the binary requires administrator privileges.
The first alternative is one of the workarounds for the bug, however it does not apply to the case of the Java Web Start Installer.
The second alternative is in what consists the bug fix. A new binary has been created. This binary has a manifest informing that it requires administrator privileges. This binary will be used in Vista as a wrapper to call operations that require administrator privileges (modifying the registry in windows-services.bat command line and calling "net start" and "net stop").
If the user is running the setup, the status-panel using the "Run as Administrator" option or is using the command lines from a command prompt launched with that option the behavior in Vista does not change with the behavior in previous versions of Windows.
If the UAC is enabled and the user is not using the "Run as Administrator" options, (s)he will be prompted for confirmation each time the registry is modified and the server is started or stopped as a service. The wrapper is called on any of the individual operations. An alternative would be to call the wrapper when we launch the setup or the status-panel but this generates some issues:
1. This does not work (directly) with the Java Web Start installer.
2. This would force users that are not administrators to provide administrator credentials even to install/run an OpenDS that does not require to do privileged operations (an OpenDS that does not run as a service). |
| ef629cb5106ea89a04c63677373c4d70b099e053 1706 |
|
25-Apr-2007 |
jvergara |
Fix for issue 1273 (exception if JAVA_HOME undefined in scripts).
The fix consists of modifying the scripts to launch the InstallDS classwith a test option using the JVM that was found. If the JVM can be successfully launched, the JVM is compatible with 1.5, if not we as sume that is not compatible with JDK 1.5.
The downside of the fix is that it requires an additional start of the JVM each time the command line is launched. That is why the fix only applies to setup, uninstall, upgrade, start and stop command lines. The modifications in _server-script.* and _client-script.sh just modify the message displayed when a JVM could not be found (informing that JDK 1.5 or later can be used). |
| 844850276200bf083a9410753d88c49c00135816 1218 |
|
22-Feb-2007 |
jvergara |
Fix for Issues #1025 and #1248 ('stop-ds.bat should be able to stop server even if LDAP port' and 'cannot stop server through status panel').
The goal of these changes is to be able to have exactly the same user interface in Windows and Unix to stop the server. In windows we force the user to provide LDAP credentials even if the command is going to be run locally. The goal is to allow to stop the server using only system credentials (as we do in UNIX) when the user does not provide arguments when calling stop-ds.bat.
In order to do this I have written some native code. This native code is called when we start the server to:
1. Launch the java process and get the associated PID.
2. Create a server.pid file as we do for UNIX systems to store the PID of the process.
The native code that stops the server reads the PID file contents and tries to stop the process associated with the PID.
In order to allow the users to be able to build the product with independence of the platform, the binaries will be included with the source code. The code used to generate these binaries will also be provided.
I have generated 1 executable called winlauncher.exe. The binaries will be committed in the source tree under lib (with activation.jar and mail.jar). They will also be installed under <server root>\lib.
The native code is in the files winlauncher.c and winlauncher.h. These files are placed under the new directory build-tools/src/windows.
I have tried to keep the native code simple and leave as much logic as I could into the batch files (for instance everything related to the discovery of the java binaries) so that the administrators can play with them.
A README file has been also been included to explain how to generate the binaries.
Extras:
When we call start-ds from the command line, the server will not stop when the command prompt window is closed (unless start-ds was called to run in not-detached mode). The next step is to register DS as a service to avoid the server to be stopped when the user logs out.
When we call setup (with no arguments) or the statuspanel the generated process (and windows) will no longer get killed when the command prompt window is killed.
When the user double-clicks on the setup.bat or the statuspanel.bat files, the command prompt window only appears briefly. Today when we do this a command prompt window stays open until we close setup or the status panel window. |
| 266c5071a91fda6a5159b08ea8d45261228d03d5 702 |
|
11-Nov-2006 |
neil_a_wilson |
Make a number of changes to administrative tools provided with OpenDS. These
are all made under the umbrella of issue #994, but there are individual issues
for each change.
- Issue #979 -- Re-order LDAP tool arguments
When displaying usage information for many of the LDAP tools (e.g.,
ldapsearch, ldapmodify, etc.), the arguments were not provided in any kind of
logical grouping. This has been corrected so that the arguments are listed
in a more logical ordering.
- Issue #983 -- Add tool description to argument parser
When displaying usage information for administrative tools, it now includes a
small summary of what the tool does at the top of the argument list.
- Issue #984 -- Make tool usage more compact
Previously, the tool usage included a blank line between each argument, which
made the usage information seem too verbose, especially for tools like
ldapsearch with a lot of arguments. This extra space has been removed.
Also, many of the argument descriptions have been rewritten in an attempt to
avoid requiring multiple lines.
- Issue #985 -- Wrap long output in administrative tools when appropriate
Update most of the output for the administrative tools so that it is easier
to read on 80-column displays. This primarily impacts error message, and
cases in which the format of the output is important (e.g., LDIF output from
ldapsearch) no changes were made.
- Issue #986 -- Eliminate hard-coded strings in tools
Some of the tools had hard-coded strings used for error and warning messages.
They have been replaced with localizeable output from the messages files.
- Issue #990 -- LDAP tools don't use trust store password
The LDAP tools didn't provide any mechanism for specifying the PIN needed to
access the contents of an SSL trust store. Some types of trust stores may
require a PIN to access them, so it is now possible to either directly
specify the PIN or to provide the path to a PIN file.
- Issue #991 -- Disconnect when running stop-ds shouldn't be an error
When using the stop-ds script, if the server began shutting down before it
returned a response to the client, the client would provide an error message
making it sound like something went wrong. The output has now been updated
to indicate that the server is likely in the course of shutting down.
- Issue #992 -- Tool usage should include the tool name rather than the class
When displaying usage information for the administrative tools, the
fully-qualified class name for the Java class was displayed, where the name
of the shell script or batch file would have been more useful. |