[webmin-l] Spurious duplication in URL path

[Chris M. J. <ch...@gm...>]

Hello, webadmin-list world!

Using Webmin in an Apache "subdirectory" is causing some scripts to
duplicate the prefix directory in URLs when it &redirects.

I've followed the instructions on http://webmin.com/apache.html to set
up Webmin to be available in an apparent subdirectory, namely
http://$hostname/admin (I have not used virtual hosts deliberately,
since to use them across the many servers on the LAN would require
some non-trivial changes in the local DNS).

Using Debian "sarge" (a.k.a. 3.1) stable, Apache/2.0.54, Webmin/1.180
(both of which being the most up-to-date available in the
distribution), I have the following configuration in
/etc/apache2/sites-enabled (apparently it didn't like being in
/etc/apache2/conf.d):

# Apache config for Webmin

# Webmin files are installed in /usr/share
Alias /admin /usr/share/webmin
<Directory /usr/share/webmin>
        AddHandler cgi-script .cgi
        DirectoryIndex index.cgi
        # Reason for FollowSymLinks explained later
        Options ExecCGI FollowSymLinks
        SetEnv WEBMIN_CONFIG /etc/webmin
        SetEnv WEBMIN_VAR /var/webmin
        SetEnv SERVER_ROOT /usr/share/webmin
        SetEnv MINISERV_CONFIG /etc/webmin/miniserv.conf
        # This shell expansion is mental-only ;-)
        AuthName "Webmin on $hostname"
        AuthType basic
        AuthUserFile /etc/webmin/htusers # file created with htpasswd
        require valid-user
</Directory>

As well as this, the CGIs themselves are now passing the -U option to
perl, and /etc/webmin/config now sports the line

        webprefix=3D/admin

When I try to execute some of the scripts, the prefix in the path gets
duplicated, e.g.

http://$hostname/admin/dhcp/list_leases.cgi - clicking on a lease to
delete it ...
http://$hostname/admin/dhcp/delete_lease.cgi - when it's done, it
redirects to ..
http://$hostname/admin/admin/dhcp/list_leases.cgi - note that "admin"
now appears twice

Originally, this returned a 404 (obviously, the path didn't exist).  I
added in a symlink, which predictably returned 403.  When I added the
FollowSymLinks option, I now get the curious message:

    Access denied : User root is not allowed to use the  module

(Note two spaces before "module", suggesting there's an empty variable
in there somewhere).

Is there something I've missed in my configuration, or is there a bug
(possibly one that has already been fixed) in there somewhere?

TIA,

--
Chris Jackson
Now with enhanced time-wasting capabilities
Non-Terminal Boredom: http://www.xpns.co.uk/life/