Vedran B
Vedran B

Reputation: 33

Zpanel's proftpd can't create new ftp user (possibly after mysql update)

Problem:

I used to create and delete ftp user accounts from Zpanel's "file > ftp accounts" with no problems ever. I tried to create a new account today and it all seems OK in zpanel, the UI returns "success", the account is listed in zpanel permanently but i just cannot connect to it. FTP Error 530.

System information:

Possibly:

I've remembered i did a mysql server update a few weeks ago and that I didn't manage any ftp accounts since. Looking in the zpanel_proftpd.ftpusers table I've noticed that the new ftp accounts are not being written into the table.

I also checked:

On the side note

How to proceed ?

Before i start downgrading mysql or debugging some zpanel code I don't even know where to look for, I would like to get some answers.

If possible, a solution from someone who experienced this already but if not any of the following might help me pinpointing the problem:

Can I somehow see the DB response on zpanel queries upon ftp user creation?

Furthermore why zpanels notification window says "user created successfully" ?

How come zpanel keeps listing the newly created users if it doesn't find a user row in the database ? Did I wrongly assume that proftpd's user system functions like this ? are the proftpd users created somewhere else ? AuthUserFile does not exists but still all of the old users ftp accounts function properly.

where in the zpanel directory do I look for a php model that is processing ftp user creation?

Can all that suspicious log activity have anything to do with blocking ftpd somehow ?

I hope all the info helps. Thank you.

Upvotes: 0

Views: 659

Answers (1)

Vedran B
Vedran B

Reputation: 33

Answer:

The answer is that after updating to mysql 5.6 the installation created another my.cnf (/usr/my.cnf) which had sql_mode set to strict parameters (comment it out or change params). In the same time zpanel is logging every operation to a sql table writing down a dateformat string in a column and because of the sql_mode this was failing and consequentially aborting the rest of the queries.

side note

all the activity in the logs was due to this XOR.DDoS menace from China described here: http://blog.malwaremustdie.org/2014/09/mmd-0028-2014-fuzzy-reversing-new-china.html

my way to the solution started with "fail2ban" ...

Upvotes: 0

Related Questions