Problem generating random password

sce

sce

Verified User
Joined
Aug 22, 2008
Messages
101
Location
EU
Hey folks!

I have a weird problem. It seems I cannot generate random password for anything in DA (email accounts, ftp accounts...). When I click on the "2 dice" icon nothing happens. I even have a problem of entering my own password. Form becomes red, I see the popup, but no error message.

I tried with latest Google Chrome and Firefox, Win/Linux. I've also tried in "Incognito/InPrivate" mode and no cigar.
Server is CentOS7 64-Bit with all updates, DirectAdmin 1.63.3. (new install, couple of days old), skin is evolution, but its the same on enhanced skin.


I've posted a pic & video. Any Ideas what else to try?

Video:
 

Attachments

  • no_error.jpg
    no_error.jpg
    29 KB · Views: 7
Do you see any error in browser's console? This random password is generated using PHP file, so, it might be that there are some problems with it.. Does php -v works fine?
 
First of all, thanks for your time. No, there is nothing in console. I've tried different php versions (php1_mode) and no luck. php -v shows no errors.

Code: 
PHP 7.4.10 (cli) (built: Sep  8 2020 22:34:44) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.10, Copyright (c), by Zend Technologies

But now that you mentioned it's php problem, i've tailed directadmin's error.log and I do see these errors exacly when I click on "dices" in DA.

Code: 
executeAsUser('/usr/local/bin/php', 512, diradmin, 1, stdin_txt, int *child_pid, *snd, group=(null)): wrt_remain=2554: Error piping txt to stdin: Broken pipe

I've rebuild php atleast 10 times. Any thoughts?
 
The way DA gets a random password, is with:
Code: 
/CMD_JSON_VALIDATE?json=yes&action=get&type=password&value=yes
DA internally generates the random passwords, but if you have enforce_difficult_passwords=1 turned on, then that's likely where the php issue is coming form. DA will keep sending new passwords to that script until one of them passes (20 tries before it gives up).

Thus the script that's probably having issues is either:
Code: 
/usr/local/directadmin/scripts/custom/difficult_password.php
or
Code: 
/usr/local/directadmin/scripts/difficult_password.php
If you have the first (custom) instance, rename it to something else.. else it would need debugging.

If you only have the 2nd default one, then it would need to be tested by passing all of the env vars to it, before running the script.... we'll cross that bridge when we get there as assembling the list may take a bit of work. If you run the CMD_JSON_VALIDATE command, with DA in debug level 76, that's specific to the tokenizer calling the script, so you'd get a bit more useful info in the output, including the list of evn vars to pass it.

John
 
Possibly even trying the most basic method.. eg:
Code: 
[root@es6-64 scripts]# password=AbCd123! ./difficult_password.php
Password OK
 
Hi, Thank you for your answers and time. Yes. This seems to be the problem. If I disable enforcment, it works OK. If I enable it, It does not. I've tried your test (post #5) and that works. No worries. As of now I will not enforce users, we are all IT guys. I will try this on my other two servers.

Thanks
 
sce said:
Hi, Thank you for your answers and time. Yes. This seems to be the problem. If I disable enforcment, it works OK. If I enable it, It does not. I've tried your test (post #5) and that works. No worries. As of now I will not enforce users, we are all IT guys. I will try this on my other two servers.

Thanks
Click to expand...
What's the version of DA there?

Code: 
/usr/local/directadmin/directadmin o

If it's possible to get access to the box, we'd like to investigate it, even if it's first report ever seen :)
 
Code: 
Compiled on 'CentOS 7.0 64-Bit'
Compile time: Jun 10 2020 at 14:36:27
Timestamp: '1591821355'
Compiled with IPv6
Static binary: yes
gettext support: yes
gettext path: /usr/local/directadmin/data/lang

I can give access if needed ofc. I'm just in the process of testing this on totally another box to see if I can reproduce this.
 
I can report that I have the same problem on the other box. However the 3rd box works fine. Box1 and Box2 (both have problems) are from the same provider (their licence). The 3rd box is from different one. All 3 have the same DirectAdmin info as above. Hopefully that helps.
 
OK, testing more here (to help debug), the call to
Code: 
/CMD_JSON_VALIDATE?json=yes&action=get&type=password&value=yes
in debug level 76 would give this... your variables may be different. Use the value that generate the error for you. Also check your special_characters_in_random_passwords state, in those chars are throwing the script errors.
Code: 
0: difficult_password_length_min=6
1: language=en
2: password=v5vE306vH
3: random_password_length=8
4: random_password_length_max=10
5: special_characters_in_random_passwords=0
The above setup would be:
Code: 
language=en password=v5vE306vH random_password_length=8 random_password_length_max=10 special_characters_in_random_passwords=0 ./difficult_password.php
If anyone else runs into this, we'd love to debug further. If needed for you, create a ticket, we may need to login to see exactly what's up, as Martynas mentioned, this is the first we've seen, so want to squash it if it's a bug somewhere :)

John
 
I'm sorry, but its always "Password OK". I've tried 10 possible combinations. I don't really need this but I can still give access.
 
Thanks! But I can't as it is "VPS" licence. Can I email it on support@?
 
Done. Thanks again. Hopefully we can get to the bottom of this. If you find a fix, I can also try to implement it on the other "non working" box.
 
Issue found, but we believe it's saved in the VPS template from the provider.
In this case, php could not run as anything lower than root due to:
Code: 
bash-4.2$ ls -lad /usr/local/icu
drwx------. 7 root root 4096 Aug 16  2018 /usr/local/icu
bash-4.2$ ls -lad /usr/local/icu/lib
drwx------. 4 root root 4096 Sep  9 21:24 /usr/local/icu/lib
where setting those 2 dirs to 755 should address it.
Also explains while manual testing (as root) didn't show the error, as root wasn't affected.

John
 
  • Like
Reactions: sce
Have you tried clearing your browser cache or checking if there are any browser extensions causing conflicts? Sometimes, extensions can interfere with JavaScript functions like generating passwords.
 
You must log in or register to reply here.
Back
Top