1 2 Previous Next 21 Replies Latest reply: Nov 4, 2012 10:47 PM by Claude Cauwe
Claude Cauwe Level 2 Level 2 (210 points)

Dear all,

 

I recently purchased an old MacMini to do some Web-application testing in a more convenient way than using a remote server.

Because the MacMini is a rather old model (first Core 2 Duo model), I installed MacOS 10.6.6 SnowLeopard Server on it.

 

I am, however, facing troubles to get it do what I wish.

 

The IP address of the machine is : 192.168.1.42

 

I wish it to respond to the following addresses :

 

192.168.1.100 for website svenskaklubben.be

192.168.1.101 for website schumantrophy.eu

192.168.1.102 for website sky-project.com

 

Etc ...

 

These sites do not have to be accessible from the outside : they are LAN only for testing.

 

The default configuration with only one site works perfectly, but things do change when I add several websites.

 

When I setup the zones in the DNS part of the server, the best result I can achieve is that a trace (or ping) on the name returns the IP correctly.

But when I ping (or trace) the IP, it always says : "host not found", or "host down"

 

Most probably, I do mess up somewhere.

Any help to guide me step-by-step would be highly appreciated, since I'm working on this since a couple of days and start to loose my nerves :-)

 

Lots of thanks in advance


iMac 24, Mac OS X (10.7.2), SpeedTouch Router, 802.11g, Nikon D80, PBG4 1.33 and iPad 3G/32
  • 1. Re: Setting individual IP addresses for Web testing
    MrHoffman Level 6 Level 6 (12,455 points)

    Have you discounted virtual hosting ("sites") for a particular reason; do you actually need to use distinct IP addresses here?

     

    It'd be easier to configure a virtual host ("site") for each of these three domains, and share the same IP address.  That would mean an A (machine) record for the actual host name for the Mac Mini Server (whatever you're really calling the system), and three (or more) CNAME (alias) entries for the domains you want to test with.

  • 2. Re: Setting individual IP addresses for Web testing
    Claude Cauwe Level 2 Level 2 (210 points)

    Txs MrHoffman for this first reaction.

     

    This might be where I am getting confused.

     

    Do you mean that Virtual Hosting uses the same IP of the server (192.168.1.42) ?

    I thought, after a look in the Apache config files, that those "sites" needed each a different IP - hence my question.

     

    But your answer raises another question from my side, then : how can I be sure, when I do test a site using the CNAME alias is pointing to my development version on the LAN? and not to the the existing official site on the Web ?

  • 3. Re: Setting individual IP addresses for Web testing
    Claude Cauwe Level 2 Level 2 (210 points)

    Nah, cannot get it to work !

     

    I must miss a very stupid point, but can't see which one !

  • 4. Re: Setting individual IP addresses for Web testing
    MrHoffman Level 6 Level 6 (12,455 points)

    If this is a newly-installed system, wipe your disk and reinstall and keep clear of the configuration files; stay clear of modifications to those until you gain some experience with OS X Server, as modifications there can lead to instabilities or problems with the management tools.  Use the Server Admin tool to manage the virtual hosts; what Apple refers to as "Sites" in Server Admin tool.

     

    Do you mean that Virtual Hosting uses the same IP of the server (192.168.1.42) ?

     

    Yes.  The web server host can be and often is a virtual construct, and not a one-host one-server or one-host one-IP setup.   IPv4 addresses - and particularly public IPv4 addresses - can be fairly dear resources, so using fewer of these addresses is quite popular, and a number of network services can therefore be virtualized.

     

    I thought, after a look in the Apache config files, that those "sites" needed each a different IP - hence my question.

     

    The user enters the target domain name or IP address into the URL bar of the web browser client.  The web client asks its DNS server for the IP address, if a DNS domain name is entered.  This IP address is then used for IP routing.   The web clients will (also) pass a text string containing the target web server and file specification in the HTTP (or HTTPS) web traffic; the target name is passed from the client to the web server.  This string is then parsed and can be used by the web server to select which web site (virtual host) to present to the client.   While IP addresses can be relevant here if that's the particular target string that the user has entered into the URL address in the browser (and thus what gets passed over to the server), IP addresses are usually otherwise only used for network packet routing and don't get involved in the higher-level HTTP/HTTPS traffic and the web presentation.  IP routing is entirely happy to operate with zero or one or a thousand web sites with the same IP address, after all.  It's the HTTP/HTTPS connection between the web client and the web server that selects the virtual host ("site") that the web server displays.

     

    If you're unfamiliar with HTTP, and on how DNS and HTTP (and HTTPS) and virtual hosts ("sites") interact, then here is a very quick intro.

     

    But your answer raises another question from my side, then : how can I be sure, when I do test a site using the CNAME alias is pointing to my development version on the LAN? and not to the the existing official site on the Web ?

     

    Because your LAN DNS server is configured and refers to your domains and your host, and to your local IP addresses?   That would be typical, after all, when you want to have a second and separate server mimicking (or spoofing) the "real" server.  If your web client hits your DNS server, then your DNS server returns your local IP addresses, you're encapsulated on your LAN.  You won't ever reach the "real" servers with these particular domain names; with what you've configured in your local DNS services database.  If you're unfamiliar with setting up OS X Server DNS services on your local network, then here is a detailed OS X Server DNS server set-up article.

  • 5. Re: Setting individual IP addresses for Web testing
    Claude Cauwe Level 2 Level 2 (210 points)

    Thanks again for your extensive explanation - I hope it will help.

     

    At least it clarifies many things - even though I *thought* I knew quite a lot of things on IP's and DNS :-)

     

    Will read it carefully, incl. the provided links, see if that works and report back !

  • 6. Re: Setting individual IP addresses for Web testing
    Claude Cauwe Level 2 Level 2 (210 points)

    Oh well ...

     

    I followed the instruction on your pages, and indeed it clarified some points.

     

    I could have the DNS working (I think), since the dig command returned the following results, reflecting several modifications as well (those results were obtained through a client machine on the network) :

     

    Last login: Wed Oct 31 07:27:27 on ttys000

    You have mail.

    imac-00-1f-f3-d2-d7-76:~ claudem.cauwe$ dig www.example.com

     

     

    ; <<>> DiG 9.8.3-P1 <<>> www.example.com

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35415

    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

     

     

    ;; QUESTION SECTION:

    ;www.example.com.                    IN          A

     

     

    ;; ANSWER SECTION:

    www.example.com.          10800          IN          A          10.0.0.1

     

     

    ;; AUTHORITY SECTION:

    example.com.                    10800          IN          NS          192.168.1.30.example.com.

     

     

    ;; Query time: 4 msec

    ;; SERVER: 192.168.1.42#53(192.168.1.42)

    ;; WHEN: Wed Oct 31 10:54:00 2012

    ;; MSG SIZE  rcvd: 76

     

     

    imac-00-1f-f3-d2-d7-76:~ claudem.cauwe$ dig -x 192.168.1.30

     

     

    ; <<>> DiG 9.8.3-P1 <<>> -x 192.168.1.30

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12765

    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

     

     

    ;; QUESTION SECTION:

    ;30.1.168.192.in-addr.arpa.          IN          PTR

     

     

    ;; AUTHORITY SECTION:

    168.192.in-addr.arpa.          10800          IN          SOA          prisoner.iana.org. hostmaster.root-servers.org. 1 1800 900 604800 604800

     

     

    ;; Query time: 42 msec

    ;; SERVER: 192.168.1.42#53(192.168.1.42)

    ;; WHEN: Wed Oct 31 10:55:10 2012

    ;; MSG SIZE  rcvd: 120

     

     

    imac-00-1f-f3-d2-d7-76:~ claudem.cauwe$ dig schuman-trophy.example.com

     

     

    ; <<>> DiG 9.8.3-P1 <<>> schuman-trophy.example.com

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64844

    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

     

     

    ;; QUESTION SECTION:

    ;schuman-trophy.example.com.          IN          A

     

     

    ;; ANSWER SECTION:

    schuman-trophy.example.com. 10800 IN          A          10.0.0.1

     

     

    ;; AUTHORITY SECTION:

    example.com.                    10800          IN          NS          192.168.1.30.example.com.

     

     

    ;; Query time: 2 msec

    ;; SERVER: 192.168.1.42#53(192.168.1.42)

    ;; WHEN: Wed Oct 31 10:57:53 2012

    ;; MSG SIZE  rcvd: 87

     

     

    imac-00-1f-f3-d2-d7-76:~ claudem.cauwe$ dig 192.168.1.30

     

     

    ; <<>> DiG 9.8.3-P1 <<>> 192.168.1.30

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29122

    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

     

     

    ;; QUESTION SECTION:

    ;192.168.1.30.                              IN          A

     

     

    ;; AUTHORITY SECTION:

    .                              10800          IN          SOA          a.root-servers.net. nstld.verisign-grs.com. 2012103100 1800 900 604800 86400

     

     

    ;; Query time: 71 msec

    ;; SERVER: 192.168.1.42#53(192.168.1.42)

    ;; WHEN: Wed Oct 31 10:58:42 2012

    ;; MSG SIZE  rcvd: 105

     

     

    imac-00-1f-f3-d2-d7-76:~ claudem.cauwe$ dig schuman-trophy.example.com

     

     

    ; <<>> DiG 9.8.3-P1 <<>> schuman-trophy.example.com

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1790

    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

     

     

    ;; QUESTION SECTION:

    ;schuman-trophy.example.com.          IN          A

     

     

    ;; ANSWER SECTION:

    schuman-trophy.example.com. 10800 IN          A          192.168.1.100

     

     

    ;; AUTHORITY SECTION:

    example.com.                    10800          IN          NS          192.168.1.30.example.com.

     

     

    ;; Query time: 1 msec

    ;; SERVER: 192.168.1.42#53(192.168.1.42)

    ;; WHEN: Wed Oct 31 10:59:48 2012

    ;; MSG SIZE  rcvd: 87

     

     

    imac-00-1f-f3-d2-d7-76:~ claudem.cauwe$

     

    HOWEVER, i was still totally unable to get it working with a VirtualHost set in the "sites" part of ServerAdmin.

     

    Ping returns :

     

    ping: sendto: No route to host

    ping: sendto: Host is down

    ping: sendto: Host is down

     

    While TraceRoute returns :

     

    Traceroute has started…

     

    traceroute to schuman-trophy.example.com (192.168.1.100), 64 hops max, 72 byte packets

    1  * * *

    traceroute: sendto: Host is down

    2 traceroute: wrote schuman-trophy.example.com 72 chars, ret=-1

    *traceroute: sendto: Host is down

    traceroute: wrote schuman-trophy.example.com 72 chars, ret=-1

    *traceroute: sendto: Host is down

    traceroute: wrote schuman-trophy.example.com 72 chars, ret=-1

    *

    traceroute: sendto: Host is down

    3 traceroute: wrote schuman-trophy.example.com 72 chars, ret=-1

    * * *

    4  * * *

    traceroute: sendto: No route to host

    5 traceroute: wrote schuman-trophy.example.com 72 chars, ret=-1


    Interesting, though, is the fact that the IP address seems to be correctly resolved in the Traceroute ...

  • 7. Re: Setting individual IP addresses for Web testing
    MrHoffman Level 6 Level 6 (12,455 points)

    This is likely an error: 192.168.1.30.example.com.

     

    That's not what I would expect the NS nameserver name to be.

     

    This is an error for what should be resolved from local DNS: a.root-servers.net. nstld.verisign-grs.com.

     

    That's not your DNS server that's being referenced; that's leaking out to the Internet.

     

    Don't bother testing with the virtual hosts settings until DNS is working.

     

    Check your DNS server name in DNS, as it looks incorrect in one or more of your zones, and (because it's a common source of errors) the DNS server specification in DHCP.  There appear to be two separate errors here.

     

    Use of the 192.168.1.0/24 subnet (and the 192.168.0.0.24 subnet, for that matter) can cause issues for VPN routing, if/when you decide to start utilizing that capability.

  • 8. Re: Setting individual IP addresses for Web testing
    Claude Cauwe Level 2 Level 2 (210 points)

    So much for my proficiency in networks .. :-(

     

    OK, I will erase all configs and start over again.

     

    What would be the adequate tests to ensure that DNS is working properly ?

    Has the DNS IP to be the same as the "hardware" IP of the MacMini ?

    What would be atypical result of a dig commands ?

     

    For info, all the machines are fixed IP in different 'blocks' :

     

    192.168.1.254 is the ADSL modem acting as a router

    192.168.1.3x are the Macs/iDevices connected over WiFi

    192.168.1.4x are the macs (incl. the MacMini server) connected over wire

    192.168.1.5x are the TV, DVD player, etc...

    192.168.1.6x are the mass storage machines (TimeMachine, NAS acting as multimedia server)

    192.168.1.7x unused - reserved for "visiting" machines

    192.168.1.1xx originally intended for the various website in local-for-development versions

     

    Don't know if this helps - but txs again for all of your help. Greatly appreciated !

  • 9. Re: Setting individual IP addresses for Web testing
    Claude Cauwe Level 2 Level 2 (210 points)

    Starting from scratch again.

     

    This works - only from the macMini.

     

    Last login: Thu Nov  1 08:48:29 on ttys000

    macmini:~ admin$ nslookup macserver.cauwe.skp.server

    Server:                    127.0.0.1

    Address:          127.0.0.1#53

     

    ** server can't find macserver.cauwe.skp.server: NXDOMAIN

     

    macmini:~ admin$ nslookup macserver.cauwe.skp.server

    ;; connection timed out; no servers could be reached

     

    macmini:~ admin$ nslookup macserver.cauwe.skp.server

    Server:                    127.0.0.1

    Address:          127.0.0.1#53

     

    Name:          macserver.cauwe.skp.server

    Address: 192.168.1.42

     

    macmini:~ admin$ 192.168.1.42

    -bash: 192.168.1.42: command not found

    macmini:~ admin$ nslookup 192.168.1.42

    Server:                    127.0.0.1

    Address:          127.0.0.1#53

     

    ** server can't find 42.1.168.192.in-addr.arpa.: NXDOMAIN

     

    macmini:~ admin$ nslookup macserver.cauwe.skp.server

    Server:                    127.0.0.1

    Address:          127.0.0.1#53

     

    Name:          macserver.cauwe.skp.server

    Address: 192.168.1.42

     

    macmini:~ admin$ nslookup 192.168.1.42

    Server:                    127.0.0.1

    Address:          127.0.0.1#53

     

    42.1.168.192.in-addr.arpa          name = macserver.cauwe.skp.server.

     

    macmini:~ admin$ dig macserver.cauwe.skp.server

     

    ; <<>> DiG 9.6-ESV-R4-P3 <<>> macserver.cauwe.skp.server

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27088

    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

     

    ;; QUESTION SECTION:

    ;macserver.cauwe.skp.server.          IN          A

     

    ;; ANSWER SECTION:

    macserver.cauwe.skp.server. 10800 IN          A          192.168.1.42

     

    ;; AUTHORITY SECTION:

    cauwe.skp.server.          10800          IN          NS          macmini.cauwe.skp.server.

     

    ;; Query time: 5 msec

    ;; SERVER: 127.0.0.1#53(127.0.0.1)

    ;; WHEN: Thu Nov  1 09:12:18 2012

    ;; MSG SIZE  rcvd: 82

     

    macmini:~ admin$ dig -s 192.168.1.42

    Invalid option: -s

    Usage:  dig [@global-server] [domain] [q-type] [q-class] {q-opt}

                {global-d-opt} host [@local-server] {local-d-opt}

                [ host [@local-server] {local-d-opt} [...]]

     

    Use "dig -h" (or "dig -h | more") for complete list of options

    macmini:~ admin$ host macserver.cauwe.skp.server

    macserver.cauwe.skp.server has address 192.168.1.42

    macmini:~ admin$ host 192.168.1.42

    42.1.168.192.in-addr.arpa domain name pointer macserver.cauwe.skp.server.

    macmini:~ admin$

     

    So I assume that the DNS is working fine.

     

    I can both Ping and TraceRoute the IP 192.168.1.42 from any machine on the network, but none of those machines will resolve the name macserver.cauwe.skp.server. I assume that this comes from the Network Preferences, but will be for later.

     

    Now ... The next trick is to add the websites ...

  • 10. Re: Setting individual IP addresses for Web testing
    MrHoffman Level 6 Level 6 (12,455 points)

    Your LAN-local clients will want to reference your DNS server (and only your DNS server), either manually with Network Preferences configuration, or via your DHCP Server settings.

     

    I show and generally use the dig and dig -x commands for testing DNS servers, and generally not the nslookup stuff.

     

    If you want to look at the DNS cache contents with OS X or OS X Server, see the dscacheutil command.  Here is a quick example of dscacheutil; of forward- and reverse-DNS translations using the local DNS caches.

     

    I'd recommend getting a real and registered domain, and not using a made-up domain, too.  The more stuff you have and the longer you run with a made-up domain, the bigger the pain factor if (when?) you should want (need?) to go public with some of your local network host names; spending $5 to $15 a year on a real and registered domain or two starts to look cheap in comparison with migrating.

  • 11. Re: Setting individual IP addresses for Web testing
    Camelot Level 8 Level 8 (45,790 points)

    It seems to me you're looking at this from the wrong direction.

     

    Your original post seems to indicate that DNS is, indeed, working properly:

     

    traceroute to schuman-trophy.example.com (192.168.1.100), 64 hops max, 72 byte packets


    This tells me you tried to traceroute to shhuman-trophy.example.com and that the OS looked up the address of this host and got back a reply of 192.168.1.100

     

    That means your DNS is working.


    What's missing is whether you've configured that IP address on your server. Nowhere in your post do you say you've done that. The fact that your ping and traceroute fail indicate to me (at least if you're trying this on the LAN), that there is no machine on your network with that IP address.

     

    So my question is - did you actually configure these IP addresses on your server? or does it still only have the .42 address?

    Just adding a machine to DNS doesn't do anything about it actually existing anywhere. You still need to configure a machine with that address for the rest of the equation to work.

  • 12. Re: Setting individual IP addresses for Web testing
    Claude Cauwe Level 2 Level 2 (210 points)

    Hi Camelot,

     

    Thank you for your intervention.

     

    I have indeed suspected something wrong with the Machines for the Web servers, but Apple's documentation is not very clear (to  my opinion) on this.

     

    Would you be so kind to give me a short "step-by-step" lead to achieve the setup of the first web folder, considering the fact that the DNS is now as in my lasr message (domain = cauwe.skp.server) ?

     

    Thank you very much in advance !

  • 13. Re: Setting individual IP addresses for Web testing
    Camelot Level 8 Level 8 (45,790 points)

    It's kind of hard to get a clear picture of where you are, but I *think* you're at the state where you have a functional machine (192.168.1.42) that all the clients on the network can access (at least ping and traceroute to).

     

    Your recent post, though, shows varying instances where you can sometimes nslookup the name of the server to resolve it's IP, and sometimes you can't. Are those from various machines on the network? or from the same machine?

     

    If they're from different machines then the first problem is that each machine is using 127.0.0.1 (localhost) for name resolution. That is only valid if every machine is running as a DNS server. That's OK to do... unusual, at the very least, but valid, but then you have to determine whether you want to maintain individual zone files on each machine (a PITA), or whether one machine should be the master, from which all the other machines refer to.

     

    You could, of course, setup your network in a more typical manner and just have one (or two) servers on your LAN running as DNS server, and pointing each client to use those for all DNS lookups. This simplifies your DNS setup, where you need to make changes, and the number of potential points of failure.

     

    So I suggest step one at this point is to answer my questions on DNS - how it's running now, and how you want to run it moving forwards.

  • 14. Re: Setting individual IP addresses for Web testing
    Claude Cauwe Level 2 Level 2 (210 points)

    Hi again :-)

     

    Yes, there has been a lot of back and forths in this thread, as I tried several solutions.

     

    The current state is as follows :

     

    I have one main machine acting as DNS on 192.168.1.42, which resolves correctly in nslookup.

    Ping and traceroute work correctly

     

    I *tried* adding another machine after your post, which is named schumantrophy and has 192.168.1.100 as IP.

    It also resolves correctly in nslookup, but no ping nor traceroute give results ("host is down")

     

    Here below a screenshot of how it looks, it might be clearer :-)

     

    Screen Shot 2012-11-03 at 09.21.03.png

1 2 Previous Next