Um, problem? Indubitably!!! I'm sorry for the red mad face, but that seems like a pretty big bug. Any thoughts till or falko? I should elaborate. Clicking ON the user&email tab doesn't reset the pw, but clicking OFF the tab does. So if you click on user&email at all, the password will inevitably reset as soon as you view something else. Argh! I'm at a loss as to how I can avoid this, otherwise I'll have to keep a password protected database for all users so if I have to modify or view them I can make sure I retype the password. Frustrating. HELP!
Then there's something wrong on your system. The password is changed only if you type in a new password in the password field. If you don't type in anything then it is not going to be changed. Also have a look here: http://www.ispconfig.org/downloads/manual_en/manual_admin_en_src.htm#2_1_7
mmmm, perhaps there is something wrong with my system, but i doubt it. i clicked on "User & Email", then on "Advanced Settings", and I try to log into Uebimiau and I get this message: Code: Login error You cannot login with the username and password entered. Please check your username and password and try again. Back
I dont think the behaviouryou described is a general bug, otherwise we would have heard about that before. Lets try to track it down. 1) Create a user and verify that you can login with UebiMiau. 2) Have a look at /etc/passwd and /etc/shadow and note the lines for this user. 3) Go in the ISPConfig interface and change the tabs as you described. a) whats get written newly to the ispconfig logfile: /home/admispconfig/ispconfig/ispconfig.log b) Dies /etc/passwd and /etc/shadow gets changed. Is the password emptied in /etc/shadow ?
Right there with ya. Let's do this thing. Ready? Go! ... Done, user is "domain.dom-test". /etc/passwd: Code: domain.dom-test:x:10005:10003:Test Email:/var/www/web3/user/domain.dom-test:/bin/false /etc/shadow (edited for my comfort): Code: domain.dom-test:(encrypt_pass_here?):13161:0:99999:7::: Done, only this time I even pressed "Cancel" with the same result! Can't log into webby-meow! (how do you pronounce it, btw? a little off topic but what the hey.) /home/admispconfig/ispconfig/ispconfig.log: Code: # cat /home/admispconfig/ispconfig/ispconfig.log | tail 13.01.2006 - 09:05:55 => INFO - /root/ispconfig/scripts/lib/config.lib.php, Line 695: setquota -u domain.dom-test 0 0 0 0 -a &> /dev/null 13.01.2006 - 09:05:55 => INFO - /root/ispconfig/scripts/lib/classes/ispconfig_procmail.lib.php, Line 57: cp -f /root/ispconfig/isp/conf/forward.master /var/www/web3/user/domain.dom-test/.forward 13.01.2006 - 09:05:55 => INFO - maildirmake /var/www/web3/user/domain.dom-test/Maildir &> /dev/null, Line 106: maildirmake /var/www/web3/user/domain.dom-test/Maildir &> /dev/null 13.01.2006 - 09:05:55 => INFO - /root/ispconfig/scripts/lib/classes/ispconfig_postfix.lib.php, Line 136: cp -fr /etc/postfix/local-host-names /etc/postfix/local-host-names~ 13.01.2006 - 09:05:55 => INFO - /root/ispconfig/scripts/lib/classes/ispconfig_postfix.lib.php, Line 283: cp -fr /etc/postfix/virtusertable /etc/postfix/virtusertable~ 13.01.2006 - 09:05:55 => INFO - /root/ispconfig/scripts/lib/classes/ispconfig_postfix.lib.php, Line 288: postmap hash:/etc/postfix/virtusertable 13.01.2006 - 09:05:55 => INFO - /root/ispconfig/scripts/lib/config.lib.php, Line 1191: cp -fr /etc/apache2/vhosts/Vhosts_ispconfig.conf /etc/apache2/vhosts/Vhosts_ispconfig.conf~ 13.01.2006 - 09:05:55 => INFO - /root/ispconfig/scripts/lib/classes/ispconfig_system.lib.php, Line 696: /etc/init.d/postfix stop &> /dev/null 13.01.2006 - 09:05:56 => INFO - /root/ispconfig/scripts/lib/classes/ispconfig_system.lib.php, Line 696: /etc/init.d/postfix start &> /dev/null 13.01.2006 - 09:05:56 => INFO - /root/ispconfig/scripts/lib/config.lib.php, Line 1825: cp -fr /etc/proftpd_ispconfig.conf /etc/proftpd_ispconfig.conf~ Looks like all account creation stuff to me. Nope, still there. Does this have anything to do with me using certain characters such as pound (#) or bang (!) for example? Never had a problem using certain chars in Linux pw's before. Is that it though?
If /etc/passwd and /etc/shadow does not get changed, the account must be still valid... Have you tried to login with a "normal" not webbased pop3 client. Please try passwords without special charachters, did you get the same behaviour?
Well now that's a strange thing. Here's what happened: 1. Didn't change anything since unable to login via webmail, WAS able to log in via POP3 (T-Bird). 2. Sent an email to that account, dl-ed w/T-Bird no prob, then WAS able to log in via webmail! 3. Did the "click on / click off" thing, then could NOT log in either via webmail or T-Bird!!! 4. Sent myself another email thinking perhaps that was what fixed webmail earlier - no effect. OK, that worked fine. Must be the strange characters. That does concern me though, as Linux is cool with special characters and I have always liked to keep my pw's a little cryptic in and of themselves, just to avoid brute-force attacks and lucky guesses. Is there any way this can be added to ISPC v3? Would this be worthwhile to submit as a bug or a feature request? Thanks for all your help!
ISPConfig does not care about the characters used in passwords. The problems I've encountered sometimes where that the crypt function in linux seem to result in another hash then the crypt function in PHP.
Well ain't that a b!tch. Why should that affect standard POP3 connections though? It shouldn't rewrite the encrypted pw to /etc/shadow, right?
OK, new development: I just tried again with a different test account. I did the "click on / click off" thing, checked "/etc/shadow", and verified the encrypted pw was still OK. Then I tried loggin in via Uebimiau, got the error, checked "/etc/shadow" and the pw was reset to "*"!!! Weird. Then I tried just doing a "passwd <user>" in bash and got a completely different crypt pw in shadow. THIS FIXED THE ISSUE! The pw no longer gets reset to "*" when I do the click on/off thing and then check webmail. My friends, I appreciate all your help, but as a developer I would most definitely consider this a bug. Is there any way to force ISPC to use the Linux pw hashing algorithm instead of PHP's? Thanks. EDIT: The "bug" as I call it seems to be very specific and is not caused only by ISPC or only by Uebimiau, but a combination of actions between the two. Specifically, I have to click on/off in ISPC AND THEN attempt to log into the account via Uebimiau.
I think the problem might be that you use usernames with dots and hyphens (e.g. domain.dom-test). Linux doesn't like that...
That's news to me. If that's true, why would ISPC allow me to set the prefix as "[DOMAIN]"? That would definitely have a dot in it, and could potentially have a hyphen as well (e.g. my-domain-is-great.com). I guess I'll have to wait for ISPC v3 and those nifty virtual user names. I still think if ISPC would use Linux's "passwd" hashing algorithm it wouldn't be a problem, as that resolved the issue for me. Maybe I'll write a script to allow new customers to create their own "special character" passwords, put it in a web form on an SSL site, and that will be that - at least for now. Thanks for your advice.
ISPConfig has the Domain option beacuse some poeple wanted it even if it causes problems. Thats why it is not used by default and we dont recommend to use it. I think the best solution will be that we will disable the special characters in password chars until the issue is fixed in the PHP crypt function.
That makes sense, I could live with that. If it doesn't work, don't allow it! Any idea when they'll fix PHP?
I had the same Well i encountered the same behavior but not on all accounts. The passwords have !@% and the like characters and the usernames are webxx_username where username can have - or _ characters. I dont know why but there are 100 pop accounts, just some of them recently showed this behavior (linux update??) Anyway the brand new ISP config 2.2.8 seems to have solved this! thorsten
