Bug 247283 - Multiple problems with CGIs used by Admin Server Console
Summary: Multiple problems with CGIs used by Admin Server Console
Alias: None
Product: 389
Classification: Retired
Component: Admin   
(Show other bugs)
Version: 1.1.0
Hardware: All Linux
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
Depends On:
Blocks: 240316 FDS1.1.0
TreeView+ depends on / blocked
Reported: 2007-07-06 17:09 UTC by Nathan Kinder
Modified: 2015-12-07 16:59 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-07 16:59:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
CVS Diffs (11.70 KB, patch)
2007-07-06 17:09 UTC, Nathan Kinder
no flags Details | Diff

Description Nathan Kinder 2007-07-06 17:09:01 UTC
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.

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.

Comment 1 Nathan Kinder 2007-07-06 17:09:01 UTC
Created attachment 158674 [details]
CVS Diffs

Comment 2 Nathan Kinder 2007-07-06 18:07:48 UTC
Checked into adminserver (HEAD).  Thanks for the review Rich!

Checking in admserv/cgi-src40/ReadLog.c;
/cvs/dirsec/adminserver/admserv/cgi-src40/ReadLog.c,v  <--  ReadLog.c
new revision: 1.8; previous revision: 1.7
Checking in admserv/cgi-src40/config.c;
/cvs/dirsec/adminserver/admserv/cgi-src40/config.c,v  <--  config.c
new revision: 1.12; previous revision: 1.11
Checking in admserv/cgi-src40/sec-activate.c;
/cvs/dirsec/adminserver/admserv/cgi-src40/sec-activate.c,v  <--  sec-activate.c
new revision: 1.10; previous revision: 1.9
Checking in admserv/newinst/src/adminserver.map.in;
/cvs/dirsec/adminserver/admserv/newinst/src/adminserver.map.in,v  <-- 
new revision: 1.5; previous revision: 1.4
Checking in admserv/newinst/src/register_param.map.in;
/cvs/dirsec/adminserver/admserv/newinst/src/register_param.map.in,v  <-- 
new revision: 1.6; previous revision: 1.5
Checking in mod_admserv/mod_admserv.c;
/cvs/dirsec/mod_admserv/mod_admserv.c,v  <--  mod_admserv.c
new revision: 1.32; previous revision: 1.31

Comment 3 Nathan Kinder 2007-12-11 18:18:03 UTC
To verify the fixes, you can do the following in the Administration Server Console:

- Ensure that you can view the logfiles.
- Ensure that you can modify and save any of the settings on the "config" tab.
- Check, then uncheck the "enable ssl" checkbox, then click save.  Ensure that
you don't get an error dialog stating that a cipher family is required.

Note You need to log in before you can comment on or make changes to this bug.