0

We have one server and want to run multiple versions of our in-house intranet app and have them be accessible through a web browser by their name, without a port number.

This is our current setup: In dnsmgmt we have some CNAME aliases: 'intranet', 'dev', 'production', etc. all pointing to servername.ourdomain.lan.. We then have a Host (A) record for servername pointing to its static IP.

Then, we have each intranet app version running its own httpd instance, plus one for 'intranet'. Now, intranet's config file has it listen on port 80 (the others have their own ports) and uses mod_rewrite to redirect traffic from aliases to the same thing but with the special port added on. This makes it so if you go to http://dev/, internall it's http://dev:1234/ but to the user it looks like what they typed in. We also have extranet versions of some of these, so off-network you can access using a port number, if you like.

It would be nice if we got rid of the mod_rewrite layer for these reasons:

  1. it masks important information from mod_perl for debugging purposes, such as the original IP address a request comes from (only the server's IP shows up) -- could use another module to get this information
  2. when the intranet service is down, all of the versions of the app are inaccessible, so:
    1. any changes to that service have to be done after-hours
    2. it's more precarious if something happens to affect the intranet service
  3. it's more overhead per request and on startup
  4. it's more code to look through if problems arise or changes need to be made

It's possible I only set it up this way in the first place because I didn't know there was another way--probably found help/docs that more applied to a hosting provider than an in-house intranet server.

I'd like to do this:

  1. add more IP addresses, one for each service
  2. configure our intranet apps' httpd.confs to listen on port 80 of their new IP addresses (or better yet, port 80 of their aliases)
  3. have the CNAME aliases be replaced with Host (A) records that point to the new IP addresses instead of servername.ourdomain.lan.
  4. configure our router to reroute extranet requests to the appropriate IP rather than port
  5. delete the CNAME for intranet and shut it down

I think this should allow the same browser service from inside and outside as before.

My question is, are there any downsides to this setup / is it even possible to do it this way / is this wise? I've never tried running multiple internal IPs before. Will this mess up anything to do with our intranet? Our extranet? Our server in general? Our network in general?

3
  • 1
    My personal opinion: this can be made to work, but I wouldn't consider it a good idea. It will increase the administrative overhead in your environment. Having a central proxy server route requests for the multiple versions of webapps you have is my preferred choice. If all you want is knowing where a request originally came from why not just log X-Forwarded-For? That contains the IP of the source of the request. Mar 28, 2013 at 10:52
  • Fair enough, but how will it increase the admin overhead? (It's a small shop so I'm the admin too.) Also I will update the question to add more reasons for why I'd want to do this.
    – Kev
    Mar 28, 2013 at 11:26
  • (BTW feel free to add an answer. I'm not a fan of accepting my own answers if I don't have to.)
    – Kev
    Mar 28, 2013 at 17:37

1 Answer 1

0

There's at least one gotcha:

For some reason, adding an IP address seems to cause certain programs (SQL Server, httpd, dns, lsass among them) to bind (sometimes) connections to them even though I didn't explicitly tell those services about the new IP address (in fact, httpd is set to Listen intranet:80 and Listen dev:12222, so why it's bound to anything other than those names, I'm not sure.) Maybe they are doing some kind of load balancing, even though Network Load Balancing isn't checked off in TCP/IP properties.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .