System issue da and proftp

D

Djunity

Verified User
Joined
Mar 9, 2008
Messages
243
Location
Holland
Hi all,

I got a strange system issue i hope someone can tell me the problem and how to fix.

We think that when a user changes his password proftp doesnt reload the password file becouse users caan loggin anymore untill me manualy reload proftp.

Second issue we had a reseller who went over its traffic limit, we then unchecked the suspend option on the account and raised the temp extra limit so the account should have enought traffic 25GB + 10GB temp extra the ussage at that point was 30GB.
During the night tally the account whent over 35GB traffic (about 55GB) the account again got suspended even when the suspend options was off.

Some how we think there is a mayor issue on this server when changing settings the prevents the services to automaticly reload the services so that the new settings are loaded.

I hope someone can help me out
 
Hello,

An what is there in directadmin logs? If you think that ProFTPd is not restarted, then learn it from logs and do some hand work. Fix in mind the ProFTPd PID and change password, and again learn its PID. Compare them. But! As far as I know, there is no need for ProFTPd to get restarted, on password changing.

Since, tally is done once per day (at night), user can overcome with badwidth.
 
zEitEr said:
Hello,

An what is there in directadmin logs? If you think that ProFTPd is not restarted, then learn it from logs and do some hand work. Fix in mind the ProFTPd PID and change password, and again learn its PID. Compare them. But! As far as I know, there is no need for ProFTPd to get restarted, on password changing.

Since, tally is done once per day (at night), user can overcome with badwidth.
Click to expand...

We think the problem occurs after a password change we do not really know how the problem occurs only know that is does, the proftp problem happend before after reload problem got solved but a few weeks later happend again

In the message log i can only find this after the nightly backup (at 3 o clock) is this Mar 13 04:02:19 server2 proftpd[29638]: 81.30.65.78 - received SIGHUP -- master server reparsing configuration file
In the direct admin system log i found this: 2011:03:13-10:43:02: proftpd rereaded


About the suspend problem:
Yes we know but how can it happen that when suspend option is on off in the config of the account that the account still got suspended thats basicly the question.
 
Last edited:
When your customer changes his/her password for a FTP account and looses access to a FTP server, can you with your any other login and password establish connection and go through authorization?

So you are even unsure, that's this is related. OK. Are you running CentOS 5?

About the suspend problem, you'd better ask John. We do not limit bandwidth for our shared hosting customers.
 
zEitEr said:
When your customer changes his/her password for a FTP account and looses access to a FTP server, can you with your any other login and password establish connection and go through authorization?

So you are even unsure, that's this is related. OK. Are you running CentOS 5?

About the suspend problem, you'd better ask John. We do not limit bandwidth for our shared hosting customers.
Click to expand...

i contacted john.

About ftp problem we are not sure indeed but assumed it has to do with password change becouse the issue the customers had, somewhere on the forum we found some post that mentioned to reload proftp, that indeed solved the problem for a while anyway.
This server is used for resellers and there customers only we got 1 reseller who has had this problem 2 times allready in 2 months time and also got another reseller who had the problem. We also do know that the customers of the resellers are not really active only the reseller them self are active on the server.
 
Second issue we had a reseller who went over its traffic limit, we then unchecked the suspend option on the account and raised the temp extra limit so the account should have enought traffic 25GB + 10GB temp extra the ussage at that point was 30GB.
During the night tally the account whent over 35GB traffic (about 55GB) the account again got suspended even when the suspend options was off.[/code]Double check that the domain itself doesn't have a limit. This is set by the User and is not related to the User limit.
Click to expand...

Login to DA as the User, go to:
User Level -> Domain Setup -> domain.com

and ensure the option "Same as Main Account" is enabled.

Also check:
/var/log/directadmin/system.log

Look for a line with:
Code: 
User testuser has been suspended: bw used: 611.7, bw limit: 600
OR
Code: 
Domain testdomain.com has been suspended for user testuser with 100000.000000 used of 1.000000
This will tell you if it's actually the User or the Domain being suspended.


As for proftpd, a restart/reload/reread is not required for the password files.
The only thing that requires the restart/reread is when new entires are added or removed from /etc/proftpd.vhosts.conf, as they can alter the password file chosen based on the VirtualHost present.

I would say to see if you can duplicate the login issue with this:
http://help.directadmin.com/item.php?id=212

but if stopping, then starting proftpd in debug mode fixes it, then it might be very difficult to debug.

Ensure your /etc/proftpd.conf closely matches the default template:
/usr/local/directadmin/data/templates/proftpd.conf

We don't want it to be using PAM, since that confuses things even more.
Related, if the IP is owned:
http://help.directadmin.com/item.php?id=122

John
 
DirectAdmin Support said:
Second issue we had a reseller who went over its traffic limit, we then unchecked the suspend option on the account and raised the temp extra limit so the account should have enought traffic 25GB + 10GB temp extra the ussage at that point was 30GB.
During the night tally the account whent over 35GB traffic (about 55GB) the account again got suspended even when the suspend options was off.[/code]Double check that the domain itself doesn't have a limit. This is set by the User and is not related to the User limit.

Login to DA as the User, go to:
User Level -> Domain Setup -> domain.com

and ensure the option "Same as Main Account" is enabled.

Also check:
/var/log/directadmin/system.log

Look for a line with:
Code: 
User testuser has been suspended: bw used: 611.7, bw limit: 600
OR
Code: 
Domain testdomain.com has been suspended for user testuser with 100000.000000 used of 1.000000
This will tell you if it's actually the User or the Domain being suspended.


As for proftpd, a restart/reload/reread is not required for the password files.
The only thing that requires the restart/reread is when new entires are added or removed from /etc/proftpd.vhosts.conf, as they can alter the password file chosen based on the VirtualHost present.

I would say to see if you can duplicate the login issue with this:
http://help.directadmin.com/item.php?id=212

but if stopping, then starting proftpd in debug mode fixes it, then it might be very difficult to debug.

Ensure your /etc/proftpd.conf closely matches the default template:
/usr/local/directadmin/data/templates/proftpd.conf

We don't want it to be using PAM, since that confuses things even more.
Related, if the IP is owned:
http://help.directadmin.com/item.php?id=122

John
Click to expand...

Suspend:
The reseller got suspended and all account of the reseller to.
In the log file i can find the following lines:
2011:03:15-00:10:33: Tally User klant00218 Begin
2011:03:15-00:10:33: Tally User klant00218 Complete
between these lines are lines that all user accounts of this reseller are suspended becouse the reseller got suspended.
2011:03:15-00:10:36: Reseller klant00218 suspended by Tally
2011:03:15-00:10:36: Tally Reseller klant00218 Complete

About ftp: i need to wait until the issue occurs again to run debug mode.
Thanks.
Click to expand...
 
Ok we finaly solved the suspend problem.

The thing that remains is the ftp problem.

After for example a new account is created either reseller or normal user account, wou wont be able to login with ftp with the newly created account details you will get login error on login details only after restarting ftp you are able to login true ftp.

Any one got any idea ?
 
FTP may not be restarting automatically as it should be after the account is created.

Jeff
 
And do you have an idea on why or how to fix it ?, this server is running a few months now and have this problem from start on.
Before we started using this server it was a test server for ipv6 after testing we did a reinstall of da and then started using it for customers
 
zEitEr said:
If it's needed, you can use

ftp_create_post.sh
ftp_modify_post.sh
ftp_delete_post.sh

to re-start FTP daemon.

See the link for details ftp_create_post.sh, ftp_modfiy_post.sh, ftp_delete_post.sh
Click to expand...

Added ftp_create_post.sh for ftp re-read this works gladly.

Do you maybe have an idea on why the new login details where not loaded on the ftp server after the account was created ? on all or other servers this isnt a problem.
 
Do you have a default built with the help of custombuild ProFTPd copy? Any additional mods? We have something similar on one of our servers. By us it happens very seldom, so it's hard to investigate it.

Did you try to ask anybody on ProFTPd mailing lists? I have no information why could this happen.
 
zEitEr said:
Do you have a default built with the help of custombuild ProFTPd copy? Any additional mods? We have something similar on one of our servers. By us it happens very seldom, so it's hard to investigate it.

Did you try to ask anybody on ProFTPd mailing lists? I have no information why could this happen.
Click to expand...

We use custombuild yes no additional mods just basic da install.

It happens all the time with new accounts and sometimes nobody could login even with old login details that worked before

Nope i havent posted on proftp list because i believed it was an bug in da not proftp itselve.
 
Hello,

Note, check to see if you're using the unified_ftp_password_file option. This should be enabled by default for new installs.

With this option enabled, proftpd should never need to be restarted, since the config files never change. The only thing that changes is the "unified" password file. (means all accounts in the /etc/proftpd.passwd, for all IP types, shared and owned). Related:
http://www.directadmin.com/features.php?id=1134
Code: 
cd /usr/local/directadmin
./directadmin c | grep unified_ftp_password_file
All of the post.sh script shouldn't be required... even if the unified_ftp_password_file password option is disabled... if there is a bug, we'd prefer to fix it.

If the password issue has nothing to with creating a new User, or changing IPs... and only reflects changing the password.. then I'm not too sure. Again, in this case, no restart/reload should be needed, since proftpd reads the proftpd.passwd (or ftp.passwd for owned ips if the unified_ftp_password_file option is disabled) at every user login. My only guess here would be if the OS or proftpd is caching something, when it should be re-reading the password file.


In any case:
1) Ensure you've got the latest version of proftpd (1.3.3e at the time of this post)
2) If in doubt, enable the unfied_ftp_password_file option.. although that may just be working around the issue vs solving it.
3) Last resort, using the post.sh script to reread/reload proftpd.


The default builds should be here:
http://files.directadmin.com/services/youros

or you should have the original in:
/usr/local/directadmin/scripts/packages/

Packages aside, it's best to have a compile for your OS right on the box, rather than a binary from some other system which may not match your libraries 100%.
You can use custombuild for this, eg:
Code: 
./build update
./build set proftpd yes
./build proftpd
or:
http://help.directadmin.com/item.php?id=82

John
 
Hi John,

Thanks for your response.

We updated and rebuild proftp begin this week to see if this would solve it so thats not the point.
The unified_ftp_password_file was not yet set in the directadmin.conf so i follwed the instructions on how to activate it.
We also have the post.sh file at this moment.

We have send out an mailling to all customers and have to wait and see now, i think this will solve the problem.

Thanks
 
You must log in or register to reply here.
Back
Top