Hi folks, I will eventually get all this into a REAL Newby help doc. When I get it all together.
UPDATE Lesson 1: Joe has had to help me a lot - but much of it because the initial install actually broke. (why unknown). Some bugs surfaced - so it was not all UGNC ( usual great Newby confusion). SO: Especially with Beta/early programs good advice is to check with support after RTFM fails and not persevere alone! Of course, that means HAVING good support - usually there with GPL strangely - and better than most "commercial"! ( Great support here, though!) Virtualmin has been my focus - as I'm always looking for auto/easier ways to make up for non-geekness and my constant time constraints - trying to make a buck outta all this...
Lesson2: It really needs a crossover booklet for those transiting from THAT other one. I'm really struggling with finding things.
I would think my requirements would represent the greater mass of Vmin prospects out here in the Cyberbog: i)To move[b>existing</b> clients safely. ii) Migrate to/use Vmin from existing OTHER knowledge base (no matter how small!) :-) I'm amazed at how little knowledge so many would-be Sysops have.... even less than mine! :-0 These key needs have rapidly become: 1. TRANSITION. How to get my existing clients transferred without too many ruffled feathers. (HINT:) Promise them a present...! :-) UNfortunately, despite having an expert (Joe)get my Vmin up, the mail side is broken. Oddly,individual mail accounts simply left out in the transfer.
SIMPLE PROPOSED SOLUTION TO MY EXPERIENCES: Offer a complete turnkey package (Webmin+Vmin) based on TOO ( That Other One) 's approach)that sets up a typical low-level basic DEFAULT scenario on the Henry Ford Principle: 1. Auto update 2. Auto Spam control 3. Auto sensible security 4. Even a default Hosting package (all 10's) 5. Same with Installer: few basic suggestions. (e.g. whoiscart?)
In the early days, the target: no tech decisions required by Client!
<b>PERSONAL SITUATION NOW:</b>
1. Trying to understand how to get my accounts "seen" again with as little disruption as possible:
1. To use "A" record pointers to the new IP number (very fast as I understand)
OR
2. Setup new NS on the Server level - no clue how to, yet. Have sought advice - got lots - all in "Russian" to me :-)
(2) This seems the better, but up to 36 hours to propagate. What happens to all the mail and orders(!) in the meantime???
Peace!
Hi folks,
To clarify the problems a non-techie faces in something like this:
<i>1. Trying to understand how to get my accounts "seen" again with as little disruption as possible:
1. To use "A" record pointers to the new IP number (very fast as I understand)
OR
2. Setup new NS on the Server level - no clue how to, yet. Have sought advice - got lots - all in "Russian" to me :-)
(2) This seems the better, but up to 36 hours to propagate. What happens to all the mail and orders(!) in the meantime???
</i>
Have a look at the well-meaning advice - or non-existent - or overwhelming suff on this one little point:http://www.webhostingtalk.com/showthread.php?t=298085
frightened the daylights outta me! :-)
OR
https://38.101.153.34:10000/man/search.cgi?for=nameserver+dns&and=0&...
(From inside Webmin...)
<b> This is not a whinge!</b>
I face the same thing in explaining FOREX to people in my area. It is difficult, but it can be done. With enough input we will come up with a simple English HOW-TO
PEACE! Better than Cheers right now.... :-)
Hi Philkin,
Server migration is a problem common to all network services--not just virtual hosting. And the solution is the same across all of them. And you're probably not going to like some aspects of the process (because they take time, and I know you're in a hurry to get migrated). That said, see the steps at the end of this message for the "fast and painless" migration process you were looking for--but read the rest of this for why it probably won't actually be painless for everybody.
First thing necessary is to plan ahead (d'oh! Nobody ever does...I've forgotten to do this step too.)
Before a server migration takes place, if you want to insure zero downtime and be able to make a "hard" switch between the two servers (i.e. one goes down, the other comes up), you have to shorten your DNS TTL times. 30 or 60 seconds is the norm when preparing for a migration. This needs to happen a few days before the actual move. Why, you ask? Because DNS is a caching protocol, and the vast majority of DNS servers on the internet that have queried your domains already have cached the old IP address and won't be checking it again for some period of time. This is, of course, assuming that all name servers on the internet are configured according to RFCs and will actually obey TTL when caching addresses--some do not.
Ok, so assume we don't have the luxury of a few days to make this change, and we want those users stuck behind misbehaving name servers to get the new server too...What next? Actually, we simply <i>need</i> those few days if service isn't to be interrupted. There's no way to avoid it. But we can get everyones mail and web requests going to the right place, even before all of the DNS info propogates.
We can proxy all web requests to the new server and relay all mail to the new server. However, it also requires your old server to keep running for a few days until DNS caches refresh with the new data. D'oh! We just keep coming back to that planning ahead thing, don't we?
In reality, if you update your registrar(s) for your domains to point to your new name server, the majority of requests and messages will find the new server within 24 hours (and quite a few will begin within 8 hours or less--so things need to be working right before you make the change, even if you know it's going to take a while to propogate).
If you can stand 8 hours of downtime for some users and 24 hours of downtime for the majority of users, and no more than three or four days of downtime for <i>all</i> users, then just moving the registrar pointer to your new server will work fine. If these times aren't acceptable (and in most cases they aren't), you'll have to setup proxying for the web requests and relaying for email on the old machine, and then update your DNS on the old machine to point to the new server, and then update your registrar(s) to point to your new name server(s).
Proxying is done in Apache using the ProxyPass and ProxyPassReverse options:
ProxyPass "/" "http://new.domain.com/"
ProxyPassReverse "/" "http://new.domain.com/"
Where new.domain.com is simply and alias you've created on the new server for this purpose--the tricky bit here is that this DNS information needs to be configured on the <i>old</i> DNS server (probably your old hosting server)...Because Apache on the local machine will get its information from the local name server (you could alter it, but things get scary when you start changing a lot of stuff).
Relays are similar. You've already created new.domain.com DNS records, which points to the new server. You can use it for relaying explicitly, or you can modify your MX host entries on the old machine to point to this new address. This will, if configured correctly, relay all mail to the new machine.
Migrations aren't easy, and there's very little Virtualmin can to do ease the task, beyond bring the data over (and we're working with you make sure your old cPanel server data has made it over OK)--all of the work happens on your old machine and at your registrar(s).
Documentation would be good. I don't know of any good source for this information--it is specific to the mail server and web server on the old machine, not to Virtualmin. But it's probably worth spending some time on, as soon as I find some to spare, as it would make it easier for folks to know what the steps are.
Anyway, if you want <i>easy</i> and to hell with those poor slobs behind badly configured name servers, here's what you do:
[ol]
[*]Lower the TTL for all domains on your old machine to 30 seconds.[/*]
[*]Wait two days.[/*]
[*]Point the old name server entries--all of the records for all of the domains--to the new machine.[/*]
[*]Wait another few hours.[/*]
[*]Update your registrar(s) with the new machine IP.[/*]
[*]Wait until this update actually takes place (check using "whois domain.name").[/*]
[*]Shutdown the old machine. Field two or three queries from the aforementioned poor slobs explaining that their ISP sucks, but they can get to you by querying a new name, like new.domain.com (which you create before-hand on the new server, or on an as-needed basis, your call).[/*]
[/ol]
You're done. Mostly painless, and it only took two days plus a few hours. Everyone except those with bad ISPs (more than you think, but few enough to where most folks can live with it) will not notice any downtime.
--
Check out the forum guidelines!
Hi Joe,
EEEK!! :-)
That's simple? Like the guy said: Climbing Everest without oxygen? Simple. Don't breathe so much.
So what about my easy way? ( Changing the A Records)
Most of my clients and my own domains are via Registerfly.
Here is my query and a response from techsupport at Registerfly:
<i>
If I alter the NS from mine: ns3.fablor.net and ns4.fablor.net - to now use YOUR Nservers - will I gain:
1. the stated extremely rapid propagation? ( How fast on average?)
2. Does this mean I don't need to dedicate 2 IP's to NS use if I use yours? ( Just the main Server IP being a dedicated IP?)
Vis: I have 8 I.P.'s with the Server but lose 2 to the NS setup.
3. If I setup auto domain registration on my Server Accounts system, ( like ModernBill) how does the purchased Domain Name get pointed to my Server?
Responses from Customer Support
1) You can setup IP pointing of domain name to IP of hosting server at which name is hosted directly using ADDRESS record pointing from Advanced DNS settings. It takes average 15 to 20 minutes to reflect changes.
2) You only will have to setup pointing of domain to Main IP of server on which name is hosted.
3) You will have to manually setup IP pointing on domain name registered with us through "Advanced DNS settings" link at Domain Manager.[/i>
-----------------------------------
I did this and in minutes(!) my 2 test ones were visible!
I don't see the downside to using this method at all. Can someone enlighten me as to why EVERYBODY isn't using it?
Peace!
<i>I did this and in minutes(!) my 2 test ones were visible!
I don't see the downside to using this method at all. Can someone enlighten me as to why EVERYBODY isn't using it?</i>
Because not everyone on the internet will have your new addresses. DNS is a caching protocol, and there are some DNS servers out there that won't be checking in with your DNS servers for another day or two. Not a big deal on low traffic sites. Just something to be aware of.
--
Check out the forum guidelines!
Hi Joe (looks like we are alone here....??):-)
<i>Because not everyone on the internet will have your new addresses. DNS is a caching protocol, and there are some DNS servers out there that won't be checking in with your DNS servers for another day or two. Not a big deal on low traffic sites. Just something to be aware of.
</i>
But is there any technical downside? - It is real easy to do!:-
What happens to mail in the intervening time? ( Main concern)
Whenever I accumulated NEW Clients before, all I did was point them to my Nameservers and told them to wait..... took sometimes 2 days.
The "A" way at worst seems it might only have the same problem, if I understand you?
Sorry to be a hassle, but I never dreamed that it would be this involved migrating my little lot. But I hafta go off the old box now. ( Certainly no regrets about that.... it was a real dog)
Peace! Or else!
The technical downside is that some clients (I don't mean your customers when I say clients...I mean web browsers and email clients) get the old address, some get the new. What this means is that some mail could continue to end up on the old server and some on the new. It can be a serious problem in a large-scale hosting environment.
The way to eliminate this possibility (but cause obvious downtime for those unfortunate clients who continue to get the old IP) is to shutdown all of the services that this can cause problems with (mail certainly, possibly other services--databases come to mind, but then you'd need to address the fact that any database-backed websites that rely on the database would fail to function).
In short, it all comes down to tradeoffs and planning ahead.
Probably not a huge problem for low-load systems, as long as you make sure no mail gets lost on the old server.
--
Check out the forum guidelines!