Skip navigation

Local or Private internal website - how to?

284 Views 1 Reply Latest reply: Jun 9, 2013 5:46 AM by MrHoffman RSS
Hamish B. Level 1 Level 1 (10 points)
Currently Being Moderated
Jun 9, 2013 1:33 AM

I (still) want to setup a local web testing environment using Mountain Lion Server.

 

I can access the default macosxserver.local website and would like to replicate this with say test.local or test.private

 

Can this be done, and if so, how do I configure the Website and DNS settings to do so.

 

TIA

  • MrHoffman Level 6 Level 6 (11,700 points)
    Currently Being Moderated
    Jun 9, 2013 5:46 AM (in response to Hamish B.)

    Some of the various options, and I've probably missed a couple.

     

     

    1. Get a gateway-firewall-NAT box (preferably one that's also VPN-server-capable) network device for the edge of your network.
    2. Configure port 80 and port 443 port-forwarding for any external sites.
    3. Configure an Apache virtual host ("site") on an alternate port.
    4. Done.

     

    The above works fine, though your local clients will have to specify the alternate port.  Remote access requires added port forwarding or a VPN.  Set-up mistakes in the configuration files can potentially mess up the production web server.

     

     

    1. Configure internal DNS with a DNS CNAME for the private site.  Omit this in your external DNS.
    2. Configure Apache with the virtual host ("site").
    3. assume/hope/expect nobody outside your network configures their DNS for the same site, referencing your external IP.
    4. Done.

     

    The above works fine, though the local and any remote clients that need access will need to have the host name specified via /etc/hosts (not fond of that approach) or using their own local DNS translations, or via a VPN into the local network.  Set-up mistakes can potentially mess up the production web server.

     

     

    1. Configure internal DNS with a DNS CNAME for the private site.
    2. configure Apache with the virtual host ("site").
    3. Edit the Apache configuration files to make the site password protected.
    4. Done.

     

    The above works fine, though the local and any remote clients will need the credentials.  Remote clients will also need either /etc/hosts or their own local DNS modified, or a VPN into the local network  Set-up mistakes can potentially mess up the production web server.

     

     

    1. Get a gateway-firewall box.
    2. Configure the production web server in a DMZ.
    3. Get a test server.
    4. Done.

     

    The above works just fine, though involves more hardware.  Mistakes here usually won't mess up the production web server, short of messing up at the gateway-firewall box.  Access to the test box can be controlled based on VPN or port-forwarding.  Having the production server configured in a DMZ also has the benefit of (usually) containing breaches to that web server.

     

    The usual sorts of confusions about this stuff can usually be resolved by understanding how the various pieces work:

     

    Here's how DNS and virtual hosts interact.  Here's how to set up DNS on your LAN.  Here's why I prefer using a gateway firewall.  There's other stuff posted there, too, including an overview of the basic concepts and components of IP networking.

     

    And while it's true that DNS responses can specify a TCP port, but no web browser uses that. 

     

    FWIW, do not use .local as your local DNS domain for your server; don't mix DNS with multicast DNS (mDNS, Bonjour).  Get your local DNS services on your LAN configured and verified and going, as a failure to have functional DNS tends to cause other services to have unexpected behaviours if/when/as you bring those services online.

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.