I've set up an RHEL4 server named sybil.compusmiths.com on 72.70.42.18 and installed VirtualMin on it. I've pointed NetSol to that IP address, named dns.geekho.com, and I can ping that address from the net.
I've added the virtual domain geekho.com to the system, but nothing's resolving. I can get to http://72.70.42.18 but I can't see http://geekho.com
I think I'm confused about naming conventions. What should the FQN of the system be before I install VirtualMin, and what should I do to make sure the DNS servers of the world look to dns.geekho.com to resolve the names of the virtual sites I enter?
Thanks!
I've just discovered that I can't even resolve domain names for virtual domains on this server. For instance, computersmithsconsulting.com is one of the virtual domains, but from a terminal window I get:
/*
[[root@sybil ~]]# ping computersmithsconsulting.com
ping: unknown host computersmithsconsulting.com
[[root@sybil ~]]#
*/
Any thoughts?
Hey William,
Not sure. You'll need to do a bit of DNS troubleshooting.
To test your local nameserver (the one on the server itself):
host geekho.com 72.70.42.18
This will return the response from the name server at 72.70.42.18. If it is anything other than what you expect, the problem is with the name server configuration.
If it gives you the result you expect, you need to figure out why the world doesn't get the right address--probably incorrect glue records at the registrar.
whois geekho.com
I've done this, and I see that the glue record is correct, but I get a timeout when I try to perform the above test. This could be either the DNS server not running, or the firewall you mentioned in your previous post.
A DNS hole is:
iptables -I INPUT -p tcp --dport domain -j ACCEPT
iptables -I INPUT -p udp --dport domain -j ACCEPT
iptables-save
You'll also need "ESTABLISHED" and "RELATED" rules to allow high port interaction after the request (I'm pretty sure). That's a default part of most firewall scripts...I think, including the Red Hat default script.
--
Check out the forum guidelines!
Hey William,
The FQDN of the system can be pretty much anything you want it to be. Probably your base domain name (something like virtualmin.com or geekho.com)--though something like ns.geekho.com is also a good choice, since by default Virtualmin picks up that name for the first NS record (this is configurable, but the default is just to pick up the name during install). There are a few quirks to using a name that you will be adding a virtual host for later, but nothing insurmountable...I don't exactly remember what issues do pop up, but I think they only happen if your DNS server on the machine knows about the name before Virtualmin tries to create the domain.
--
Check out the forum guidelines!
>iptables -I INPUT -p udp --dport domain -j ACCEPT
Ah, that was it, I didn't realize that DNS uses UDP as well as TCP, now evertything seems to be working!
/*
You'll also need "ESTABLISHED" and "RELATED" rules to allow high port interaction after the request (I'm pretty sure). That's a default part of most firewall scripts...I think, including the Red Hat default script.
*/
I already have:
Accept If state of connection is RELATED,ESTABLISHED
in one of my other chains, is that good enough?
>ns.geekho.com is also a good choice, since by default]Virtualmin picks up that name for the first NS record
OK, I'll restore my backup and start over (again). I ran around in tight little circles with having a name, being unable to add that virtual server because[something> was already logging(?) for that domain, rebuilding with an unqualified name, being unable to install virtualmin without a FQD name, picking a name that didn't match the NetSol pointers, etc.
>There are a few quirks to using a name that you will be]adding a virtual host for later, but nothing]insurmountable.
Where can I find more information about this? I've got both Webmin books, but haven't gotten very far in them, and it's difficult to map them to VirtualMin at times...
Thanks!
Hey William,
Yes, that established/related rule is fine. Stateful firewalls are nice. (This one rule replaces potentially dozens of more specific rules in a non-stateful firewall...and is still more secure.)
No need to do any starting over just to change NS records or similar. All of this stuff is configurable after the fact (though if you have a large number of domains with the previous NS records you may want to use an automatic script to make changes just to save time and avoid making mistakes...a simple sed will do it). For example, to change all NS records from oops.virtualmin.com to ns0.virtualmin.com, I could run something like:
cd /var/named/chroot/var/named
sed -i 's/oops.virtualmin.com/ns0.virtualmin.com/' *.hosts
Where you'd cd to wherever your hosts files are located (the above is correct on Red Hat based systems that have a chrooted BIND configuration).
There isn't really any documentation on the quirks in naming during installation, and then later when you begin creating a domain named the same thing, I'm afraid. I haven't ever actually written down the problems that pop up. Obviously, something needs to be written down. I'll try to do that today. But I don't think they'll occur if you name the server ns.domain.tld, or even if you decide to change it later to domain.tld.
Let me know what you're actually seeing when you try to do it the way you want to do it (i.e. pick the name you want, and do the things that seem intuitive to you, and when/if it fails, let me know the error and the circumstances that produced it). We'll make that case work better, or at least document how to do what you want to do.
--
Check out the forum guidelines!