Best practice to add and remove domains
I initially established a free hosting account with a host that provides VistaPanel. That initial account is a subdomain of the server domain that I ended up on. I established a couple of domain accounts of my own and then had to move a client domain to the account. That is when I discovered that the free host was not providing basic email account service, which was essential to this client's website. So, we signed the client up for a premium account that provides cPanel with the same company, which happens to be located on a different server. At that time, we asked the provider to migrate the client domain to the new account. Instead, they migrated all four domains. I got them to restore the account functionality for the domains that should not have been migrated back to the free account and have confirmed that the sites are being served from it. But copies of the migrated files remain in the File Manager of the premium account.
My first question is, what is the best order in which to remove these "domains" and their attendant files from the premium server, and will they automatically repopulate on their own, as I do not have access to information about how the host migrated the domains in the first place? All of the domains are listed on the "Domains" page in cPanel, all are listed on the "Addon Domains" page and their document root listings place each respective domain in its same named folder in public_html, as in public_html/domain2.tld, and each has a related, albeit random, listing on the "Subdomains" page as in abcde.maindomain.tld, generated by the host during the migration, that roots to the same/cooresponding folder identified on "Addon Domains", as in public_html/domain2.tld. So, to dismantle and remove the unnecessary files, should the "Subdomains" or the "Addon Domains" be deleted first? I assume I should delete these listings in cPanel before deleting the files via FTP or the File Manager.
The host also left a residual "root" folder chain in public_html that documents the migration path and holds an additional copy of the domain files. Can this safely be deleted?
To complicate these questions further, I use Custom MX Records on the free account to allow a working email address for each of the two domains hosted there to be created on the premium account and I need to preserve these email addresses. Can these email addresses be maintained while still deleting the Addon Domains/Subdomains in cPanel and/or their attendant directories and files as I propose?
Another new issue: I am adding a new Addon Domain to the premium account. My first attempt created the newdomain.tld folder at the root of the site, which is different than when the migration took place before. Based on my prior experience, I edited the document root to place the site files at public_html/and (abbreviated new domain). I still haven't directed the DNS for the site to these servers because a prior iteration still exists and I need to test the site. The host has directed me to edit my hosts file to see the site on my system for testing purposes. Which location for the document root is current best practice for editing of the hosts file to work for me?
Thank for your time,
Mark Harrison
-
Hey there! Normally I would just recommend removing the Addon Domain through cPanel and then deleting the content through File Manager, but then you mentioned the email accounts. Can you let me know more about how the custom MX records are created and handled on the system? 0 -
This info is from the respective cPanels... At the free account: Email VistaPanel options Email Accounts NONE Forwarders 1 MX Entry 2 SPF Records NONE Webmail available"not sure why, if no email accounts? It looks like the MX Records on the free account were created by me: Domain MX Record Priority addondomain1.com mx.byethost.com. 1 addondomain2.com mx.byethost.com. 1 Forwarders 1 forwarder from addondomain1 address to external address working At the premium account: Email Accounts 1 default address created by host 3 main domain addresses 1 addondomain1 address used as sender for webform 1 addondomain2 address used to send email when ISP email was down Forwarders 4 main domain forwarders Email Routing NONE DNS Zone Editor main domain A Records 41 includes subdomains CNAME 2 MX Record 1 TXT Rec 7 includes subdomains addondomain1 A Records 8 CNAME 3 MX Record 1 TXT Rec 3 addondomain2 A Records 8 CNAME 3 MX Record 1 TXT Rec 3 addondomain-premum A Records 8 CNAME 3 MX Record 1 TXT Rec 2 one less txt record DNS Zone Editor--respective MX listings Name TTL Class Type Record addondomain1.com. 200 IN MX Priority: 0 Destination: addondomain1.com Name TTL Class Type Record addondomain2.com. 200 IN MX Priority: 0 Destination: addondomain2.com I tried to make these listings generic--not sure how serious the security risk to be less opaque would be. 0 -
Thanks for the details, although I'm not sure they really helped with my understanding of the situation. Maybe this will help - you don't need a full account created to have forwarders in place, so if you're just using a forwarder you could remove the addon domain and set up an Alias instead. That will still allow you to create forwarders and email addresses, but you would not get any unique web hosting options for an Alias domain. 0 -
Since the MX Record host wasn't identified in the cPanel/premium account, I ran these further tests at their respective online URLs: Network Tools: DNS,IP,Email mx:addondomain1.com Pref 1 Hostname mx.byethost.com IP Address 82.163.176.236 Wildcard UK Limited (AS34119) TTL 24 hrs Pref 10 Hostname byethost16.org IP Address 31.22.4.5 Wildcard UK Limited (AS34119) TTL 24 hrs mx:addondomain2.com Pref 0 Hostname byethost16.org IP Address 31.22.4.5 Wildcard UK Limited (AS34119) TTL 24 hrs Pref 1 Hostname mx.byethost.com IP Address 82.163.176.236 Wildcard UK Limited (AS34119) TTL 24 hrs I hope this will clarify the matter further. Is there a command which can reveal which IP address is the actual relay/sender for the email. And then I thought... Looking at the headers from email sent from addondomain1.com that I receive at the forwarding address, I see this in the received from tree: Received: from sv27.byethost27.org ([82.163.176.28]) by oxsus1nmtai01p.internal.vadesecure.com with ngmta id 9c6aad47-165d15fc7d8c2c3c; Sun, 24 Jan 2021 06:06:56 +0000 Received: from [185.27.134.81] (port=56451 helo= addondomain1.com) by sv27.byethost27.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l3YY1-0006VD-BC for xxx@xxx.net; Sun, 24 Jan 2021 01:06:53 -0500 Hopefully, this will help you determine which MX record is actually being used to send the mail, and therefore, needs to be preserved. 0 -
Sorry, I missed your reply while composing my second message today. There are no alias domains or redirects involved. One email address for each addondomain at the free account has been created at the premium account. addondomain1.com has a form that is filled out and then sent via FormTools from its email address. Its been a while since I set it up. The forwarding may be intrinsic to FormTools, although I did set up a fowarder at the time, so it must have been necessary. The email address for addondomain2.com has only been used in the Thunderbird email client when my ISP's email service was down and I had time-sensitive emails that needed to be sent on deadline. I really only intended to use it in this one emergency situation, although it was inadvertently used around the holidays and I got a reply then, so I'd rather not lose it as an avenue of communication. I did some ping tests today also. The free account domains all ping here: 185.27.134.112 The premiun account domain and migrated subdomains all ping here: 31.22.4.5 (I would like to remove these subdomains--part of my original question was whether each subdomain should be removed before its associated addondomain or if the addondomains should be removed first.) Of course, will removing any of these impact the associated email addresses? The new premium addon domain mentioned in the last paragraph of my original post pings here: 31.22.4.101 I am also seeing 500 server errors trying to view this site in a browser. 0 -
I should have also said that the addon domains in the form of subdomains at the premium account cannot resolve, as in: ping: cannot resolve addondomain1.maindomain.com: Unknown host What does resolve is the host-created subdomain, as in xyz123.maindomain.com that is associated with addondomain1. And that is why I question in which order the addon domain and associated subdomain should be removed/deleted? How dependent is one on the other in order to exist? And how does removing either or both affect associated email addresses? If the web files remain on the server and have to be deleted separately, will the email addresses remain after the domain is deleted or are they removed as part of the process of deleting the addon domain? 0 -
Okay - I read this again and I think I've got it. You had 4 domains moved to serverB when you were only expecting 1 domain to be moved. You would just want to make sure the MX record destination is set to the correct server wherever the DNS is being handled, so it's possible that serverB is already not handling the web site or mail for the domain at all. 0 -
Yes! 4 domains were moved and 3 were "returned" to serverA, except that all this detritus from the inadvertent move remains in cPanel and on serverB. I would like to safely removed the detritus and not affect the email services. I have tested to confirm that all serverA sites are served from serverA. The header I quoted above shows that the email forward originates at 185.27.134.xxx which ping suggests also comes from serverA. I guess I can just delete the serverB junk and test to confirm that all continues to work as expected? 0 -
That sounds like the right plan to me. I suppose if you had to, you could quickly re-add the domains to serverB and then have the host investigate more on their end if things end up not working well. 0 -
Okay! Thanks for your help! Regarding the new addon domain on the premium server, I get a 500 error with the document root set to /public_html/addon. This path was edited by me. The original document root was addondomain.com outside of the public_html folder. I changed the path to be consistent with the other files on the server as well as my own prior experience over the years. Is it now best practice for the addon domain to be rooted outside of the public_html folder? I fear that the 500 error has to do with my rooting within the public_html folder because the main site is a drupal 6 installation and I use rewrite rules within the .htaccess file to house the site in a subfolder. If addondomain.com exists outside of the public_html folder, does that free it up from the main domain's .htaccess file? 0 -
The location of the addon domain can actually be restricted by the hosting provider as it can either be in /home/username or /home/username/public_html. I would expect either to work properly, but the system should tell you the correct path. If you check the cPanel >> Errors page it should show you the reason for the 500 error, as those are often related to a configuration error. If it doesn't, you might need to ask the host what shows up in the Apache log. 0 -
Sorry, wanted to update this sooner but didn't get the chance until now. Thought I would start with the new addon domain at server2--the premium server. The host doesn't provide me the error logs, but I was able to view raw access logs which didn't offer much either. So, I temporarily disabled the .htaccess file for the main domain (as I had placed the addondomain document root within the public_html folder) and the 500 error immediately disappeared, accessing via subdomain.maindomain.com, via maindomain.com/addon, and also via a proxy URL that I created at hosts.cx. Led me to the conclusion that it was better to have the Addon Domain rooted outside of the public_html folder, to avoid conflict with the main domain's .htaccess file. Regarding the server1 domains that I wanted to remove from server2, I realized that removing the AddonDomain entries in cPanel would probably "handle"/remove the associated subdomains also, and possibly the email addresses that I had created at server2. So that is how I proceeded. Once each addondomain was deleted in cPanel, I then removed its migrated files via FTP. The associated email address disappeared from cPanel on its own. So I then successfully tested the email address (send/receive/via webform) to confirm that it was still working. Everything seemed to be successful as the addondomains and files were removed while email continued to work afterwards. This was on Monday. The following morning, my email client was prompting me for a password to check email for one of the addondomains. So, I tested again and both email addresses were failing to send or receive as the email client could not authenticate and connect to the mail server. My best guess is that an overnight CRON run must have flushed the details that kept the addresses working the rest of Monday. So, I recreated the Addondomains at server2, all rooted outside of public_html. The email addresses, that I had not removed manually, repopulated in cPanel once again, and began working as well. No need to recreated them or their passwords. So, seems to have been successful in cleaning up server2. Which leads me to a new question: Previously, you had mentioned alias domains, but I think that would interfere with the webform sendmail as well as email server authentication. Also previously, with the addondomains rooted into public_html, this was obscured by the maindomain's .htaccess file as noted above. Now that they are rooted outside of public_html, subdomain.maindomain.com becomes a viable (albeit unlikely) option. Would a redirect or an alias be the best/most appropriate method to connect these potential URLs back to the website files housed on server1? 0 -
I'll be honest, I'm not completely sure I understand the situation here. If you have domainA on server2 and domainB on server 1, you could use a redirect to point the domain to the correct machine if the DNS is all currently pointed to server2. 0 -
I have two identical parallel situations, so let's just talk about one. server1 is the free server which has domainA established as an AddonDomain and houses/servers the website files for domainA. server2 is the premium server and also has domainA established as an AddonDomain, but only for the purpose of email handling, which is working as expected. The DNS nameservers for domainA point to server1 in the form of "NS1.BYET.ORG". I thought they would be identical for both servers (as they are different wings of the same organization), but the DNS for server2 is in the form of "NS1.BYETHOST16.ORG." Prior to the events of our discussion above, the .htaccess for the maindomain on server2 effectively blocked domainA.maindomain.com from working. Now that I have recreated the domainA AddonDomain at server2 rooted outside of public_html, it is possible to access domainA.maindomain.com in a browser. Although this is a highly unlikely occurance because the general public will not know to associate these two domains in such a way, I wanted to preempt such an eventuality by pointing domainA.maindomain.com (from server2) to domainA.com (at server1). Sorry if this sounds like doubletalk. Maybe it isn't even worth the trouble? 0 -
I see what you mean now :D In theory, this isn't necessary, as the A record for the domain will always point to server1, while the MX record will handle mail properly on server2. There wouldn't be a way for user to get web traffic to server2 with any type of normal browsing activity with the way that DNS is configured. 0 -
Thanks, I will let it go then and stop stressing about it. I really appreciate all of your help. 0 -
Happy to help! 0 -
Kudos thanks to everyone 0
Please sign in to leave a comment.
Comments
18 comments