I have one doubts, Please clarify this
We have currently host the one sub application to under main application. like below
URL like
www.Examples.com/internal
internal is a sub application hosted under Examples main application.
But, i want to host the sub application as main application like below
But, the URL should be same like
www.Examples.com/internal
Note: Internal application maintain in single server or different server but, the URL should be same.
Is there any posibilities to maintain website like this?
Thanks,
Mathan Kumar H J
A more common way is having your root zone, example.com, and making other projects DNS records on that zone, for example, if you host the internal app at Ipv4 1.2.3.4 then you would make the DNS record internal IN A 1.2.3.4 in your zone and then internal.example.com will resolve to your app
Edit: noticed you do not want to change the url - if the other site is running on its own server, then you would have to get the user to that server eventually, so if you did it the example.com/internal way you would have to 301 redirect to that ip which would end up changing the url anyway
Related
I'm trying to figure out whether a website I use was hacked.
When I access the site via www.site-name.com, I'm taken to the website.
However, when I access the site without the "www," i.e. site-name.com, I'm taken to a different website.
Why is this happening? I did a little research and my only guess is that someone changed the site's .htaccess file, but that seems unlikely, as the different website has no relation to the official site.
Can someone help me understand what's going on here?
One IP address can host multiple websites with different hostnames using Virtual Name Hosting.
The HTTP server will look at the Host header in the request to determine what site to use for a given request.
This lets you have one IP address serving example.com and example.net.
Typically, the first Virtual Name Host will be the default, so if you were to ask for example.org the server would not recognise it and give you example.com instead.
In this case, it appears that the server has a Virtual Name Host configured for www.site-name.com but not for site-name.com so requests for site-name.com get the default site for the server.
I have a complex web app at example-app.com, hosting fully on AWS using ELB and Route 53 for DNS. It's a Rails app.
I'm running an experiment that I'm using in the rails app, at example-app.com/test. I want to set up new-domain-app.com, to point at example-app.com/test, and have the URL cloacked to always be new-domain-app.com. It's a single page site, so it shouldn't require any navigation.
I'm having a lot of trouble figuring out how to set up my DNS on Route 53 to accomplish this. Does anyone have good ideas on what this Route 53 configuration should look like?
AWS offers a very simple way to implement this -- with CloudFront. Forget about the fact that it's marketed as a CDN. It's also a reverse proxy that can prepend a fixed value onto the path, and send a different hostname to the back-end server than the one typed into the browser, which sounds like what you need.
Create a CloudFront web distribution.
Configure the new domain name as an alternate domain name for the distribution.
For the origin server, put your existing hostname.
For the origin path, put /test -- or whatever string you want prefixed onto the path sent by the browser.
Configure the cache behavior as needed -- enable forwarding of the query string or cookies if needed and any headers your app wants to see, but not Host.
Point your new domain name at CloudFront... But before you do that, note that your CloudFront distribution has a dxxxexample.cloudfront.net hostname. After the distribution finishes setting up (the "In Progress" status goes away, usually in 5 to 20 minutes) your site should be accessible at the cloudfront.net hostname.
How this works: When you type http://example.com into the browser, CloudFront will add the origin path onto the path the browser sends, so GET / HTTP/1.1 becomes GET /test/ HTTP/1.1. This configuration just prefixes every request's path with the string you specified as the origin path, and sends it on to the server. The browser address bar does not change, because this is not a redirect. The host header sent by the browser is replaced with the hostname of the origin server when the request is sent to the origin.
What you are trying to do is not possible. Route53 is a DNS system, and you can not configure a hostname (e.g. new-domain-app.com) to point to URL (e.g. http://example-app.com/test) using DNS.
However, you are probably using a wrong tool for the job. If example-app.com/test is indeed a simple, static, single page site, then you do not need to host it inside Rails app. Instead, you can host it on AWS S3 bucket, and then you can point new-domain-app.com to that bucket using Route53.
See the following for details:
http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/RoutingToS3Bucket.html
DNS knows about Domains, not url's. DNS simply converts names to IP addresses.
You can't do what you are asking for just using DNS and ELB, however, what you can do is have a seperate VHOST for new-domain-app.com that points to your example-app.com site and accomplishes what you want using some sort of redirection rule that only fires for new-domain-app.com.
I'm not sure that this qualifies as an SO question, and more likely is a serverfault question. Specifics about your webserver and OS platform would be helpful in getting more specific advice.
So here's some details:
You already have example-app.com setup and working
You create a CNAME entry pointing new-domain-app.com to example-app.com or you can make an A record pointing to the same IP. If you already have example-app.com pointing to a different IP address, then use a subdomain (test.example-app.com) to isolate it.
Setup a new vhost on your server that basically duplicates the existing vhost for new-domain-app.com. The only thing you need to change is the server name configuration.
Why does this work? Because HTTP 1.1 included the HOST header that browsers send along, and web servers use in vhosting to determine which virtual host to route an incoming request to. When it sees that the client browser wanted "example-app.com" it routes the request to the appropriate vhost.
Rather than having to do some fancy proxying, which certainly can be used to get to a similar result, you can just add a redirection rule that looks for requests for the host example-app.com and redirects those to example-app.com. In apache that uses mod_rewrite which people often utilize by putting rules in the ubiquitous .htacess file, but can also be done in nginx and other common web servers. The specifics are slightly different for each.
I have hosted a RoR app on Amazon EC2 instance. Instance has public IP but no elastic IP is assigned. Application is pointed to a domain using Dreamhost.
We use Amazon S3 to store audio files uploaded through web application and load these files back to site and play in player.
This is where I am facing weird issue, sometimes files play fine but sometimes it gives error saying
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin http://XX.XXX.XX.XXX is therefore not allowed access.
But at the same time if I copy paste S3 url in browser outside my application it loads.
Why error gives IP address instead of saying mydoamin.com is therefore not allowed access?
I am guessing the issue is because of some domain/IP configurations.
An elastic IP on amazon is an IP which is reserved to you. Without it, every time you stop and start your instance, a different IP will be set to it.
You don't have to use elastic IP, you could, for example point your domain to an ELB (elastic load balancer) CNAME, which will remain constant as it load balances between one or more instances of your application.
I'm not sure this has anything to do with the error given, which is explained in this answer:
Site B uses Access-Control-Allow-Origin to tell the browser that the
content of this page is accessible to certain domains. By default,
site B's pages are not accessible to any other domain; using the ACAO
header opens a door for cross-domain access by specific domains.
Site B should serve its pages with
Access-Control-Allow-Origin: http://sitea.com
It seems that the problematic link is an absolute path with the explicit IP, I have no idea why this should happen, look at the source of the page from which the link fails, and try to figure it out.
I have a Rails app hosted on Heroku which servers generated pages for marketing/seo purposes. I have other content pages on another server, which are static pages. I want to keep them both on the same domain, to build seo goodness on that domain.
example:
domain.com/blah-blah-blah-something
should really load a page from heroku-server-name/blah-blah-blah-something but it LOOKS like it's from domain.com.
Possible?
You can front the site with HAProxy and configure it for content switching. To do this you have the frontend listen on some internal IP address that's mapped to your external IP. The backends are your servers. You setup access control lists to determine which backend to send to. For example, this could be via some path name or file extension (such as .html goes to server A and .aspx goes to another). In the end, the user has no idea they are on two separate servers, cause they only see the site being served on one domain name.
Note:
1) You won't be able to share sessions (which I'm sure you're already aware of).
2) HAProxy doesn't handle https, so if you need https then you'll have to have something to handle https termination, such as nginx or haproxy or stunnel.
Hope this is applicable, because I'm not familiar with heroku.
The DNS record for the domain can only point to one IP address (and consequently server). You could configure your heroku based application to render content from another server by effectively fetching the site and displaying it.
I've borrowed this code snippet from this link:
def fetch_url(url)
r = Net::HTTP.get_response( URI.parse( url ) )
if r.is_a? Net::HTTPSuccess
r.body
else
nil
end
end
# use like this from your controller
#snippet = fetch_url "http://www.oreilly.com/"
# and in your page <%= #snippet %>
http://answers.oreilly.com/topic/1052-ruby-on-rails-how-does-one-render-html-from-another-web-server-to-a-ruby-on-rails-app/
There will likely be poor performance to any request like this as it will effectively take the time of two requests.
One of my rails apps (using passenger and apache) is changing server hosts. I've got the app running on both servers (the new one in testing) and the DNS TTL to 5 minutes. I've been told (and experienced something like this myself) by a colleague that sometimes DNS resolvers slightly ignore the TTL and may have the old IP cached for some time after I update DNS to the new server.
So, after I've thrown the switch on DNS, what I'd like to do is hack the old server to issue a forced redirect to the IP address of the new server for all visitors. Obviously I can do a number of redirects (301, 302) in either Apache or the app itself. I'd like to avoid the app method since I don't want to do a checkin and deploy of code just for this one instance so I was thinking a basic http url redirect would work. Buuttt, there are SEO implications should google visit the old site etc. etc.
How best to achieve the re-direct whilst maintaining search engine niceness?
I guess the question is - where would you redirect to? If you are redirecting to the domain name, the browser (or bot) would just get the same old IP address and end up in a redirect loop.
If you redirect to an IP address.. well, that's not going to look very user friendly in someone's browser.
Personally, I wouldn't do anything. There may be some short period where bots get errors trying to access your site, but it should all work itself out in a couple days without any "SEO damage"
One solution might be to use Mod_Proxy instead of a rewrite to proxy traffic to the new host. This way you shouldn't see any "SEO damage".
I used rinetd to redirect the IP traffic from the old server to the new one on IP level. No web server or virtual hosts config needed. Runs very smoothly and absolutely transparent to any client.