Printable View
Many of you received the email this morning regarding the move of all servers on APTHost away from Apache. What this means is that the htaccess file will no longer work and the mod rules will have to be rewritten. They did provide a help link to a Nginx hacker site for help in recoding the scripts but many of us are now over our heads and need help. Admin, can you help us here?
Is APTHost planning on giving all of you direct access to the NGinx configuration files? If not, then I don't see how you could use them with vShare. Unlike Apache, which offers a .htaccess file that Apache can read and process relative to your site, NGinx does not offer this ability. Rather, all of the rewrite rules are written directly into the NGinx configuration file for each site, which I doubt that APT would give you access to. Changing the rewrites for NGinx is going to be tricky and complicated because the rewrite system in NGinx is absolute, not relative (like it is in Apache). This means that rewrite commands would have to be written for each site specifically and cannot be generalized. You may end up having to find another host.
Here is the email Apthost sent out....
Dear Valued Customer,
CPanel shared web-hosting in APTHost is changing for the better, and
we like to share the major improvements coming to your web-hosting
experience.
One of the major upgrades is replacing Apache as the front-end server
to handle all of your web-content delivery, this will be replaced by
Nginx.
It was a hard decision, but it's one we must make to improve service
to our customers today, and in the future. Its important you know what
the impact of this is , as it will affect the behavior of your
website.
The main reason for the switch was for speed, in which you will notice
as soon as the switch is made, in which we plan to deploy 1-2 weeks
from today.
Why use Nginx?
1) Its faster!
2) Handle more request per second, Nginx is supposed to be able to
handle as many as 8,000 to 10,000 requests per second using
comparatively little memory.
3) Easier to deploy applications, and scale.
4) Nginx comes with conditional code for rewrite rules so it is much
easier to understand than Apache's mod_rewrite.
Since a majority of websites we host are FFMPEG based websites, and
serve alot of video content, we required a solution that would make
video streaming faster, scalable, and easier in our boxes. Nginx is faster,
and is capable of handling a large amount of hits a second without slowing
the server down, or taking down the box. In several Apache vs Nginx
benchmark tests, Apache only served ~80% of traffic, compared to
Nginx, which served 100% of all traffic, this means more visitors to a
person's website, in most cases equals to more ad revenue.
How would this affect my website?
The only impact would be .htacess files, Nginx does not support it,
means all of your mod_rewrite rules would have to be converted to nginx
rewrite rules. Since nginx uses conditional code for rewrite rules,
its easy to do so, and there is a lot of websites out there describing
how to do so, like:
http://blog.taragana.com/index.php/arch ... king-tips/
In our environment we have developed a unique system to edit your
Nginx configuration file for your domain names, it provides an
incredible amount of flexibility compared to other shared hosting
providers. I will quickly demonstrate how:
If you notice now in your web-hosting accounts (Not VPS or Dedicated)
there is a new folder called "nginx" under your home directory, under
this folder you will see all the domain names hosted in your account.
So if your domain name was for example, iloveapthost.com, you will see
under nginx folder :
iloveapthost.com
iloveapthost.com.nginx
The file in which you will edit for your rewrite nginx rules, would be
"iloveapthost.com" for iloveapthost.com, its that simple, the file
iloveapthost.com.nginx you cannot edit directly, as this is the real
file that loads into the nginx configuration file. You just modify
iloveapthost.com , as soon as your modify it, every minute this file
will be tested for nginx compability, and if it passes, it will then
write it to the iloveapthost.com.nginx , in which it will load into
nginx, and it would be live in your website that minute. If it fails,
it will create a new file called:
iloveapthost.com-error.log - in which will tell you in detail why it
didn't pass the nginx configuration check.
We highly encourage everyone to convert their mod_Rewrite rules to
Nginx, due to we will work more with Nginx to provide more features
and service compared to Apache, as nginx gives us this flexibility,
and reliability we seek. For those select few that require Apache to run their
websites, or prefer to have Apache running as their front-end of their
website, we will provide free migrations to Apache based servers for
both shared, and resellers, so just submit a support ticket.
Since we host a majority of FFMPEG video websites, one great feature
nginx provides is their FLV Streaming Module:
http://wiki.codemongers.com/NginxHttpFlvStreamModule
and
http://wiki.codemongers.com/NginxHttpUp ... ressModule
In which many developers can implement in our new hosting service to
maximize the experience to their online visitors.
Please start converting your mod_Rewrite rules now, so when the switch
is done from Apache to nginx, there would be no loss in functionality
of your website.
PHP, and cgi scripts would continue to work as it is now, but better.
CGI would still be handled by Apache, and PHP-fpm would be handling
all of your PHP traffic. With PHP-fpm we can give an unprecedented amount
of security and flexibility to the developer. Each individual user in our servers will
have their own isolated memory pool, and dedicated PHP worker.
Means each user would have the power to edit any settings in their PHP, by
just uploading a php-fpm.conf file in their phpcgi folder in their
home phpcgi directory, and these PHP values will load for all the
accounts under this specific user. In PHP-FPM the values need to be
set in XML format, so they would look like:
<value name="display_errors">0</value>
So if I wanted register_globals On, as it is disabled by default, I
would write to this file:
<value name="register_globals">1</value>
Or to change the location of TMP, : <value name="TMP">/tmp</value>
By just editing this file under the user's
/home/USERNAME/phpcgi/php-fpm.xml , the developer has the full power
to edit any variables for PHP under their own secure memory pool,
isolated from everyone else.
Under PHP-fpm , we have compiled it very optimized for 99% of our
customer needs, with the ffmpeg module, optimized php.ini for video sharing/uploading,
Ioncube, Zend, PHP-Shield, SourceGuardian, and we are adding X-Cache
to the family.
XCache is a open-source opcode cacher, which means that it accelerates
the performance of PHP on servers. It optimizes performance by
removing the compilation time of PHP scripts by caching the compiled
state of PHP scripts into the shm (RAM) and uses the compiled version
straight from the RAM. This will increase the rate of page generation
time by up to 5 times as it also optimizes many other aspects of php
scripts and reduce server load.
Greater speed, reliability, and security is coming to a whole new
generation of Web-hosting offered by APTHost, we hope you enjoy our
positive changes we are doing, and assist us during this transition,
we hope it would be a smooth one with your cooperation.
After this transition is done, we will offer some great new features
only offered at APTHost in addition to the above, which would be:
1) Automatic script installer, it will feature a script library of
over 20+ scripts to choose from to instantly install onto your website.
Like phpMotion, vidiscript, ClipShare, MediaShare, OSTube, and many
many more, for free! ETA Launch Date: 1 week.
2) Dedicated Ruby Mogrel Containers
3) Red5 Compatibility
4) JSP Tomcat Hosting
Please get your website mod_rewrite rules converted over to nginx, if
you have any, if you need assistance, please feel free to ask any of
our techs, we can point you to the right direction. If you wish for us
to convert mod_rewrite rules for you, due to the administration time
this would take, we would have to charge $5 per domain name we would
need to do this on, just file a support ticket to have this done.
We will start updating our customers using the popular based social
messaging utility, Twitter, you can find us at:
http://twitter.com/apthost
Subscribe, and interact with us, we will remain as active as possible
on twitter to keep customers and viewers up2date with our servers,
offerings, or anything wacky going down here in the APTHost family.
We hope you enjoy the changes coming to APTHost, on improving your
web-hosting experience.
The APTHost Family
Sounds to me like a company that's about to start circling the drain. What a stupid move to make. Its fun to experiment on your own servers or even on NEW servers, but a hosting company that springs something like this on its existing customers is sure to be gone before long. Although I guess people still host with Godaddy even though they are the absolute worst hosts on the face of the planet, so perhaps I'm wrong.
I could not agree more, Mersh:
While I can understand the reason behind switching from Apache to NGinx (I would have selected lighttpd over NGinx personally), this just sounds to me as though they are overselling their services and need to squeeze more people per server to be able to make up the difference. Normally, when a host has a performance problem, they either get more servers or, if the performance problem is caused by a handful of users, they have those users move off to their own servers so as to not hurt the performance of others. These guys are addressing the problem by switching to a virtually small user-base system. This will either be their biggest achievement or their biggest failure.
Yah, servers are so cheap today compared to what it was just a few years ago, kind of hard to imagine a web host putting their entire customer base (not to mention all their techs) through this kind of stress. Better to open up a server or two (or half a dozen, fifty, whatever) with this "feature" and then put all your NEW accounts on there, and offer migration to your existing customers that may want it. I think these guys better go to Costco for one of the giant 1,000,000,000 pill aspirin bottles.
I'd go with the lightppd too - I don't trust systems I can't pronounce :)
I just moved in three days, about 50 websites with about 200 gigs in files (the bulk of course from my three or so video share sites) with no burp or interruption in anything, and my customers didn't even know it. Seamless, using Cpanel. What an amazing tool. I recommend that anyone who's not a linux guru host up with someone that uses cpanel.
I'm getting strange errors trying to post new threads... anyone else?
I'm hosted with Apt Host and they converted mine for me, they asked me if I would share it with the Vshare users.Quote:
Originally Posted by jayscot
Near bottom, for Hot-Link code, Change YOURSITE.COM to your own. Do not include www.
Code:if (!-e $request_filename) {
rewrite ^/view/(.*)/(.*)/ /view_video.php?id=$1 last;
rewrite ^/tag/(.*)/(.*) /tag.php?search_id=$1&page=$2 last;
rewrite ^/channel/(.*)/(.*)/recent/(.*) /video.php?category=recent&chid=$1&page=$3;
rewrite ^/channel/(.*)/(.*)/viewed/(.*) /video.php?category=viewed&chid=$1&page=$3;
rewrite ^/channel/(.*)/(.*)/ /channel_detail.php?id=$1;
rewrite ^/detailed/recent/(.*) /video.php?category=recent&page=$1&viewtype=detailed;
rewrite ^/detailed/viewed/(.*) /video.php?category=viewed&page=$1&viewtype=detailed;
rewrite ^/detailed/discussed/(.*) /video.php?category=discussed&page=$1&viewtype=detailed;
rewrite ^/detailed/favorites/(.*) /video.php?category=favorites&page=$1&viewtype=detailed;
rewrite ^/detailed/rated/(.*) /video.php?category=rated&page=$1&viewtype=detailed;
rewrite ^/detailed/featured/(.*) /video.php?category=featured&page=$1&viewtype=detailed;
rewrite ^/detailed/random/(.*) /video.php?category=random&page=$1&viewtype=detailed;
rewrite ^/recent/(.*) /video.php?category=recent&page=$1;
rewrite ^/viewed/(.*) /video.php?category=viewed&page=$1;
rewrite ^/discussed/(.*) /video.php?category=discussed&page=$1;
rewrite ^/favorites/(.*) /video.php?category=favorites&page=$1;
rewrite ^/rated/(.*) /video.php?category=rated&page=$1;
rewrite ^/featured/(.*) /video.php?category=featured&page=$1;
rewrite ^/random/(.*) /video.php?category=random&page=$1;
rewrite ^/rss/new/ /rss.php?type=new last;
rewrite ^/rss/comments/ /rss.php?type=comments last;
rewrite ^/rss/views/ /rss.php?type=views last;
rewrite ^/group/(.*)/members/(.*) /group_members.php?urlkey=$1&page=$2;
rewrite ^/group/(.*)/videos/(.*) /group_videos.php?urlkey=$1&page=$2;
rewrite ^/group/(.*)/add/(.*) /add_video.php?urlkey=$1&page=$2;
rewrite ^/group/(.*)/fav/(.*) /add_favour.php?urlkey=$1&page=$2;
rewrite ^/group/(.*)/topic/(.*) /group_posts.php?urlkey=$1&tid=$2;
rewrite ^/group/(.*)/invite/ /invite_members.php?urlkey=$1 last;
rewrite ^/group/(.*)/ /groups_home.php?urlkey=$1 last;
rewrite ^/groups/(.*)/(.*)/(.*) /groups.php?chid=$1&page=$3;
rewrite ^/groups/(.*)/(.*) /groups.php?category=$1&page=$2;
rewrite ^/include/(.*) http://www.vshare.in;
rewrite ^/pages/(.*).html$ /show_page.php?name=$1 last;
rewrite ^/([^/\.]+)/favorites/(.*) /user_favorites.php?username=$1&page=$2;
rewrite ^/([^/\.]+)/playlist/(.*) /playlist.php?username=$1&page=$2;
rewrite ^/([^/\.]+)/friends/(.*) /user_friends.php?username=$1&page=$2;
rewrite ^/([^/\.]+)/public/(.*)$ /user_videos.php?username=$1&type=public&page=$2;
rewrite ^/([^/\.]+)/private/(.*)$ /user_videos.php?username=$1&type=private&page=$2 last;
rewrite ^/([^/\.]+)/groups/(.*)$ /user_groups.php?username=$1&page=$2 last;
rewrite ^/([^/\.]+)?/?$ /user.php?username=$1 last;
}
location ~ \.(jpg|jpeg|gif|png|bmp)$ {
valid_referers none blocked yoursite.com *.yoursite.com;
if ($invalid_referer) {
return 403;
}
}
Mersh:
If you are wanting to do a full server changeover, here is how I would do it.
1. Send out an email to my users letting them know that I was changing servers and that during this process, they may experience a brief delay as everything changes over. Tell them that this is normal and that everything should be fully restored in about 24-72 hours.
2. Disable the ability for websites to make changes to their files.
3. Copy everything over to the new server.
4. Go to my registrar and make the changes to my name servers. Depending on who your registrar is, this can take anywhere from 1-72 hours.
5. After about 72 hours, perform a flush dns on your local machine
6. Ping your domains to see if they are pointing to the new or old IP address. Be sure to perform pings from multiple locations (find some online ping and nslookup services and check to make sure that your DNS has fully propagated.
7. Recopy all of your data from the old server to the new server to get any changes that could have been made (things do slip through the cracks).
8. Shut down the old server.
One thing to note, never name your servers with the same name as your name servers. Always use a name that is different, such as server1.server.com, etc.
Heh thanks, Bplex... pretty much what I did, with one or two exceptions. Appreciate the reply.
Now my first host is offering me a special deal, might wind up with them back in Vansterdam.
Actually what I did was changed the dns on one of the name servers (secondary specifically) so that in theory there won't be any down time. I did name the second server the same name as the ns2 - but I believe you when you say I shouldn't. Been doing it for a year now, hasn't SEEMED to harm anything... but I can see where confusion can set in.Quote:
Originally Posted by bplex
I figure by moving only one name server at a time, "the internet" will look to the secondary only in case of failure of the primary. When I know the secondary ip address has propagated, I'll kill the first, so dns will then be handled by the second and it will refer requests to the new server. Meanwhile, I've set all the dns records on server one to point to server two (execpt the ns1 record) so if any changes are made, they'll be to the "correct" website. As soon as I did that, within minutes the sites started pinging to the new server.
I appreciate your reply a lot, at least I know I'm on the right track. Now if this server2 ip address would just go ahead and propagate for me then I'll be in business.
It probably never will. To do it your way requires a bit more than just changing where "ns2" points at the registrar level. When dealing with DNS, there are actually two parts: FDNS, and RDNS. At the registrar level, when you create name servers, what you are actually creating is RDNS (or reverse DNS). This allows for the root DNS servers to have a starting IP address for which they can get more DNS information on a domain (FDNS). They follow the starting point in order. So, the root DNS will contact whatever is listed as primary (your NS1). When it gets there, it contacts the DNS server there and pulls listing for everything else. If NS1 were to fail (or be shutdown), the root DNS will still contain a cached copy of the DNS available from NS1 until the TTL expires. It is at this point that the root will attempt to contact NS1 to revalidate the records. If it fails to contact NS1, it then looks up the domain root (from the registrar) to see if there are other name servers listed for contact. It is at this point that it would find NS2 and would attempt to contact NS2. Doing it this way will result in downtime as you have to wait for the TTL before the root DNS will start looking for secondary name server. Regardless of whether or not you are a root DNS or a secondary DNS (most ISPs, open DNS servers, etc), DNS traffic all work in the same manner. In order to do it your way, you would have to do the following:
1. Send out an email to your users letting them know that you are changing servers and that during this process, they may experience a brief delay as everything changes over. Tell them that this is normal and that everything should be fully restored in about 24-72 hours. You still have to do this as not all DNS servers operate equally. There could still be periods of downtime.
2. Disable the ability for your users to change their files.
3. Copy everything over to the new server.
4. Go to you registrar and change the value for my NS2 record to point to you new server.
5. Go to your first server and update all of your domain name's DNS records to point to the new server for A, NS, and MX records. For example:
example.com IN NS ns2.exampleserver.com.
example.com IN A 123.123.123.123.
example.com MX 10 mail.example.com.
mail.example.com IN A 123.123.123.123.
Where "123.123.123.123" is the IP on the new server for which the domain will reside. You will need to change every A record to point to the new server as well. You will need to remove any NS records that point to the old server.
6. Wait 24-72 hours.
7. Ping your domains from multiple locations and check to be sure that they are in fact pinging the NEW IP address and not the OLD IP address. Also, perform nslookups to make sure that the NS is pointing to NS2 and not NS1.
8. Recopy all of your data from the old server to the new to be certain that you haven't missed any changes that may have slipped through the cracks.
9. Shut down the old server.
funny... that's actually pretty much exactly what I did.... except for the second copying of data. I own most of the sites on the server, and the customers I do have, have pretty much static web sites. It seemed that within an hour of adding the A records on the first server, the sites were pinging to the second one. I was thinking though that I can't turn off the first server, until I see the second ns2 value pinging to the new server.
Meanwhile, the first server company offered me an upgrade to quad core servers (I'm on dual core) with twice the drive space and bandwidth, at the same price, to try to get me to stay. I may take them up on it.