vsftpd or pureftp addition?

Should DA switch ftp servers?

  • Yes, switch as I don't like all these exploits!

    Votes: 33 78.6%

  • No, keep it as is I like constantly updating proftp.

    Votes: 9 21.4%
  • Total voters
    42
Status
Not open for further replies.
As far as I'm concerned I fully agree with your complete reply.
Indeed the adjustments to be made for people running DA are minor compared to possibility's when pure-fptd/vsftpd is added.

So my vote would be to go for option 3 you mentioned.
 
I too like your option 3. I've never understood why anyone needed user logins for ftp with dedicated IP#. A slight convenience perhaps, but most users input their username/password combinations only once.

I would add however that when writing the conversion script you might want to also offer a mode in which it would run, make NO changes, but list the logins it would need to change, so we could notify our users, easily, in advance.

Thanks, John, for helping clarify this.

Jeff
 
Hello,

Thanks for the suggestion Jeff. I've added a simulate=yes option so you can see who you need to notify. To help make your lives easier I've also output the email address of the DA User (from the user.conf) so you can use that to email them if you want to do it all manually.

Sample output for the simulation:
Code: 
[root@server directadmin]# echo "action=convert&value=unifiedftp&simulate=yes" >> data/task.queue
[root@server directadmin]# ./dataskq d1
Debug set to level 1
In debug mode, level 1
Simulating converting to unified ftp password file.  Only accounts with owned IPs are used.
unified_ftp_password_file=1 is not set. We're only in simulation, so we'll ignore that and continue.

Checking User ipcheck : (email address: [email protected])

Checking User iptest : (email address: [email protected])
    account notdefault has changed to [email protected]
    account test has changed to [email protected]

Checking User ipftptest : (email address: [email protected])

Checking User testuser : (email address: [email protected])
    account ftptestish has changed to [email protected]

Simulation complete.  Skipping all changes to disk
[root@server directadmin]#
The full version without simulate=yes will go further. It then backs up the main proftpd.passwd, then reads it in, and merges the converted accounts to it, then writes the proftpd.passwd. Note that the above text are not *all* values that are merged. They're only the values that change. There will be other accounts which were already in the [email protected] format, but they don't need to know about the change since their format is unaffected and they won't notice anything different.


And o zEitEr, yes, I've taken into account the ftpsep option.

John
 
Hello,

The coding for this is now done. If you'd like these binaries to try out, grab them from your Clients Section. Click your license, and follow the pre-release link.

Please read over the versions entry for this change so you understand what's going on.

I do recommend using the simulate=yes option first, to both verify that things are doing what they're supposed to be doing, and so you have some notice for any clients that need them.

With these changes, you can use pureftp (or vsftpd).
Install it as per it's instructions. Set the password file to point to the /etc/proftpd.passwd. Edit /usr/local/directadmin/data/admin/services.status and replace proftpd with pureftpd. Ensure the bootscript for it matches the running process's name.

Note, these are "pre-release" binaries, so they don't have a massive amount of testing on them yet. You can go back to the original binaries if needed.

John
 
Hello,

The username that you login to DA with will be unaffected for ftp. These are the ones that exist by default when the DA user account is created. They will *not* be affected.

The only usernames that will matter are created ftp accounts (User Level -> FTP Management -> Create FTP Account) which are on the main domain (usually the first domain created under the User), and where the User is on an "owned" IP address. These created ftp accounts have the login format "username", since they've got their own IP, with proftpd they can have their own ftp.passwd file, so they don't need the @domain.com to be unique, since only that User has access to the the file. Additional domains on that owned IP already use the [email protected] format, so they don't matter. Both the username and [email protected] ftp accounts from Users on owned IPs will be moved into the main proftpd.passwd file. Since the [email protected] format is already distinct enough, they're fine, no change needed. Only the main domain ftp accounts from owned IPs need to be changed.

If you want to see which accounts will be affected, you can run with the simulation=yes mode, and DA will tell you everyone that will be affected.
For example, in the above post #44, only 3 accounts are affected on that test system.

Note, that without using this method of unifying the ftp password files, DA will disable the multi-IP per user/domain tool. Both the multi-ip and old ftp account systems are complex, too much so to have both together. Hence this is a one-or-the-other type scenario. The loss of the "username" format is quite minor as compared to the number of positives that will come out of the change.

New DA installs will use the unified ftp password setup by default, thus they'll also have multi-ip enabled.

It will be recommended (after testing and release) that everyone make this conversion.

John
 
DirectAdmin Support said:
The only usernames that will matter are created ftp accounts (User Level -> FTP Management -> Create FTP Account) which are on the main domain (usually the first domain created under the User), and where the User is on an "owned" IP address. These created ftp accounts have the login format "username"...
Click to expand...

Sorry, but now I am totally confused.

Because when one of my users create additional FTP accounts, the username then is in this format: [email protected] - but reading your answer it seems like it is not, and that this would be the change?

All my users default (S)FTP accounts created by DA have (the once that can't be deleted) this format: username

All extra FTP accounts my users create them self have this format: [email protected]

I am running DirectAdmin v.1.36.2.

Edit: Question: Will the usernames in the format "username" for the default DA FTP accounts (the once that can't be deleted) change?
 
Hello,

Because when one of my users create additional FTP accounts, the username then is in this format: [email protected] - but reading your answer it seems like it is not, and that this would be the change?
Click to expand...
Most ftp accounts already have the [email protected] format.

Again, it's only a small subset of the ftp accounts that exist on your server.

To have the "username" format, the following must be true:
1) The User account must be on an owned IP
2) The domain the ftp accounts are being created on must be the "main" domain. You can check this by going to:
User Level -> Domain Setup

the domain that is in bold is the main domain.
3) But more specifically, the value:
Code: 
defaultdomain=yes
must exist in:
/usr/local/directadmin/data/users/username/domains/domain.com.ftp

this value is not always set to yes, sometimes even with a default domain being set... so again, it's not likely going to affect the bulk of the accounts you have.

For the conversion, the fewer accounts the better, hence if any of the above are false, it will just mean far fewer headaches for you if/when you convert to the unified password file.

John
 
DirectAdmin Support said:
To have the "username" format, the following must be true:
1) The User account must be on an owned IP
Click to expand...

All my users default FTP user accounts created by DA when the account is setup have the format "username", and they are on shared IP. Is that not normal?

All those FTP user account will change to "[email protected]" in the next DA release?
 
Hello,

No, the default ftp Users (created with the DA User account) will all have "username" and are not touched. This is normal and not related to the issue.
I shall start calling these accounts system ftp accounts

Shared IP accounts are not affected for the conversion. Only owned IP accounts are.

These system ftp accounts will remain in the "username" format, they're untouched. It's only the virtual ftp accounts that the User has created via his User level.. and only if the numerous things above are all "true", which will be affected.

This describes how the old system works:
http://help.directadmin.com/item.php?id=122

So the conversion does not affect system ftp accounts.
It only affects virtual ftp accounts, and only if points 1 2 and 3 are true in my previous post.

You can check to see if this applies to them by logging into their account, go to their "FTP Management" section. Under "Account", (ignore their system ftp account) if you see their virtual ftp accounts listed as "user", then it applies to them. If you see their virtual ftp accounts listed as [email protected], then those are not affected.

Again, for the full list of affected accounts, run in the simulate=yes mode.

John
 
Another issue (or probably you'd call it a non-issue): if you create ftp ac****s from the command line (as we occasionally do, for various reasons), they won't be affected either, and will use just username as the username.

Jeff
 
Now for the less intelligent... (jajaja)

if i want to change proftpd to pure-ftpd these are the steps:

1.) Download the pre-release binaries for my client area
2.) Execute:
[root@server directadmin]# echo "action=convert&value=unifiedftp&simulate=yes" >> data/task.queue
[root@server directadmin]# ./dataskq d1
without simulate=yes
3.) Install pure-ftpd

is this ok?????

i don't find any option in custombuild for pure-ftpd, so imagine that i have to do it manually???

thanks in advance.
 
Hello,

On top of the new build scripts, you also need new DA binaries which are not yet in pre-release (not quite done yet). The current pre-release binaries (as of Dec 8th) don't have the specific pure-ftp code to rebuild the user database, which is needed each time a user is added, removed or modified from the password file. (you can do it manually now if you want). I'm hoping to have the coding done for it and put them into pre-release in the new few days.

John
 
Status
Not open for further replies.
Back
Top