One of the perks of owning a Mac is the ability to create your own website using iWeb1 and then to host it from your home using the built-in Apache webserver in Mac OS X. While generally straightforward, the process does include a number of decisions and tasks of which the everyday Mac user probably is not cognizant. The following guide should fill in these gaps to allow just about anyone with a home Internet connection to host and maintain their own website (or multiple sites) using nothing more than the software bundled with Mac OS X.
Create Your Site
Of course, there’s no point in using your Mac to host a website if there is no website. WYSIWYG2 software packages such as iWeb are great for quickly organizing simple yet functional websites. While an avid web developer would likely find these programs constraining, they are just what the doctor ordered for someone looking to start a blog, share pictures/videos, or even start a podcast. No matter how you decide to do it, though, creating your site is probably the first step. Once you have something put together to publish online (which doesn’t need to be much), you are set to use the steps outlined in this article – learn about networks, register a domain, configure your router, etc. That’s right, you are going to do all of those things – and it probably won’t be as painful as you think.
Before getting into the thick of things, it is important to know how networks work. While more detailed information on this subject is available elsewhere,3 most of the definitions and explanations necessary to take full advantage of this article are included below:
- Server – any computer that is willing to accept and handle a request. If you have an image in your mind of a towering rack of blinking lights, discard it. The very computer you are reading this article from could be a server with proper configuration.
- Client – any computer that sends requests to a server. The computer you used to access this article is a client of the OmniNerd server.
- Port – a number that helps channel the requests a server receives and usually represents a certain type of traffic. The vast majority of webservers are configured to take requests on port 80.4
- Hostname – a computer name that is known by the computer itself and possibly other computers on its network.
- Domain Name – a registered name that has global scope. OmniNerd.com is an example. There is only one OmniNerd.com.
- IP address – a numeric identifier in the form of XXX.XXX.XXX.XXX where XXX represents a number from 0-255. Domain names get translated into IP addresses, which are what routers and computers use to direct information on networks.
- Internet Service Provider (ISP) – the company you pay to provide access to the Internet.
- Hyper Text Markup Language (HTML) – a markup language describing how plain text should be annotated with tags to provide information about the text.
- Hyper Text Transfer Protocol (HTTP) – the way HTML documents are transferred on networks.
- Routing – a manner of directing client requests to the proper location. This is accomplished in many ways, but for the purposes of this article we will consider the routing involved when a server is running from your home and is plugged into a router, which is plugged into a modem. This model breaks down as follows:
- Client to DNS – when the client queries a separate, authoritative server for the IP address associated with a submitted domain name.
- Client to Your Modem – when the client uses the IP address received to accesses your modem.
- Modem to Router – when your modem passes the traffic along to your router, which you have told to forward all port 80 traffic to your computer (the webserver).
- Router to Webserver – when the router passes the traffic to your server, which fulfills the request and basically reverses this process to get the requested data to the client.
Should I Host My Own Site?
Playing around in iWeb and learning about networking is all well and good, but is hosting your own website right for you? I mean, even though Steve Jobs5 could use this article to serve the next version of Apple.com from his home Mac, that does not mean it would be a good idea. Aspiring webmasters (like you) should first consider issues like available equipment, bandwidth requirements, etc.
If you are running Mac OS X and are connected to the Internet, you likely have all the equipment necessary to host your own website. The only potential issue comes when certain ISPs block port 80. The easiest way to determine if this will be an issue for you should be to call your ISP, but we do not recommend this as you are likely to get bad information (depending on the quality of your ISP, of course). The section entitled "Hosting the Site" below will give you further details on checking the availability of port 80.
While Mac OS X provides a lot of out-of-the-box functionality, like a webserver, internal and external factors will likely keep it from performing anywhere close to commercial-grade servers on all levels.
Unless you paid extra for it, your Internet connection is likely slow. This means that your website will lag and may even result in 503 errors6 when it is subjected to traffic beyond the abilities of your Internet connection or processing capacity. Additionally, the same issue may result if you intend to serve high volumes of content to even a few users. The vast majority of personal websites (e.g., blogs, photo sharing, etc.), however, will not fall victim to these limitations. If you have tons of video and images in mind, you may want to reconsider or call your ISP to see what increased bandwidth options are available.
Uptime is another factor to consider. Your computer, network, and ISP must all be in simultaneous working order for your site to function. If your site cannot afford to have temporary downtime while any of these components are either turned off, out of order or mis-configured, you may need to check out other options. With that being said, many computers and networks are able to run almost continuously and ISPs are gaining credibility; it could be that power outages are the only time your service experiences any interruption.
Another potential issue is that you will be responsible for all maintenance. While the basics of such maintenance will be covered in this article, it is possible that a combination of circumstances, predatory software, or other foul luck could land your server in a complicated mess – with no officially provided tech support to turn to for guidance.
UNIX-like System Knowledge
One key in being able to address server issues is knowledge of UNIX-like systems. Much in Mac OS X, including the Apache server, can be efficiently addressed via the Terminal application (and shell of your choice, though bash is the default), and thus proficiency in Terminal navigation will be beneficial. If you’ve heard of UNIX and are fairly computer literate but aren’t UNIX-adept, fear not; this article will explain what you need to know. If, on the other hand, UNIX is Greek to you and you have difficulty working anything more than email and a web browser, you will likely struggle with website administration.7
If all of these factors have you convinced serving your own website is for the dogs, you will have to open your pocketbook and turn to a commercial sector for a third-party server. These come in two varieties: shared and dedicated.
Shared Third-party Servers
Shared servers, as the name implies, are servers shared with other sites. They range from very affordable at under $15/month, to rather costly at over $100/month.8 Most shared servers will meet the needs of the run-of-the-mill website; it is only when your site starts to attract relatively heavy traffic that a dedicated server becomes necessary. Additionally, if your site will be nothing more than some HTML generated by an application such as iWeb and will have traffic on the order of a typical blog or family site, you might be able to secure a shared server environment for less than $10/month.
It is also of note that many shared servers are "managed," meaning most site administration activities are taken care of by the server host – to include available technical support.
Dedicated Third-party Servers
Dedicated servers are reserved for your site (or sites) alone. They are considerably more expensive, ranging from just under $100/month to over $250/month.9 If your site is going to be developed using iWeb or a similar application, a dedicated server is probably overkill and not worth the extra cost.
The more expensive dedicated servers are also usually not managed in terms of software, meaning all server administration will be in your hands – which may be manageable for a beginner when using your Mac as a server, but is a whole different story when dealing with a dedicated server from a remote location.
Register a Domain
After deciding if serving your own website is in your best interest, the next step is to register a domain. Your site domain, or hostname, is what the user will enter into a browser as part of a website, other URL, or email address to access your site and its features. The domain name of OmniNerd, for example, is omninerd.com. When a domain is "registered" in behalf of a person, group or organization, it is reserved for their use. In this way someone could register iamthecoolestpersoninthewholewideworld.com for the homepage of their new blog and not have to worry about someone else stealing the name for their startup social networking site.
Additionally, keep in mind when determining your domain that certain extensions are designated for different purposes. These guidelines are not strictly enforced in some instances (e.g., .org and .info), but are more stringent in others (e.g., .gov and .edu).10
Determine Domain Availability
The first step in registration is to determine if your desired name is available. This is most easily and accurately determined by using a "whois" command to find more information on the owner of a site. To do this, simply type "whois exampledomain.com" at a Terminal prompt and scour the output for any leads.11 The quickest visual cue in the output of a whois command is domain registrant information. For example
whois omninerd.com will dump a lot of stuff, but the section with the following makes it fairly obvious that this domain is registered:
Domain Name: omninerd.com Registrar: AAAQ.COM ... much more registrant info would follow ...
Conversely, non-existent domains are even easier. Consider
whois probablydoesntexistdomain.com. Simply look for a line like:
No match for &"PROBABLYDOESNTEXISTDOMAIN.COM".
Alternatively, you could type your desired domain into a web browser, but that would only check if anything was listed for the domain on port 80. (There are roughly 65,000 other ports.) Lastly, another means of checking for domain availability is to run a search on a domain registration site. This is usually integrated into the registration process, and is unnecessarily slow to obtain the same results.
Figure 1. “Server not found” error when an unregistered domain is requested in Firefox, indicating nothing is listed for that domain on port 80 only.
There are many online sites that offer domain registration services. Some of the more popular ones include GoDaddy.com,12 register.com,13 networksolutions.com14 and aplus.net.15 Each will likely be running myriad sales and promotions, so a quick survey of these and others may save you a couple of dollars (and hopefully make you as happy as the people pictured on those sites).
If you are less particular on your domain name, you should also consider various free domain providers. If you are willing to append .dyndns.org (or any of a long list of other extensions) to the end of your domain, for example, you can register a free domain at Dynamic Networking Services.16
Post-Registration Setup through the Registrar
After registering, you will notice your selected domain now points to a default page or place holder posted by your domain registrar. In order to display your site, you will need to tell the registrar where to look. This is done using "DNS Control," which can usually be found on the domain management page after logging into your account with your domain registrar. One line of the included information will indicate the IP address to which the domain is presently pointing. Edit this to be your site’s location, or WAN IP address, which will be the IP address of either your Mac or your home network router. (If you are unsure of how to determine the appropriate IP address, do not fear; it is covered later in the article.)
Figure 4. The IP address to which the domain is pointed, as shown on GoDaddy.com’s DNS control page.
Figure 5. Information needed to change the domain pointer, as shown on GoDaddy.com’s DNS host record creation page.
Your domain registrar could take up to 24 hours to properly implement your IP address changes on their system, but it is usually accomplished in no longer than 15-20 minutes. If your domain is still not properly forwarded to your computer after 24 hours, and you have properly cleared your cache, contact your domain registrar’s customer service department.
What to Expect Post-Registration
Other than an occasional promotional email and a reminder to renew your registration, you will likely not hear from your domain registrar. You may need to return to the site to update your IP address, however, so user-friendliness and customer service are factors you should consider in your selection.
Host the Site
Hosting websites in Mac OS X is probably best described in two ways: the easy, inflexible way, and the less easy, flexible way. The former is ideal for those wishing to zip through the process with as little hassle as possible and with no "I’d like to expand to do X in the future" ideas floating around in their heads. The latter is ideal for those with the floating ideas.
Extremely Easy, Less Flexible Way
The easy, flexible method essentially consists of four simple steps:
- Turning on your Mac’s webserver.
- Ensure access on port 80.
- Move your files.
- Do a quick internal test.
Turn on Websharing
In order to turn on your webserver, first ensure you have a working network connection and then open System Preferences and select the Sharing preference pane. Locate the Web Sharing option and turn it on by clicking the start button. Once running, your computer’s IP address will be listed under "Network Identity" in the preference pane.17 Make note of this for future reference and feel free to return to this preference pane if you forget your computer’s IP address in the future. Alternatively, you can always run "ifconfig" in a Terminal window and locating the IP address in the output.
Before going further, it is important to understand what kind of IP address it is you have just obtained. There are two kinds of IP addresses: those on Local Area Networks (LAN) and those on the Wide Area Network (WAN). The LAN addresses are used for communication within a local (or home) network, while the WAN addresses are used for communication over the Internet. Depending on what hardware you have at home to connect to the Internet, your computer’s IP address (the number you looked up in the previous paragraph) can be either of these. If you are using a router, then it (the router) holds a WAN address and assigns your computer a LAN address. If there is no router, then your modem assigns your computer a WAN address and there is no LAN address. Perhaps the easiest way to determine the type of IP address your computer has, however, is to know that nearly all LAN addresses start with 192.168.18 Thus, in Figure 6 above, it is obvious the shown IP address (192.168.1.100) is on a local network and thus would not allow access to someone outside of that network. (If a user outside of that network entered that IP address into a browser, it would attempt to access the computer with that same IP address on its own local network.)
The important thing to remember out of all of this is the WAN address, whether held by your computer or your router, is what a user will need to access your website.
Move Web Files
Once your webserver is turned on, drag or paste the HTML documents that makeup your site into the Sites folder in your Home directory. At the least, these documents should include an HTML file entitled "index.html" or "Home.html." You can test to see if everything is properly configured by typing your computer’s IP address you identified earlier into a browser: http://yourHomeNetworkIPAddress/~yourShortUserName/. (You can locate your short user name by navigating to System Preferences -> Users Preferences, clicking on your name and then selecting Edit User.) Accessing this location is also possible by following the link on the System Preferences -> Sharing -> Web Sharing page, "http://184.108.40.206/~Brandon" in Figure 6 above. If your site displays properly, everything the files are in the correct location.
Configure Your Router to Allow Accessibility on Port 80
As previously mentioned, if your computer is on a home network (and thus has a LAN IP address), you must ensure incoming requests for your site are directed to your computer (rather than a network printer, for example) by your router. This is done by telling the router to send all requests on port 80 where to go. In order to do this, access your router by inserting http://192.168.1.1 (or your router’s LAN IP address if different) into a browser. (If, on the other hand, your computer has a WAN IP address, you can skip this section.)
After logging on with your user name and password, check your router’s Application/Gaming page (or something similar) to see if it allows access on port 80, as shown in Figure 7. If there is no line for port 80 access, add one. If there is an existing line, then confirm the IP address listed matches your Mac’s LAN IP address and that the "Enable" box is checked (if necessary).
If you do not know the LAN IP address of your Mac (forgot already?), you can find it using the "ifconfig" Terminal command or the System Preferences check mentioned earlier. Remember, since you obviously have a router if you are attempting to configure it, your computer has a LAN IP address that will usually be of the form 192.168.1.xxx, with xxx commonly being 100, 101, 102, etc.
Test and Go Global
Once websharing is on, your files are in place and the router is configured to allow port 80 access (if necessary), everything should be set to introduce your website to the world. Before going public, however, test your site by inserting your router’s WAN IP address into your browser. If you do not know your router’s WAN IP address, you can find it by accessing your router’s Status page (probably http://192.168.1.1, again). On the other hand, if your computer has the WAN IP address (i.e., you don’t have a router), use that instead.
If you insert the WAN IP address into a browser and see your website, then everything is properly configured; the router (if it exists) is properly directing traffic on port 80 to your Mac, and your Mac is successfully serving your website. If your domain registrar has successfully connected your domain to your WAN IP address, you (and anyone else) should now be able to access your website using the domain name.
Once successful, feel free to step outside briefly and shout, “Hello world!”
A Little More Complex, More Flexible Way
The slightly more complex but much more flexible way adds the ability to serve more than one website from your computer and also to access the webfiles from more than one administrative account. If you are not interested in those features, feel free to use the simpler, less flexible method above.
Host More than One Site
Hosting more than one site in Mac OS X involves editing the main Apache main configuration file. Apache, which is the webserver Mac OS X uses to do all of this magic, is configured by placing directives, or sections of code, in plain text configuration files.19 The main configuration file is called httpd.conf and you can locate it by running the command
httpd -V from the Terminal. Within the output is contained the Apache server version (e.g.,
Server version: Apache/1.3.20 (Darwin)), the main configuration file location (e.g.,
-D SERVER_CONFIG_FILE="/etc/httpd/httpd.conf"), as well as the Apache log files (e.g.,
-D DEFAULT_XFERLOG="/var/log/httpd/access_log" / -D DEFAULT_ERRORLOG="/var/log/httpd/error_log").
Directives placed in this main configuration file will apply to everything served from your computer. If you want to serve more than one website from your Mac (i.e., have certain directives only apply to certain requests), however, you will need to implement what is called a Virtual Host.20,21,22 Basically, this directive in the configuration file serves as a filter to point incoming requests to different websites. The filter can be "IP-based," meaning that you have a different IP address for every website, or "name-based," meaning you have multiple domain names on a single IP address. Either way, the end user will not be able to tell the sites are running on the same physical server.
Although both name-based and IP-based virtual hosts can be used within Mac OS X, this article will concentrate on the name-based method.23 This method is recommended as it is more flexible and conserves scarce IP addresses.24
Name-based Virtual Host
As previously mentioned, in order to use name-based virtual hosting, you must edit your Apache configuration file (httpd.conf) to include
<VirtualHost> blocks. The first step of this block is to use the
NameVirtualHost directive, after which you can create a
<VirtualHost> block for each different host you want to serve. Both the
<VirtualHost> directives should have the same argument:
*:80, representing all IP addresses coming through port 80. Inside each
<VirtualHost> block, a
DocumentRoot directive is required to designate which host is served and where that host’s content is stored in the filesystem.
As an example, if you wish to serve both www.omninerdrules.com and www.omninerdcantbebeat.com from your Mac, you would add the following to httpd.conf:25
<VirtualHost *:80> ServerName www.omninerdrules.com ServerAlias omninerdrules.com *.omninerdrules.com DocumentRoot /www/omninerdrules </VirtualHost>
<VirtualHost *:80> ServerName www.omninerdcantbebeat.com ServerAlias omninerdcantbebeat.com *.omninerdcantbebeat.com DocumentRoot /www/omninerdcantbebeat.com </VirtualHost>
Notice the utility of the
ServerAlias directive, which allows access from more than one name, such as both www.omninerdrules.com and omninerdrules.com. Of course, if you wish to direct multiple domains in this fashion, you must properly configure your DNS server to map all of them to your IP address.
Additionally, you should note that order matters. When a request arrives, the server will first look for a matching
ServerAlias. If it finds one, it will use it, but if it does not, the first loaded virtual host will be used. Thus, how you actually store your virtual hosts matters. For example, if you store them all in your httpd.conf file, they will be loaded in the order you list them and the first one will become the default. However, if you have some lines like this in your httpd.conf:
NameVirtualHost *:80 # This line and folder exists as of Mac OS X 10.4 Include /private/etc/httpd/users/*.conf
… then that’s a location Apache will look for virtual hosts (and any other things that you want to store in individual files). All files that end in .conf in that directory will be appended to httpd.conf, as if their contents were at the end of http.conf’s. The key to note is that these files will be loaded lexically according to the system environment, i.e., filenames starting with symbols first, numbers second, then alphabetically. So if you have a slew of files, an easy way to change the default is simply to change filennames, e.g., given mysite.conf and sweetsite.conf, mysite.conf loads first unless you rename them mysite.conf and !sweetsite.conf. Now !sweetsite.conf loads first and is the default.
You should note too that both the inline and include methods can coexist. Just think of the include as pasting the .conf contents wherever it occurs in the httpd.conf file. If it occurs after virtual hosts you list, then the first host will be the default. If it occurs before the virtual hosts you list, then the first file lexically will be loaded and thus the default.
In practice, storing virtual hosts in separate files is preferred. This allows you to create a stable httpd.conf file that you do not have to edit (and potentially corrupt). Should you have a site that you decide to stop serving or move to another server, all you need to do is delete or move one conf file and restart your server, i.e., no edits necessary. This greatly removes the chance for human error.
Serve Files from a Non-Account Location
In addition to serving more than one site, you may also wish to allow access to your web files from more than one user account. By storing your website files in Home -> Sites, as instructed in the simple, less flexible method, this will be impossible. Instead, place the files in any location not subordinate to a user’s home folder. For example, I use Macintosh HD -> Library -> Webserver -> Documents.26
Once you move your files, plug http://127.0.0.1 (every computer’s IP address for itself) into a browser and see if it brings up your site. If it does, then your computer is correctly serving your site – at least in its own world. If the test is unsuccessful, you have one of two problems; either your files are in the incorrect location or your webserver is not properly turned on (both of which have been covered previously in the article, so it may be good to go back and review those steps).
Maintain the Site
As mentioned previously, hosting your own website means you and only you are responsible for server administration. Usually, the bulk of your potential problems in this capacity will come from power and ISP outages.
Obviously, your Mac cannot serve your site if it does not have power, but a less obvious complication following a power outage to your residence is your router may re-assign LAN IP addresses. This means once your power comes back on, your router could assign your computer’s previous LAN IP address to another entity on your home network and then will proceed to forward incoming traffic on port 80 there, instead of your computer.
Additionally, when your ISP service is out for any reason, the site will not be served. Not only can your ISP service block traffic on port 80, it may occasionally (and without notice) change your assigned WAN IP address. This means your domain would no longer be forwarded properly to your computer, and might even point to someone else’s house!
Although dealing with these issues may seem like a potential nightmare, following a few simple steps in the event of an outage can usually resolve things fairly quickly and painlessly:
- Check Your Webserver – As described earlier, insert http://127.0.0.1 into a browser and see if your computer is at least working in its own world. If not, pursue the potential issues previously indicated: your files in the incorrect location or your webserver not properly turned on.
- Check Mac Service through Router 1 – If you have a router, determine your Mac’s LAN IP address and plug this into a browser on a computer on the same local network. If it successfully displays your site, then you know your computer is properly serving your site and this can be found through your router. (As described previously, your Mac’s LAN IP address can be found using "ifconfig" from Terminal, or checking the Sharing page in System Preferences.)
- Check Mac Service through Router 2 – If you have a router, confirm its WAN IP address and insert it into a browser from any computer. If it brings up your site, then your router and computer are both correctly serving your site and you can skip to the Check Registration Address step.
- Check the Router Port 80 Forwarding – If the router’s WAN IP address or your computer’s LAN IP address does not work and yet your computer is good to go in its own world, then the issue is somewhere between the two. Check your router’s Application/Gaming page (likely http://192.168.1.1 again) to ensure it allows access on port 80 through to your Mac’s LAN IP address, as previously described.
- Check Registration Address – Access DNS control on your domain registrar’s site and check if the IP address listed matches your WAN IP address (whether held by your router or your computer). If it does, then the domain is correctly forwarding to your router. If not, modify it to match your WAN IP address and allow the registrar at most 24 hours to update their system, after which you should contact their customer service department.
If all of these steps check out, then your problem may be outside the scope of this article. Consider reviewing the steps herein (just to be sure you did not miss anything) or contacting your ISP or domain registrar customer service department for further assistance.
2 Pronounced "wizzy-wig," this acronym stands for "what you see is what you get." A WYSIWYG editor editor allows you to edit a site and see exactly how it will look, as opposed to just writing source code in a text file.
6 "503 Service Unavailable". Hypertext Transfer Protocol — HTTP/1.1, Section 10.5.4. W3.org. Accessed January 2007 from http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.
7 "BASH Reference Manual." GNU.org. Accessed February 2007 from http://www.gnu.org/software/bash/manual/bashref.html. The Born-Again SHell is what is behind the Terminal workings. Details on most everything can be found in this reference.
8 "Hostway Web Hosting Solutions." Hostway Corporation, 2007. Accessed February 2007 from http://www.hostway.com/web-hosting/index.html. Hostway’s prices for shared servers, for example, range from $13.95/month to $117.95/month.
9 "Dedicated Servers and Managed Dedicated Servers by Hostway Corporation." Hostway Corporation, 2007. Accessed February 2007 from http://www.hostway.com/dedicated-servers/index.html. Hostway is one example, with their cheapest dedicated server set at $99/month and their most expensive listed dedicated server at $269/month. The option for multiple servers, of course, has the potential to increase this significantly.
12 "Star your domain name search here." GoDaddy.com. Accessed January 2007 from https://www.godaddy.com/gdshop/registrar/search.asp?ci=235.
13 "Register Your Domain." Register.com.
14 "Domain Names." NetworkSolutions.com. Accessed January 2007 from http://www.networksolutions.com/domain-name-registration/index.jsp.
16 Dynamic Netorking Service, DynDns.com_, Accessed January 2007 from http://www.dyndns.com/?gclid=CKy5nqjl_okCFQlQWAodukvqQwokCFQlQWAodukvqQw.
17 If there are two IP addresses listed, either one may be used.
18 While LAN IP addresses starting with 192.168 are the most common for home routers, there are other reserved networks. For example, if you use an Apple Airport router, the LAN IP address of your computer will be 10.0.0.×.
20 Ibid., Scope of Directives. Speaking more generally, if you want to change configurations for only parts of the server (i.e., for only one website and not the other), you can place your directives within the
<LocationMatch> sections. These sections limit the application of their enclosed directives to particular filesystem locations or URLs, and they can also be nested.
22 "Apache Core Features: <VirtualHost> Directive." Apache.org. Accessed February 2007 from http://httpd.apache.org/docs/2.2/mod/core.html#virtualhost. Details of the VirtualServer directive.
23 "Apache IP-based Virtual Host Support." Apache.org. Accessed February 2007 from http://httpd.apache.org/docs/2.2/vhosts/ip-based.html. Details on the IP-based method not covered in this article.
24 "Name-based Virtual Host Support." Apache.org. Accessed February 2007 from http://httpd.apache.org/docs/2.2/vhosts/name-based.html. Apache lists a couple of reasons why you might consider using IP-based virtual hosting, including some incompatible ancient clients, SSL secure servers, and the bandwidth management techniques used by some operating systems and network equipment.
25 "VirtualHost Examples." Apache.org. Accessed February 2007 from http://httpd.apache.org/docs/2.2/vhosts/examples.html. More virtual host examples.
Similarly tagged OmniNerd content: