Email routing problem when restoring reseller w/o all domains

[nobaloney]

I've found what some might consider a bug.

I had a reseller with one site which wouldn't run after a PHP version change, so we moved him to a machine still running the old version:

We first backed up and restored the reseller (no users) to the server running the older version of php.

Then we backed up and restored the specific user.

When done, we had a reseller account with no users in the user list except the one user we'd backed up and restored.

But the domain names hosted in all the user accounts in the machine we were moving FROM, were all in the /etc/virtual account. The end result was that the user who'd been moved couldn't send email to any other use, who had not been moved but was still on the original sever. Because exim thought the domain names were hosted locally.

The only workaround after the fact was to manually remove the the domain names affected from the /etc/domains file.

to make sure no one could add or remove a domain, and so change the file out from underneath us, we had to disable DirectAdmin during the time it took to make the changes.

Design decision? Feature? Bug?

Personally I vote for the latter.

The easy fix I can see is to not restore the user list from the reseller backup to //etcvirtual/domains. I've thought this out and I believe it will work and not cause additional problems.

Discussion is welcome.

Jeff

 

[DirectAdmin Support]

Hi Jeff,

I'll need clarification here:

But the domain names hosted in all the user accounts in the machine we were moving FROM, were all in the /etc/virtual account

Old php box, moving to: box A
New php box, moving from: box B

Assuming you're moving the Reseller and User from B to A.

--------

1) Ok, so for clarification, you're saying that domains from Users that exist on B, ended up in the /etc/virtual/* directory of A... but those users were not part of the migration?
2) If I'm understanding correctly, domains appeared on box A, that should not have been in any backups at all?

If that's true, I'm not clear where the domain names would have been listed to get restored..

I have a feeling I'm not clear on what the actual conditions are.

Fill me in, and we can go from there.

John

 

[nobaloney]

I wasn't moving the reseller.

The reseller had (for example) 10 usres.

I had to move one of the users from da63 to da16, for php compatibility.

The following backups/restores were made using the admin level 'Admin Backup/Transfer' facility.

I first backed up the reseller from da63, transferred the file to da16, and restored it there. I don't remember if I checked to see if there were any usernames in the userlist as shown on DirectAdmin on da16, but if there were, I marked them all for delete (and then of course likely got the 'not on server; removing from list' error message).

Once I had an empty reseller account on da16, I backed up da63's copy of the user, transferred the file to da16, and restored it there.

When I was done the usrlist for the reseller on da16 had onlky the one user listed in it and everything appeared to work, but about two weeks later the reseller notified me that the user couldn't send mail to any of the other domains in his reseller account (in other words from da16 to da63).

I checked, and sure enough all the domain names from the reseller account on da63 were in the etc/domains file, even though the users weren't listed under the reseller. Since the user had about 30 domains it took a while to clean up the /etc/domains file on da16 so email destined for those domains would be transferred according to DNS, and not try local delivery on da16.

During the manual repair I had to shut down directAdmin so no users could add or delete domains from /etc/domains while I was working on it. (My command-line editor, joe, warns me if a file is changed while I'm working on it, but it doesn't have a way to merge changes automatically.)

I think I'm calling it a bug; it's behavior I didn't expect.

I believe it can be resolved by not copying the domain list to the etc/domains file when restoring a reseller, but rather by keeping what's there already (since users and domains already on the server are not touched by a restore of other users) and simply add the domains for any users restored who didn't already exist.

I hope this is more clear.

Jeff

 

[DirectAdmin Support]

Hi Jeff,

Sorry, I must be tired.. still not quite clear.

The extra domains that were in the /etc/virtual/domains file.
If I'm reading correctly, did they belong to the Reseller on da63?

If the domains belonged to the Reseller, and that Reseller was backed up from da63, and restored on da16, then that Reseller would include all domains created at the User Level on da63, restored on da16.
So if you restore the Reseller from da63, and restore him on da16, those domains will be included, as they're part of his account.

Also, this users.list files, although in the tar.gz backup, is not part of the restore.. it's not looked at during the Restore process.
Looking at the code, the only Reseller Level items that are restored are the packages, and the reseller.history file.

John

 

[nobaloney]

Sorry, John; I didn't expect a problem so I didn't track everything I did.

I do believe that domains not hosted on da16, but which had been hosted on da63, had their domain names in the /etc/virtual/domains file on da16 after I restored only the backed up reseller account (but not any of his users) on da16.

I'll have to move accounts again at some point, and when I do I'll check more carefully every step of the way.

Thanks for your help.

Jeff

 

[DirectAdmin Support]

For the mystery domains that appeared in /etc/virtual/domains on da16, who owned them on da63?
Was that owner backed up and restored on da16?

I've just added domain creation/deletion accountability to the system.log (available in the pre-release binaries within a few days)
It will tell us what mechanism created a domain, either User creation, API, User restore or manual User creation.
Same idea for deletion.
Should it happen again, we can better track what's going on.

John

 

[nobaloney]

For the mystery domains that appeared in /etc/virtual/domains on da16, who owned them on da63?
All the users under the reseller I was migrating over, even though those users were not being migrated.

Was that owner backed up and restored on da16?

No. The reseller was, but not the owners.

I've just added domain creation/deletion accountability to the system.log (available in the pre-release binaries within a few days)
It will tell us what mechanism created a domain, either User creation, API, User restore or manual User creation.
Same idea for deletion.
Should it happen again, we can better track what's going on.

I'll be building a new server a week (or so) for the next few weeks, and will transfer resellers to them from other (older) servers.

So hopefully we'll find something.

Thanks.

Jeff