I see several people describing how to do this for a custom domain with sub-domain but no one talking about how to do it without one.
Example: Setting foobar.com and www.foobar.com to point to my Amazon S3–hosted site
I personally do not want the www prefix. Is there no way to make this happen? I seems crazy that Amazon would set it up to allow static sites and custom domains, then lock it down to prefixed domains?
Thanks in advance,
For historical reasons any URL needs to resolve to a subdomain, which you already know how to handle: Create a CNAME record with your DNS provider, pointing www to your S3-hosted subdomain. There are details to get right, described nicely elsewhere.
You nevertheless want to support users who, charmed that their browsers will autocomplete http:// and .com and such, want to type a naked domain domain.com, and have it automatically complete to your default subdomain such as www.domain.com.
The easiest way to accomplish this is to use www as your default subdomain, and point your DNS provider's A record at wwwizer.com (174.129.25.170). They automatically redirect any naked domain to the same domain with www in front.
You get fastest turnaround on development, and your visitors get fastest DNS resolution, if you use Amazon Route 53 to provide your DNS services. Route 53 can point its A records to wwwizer.com. However, you may want to create a micro Amazon EC2 instance, and start programming it. In the '50s everyone rebuilt their own cars. In the '80s everyone pushed a shopping cart down the aisle at Fry's, and built their own computer. Now, you want to be able to build your own computer in the cloud, for many reasons you will discover with time, and Amazon EC2 is best choice. For now, your cloud computer will simply handle naked domains for you. Later, email, generating the static site, ...
Install the Apache web server (the A in LAMP; a LAMP server will do the trick), and configure a virtual host for each of your domains. Then point an elastic IP address at your EC2 instance, and update Route 53 to have your A record point to this elastic IP address. Amazon doesn't support having multiple elastic IPs pointing to the same EC2 instance, but you can provide the same elastic IP to multiple domain A records, and have Apache resolve this within your EC2 instance.
This takes some fiddling and experimenting, as there's lots of conflicting advice on the details. I used the ami-ad36fbc4 instance image (US East, 64 bit EBS-backed Ubuntu 10.04 LTS), as I'm familiar with Ubuntu, there's plenty of online help with Ubuntu, and this image will be supported for years. I edited /etc/apache2/httpd.conf to have the contents
NameVirtualHost *
<VirtualHost *>
ServerName first.net
Redirect permanent / http://www.first.net/
</VirtualHost>
<VirtualHost *>
ServerName second.net
Redirect permanent / http://www.second.net/
</VirtualHost>
then checked for errors using
sudo /usr/sbin/apache2ctl configtest
then restarted the Apache server using
sudo /etc/init.d/apache2 restart
Apache is standard across Linux flavors, but the details such as file locations may vary, e.g./etc/apache2/httpd.conf could be /etc/httpd.conf. For example, it might be necessary put a Listen 80 in httpd.conf, but Apache throws an error if that command was already somewhere else. So read web instructions with a grain of salt, and be prepared to Google any error messages.
As I'd already been using Amazon Route 53 for days to point to wwwizer.com, this worked immediately once I updated Route 53 to point to my elastic IP. Before switching to Route 53, each change took days for me to verify, as the information propagated across the web. Once everyone knows to look to Amazon, Amazon can propagate its internal changes much more quickly.
Unfortunately you can not point foobar.com to an Amazon S3 bucket and the reason for this has to do with how DNS works.
DNS does not allow the root of a domain (called zone apex) to point to another DNS name (you can not have foobar.com set up as a CNAME / only subdomain.foobar.com can be a CNAME)
Since this question was asked things have changed. It is now possible to host your site on S3 with a root domain.
Instead of just having one bucket named "www.yourserver.com", you have to create another bucket with the nude (root) domain name, e.g. "yourserver.com".
After that you will have to use Amazon's DNS service Route 53. Create an A record for the nude domain and a CNAME for the "www" hostname.
Note that you will need to move the domain management of your domain to Amazon Route 53 completely.
See for the detailled walk-through here: http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html
Related
I bought a domain and registered it on a dns server. But I wonder how my web server know whether the coming request is from my domain. E.g. someone registered his domain on my server too. Obviously apache should reject other domain's request. I just wanna know more details about how a web server (like apache) detect this. Does it simply set in the config file (maybe ServerName?) and do some string comparison?
Short answer: By default, if another person points their domain to your website, by default the webpages that are sent to their computer are the same webpages you use for www.yourdomain.com. You can also program your webserver to deny/redirect requests from other domains.
Long answer (I recommand you read):
A common newbie misconception is that domains are "TIED" to a web server. However, that is not true. They are completely different and somewhat unrelated. A domain is just shorthand for an IP address that correlates to your web server. An IP address is really what is TIED with your web server.
For example:
www.example.com could 'resolve'/correlate to 1.1.1.1
and
www.randomdomain.com could also resolve to 1.1.1.1
If 1.1.1.1 is the ip address your web server is correlated to, THEN these requests will both get sent to your web server.
Now, if you think about it, with this logic, you should be able to access your web server by just typing in 1.1.1.1 That is true!
Real world example:
www.google.com goes to Google
172.217.6.78 also goes to Google because 172.217.6.78 is one of the web servers google.com will correlate/resolve to. Go ahead and type 172.217.6.78 into your web browser. It will take you to google.com.
DNS servers point your domain to the IP address of your web server.
On your webserver:
Your server will run a software that will respond to requests it gets from the outside internet. This software will usually know how to respond to this requests using the correct syntax and also be able to handle multiple requests at the same time. When this software gets a request, it will load a file (that you specify) and send it to the user/client.
Common examples of this software include Apache (most famous/popular - runs like 40% of all websites you browse including facebook.com) and nginx (becoming more popular).
The default config of an Apache/nginx/etc web server is to serve that user (at port 80) the documents that are in the 'www' folder. However, (for Apache) if you would like to serve multiple domains on one web server (www.example.com & login.example.com), you would usually create virtual hosts. Creating virtual hosts can be done by editing your Apache configuration file. (If you're hosting on GoDaddy/namecheap or something similar, you won't have access to this.)
An example of a basic virtual host could be:
<VirtualHost *:80> #80 for port 80 - the standard port for unencrypted web traffic
ServerName www.yourdomain.com
DocumentRoot /where/your/web/files/are/located
<VirtualHost>
You could then create another virtual host to reject/forward another domain's traffic
<VirtualHost *:80>
ServerName www.randomotherdomain.com
#here, you could either serve new content to this domain using "DocumentRoot" or you can forward all traffic to your website
Redirect / http://www.yourdomain.com
<VirtualHost>
However, by default, if another person points their domain to your website, by default the webpages that are sent to their computer are the same webpages you use for www.yourdomain.com
I run a local development web server for testing out code changes.
Often I have to test my local changes with remote services that can only connect securely to another domain.
e.g. https://external1.com will only talk to https://someOtherDomain.com, but I've got to test integration of my new code changes with https://external1.com
While I've got a setup configured that works, it seems complex, and took a bit to get setup right. It seems to me that many developers would want to do this same thing, so my question is this:
Is there an easy way to proxy my local webserver as https://someOtherDomain.com ?
EDIT: So maybe this should be asked this way - Does a command line or GUI tool exist that you can pass a local port and a domain name, and it serves your local port securely over https://someOtherDomain.com - no config or SSL cert creation required? Of course it'd be nice if the SSL cert could be replaced through configuration if need be, but by default, it'd work automatically, by using a precanned SSL cert. And even though I'm using Apache, I'm looking for a solution that actually doesnt use Apache - it uses something else. Why? Because I want this solution to work well with any other webserver that's being used by people on our team - as we all run different stacks, and I'd like to be able to let any of us securely serve our sites without having to configure each webserver individually.
Here's my current setup for taking my local webserver and serving it up at https://www.someOtherDomain.com
To test this locally, I've been:
editing my hosts file, and adding an entry to make www.someOtherDomain.com point to my local machine, which of course is running my dev server. This makes it so my local site is now available at http://www.someOtherDomain.com
127.0.0.1 www.someOtherDomain.com
Running Apache with a SSL Cert setup and mod_proxy to redirect all https requests to my local http server, thus making my site available at https://www.someOtherDomain.com. Here's my Apache config for this:
ServerName www.someOtherDomain.com
<Location /balancer-manager>
SetHandler balancer-manager
</Location>
ProxyPass /balancer-manager !
ProxyPass / balancer://mycluster/
<Proxy balancer://mycluster>
BalancerMember http://localhost route=1
</Proxy>
ProxyPass / balancer://mycluster
ProxyPassReverse / balancer://mycluster
SSLHonorCipherOrder On
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite RC4-SHA:HIGH:!ADH
# Rewrite all http requests to https
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
I run this on a mac, but am interested in solutions for linux as well. I've seen various Man in the Middle proxy's that sound like they'd work with some configuration... but I'm looking for something really simple to install and run - not just for me, but something I can tell team members about too, as we may all have to do this a lot in the future.
IMPORTANT NOTE: My local webserver isn't running on Port 80, though I've put it this way in the above example, to keep it simple. I understand port 80 on a mac is a bit special, but am very happy with solutions that work fine on all ports but port 80.
I think mitmproxy can do this for you, as least on linux and os-x. I haven't tried it myself but this question seems to show how it is done. It's still not a trivial program though.
There are however other approaches, which I have used:
The first one is the most pretty simple one, create a DNS entry for develop.mydomain.com which points to 127.0.0.1 and a single certificate for a (sub)domain where you control the DNS. Spread that certificate to all your developers. They'll still need to setup SSL themself but they don't need to generate certificates anymore. It has the added benefit that everybody is developing against https://develop.mydomain.com which allows them to share the configuration.
For bonus points, create a DNS entry for *.develop.mydomain.com and a wildcard certificate and your developers can have different sites (e.g. https://project1.develop.mydomain.com and https://project2.develop.mydomain.com) on there local machine. (Contrary to what the internet sometimes tells you, name based virtual hosting works fine with SSL as long as the certificate is valid for all the named hosts). Since the domain is the same for everybody you can consider getting a valid wildcard certificate to get rid of the warnings.
Unlike the solutions below this works even outside of the office network, which may be relevant when people are working from home or at the customer.
Building on this you could also create DNS entries for the internal IP's of the developer machines (if those are fixed). This does add some work, but it means the ongoing work of a developer can be reached by others in the local network, which can be very convenient for demo's, testing on mobile devices, etc.
An other option is to configure a single machine to proxy for all your developers. Create a DNS entry pointing to the internal IP of this box on something like *.develop.mydomain.com, a matching wildcard certificate and configure that box once with the correct certificate. Now you can create a virtual host for each proxied server, and again, all sites will be reachable throughout the local network, but it does require the developer to have fixed ip addresses (or hostnames added to DNS through DHCP).
Combined with the ability of apache to include all files in a directory in it's configuration makes it trivial to create a script which adds a new site based on a template. All it has to do is write a new file based on the requested subdomain plus the destination and reload the apache config. This means something like a simple PHP script can do what you want the application to do.
If you want to expose your web on your local machine to the internet try Runscope Passageway, it's easy to setup and "just works" (from experience).
Another alternative is ngrok which I also used, but it didn't always work for me.
I'm trying to redirect a router to a certain PHP page stored on what I think is CentOS on my AMI (Amazon Machine Image). I've done a bit of research and have found that other people were having the same problem: I've looked here, and here and what I got was that I need an elastic IP for the instance that has the page I want to redirect to, but I already have that.
I've tried ec2-xx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com/root/path/to/page, as well as (just the IP) xx.xxx.xxx.xxx/root/path/to/page and nothing seems to work. I'm so confused. I don't need a particular domain to redirect to my AMI so I don't need to map my domain's DNS to the elastic IP.
Okay, so I figured out the problem with the redirection. Essentially, I have Apache running on my CentOS AMI. As Apache, I think, handles most if not all HTTP requests, the request for the particular page on my AMI was being handled by Apache. What I did was that I looked in the configuration files of Apache on the AMI which are under etc/httpd/conf on CentOS at least (I don't know about other distributions), and opened httpd.conf (full path: /etc/httpd/conf/httpd.conf).
I looked for the particular line that had the DocumentRoot (this line sets the directory from which Apache will serve files) directive and saw that it had "DocumentRoot "/var/www/html".
What I was doing wrong was that my redirection URL was set to ec2-xx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com/root/path/to/page instead of just ec2-xx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com/page because I didn't know Apache was automatically appending /var/www/html before /page.
So since my redirection URL was set to ec2-xx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com/var/www/html/page, when Apache was getting the request it would append another /var/www/html and look in ec2-xx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com/var/www/html/var/www/html/page.
I recently installed business objects software on tomcat 6. I have 2 domains - domain1 and domain2. This software allows access to two of its applications via these URLS:
xxxxxhttp://myservername.domain1:8080/BO/APP1 and xxxxhttp://myservername.domain1:8080/BO/APP2
Instead of these urls, I would like the end users to access these apps via something like http://bobj.domain2.com:8080/BO/APP1 and http://bobj.domain2.com:8080/BO/APP2.
I cannot figure out how to accomplish that. I have looked into the option of http redirect (not good because the destination address shows up in the address bar), domain forwarding (not sure if it would work with multiple applications and forwarding from one domain to another) and also using apache tomcat with mod_jk by using virtual hosts (not sure if it is possible when forwarding from one domain to a sub domain in another domain) ??
Experts, please advise as to what would be my best option and how to accomplish.
thanks a bunch
There must be a DNS entry for bobj.domain2.com to point to your IP address. Then adding a ServerAlias directive to Apache should do the trick. You can also use wildcards, e.g. DNS entry for *.domain2.com, and ServerAlias *.domain2.com.
What should do to setup a sub-domain for the users when they sign-up into my site.
What are the infrastructure required? I am using Linux servers.
You can either use a specific DNS (CNAME or A/AAAA) entry for each known subdomain, or a wild-card DNS entry that'll accept *.example.com:
$ORIGIN example.com
foo IN A 12.34.6.78
bar IN A 12.34.6.78
or
$ORIGIN example.com
* IN A 12.34.6.78
The advantage of this latter is that no changes are required to either DNS or Apache configuration once the service is running. The disadvantage is that all such wildcard lookups must (by definition) end up returning the same IP address.
The Apache configuration will depend on your requirements, both for end-user control and security. Note that if the users have permission to run CGI scripts on the server then additional setup will be needed to ensure that that's done securely.
Depending on whether content is static or dynamic this will also affect your configuration:
Use mod_vhost_alias to map individual virtual hosts into their individual directories on the server.
If you really want, create a separate <VirtualHost> section for each known site, but then you'll have to restart Apache each time a new user signs up
Use a single <VirtualHost> and then look at the hostname part of the requested URL (from the $SERVER_NAME environment variable) in the scripts that render the output to figure out which user's content to display.
You can make a CNAME entry/ A Record in your DNS settings, for each subdomain
A CNAME record is a record in your
Domain Management Settings that allows
you to control a subdomain of your
domain.
To automate it along with registration, you can write a script which is executed for each user, when s/he registers.
You can refer to this link, as well, for a step-by-step process for Apache:
How to setup subdomains in apache
(since you mentioned Linux, I assume it must be APache. Please mention if it is otherwise)
Alternate Solution
You can also refer to the wildcard solution, given by Alnitak, in the same thread. I find his is an easier way. :)
infrastructure includes access the the dns server to add a wildcard entry, and rewrite rules in Apache.
Try these answers:
How to let PHP to create subdomain automatically for each user?
How to make subdomain user accounts in a webapp
or this link:
http://jam.jrox.com/docs/index.php?article=76
If your using Linux server's I'm assuming your using Apache as your webserver.
You'll have to setup proper DNS routing for the sub domain as well as a virtual host.
Virtual Hosts are fairly easy to setup but I'm not sure how easy it is to do them on the fly progmatically.
Most of the time it's as easy as editing your apache config file and adding the following:
Port 80
ServerName www.mydomain.com
NameVirtualHost *:80
<VirtualHost *:80>
DocumentRoot /www/user-bob
ServerName bob.mydomain.com
...
</VirtualHost>
<VirtualHost *:80>
DocumentRoot /www/user-sally
ServerName sally.mydomain.com
...
</VirtualHost>
The VirtualHost Documention will probably of some use to you.
Apache allows you to specify any number of 'sites' based on subdomains on a single server. Creating a new 'site definition' file with the appropriate subdomain information in it, along with proper DNS wildcards, will do what you want.
In other words, the process is like this:
Setup wildcards so that *.mysite.com directs to the proper server.
When a new user signs up, create the proper Apache site definition file - you'll probably have a base template that you put the right subdomain information into and save.
Make Apache re-read its configuration.
Profit.
IMPORTANT This is based on a Debian-style Apache configuration, where the config files are included in a directory, and the main configuration reads all the config files in that directory. This will simplify things a great deal, because adding/removing subdomains will mean adding/removing files, rather than editing a single file, and so the process will be much easier to automate.