[Fedora-directory-devel] Please Review: (247283) Multiple problems with CGIs used by Admin Server Console
by Nathan Kinder
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247283
Resolves: bug 247283
Bug Description: While working on getting the Admin Server Console
to work with the new Admin Server, I ran into multiple problems
with various CGIs that the Console calls. I'll detail each of
the issues below.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The ReadLog CGI was changed to eliminate the
possibility of the caller
passing in the path to the log files. To get the path to the log
file, the CGI was
concatenating the logdir with the value of the configuration parameter
that says
where the requested log type is. The problem is that the config
parameters use
an absolute path, not just the file name. This was resulting in the
logdir
being listed twice, which is obviously wrong. In addition to the
logdir being
listed twice, the config parameter for the error log had the log file name
listed as "errors" instead of "error". This would cause the CGI to
not find the
logfile. The solution for these issues is to just use the config
value directly
without prepending the logdir, as well as fixing the logfile name for
the error log.
The config CGI is used to read and write Admin Server configuration
parameters.
This CGI was setting overriding the user DN and password with the sie
DN and
password. These is no need to use the sie DN, and doing so was
causing this CGI
to fail to read and set the config values. The solution is to just
use the
passed in user DN and password.
The sec-activate CGI is used to enable SSL for the Admin Server. When
using the
Console, I found that I could check the enable SSL checkbox, then
uncheck it and
click on save. This would call sec-activate to save the changes,
which would
result in an error about the cipher family setting not being present.
We should
only require a cipher family setting if we are turning SSL on. The
solution is
to first check if the setting being saved have SSL off, and only
require the
cipher family settings if SSL is set to on.
The last issue isn't actually a CGI issue, but instead is an issue in
mod_admserv when the "admin-serv/authenticate" URI is called. This URI is
supposed to return the user and group directory connection information
to the
caller. The problem is that the user and group directory info is set
at Admin
Server startup time. The Admin Server doesn't have the ability to
authenticate
to LDAP at startup since it has no credentials, so it always ends up
setting the
user and group directory to point to the config directory (it uses
"o=netscaperoot" as the base). This causes the users and groups tab
in Console
to search the wrong tree in the directory. The solution is to not set
the user
& group directory info at startup, but instead delay it until the
first time
that it is needed during an authentication. We can then pass that
authentication info through to get a valid LDAP handle which will
allow us to
search for the real user and group information.
Platforms tested: FC6
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158674&action=diff
16 years, 9 months
[Fedora-directory-devel] Please review: [Bug 247215] Reimplement ds_remove without setuputil code
by Noriko Hosoi
Summary: Reimplement ds_remove without setuputil code
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247215
This is the first step of ds_remove. With this change, this command line cleans up the Configuration entries from the Configuration server.
register_server.pl -v -m <mappath>/dirserver.map -p <port> -w <passwd> -d <infdir> -i <dynamic_inffile> 10rm_dsdata.ldif.tmpl
------- Additional Comments From nhosoi(a)redhat.com 2007-07-05 21:14 EST -------
Created an attachment (id=158634)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158634&action=view)
cvs diff ldapserver/ldap/admin/src/scripts/Util.pm.in
Description:
1) introduced delete entry operation. It supports an entry which contains
"changetype: delete" as follows:
dn: cn=slapd-%dsid%, cn=%brand% Directory Server, cn=Server Group, cn=%fqdn%,
ou=%domain%, o=NetscapeRoot
changetype: delete
It deletes all the subordinate entries.
2) cleaned up check_and_add code a bit (it's not "and_add" any more, tho... ):
------- Additional Comments From nhosoi(a)redhat.com 2007-07-05 21:17 EST -------
Created an attachment (id=158635)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158635&action=view)
New: tmpl file used for remove
File: adminserver/admserv/schema/ldif/10rm_dsdata.ldif.tmpl
Description: remove tmpl file to clean up the Configuration entries belonging
to the removed Directory Server instance.
Thanks,
--noriko
16 years, 9 months
[Fedora-directory-devel] Please Review: (247192) adminutil: admldapBuildInfoCbk() is not properly setting the LDAP handle
by Nathan Kinder
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247192
Resolves: bug 247192
Bug Description: The admldapBuildInfoCbk() function is supposed to
create an LDAP handle. This handle is not getting created since
it is attempting to bind as the sie DN, which will always fail.
This causes a problem for other functions which require a valid
LDAP handle. One of the functions that this causes a problem for
in particular is the admldapGetUserDirectoryInfo() function.
The admldapGetUserDirectoryInfo function is used to get info about
the users and groups directory. This is used at Admin Server startup
time as well as by the ugdsconfig CGI that is called by the Admin
Server Console. When used by the Console, we need to pass the userdn
used to authenticate to the Admin Server through to the Directory
Server. This approach does not work for the startup of the Admin
Server since there is no userdn set at that time. This is ok since
mod_admserv will use cached info if there is no LDAP handle present.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The afix addresses this issue by overriding the sie DN
with the userdn when when setting up the LDAP handle. We only override
the sie DN if the userdn is initialized.
Platforms tested: FC6
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158620&action=diff
16 years, 9 months
[Fedora-directory-devel] Please review: Bug 246683: Reimplement ds_create without setuputil code
by Rich Megginson
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246683
Resolves: bug 246683
Bug Description: Reimplement ds_create without setuputil code
Reviewed by: ???
Files: new files
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158484
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158486
Branch: HEAD
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.
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158485&action=diff
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158487&action=diff
16 years, 10 months
[Fedora-directory-devel] Please Review: (246651) Clean up dialogs when a jar file is not able to be downloaded
by Nathan Kinder
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246651
Resolves: bug 246651
Bug Description: When the Console attempts to download a jar file from
the Admin Server, a progress indicator dialog pops up as the download
progresses. If there is a problem with the download, such as the jar
file not existing on the admin server, an error dialog pops up, but
the progress dialog remains, just sitting at 0%.
To make things worse, the progress dialog keeps the focus, so the error
dialog is behind it. If you dismiss the error dialog, the progress
dialog remains, and you must manually dismiss it. This looks really
confusing when it happens.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The fix detects if there is a download problem, and gets
rid of the progress dialog in that case. I also improved the message
displayed in the error dialog to tell the user to make sure that the
proper console package is installed on the Admin Server.
Platforms Tested: RHEL4
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=158459&action=diff
16 years, 10 months