Originally Posted by flurpny
Does the fully qualified domain name virtualmin requires in its tutorial introduction need to be a domain I own, does it need to be a domain I'll own for the entire time I own the server, and does it have to be a domain I won't be receiving mail from even if it only receives the email once?
Will the FQDN be the nameserver that all the domains will be archived under over at online IP and domain lookup database sites?
Yes, you need to own the domain you use. It does not need to currently have DNS service (you can set it up in Webmin after installation).
The FQDN is used for a bunch of different parts of the configuration process for the various services Virtualmin configures. If you don't have one configured during installation, you'll have to manually configure those settings after the fact, which is very time consuming. It's much easier to use a FQDN from the beginning.
The most important places it gets used is in DNS records (it becomes the first NS record, by default...this can be changed, after installation, of course), and mail server configuration.
So, you need to own your FQDN.
It needs to resolve to your server, at some point before you put the server into production. You can use Webmin to create the necessary A records (and Virtualmin can auto-create the zone for you, if you will be hosting the domain's website on the server). Or you can use a name that already exists, and is hosted on some other server, and already points to the IP of the server.
I usually use srv1.domain.com (srv2, srv3, etc. depending on how many servers I have in a domain), so that it won't overlap with any Virtualmin records, and won't confuse the mail server when a virtual domain with the same name gets created by Virtualmin (if you set your FQDN to domain.com and then created domain.com in Virtualmin for virtual hosting, Postfix will be configured to receive mail on the virtual domain domain.com, which would cause warnings in the log about the name being setup twice). I then usually change the Virtualmin configuration for NS records to use ns1 and ns2 rather than srv1 (there is no technical reason to change this; srv1 can be a name server as easily as ns1, it is only tradition that names it ns). Other folks might use primary.domain.com (and secondary and tertiary), or whatever you like.
In short, don't make it complicated. If you don't set a FQDN that will resolve (eventually), you'll have to work harder later, so it's more complicated to not set a FQDN during installation.