Migrating users from one server to a new one.

D

desynced

Verified User
Joined
Dec 29, 2008
Messages
46
We're in the process of upgrading some older servers to brand new ones and on the first few, we ran into a problem. We backed everything up and restored on the new server. But for some reason, the primary FTP account is not transferring over, or the settings isnt.

For instance, on the old server, the users can sign in with their primary account name just fine. When I move their site over to the new server, the primary account can no longer login but all of the FTP accounts made through DirectAdmin's control panel on the old server can log in.

Both servers are running the latest DirectAdmin, both are on CentOS 5, but the new server was installed and went "live" about 2 months ago. We had some previous issues that did not allow us to migrate right away. We migrated all the sites, and then I remembered I havent updated the packages on the server since the original install. I did notice ProFTPD was one of the updates. All the updates did install fine as far as I could tell.

But now when I look at proftpd.passwd, all the primary accounts are missing but all the extra FTP accounts ([email protected] accounts) made through the DA control panel are there. Any ideas on how to restore all the primary (username) accounts back into proftpd.passwd?

Sadly, we thought everything was working on these servers and the old server has just been deracked, boxed up, and is now sitting in the hands of UPS Ground so I cant access the old server. But of course NOW is when a couple clients noticed the FTP issue.
 
Last edited:
Nice find! But it only shows 6 of the user accounts instead of all 147 on the server. Any other ideas?
 
Last edited:
For users that are not being added, does the /home/usernamehere/.shadow file exists and contains a pass string?
 
Yes, it contains a file with a 32 character line with random letters, numbers, and characters.

Example:
$1$OLXJYpKe$bARVz1KkSdaZb4yd.r0gw.

Edit: I just noticed the 6 accounts have a different IP (static ip) than the primary IP (shared IP).
 
Last edited:
Careful, because its a (crypted) password.

But if you are sure that each user not showing up in the proftpd password file, does have a .shadow file, then theres something odd going on. Maybe someone else has a suggestion.
 
Arieh said:
Careful, because its a (crypted) password.
Click to expand...
That was pretty much random characters except the first $. :)

Arieh said:
But if you are sure that each user not showing up in the proftpd password file, does have a .shadow file, then theres something odd going on. Maybe someone else has a suggestion.
Click to expand...

Yeah it has me boggled also. I've been searching the forums and did a few suggestions, but nothing has fixed it yet. I see some people suggesting migrating over to PureFTPD, but at the same time see many problems also. But I'll try that as a last resort. Thanks for the link though. Some reason I didnt find that KB page but read some others.
 
Hello,

If the system accounts are missing from the /etc/proftpd.passwd, then the metioned article should be adding them.

When you run the fix.sh (without piping to anything), is any text output?
Note that the script itself doesn't automatically fix the proftpd.passwd.. it's running the script with the ">> /etc/proftpd.passwd" is what will add the missing accounts to the file.
If you run "./fix.sh" without any options, and you see output, then the values have not yet been added to the proftpd.conf.

If there are no values output, then everything should be fixed.
If that's the case.. and you can confirm that the accounts are in the proftpd.passwd.. but they still cannot login, then first try resetting the password..as it may be incorrect.

Last thing to try is to run proftpd in debug mode to get more info:
http://help.directadmin.com/item.php?id=212

New servers run with "unified_ftp_password_file" enabled, so everything should go into the /etc/proftpd.passwd file.. and owned vs shared IPs won't have any effect.
Also, moving to pureftp won't change anything, since pureftp also uses the proftpd.passwd file. If the proftpd.passwd file is incomplete, then that's the only thing we need to worry about.

John
 
DirectAdmin Support said:
Hello,

If the system accounts are missing from the /etc/proftpd.passwd, then the metioned article should be adding them.

When you run the fix.sh (without piping to anything), is any text output?
Note that the script itself doesn't automatically fix the proftpd.passwd.. it's running the script with the ">> /etc/proftpd.passwd" is what will add the missing accounts to the file.
If you run "./fix.sh" without any options, and you see output, then the values have not yet been added to the proftpd.conf.

If there are no values output, then everything should be fixed.
If that's the case.. and you can confirm that the accounts are in the proftpd.passwd.. but they still cannot login, then first try resetting the password..as it may be incorrect.

Last thing to try is to run proftpd in debug mode to get more info:
http://help.directadmin.com/item.php?id=212

New servers run with "unified_ftp_password_file" enabled, so everything should go into the /etc/proftpd.passwd file.. and owned vs shared IPs won't have any effect.
Also, moving to pureftp won't change anything, since pureftp also uses the proftpd.passwd file. If the proftpd.passwd file is incomplete, then that's the only thing we need to worry about.

John
Click to expand...

Hi John,
Thanks for the reply. When I ran that script, it showed only 6 users as the output, not all of the users on the server. Even the accounts that have a .shadow in their home directory is not being listed with this script.

I have confirmed the ownership of .shadow is user/mail.
 
It only echo's the users that are not already in the file - which are those 6 users, because as you said they have their own IP addresses - and those users have their own ftp.password file (http://help.directadmin.com/item.php?id=122). So it kinda makes sense I think. Are you sure the other users are not in the /etc/proftpd.passwd file?
 
100% possitive. When I edit the proftpd.passwd file, it only contains the [email protected] accounts (the ones the users created through the control panel), and none of them are just the primary username accounts. But after running the above script, I now have the primary accounts of the static IP users, but still none of the primary users on the shared IPs.

On a side note, when backing up from one server to another one, it doesnt matter if the server has 2 separate IP addresses or anything does it? Besides the old servers (IBM xSeries, 4 single core Xeons) which were configured as RAID1 on a couple old Ultra SCSI disks to new the new servers (Dell PowerEdge 2 Quad core Xeons) which are configured for RAID5 and the new servers located at a different data center with different IP address, and both are running CentOS 5.8 with the latest DA (1.40.3). The old servers were running x86 CentOS while the new ones are running x64 CentOS. Also the licenses of DA are different, which I doubt would be any problems. So there shouldnt be any problems backing up and restoring between the two, correct? I've never had problems doing this in the past, but this is the first migration we've done going from a 32bit OS to a 64bit OS via DirectAdmin.
 
Last edited:
None of these should matter.

What I'm about to write is totally off the wall; please correct me, anyone :):

Did you move from a server without unified password file to a server with? Or vice-versa?

Just wondering if this makes a difference.

Jeff
 
nobaloney said:
None of these should matter.

What I'm about to write is totally off the wall; please correct me, anyone :):

Did you move from a server without unified password file to a server with? Or vice-versa?

Just wondering if this makes a difference.

Jeff
Click to expand...

That's something I'm not 100% sure on. Neither of my techs recall changing that on any of the servers. Another question was brought up though, would using different version of custombuild have any effect? Im not sure what version was used on the old servers (whatever version was the latest a couple years back).

Also we're planning to wipe these servers tonight and do a reinstall. Since we're moving to datacenters local to us, we can watch closely during the install and see if anything happens (errors, etc).
 
Last edited:
Custombuild differences shouldn't cause a problem. If you find they do, please report it as a bug.

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