Virtualmin Password Recovery module issue

Virtualmin
1
SYSTEM INFORMATION
OS type and version Ubuntu 22.04
Webmin version 2.001
Virtualmin version 7.2-1
Related packages webmin-virtualmin-password-recovery 1.12
Related packages Running on Azure VM with 5.15.0-1020-azure kernel

I’m encountering a repeated problem with several recent Virtualmin installs. I want to use the Password Recovery module, but after installation it doesn’t work. I have successfully installed & used in the past, in fact I still have it running fine on another VM, which I have been comparing with to try to troubleshoot. That I’ve had the same problem with several recent instances leads me to believe this is a bug.
I’ve had a quick look for other posts, while there are several on the Password Recovery module, only this one - the most recent - seems t describe the same issue: Usermin password recovery - again
“But: how do we really do the password recovery, if the button always redirects to new page with a webmin login?”

This is my experience, clicking the orange button on : DOMAIN/:10000/session_login.cgi opens a new, identical seeming, tab, but with address DOMAIN:10000/virtualmin-password-recovery/
On my older VM with working password recovery the addresses are the same, but the new DOMAIN:10000/virtualmin-password-recovery/ tab contains the expected password recovery page.

I have done some investigation, but am not the most skilled. I noticed that the link address from the button wasn’t correctly formatted, missing the double quotes for href (so href=/virtualmin-password-recovery/) but I think that’s not the cause of the issue - as I tried editing session_login.cgi (I know that’s not a permanent fix & the value comes from session_postfix= somewhere, but I can’t find the location of that, even in my VM that is working that entry doesn’t appear in e.g. /etc/webmin/authentic-theme/custom-lang), also if the address DOMAIN:10000/virtualmin-password-recovery/ is being reached it’s nothing to do with that link lacking quote marks.

I’m working away on the basis that if DOMAIN:10000/virtualmin-password-recovery/ is in the address bar on the tab then /usr/share/webmin/virtualmin-password-recovery/index.cgi is being called, but there is something wrong after that, probably in files that file then references/calls. I’m trying to troubleshoot by inserting breaks in index.cgi, but haven’t worked with Perl before & also caching (I think) is making changes hard to effect.

Any help appreciated - I’m hoping someone from Virtualmin team can comment as, as above, I believe this to be a general fault & not a glitch in a single install (appreciate it may be particular to e.g. Azure VM or maybe I keep continually making the same false step in install, however, again as above, I’ve done it right in past)

2

Hello.

We will have to take a deer look in to this problem. If you go to Webmin / Webmin ⇾ Webmin Configuration: Webmin Themes and change the theme to Gray Framed Theme, then logout – does the password recovery works correctly then?

3

Hi Ilia, thanks for the reply.
In grey framed theme the behaviour is pretty much the same.
The only slight difference is that instead of another log in screen appearing in a new tab under the address :10000/virtualmin-password-recovery/ the “new” log in screen replaces the “old” in the same tab (with address switching from :10000 to :10000/virtualmin-password-recovery/)

4

I am still chipping away at this one.
What I think I know so far:
Both my “working & problem servers” (problem = password recovery page not showing) have the same link associated with the orange button:
<a target="_blank" href="/virtualmin-password-recovery/" class="btn btn-warning"><i class="fa fa-unlock"></i>&nbsp;&nbsp;Forgot your Webmin password?</a>

Resulting in a browser window with address DOMAIN:10000/virtualmin-password-recovery/

The issue is about how that address is then resolved/treated. On the working server the link is followed to the index.cgi file in /usr/share/webmin/virtualmin-password-recovery/
On the problem server this is MOSTLY not the case & I simply get another window/tab with the Webmin log in page repeated.
However in the Chrome session I have open now somehow this has changed & “the problem” server is acting the same as the good server - password recovery page is reached.
So it’s fixed? No, as I now have the weird behaviour that if I enter DOMAIN:10000/virtualmin-password-recovery/ in this Chrome session all seems well, but if I copy that address to Firefox or Edge on same machine (or Chrome on another machine) I still have the issue.
It seems there is some tiny glitch in resolving DOMAIN:10000/virtualmin-password-recovery/ so that it now works in this one Chrome session, some link made or gap bridged & now things are behaving as they are supposed to.
But in a fresh browsing session I still have the issue.

5

Sorry. I remember about this issue, I just haven’t had a chance yet to look at it. I will update this ticket when it’s done.

6

Hi Ilia - any progress on this one?
Let me know if I can do anymore investigation.
I’m coming to the end of some other work & will try to get back to looking at this myself, though, as above, I’m at the limit of my knowledge/skill in taking further.

7

I’m starting another round of attempting to fix (or at last understand) this issue now.
If, by some chance, you have given this issue any further consideration & can provide me any information that will help me please let me know.

8

So far I have discovered that IT SEEMS that whatever I edit the link in /usr/share/webmin/authentic-theme/session_login.cgi to be
(e.g. I have tried creating a test.html file in the same /usr/share/webmin/authentic-theme/ directory & attempting to link to that)
when the button is pressed (the link used) you just get another copy of /usr/share/webmin/authentic-theme/session_login.cgi in a new tab

9

The work I’m doing - documenting full process for use of Virtualmin in my organisation - is now held up by the issue with Password Recovery Module & I’m not making progress either via this ticket or trying to solve it myself.
I’ve experienced the issue in multiple installs. The most recent was a trial of the beta installer that was avaialble for 22.04 compatibility when 22.04 wasn’t on the list of supported systems. The one before was the stable installer on 20.04.
As some time has passed since my last creation of a new Virtualmin VM I just checked & 22.04 is now listed as fully supported. Consequently I’m going to have a go at a fresh install in the hope things have changed & issue won’t be there. Grasping at straws, but I don’t have another route to go, other than getting someone more technically able to investigate the issue.

10

We have discussed it with @Jamie, and password recovery functionality will be implemented as WebminCore feature in the future.

11

@FrancisW so it’s expected that the “Forgot your Webmin password?” button will open up a new page with a URL like https://yourdomain.com:10000/virtualmin-password-recovery/

I didn’t quite follow what goes wrong after this point though?

12

Hi @Jamie
Thanks for your response. Let me rephrase the paragraph from my original post opening this topic, for more clarity:

Expected behaviour:
Clicking the “Forgot your Webmin password?” orange button on : DOMAIN/:10000/session_login.cgi opens a new browser tab which has the address DOMAIN:10000/virtualmin-password-recovery/ & displays the desired password recovery page.

Actual behaviour (on my newer installs, older installs are OK):
Clicking the “Forgot your Webmin password?” orange button on : DOMAIN/:10000/session_login.cgi opens a new browser tab which has the address DOMAIN:10000/virtualmin-password-recovery/ BUT this does NOT display the password recovery page, but “another copy” of the Webmin log in page (= pressing the orange password recovery button just opens another log in page with another orange password recovery button).

13

Seems like access to the password recovery module while not logged in isn’t working. Is there any anonymous= line in your /etc/webmin/miniserv.conf file ?

14

Yes, the line is:
anonymous=/virtualmin-password-recovery=

15

Try changing that to anonymous=/virtualmin-password-recovery=anonymous , then running /etc/webmin/restart

Also, is there an entry in /etc/webmin/webmin.acl for the user anonymous ?

16

I have made the change you specify, but it has not fixed the issue.

The line in /etc/webmin/webmin.acl is:
anonymous: virtualmin-password-recovery

17

Ok we found the bug that causes that anonymous= line to be incorrectly created.

After fixing it to be like anonymous=/virtualmin-password-recovery=anonymous , do you still get the same error when trying password recovery?

18

Hi Jamie
Yes I have made that change & no it has not fixed the issue

19

Hi @Jamie - do we have any progress on this?

I’d like to make clear my circumstances are perhaps different to people generally putting in a ticket.

  1. I have no real need to “fix” the particular Vmin install I’m working on/have running at the moment. It’s a test bed to help me develop documentation (though when I’m happy with my documentation I will create a new Vmin server based on it, that will be our new production server).

  2. What I do need is the issue I’m encountering to be solved “going forward”. If you were to say to me “We don’t seem to be able to patch your already created server, however we’ve made a change that we’re confident will mean a new install of Virtualmin & the Password Recovery module will not have the issue you’re encountering” that will be fine.
    That of course would mean you’ve found something & made a change to your install packages, I’m not saying that is necessarily what will happen, it may be that I am repeatedly making some mistake in my install, which causes the issue on a repeating & consistent basis (over maybe 4 installs now).
    I need to either know what wrong step I’m taking, so I can change it - or have you find there’s an improvement you can make your end. Either way I need a (working) password recovery function.

Thank you for your help so far on this.

20

So we found a couple of bugs in Webmin that can cause this kind of incorrect setup. And the next release (version 2.011) will fix this for future installs…