|
| Frequently Asked Questions |
This is a source of much confusion to people new to setting up websites as well as to many experienced webmasters. Each of these services has a different purpose and is billed differently. Together, these three components form the chain that links a domain name (like example.com) to a website (like example.cust.nearlyfreespeech.net).
Domain Registration is the process of reserving a domain name with a central authority (called a registry) so that no one but you can use it. Domain names are of the form example.com as opposed to www.example.com. Domain registrars act as intermediaries between you and the registry, and they charge a fixed annual fee for this service. We provide domain registration services starting at $7.99 per year for most common top level domains.
DNS or Domain Name Service is used to tell the world what you want to do with your domain name. Most commonly, it is used to create a hostname. Most hostnames have another word attached to the domain name like www.example.com. Each hostname corresponds to a website. It is possible to have more than one hostname per website, but a hostname can only refer to a single site. DNS links this hostname to your website, so when people want to visit www.example.com, their web browser can find it. This is a little like calling directory assistance to have them find a phone number based on someone's name. We offer low-cost DNS service that provides this functionality.
Note: You can use example.com as both a domain name and a hostname but doing so has certain hard-to-understand limitations, and we do not recommend it.
Hosting or Web Hosting refers to the storage and retrieval of your actual web pages. After a web browser has checked with the registrar to see that your domain name is valid, and checked with DNS to find out where to look for your website, it goes to your web host to retrieve your web pages. This is the simplest of the three, and the only one that can work by itself. If you don't have a domain name registered or DNS service, you can always still refer to your site as example.nfshost.com.
For more information about domain registration and domain name service (DNS), please see those sections of our FAQ.
If your domain is registered and has DNS service but your domain name does not point to your site, the most likely cause is that there's one more step you need to follow after registering your domain and setting up DNS service, either with us or with your third-party DNS provider: Add an "alias" to your site for that domain.
An "alias" is a domain name (e.g. example.com), such as the one you registered. An alias will commonly include "www." (e.g. www.example.com); further explanation appears on the "Add a New Alias" page. Here's how to add one (note that while changes often take only minutes to take effect, they can sometimes take a few hours or longer, since they will depend on the propagation of DNS updates):
See also the complete "Domain Name Service (DNS)" and "Domain Registration" sections of our FAQ for other related issues that could keep your domain from pointing to your site.
DNS considerations: Please be aware that, if you are using our DNS service, adding an alias will result in the automatic addition of a CNAME record to your domain's DNS. If you later want to point the same hostname (www.example.com) elsewhere via a new DNS record, you'll need to first delete the alias you created so that the CNAME record our system added to your DNS will also be removed; otherwise, you won't be able to add a new DNS record for that hostname.
If you already have a correct alias added to your site and you have set up our DNS, but it is not working, it is also possible that you have incorrect name servers listed on your registration. See this FAQ entry for more information.
Yes. You should adopt a backup policy that assumes we are storing crates of sweaty dynamite on top of the servers that hold your important data. (Even though we aren't.)
We perform automatic rolling backups, and we use mirrored RAID 5 (with 4 hot spares per array) and RAID 6 (plus hot spares) to protect live website data, and extensive multimirroring for MySQL data. (Which, incidentally, explains a big chunk of our storage charge.) In the event of a serious catastrophe, the most harmful consequence would probably be the loss of everything since the most recent backup, which is generally about 12 hours for sites and 24 hours for MySQL processes. In practice, the time-to-first-backup for new data (web sites or MySQL) averages 12 hours.
That should not trick you into thinking you do not need to make your own backups early and often. If we actually had to restore backups from scratch, the amount of data involved is very large and it would take a really long time, during which you might want a copy of your data.
You should also keep your own backups in case you make a mistake while editing your site. People often send in requests for help recovering files they accidentally changed or deleted. Our backups are designed to recover the whole system, and they are designed to discover and back up changes as quickly as possible; this policy of "disaster recovery" focus on current data actively works against the use of our backups to recover old or overwritten data.
Sometimes it works. If you let us know right away, we will try to help. But for the same reason the chance of losing data in a disaster is very small, the chance of getting back old versions of changed data before the change itself is backed up is also very small. You shouldn't count on it. In most cases, we will need to charge you for the sysadmin time and resources needed for a successful recovery based on the amount of data to be restored and the amount of effort require to restore it.
Make your own backups, please! We are happy to try to help, and we love to save the day, but it stinks when we have to tell someone that we can't help them get their hard work back.
NOTE: If you plan to register a domain name when you set up your site with us, you can use the instructions in our Getting Started Guide.
By "site" we mean the method by which you instruct our system to set up space in which you can create a web site. This is a necessary first step (after creating a funded account that will pay for the resources your site uses) before you can do anything else, such as uploading files or associating a domain name with your site.
(The "short name" will be used as the subdomain of .nfshost.com (such as example.nfshost.com) that you can use to access your site via a web browser; it is not necessary to register your own domain name to host a site on our service.)
For more information on associating a domain name with your site and setting up DNS, see the "Domain Name Service (DNS)" and "Domain Registration" sections of our FAQ.
For more general service-related questions, please see the "Our Service" section of our FAQ.
Start here, and be sure to check out the rest of the "Uploading" section for more details.
This is caused by the mechanism we use to efficiently distribute your content within our network. If you wait a few minutes, the files should resynchronize automatically. The exact time depends upon the type of the file and the time since it was last modified. HTML files are checked most frequently, while images, .zip files, and other large static content are checked less frequently.
If you prefer not to wait, you can also help the process along by visiting the modified page yourself and doing a forced reload. For Internet Explorer, this is done with CTRL-Refresh (or CTRL-F5) and with Firefox this is Shift-Reload (Ctrl-Shift-R on Windows, Command-Shift-R on Mac). This will force that page and all related content (images, .js files) to be resynchronized immediately. Since we have a lot of caches and requests are load balanced among them, you may need to do this a few times to get all the ones that might answer for your site.
There is a case where if you access the site before the IP addresses are assigned (within the first minute after it's created), you'll get a DNS error. Once that happens, some versions of Internet Explorer will keep returning errors long after the site is created, even if you use a forced refresh. Waiting a few minutes, restarting IE, and sometimes rebooting have all appeared to help this under various circumstances.
There is also a case where, if you edit a file twice in quick succession (i.e. a few minutes apart) and you access the file between the edits, a software bug beyond our control will occasionally cause the old version to get "stuck" and continue to be served from time to time. The way to fix this is to update the file again or simply use the Unix "touch" command to change the timestamp.
If your site is correctly set up but you have not uploaded any content, you should see a "Not Available" message when you access the site, which you should be able to "refresh away" once you have uploaded something.
For more basic service-related questions, please see the "Our Service" section of our FAQ. See also the "Uploading" section for specific information about uploading your site.
No. Domain registration is an entirely separate and required step if you want to use a domain name (like www.example.com) with your web site. Please see this FAQ entry for further explanation of domain registration and related terms; please see this page for information about our domain registration service.
You might also wish to read our Getting Started Guide for a step-by-step approach to registering a domain and setting it up with your web site.
To verify the ownership or availability of a domain name, visit a site like DNS Stuff (use the "WHOIS Lookup" search) or Better WHOIS. (Our registration system will also tell you if a domain is unavailable when you attempt to register it.)
Note that it can take up to a day or two for a domain registration to become live on the Internet and your site to be reachable using your new domain. Often this happens in a matter of minutes, but a little patience is usually the solution if you don't see your new domain working immediately, and you've checked our FAQ to eliminate other common configuration issues with your site, domain or DNS.
We've written a Getting Started Guide that covers this common situation. Check it out.
NOTE: If you need a receipt, please print the confirmation page that is displayed after you have made your deposit. If you didn't happen to make a copy, see this entry for an alternative.
For more basic service-related questions, please see the "Our Service" section of our FAQ.
In addition to our member FAQ, you can find relevant information in the following places:
See the "Support" section of the member site for more support-related links and information.
Many of the changes you make have immediate effect. The ones that don't tend to involve DNS or domain registration changes.
Most DNS changes, such as associating a name like www.example.com with a site hosted here, take effect within a minute or two. However, there is a catch. If you recently accessed the name before you set it up, your browser and/or local ISP may "remember" the old information. (Either that it pointed somewhere else or that it didn't work.) Exactly how long that will last depends on what the previous setup was; if it was moving things around on our system it should be visible within a couple of hours. If you changed a domain from somewhere else, it may take a day or more depending on what the other provider had set.
How long it takes to see DNS changes is controlled by the time-to-live (TTL) value for the relevant DNS records. (If a record doesn't exist, the domain contains a setting called Minimum TTL which will be used to tell people how long they can assume that record will continue not to exist.) When you look up a domain name, your local name server (usually run by your ISP) will look at the TTL value and will keep giving you the same answer for that long, even if there are changes in the meantime. (Advanced members with the right tools -- such as "dig" -- can query their name servers to see how much time is left before a given record is rechecked, but that's beyond the scope of this FAQ.)
The root DNS servers operated by the domain registries store your name server records with TTL's of two days. That means if you change your domain's name servers, that change can take up to two days to be fully visible throughout the internet. (The same applies if your domain expires and gets the "parking" name servers, so don't let that happen!)
For a newly-created domain name, things will often work within a few minutes if you don't try to see if it's working until it's already working. If you happen to hit it before it's ready, you'll trip the DNS TTL delay and may have to wait a couple of hours to see your new domain. You should, in all cases, be able to see a new site using our nfshost.com domain within 10-15 minutes.
Yes it does. We use Unix systems, which employ a case-sensitive filesystem. It is entirely possible to have one file called index.html, another called Index.html, and another called INDEX.HTML. Of these, only index.html will be recognized and examined by the system.
This occasionally comes as quite a shock, particularly to Windows users who are used to ignoring filename case.
To avoid confusion and promote consistency, it is recommended that all files be uploaded using only all-lowercase filenames unless there is a specific reason to do otherwise. By adhering to this convention, you never have to wonder or remember whether (or how) you used uppercase letters in your filenames.
Many uploading utilities on systems that ignore case distinctions offer the ability to automatically convert filenames to lowercase. Using this option is highly recommended, but it is also necessary to make sure references to external files, such as images linked in an HTML file, also use the correct case.
For more basic service-related questions, please see the "Our Service" section of our FAQ.
These instructions are for domains you have not registered with us:
If it is not there, you either registered this domain with us and need to contact us about canceling it (or contact a new registrar about transferring it elsewhere), or there is still some other service associated with the domain that is keeping our system from showing you the "Remove" link.
NearlyFreeSpeech.NET supports three types of canonical name settings:
off - The network attempts to avoid the use of a site's canonical name. Redirects issued by the network will use the hostname presented in the HTTP Host: header. From an application standpoint this means that the HTTP_HOST variable will be copied to the SERVER_NAME variable for each request. This setting is particularly suited to sites that vary their content based on which alias is used, such as Drupal multi-site hosting. This setting is approximately equivalent to the Apache "UseCanonicalName off" directive.
soft - The network will use the site's configured canonical name when needed, such as during redirects, but will accept requests for any other alias and deliver them if possible. The SERVER_NAME variable will contain the configured canonical name. This setting is approximately equivalent to the Apache "UseCanonicalName on" directive.
hard - The network will always use the site's configured canonical name. If a request arrives for a non-canonical name, the network will automatically, transparently issue a "301 Moved Permanently" redirect to the browser, causing it to switch to the correct name. This setting is particularly appropriate for sites with one correct name, but a number of other names that the site owner also wishes to accept. There is no Apache equivalent to this setting.
As of April 6, 2008, the default canonical name type for new sites is off. For sites created previously, the default was soft.
The default canonical name of each site is its nfshost.com alias. If your site's shortname is example, then default canonical name is example.nfshost.com. This is usually only relevant if your canonical type is not off.
Your site's canonical name and type settings are visible in the "Config Information" box on the Site Information panel for that site. To make changes to your site's canonical name or type settings, use the "Set Canonical Name" action on the same page.
NOTE: Be sure you have already created the desired alias(es) and specify which alias is to be the canonical name, when requesting the "soft" or "hard" types. See What should my canonical name be? for more information.
By default, you must create an index file for each directory that you create. This is a security precaution for novice webmasters to protect them from unintentionally exposing files they did not intend to publish.
The index file can have any one of several names:
(If more than one of these files exists, the server will use the highest one on the list.)
If you want the web server to display a list of files in a directory, you add the following line to your .htaccess file for that directory:
Options +Indexes
Note that this directive applies to the directory containing its .htaccess file as well as any and all subdirectories.
You can do this by creating a one-line .htaccess file (a plain text file with the file name .htaccess) in the public directory of the forwarding site. This line should look like:
RedirectPermanent / http://www.example.com/members/
Replace www.example.com with the name of the site that you wish to forward users to. This is good because it works for all sorts of URLs, not just the main site. For example, if you use this technique to forward members.example.com visitors to www.example.com/members/ and someone visits http://members.example.com/page.html they will be forwarded to http://www.example.com/members/page.html, whereas most other forwarding techniques would result in an error.
Please note if the target site is hosted here and you merely want to redirect alternative names, setting a hard canonical name is usually more appropriate (and easier) than this approach. This approach is better suited when the redirection involves path manipulation at either or both ends.
Due to the internal security requirements for the Apache web server, .htpasswd files must be referred to by an absolute path. The Apache web server uses the same site root as PHP for this purpose, but you cannot use PHP variables to specify it. To find this path for your site, check the "Apache Site Root" value in the "Config Information" box on the site information panel for your site.
For example, if you have a site named example and the .htpasswd file is in your site's /home/protected directory, your .htaccess file might read:
AuthUserFile /f1/content/example/protected/.htpasswd
Although it should be impossible to retrieve an .htpasswd file using web access*, the Apache documentation recommends that you do not store .htpasswd files inside your document root. This is why we recommend using the protected directory instead. Whatever its location, an .htpasswd file, must be world readable (or, at least, readable by group "web").
*Only the specific filename .htpasswd is protected from web access. If you use password files with another name in your public directory, they may be visible from the web, which is bad.
NearlyFreeSpeech.NET provides a basic error page in response to most common types of site errors. Sometimes, you may wish to override these pages and provide your own error messages that fit your site style or provide additional information. In order to do this, add the following line to the .htaccess file in your public directory (you'll need to create this plain-text file first if you don't have one):
ErrorDocument 404 /err404.html
Where 404 is the number of the error you wish to catch and err404.html is the name of the file you want displayed when an error occurs. You may use a PHP or CGI script for an ErrorDocument, but be careful not to use absolute paths to specify the name of your ErrorDocument.
Here are the most common errors:
Due to the design of our network, you cannot use an ErrorDocument to catch a 503 Service Unavailable error. Such errors do not routinely occur except during system maintenance. They may also occur during some types of partial service interruptions.
Due to the way our network handles incoming requests, it is not possible to use .htaccess files to block IP addresses from accessing your site; by the time the .htaccess file is considered, the incoming request has already been accepted.
However, we recognize the common desire to restrict accesses in this way. For this reason, we provide the ability to block accesses on a per-site per-IP basis at the edge of our network.
By default, all accesses are allowed. We maintain two lists for each site, an allow list and a deny list, which are processed in the order: allow, deny. Thus, an IP address that appears on both lists will be allowed. Entries to either list can contain either an IP address or a netblock specified in CIDR format (10.20.30.40/24).
Currently, you can see your site's IP access controls (if any) in the "Config Information" box on the Site information panel. However, to manipulate the list you will currently need to submit an assistance request.
To see exactly what blocked visitors see, visit blocked.nfshost.com, which blocks all visitors.
Yes. Our servers support having more than one alternate name for your site (such as www.example.com and www.anotherexample.com). If you click on the "Sites" tab at the top of the page and then click your site name in the "Your Web Sites" list, you will see the Site Information panel, where you can add and remove aliases at any time.
You may also add NearlyFreeSpeech.NET DNS to an alias at any time by clicking the "Domains" tab and clicking "Add" under the "DNS" column for the relevant alias (domain).
It's the name you plan to use when someone asks you for the address of your web site; the "official" name. This would typically be something like www.example.com, and must be one of the aliases that is associated with your site (this can include the default alias ending in .nfshost.com).
For more information on this subject, see What canonical name settings are available?
For more information on aliases, see Why does my domain not point to my site yet? (Or: What is an alias and why do I need one?)
To select the static content site type -- thereby avoiding the $0.01/day charge for sites that support CGI & PHP -- follow these steps:
(Note: During the static site beta period, you may need to rename any .htaccess files to .htstatic.)
By default, this is the correct behavior. Using URLs of the form http://example.com/ creates a number of problems, and we strongly recommend that you avoid it. Some of the limitations are:
Although we don't recommend the practice, you are still welcome to use bare domains with our service. Just add the domain name as an alias to your site and, if you have NearlyFreeSpeech.NET DNS, our system will set it up automatically.
We strongly encourage you to consider the alternatives and implications before using the bare domain name. The best compromise solution we have found is to redirect example.com visitors to your www.example.com alias. There are several ways to do this. In order of our recommendation, they are:
If you have NearlyFreeSpeech.NET DNS, the behavior of http://example.com/ is summarized in the "Domain as alias" line on your domain's DNS information panel.
The preferred way is to create a CNAME or domain name alias. This allows you to take full advantage of our load balancing and fault tolerance features to get the best performance and reliability for your site. To do this, if your site was named example and you wanted to use the domain name www.example.com then you would configure a DNS alias or CNAME record from www.example.com to example.nfshost.com.
You cannot use a CNAME record with a bare domain name. All domain names have special records, called SOA records, which must exist. So, if you attempt to point example.com to example.nfshost.com via a CNAME record, you will violate the DNS specification, which does not allow CNAME records to coexist with other records. This will cause all kinds of unpredictable and hard-to-diagnose problems with your domain.
Although we do not recommend it, you can also use the IP addresses from your Site Information page (click the "Sites" tab at the top of the page and then click your site name in the "Your Web Sites" list; the IP addresses are at the bottom of the Site Information page). If you do this, we strongly urge you to use more than one of the three listed IP addresses. If you use only one, you may experience unnecessary outages when we perform network maintenance.
You will need to use this method if you are configuring your bare domain name (such as example.com without www. in front) to point to a NearlyFreeSpeech.NET hosted site. If you want to do this, we strongly recommend that you use our DNS, which will automatically keep the DNS records for your domain up to date with any changes we make.
When configuring third-party DNS, make sure that you have configured the site name that you will be using as an alias for your site on the Site Information page. Otherwise, when the request gets to our network, our servers will have no idea what site you want and will return an "Unknown Site" error message.
If you have NearlyFreeSpeech.NET DNS for your domain, your authoritative name servers are the "official" name servers for that domain.
However, in order for these name servers to be used, you must take the list of authoritative name servers and make them active by entering them at your domain registrar (even if your domain is registered through us).
If you go to the DNS information panel and see both "Authoritative Name Servers" and "Active Name Servers" then you have NearlyFreeSpeech.NET DNS, but your domain registration points elsewhere.
If that's the case, you have two options to correct the problem:
This scenario most commonly arises when you transfer an existing domain name from another registrar without updating the name servers first. In that case, you just need to change them in our system once the transfer completes.
For maximum reliability it is always best to make sure that the active and authoritative name servers match. There are isolated reports of weird things happening if they don't, and some ccTLD registries (notably .DE) actually verify that they match before allowing changes.
In order to add NearlyFreeSpeech.NET DNS to an existing website, follow these steps:
That's all there is to it!
If you've already registered your domain with a third-party registrar when you set up NearlyFreeSpeech.NET DNS, don't forget to update your list of name servers at your domain registrar with the name server information we provide for your domain.
If you have NearlyFreeSpeech.NET DNS service, you may obtain your name server information from the DNS information page for your domain in our user interface. Just go to the Domains panel and, for the domain in question, under the "DNS" column, click "Manage." The name servers for your domain are listed in the "Authoritative Name Servers" box.
If you are using third party DNS, you must get the name server information from your DNS provider.
If you do not have NearlyFreeSpeech.NET DNS and you do not have DNS from a third party, you do not have name servers and will usually not be able to use domain names with your website, except through "masking" or "forwarding" offered by some domain registrars.
If you're registering a new domain name with a third-party registrar and you're planning to use NearlyFreeSpeech.NET DNS, and you run into a situation where the registrar needs you to have valid name servers before you register the domain, send us a Secure Support request and we'll add the domain and activate DNS for you.
No! When you create NearlyFreeSpeech.NET DNS for a site named www.example.com, your NearlyFreeSpeech.NET DNS is actually being set up for your registered domain, example.com. You may add as many subdomain names as you want to an existing NearlyFreeSpeech.NET DNS domain at no additional cost.
Multiple names can each point to a different sites, all point to the same site, or any combination you need.
No matter how many subdomains you add, email forwarding support is currently only available for the primary example.com domain name.
All you have to do is create another site from our member interface. Click the Sites tab at the top of the page and then click Create a New Site in the "Actions" box. You'll first be asked to add a "short name" for use on our system (and possibly also asked which account to assign the site to, if you have more than one eligible account). Then, on the "Add a Site (Using another name?)" screen, under "Alias", add your subdomain name as an alias for the site in answer to the question "Do you want to refer to your site by another name?" -- select "Yes, and the name is" and add your subdomain in the text-entry field to the right.
You may also add additional subdomains to a site you already have, by following the instructions in this related FAQ entry.
We do not use or support the scheme of placing subdomains in subdirectories of your existing site that is employed by some mass-market hosting control panel options.
This is generally very straightforward.
(In order for this to work, you must first have set up NearlyFreeSpeech.NET DNS for your domain name. If that is not already done, start with this FAQ entry and then return here.)
Since each registrar has a slightly different way of editing name servers, you would need to contact them for specific help with using their system.
Once these steps are complete, you may have to wait awhile for the change to take effect. Changes in most top-level domains take less than 24 hours, and the major ones (.com, .net, and .org) seem to be taking effect often within a few minutes.
If your domain registrar provides DNS service, you can also use that, although it is not recommended. Please see this FAQ entry for more information.
The IP addresses listed on your "Site Information" page at the bottom under "Web Site IP Addresses" are used by our web servers. They are not alternate addresses for our name servers.
For more information about how those IP addresses work with our service see this entry.
If you are trying to obtain DNS name server information, please read this entry.
Follow these steps:
SPF is the Sender Policy Framework, a way to use DNS to tell the world about the servers that can legitimately send email for your domain. It is an anti-spam tool that makes it a little easier to identify spam, and a little harder for spammers to hide.
We've noticed that many of our members register more domains than they need for email purposes. For example, someone whose domain is example.com may also register theexample.com or other similar domain names to prevent competitors from creating similarly-named sites. But they only use their primary domain for email.
Our "SPF Email Protection" feature is an easy, automatic SPF record that will tell the world that your domain isn't used for email. That will help foil spammers who might otherwise forge email from that domain, as described in this FAQ entry. That means that spammers have one less place to hide, and also that you won't get their bounce messages.
Our standard offering is designed to be easy to use for this common case. If you need more specific settings for SPF, you can create your own custom TXT record for your domain containing any SPF code you want. The specific code you need depends on the server you use to send (not receive) email, which is usually your ISP's mail server.
To find out what SPF code you should use, or to learn more about SPF and how it can help you, check out the SPF home page. They have a great deal of information, as well as a handy "SPF Wizard" that can make getting started with SPF much easier.
SPF isn't suitable for all cases. For example, it doesn't work well if your domain sends email from a number of different or frequently changing places. But where it is suitable, it both helps you a little bit, and it's a way to be a "good netizen" to your Internet neighbors by making spamming just a little bit harder.
Anyone who wants to send mail from their domain from our servers and wants an SPF record for it should add "include:nfshost.com" to their SPF record.
These instructions assume you have turned on our DNS and that your domain name registration has our name servers listed. To turn DNS on for a new domain, see this FAQ entry; to turn it on for a domain you've newly registered with or transferred to us (that wasn't already using our DNS), see this one.
To add resource records:
To remove existing resource records:
NOTE: If you want to remove a CNAME record pointing to an .nfshost.com address but do not see a "remove" button, this is an alias you added to your site that must be removed from your site before it will disappear from your DNS records. To remove an alias, visit the "sites" page and click on the relevant site short name; the next page will list the aliases and provide "Remove" buttons.
See this FAQ entry.
No, we do not presently support wildcard DNS; adding support for wildcard aliases would slow down everybody, even people who weren't using them.
Yes, this is available upon secure support request on a per-domain basis.
For a $1.00 set-up fee we will manually configure your DNS to use one name server in our primary Phoenix location, and one in an offsite location that has no direct dependencies on our primary network.
This service is suitable for people who want maximum DNS uptime, even during a serious outage that affected our entire hosting facility. This may be desirable if, for example, the domain is associated with other services that we do not provide, such as third-party email or a corporate office.
If you run into this, it is most likely a CNAME record that was automatically created by our system when you added a corresponding alias to one of your sites because you wanted our system to know that a certain hostname (such as www.example.com) should be used with that site.
If this is your situation, on the DNS information page for your domain, the CNAME record in question should look similar to this one:
www.example.com CNAME example.nfshost.com.
If you want to remove a CNAME record pointing to an .nfshost.com address, visit the "sites" page and click on the relevant site short name; the next page will list the aliases and provide "Remove" buttons. Removing the offending alias will delete the CNAME record from your DNS automatically.
* If you are already using our DNS and just need to have your assigned name servers listed on your domain registration, any existing custom DNS records you have added will not be changed or removed.
Yes, you may use our member interface to add or remove RespectMyPrivacy service on any domain registered through NearlyFreeSpeech.NET at any time, as long as the registration is not expired.
As with all domain contact changes, RespectMyPrivacy can only be added or removed if your domain is unlocked.
To add it: Visit the "domains" page. Under the "Registrar" column, click "Manage" for the relevant domain. The next page will (if, as noted above, your domain is unlocked) have an "Add RespectMyPrivacy.COM" link in the "Actions" box.
To remove it: Visit the "domains" page and, under the "Registrar" column, click "Manage" for the relevant domain. The next page will (if, as noted above, your domain is unlocked; otherwise unlock it first) have a "Remove RespectMyPrivacy.COM" link in the "Actions" box.
In most cases there will be no disruptions. The only thing that might be interrupted would be if you are using DNS service with the current domain registrar. It's possible they will terminate that service upon transfer of the domain, so you might want to switch the DNS service either to us or a third party before you transfer the domain to us.
Assuming that your DNS is valid and continues to operate, there should be no interruptions in any services tied to that domain during the transfer.
No, we are not. We have integrated the registration services of Public Domain Registry, an ICANN-accredited domain registrar, into our member interface to provide domain registration. Public Domain Registry enables us to offer great prices and, more importantly, enables us to support our members ourselves, all the way through the domain registration process.
We have on several occasions considered ICANN accreditation and decided against it. The development effort required to individually integrate different systems for each registry would significantly detract from our core mission to develop the best possible web hosting. And once we went to all that development effort, we would have a domain registration service that would be essentially identical to what we can already offer; domain registration doesn't have a lot of room for innovation.
We would also have a lot of development expense and accreditation costs to recoup, which for a company of our relatively small size would most likely translate to several years of higher prices for our members with little additional benefit. Should we ever decide that ICANN accreditation offers our members some compelling benefit, then we would revisit it.
Yes. Note that if you just registered or renewed it recently, you'll have to wait until the sixty-day waiting period is up before you can transfer it to us or another registrar.
If 60 days have already elapsed since you registered or renewed it, you can transfer it, and you'll not only keep your existing time you already paid for with the current registrar, but we'll also give you an additional year as part of the transfer.
Do note that if you prepaid for another registrar's privacy service, they are unlikely to refund that to you, so that money would probably be lost.
We offer three renewal settings, which can be selected or changed at any time via the Renewal Monitor or the info panel for the domain:
If you select automatic renewal, your domain will automatically renew and you will be charged for the renewal, as long as your account balance is high enough. In this case, "high enough" means that renewing the domain will not trip your lowest account balance warning (by default, $1.00). If your account has insufficient funds to process the renewal our system will keep trying once per day until you disable auto renew, the domain expires and is deleted from our system, or you deposit enough funds for the renewal to succeed. Each time our system attempts to auto-renew a domain, you will receive an email with the results (success or failure). This means you will get daily emails when a domain is about to expire (and for some time afterward) if you do not have enough funds available. Remember that domain renewals are non-refundable, so be sure that you only enable this setting if you are sure you want the domain to auto-renew.
If you select manual renewal, you will receive email reminders, beginning a week prior to your domain's expiration, but since domain registration is so important, we encourage you to have your own reminder, in case ours get lost or misfiled as spam.
If you select not to renew, you may still renew the domain at any time, but it will not automatically renew, nor will you receive any reminder emails. This option is most appropriate for domains that you intend to let expire.
The reason for this depend on the domain transfer status.
First and foremost, if your domain transfer status is "Transfer waiting for Admin Contact Approval" then you need to take action. Check the domain's current administrative contact email address for a confirmation message with a link to a site where you must select to approve or decline the transfer. If you haven't received this message, contact us to have it resent, but please make sure you're checking the right email address. If we don't get confirmation within five days, the transfer will fail.
Once you confirm the transfer, any domain registrar is entitled to stall an outbound transfer for up to seven days. If your domain is in this state, it will show up in our system as "Transfer waiting for Losing Registrar Approval."
Some registrars simply make you wait the full period. Other registrars offer a way to expedite the transfer from their site, even if they send you an email saying you don't need to do anything. However, of these, a few registrars don't actually implement anything as a result of approving the transfer and still make you wait. Some registrars don't impose any additional delay at all; we have seen people place transfer orders that were fully completed within hours, while many others have to wait the full seven days every time.
Because this delay is imposed by the registrar you are transferring away from, we have no control over it and cannot help to expedite your transfer.
A much less common domain transfer status is "Could not Fetch Current Administrative Contact Email Address. Will attempt again every hour." This means there is a problem retrieving the admin contact email address from the domain's current registrar. This is an internal problem related to the registry prototol (EPP) and can occur even if the whois information appears correct. This status is typically auto-correcting within 12-24 hours and no action needs to be taken on your part and nothing you or we do can speed it up. In some very rare cases, it will take too long and the transfer will fail. If that happens, simple wait to be refunded and try again; generally the transfer will go right through on the second attempt.
Should a transfer fail for any reason, we will notify you promptly via email.
Each domain transfer has the following steps:
These are the high-level steps. This section of the FAQ contains many other entries that provide detailed information for the various steps.
If you transfer the domain without first updating the name servers, this can happen even if you have set up your DNS here. Your domain will continue to point to the old DNS servers until you update it.
To update the domain:
Your name server information is not updated during a domain transfer. To avoid problems, we strongly recommend that you update your name server information at your old registrar before you initiate a domain transfer.
If you are obtaining DNS from your old registrar and you don't update your name servers, they will probably remove your DNS service when they process your transfer. This typically manifests as your domain suddenly going to the old registrar's parking page or failing outright after the transfer completes.
To find out how to update your name servers on another registrar's system before a transfer, contact them directly.
If you have already transferred a domain without changing the name servers and you now need to update them, please see this related FAQ entry.
Usually not.
When you place an order for a domain transfer, the registrar sends out an email to the current administrative contact's email address requesting approval of the transfer. Most proxy registration services automatically discard this message, making it impossible for you to transfer your domain away. Your only option is to cancel the privacy service before initiating the transfer, thus exposing your personal information. Unless you are willing to temporarily forego your privacy you can never switch away from that registrar, which is why we call this situation "extortion by proxy."
To avoid delaying your transfer, we strongly recommend that you cancel any proxy registration service before you initiate the transfer. Since not all changes happen immediately, you may wish to consult the whois information for your domain to make sure it has been canceled before placing your transfer order.
If you have already placed your transfer order and you find yourself in this situation, you will have to wait for the transfer to fail (usually seven days from the time you place the transfer order). See this related FAQ entry for complete details.
Our members have reported encountering this problem with most proxy registration services. (Naturally, RespectMyPrivacy does not have this limitation, as it is designed to respect your privacy, not prevent you from controlling or transferring your domain.)
If you let your domain expire, you can usually renew it as normal during the renewal grace period. After that, there is no automated process for renewal. Such domains can often be recovered, but the desire to do so must be communicated manually all the way up the chain from you to the TLD registry, who must then perform the recovery by hand. For this reason, they charge a hefty fee for such recoveries, which we must pass along. The fee is currently $66.
What does this mean? If your domain has expired and is now past the grace period, you have two options:
If you choose to wait, you risk the domain being registered immediately upon deletion by domain "tasters" who traffic in used domain names to see if they attract profitable hits. Due to a policy loophole that makes the practice essentially free, this happens more often than you might think, although not as much as it used to. If (when) they get the domain, tasters will often want hundreds or thousands of dollars to sell it back to you.
If you choose to pay the redemption fee, it takes 2-3 days for the manual request to process through before you can use the domain again. There is no way to expedite the recovery.
Neither choice is attractive, which is why we recommend against letting your domain registration lapse unintentionally. If a domain you want to keep expires, renew it immediately. But try to avoid letting important domains expire at all. There is no penalty for early renewal, and we offer domain auto-renewal for critical domains that must not be allowed to expire.
If you are in this situation and want to pay the redemption fee, make sure you have the funds on deposit and support points and open a Secure Support Issue as soon as possible so we can initiate the process.
As soon as our system records the failure of the domain transfer, you will receive a refund of the transfer cost and you can try the transfer again. This process is semi-automated, which means we will do it for you without being asked, but we typically only process failed transfer refunds twice a day.
Please note that if your transfer fails you cannot re-attempt the transfer of that domain name until the refund is issued. Also, you should not re-attempt the transfer until you have understood or resolved the issue that prevented the previous transfer.
Our domain registration services are designed and intended to be used in conjunction with our hosting services. Child name server records (AKA glue records) are used only when you are maintaining your own dedicated DNS servers, and therefore are not needed or used by the vast majority of our hosting customers. Consequently, we do not provide this feature via our member interface.
However, if you have a need for name server glue records in your domain, send us a secure support issue containing the hostname and IP address for the desired record(s). You will be charged two support points for the first glue record add, change, or deletion made in any single request, and one point for each additional change made in the same request to cover the admin time required to manually perform these changes on your behalf. Please make sure your domain is unlocked when requesting child name server maintenance.
At this time, we can add only IPv4 (A) glue records; our registrar currently does not support IPv6 (AAAA) records.
No, we cannot. The administrative contact must approve the transfer by responding to an email message, and the email address that must be used is the one that is active at the time the transfer is initiated. It would facilitate domain hijacking if there were a way to start a transfer and then override who approves it.
If you have started a domain transfer using incorrect contact information, you have the option of opening a secure support issue requesting that we manually try to have the transfer attempt canceled. If you prefer not to do that, you'll have to wait for the transfer to fail and be refunded, which generally takes seven days from the initial transfer request. In either event, you can retry the transfer as soon as it fails and you see the refund in your account balance. Make sure you have the correct administrative contact email address before retrying the transfer!
Be careful to update the administrative contact without altering the registrant information. If the registrant information is updated, your old domain registrar may refuse to transfer the domain for 60 days. (They're not really supposed to, but sometimes it happens anyway.)
The requirement for valid contact info in your domain whois information is an ICANN requirement, not a requirement of our TACOS. As a practical matter, this requirement is only very rarely enforced.
The primary risk you face if you don't abide by this requirement is having your domain suspended or canceled if someone makes a complaint. If someone doesn't like you or your domain's content, invalid contact information can give them a pretext to cause trouble or get your domain immediately shut down.
However, that is not the only problem. If your domain contact email address is invalid, you're likely to miss renewal notices or other potentially important messages. There are good reasons for requiring accurate information.
Although the validity of domain contact information isn't something we have the resources to proactively monitor, if you ask for support related to a domain with obviously false information we'll have to ask you to correct it before proceeding. We are also required to resolve complaints when they arise, which typically means suspending domains with obviously bogus contact information until the registrant is ready to resolve the issue.
We urge you to follow the rules and provide valid contact information. And even though we enforce those rules reactively, rather than proactively, we absolutely can't be responsible for anything bad that happens to you or your domain as a result of invalid contact information.
If you use RespectMyPrivacy proxy contact service, your domain information is considered valid by definition so long as you comply with our Terms & Conditions of Service requirement to provide accurate account and contact information to us.
Our members have requested registration support for some additional country-specific top-level domains (TLDs) via our feature voting panel. To show your support for one of these ccTLDs, feel free to vote on such a proposal.
We are somewhat hesitant to allow adding ccTLDs for countries other than the United States due to concerns about giving those countries political, economic, or legal leverage over us or our members. Most ccTLD operators are part of or run on behalf of the country's government, and they typically include something in their registrar agreement about "Paragraph 1219: You will follow all of our country's laws." and "Paragraph 2751: The ccTLD operator reserves the right to terminate this reason at any time for any reason." Either could cause serious problems for us. Suppose, for example, that we offered registrations in Elbonia's .eb ccTLD and accumulated a few thousand .eb domains. Then suppose that the Elbonian government decided they didn't like a site we host that criticized their Grand Vizier's hat, and told us to get rid of it or have all those domains seized.
While that's a little farfetched, we have had conflicts with foreign governments over member sites, and handing significant leverage to people who may not have our members' best interests at heart doesn't seem like a good idea.
Yes. If you have more than 10 domain registrations, renewals, or transfers to process in a single batch, you can create a list of domain commands and submit them to us in a secure support request. We'll run them for you, charge you accordingly, and send you back the results. Please do not send us a list with less than ten actions, or a list that contains more than one action for a domain, as we will not be able to process them.
Here are some examples:
register example.com register example2.com private register example.biz auto transfer example.org abcd12345678 auto renew example.net
If you want our RespectMyPrivacy.COM service, you can just add "private" to the end of a "register" or "transfer" line for the domain you want it set up for. Similarly, if you want registrations to auto-renew year after year, you can add "auto" the same way.
There are no bulk discounts; we give everybody the best possible price. But, if you have a lot of domains to manage, this feature can make the process signficantly easier for you. Please contact us if you have any questions about it.
The purpose of RespectMyPrivacy is to keep your contact information out of the public WHOIS database while still permitting you to be contacted if necessary. Expired domains persist in that database, complete with publicly visible contact information, for a really long time before they are finally deleted.
Once a domain expires, it is suspended by the registry and no changes can be made, so RespectMyPrivacy cannot be removed or cancelled in the usual way.
Once your domain is deleted, RespectMyPrivacy will be automatically cancelled.
To remove RespectMyPrivacy from your domain before it expires, see this FAQ entry. If your domain is already expired and you really want to remove RespectMyPrivacy, use the Abandon a Registered Domain assistance request and we will manually remove it.
A push transfer is a special type of intra-registrar domain transfer. This happens in one of two cases:
In the former case, just follow our standard asset transfer procedure.
The latter case is a bit more complicated. You'll need to submit a Secure Support Request indicating the domain you want to transfer and which funded account you want the domain associated with. We will provide you with a unique customer ID number. You must take this number and your member contact email address and go back to your existing registration provider and initiate the "move services" action. Sometimes they offer this functionality through their control panel, and sometimes you will have to ask them to do it for you. Once you have completed the transfer, you'll need to reply back to us so we can confirm receipt of the domain and add it to your control panel.
In both cases, push transfers do not cost anything, and do not extend the registration time of the domain. You can renew the domain before or after the transfer if you want to extend the registration time. Expired or suspended domains cannot be pushed.
If you need to do a push transfer away from NearlyFreeSpeech.NET, just provide us with the recipient's customer ID number and email address via a secure support request and we will take care of it for you.
When a domain name is locked to prevent hijacking, it may not be transferred or renewed, and its contacts, name servers and RespectMyPrivacy.COM settings may not be edited. If you need to make these kinds of changes, simply unlock the domain and these options will appear in the action box on that domain's information page. Be sure to lock it again when you are finished!
To find the domain's registration information page, visit the "domains" section and then, under "Registrar" for the relevant domain, click "Manage."
If your domain is registered through us, but is set to require manual renewal, follow these steps to renew it:
If your domain is registered with us and it is set to auto-renew, it will renew automatically about a week before expiration with no action needed on your part, provided there are sufficient funds in your account. (You'll be warned repeatedly and often if the necessary funds are not available.)
If your domain is not registered through us, you will need to contact your registrar to renew it.
Remember, any renewals add on to the existing registration. So if it is May 2009 and your domain expires in August 2009 and you purchase a one year renewal, your new expiration date will be in August 2010, not May 2010. There is no penalty for renewing early!
Regardless of the renewal method, the maximum length of time on a domain registration is ten years from today. Thus, if your domain expires in five years and a few days—for example, if today is February 16, 2010 and your domain expires on February 21, 2015—you'll only be able to renew it for a maximum of four more years, because it can't be renewed for a partial additional year. Our system won't let you select a number of years for renewal that exceeds the allowed maximum of ten. (This also means that for a domain that expires in more than nine but less than ten years, our system won't let you attempt to renew it at all.)
The first (and possibly most important) thing that happens when your domain expires is that it stops working. Not only are its records withdrawn from the registry's master DNS servers and replaced with "parking" records by the registrar, but its information becomes frozen and cannot be changed or updated. This has implications for domains with RespectMyPrivacy.
After expiration, your domain enters the "renewal grace period." This is (usually) a 40-day period* during which the domain can be renewed at the regular cost.
After the renewal grace period, the domain enters the "redemption grace period." During This period, usually 30 days**, the domain can still be renewed, but it costs a lot more and takes a day or two to complete.
(Any renewal during either grace period will be effective as of the original expiration date; you can't get extra time by renewing after the domain expires.)
After the redemption grace period, the domain enters the "pending delete" status, where it typically remains for five days. It cannot be renewed during this period. After that, the domain is really, really gone and is free to be re-registered. Thus, the average domain can linger for as long as 75 days after deletion.
For awhile, it was the case that virtually every deleted name was instantly snapped up by speculators, but as of August 2008, that seems to be somewhat less common than it was. Nonetheless, the more valuable your domain is, the more crucial it is that you not take the chance.
*The length of the grace periods is not set by us and changes from time to time without notice to us. Thus we can't guarantee the lengths referenced here. Renew your domain as soon as you can if you care about it.
**Redemption grace period lengths also vary by TLD. For example, the .NAME domain currently provides only a five-day redemption grace period.
Our domain registration services are provided under the auspices of a third-party company, Public Domain Registry. They are required by the various top-level domain registries and ICANN to impose various conditions on registration.
Public Domain Registry also resells web hosting and other services using a product they call "OrderBox." We are not resellers of the "OrderBox" services. They have a laundry list of terms and conditions for the use of those services that can be found in "Appendix A" of their Registrar-Registrant agreement, which you must agree to in order to register domain names through us.
Unlike our own Terms and Conditions of Service, theirs are fairly typical for the hosting industry, including a variety of prohibitions against controversial behavior that are highly inconsistent with our own. The contents of their "Appendix A" do not apply to your use of our hosting services.
The enforceability of their agreement is strictly limited to your use of their domain registration service. "Appendix A" applies to your use of their hosting (or other) services. Since you are using our hosting services, not theirs, its prohibitions are irrelevant to you and are superceded by our own Terms and Conditions of Service. Public Domain Registry has no authority or ability to interfere with your NearlyFreeSpeech.NET hosting services. No matter what you do, their sole remedy would be refusal to process your domain registration.*
To look at it another way, since we do not provide those services, you are not allowed to use their "OrderBox Services" at all, so the question of how you may use them is moot. It's unfortunate that they have chosen this "everything and the kitchen sink" approach to their agreement, but they did.
If you register a domain with an offensive or controversial component, you are at a certain level of risk of having your domain cancelled, but not from Public Domain Registry. Each top-level domain registry has different rules for what domain names they will allow, and no matter what registrar you choose, you will always be subject to those rules.
If this is a concern to you, do not register a domain name (anywhere) containing an offensive or controversial component.
*Should a circumstance ever arise where Public Domain Registry refuses to process a registration that is otherwise acceptable to the governing top-level domain registry, we will make sure you receive at least a pro-rated refund for any time remaining on that registration, and we will provide as much assistance as we can to help you secure the registration through another registrar. This has never happened, and we have no reason to suspect it ever will.
Any time you want.
When you renew a domain, the renewal period begins at the end of the current registration period. In other words, renewing for one year adds one year to the current expiration date, even if the current expiration date is months (or years) away.
Exception: Your domain can never be registered for more than ten years. So if a domain's current expiration date is 9.5 years away, our system will return the error "this domain is already registered for the maximum duration" and not allow a renewal attempt. You'd need to wait until a full additional year could be added before you'd be able to renew it.
Please don't wait until the last possible minute to renew (or transfer) your domain.
The complete list of top-level domains (TLDs) in which we can provide domain registration services can be found on this page.
Currently we offer only global (gTLD) domains. If you want to register a domain in a specific country's top-level domain (ccTLD), you will need to contact a registrar accredited by that country.
If you already have such a domain and wish to use it with our service, this is generally no problem. Just add your domain to our control panel as an existing domain, create DNS for it, and have your registrar update your name server information accordingly.
See also this entry about adding new TLDs.
To transfer your domain to another registrar, you will need a transfer code, also known as an EPP code, auth info code, or transfer secret.
To get yours, make sure your domain is unlocked. Once it is, go the the domain information panel for that domain, reachable by clicking the "Manage" button next to your domain name on the Domains tab. Once there, select the "Retrieve Transfer Code" action from the action box in the upper right corner to retrieve the code.
In order for a domain to be successfully transferred to another registrar, it must be unlocked during the whole process and it must not have been registered, renewed, or transferred in the preceding 60 days. Only the member who registered the domain can request the transfer code.
If you have a large number (10+) of domains registered and you need to transfer them all, we can retrieve all the transfer codes for you at once. Just send us a secure support request.
As with canceling service, we will not ask why you are transferring the domain, hassle you, or attempt to stop you (unless one of the above limitations applies). But it does make us sad to see domains transferred away, so if there's something you're unhappy with that we might be able to do something about, please let us know before requesting the codes.
External domains are those domains which are registered through some other company that are not eligible be transferred in to our service. This typically includes domains in top-level domains that we do not support for registration, such as all ccTLDs.
Note: As of October 20, 2009, we have finally developed a workaround for the problem described here. When you add a contact, you will have the opportunity to edit the information yourself before the contact is created, and if the new contact matches an existing one, you'll get a warning on the spot and a chance to fix it, instead of weird counterintuitive behavior popping up later. We're leaving the description of the old behavior for now to benefit people to whom this has already happened.
With the domain registration system we use, when you create a new contact, your default contact information is used. However, if there is already a contact with the exact same information, the system will not really create a new contact. Instead, the registrar's system tells our system that it created one, but actually reuses the existing matching one.
If you have never edited your existing contact, this can lead to very surprising behavior: if you "add a new contact," and then edit it, you will find that all your domains' contact information using the default contact info have been edited. This is almost never what you want. Unfortunately, since the "contact reuse" is not happening on our end, we cannot change this behavior.
The workaround for this problem is to edit your existing default contact information somehow before adding a new contact. Any change will do, such as adding or removing a middle initial.
The most common causes of transfer failure are:
The other registrar is not required to give us a reason for refusing a transfer, so if the problem is anything other than "the administrative contact did not confirm the transfer," we won't be able to provide you with any information.
When domains expire, the registrar shifts the domain's name servers to special "parked" nameservers. As soon as the domain is renewed, the name servers are switched back. However, the global registries serve 2-day time-to-live (TTL) values when delivering name server glue records.
This means that most people who haven't already seen the "parked" domain will be able to see the site after it's renewed. However, anyone who tried to access the domain while it was expired (including, most likely, you -- its registrant) may continue to see the "parked" page until the two-day time-to-live period expires. It is possible to see the exact remaining time with the Unix command line utility dig, if it is present on your local system.
Although this doesn't tend to affect most site visitors, those who are affected have no recourse unless they have direct control over their local name servers. This is standard to the global registries that operate each TLD and thus works exactly the same for all registrars. It is not something we or our registrar chose or have control over.
In order to prevent this, NearlyFreeSpeech.NET recommends that you either use our auto-renewal feature to make sure your domain never expires or pre-renew your domain so it is never within a year of expiring.
If you receive this error while attempting to make changes to your domain's name servers, it means the registrar rejected the names you provided. There are several reasons why this can happen:
These are pretty self-explanatory, except for the requirement that name servers be registered. If you want to use a name server like ns1.example.com, that name needs to be registered as a child name server (along with its IP address) by the registrant of example.com in order to create the necessary NS pointer records ("glue records") at the gTLD registries. If you got these name server names from someone else, check with them to ensure the names have been registered as name servers. If you registered the domain containing the name server names here and now need to create new child name servers, see this FAQ entry for instructions.
Unfortunately, the error response they return is neither human nor machine readable, so it does not indicate which of these is the case in a way we can automatically display. The good news is that the causes are few and easy to check. If you would like us to manually look up the error response in our logs and convert it to a human-readable explanation, we can do that if you open a paid support issue.
Domains cannot be re-renewed immediately after they have been renewed; to prevent accidental double-renewal orders from getting placed they are locked out for a period of time. During that time, they won't show up in the renewal monitor.
Recently-renewed domains should reappear on the renewal monitor within a few hours. Until they do, you can still view and edit them as normal on the domains tab and their individual domain panels.
When the registry interface we use returns an error, the error messages are usually neither human nor machine readable, so we sometimes have to mask them with this message.
Here are some of the most common reasons this can happen:
If you've following all these restrictions and you still can't figure out what the problem is, please ask. We do have a way to look up the error and decode it by hand, and if it's not one of the above, you won't be assessed support points for us to do that. (If it is a reason listed here, you will.)
As an anti-spam provision, each web site has a dynamic email limit called its "email bank." This represents the amount of email that a site can send before it is rate-limited. By default, the email bank can hold a maximum of 100 "points," each of which can be used to send one message. Points accrue at the rate of one per minute, starting from 0 when the site is created.
Each site's email bank values are shown on the site information panel as a fraction on the "Email Sending" line. The first number indicates the current size of the email bank, and the second number indicates the maximum size. For example, if it shows 75/100, it means the site's email bank currently contains 75 out of a maximum of 100 points.
Each time your site sends a message using the PHP mail() function, the email bank will be debited one point. As long as your site's current email bank size is positive, it should be able to send 30-60 messages per minute. If your site's email bank reaches zero, additional messages sent will be queued until more points are available, effectively rate-limiting additional messages to one per minute. If your site has queued outbound messages, this information will also be visible on the site information panel.
If your site generates a large mail queue, usually the result of a vulnerable email form, we will automatically investigate. First, to protect your privacy, we will use automated tools to spam-scan your outbound messages and if and only if we believe there is an issue, we will manually check your queue, remove spam, disable any exploited scripts, and contact you about the problem. If the messages are not spam, they will be cleared to send and/or your maximum bank size may be raised to accommodate the typical volume of email that your site sends. If you have an increased bank size, you will both send messages and recover bank points more quickly. Most reviews take place during our standard support hours, so if you have a large volume of mail to send, please try to avoid sending it in the middle of the night or it may get delayed until the following morning.
The email bank applies only to emails sent by your web site. Email forwarding is an entirely separate service and has no connection to any site's email bank. Currently, the email bank applies only to site emails sent via PHP. While emails sent via CGI are not currently counted, they will be in a future update.
We do not currently offer email hosting, nor are we offering any reseller arrangements in this area at the present time.
If you prefer a free solution, Gmail seems to be the most popular, and can be used with domains via the advertisement-supported version of Google Apps, although some of our members find trusting Google with such sensitive information difficult.
Other (paid) email services that people have recommended include FastMail, Tuffmail, and Hushmail.
This is one of the great scourges facing the Internet today. Anyone can forge email to make it look like it came from anyone, and spammers do. They don't need anything special, no passwords, no special access, nothing. They pick domains at random in order to help obscure who they are and where they are coming from.
If this happens to your domain, the symptom will be that you will receive a large number of bounce messages for messages you never sent. If you investigate further, you will generally find that the From: addresses of the messages are either fake names (frank@yourdomain.com, bob@yourdomain.com) or gibberish addresses (2nkdklwejw@yourdomain.com).
When you configure your mail client to send mail from your domain instead of your ISP's, it's completely between you and your mail client. Everybody else has to trust that you told your software the truth. Nobody can stop you from putting "president@whitehouse.gov" as your sender address. Spammers abuse this trust to send out their messages.
The emails you're talking about never pass through our system, so we can not help you figure out where they are coming from or help stop them. In general, messages of this type are sent through hacked machines belonging to residential cable modem Internet subscribers, or they are sent through unprotected servers in developing countries like China.
This happens with literally every domain registered sooner or later and at present, there is unfortunately absolutely nothing that can be done to stop it. This is true no matter what domain registrar or hosting company is used, and is even true if the domain isn't used for web hosting at all.
For more information about this subject, you may want to search for news articles about Microsoft's Sender ID proposals, and Yahoo!'s Domain Keys research. msn.com and yahoo.com are two of the biggest victims, both in terms of junk mail received and in terms of fake mail sent looking like it came from their domain, so they are very interested in bringing this nonsense to a halt. Unfortunately, as big companies do, they are still arguing about whose idea is better.
We are experimenting with Sender Policy Framework, a precursor to some of the proposed technologies. Unfortunately, it doesn't seem to offer a lot of promise yet. We do offer an SPF option for domains not used for email, which is a helpful step if it applies.
While you cannot prevent this from happening, you can diminish its effects on you. Most of the people who get buried in bounce messages have the "catch-all" email forwarding enabled. You can disable this and set up only specific email forwards, and this will dramatically decrease the number of bogus bounce messages you receive.
Our theory is that Gmail does not like "duplicate" messages. Because there is a copy of this message already in your "Sent" folder, it appears that gmail will ignore the copy that has made the round trip through our server and back.
If you try your test from some other gmail account (one other than the one the message will ultimately be delivered to) then it should arrive normally.
Gmail also filters spam and viruses fairly vigorously, and sometimes test messages blend in, so don't forget to check your "Junk" folder if you're expecting a message that hasn't arrived. We also have some reported cases that messages sent to gmail sometimes simply don't arrive (whether forwarded through our system or not).
In order to fight spam, our email servers have very high standards for accepting email. Occasionally, this may cause someone who wants to send you email from a misconfigured email server to run into problems. If you can get a copy of the bounce message and forward it to us, we may be able to point the server operators in the right direction as far as fixing their problem, but since it is their problem, it will be up to them to fix it.
Since most of the inquiries about this come from people who are not members but have email problems and don't know what to do about them, most of our documentation of this subject can be found on our public Email Acceptance policy page in an attempt to help them.
Most mail programs, such as Outlook, Outlook Express, and Thunderbird, have the ability to do this with just a few minutes' worth of configuration. However, you must have an email server that you can use to send these messages; we do not provide that service.
In almost all cases, the email server you need is run by your ISP, and it is the same email server you would use to send mail from your regular ISP email account. Since ISPs vary widely, we cannot provide more specific guidance than this. However, they should have their own technical support that can help you get this set up.
For many reasons, we cannot provide this service to you. Most ISPs block access to outside mail servers by their users because of the email problems created when one of their users' computers gets a virus. Even if yours doesn't (and they probably should), you cannot use our servers to send mail as this is a technique called "relaying" that is used by spammers to conceal the origin of their messages. As a result of that, the practice of relaying is now deprecated and is not supported.
Follow these steps:
NOTE: You will be charged for email forwarding until you remove it using the above steps; disabling it will not be sufficient.
You will need mail server information (called MX records) from your third-party email provider. Once you have obtained this information from them, follow these steps:
The defining characteristic of any email forwarding service is that it forwards the email it receives on your behalf to some other mail server. When it comes to spam, this is a problem.
If we forward spam to other mail servers, those other mail servers don't know we didn't originate it. ("Hey, I really got this message from that other guy!" is a common spam sender trick.) If we forward enough of it, they will assume we are spammers and block our forwarders from delivering email to their mail servers entirely. Doing our best to prevent spam is the only way we can assure our continued ability to provide this service.
For that reason, we cannot honor requests to bypass our filtering mechanisms under any circumstances. To do so would threaten not only our ability to forward email to the member requesting it, but also our ability to forward email at all.
This is an unfortunate circumstance, but it's a necessary evil and is true for all viable email forwarding services, not just ours. If you have some special circumstance that requires you to receive spam, spam-like email, or viruses, or if you simply want to exert maximum control over how your email is handled, you will need to eschew the use of any type of forwarding and arrange for a direct-delivery email service that provides that level of control.
About once a month, one of our members reports that their NearlyFreeSpeech.NET email forwarding service will not forward messages to their Comcast email address. This happens because Comcast occasionally blocks one or another of our email servers for sending email in "patterns which are characteristic of spam."
It seems they automatically block based on a fixed number of "spam-like" messages from any given server and since we handle email for so many domains, it's not impossible for us to hit the limit from time to time because we forward email without considering the contents.
Of course we can't just throw away a suspect email message, because if it's a false positive, it will disappear without a trace and that's unacceptable to us (and almost certainly to you). However, throwing away email isn't unacceptable to Comcast; rather, they appear to demand it, and because we refuse to do so, sooner or later this happens. So far they refuse to engage in a constructive discussion on this subject or even acknowledge the problem.
Consequently, we recommend not using email forwarding in conjunction with Comcast email addresses. But if you do, and they block it, just let us know. We'll fill out their little form and they will most likely remove the block in a few hours.
For information about the anti-spam measures we take, see this FAQ entry and our Email Acceptance Policy.
We need you to have a current, working email address at all times in case we need to contact you about problems. If your email address is hosted here and there's a problem with your hosting, we might not be able to contact you. That's bad.
For example, suppose your domain's email stops working. And suppose that you forgot your password and need a new one mailed to you to fix things. But you can't get the email you need to fix things, because things aren't working. In cases like that, our Privacy Policy turns from critically important protection into a colossal roadblock; you'll wind up giving us a DNA sample and fingerprints to get your access back. (Well, not really, but it'll feel like that, especially if you're in a hurry.)
These types of circular dependencies create a lot of headaches, so we simply don't allow them.
If you don't want to have multiple email boxes to keep track of, there is a workaround. If your primary email address is in the domain that you want to host here, which is not uncommon if you have a business, what you can do is set up a special alternate email address somewhere else, for example at a reasonably reliable provider of free email accounts, and easily set it up to forward copies of all the messages it receives to your normal mailbox. That way, you'll get all the messages, but if there's ever a problem, you can fall back on the alternate mailbox to get in touch with us, secure in the knowledge that it's got copies of any recent messages we've sent you to work from.
Just be sure that you don't need your primary email address to reset your alternate one, in case you forget both. A bigger circular dependency is still a circular dependency.
Greylisting is a technique we use in conjunction with email forwarding designed to help differentiate misconfigured servers from spammers and virus-writers.
A variety of standards and best practices exist around the protocols used to send emails and identify their senders (SMTP and DNS). Most servers follow these standards very closely. Spammers and email virus writers, on the other hand, are just as uninterested in standards as they are laws against what they do.
If (and only if) a standards compliance problem is detected with a sending server, the message it's sending is refused by us, and the sending server is added to the greylist. If the server tries to send that same message again a little later (one to four hours, depending on how messed up the server is), the message will be allowed and that server will be automatically added to a whitelist of servers that have passed the test.
Legitimate mail servers are required to queue messages and try them again later, so to them greylisting is a temporary inconvenience (plus it puts messages in their logs telling them to fix whatever problem(s) got them on the list). Viruses, on the other hand, have to fit their SMTP engines into small spaces; even if they wanted to implement a system that retried messages, they typically have no place to queue them. Greylisting is thus very effective against viruses in general, even new viruses that standard virus scans don't know to detect. Spam senders are somewhere in the middle; many use poorly-written software that simply sends out as much as it can as fast as it can, ignoring errors, and greylisting can be a pretty effective barrier to those.
The greylist (and the associated auto-whitelist) is on a per-sending-server basis and is shared by all of our email forwarding domains. Once auto-whitelisted, a legitimate server stays there until it goes 32 days without sending any mail; every time a message goes through, the clock resets. So as long as a server sends a message to someone using our email forwarding service at least once per month, it will stay in the clear.
In the event of a conflict, the spam blacklist (a list of known spam sources) overrides the auto-whitelist, so if a sending server is identified as a spam source sometime after being auto-whitelisted, its messages will still be thwarted.
Part A: Get your name server information from our system.
Part B: Update the legacy registrar's system with the name server information. If that registrar is Wild West, use the instructions below; otherwise see your registrar for information on updating name servers.
NOTE: We have received reports that this portion of the FAQ entry is out of date. You may need to vary the steps slightly to perform this function.
That should be all there is to it. This change will usually be visible the next morning (US time), and sometimes sooner, but the official line from the reseller is that it takes 24-48 hours.
This happens when you do not properly update your name servers after setting up NearlyFreeSpeech.NET DNS. After setting up NearlyFreeSpeech.NET DNS, you must log in to the legacy registrar's web site and enter the information about name servers found on the DNS information page for that site (click the "Domains" tab at the top of the page, then under the "DNS" column, click "Manage" for the relevant domain name), or your domain name will remain "parked" indefinitely and you will not be able to use it.
To verify that this is the cause of the problem, try accessing your site using all of the names in the "Site Names & Aliases" box on the Site Information page in our member interface (click the "Sites" tab at the top of the page, then click the name of the relevant site in the "Your Web Sites" list). If the "sitename.nfshost.com" name works but your domain name does not, or if you get different error pages from the two names, then something else is likely responsible. You may want to check other FAQ entries, try our Site Troubleshooting Wizard or send us a secure support request.
For legacy registrations, this FAQ entry explains how to perform this update.
Depending on the top-level domain and registrar, this change may take up to 48 hours to take effect after you submit it to them.
No. The legacy domain system is run by a separate company, and we have no access to each others' account information. They accept a variety of payment methods, including credit cards and PayPal.
If you register domains using our built-in system, then you will be able to use your personal bandwidth account.
In almost all cases, yes. The legacy registrar does not provide standalone DNS service, so if you want to use the domain name in conjunction with our hosting, you will probably need NearlyFreeSpeech.NET DNS.
We have written up detailed instructions to help with this process.
Since legacy domain registrations are handled by a completely separate company, we are very limited in the level of support we can provide for this service. They do offer their own separate support, which you can reach by visiting https://www.securepaynet.net/gdshop/support_submit_question.asp?prog_id=nfsninc. If you need to email them, the address is support@secureserver.net.
We have made AWStats, a graphical site statistics package, available for our members. Setup instructions for AWStats have been moved to our Wiki.
They are located in the /home/logs directory, as seen ssh, or the /logs directory as seen from FTP.
Most FTP clients start in the /public directory, so you would need to first change to the root directory (/) before you will see this.
Access logs are the most common type. Each line in the access log represents one access to your website. It contains a variety of information, like what IP address accessed your site, what they accessed, what web browser they used, and etc. This is the type of log file that is most commonly used by statistics-generating programs like awstats and analog.
Error logs contain information about problems with your site. Although they contain lots of generic information, like records of attempts to access pages that don't exist, they are most important to web developers and people with complex software loaded on their site. Whenever software running on a site has a problem, it should (but doesn't always) say something about the problem in the error log. Finding that message can save you fruitless hours of wondering what the heck is wrong with your site, which is why the first question that typically gets asked when someone has a problem with PHP or CGI is "have you got your error log on?" Followed quickly by "what does it say?"
The third type, rewrite logs, are a bit more special-purpose. Rewrite logs track internal changes made to URLs by Apache. They're generally only useful when debugging these changes if you've set up your own rewriting rules, because the time it takes to write rewrite logs to our disk can slow your site to a crawl if you use a lot of them. If you don't know what a rewrite is or why you'd want to log them, you should definitely leave this one turned off.
When you ask to rotate your logs, our system waits for an opportune moment and then does it. Your access_log file, for instance, becomes access_log.1 and a new access_log is created. It may not be right away, particularly if there is a lot of compression involved, but it usually takes just a few minutes.
If there was already an access_log.1, it becomes access_log.2 and is eligible for compression. If there was already an access_log.2, it becomes access_log.3, and so on. The oldest log file always has the highest number.
When you rotate log files can be compressed with one of two techniques, gzip or bzip2. The default is bzip2 because it produces smaller files and saves you space. Log files ending with .2 will be compressed after you request a rotation. If you do not want your log files to be compressed, you can turn this feature off on the Site Information page.
Here are the steps for enabling log files:
If you're planning to measure any kind of statistics, enable the access log. For best results, enable it a week or so before measuring your statistics, as data from a longer period of time will produce more informative reports.
To find and debug problems with your site, enable the error log. If you submit a support request about an error message received from your site, we will often ask what your error log says about it. If you do not have your error log enabled, we may not be able to help you diagnose some problems.
We also provide a rewrite log which can be enabled in the same way, but may be set to varying levels of verbosity. Do not enable the rewrite log unless you are having problems with RewriteRule directives in your .htaccess file, and disable it as soon as you fix them. Using the rewrite log will dramatically slow down your site.
This code can also appear for other reasons, such as if someone accesses your site through a web cache.
The .old log files are never automatically compressed. If you rotate again, it will be renamed based on its last-modified date and only then will it be automatically compressed.
This is for two reasons. First, log entries come from many different parts of our network so there needs to be a "cooling off" period after rotating to make sure all parts of the network have switched to the new log. Otherwise, stuff might still be logged while compression is happening, and it would get lost.
Also, many people like to run analysis against a static log file. That way, if you change an analyzer setting and run it again, or if you want to do more than one thing to the log, you're working with a consistent set of logs. After log files are compressed, they're a lot harder to analyze, so keeping the .old file around often makes log analyzing much easier.
You're free to remove the .old log file yourself if you like, although we recommend waiting until you see log entries appearing in the new log file. If you rename or compress it yourself, it will not be auto-rotated in the future.
Our log files are based on the standard "combined" log file format, which is a superset of the "common" format. This format is good for web log analyzing software. The fields, in order, are:
clientip - username [time] "request" status bytes "referer" "useragent"
1.2.3.4 - - [22/Nov/2004:22:32:01 -0700] "GET /index.html HTTP/1.0" 200 0 "-" "Wget/1.9.1"
The meaning of each field is shown below:
clientip: The IP address of the machine that requested the page. If you get a "-" in this field, it may mean that your site performs HTTP accesses on itself, or that we had to test your site with some internal application. If the access has passed through a proxy server on its way to our network, additional IP information may be listed here, separated by commas. More information about this can be found in the member wiki.
dash: This field used to be used, but isn't anymore. Lots of weblog analyzers still expect it to be there, so it always appears as a -.
username: If you use Basic HTTP Authentication, the authenticated username will appear here. If you don't, it will be a -.
time: The time in the format DD/Mon/Year:HH:MM:SS tzone"
request: The request method, requested URI, and protocol, like GET /index.html HTTP/1.0.
status: The return code. The most common codes are 200 (ok), 304 (served elsewhere), 404 (file not found), and 500 (internal server error - a script error or a problem with our server).
bytes: The number of raw bytes served, not including headers, transfer encoding, or protocol overhead.
referer: The page that contained the link to the requested resource. You can use this to see who is linking to you, and weblog analyzers use it to map your site. "referer" is not a typo, although it is spelled incorrectly. It's actually in the published standard that way.
useragent: The web browser sends this to identify itself. Lots of weblog analyzers can graph this.
The status of your support issue is indicated in parenthesis after the issue summary on the support panel. Here's an explanation of the terms you might see there:
NOTE: If your membership is still a free trial, you will need to make a deposit before requesting software installation.
We can install software into the public CGI and PHP environments from several sources.
For PHP, we can typically install stable releases of any standard PEAR module. For the sake of our sanity and not introducing instability into member sites, we do not install beta or prerelease versions of PEAR modules. If you need such a module, it's usually very easy for you to download it and install it into your own private space.
Due to the onerous RAM requirements associated with deploying PHP extensions networkwide, we cannot honor individual requests for customized or specific PHP binary extensions (including PECL extensions), except through our feature proposal system. If widespread support for adding a specific extension is demonstrated in that fashion, we will consider adding support for it.
For CGI, the largest source of software is the FreeBSD ports collection, which contains 18,000+ applications. We are generally able to install any software from the FreeBSD ports collection with the following exceptions: games, client applications (like email or IRC clients), server applications, and X11 software. In a nutshell, we require that the requested port have some application to your website. Only the version of a software package officially supported by the FreeBSD ports collection can be installed. Sometimes this runs a version or two behind the latest release due to compatibility requirements or the sheer effort required to maintain that many applications. If you want a more recent version, first check to see if the version we have is up-to-date versus the ports collection. If not, please request us to update it (we rarely upgrade apps without a request to do so in order to keep the environment somewhat stable). If you need a version more recent than what the ports collection contains, please ask the official FreeBSD port maintainer politely if they can update the port for you. Once they do, then ask us to upgrade.
For perl CGI applications, we can also install most modules from the CPAN archive. In this case, we require that the built-in tests pass in our environment and, as above, that their intended usage is appropriate for our shared-hosting service.
Due to the scale of our clustered hosting environment and the inherent complexity associated with maintaining such a large number of packages on a large number of machines, we regret that we cannot globally install customized packages or software not available through one of the mechanisms described above. Nor can we install software just for an individual site. In many cases, you can manually install software for your individual site yourself, for example to your site's protected directory, with appropriate path modifications.
In all cases, please request installation or upgrade of eligible software packages through the Assistance Request system. Please don't post requests for installation in our member forum, as the forum is not an issue-tracking system that guarantees that such requests get followed up on; since we usually batch software updates and perform them once per day, forum requests are very likely to get lost in the shuffle.
Because the system problem report feature is intended only to provide a no-cost mechanism to allow our members to let us know about malfunctions affecting their service, not as a general-purpose support mechanism, the responses we can generate are limited. When you submit a system problem report, you will receive a limited response based on our findings.
If necessary (typically only in the case of insufficient information) you can reply back with additional information and we can give it another check.
If you get a response that indicates that no problem was found or that the issue is not a system problem, then you may need more information to help understand what's going on. We would recommend following up through the member forum or the regular support system.
The definition of a system problem:
A system problem is a malfunction in our systems or network negatively affecting previously-working production services that requires the manual intervention of our system administrators to resolve.
That is very dense, and each part has a specific meaning. Here's how it breaks down:
Typical system problems include:
A few examples of things that are not system problems include:
In most cases, you won't know what the specific system problem is. You have to detect them by the effects they have on your service. Some example effects of possible system problems would be:
However, situations do require interpretation. Sometimes the same effects can occur from both a system problem and something that is not a system problem. For example, if your website's domain name does not resolve because our DNS servers all crashed, that would be a system problem. If your website's domain name does not resolve because it is expired, that is not a system problem.
The most important thing to know is that if you're encountering a system problem and you think we don't already know about it, we want you to report it.
With that said, system problem reports are only one tool in the toolbox of support options we provide. Like most tools, they are not appropriate for every situation. Also like most tools, in order to get good results, it's important for you to make sure that it's the right tool for the job, and then to use it correctly. And like most tools, if you use it in the wrong situation, or use it improperly, the outcome will be bad, if not downright painful. Members occasionally torture themselves with a system problem report because it's the wrong tool for the job but they insist on using it anyway; we hate to see that.
In light of that, there are a few things to understand that can help make sure you get the best results from a system problem report.
First, familiarize yourself with the definition of a system problem report. The most important aspect of a system problem report is determining whether the issue at hand is really a system problem.
Second, system problem reports are essentially a one-way channel of communication. They are a free way for you to provide important information to us, not vice versa. The only response you will receive will be an acknowledgment of the report and, at most, a fairly generic one-line summary of the findings. It will rarely satisfy your curiosity, and it will never answer any questions or provide guidance about actions you should take. A decent rule of thumb is that if there's a question in your system problem report, you're probably not reporting a system problem.
Third, reporting a system problem is serious business, like pulling a fire alarm. We understand that mistakes happen, but if we roll out of bed and get suited up to fight the system fire on your word, and there's not one, we're going to be irritated. Our irritation will be directly proportional to how likely we feel it is that a reasonable person should have known better.
Once you submit a system problem report, we will typically receive and investigate it very quickly. Although our stated response is "as soon as possible," many system problem reports are closed within a few minutes of being created. But we do invest the time necessary to check out the report, so it may take longer.
After we've finished investigating the report and doing whatever we need to do, if anything, we'll tag the report with a response type, and optionally add up to one line of notes. You'll get a form letter back show the response type and comment and, in every case but "insufficient information," that's pretty much that. (Even "insufficient information" covers only the most simple omissions. E.g. "my site is down" and you didn't specify which of your 16 web sites you mean.)
Once we've tagged the report, it's closed. You can't reply to it and we can't respond further or in more detail. If you want or need more information (for example if the comment indicates some variant of "user error" and you need help figuring out what that means), you'll have to use one of the other support options to get it.
Those are the basics. Keep all that in mind, and the system problem report facility should work just fine for you. But sometimes things go wrong, so we'll try to talk a bit about where and how they go wrong.
We find that sometimes system problem reports get submitted inappropriately because the member has a particular misconception about what such reports are for or how they work. One such misconception is that system problem is a synonym for important. This is not the case, and attempting to misreport something as a system problem because it's important to you is a recipe for frustration. The report will be closed, everyone involved will be irritated, and you will have to start over with lost time and an even higher frustration level.
If you want the fastest possible response about something important to you that does not meet the criteria for a system problem, then opening an "Urgent" support issue is the way to go. The responsiveness goals are the same, and chance of getting a frustrating non-answer is much lower.
We also find that members are sometimes confused about which support mechanism is right for their situation, so they choose the free one. In general, if you're not sure which support mechanism is right for your needs, ask in our member forum.
Another difficulty we encounter is a redefinition of "system problem." Anything that doesn't work as expected, the theory goes, qualifies is a "system problem" because system is not working as expected, and that's a problem. This is not the case. We have meticulously defined exactly what constitutes a system problem. Please make sure you're using our definition when reporting a system problem.
Here are a few examples of issues commonly misreported as system problems:
Any one of those could be critically important to the person reporting them, but even if that's true, they still aren't system problems and can't be addressed through the system problem report facility.
Keep in mind that our system does evaluate your past system problem reports when determining whether to allow you to report new system problems as well as what priority to give them. For this reason, we strongly encourage you to investigate the situation to the best of your ability before reporting a system problem. There are "boy who cried wolf" consequences for people who consistently misuse the feature.
In all cases, we recommend following our troubleshooting tips before opening a system problem report, and writing a system problem report that shows you did so. The best system problem reports do these two things:
Making sure you cover both of those will help to ensure you get the quickest, most accurate, and most helpful resolution of your system problem report.
No.
We assess support point charges in conjunction with secure issues to reflect the fact that the time of one or more professionals is being spent exclusively and privately on your issue. The majority of questions we receive via the secure issue system could just as easily be asked in our Member Forums.
We'll answer the same question for free in the forums that we would charge to answer in a secure issue, and usually in the same timeframe, because when we answer a question in the forums, everyone can see and benefit from the answer, not just the asker.
So, in most cases, if you're paying for the answer to a simple question via our secure issue system, you're not paying to have the question answered, you're paying to have it answered privately.
Naturally there are exceptions, particularly if you need us to do something, rather than answer something. Once you get outside the realm of answering a question into an area where we're expending professional time investigating or explaining something on your behalf, the secure issue system and the accompanying support point charges are the most appropriate way for us to recover the associated costs.
As long as you don't have any open issues that need points, just open a secure issue and request to have them credited back to your account. You won't be charged points for that.
If you have more than one account, make sure you indicate which one you want them credited to.
Support points are also automatically sold back when a membership is closed.
We provide a number of support options designed to meet various needs.
Self-Help Options
Self-help options are always free.
Special-Purpose Professional Support
Like self-help options, our special-purpose support options are free. Unlike self-help, the scope of the special-purpose professional options is very limited.
General-Purpose Professional Support
If you would like to ask questions or get personal support from our staff in private, you may purchase support points and then open a secure issue. We'll do our best to help out, with support point costs being assessed based on the time we spend. Keep in mind that this feature is used to request information from us; there's a limit to how involved we can get in actually doing stuff. "Can you help me figure out why my site is slow?" is something we may be able to help with. "Please fix my site's code so it isn't slow" is not.
Our paid general-purpose support is also "best effort." We'll do the best we can to help out, but we're not omniscient, and we can't guarantee any particular outcome. That means support point charges associated with an issue are based on the amount of time we spend on them, not on whether a specific result is obtained.
If you open a secure issue to ask a question answered by our FAQ, there is a flat one-point charge to send you a link to the relevant FAQ entry to cover our time to search the FAQ for you. Certain other actions, like changing your member login name or adjusting your site's PHP memory limit, are also covered by flat support-point charges.
The link to Purchase Support Points is found in the Action Box in the upper right corner of the Support tab.
If you've reviewed our member support options and you're not sure which one is right for your situation, we recommend posting the general, public-safe details of your situation in our Member Forums and asking for guidance. Someone will be glad to help you figure out what's the best way to go.
MySQL processes are created in our member interface. Please click here to visit the appropriate panel. See this page for a description of our MySQL pricing.
Within a MySQL process, you will have full administrative control and you may create as many databases as you wish. One process is more than adequate for most uses, including supporting web sites, each with multiple unrelated applications, such as forum software and blogging tools, but you may add more if you wish.
We do reserve the right to limit excessive MySQL usage that disrupts other members. MySQL is very efficient, so this is rarely an issue, although it can come up if a process is using large tables that are not properly indexed.
(For information about the difference between a MySQL process and MySQL database, please see this related FAQ entry.)
The DSN, or hostname, for connecting to MySQL is the name you gave when you created it, followed by the extension .db. The full connection information can be found in the email sent to you when you created your database. Never use localhost as part of your database connection information.
If you need to find your DSN and no longer have this email, visit the MySQL Servers Panel. The DSN for your database appears in the first column. Clicking on the DSN name will take you to a page that also lists your default admin username.
DSN stands for Database Server Name and is sometimes also referred to as hostname or MySQL Server Name or even just server name. This is different from Database Name, which is something you choose separately for each program that uses your database (and usually create in phpMyAdmin).
Sometimes if you are using a pre-built application, it will create its own database, but in general you will have to do this yourself.
Remember that MySQL databases and MySQL processes are not the same thing. When you first create your MySQL process, there won't be any databases in it.
There are two easy ways to create a database inside your MySQL process. For either method, you will need the database administrator username and password. The username is the same as your member login name, and the default password is the same as your login password at the time you created the database.
The fastest way to create a database in your MySQL process is to click the "Create a Database" action on the MySQL information page for your MySQL process under the MySQL tab, and just follow the steps.
However, the phpMyAdmin tool that we provide can also be used. This tool is available by clicking the "Open phpMyAdmin" action, also on the MySQL information page for your MySQL process. Select it, then log in to your MySQL process. Next, look for the text box under Create new database in the middle of the page. Pick a name for your database and enter it in that box. Then click the Create button. That's all there is to it!
You can use this ability to set up a whole bunch of applications to use different databases in the same MySQL process, even if the applications are running on completely different sites and don't share any information.
Example: Suppose you have two sites, and you wish to run the phpBB forum software on both of them without having them smack into each other. You could create two databases, one called sitea and one called siteb, in your single MySQL process, then set the $dbname value in each site's phpBB config.php file to sitea or siteb.
(You can also use phpBB's $table_prefix feature for this purpose, but three out of four nerds agree that the two-database way is "better.")
A MySQL process or MySQL server (or even MySQL server process) refers to the actual running MySQL software.
A MySQL database, on the other hand, is a collection of related tables within a MySQL process that share a common purpose, like running a forum or blog application.
A MySQL process may contain more than one MySQL database. (If it doesn't have at least one, it isn't very useful.)
MySQL processes are identified by their DSN or hostname, which is of the form example.db. You chose this when you created the MySQL process, and you can see it on your MySQL Process panel in the user interface.
MySQL databases are identified by their database name. You can create these from phpMyAdmin.
Sometimes the term MySQL database gets misused to mean the MySQL process. This usually happens when the process only has one database. We try to avoid that usage, because it is ambiguous and confusing, and we encourage you to do the same. But it happens, so if someone says "MySQL database" and you aren't 100% sure which one they mean, ask them. "Do you mean the MySQL process itself or the database within the process?" The confusion you avoid may be your own, because you have to know which name goes where when you configure your application.
Possibly. When we created your database, we assigned a password to the 'root' MySQL user, which can only be used from the physical machine running the database (which no users have access to). If you have not removed our access, then we can reset your database password for you with no problem. (In cases where this is all that is needed, the cost is two support points.)
If you have removed it, which you are welcome to do, then we will have to use a different approach that is very time consuming, will cause downtime for your database and any sites that depend on it, will incur a nominal fee for the time involved, and might cause you to lose some or all of your data.
We strongly recommend that you use your MySQL administrator username (which is the same as your member name) and password only for the purpose of creating other MySQL users from phpMyAdmin. It is much too powerful to be used directly from your web site or plugged into any web pages! To create a new user with only the necessary privileges, see: this entry.
Please keep careful track of your MySQL passwords.
The best guideline for whether what you are doing is allowed is whether you are doing it. In other words, no automated access is allowed; it must be you personally doing whatever you're doing.
Because of the large variety of ssh clients and ssh-protocol tunneling applications that exist, and the innate complexity of ssh tunneling, we cannot provide any technical support related to remote access to your MySQL database.
To use ssh port forwarding in conjunction with the industry-standard OpenSSH client, one would use a command similar to the following on one's local system (not our ssh server):
YourPrompt> ssh -N -L 3306:your.db:3306 user_site@ssh.xxx.nearlyfreespeech.net
Please note that the command above needs significant specialization for use in your specific circumstances. If you are uncomfortable making the needed changes, this is not a feature you should attempt to use.
No! This is a very common mistake. The "mysql" database contains vital information about the other databases, usernames and passwords in your MySQL server. If you delete it or overwrite it with anything else, the server won't notice until the next time it goes to restart (which could be months later). Restarting will fail, and your database will be useless.
If you do this, your database will most likely be ruined and will have to be removed. We may be able to recover your data, but if this is possible and you wish it done, a service fee will apply to cover MySQL administrator time.
If you catch this mistake before your database stops, you should still be able to connect to it and make a backup of your data.
If you have any question about whether something should be there or not, please ask before you delete it.
To connect successfully, use a command similar to the following:
YourPrompt> mysql --host=example.db --user=username -p Database
Where the "username" is the database username (usually the same as your NearlyFreeSpeech.NET login, unless you have created another) and "example.db" is the database DSN you chose when creating your database and "Database" is the name of a database in your MySQL process that you have created. Using the above command line, you will be prompted for your MySQL password. Like your login, this will be the same as your member password at the time you created your database unless you change it.
To create a database in your MySQL process from the command line, use a command similar to the following:
YourPrompt> mysqladmin --host=example.db --user=username -p create Database
Using the same values as the first example, this will prompt you for your MySQL password and then create a database called Database in your MySQL process. (We'll leave the task of coming up with a database name more creative than "Database" as an exercise for the reader.)
If you need to redirect input (for example to load a MySQL dump file), you will additionally have to specify the MySQL password on the command line, like so:
YourPrompt> mysql --host=example.db --user=username --password=password Database <database.sql
When you created the MySQL process, you selected a DSN (also called its hostname), which is the name you must use to access your process. This name is of the form something.db and is also identified in your MySQL setup email and on your MySQL Process panel.
Most software packages that use MySQL offer a configuration variable of some kind to specify the DSN. You must enter the something.db name for this purpose. You cannot use localhost or leave it blank, or your program will not work, and you'll get this error message.
Because we still have to retain the associated MySQL data and reserve enough resources for you to start it at any time.
To avoid being charged for having a MySQL process you are not using, you can remove it by visiting the "mysql" page, selecting the name of the process you want to delete, and then selecting "Permanently Remove Process" from the "Actions" box.
The official documentation is here:
MySQL 5: http://dev.mysql.com/doc/refman/5.0/en/user-account-management.html
MySQL 4: http://dev.mysql.com/doc/refman/4.1/en/user-account-management.html.
phpMyAdmin: http://wiki.cihar.com/pma/user_management.
On our system, whatever method you choose needs to boil down to two SQL commands:
Do not specify a hostname when creating users; since we use a clustered hosting network, you cannot predict from what host a connection will originate. Also, attempts to "GRANT ALL ON *.*" will typically fail due to the lack of the FILE permission by default on admin users, and it is bad practice to grant administrative privileges to a website user. Finally, try to avoid granting ALL if you can; security is always enhanced by minimizing the privileges of website users.
After a MySQL upgrade, when using phpMyAdmin or attempting create or modify MySQL users with CREATE USER, GRANT, or REVOKE, you may see messages like this:
This is a result of upgrading the version of MySQL you use without upgrading its internal data (something only you can do). You have three options for how to handle it:
If you are running MySQL 5, follow the suggestion and run mysql_fix_privilege_tables from the ssh command line. It uses the same basic parameters as the MySQL command line client:
YourPrompt> mysql_fix_privilege_tables --user=username --password=password --host=yourdatabase.db
To remove your MySQL process, visit the "mysql" page, click on the name of the relevant MySQL process, and select the "Permanently Remove Process" action from the processes' MySQL Information panel.
Aside from not correctly entering a valid username/password combination, this can also occur if your member login, which is also your default MySQL username, is too long for MySQL. Our system truncates it automatically, and lists the correct default MySQL username on the information page for each MySQL process you have.
You can find this information by visiting the "mysql" tab and clicking on the name of the process (ending in ".db"), which is listed under the "DSN" column. Your MySQL default username is listed under "How to Access MySQL."
This often happens when you log in to phpMyAdmin with your administrator username and change the password for that username while you're logged in. The best thing to do in this case is to sign completely out of our member interface and log in again from scratch.
If this happens for some other reason, try accessing your database from the command line or web site. If that works, try closing your browser, or, as a last resort, deleting any browser cookies you have from members.nearlyfreespeech.net.
If you are not able to access the process at all, treat it as a lost MySQL password.
The MySQL "user" table that controls who can access your MySQL process contains a "Host" field that controls what hosts can connect as that user. No matter how you create MySQL users, when using our service, you should always use make sure the "Host" field winds up containing only the % character.
Since we use a clustered network with specialized nodes for hosting and specialized nodes for MySQL, you will never connect to your MySQL process from the server it's actually running on. Since things move around, you won't even know in advance which server will originate the connection. Using the % character allows connections from any of the servers on our network, which is the only way you will be able to connect. Using "localhost" or any other value will lead to connection problems.
We have to enable or disable InnoDB for you manually, as it requires filesystem changes and a synchronized restart. Please submit a secure support request.
Since enabling InnoDB costs an additional $0.01/day per MySQL process, please indicate your acceptance of this charge in your secure support request.
When setting up your site's MySQL connection information, it's tempting to skip the step of creating an additional user and just use the "admin" username and password. Never do that!
The first and most important reason not to do this is security. If your MySQL admin username's password is the same as your member password, you are storing your member password in plain text as part of your publicly-accessible web site. The slightest vulnerability in your application, the web server software, or the operating system could result in a compromise of your entire membership. Since that's a compromise of our system, we take a dim view of this and to protect ourselves, we tend to suspend sites if we discover the member password being stored in plaintext.
Even if you change your MySQL admin password, it's still not safe to use from your site. Your web site doesn't need administrator privileges against your database. It needs some subset of that, and creating a dedicated MySQL user for your site with only the necessary privileges is a good way to limit exposure to SQL injection attacks and other security issues.
Second, your admin username has the SUPER privilege. MySQL only allows a certain number of connections at a time. If it runs out, either due to a problem with your application or a glitch in the MySQL process itself, your site will start getting "too many connections" errors. However, in order to make sure you can get in and fix it, MySQL always holds a single connection aside for a user with the SUPER privilege. If your site is using your admin username, you'll be unable to resolve the issue yourself because that "rescue" connection will already have been wasted by the site. If you find yourself in that situation, you'll have to open a support issue and ask us to manually restart the process.
Note: If we have to log in and manually restart your process, that's something we have to charge support points for; the protective measures described above are designed to ensure that it is never necessary. If you bypass all the protections, you'll have to bear the consequences.
So remember, using your MySQL admin username from your site is a terrible idea. It seems easy and harmless up front, but sooner or later you will wind up regretting it.
We're doing the best job we can to ensure that there is no catch. But of course, there's always fine print. In order to convey your deposits into your personal bandwidth account, we have to charge you a small deposit fee. This is a substitute for the huge "setup fees" charged by some other providers.
Our deposit fee is presently $1.00 plus 3% of the amount of your deposit that is over $20. That means, if you make any deposit up to $20, you'll be charged $1.00 to cover our actual costs of handling the deposit and managing your account. If you deposit $50, you'll be charged $1.00 plus 3% of $30. If you deposit $100, you'll be charged $1.00 plus 3% of $80. This same fee is applied no matter how you make your deposit, including checks, credit cards, and PayPal.
However we don't want this fee to discourage people hosting small sites. Consequently, we also apply an instant rebate when you make a deposit of less than $20.00. Because the deposit fee is particularly onerous on the smallest deposits, rebates are generally largest for deposits of $5.00 and under.
For example, if you make a PayPal Microdeposit of $0.25, the deposit fee would ordinarily be $1.00, not a very good deal! However, at the time of this writing, the rebate for this transaction would be $0.94, leading to a net deposit of $0.19, the smallest deposit it is presently possible to make to establish service with us.
We do not profit from deposit fees.
We apologize for the need to make this so complicated. It is unfortunately necessary in order to provide you with the best possible pricing without running afoul of the conditions imposed upon us by our payment processors. We're constantly on the lookout for ways to reduce (or simplify!) these administrative costs, because they don't help us and they don't help you.
Beware of plans that promise a certain (large) amount of data transfer for a certain fixed monthly price. Often, such plans include huge amounts of disk space as well. But you pay that price regardless of what you actually use.
If your hosting plan offers 10,000GB for $10/mo, that sounds like $0.001/GB. We must be crazy; our prices aren't anywhere close to that! But what if your site only transfers 8GB one month? ($1.25/GB.) Or 5GB? ($2.00/GB.) Or 1GB? ($10.00/GB.) Suddenly our prices seem like the good kind of crazy! Big bundle hosts make big money off of people who are paying for a lot of capacity that they didn't really use.
When you use one of these services, if you use too little, you wind up paying a lot for it. It's true, if you use too much you might get away with it. But you might get hit with overage charges, or you might find yourself terminated for violating some obscure resource limit well before you use up the bandwidth or disk space they promised you.
Big bundles represent a bet: you're betting you'll use a lot of service, the hosting company is betting you won't. As with casinos, the bundles are packaged to look as favorable and attractive as possible, so it seems like a sure thing.
First off, ask yourself if you want a hosting company that is betting against the success of your site. Isn't that fundamentally wrong?
Second, when you take that bet, you're doing it based on a few hours of one-time research. The hosting companies you're betting against take those bets for a living, all day every day. They have all the info, they hold all the cards, and they make a lot of money.
It is possible to beat the odds and get a great deal. Like a casino, they can afford to let a few people "win" because so many people only think they do. But it's a lot of work to beat the system, and it's a new game every month.
We encourage you to think about the price you want to pay in terms of what you really use, not in terms of what you might have used, but didn't, or what you may use someday. If you're in the category where you're paying a lot for stuff you aren't using, give our service a try. If you're in the category where you're costing your host a lot more money than you pay, then our service might not be the one for you. :-)
Our service is pretty barebones, and it is priced accordingly. Whether your site is big or small, our usage-based pricing ensures that you pay a price that's fair to you and fair to us; not one penny more, not one penny less. If your site becomes successful and uses more resources, we'll make more money. That gives us a vested interest in ensuring that your site runs as well as possible, all the time.
So... if you think someone else is offering you a better deal, remember to ask yourself... wanna bet?
We have recently changed our pricing, and so we cannot currently offer good statistics for this. They will return in a few months. Until then, we recommend using our Pricing Estimator tool to get an idea of what your hosting costs might be.
We currently accept:
Online credit card and PayPal payments are processed immediately. Mail-in deposits take longer.
For our International members, we also support manual payments made through moneybookers.com. If you would like information about this option, please contact us.
We do not accept cash payments for the simple reason that cash sent through the mail all-too-frequently does not reach its destination. Even the US Postal Service acknowledges this and officially discourages the practice. You may use cash to obtain money orders from the United States Postal Service, Western Union, and many other vendors in the United States. Internationally, we recommend the use of American Express worldwide money orders denominated in US Dollars.
If you wish to pay us anonymously, contact us in advance to request special arrangements. As we have a very protective privacy policy, such requests will be granted only if there are extenuating circumstances.
Yes, absolutely! You can run CGI lisp, perl, python, ruby, and tcl scripts by putting them in your web space and giving them a .cgi extension. Our secure shell environment provides the necessary resources to compile and link C & C++ applications for use with CGI, though technical support is not generally available for such activities.
You can get a live snapshot of our available CGI languages and their current versions on this example page. There is also information about available Perl modules available. If you need special Perl modules installed, just let us know the CPAN name of the module you need and we will add it for you if at all possible.
Our default configuration provides PHP 5 with many of the most popular extensions. This page has an example of our default PHP configuration and links to the alternatives. We can install PEAR modules upon request, but we generally require them to be marked "stable" before we will make them available on the system.
SSI (server-side includes) can be used by naming your files with a .shtml extension.
Full MySQL support is available. We give you your own private MySQL process and full administrator privileges; there's no need to worry about other users trampling on your databases or trying to shoehorn several applications into a single database.
To help you manage your process remotely without having to install and maintain extra software, we provide a private installation of phpMyAdmin that can be used to access hosted processes easily.
We also support a number of common database libraries in both PHP and CGI applications, including SQLite, db4 and gdbm.
We do not support or plan to support PostgreSQL at this time.
No we do not.
We do, however, provide email forwarding service. You can set up as many different addresses at your domain as you like, specifying where each one should be forwarded and/or use "catchall" forwarding to send everything to a single address.
The first choice, and often the best one, is to use the email account(s) provided by your ISP for this, but there are other options. Many of our members choose to use free email services like Google's Gmail, MSN Hotmail or Yahoo! Mail. Any of these will work with our email forwarding.
For more elaborate email hosting requirements, you may wish to investigate companies like HostMail or Everyone.net. These also work very well in conjunction with our service.
Yes, almost any directive that can be placed in an Apache .htaccess file will work on our system. The most significant ones that will not work are those that perform access control based on IP address; due to our network architecture, IP blocking is performed before requests reach .htaccess and must be configured separately.
At this time, we provide only HTTP (web hosting) using our customized (Apache-based) server platform. This limits the applications we support to those that work through CGI or PHP. A partial list of servers that will not work with our system includes:
Lots! Here's a partial list of the ones most frequently asked about or used:
Yes! Our DNS service meets most simple DNS and email service requirements for the average website. NearlyFreeSpeech.NET DNS supports most common resource record types (A, AAAA, CNAME, MX, NS, SRV, TXT, and PTR).
No.
Compared to the endless parade of hosts that provide tons of "one-click installs," one-size-fits-all web site templates, unlimited toll-free telephone support, and cookie-cutter control panels, our service is arcane and complex. We consider this a positive.
Our service is designed for people who are comfortable with Unix-based web hosting, including manipulating MySQL and files using command line tools. To get good results for nontrivial sites, our members need to understand how Unix file permissions and ownership work, and how they apply in a secure web hosting environment.
We do provide extensive documentation, including a massive FAQ, that addresses a large number of the most common inquiries we receive. Because we employ neither "canned answers" to inquiries for support nor underpaid "tier 1" support personnel to give them, we do tend to refer people to the documentation when their questions have detailed and complete answers there.
But if our systems are working properly, we expect that most of our members should never need to contact support. By extension, they should not have to pay extra to maintain a staff of people they never use. Consequently, our free technical support is extremely limited; our primary individual support option costs extra, and even that has fairly strict limits as far as how much help we can provide.
We have found that most of our successful members are those who have previous experience with web hosting. This is, however, a gross generalization. We have plenty of members who have made amazing sites starting from ground zero because they are strongly self-motivated and learn well independently. It's cool for us to watch them learn, too.
If you are not comfortable that you already have the knowledge and experience outlined here, and you do not particularly want to acquire it, that's a perfectly valid position, but it means that using our service may be an exercise in frustration for you that is best avoided.
We have our own custom control panel that is as unique as the rest of our service. While it is in no danger of winning any awards for its great beauty, it does allow you to control most aspects of our service without resorting to complicated configuration files. The major benefits of this custom environment are:
There's no "demo" of our control panel, but you can create a membership and kick the real thing around for yourself. Naturally, doing so is completely free. To get a basic idea, all you need to provide is a login name, the name you want us to call you, and a working email address.
To get a better idea, we recommend that you create a personal bandwidth account, which will require your basic information (real name, address, etc.), but don't worry, our privacy policy has your back. No payment information is needed to check out the control panel. So please try creating an account; you might be surprised by what happens next!
Any program that can upload to our system using the FTP Internet protocol should work. Our members have successfully used Microsoft Front Page, Adobe GoLive, Adobe PageMill, Macromedia Dreamweaver, and other programs to create web pages and upload them to our system. Some people have used Microsoft Publisher successfully, but it seems to do something that makes web pages far larger than the same pages created in other programs. This makes them take up extra space and take longer to download, with no visible benefit, so we do not recommend it.
In addition to regular FTP, we also offer SFTP (Secure FTP) and scp support should you wish to upload your files under the aegis of strong encryption.
Of course, since we offer ssh-secured shell access, you are equally welcome to use vi as your HTML editing tool if you prefer. (Or emacs, pico, nano, and others.)
Our system is very flexible in this regard. Each membership can have one or more accounts. Each account can have one or more sites. Each site can have one or more domain names. For many people, this means one membership, one account, one site, and one domain name. For many others, it gives them the power to be as creative as they want, and to pursue several different goals.
Whether you spread your websites across multiple accounts or keep them all in one is completely up to you. Support for multiple accounts allows people who have sites for different reasons, such as business and personal, to keep the finances separate if they choose to do so.
Please see Abuse @ NearlyFreeSpeech.NET.
Please review our Terms and Conditions of Service.
Our primary requirements in this area are as follows:
If you have questions about whether your proposed site is legal, you need to consult an attorney. Under no circumstances can we give a legal opinion or advice, nor can we make binding statements about hypothetical sites and circumstances.
*You must obey all applicable local laws unless you get our prior express consent in writing. We do provide anonymous hosting of content that violates local government censorship laws at our sole discretion in cases outside the United States where we feel government censorship is contrary to the cause of freedom.
If you have questions about our willingness to put up with controversial or unpopular sites that are nonetheless legal, we invite you to review our Abuse @ NearlyFreeSpeech.NET page.
Our member interface includes a feature called a "Secure Support Request" which you can use to submit requests for assistance, or if you need us to do something related to your service. We also accept support requests via email for general questions that do not require us to verify your identity or to do something that would affect your hosting. We do not offer telephone support.
We know what it's like to get miserably bad customer service, and we have set up our system based on those experiences. Here are a few examples.
We also maintain a detailed technical FAQ for our members as well as Member Forums populated by some very, very smart people.
For more information about the extent of the technical support we provide, please see this related FAQ entry.
The same thing that happens if your site uses less than $0.01 in a day, in a week, or in a year: it keeps going until it does.
We aren't really interested in months. The amount of bandwidth you use is carried over as long as it takes until you accumulate a penny's worth of usage (at least 10,737,418 bytes), even if that takes a month or more.
Yes, we are happy to host sites like this.
Yes.
We have a corporate policy that we do not offer services that consume IP address space on a per-site or per-user basis. The most common example of this is when a web site is assigned one (or more) static IP addresses, but it also applies to SSL (https) sites and anonymous FTP sites.
Assigning static IP addresses on a per-site basis is a practice that has devastated the Internet address space, so we don't participate in it. Tens of thousands of IP addresses can be assigned to a single rack of equipment in a datacenter somewhere, but there is a shortage of IP address space. That's not the right way to do things.
We regard this as an "Internet environmental" issue, and it's one about which we're prepared to be a little extremist. Basically, we believe that it's wrong for us to do it, so we don't do it. Not everyone agrees with us, and we definitely do lose business because of this position.
For standards-compliant web hosting (HTTP/1.1), there is no need to assign a static IP address, and no supported browser remains available that requires this. Static IP addresses also severely limit our ability to reroute around equipment that has problems or is being maintained, and even makes it tougher for you to benefit from our load balancing technology.
The most common reason people request a static IP address is to point external DNS at a site hosted with us. As part of our hosting service, we provide our own special DNS records for each site that you can link to external DNS using the CNAME capability that work even better than static IPs. These records preserve full fault tolerance and load balancing.
Not at this time.
The "HTTPS" standard for SSL-secured web sites has a fundamental design problem that causes it to require one IP address per site to work properly. See this related question for information about why we will not assign IP addresses on a per-site basis.
We will continue to evaluate proposed changes to the https and SSL/TLS standards that might enable us to offer this service in the future, because for some, free speech also means being able to access information without being monitored or fearing reprisal.
We are also conducting independent research in this area which may lead to a compromise solution.
Yes we do.
See this page for full information about our integrated domain name registration services.
Here are the things we are most often asked about that do not work with our service:
It's been suggested that publicly posting information about our technical limitations isn't savvy marketing, but if our service isn't going to work for you, we want you to know that before you sign up if at all possible.
You may contact us at any time to close your membership and cancel your service. When you do, we will return the money remaining in your personal bandwidth account. All of it.* You're only responsible for the cost of services that you actually use.
If you try out our service and figure out the same day (by early evening) that it is not right for you, let us know right away. Sometimes, but not always, we can void your transaction so that you will not only get a refund, but it will be as if you were never even charged. We can't promise that, but if you let us know fast enough, we will do our best for you.
Please note that we cannot issue a partial refund of your balance; we can only issue a full refund, and only in conjunction with the close of your membership. Also, if you have any domains registered through us, you will obviously need to transfer them to another registrar or authorize us to delete them (without a refund) before requesting cancellation.
*If we have to mail you a check, there will be a small charge, and we won't issue a refund for a balance less than the charge. See our Terms and Conditions of Service for complete details.
Our hosting platform uses a network of distributed, fault-tolerant, load-balancing shared servers. Sites are automatically distributed across the servers to make the best use of resources based on the popularity of the site and the capacity of the server. As a result, there is no need to fear having busy or CPU intensive sites on the same server slow you down; our system will re-balance them automatically.
Our system will send you email reminders when your account is running low on funds (and of course it will let you know if you run completely out). The reminder levels come pre-configured at $5.00 and $1.00, but you can add, change, or remove them at will.
No.
Our pricing plan is designed to be fair to you and fair for us. It represents our actual cost to provide the service. In the case of storage, for instance, this is literally true: all revenue from storage charges is channeled directly into the purchase of additional hardware. And by "hardware" we don't mean a company Hummer.
Our pricing plan is simple and straightforward as well as very competitive. You pay for what you use, and you don't pay for what you don't use. That's all there is to it.
Prices that appear better than ours fall into to two categories: big bundles and temporary loss leaders. Our thoughts on big bundles are detailed elsewhere. As for loss leaders, as long as the hosting business exists, there will be somebody offering free or below-cost service because they think adding customers is more important than building a sustainable service. Competing on price with every free-today-gone-tomorrow hosting provider that comes along would simply guarantee that we'd lose what really makes our service the best deal: its simplicity, honesty, and sustainability.
It's not easy. For one thing, we keep overhead to a minimum. No fancy multi-acre Silicon Valley office palaces with slides and wandering masseurs here. No business development teams. No commission-driven sales force. Also, we use our buying power to force our providers to give us the same deal we give you: we pay only for what we use, which helps us stay profitable. Lastly, we try to avoid doing stupid things that make no sense just because we heard someone else made a lot of money that way. That really helps.
This is not a loss leader, a limited time offer, or restricted to only certain people. This is our business model, and it works.
Microsoft Front Page (the web page designing program) works just fine with our system.
We're sorry, but our service does not support Microsoft FrontPage Extensions (almost the same name, completely different technology) or Microsoft Active Server Pages. There are presently no plans to add support for these technologies.
We do this for three good reasons:
We say: go visit SomebodyElse.com. Look for their affiliate program. Find out if your web designer is getting a kickback for referring you. Some providers pay 10% or more every month.
Affiliate programs make it difficult for a web designer to make objective recommendations about what's good for your business. So good web designers generally don't participate in affiliate programs, and you can rely on their advice. We don't have an affiliate program, so when someone recommends us, you can be comfortable that it's because they like us.
On the other hand, maybe your designer has had good luck with somebody else and knows that they provide the quality service you need at a competitive price. In a case like that, sometimes it's better to go that way. Few roads are better than the ones one knows best. We'll be here if you need us.
We do not offer dedicated hosting, because at our prices it would take centuries to recoup the cost of even the most barebones servers and we like to upgrade much more often than that.
However, some people have actually found that due to the specialized nature of the machines in our network and the fact that each one is devoted solely to its particular job, our service can actually exceed the performance of a dedicated server (particularly one with only a single desktop-grade hard drive) for some applications.
Our system will attempt to allow any reasonable deposit. Presently, PayPal micropayments can be made as small as $0.25.
There is no minimum balance needed to create a site, but your balance must be at least $0.01 if you want it to work. :-)
NearlyFreeSpeech.NET is not a public company, and we are not seeking private investments at this time. We are a real business, organically grown and designed to last, not a venture capital/IPO/bankruptcy Ponzi scheme.
No, we will not. Our design skills are horrifyingly bad anyway. We like to stick to what we're good at, which is hosting sites, not creating them. Our current public site reflects this.
Your website will be automatically disabled. As soon as you add more, it'll come back, but that can take 15-20 minutes and that often feels like the longest 15 minutes of your life, so we recommend using the account balance warning system to keep track of things before they go that far.
If you don't add more funds right away, your account will hang around for 30 days. You can add more funds at any point during that period and get it all back. After that, your account and sites will be permanently removed in accordance with our Privacy Policy.
Please see Abuse @ NearlyFreeSpeech.NET.
On our system, a gigabyte is 1,073,741,824 bytes. Hard drive manufacturers would have you believe that it's 1,000,000,000 bytes, but we don't sell hard drives.
(Technically 1,073,741,824 bytes is a gibibyte, but we have a hard time calling it that without a childish urge to snicker, and nobody likes a snickerer. If you want to be strictly accurate, the hard drive manufacturers are right, and we bill storage and bandwidth based on gibibytes* and mebibytes* (1,048,576 bytes), not gigabytes and megabytes. Someday we'll grow up about this, but that day has not yet arrived.)
*Must... keep from... snickering.
No. The costs of such a program would be more than the actual interest produced. We periodically reevaluate this situation, because we think a web account that runs forever purely off of its own interest is a pretty cool idea.
Of course! This is a great way to give our service a test run and slash your costs at the same time. Images, video files, and all types of downloads are popular candidates for this type of arrangement.
Please see Abuse @ NearlyFreeSpeech.NET.
No we do not.
Nope. Aren't those annoying?
No, that would be silly. If our service goes down, you'll never be charged in the first place! We only charge you for the bandwidth you actually use. If the service is down... well, you aren't using any bandwidth!
This business model has another profound consequence. In the event of a service failure, our revenue craters on the spot until it is fixed. The technical term for that is "motivation." For this reason, we do not offer any service level agreements or uptime guarantees other than "you will get the very best we have to offer."
By way of disclaimer, the above applies only to bandwidth charges. Storage and other charges have always continued to apply during network outages. We don't know what we would do if we ever had a storage-but-not-bandwidth outage severe enough that it would round up to a penny, since it's never happened. If it ever does, we'll try to do the right thing.
Yes. Our NearlyFreeSpeech.NET DNS service allows unlimited subdomains under a single domain name at no additional charge.
Please be aware, however, that we do not use the subdomain-is-subdirectory hack (unfortunately) made popular by a certain brand of web hosting control panel software. You can use our service to create multiple independent sites and then assign or remove names from one or more NearlyFreeSpeech.NET DNS domains at your discretion. There is no connection between a site and a domain name or subdomain other than what you create, and there is no correlation at all between subdirectories of a site and subdomains of a domain.
Subdomains can be associated with sites we host by adding them as aliases. If you're a member, see this member FAQ entry for more information.
A "major slashdotting" of a site hosted on our service will cost you (on average) less than $10, one time. The best part about that is that as soon as it's over, your costs go back to normal, but you'll save any usage-based discount resulting from the traffic burst. There's no higher-tier pricing to get permanently pushed into, and we won't cancel you for having something to say that people actually want to hear.
This happens to one of our members about once a week, so you can bet we know how to handle it. Or rather, our systems do. Our load-adaptive clustering technology is at its best when handling demand surges, and our pricing is at its best when you'd prefer not to be billed based on a 1% event the other 99% of the time.
When you create your website on our service, you will be asked to give it a "short name," which is a brief one-word name for your site that must be unique across our entire service, and we give you a built-in hostname based on that.
For example, if you choose example as your site's short name, you will always be able to access it as http://example.nfshost.com/.
If you don't want DNS or a domain of your own, you're welcome to use this name for your site at no additional cost. If you do use a domain of your own, then having your site available under this alternate name may help you troubleshoot any problems during the setup process, as well as provide a backup if there is ever a problem with your domain.
A MySQL process can contain as many databases as you wish. You can also create multiple MySQL processes if you wish, but doing so will cost more than placing all your databases in a single process.
A "membership" represents you as a person. It's how you identify yourself to us, and how you use our services.
An "account" is how you pay for our services. It contains the funds that you use to purchase hosting. You might have multiple accounts, if you want, but you don't have to. Just as one membership can have several accounts, one account can fund several sites.
It's a little like a bank. You are one person, but you might have two savings accounts: one for college, and one for "rainy days." The bank (if they know you at all these days) knows that you are just one person.
What you cannot do is have two memberships. That would be like opening an account at your bank, then going out to your car, putting on a fake moustache, and going back in to open a second account.* You could, but why?
*At least, I assume it's like that, but I've never actually tried it. My bank has a pretty good sense of humor, but why push my luck?
Because the servers we buy and the bandwidth we obtain are very competitively priced, but they still do cost money, as do the people that run them.
We get this question from two different angles. First, there are always people who just want something for nothing. Unfortunately, we don't have much to offer those people.
The second angle comes from people who would like to see us offer some sort of ad-sponsored free service. There are two primary reasons we have not pursued that:
Of the two, storage is easier to understand. Just like you, we have hard drives (except larger and probably more expensive) and we store the files that make up your site on them. Storage refers to how much space those files take up. Storage billing is measured in units called megabyte-months, which refers to one megabyte stored on our system for one month.
Bandwidth, on the other hand, refers to the amount of data that is sent out when people visit your site. Bandwidth is measured in units of gigabytes. If your page (including any the graphics and such that go with it) takes up one megabyte of space, then about a thousand people (1024 actually) would have to download the whole thing to get to a gigabyte of bandwidth, and that's what you'd be billed for.
No, of course not. That wouldn't really be your site.
Your site will have on it exactly what you put there, and nothing else.
Naturally, if you want to put banners or ads on your site, you're welcome to do so, what with it being your site and all.
It's simple. We don't want to confuse people into thinking we're anything like other hosting providers. Our simple, text-based layout is designed to load fast, to be easy to use, and not to try to distract you from making an informed decision about us. As if that's not enough, we also think Jakob Nielsen is pretty cool.
So, sure, we could follow the crowd and get stock graphics of impressive racks of equipment and inspired-looking people staring blankly into space. We've even been told we can't possibly be taken seriously as a hosting company unless we have them. But we're not buying. Those other companies can keep the sort of people who make hosting decisions based on how cute the model on the home page is. Our members are way too smart for that, and that's just how we like it.
And psst, we'll let you in on a little secret. Not all of our servers are the same color. Scandalous, we know.
Please see this page for complete information.
No, our domain registrations services are provided on a cost-recovery basis as a service to our hosting members, and are not intended to be used as a standalone product. We are not, nor do we have any interest in being, a general-purpose domain registration provider.
Consequently, while we do not impose any restrictions on the use of our domain registration and RespectMyPrivacy.COM services, our system is specially designed to facilitate use of registered domains with our hosting services. If you wish to use these services for other purposes, you are welcome to do so, but it may require additional effort on your part to set up. We will also not be able to provide technical support for usage of domains in conjunction with third-party services.
Yes. CGI processes and individual ssh commands are limited to two to five minutes of CPU time, and PHP requests are limited to three minutes of wall-clock time.
These restrictions are designed to catch runaway processes, not to interfere with ordinary usage. "Stock" web applications, specifically including phpBB and WordPress, simply do not use enough resources to encounter these limits. Who would wait three minutes for a web page to load anyway?
Although we do not impose a overall specific per-site CPU limit, ours is a shared hosting service. Please do not sign up for our service expecting to use our hardware (either ssh or CGI/PHP) as if it were your own dedicated server, as this will not be allowed.
One important related restriction to be aware of is that we do not allow persistant processes of any sort.
Our service is designed for people who are largely self-sufficient. For that reason, we do not build into our basic fee structure any cost recovery for technical support and our support offerings are comparatively limited.
For information about our free and paid support options, please see our public site.
Yes, but. Because of the ever-present threat of spam, we monitor email usage very closely. Therefore, you should expect an amount of scrutiny directly proportional to the volume of email you send.
It is also very important to be aware of potential vulnerabilities introduced by email-enabled web pages. In particular, generic PHP "feedback" form scripts have proven to be very popular targets for spammers, who can find and exploit them automatically. You should be extremely cautious, and make sure that any email-enabled web sites you create are safe from exploit.
We will hold you responsible for email activity caused by your site, whether you intended to allow it or not. If a spammer exploits a script on your site to send spam, we will have to clean up the mess. At a minimum, that will probably entail temporarily disabling your site, and it may result in additional charges for you.
Please be aware that when we address questions of this nature, we cannot speak to hypothetical situations, nor can we guess what we would have done in a situation where we were not involved. Nor we can offer you legal advice.
In the United States, the Digital Millenium Copyright Act (DMCA) defines the process by which a copyright holder can request that material be removed. In such cases, a provider is legally obligated to remove the allegedly infringing material without judging the merits of the claim. It is essentially done on the copyright holder's sworn say-so.
However, the DMCA also governs the process for restoring material, and that process is similarly rubber-stamp on the part of the service provider. Once that's done, it becomes a matter for the courts, not the service provider.
In this regard, the DMCA is a good law for us and for you. (Although it can and does suck in many areas, this isn't one of them.) The DMCA is, in part, supposed to protect you from capricious decisions made by the service provider based on some subset of the facts. At no point does or should an Internet service provider investigate or make judgment calls about complex copyright law and questions of what might be infringing. (We specialize in server processes, not process servers.) The DMCA gives us (and you) a certain (non-perfect) confidence that the copyright owner's claim has at least some legitimacy, and provides decent protection (once you get over the initial take-down hurdle) against the use of false claims of copyright infringement to suppress legitimate content.
If you wish to host a controversial site in the US, it behooves you to know the law, particularly this one, and how to use it to your advantage in the event of a dispute. You should also be prepared for a downtime of some or all "allegedly infringing" material for a couple of weeks if the copyright owner wants to fight.
We adhere to the entire law very closely. We do not generally pull the plug on an entire site if, for example, someone claims that a single graphic is infringing. We do our best to remove only the content that the copyright owner specifically identifies as allegedly infringing. We allow and encourage the use of the "putback notification" process when material is incorrectly identified as infringing. But we do not automatically terminate a member's service merely for receiving a complaint alleging infringement. (However, actually infringing someone's copyright does violate our TACOS and will generally result in immediate termination.)
Keep in mind that while we aren't lawyers, neither are we idiots. We can tell the difference between people harassing our members via the DMCA and cases where our service is genuinely being misused, and we can adjust our attitude accordingly. Fortunately, both of these cases are very rare.
Please see this page for complete information on this message and how to eliminate it.
We are happy to receive reports about problems, no matter what the source. However, if you report a technical problem with someone else's services, you may get a frustrating response.
Our Privacy Policy doesn't allow us to discuss our members' services with other people without the affected member's consent. That includes problems and our efforts to fix them or alert the affected member. Therefore, we can respond to problem reports from the public only by acknowledging the problem so you know we received your report. Unless the problem is specific to you, we will not provide you with any additional information.
Sometimes, people interpret our inability to discuss the problem as blowing them off or that we're not going to do anything about it. This is not the case at all, it is merely an artifact of properly enforcing our Privacy Policy.
What does discussing problems have to do with our Privacy Policy? Although the simple answer is that our members' services are nobody's business but theirs until they tell us otherwise, the practical reason for this is a little more complicated.
Take a simple example: from time to time we get reports like, "I went to www.example.com and it was down! Fix it! You people suck! Your servers suck!" While we can generally say "Yes, the site is down," we do not go into why or when it might be back in response to such a report, which sometimes means the person goes away believing that not only do we suck, but we suck on purpose!
There are many reasons a web site might be offline. Maybe the person couldn't pay. If it was your site, would you want us discussing your billing status with anybody who asks? Probably not. But if we respond back to all "site down" complaints but only stonewall the ones where billing is involved, stonewalling just becomes a substitute for saying that it's a billing problem. So, to protect our members' privacy, we must treat everything as a private matter even if it makes us look like we're unwilling or unable to fix a problem.
(Those who are paying attention may have noticed the similarity to the old philosophical problem of encryption: if you only encrypt things when you have something to hide, using encryption is a clear sign that you have something to hide. For encryption to be maximally effective, you have to encrypt as much as you possibly can. Others may have had similar experiences trying to find out the condition of their hospitalized friend.)
So, if you are a member of the general public, please do not assume the worst of us because we won't discuss a problem you found. We ask that you remember that our Privacy Policy is a promise to protect our members all the time, not just when it's convenient for you or when it makes us look good. Your patience and understanding will be appreciated.
Of course this does not apply to our members and their own services. If you're having a problem with your NearlyFreeSpeech.NET services, you can always expect full disclosure regarding any issues and our full support in helping to resolve the problem.
Please feel free to report downed sites or other technical problems with NearlyFreeSpeech.NET services to support@NearlyFreeSpeech.NET even if you are not a NearlyFreeSpeech.NET member (or if you are, but not the owner of the services in question). We want to make sure our members' services stay working at all times, and we'll take any tip we can get when something might be amiss.
If you are a member and there's a problem with your services, make sure to use our Secure Support Request facility so we can get started right away and not have to goof around making sure it's you.
We do not provide spam protection per se. As a forwarding server if we discarded spam messages, any "false positives" that were incorrectly flagged as spam would be forever lost. That obviously won't work.
Complicating this, not all of our members are alike. They have a broad difference of opinion about what constitutes spam and/or undesirable messages. Some people provide tech support and need to be able to receive forwarded copies of spam and viruses that most of the rest of us would never want. One size does not fit all!
What we do instead is enforce strict restrictions on the email servers that attempt to send email through our forwarding systems. These restrictions are no problem for legitimate email servers (they should all be passed by default on a properly-configured system) but they represent a tough barrier for the sort of compromised, virus-infected servers that send most of the world's spam. This blocks most illegitimate messages based on delivery mechanisms, not the context of the message. If you want, you can read all about our Email Acceptance Policy.
Although a fair amount of spam slips through this net, it has been pre-screened in such a way that a client-side junk email filter, such as those offered by most email software, can rely on information about its delivery to be accurate and therefore do an excellent job of filtering the spam according to your specific personal criteria without becoming confused by all kinds of forgeries and maliciously-crafted messages.
Naturally, whatever email server ultimately handles the messages we forward for you may also impose content-based junk email filters.
The net result of this is a highly effective, layered defense that, through its dependence on client software under your control, best meets your specific needs.
In many cases, the site operator has contact information on the site itself. That obviously represents the best way to reach them. If such information is not available but the site has a registered domain (i.e. the site name does not end in "nfshost.com"), you may wish to consult the public whois information for the domain, which is generally required to include accurate contact information.
If the site operator chooses not to include contact information on the site and is not using a registered domain, you may safely conclude that they do not wish to be contacted.
Unfortunately our staff are not able to act as a go-between messaging service between site operators and people who wish to contact them; we simply do not have the resources. Please do not contact us directly with messages for site operators, as we will not be able to assist you.
It is our policy not to comment on member sites.
This is a tough question. We do host websites that get attacked by a wide variety of different methods. However, the variety is so wide that there is no "typical" attack scenario or "average" outcome that we can offer as an example.
At any given time, our network is typically experiencing between zero and three denial-of-service (DOS) or distributed-denial-of-service (DDOS) attacks. Most are short, lasting only a few minutes or hours, but the longest lasted for over a month. Most are not service-disrupting, but occasionally they can render a member site inaccessible, and rarely, if they are significant enough, large-scale DDOS attacks can sometimes briefly disrupt our entire service. (This is equally true of all web hosts.)
To help protect our members' sites, we employ a large number of passive network features like connection filtering and firewalls. These are generally very effective against the everyday attacks we most frequently experience. When attacks go beyond the simple, an active response by NearlyFreeSpeech.NET personnel is typically required. Our active response to attacks on member sites (or on our service itself) is roughly proportional to the square of the disruption caused; our response escalates very quickly as attacks become more severe. Thanks to our long experience in the area, we have a wide arsenal of tools that can be dynamically employed or tuned to help mitigate serious attacks. We take keeping our members' sites online very seriously!
Having your site attacked does sometimes consume resources, e.g. bandwidth, that we charge for. The cost of such an attack depends on the type, scale, and duration of the attack, as well as in large part on your actions before and during the attack. Since these factors are not under our control, vary widely, and cannot be accurately predicted, we will not under any circumstances attempt to estimate what the financial implications of a hypothetical attack might be. If you want such an estimate, simply figure out the bandwidth that would be used based on the size of your site and the anticipated volume of requests.
However, since our service is paid in advance, you always have complete control over your maximum financial liability simply by controlling the balance of your account. If you feel your site is attack-prone and you are primarily concerned about costs, we encourage you to maintain a low account balance to limit your exposure. Then, if a situation arises, you will be able to make an informed decision about your best course of action before incurring any significant expenses. If you feel your site is attack-prone and you are primarily concerned about availability, we suggest that you maintain a larger account balance and customize our account balance warning feature to notify you if your expenses spike in an abnormal way.
Our service is based on personal responsibility. Although our TACOS ensure that you have broad discretion in choosing what to say on your your site, if you choose to say something controversial then you must be prepared to be first in line to bear the consequences. We will not indemnify you or waive any costs you incur arising from an attack on a site you host; we are a hosting provider, not an insurance provider.
In all cases, if you are concerned about your site being attacked, you are your own first and best line of defense. You should design a site that is lightweight and fast-loading so that it remains available under heavy load and minimizes bandwidth cost.
If you run into a problem with someone attacking your site or trying to bleed your funds dry, please feel free to contact us. It is absolutely not our intention to sit back and laugh while someone drains your account, whether your site content provoked the attack or not. In some cases, we can block obvious troublemakers and certain types of attacks so they will not reach your site. But since you are the site operator, we will expect you to take all reasonable measures to protect yourself first. Example 1: If someone is posting rude comments on your forum site, you will need to use your forum's blocking features to handle it. Example 2: If someone writes a script to repeatedly download the largest static banner graphic on your site, we may be able to block their IP address for you.
With all that said, it's worth noting that most sites will never be attacked directly and have absolutely nothing to worry about in this area. Even given our libertarian TACOS, fewer than 0.1% of our hosted sites have ever been targeted by noteworthy attacks.
Not at all! It's true that our libertarian attitude toward personal responsibility attracts a handful of controversial websites, some of which make a person wonder, "Ok, sure, you can say that, but why?" However, the vast majority of sites we host (greater than 99.9%) are perfectly ordinary blogs, forums, wikis, and personal pages run by people just like you.
For the bulk of our member base, the "fringe" web sites we host frequently serve as the proverbial canary in the coal mine: they act as our global censorship early warning system. As long as the fringe sites can remain online, we can all be confident that the rest of us with more moderate views have real freedom to express ourselves. When people attack such sites or attempt to get them shut down, we learn more about what techniques (legal and technological) we need to use to keep your site protected.
NearlyFreeSpeech.NET isn't necessarily about saying something controversial. In a lot of cases, it's merely about knowing that if you need to someday, you won't find out that your freedom to do so atrophied away while you weren't looking.
The short answer is that fraudsters and thieves wrecked it for you.
While we support the notion of Tor on an ideological level, our real-world experience with Tor has consisted of extensive problems with Tor-sourced hacking attempts and an unsustainable level of Tor-sourced credit card fraud. We also encountered relentless exploitation by spammers and phishers using Tor to create throwaway accounts. (Sign up, create site, send spam, get caught, sign up, create site, send spam, get caught, sign up...)
For that reason, we do not allow you to access our secure members site via the Tor network unless you already have a membership and a funded personal bandwidth account and you explicitly request that it be allowed via our secure support request system. (All of which must be done without using the Tor network.) We choose not to allow it automatically so we can filter approvals based on the common sense of a real person, and to protect members who don't use Tor from Tor-based brute force attacks on their password.
We understand that it isn't the existence of the Tor network that makes these things possible, but it does make them easy, and when virtually all of the traffic from a certain source is malevolent, blocking that source can be the only option. Forcing people off of Tor at least long enough to confirm their membership and make an initial deposit may not be the ideal solution, but it's hard to argue with results.
If you know of a reliable way for us to distinguish a handful of good people amidst a throng of would-be criminals in an environment that's raison d'être is to make distinguishing people impossible, please let us know. So far, making sure we already have a relationship with the good people is the best we've come up with.
Completely separate from that, we also have concerns about reports of unscrupulous Tor exit node operators diverting SSL connections. We don't know if this is true, but I have personally experienced a case where using a particular exit node led to SSL certificate mismatches when accessing a site where I knew no such mismatch existed. You should think carefully about passing any secure information through the Tor network.
Our system used to block accesses from you if you were merely running a Tor transit node (aka a Tor relay), as opposed to using the Tor network to access us, or running a Tor exit node yourself. We believe we have adjusted our system such that merely running a Tor transit node will not cause you to be blocked. If you run a Tor transit node and you're blocked, please contact us.
If you are running a Tor exit node, you'll have to cut back to relay-only, and do so long enough for the change to be picked up, before you can sign up.
In most cases, we do not allow our members to remain anonymous.
In general, the concern is that information not be disclosed to third parties. Our industry-leading privacy policy reflects our commitment not to let that happen. Therefore, from our perspective, there are very few legitimate reasons why a member would need to conceal his or her identity from us. Most people who request anonymous hosting are attempting to perpetrate fraud (on us or on the public) or wish to escape accountability for their actions.
At NearlyFreeSpeech.NET, we believe that with great power comes great responsibility, so we take a dim view of such behavior. For that reason, our TACOS require our members to provide complete and correct contact information, and requests for anonymous hosting are typically denied.
However, we do make one important exception. If you live outside the United States and can demonstrate that the site you wish to host would put you at significant, legitimate risk of retaliation from a government with a documented track record of reprisal against people who speak out against it, we may be able to help. Anonymous hosting is serious business; it can be one component of a coordinated plan to protect you and your family from torture and murder. It's absolutely not an option you can use to dodge lawsuits or unpopularity arising from hosted material.
If you feel you need this level of protection, please contact us, taking appropriate privacy precautions with respect to your correspondence. Be sure to explain where you live, what you want to host, and while you feel hosting the material anonymously is the only way to guarantee your safety. Be very specific; you will need to explain your situation in enough detail so we can make an informed decision. We may, in our sole discretion, decide to waive the contact information requirement in exchange for periodic reviews of your site content by NearlyFreeSpeech.NET personnel to verify that your usage of the service is consistent with your claims. Please be aware that even if we approve your request, paying anonymously is extremely difficult.
We regret we are not able to provide anonymous hosting to residents of the United States under any circumstances.
Please don't attempt to circumvent our restrictions on anonymous hosting by using fake contact information. Sooner or later we'll figure it out and terminate your membership. And, since you gave us fake information, we won't even be able to give you a refund.
NearlyFreeSpeech.NET provides our members a very specific service: it is designed for people who want to tinker with their website at a very low level and squeeze every last drop out of it. We are in some respects similar to an auto parts store, rather than a mechanic. NearlyFreeSpeech.NET will sell you an alternator for your '72 Impala*, but both the responsibility to determine that the '72 Impala needs an alternator, and the job of installing it remain with the customer. All the knobs, tweaks, options, and flexibility we provide can become a real frustration for a person who just wants to be done already.
Furthermore, as a small business, we understand that one of the keys to success is for the principals to spend as much time as possible focusing on the high-skill areas and as little time as possible on "have to" stuff, including accounting, legal issues, and building web pages. Every minute that we spend on something that we're barely competent or outright bad at is a minute we're not spending leaving the competition in the dust. Thus, we try to outsource as many of those tasks as possible so we can focus on doing what we're actually good at.
For that reason, in general, we find it difficult to recommend our service to new and small businesses; it's often better to pay (a lot) more and get a turnkey solution. But there are two exceptions to this:
First, for a lot of businesses these days, the website is the business. If you're a high-tech person trying to build a small business around a dynamic web site and you need advanced control over the programming and site configuration, as well as excellent speed and scalability at minimal cost, NearlyFreeSpeech.NET may well be perfect for you.
Second, the economic realities of new businesses often dictate that the owners have to do some of the things that are outside of their core skills. If money is tighter than time and the alternative is not to have a site, the ability to create a site at NearlyFreeSpeech.NET for pennies may be priceless, even if it takes a little more work.**
*As long as your '72 Impala supports HTTP and is hosted on our service.
**But don't expect to see any "NearlyFreeSpeech.NET: It's better than nothing!" marketing campaigns.
To make sure you receive automated system emails from us (including signup confirmations, password resets, account balance warnings, domain renewal notices, and other automatic service-affecting messages), make sure you are allowing email from notify@NearlyFreeSpeech.NET.
To make sure you receive any handwritten emails from us, make sure you are allowing email from support@NearlyFreeSpeech.NET. Finally, each support ticket is assigned a unique email address @support.nearlyfreespeech.net (but we don't get too many reports of those being blocked).
We won't send you any spam or unnecessary messages from any of these addresses.
If you're not receiving email from us, the first thing to check is your junk mail folder. Since our system is highly automated, junk mail filters occasionally incorrectly flag the messages it sends as spam. If you don't find them there, check your junk mail settings. Some email providers make it very easy to block a sender and silently delete such messages, making it very hard for you to figure out later that the sender is blocked.
Hotmail is one such provider. To check your blocked senders list:
(If you have information about how to check this with other free email providers, please drop us a line. Yahoo! mail users, in particular, seem to have a rough time with selective delivery.)
If you're still unable to resolve a problem receiving email from us or our system, please feel free to contact us. Ironically, you'll probably have to do that by email, but if the problem is with receiving automatic messages, we'll have a real person write back. Write to us from the email address you're having trouble with, and we'll look up the fate of any messages we tried to send there. If there's a problem on our end, we'll fix it. If there's a problem on your end, we'll try to find a way to provide you with the relevant log entries so you can ask your email provider what the heck is going on.
Not directly. There are two primary problems with this.
First, we do not support SSL.
Second, we are a shared hosting provider. The credit card issuers impose security requirements on the acceptance of credit cards that prevent you from accepting or storing credit card information on any shared server. Even if we did support SSL, that still means us.
In order to accept credit cards and most other payments, you will need to use a third-party secure checkout service. Examples that are known to work include Authorize.Net Server Integration Method, PayPal Checkout, and Google Checkout.
By default, we do not allow public HTTP (web) or IRC proxies because such proxies will be abused by spammers within minutes of discovery. It just saves time to say "no" up front rather than wait and shut it down later after there's a problem.
If you need to set up a private web proxy for your personal use that is appropriately access-limited, that is typically no problem as long as your use of it is legitimate.
No. If you are concerned that you might encounter problems with the content you want to publish, we'd strongly advise that you consult an attorney familiar with such issues. We can't provide legal advice, and don't offer a service that is intended to (or by any stretch of the imagination, could) protect our members from everything they might bring upon themselves by what they choose to publish.
Free speech is a responsibility, and it is important that our members understand and are willing to accept the consequences of what they do, and do not expect us to do it for them.
For your reference, here are links to all the relevant fine print:
Most of our members are individuals, which makes it easy for them to figure out who they're signing up as. However, if you're signing up for any kind of organization in which you're not the sole participant, it pays to plan ahead. In these cases, we allow what's called a "role membership."
The primary difference between a personal membership and a role membership is that the former refers to a person, and the latter refers to a job. This difference is made manifest through the membership's contact email address. For example, a personal membership might be "John Smith
In either case, we require that things still come down to one single person at any given time who has final authority over the membership, and who exercises that authority by controlling the role email address. (Reminder: email is trivially forged, so we assign responsibility based on who can receive email at a given address, not who can send email purporting to be from that address.)
We recommend that role membership email contact addresses be managed using forwarding. In the example above, you might configure webmaster@example.com to forward to john.smith@example.com. Then, if John Smith hands the responsibility over to Bill Jones, just change webmaster@example.com to forward to bill.jones@example.com instead. For archival/recovery purposes, it's often best if the forwarded messages are copied to the original address, so that Bill can go into the webmaster mailbox if need be and see what John did in the past.
These guidelines will help you create a sustainable membership for an organization that can cleanly transition from one webmaster to another. If you don't follow them and you get into trouble, we either won't be able to help you, or we'll have to charge for the time we have to spend investigating and unraveling the problem, and you'll likely have to provide extensive documentation justifying your access to the account. Neither option is appealing to anyone.
Please also keep in mind that you must be an authorized representative of an organization in order to create its role membership. Specifically, you cannot do this to create memberships for others or to bypass our requirement that memberships are non-transferable. In the case of a role membership transition, only the point of contact is changed, the membership itself remains held by the organization.
This is a question only you can answer. Sites are billed based on the resources they consume (currently, bandwidth and storage). The cost is therefore based on the size and popularity of your site, as well as any optional features of our service that it uses (like domain registration or MySQL).
We don't know either of those things about your site, and we are not able to estimate things about your site that you don't know yourself. If you have your own estimates or past records about your site's size and popularity, you can use those, plus the pricing information available on our site, to estimate the approximate cost.
We do provide a Pricing Estimator you can use to try to get an idea of how much your hosting may cost.
Our latest cluster nodes are commodity 8-core Xeon servers with 32gb of RAM, but keep in mind that we offer shared hosting and we allocate sites to servers based on resources used, not N sites per machine. We use a variety of advanced techniques to ensure that each site gets pretty much the same baseline and enough headroom to burst without affecting others, regardless of the specific hardware type, so running on a certain machine type also doesn't imply that the entire resources of that machine will be available to a single site.
It depends. (Of course.) The short answer is: Not only don't we know, we can't know. The long answer uses the word "however" a lot.
Shared hosting has a well-earned reputation for volatility, due to the fact that you are sharing resources with other people and neither you nor we know from moment to moment what they or the visitors to their site are going to do. However, the most common causes of downtime for member sites are specific to the particular site affected (misconfigured DNS, an expired domain, runaway scripts, letting your prepaid account run out of funds, etc).
We find that when people ask us about uptime, they are expecting us to give them a magic number with a certain quantity of nines in it that represents what fraction of the time our service is available. However, our service is sufficiently varied and complex that offering such a number would be disingenuous, especially since we host a large number of sites and they don't all move in lock-step; one person's downtime might not affect someone else.
It would be very easy (and blatantly dishonest) for us to pick a an arbitrary metric that would allow us to claim 100% uptime, or any number of nines we want. But, likewise, for any sufficiently large cluster of computers, something somewhere is always offline for maintenance, so we could probably make an argument for 0% uptime. (Though we won't.) Sites move back and forth, servers go up and down, and most of it happens without any visible effect. Even when a production server crashes (which does happen from time to time) it typically affects only a relatively small percentage over our members' sites, and usually only for a few minutes.
Our clustered approach does provide resiliency against many (but not all) types of hardware and load problems that cause downtimes at providers where your site is 100% dependent on the availability of a specific server. However, we do develop and maintain our own clustering software, so occasionally something incredibly weird may happen here that never would have or could have happened anywhere else. Such events are rare, but not without precedent.
Sites hosted at NearlyFreeSpeech.NET are probably slightly more likely to be "collateral damage" of a denial-of-service attack targeting some other controversial site hosted here than at other hosting companies that are less flexible in terms of hosted content. However, the flip side is that you are probably better protected against most such attacks due to our extensive experience with them, leading to (most likely) a very small net difference in the chance of being affected by that type of downtime.
All in all, our overall service availability is probably above average to very good when compared to other shared hosting providers. However, "overall availability" is meaningless to someone who's affected by something that doesn't affect everyone. Each person's view of our service availability can and will vary widely based on their personal experience as well as their personal criteria for what constitutes "availability."
We do monitor all of our systems and services continuously from multiple offsite locations and respond to problems detected as quickly as possible, 24x365.
We provide a web form that can help you recover your login and password, provided your member contact email address works and you know what it is. This form, is, however, time sensitive. It can only be used once per week in order to prevent attempts to "grief" members by constantly resetting their information. If you need a password reset and it's been less than one week since you created your membership or previously used the reset facility, please send email to support@nearlyfreespeech.net from your member contact email address and we'll be happy to check things out and reset your password.
If you lose your login, member password, and access to your email address all at the same time, you're in a bad place. Obviously you should never let that happen. However, we recognize that, for various reasons, it sometimes does, and we have established standard practices for recovering access to a membership when it does.
Unfortunately, the vast majority of "I lost all my information, please make an exception to your security practices and let me in" requests we receive come from people trying to gain illicit access to someone else's membership, and because NearlyFreeSpeech.NET takes the security and privacy of our members' services very seriously, the burden of proof that legitimate membership holders who have lost their information will have to meet to differentiate themselves from these would-be scammers is be extremely high.
Our standard practices for membership recovery verification vary somewhat depending on the circumstances, but typically involve three parts: a best-effort attempt to verify the identity of the requester using standard identity documents, an attempt to verify the request using the contact information we already have, and supplemental questions about the membership requiring information that only the member should have. The process will be time-consuming and slow; it can frequently take a week or more. To initiate it, contact us by email.
We believe all of our members know that we are serious about protecting their privacy and security; we believe that's at least part of the reason a lot of them pick us. We believe that they expect us to live up to that in situations such as these so that when they emerge from it, they can be supremely confident that their membership can't be hijacked by the first person who comes along with a good story. Consequently, we automatically construe any attempt to convince us to make an exception to our standard practices as an attempt by an unauthorized party to social engineer illicit access. This includes threats, sob stories, and everything in between.
No.
We encounter a variety of situations where people contact us claiming to be the rightful owner of a web site or domain managed through our service. Such claims are typically accompanied by demands to allow the person to take over, transfer services, or take something down.
Our policies are extremely strict and are designed to provide maximum security to our members. At NearlyFreeSpeech.NET, the person or entity we have on record as the holder of a membership is the only person authorized to direct us to take any action related to services we provide under that membership.
This puts people wanting access to a membership into two categories:
First, our members. Occasionally, a member will mislay their login credentials and be unable to access the system. We are able and happy to assist with a variety of such matters; they have their own FAQ entry with the specifics.
Second, everyone else. This includes customers, vendors, employees, employers, contractors, co-workers, relatives, and friends of members, not just the general public. We apologize, but we are not able to assist you under any circumstances, unless expressly authorized to do so in advance by the relevant member, and even then only under a very limited set of circumstances (such as allowing a predesignated party to make deposits or renew domains in case of emergency). Any concern or conflict you have with the member hosting the services with us, including problems contacting them, must be resolved directly with that member or via channels other than us. There are absolutely no exceptions.
We apologize to anyone negatively affected by our hardline stance on protecting the privacy and security of our members. While this often seems harsh to people already having some other major problem not caused by this policy, we ask them to please keep in mind the absolute chaos that would result if we handed over web sites and domains to anyone who asked for them via email based on their say-so. Thank you for your understanding.
Access to your site can be shared with other NearlyFreeSpeech.NET members. You (the owner of the site) can add other members by doing the following:
Any members added will be able to use FTP and SSH to access the site just as you can.
When the other member does not have a funded account, adding the member to your site confers "Adjunct" status on that member. The member you add must already exist with a confirmed membership.
If you have more than one site, granting a member adjunct access to one site will not enable them to edit any of your other sites.
Adjunct members are not required to pay anything and their membership will not expire for nonpayment as long as they are adjunct members on at least one site . Of course, they are still entitled to fund an account and create their own sites at any time, without restricting their ability to share one or more sites with you.
The only limitation of this feature is that there is no additional security within a site; any member who has permission to access the site can access or modify any part of the site. Adjunct members have full control over the content of your site, but not the administration of it. Therefore, they may change or delete all the content on your site, but they cannot remove the site from our system, close your accounts, see your balances, or perform any other activity not related to site content.
Also, we do not have the resources to provide technical support to adjunct members. You are solely responsible for supporting any adjunct members who do not have sites of their own hosted with us.
Adjunct members must go through the signup process themselves to create their own memberships and agree to our Terms & Conditions of Service; you may not create NearlyFreeSpeech.NET memberships for other people.
Storage is billed in terms of megabyte-days. Whenever the "Unbilled Storage" amount for your site reaches 31 megabyte-days, your account will be debited a penny. A megabyte-day represents the use of one megabyte of space for a one day period. This means using 31 megabytes for one day is the same as using one megabyte for 31 days. The "Unbilled Storage" number displayed on the Member Home Page is in byte-days. 31 megabyte-days is equal to 32,505,856 byte-days.
The amount of space that your site uses is measured several times per day based on the number of 2k disk blocks that it uses. These 2k blocks are the system default block size, and represent the smallest possible allocation of disk space; even very small files and empty directories require at least one 2k block each. The system then takes the average of that measurement and the prior measurement. The number of megabyte-days is then calculated on a pro-rata basis using the interval between the two measurements.
(For relatively-constant uses of storage, you can think of this as $0.01/MB per month; 100 MB left on our servers for a month would cost roughly $1.00.)
Currently, the space used by any MySQL processes that you have is not included in these calculations.<-->Bandwidth buckets were a way of getting a bulk discount before we restructured our bandwidth pricing to give automatic bulk discounts to everybody. They are no longer available.
We offer a "give us your two cents' worth" free trial to new members. This trial includes up to $0.02 of free service that can be used for a period of about a month to help figure out if our service is right for you without the need to make a deposit. However, we have been forced to apply certain limitations and restrictions. Here they are:
In general, we are happy to provide member support to free trial members. However, if a question indicates usage not consistent with the intent of the trial offer, we may not be able to assist.
It's a bit tricky. Due to an operating system limitation that we have not yet been able to work around, the ssh application cannot prompt you when establishing an outbound connection. If you run into this problem, you will most likely see a message like "host key verification failed."
To make it work you need:
Since this isn't the most secure state of affairs, we recommend that you not store such public keys on our server, but instead, scp them in when you need them and delete them when you are finished.
In general, although it is possible to make this work, it's better if you can refactor what you're doing to ssh into our server instead. Also keep in mind that we offer ssh solely for the purpose of maintaining your website. It is not a "general purpose" Unix shell account and using it as such might cause bad things to happen to you.
No. Currently you are not charged for ssh bandwidth usage. That's subject to change at some point, but it would hardly matter as it would take you a very long time indeed to pass a gigabyte of data doing the sort of activities we allow via ssh. For example, if you are editing a web page on an 80x25 terminal, you would have to redraw the entire screen over 530,000 times to get to a gigabyte of traffic.
Because this traffic is negligible, we've never bothered. Of course, if this feature were to start getting abused, we would have to reconsider, but fortunately our members have been very conscientious about their ssh usage.
Follow these steps:
No. The IP addresses listed for your site in your member control panel will change constantly as part of how our load-balancing system works. If this is of concern to you because you are configuring third-party DNS, please see this FAQ entry for instructions.
If you or someone else has cached or is otherwise using an IP address that is no longer listed (perhaps due to not following the instructions above), it is generally not a problem. At any time, any of our dozens of member site IP addresses will provide your site, whether they are listed or not. We will announce if we ever permanently remove any IP addresses from this pool.
Each site has a home directory that lives somewhere on our network, called the site root. Inside the site root, there are five subdirectories:
Old sites may also have a symbolic link from htdocs to public. htdocs is a historical name for the same directory. It is not used by our system.
Memberships represent an individual person and as such are non-transferable. Therefore, any kind of transfer will require the recipient to have a membership of their own. Once that is accomplished, there are a couple of different ways to proceed.
1) You can transfer a personal bandwidth account in its entirety, which will also transfer all sites, domains, and MySQL server processes funded by that account.
2) If the recipient has a funded account that is eligible to create sites, you can transfer items such as sites and domains individually from your account to the recipient's.
Please note that you'll need to make sure you account for the migration of any MySQL data that might be living on a MySQL process you own, but do not wish to transfer to the other member; a site that depends on MySQL will break if it is separated from its database(s). Similarly, if you transfer a site that uses one or more domain names, it is generally necessary to transfer the domain name(s) as well.
In either case, send or have sent assistance requests from both the sender and the recipient memberships, each containing a specific list of the assets that you wish to transfer: accounts, sites, domains, and MySQL processes.
Please note that, in accordance with our policies, the balance of any personal bandwidth account transferred between two parties becomes nonrefundable. Also, since we do not allow you to have more than one membership, we will generally not help you transfer assets between memberships if we determine that you control both memberships, unless one of the memberships is being closed as part of the transfer.
As long as an account balance is positive, you may create and host as many websites as you like funded by that account.
You should only ever have one active membership (because the membership represents "you" as an individual). Creating more than one is a violation of our Terms and Conditions of Service, and doing so may impair our ability to provide you technical support. If you've done this accidentally, send us secure support requests from both memberships and we will consolidate them for you.
Within your one membership, you may have multiple accounts (each of which represents "a discrete pool of your money") if you wish. We do not ever require you to have more than one account.
The ability to create additional accounts does not serve any technical purpose in our system. It is solely a convenience feature for you that allows you to differentiate funds for different sites and help track/control your spending.
Usually, this is done for tax purposes (such as to keep funding for business and personal sites separate). It can also be useful if you have one site that is very active or given to surges and one site that must remain available at all times. If both sites are on the same account and the account runs out of funds, both sites will be disabled. If they are on separate accounts, the busy site can never cause the other site to become disabled.
Therefore, you never have to create a second account for yourself to host an additional site, but you do have that option if it suits your needs.
For more information about setting up services that will be shared with others, see this related FAQ entry.
Most synthetic traffic (i.e. traffic that does not represent a real person or computer making a real request of a service we host) is dropped at the edge of our network due to our advanced network and firewall architecture. This protects our members' services from several types of denial-of-service attacks.
If you attempt to ping your web site you may get a response. However, this response is a fake generated by our firewall and does not necessarily indicate that your site is reachable. We do sharply limit the number of outbound ICMP ping replies we send at any given time, which can mean ping requests won't even get fake replies if someone is ping-flooding us; attempts to ping-flood us are very common and completely ineffective, largely because of precautions like these. For that reason, don't assume the (in)ability to ping your site reflects on whether or not it is working properly.
Some traceroute applications, like most under Unix, use UDP packets to probe network hops. These applications will show a "filter prohibited" response (usually "!X") or a routing loop at the edge of our network. Others, most notably the tracert.exe provided with Windows, use ICMP to probe network hops and will be fooled by our fake ping responses. Both results are normal and should not be used as the basis for a problem report.
If you need to traceroute to our network to diagnose an intermediate connection issue, you can use the hostname traceroute.nearlyfreespeech.net for this purpose.
For an accurate measure of your site's performance and availability, you should complete an actual HTTP request to the site, checking both that it responds correctly and how long that response takes. This would be true even if we weren't playing games with ping and traceroute, because overloaded or malfunctioning servers often respond quickly to pings but slowly or not at all to real traffic. Various utilities exist that can be used to test HTTP servers, such as wget, curl, and fetch.
If you do choose to delete a site and then create another with the same, we recommend waiting at least fifteen minutes between deleting and creating. If you don't, some parts of our system may get confused and continue to try to access the old (gone) site.
If your site has the wrong short name then you will have to delete it and create another. Short names cannot be changed.
There are two methods. The first is via a Mail-In Donation Deposit. Information is available here.
The second method is PayPal. This feature is enabled on a case-by-case basis due to the risk involved. Send us a secure support request with information about your site and the number, frequency, and size of donations you expect. If your request is approved, we will send you some example HTML in response to your support request.
In either case, we do impose some strict limitations on you in conjunction with donations, the largest of which is that you cannot provide anything of measurable value in exchange for donations. (In other words, you cannot use it as a substitute for e-commerce.) Also, we will not under any circumstances refund payments made by third parties to you as cash. Finally, we are very unlikely to accept donations on behalf of members who have not yet funded an account themselves.
We use your PayPal email address to match your PayPal deposit to your user account. If the email address does not match your contact address, we have to assume that the deposit came from someone else. Since our Terms and Conditions of Service do not allow our service to be used to transfer money from one person to another, we have to regard such deposits as nonrefundable.
If you receive this message because you used an alternate email address, but you are the one who made the deposit from your own PayPal account, you may safely disregard it. This only ever becomes an issue if you request a refund. If your account was funded by a "nonrefundable" PayPal deposit, we'll review it and if it's obviously you, we'll be happy to accommodate a request to return it to the PayPal address it came from.
We can change your member login and/or member name for one support point (each, if you want both changed). To do this, please make sure you have points available and submit a secure issue indicating that you understand and accept the point charge and what you want your login and/or member name changed to.
MySQL process or site names can only be changed by deleting the existing process or site and creating a new one.
We are very sorry to hear that, but we understand that we are not the right environment for everyone. Just drop us a Secure Support Request to let us know that you want the remaining balance in your personal bandwidth account returned and we'll take care of it. (You must request the return via the secure support mechanism; you cannot do it through email.)
We will return your funds by the same means you used to deposit them unless that is not possible (e.g. a closed PayPal account or cancelled credit card). If we send you a check, it will go to the name and address on the account (not your membership), subject to our rules against using our service as a way to transfer money between parties. (Also, remember we told you to use your real name there. We don't mind if you call yourself "The Great Gonzo" but if you need to deposit a check, the bank might.)
If you send in a request for a deposit return, we won't try to hassle you or change your mind unless you ask us to, so if you think there's something we could help you work out to get you to stay, please let us know before you request a return. And if there's not, please let us know that too. We want feedback from all our current, former, and future members because that is the only way our service improves.
We're sorry, but we cannot provide partial returns; getting a return entails zeroing out the account, closing the membership and returning the entire amount to you.
Please note that if you have any domains registered through us, you will obviously need to transfer it to another registrar or authorize us to delete it (without a refund) before requesting cancellation.
Our service is paid in advance, and almost all charges automatically suspend when your account runs out of funds. However, there are two possible ways you can wind up with a negative balance. If this happens, you will receive a daily email reminder from us until you deposit funds to cover the overdraft.
The most common way can happen if you have our RespectMyPrivacy proxy contact service and allow your account funds to run out. This service is charged every day, whether you have funds available or not, and is the only exception to the stop-charging-at-empty rule. We could very easily cancel it as soon as you run out of funds, but because we care about your privacy and we know that oversights happen, we choose to give you every opportunity to correct the problem before we expose your personal details. As of March 3, 2008, our policy is to cancel your RespectMyPrivacy service after 30 days of nonpayment. However, during that time, charges will continue to accrue, leaving you with a negative balance.
If you are in this situation, you can remove RespectMyPrivacy at any time to prevent further charges from accumulating, provided your domain is not expired, but you will remain responsible for the negative balance already accrued.
The second way to overdraft your account is significantly less common. If you let your account go empty, most billing is suspended. MySQL billing and site storage charges, however, continue to accrue as long as we retain your data (usually around 30 days) and they will be applied shortly after you add funds to your account. If you have a large site, leave your account empty for almost the whole 30 days, and then add only a small amount, it's possible that the accrued charges will be larger than the deposit, leaving you back with a zero or negative balance.
You can see pending site storage charges on your account information panel. If you remove an unwanted MySQL process prior to adding funds to an empty account, you will not be back-billed for that MySQL process.
If you're concerned that funding an empty account may cause you to overdraft and want us to check for you, or if you want to pay only the amount needed to fully cancel your service, please send us a secure support request and we'll be happy to help. Please be aware that we cannot cancel an account with a negative balance.
Each personal bandwidth account can have an optional alternate emergency contact, which is the email address of someone who you are authorizing to take certain very specific actions related to that account if you are unavailable:
These are the only circumstances where the alternate emergency contact can be used. Alternate emergency contacts cannot: close accounts or request refunds, request inbound or outbound domain transfers, or delete anything. The emergency contact role is limited to preserving what's already there. Even so, human factors and judgment are involved, so you should not make someone an emergency contact unless you trust them and their judgment; you will ultimately be responsible for whatever they do, because you authorized them to do it.
This feature is intended to allow a level of resilience in the case of accounts held on behalf of businesses or customers where the member responsible for the account might go on vacation or otherwise be unavailable when something goes awry. It does not change the ultimate responsibility for the account and its assets at all; specifically, the alternate emergency contact does not create any sort of shared ownership or simultaneous control of the account.
The emergency contact need not be a NearlyFreeSpeech.NET member already, though we may ask them to create a membership if necessary to perform a certain function, like making a deposit.
Very carefully.
We're delighted to have people refer us to their friends. In fact, we absolutely depend upon it for growth because we spend our money on servers and programming rather than advertising. However, this situation does create a couple of occasional problems that border on heartbreaking for us, so we've created this FAQ entry to offer some guidelines. (Although there are other types of referrals than male friends, we're using the words 'friend' and 'him' here for the sake of simplicity.)
First, and most importantly, you absolutely, positively, must not ever create a membership for anyone other than yourself. Not only are memberships non-transferrable, but you have no legal authority to agree to our TACOS on behalf of a third party. Your friend needs to read, understand, and agree to our TACOS for himself. Those are the rules for using our service, and we don't want people on our system who don't know the rules. Therefore, your friend must complete the signup process for himself.
Second, please make sure that your friend is equipped to manage or maintain his site(s) without ongoing assistance from you. You are not allowed to access other people's memberships! We have gotten into several painful situations because someone "helped" their less tech-savvy friend by setting them up on our service, then disappeared for whatever reason, and the abandoned friend expected us provide whatever assistance they were promised because no one ever explained the limited scope of support to them. We simply don't have the resources for that, and it invariably winds up with the friend hating us and blaming our "unhelpful support" for not keeping someone else's promises. Please, please, please don't put us in that position. It hurts.
Third, when telling your friend about our service, make sure your friend understands and is comfortable with the scope of our member support. People who are used to lingering on the phone while someone walks them step-by-step through their individual setup sometimes don't appreciate receiving an emailed link to our FAQ when they ask us a basic question. Remember that although you may not need that type of help, some of your friends might. For friends that do, the added cost of a service that provides the extra assistance they need is a very good investment.
What should you do to refer a friend to our service? There are four basic approaches you can choose from, depending on your needs (and those of your friend).
First, you can tell your friend about it and let him do everything himself. This is by far the easiest way to go, and is often the best if your friend is as smart and clever and inclined to do his own thing as you are. (You must be; you picked us!)
Second, you can tell your friend about it, get him to sign up, and then share a site using our adjunct membership feature. With this option, he can either create an account and site of his own and make you adjunct, or you can create the site on your membership and make him adjunct. This is the best approach for people who are going to be collaborating on a site.
Third, set up your friend's site, domain, etc on your account and then have your friend create a membership of his own and, when everything is ready, transfer the whole deal to him with a couple of quick support requests. You can either create a second bandwidth account to contain the site and transfer the account between memberships, or your friend can create and fund his own account and you can transfer the relevant bits individually. This is the best approach when you're preparing the site as a gift or favor, but your friend is willing and able to maintain it over the long term.
Fourth, you can create a separate bandwidth account under your membership, use it to fund your friend's site, and manage it all yourself. With this approach, your friend never touches the site personally. This is the best approach for people reselling our service, and for use with friends who want websites of their own but still compulsively forward emails about stolen kidneys and Bill Gates paying email users. ;-)
Again, we are thrilled and grateful to receive all kinds of referrals. We're providing this information solely to help you make sure that any referrals you give work out well for everybody involved.
This is something that we can do for you. Please submit an assistance request detailing exactly what you want moved, and which accounts you want it moved from/to.
If you want to transfer a site to another person, please see this FAQ entry for more details about coordinating the transfer.
The first thing to notice about our handling of DMCA notices and the notification-and-takedown process, is our consistent use of the term "allegedly infringing." Receiving a DMCA takedown notice does not mean you have done anything wrong, or even that you have infringed someone's copyright. It only means that someone has claimed (alleged) that you infringed their copyright.
When you signed up, you agreed to follow our TACOS, and one of the things you agreed to was not to infringe other people's copyright. When you upload content to our service, you are asserting to us that you have the right to make that material available. So on the one hand, we have you, who we have a contract and a relationship with, promising us that your content is legitimate, and on the other we have some random person we've never met who has no relationship with us making a claim that it isn't. Our first inclination, under those circumstances, is obviously to believe the person we know and trust, which is you. For that reason, we do not interpret receipt of a DMCA notification as prima facie evidence that you have done something wrong.
However, that's not the way the DMCA takedown process works. Our judgment and opinion don't really enter into it. By issuing a DMCA takedown notice, the claimant is swearing under penalty of perjury that their claim is true and accurate. For that reason, the law requires us to go through the notice-and-takedown process, even if the notification looks like complete bunk to us. (Unfortunately, civil perjury is a criminal charge, and we're not aware of even one case where a US prosecutor could be bothered to bring that charge in response to an abuse of the DMCA, due in part to the difficulty in proving that the DMCA abuse was intentional and not "an accident.")
Therefore, when we receive a DMCA takedown notice, we will forward it to you in its entirety and give you 24 hours to disable access to the allegedly infringing content it references. "Disabling access" to the content doesn't necessarily mean deleting it, although that is one approach. You could also disable the site, change the file or directory permissions, or temporarily move the allegedly-infringing content to your site's "protected" or "private" directories. It doesn't matter how you do it, but you must remove the content by the deadline or we will have to do it. Our ability to disable access to content usually entails disabling access to an entire site, whether the entire site is allegedly infringing or not. That really sucks if there is only a small amount of allegedly infringing content.
Once you have disabled access to the allegedly infringing content, let us know that you've done so. When you do so, you must indicate which of these three courses of action you wish to take:
If you do not intend to submit a counter-notification, you may wish to include sufficient supporting justification for us to form an informed opinion on whether to hold this incident against you if future allegations arise, as repeated infringement is grounds for adverse termination of our service.
If you don't respond, or if you indicate that you intend to file a counter-notification and then don't do it, we will assume you are accepting the allegation of infringement. If you don't file the counter-notification, the process ends. Thus, the rest of this FAQ assumes you are filing the counter-notification.
Your counter-notification must be in writing and must contain the following elements or we will reject it:
The best ways to submit your counter-notification are email or fax. If you use email, make sure you're sending a scanned copy that shows your physical signature or a PGP-signed email with a signature that can be correlated to your member contact email address.
Pursuant to the law, we will provide a copy of your counter-notification to the claimant. This means they will know who you are. If you don't want them to be able to identify you, the counter-notification is not an option you can use.
The claimant then has 10 days after receiving the counter-notification from us to file an action against you in the appropriate court seeking a court order to restrain you from engaging in infringing activity relating to the allegedly infringing material, and then to notify us that they've done so. If they do not, we will restore access to the material. (In a case where you disabled access yourself, we will restore access to the material by notifying you when it is OK to restore it. Do not under any circumstances restore access to the allegedly infringing content or make it available at a new location without that notification; that'll result in automatic adverse termination of your service.)
This FAQ entry provides general guidance about our DMCA notification takedown and putback processes. It is not a substitute for legal advice. While we strongly urge everyone not to be bullied or to allow the DMCA process to be abused, we strongly urge you to consult a legal professional if you find yourself in this situation, because the consequences of filing a spurious counter-notification can be significant.
You can get the full text of the Online Copyright Infringement Liability Limitation Act portion of the DMCA here.
We offer a public RSS feed of News & Announcements blog entries, which include new service availability, pricing changes, etc, at:
http://blog.nearlyfreespeech.net/category/news/feed/
We have another Network Status RSS feed, which we attempt to use for announcements about service-affecting maintenance or changes that apply to all or nearly all of our members:
If you make a mistake while entering your card billing address, we may not be able to accept the transaction. However, the bank that issued your card may place a "preauthorization hold" in the amount of the deposit anyway.
These temporary holds often show up in online summaries as "pending activity" or similar. However, your bank will automatically remove them after some period, usually a few days. Only the transactions that we accept and credit to your personal bandwidth account will ultimately be charged to your credit card balance.
Since such holds are placed by your card-issuing bank, they are entirely beyond our control. We cannot remove them, nor can we accelerate the pace at which your bank removes them. The best way to avoid this situation is to double-check your address information with your billing statement prior to making a deposit.
If, for some reason, you do double-deposit into your NearlyFreeSpeech.NET personal bandwidth account in a short period of time (which is pretty hard to do by accident), please contact us immediately. We will be happy to assist you.
Ordinarily, each site has its own distinct filesystem. However, sometimes it is desirable to have multiple sites share certain content, like a common software package or a code library, or a set of large files needed by both sites that you don't want to pay for twice.
We have experimental support for a scheme where one site can be designated a "parent site" and one or more other sites can be designated as "child sites." Each child site shares the private, protected and tmp directories of its parent, but gets its own public and logs directory, as shown in this example, where child is the short name of the child site.
There is no requirement that the parent and child site have the same server type. For ssh and FTP, only the parent site is accessible, but that provides full access to all child sites as well as the parent's own content. Since this feature is experimental, be ready for some bugs (mainly in the UI).
Setting this up requires manual intervention on our filesystem. Thus, to request it, please submit a secure support request indicating which site is the parent site and which site(s) should be the child(ren). Due to the admin time requirement, there is a $1 one-time fee to adopt a child site.
When this is set up, the contents of the child site's original protected and private directories is permanently lost. Make sure there's nothing in there you want to keep!
It's often impossible (or close to it) to obtain a regular authorization for a gift card or prepaid card due to the combination of anti-fraud measures we employ and the draconian restrictions prepaid card issuers put on "acceptable" usage of their cards.
At this time, we cannot recommend or endorse attempts to use of prepaid/gift cards with our service. However, if you have no alternative, follow the following steps:
Depending on the type and availability of prepaid cards in your area, you may need to vary some parts of the above instructions, or they may not work at all. We have had at least one situation where a member physically mailed us the card and we still couldn't get the issuer to authorize it.
For your protection, we will send out a confirmation code just like we did when you created your membership with us. Once you confirm the new address, it will begin working almost immediately.
If you have NearlyFreeSpeech.NET DNS domains with the default setting to forward email to your contact address, they will be updated by this process.
Some domain registrars require you to include the IP addresses of our name servers when setting up your domain. Although this list is subject to change at any time for any reason, here are the IP addresses for all the DNS servers which may serve member domains. Be sure to use the correct name servers for your domain.
If (and only if) you are using our secondary DNS service, one of the following name servers may also apply:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.8 (FreeBSD) mQGiBEgW1+URBACVp8w//wqL8QYrmuvPHvKpzzS1RByoWIHiBbXdyzI8A8DD9FKM MOawjqVzG2CB3HTTB/DQM3Mxa5oiizi1zXpiP7b9MEu3fdTa2quYTtRcexksHkRH dXFx2lN1YiPnM9+mGxslh+IOFlNXBNzhGSD4yHRjRq+UHdgfGsRgRPiYhwCgpDz0 4KaCImXrszSeD6GhRmsa3j8D/1PajiMNglB0JcIJBPBoMVSNI0fBVAirG3n7HopI d7VBE1A2P3QWONSZcOr1z+kwEykFW4zWEeick9QTqL0jO8qNbWm9+EQ1/IsrbzBz dh2Jkml0TWAGNNMhpnhaKKCznfIYJc1tA56uAYV6+ooAwu/gczOaUa5KPStaPT0M HZ5eBACFMGxLl+GQe63KlBWp/mCBotbZzSdA4D1IfZ9dxpc0AzS2/Mpev3NGlxPU U+GEPtXtLgqd24jHoIkHHGxG1xKMz3jmCPOi99l9V7AZClYuAbc/6GF3IC1OSBSz m3pWVxK8j4XrYBHYqjeFeQAw1udRilP+Vs4CD0OZ9CzYBL7lZbRHTmVhcmx5RnJl ZVNwZWVjaC5ORVQgQmFja3VwcyAoRHJvaWQgS2V5KSA8YmFja3Vwc0BOZWFybHlG cmVlU3BlZWNoLk5FVD6IYAQTEQIAIAUCSBbX5QIbAwYLCQgHAwIEFQIIAwQWAgMB Ah4BAheAAAoJEImEvPLcwT8VMhwAn0svkRYQyJPKF4PddA91cK5ksawTAKCQ0mz0 uwN3akN0MuOfM6FzgHhbrLkEDQRIFtflEBAAu65YWvNarwEK2Ej8ZGIgceSBOVep XJxWEU97kR4MuFKcQdtvttgb/QXtA/b+4VK8hGC0SkaA9UrGZrYXbQJ46V6cJH32 /OqLWoxyJ1XQSq8c7J1hc85RXsWS162r/WmORozKziBgq73VRkeNfV9h7yVvclZE U7E4kokn7nCg9iePL9gehwJ2v8r6P3co/p5SxM5eBNAyC2THpwhP3v7UXWnOit/t dH51G4Qcq98GYtnM7qL3kM6V6nje7icGfhsDUjRXUezF5rHQQ+Hqky3WwfmKIcdv XJJQcEUKN24XzG3EYju2dFiBInl3UfLxGGW5Froo+4C+xepa4MP/0Kcq3y78AVi1 YPiSok0NHEKB7MsHSftZi0e201UHQD/QiVs6/HFG45lTucQlPt8pC6o43oBixo2L E2QdkRukbkWdbW/gtCTiRtyYB83vbBwAnsi+ksQi7I8wkfj5fUpyPtvMaawvGHyL vN2eSh+BLpyk3hF2YUJDLjKoIQRarV+rntooPVbWEMLC02YNy99Z0LC9vqlmIlS0 C1VL3aqyjRoyulMlEUsUUt80ukrLIYtL8Szsdl0kc4cB+GM3Zlm8bOAeZFC+ZRdK sKY2ymnEU8hcNwtqOd8tNEJzfv5C2B9WXL5oGgsZlfpIofc1mBHMw//J+9ORISW1 Paw+zUwB91OdSfsAAwUP/3lvkodE+PuGaBr6O8lsqm6eQr81klhtwNoBu1apim1E evOv7vAC7r4qdGMKKrDCvcQhy9lWdWdUMpvHyQGm5DfS4kGP+SNygS+9uuKA7LuU JFxdXOprCTOgi0Rco+kgdmcS454kJOxNFTd+z9jYp63QYHGrP0tW7lkkgEo3zqbI DzTBWaBfgSMYoakuQ5XYenw49K0H5ZvSkLf99Tus/cnM7T6ncecjeaxdafFVzBQu bKE9ZTgjGGnkmAL7dp/C7ha+AeonKUJdXZvHO98UhShXqFmNfx5mYc4ZbfnBTLem gR4V0FMy/8zkNq4JeMOtckh1BWJ/eLYbQpnfXb4Dt5iwZEjoE8D7ooNPupTjCf3J 4Pc4tn6z3nZ1shw819rYxDYD7kR74T/PEOmPClZoFSS5yixIxWn6Z1X17YdK6kDf bzccJKZ5juC+hzjtUE+1jXH0eXZEMV5nqkzYYf5aQg7o2kp7+6vJU2Lpfrcyi5NB wTWpBlTYFyH1jxiEnbHHzdPBUNjnh0rYWdgFlfHCX073yuJ417pHRe0lkS7p+yl9 5Turygl6N8lSOmENo6cqoSp1GlREcpU+Z7mibHK8py8weQyYRIss1LqxTtK+05rv XfkHGufaJ72TS9zchsEiGO/fu5lpkQK3wytR3O+ygtYwyzoQxUtydyiB9tiVrfG6 iEkEGBECAAkFAkgW1+UCGwwACgkQiYS88tzBPxW9PACfYYpeTUqRYIgzEqC+h2pA GQSZS4wAn2mUk10VIwptXAZt+vWIgoWByilw =D2vD -----END PGP PUBLIC KEY BLOCK-----
We do not have any automated system to process MoneyBookers deposits, therefore we process them similarly to mail-in deposits.
Send your payment to payments@NearlyFreeSpeech.NET. Make sure to include your account number in the relevant fields, or we'll have no way to tie it to your account.
Once that's done, use the Mail-In Deposit Assistance Request to send us the transaction specifics. We'll dig it up and credit it to your account (provided we can match the amount, email address and account number on the transaction with what you provide in your assistance request.
Please note there are no instant rebates for MoneyBookers deposits, meaning that deposits must be at least $1.01.
In a shared hosting environment such as we offer, keeping everyone's web site safe and secure is of vital importance. We have carefully constructed our PHP 5 Fast environment to make your site and its files as secure as possible while still running at maximum performance, and PHP's safe_mode is currently one of the many essential components of that environment.
We do offer PHP 5 Flex, which is a way to run PHP without safe_mode restrictions in our CGI environment. If the need is great, PHP 5 Flex should be compatible with certain legacy applications (e.g. Gallery) that malfunction if safe_mode is enabled, but it generally runs at least 3-10 times slower than PHP 5 Fast.
Most people who choose PHP 5 Flex do so for the wrong reasons. It can mask the existence of certain problems and thus sometimes appears to be an easy way to make broken things appear to work. Due to the severe performance penalty, we strongly recommend against using PHP 5 Flex to circumvent open_basedir() restrictions or PHP file permissions issues. Problems with open_basedir are almost always caused by incorrect path configurations or depending on bad default paths, issues which are typically very easy to resolve under PHP 5 Fast. File permissions issues merely require a basic understanding of the Unix owner/group file permissions system. If you use PHP 5 Flex to solve the problem instead, you will destroy the performance of your site for no reason. See Writing Files in PHP for more information.
If your need is appropriate, you can switch to PHP 5 Flex by visiting the "Sites" page and clicking on the short name of the relevant site. On the next page, in the "Actions" box, select "Change Server Type."
CGI applications may be automatically terminated if they consume excessive system resources, run for an excessively long time, or appear to operating as "daemon" style processes.
NOTE: In addition to .cgi the following "default" CGI extensions will also work: .py .pl .rb
There is a web service that many of our members have been able to use successfully, www.webcron.org, that will enable you to set up periodic requests for a page on your site. By making that page a script, you can achieve the same effect. Note that this service now charges a few dollars per year as of October 2008.
We do not presently support this feature ourselves, because our shared hosting environment is highly dynamic, meaning that when no one is looking at your site, it "isn't there." This means that there is nowhere for cron to run. We do plan to add a similar feature in the future, but until we do, we are very grateful to webcron.org for offering this free service.
While we allow limited usage of this nature, please remember that our service is not designed for continuous automated access, and we take a dim view of excessive resource usage. Please exercise good judgment in your use of this type of automation.
As of October 2008, we are aware that webcron is no longer offering their free service to new users. We are working on an alternative and will post more information on our blog as soon as it is available.
The only commercial HTML editor that we have access to is Microsoft Office Front Page 2003, which has its own FAQ entry. Though we don't use it, we do conduct periodic tests to make sure it works with our system. If everything else were equal, that might make this the best choice. If you get stuck with it, there is a chance, albeit a small one, that we can point you in the right direction.
There are many other commercial programs that work as well. Some of them are listed in our Pre-Sales FAQ.
There are also many freeware, public domain, and shareware utilities for editing web pages. We don't have any specific recommendations in that area because things tend to change very rapidly. A great place to start if you want to learn more about these programs is the Tucows HTML Editors Page for Windows or Mac.
Some factors to consider in choosing a program are:
The NearlyFreeSpeech.NET web site is entirely maintained using vi, except for one guy who insists on using emacs. We do not recommend learning these tools to people getting started with HTML or the Unix command line, as they are both general-purpose text editors. The newer tools are purpose-built for editing HTML pages and are much easier to learn.
No. By default, this feature of PHP is not enabled. It is widely considered a serious security risk and we have seen a number of member sites victimized by exploits related to having register_globals enabled. We discourage its use.
However, if you understand the implications of register_globals and you are prepared to accept the increased security risks associated with its use, we have provided you with the means to enable it on a per-directory basis. Simply create an .htaccess file in your public folder containing the line:
php_flag register_globals on
You can verify that this is working by using the phpinfo() function on a PHP page. You should see register_globals set to "On" in the local context and "Off" in the global context.
If you do not need register_globals support, you do not need to take any steps to protect your site from exploits related to it.
The exact path can vary based on when your site was created and when it was last reconfigured. To make sure you stay pointed at the right location, use the PHP-standard $_SERVER['DOCUMENT_ROOT'] value to refer to your site's public directory.
We also provide the $_SERVER['NFSN_SITE_ROOT'] variable for this purpose, in addition to DOCUMENT_ROOT. NFSN_SITE_ROOT points to your site's root directory, the parent of public and protected, making it the best choice for safely referring to the protected directory from PHP.
The path to your site will also differ between PHP 5 Fast (where it can vary) and PHP 5 Flex (where it will always work like CGI).
We strongly recommend that you use $_SERVER['DOCUMENT_ROOT'] or $_SERVER['NFSN_SITE_ROOT'] whenever possible and avoid hardcoding paths in order to avoid problems in the event of a change.
PHP is also a frequent topic of discussion in the Member Forum and Member Wiki.
http://www.w3schools.com/html/html_examples.asp
Here are some general reference sites that we use and recommend:
If you come across other great sites, please let us know.
<!--#include virtual="../relative/path/app.cgi" -->
The "#exec cmd" and "#include file" directives are deprecated and are not guaranteed to work at all on our system.
By default, the PHP memory_limit value is set at 32m. This is more than adequate for almost all needs (about 99.75% of sites, by our measurement). However, sometimes more memory is needed, particularly for modular applications such as Drupal when large numbers of resource-intensive plugins are in use.
We can increase the PHP memory_limit on a per-site basis if your site is using PHP 4 Fast or PHP 5 Fast, but since this correlates directly to an increased resource usage, an additional fee applies, as outlined in this table:
| 40mb | $0.01/day |
| 48mb | $0.02/day |
| 56mb | $0.03/day |
| 64mb | $0.04/day |
| 96mb | $0.08/day |
| 128mb | $0.16/day |
| More | contact us |
Of the 0.25% of sites that need an increased memory_limit, almost all need 64mb or less.
Please note the memory_limit value is per-request, not a per-site limit. Consequently, larger values represent access to huge amounts of memory when aggregated across a large number of simultaneous requests, which we must then take into account when allocating resources to your site.
To increase your memory_limit, please submit a secure support request specifying what memory_limit you would like and what site you would like the setting applied to. The first change to a site's memory limit will be made free of charge. If you want to make an additional memory limit change within three months of any previous change to the same site's memory limit, you will be charged two support points.
The path to the root of your site is always seen as /home by CGI scripts.
This is reflected in the NFSN_SITE_ROOT environment variable, which will always be set to /home for CGI scripts.
To switch between PHP 4, PHP 5 Fast and PHP 5 Flex, visit the "Sites" page and click on the short name of the relevant site. On the next page, in the "Actions" box, select "Change Server Type." This option is most often used to upgrade existing PHP4 sites to PHP5.
Be sure to see this entry for more information about what these designations mean.
As of January 1, 2009, the developers of PHP have discontinued support for PHP 4. We are therefore in the process of deprecating PHP 4 support, and it is no longer possible to switch to PHP 4, only away from it.
By default, CGI scripts are executed as the "web" user and group, which has almost no privileges on our system. In most cases, this is the best choice, as it controls the damage that a vulnerable script can inflict. However, for some file-management and other applications, it is necessary for a script to run with the full permissions of the user that owns your files (i.e. you, a.k.a. the "me" user ID when viewed from ssh).
To this end, we allow you to set the suid and/or sgid file permission bits on CGI applications. When the suid bit is set, the web server will execute the script using the user id of the owner of the script (provided that the owner of the script is you). When the sgid bit is set, the web server will execute the script using the group id of the group that owns the script. It is safe to use the suid/sgid bits for this purpose; our system does not otherwise honor them.
Please note that there are security implications to running web scripts as your own user ID. If such a script is compromised, you will need to delete your entire site and recreate it from scratch or otherwise manually check every single file because there will be no other way to ensure that other files have not been subtly changed. For this reason, we strongly discourage the indiscriminate use of this feature as a substitute for properly setting up file permissions.
You may be able to use our ssh environment to compile your application for our servers; we provide C & C++ compilers for this purpose. However, we only provide these tools as-is; you are completely on your own with respect to using them or getting custom CGI applications to run on our servers.
A site's "realm" refers to the combined collection of all the operating system files and third party applications present in its CGI/ssh environment.
Some people want the latest and greatest versions of applications, particularly programming languages, especially while they are developing a new site. Others strongly prefer things stay as stable as possible so they don't have to deal with their site breaking every time a non-backwards-compatible change gets made by some application developer, especially once their site is up and working.
Because these desires are in direct conflict, we provide multiple site realms. Currently, we provide two. The "freebsd6" realm is the default "stable" realm. Very few changes are made to this realm, other than security patches and updates that fix significant problems. We also provide the "freebsd72" realm, which starts from a much newer codebase and is where most requested software installation and upgrade happens.
Over time, the freebsd72 realm will mature and become stable and we will add another to absorb new changes and upgrades. Our goal is to release about one realm per quarter, and to keep the past four realms available. This gives you control over when to upgrade (to some extent), because you can switch realms if you want. If you do hang on to an old realm to the point where we have to get rid of it, we'll bump you to the newest stable realm at that time.
To switch between site realms, just visit your site's info panel in our member interface and select the "Change Realm" option. This is not a subtle change; if you're logged in to ssh, it will attempt to kick you off. If it doesn't succeed, the change will defer until you log out. Likewise, in-process CGI requests may cause delays in realm switches.
Please note that, with the exception of PHP Flex, the version of PHP you use is independent of what site realm you use. It affects only CGI and ssh.
When you encounter a problem that you think may be related to our service, we absolutely want to hear about it so we can fix it or help you get it fixed.
However, in order for us to help you, we need certain information. If all you tell us is that something is "down" or "doesn't work," you are severely limiting our ability to troubleshoot the problem. This is compounded if you say "my site" or "the service," and that's even more true if you host more than one site with us.
First and foremost, if you want to contact us because you received an error message, absolutely, positively, do not omit or paraphrase the error message. Include the full text of the error message. If you don't, you'll wait around for us to respond, and our response will be "what's the full text of the error message you're receiving?" That's wasted time, which is no good if there's really a problem with your site that needs our assistance.
If there is no error message, but something doesn't work the way you expect, then carefully explain what you're doing, what you expect the results to be, what the results actually are, and how the actual results differ from your expectations. Be absolutely as specific as possible.
Second, make sure you've read the error message. Many of our error messages include specific lists of reasons why they occur, and it's painful for us to see someone's site down for a reason they could fix at any time.
Third, make it really clear what site (including a specific URL if possible), or email address you're having a problem with. If you don't, particularly if there's more than one possibility, you'll lose more time while you wait for us to ask for clarification.
Fourth, outline what steps that you've already taken to try to identify the problem. Recognize that we control only a limited portion of the middle of the chain between a visitor to your site and your site; ISPs control one end and you control the other. Help us understand why you think the weak link is in our portion of the chain. For example, the Site Troubleshooting Wizard can't solve all problems, but it does identify a lot of weird domain and DNS related issues, so it'll help us to know if you've tried that and what the result was.
Finally, if you're asking about an error on your site that may be related to accessing a CGI or PHP script, or if you have a complex .htaccess file, make sure you have your error log enabled. It's disabled by default to save space, but it's an invaluable tool for identifying and resolving many types of problems.
Our goal is for your services to be working properly at all times. If something's not right, we want to hear about. But please help us help you; give us the information we'll need to confirm, troubleshoot, and resolve your problem. Keep in mind that we often have to triage requests, so that people with problems under our control get priority, and we are generally not able to provide programming or script-debugging assistance beyond confirming that our system is working correctly. If you structure your request along the lines shown here, it may help us spot yours as one that needs more immediate attention.
This is a restriction imposed by Apache. It is designed to prohibit ambiguity in determining which access controls apply to the directory.
Assume your public directory contains a subdirectory called example. If you access it via /example, you have not entered that directory. That means that the .htaccess file from your public directory would be applied, but the .htaccess file inside the example directory would not. However, if you access it via /example/, then you have entered the directory and both .htaccess files will be applied.
Now, assume that your public directory's .htaccess file allows all visitors and has directory indexing enabled. Assume that your example directory's .htaccess file allows only visitors with a certain cookie set and denies directory indexing. In this case, if it were allowed, visiting /example would produce a listing of the contents of the example directory while visiting /example/ would produce an access denied error or demand for authentication.
To prevent the confusion and security issues that such conflicting behavior would create, Apache detects attempts to access directories without trailing slashes and automatically issues a redirect to the same URI with the trailing slash appended. That way, you never have to worry about the scenario in the preceding paragraph.
Although you can't stop people from typing one in by hand, make sure you don't use invalid directory URIs internally on your site because they require this extra redirect, thus making your site appear slower.
If you find that these redirects are not using the site alias that you want, for example, if they redirect you to example.nfshost.com instead of www.example.com, then you may need to adjust your site's canonical name settings.
There are a couple of possible explanations for this.
If you allow your account to run completely out of funds, your sites will sometimes continue to be identified as "Unknown Site" after you make a deposit. To work around this issue, please follow these steps:
If you are not able to get this to work, or if you have a large number of sites, please send us a Secure Support Request and we will take care of it for you.
To prevent this problem from ever happening, simply use our account balance warnings to keep your account from running completely out of funds.
Note: We believe this issue has been resolved. If you encounter this behavior, please let us know.
Our Site Troubleshooting Wizard may be able to help. It is pretty good at detecting site problems, DNS misconfiguration, and domain registration errors.
If that doesn't work, you haven't changed anything that may have caused this, and there is nothing listed in the announcements about something wrong right now, please contact support and provide as much information as possible about your problem. Be sure to include the name of the site you are reporting trouble with!
As a security precaution, CGI and PHP scripts run with different user credentials than you do when you edit your files. Although the CGI/PHP user has significantly less privileges overall, it is possible to create a situation where an application creates files or directories that you do not have permission to access or remove via FTP or ssh. This typically happens if an application's umask is set incorrectly; the resulting files or directories will be owned by the "web" user and will not be group or world writable. (Correct umasks are 0 or 002, depending on the expected group ownership. A umask of 0 should work for most web applications, and does not compromise security on our system the way it does on some shared hosts.)
If this happens to you, please submit an Assistance Request indicating the site and the path to the files. We will perform a semi-automated change-of-ownership on the files/directories so that you (re)gain control over them.
If you ask us to delete files for you we will change their permissions as described here instead; the potential for error if we start deleting member content is too great. After we change ownership of the files, you will have full permissions to do whatever you wish yourself.
In order to process credit cards, our service makes an attempt to verify the address you have entered. In most cases, this is no problem.
Certain banks in the UK, for reasons we do not fully understand, return "This address is incorrect" when they should return "We do not support address verification." This will cause our system to reject your card no matter what you enter for your address details. This affects about 10% of our UK members.
This could happen even if you have successfully used the card other places online in the past. We are not only unusually strict in address verification enforcement to protect our members from fraud, but we are not large enough to have specialized card processing options for the UK as many huge Internet retailers (like Amazon) do. We are not allowed to set different address verification standards on a country-by-country basis.
If this happens to you, you have several options:
We are very sorry for the inconvenience caused to our affected UK members by this limitation. Even though it affects only a few, we will certainly take the first opportunity that presents itself to eliminate it.
Technically, it means that the web process handling your request closed the connection without returning any data at all, not even HTTP headers. (It sent a "zero-sized reply.")
Unfortunately, there are a number of completely different reasons why this might happen that need to be investigated individually.
If the error message takes a very long time to be displayed (a minute or more), it may just be that the system got tired of waiting for a script or CGI application to respond. In this case, try to identify what's making your script run so slowly.
If the error message appears instantly, it probably means something is aborting the connection. If you receive this error from a CGI script, it may mean that your script (or its interpreter, if applicable) is core dumping. There is a known problem on our system where you can get this error running threaded Python applications on our 64-bit servers; let us know if that happens to you and we'll move you to a 32-bit server.
To help debug this problem, make sure you have your error log enabled. If it happens immediately and there are no error log entries, it may be a core dump. In that case, find a public URL that does it reproducibly and submit it to us in a secure support request; we can check the system logs to find out if requests for that URL are indeed core dumping. If there are error logs, they will probably help identify the problem.
If you are running into this problem on a PHP site, it may help to add the following lines to your .htaccess file:
php_value pcre.recursion_limit 1000 php_value pcre.backtrack_limit 1000
The specific values to use vary from site to site. Some require settings as low as 10, others may be fine with 100000. You want the largest value that you can set without triggering the zero-sized reply. This is caused by a PHP/PCRE bug and is not under our control.
Please see this page for complete information on this message and how to eliminate it.
This error means there are too many total simultaneous non-cacheable HTTP requests in progress for your site. This is an extremely rare condition, but the causes, in order of decreasing likelihood, are:
Please be aware that while almost everyone starts out thinking #4 is the reason that applies to their situation, the cause almost inevitably turns out to be something else. A good rule of thumb is that each possible explanation above is about ten times less likely than the one above it, so the top one is 90% likely and the bottom one is about 0.09% likely.
If this message persists long enough to cause problems, the explanation is most likely the second one. In that case, the way to troubleshoot it is to identify and resolve the cause. Coding problems that can cause this include unconditional long sleeps, system calls that can hang indefinitely, poorly-optimized MySQL queries, and anything that serializes requests (causes them to have to wait in line and get handled one at a time). Some poorly-written WordPress and Drupal plugins have been known to cause these sorts of problems under heavy loads, particularly ones that deal with statistics or running periodic scheduled tasks. It's also possible to encounter this without any code problems if your code makes untimed network connections (e.g. DNS or HTTP) to other sites or services that are down or unreachable.
If you submit a secure support request while the problem is occurring, we can typically identify the problem URLs for you, and may be able to give you some insight as to what they are waiting for. After the fact, it may be possible for you to get some idea of what happened by looking at your site's access logs, if they were enabled.
It is important to understand that this limit is not some nuisance we put in at random to cause problems. It is an important protection that keeps your site (and others') safe. When someone says they want it removed, we hear: "My car would go a lot faster through the mountains if it didn't skid along the guardrail every time I go around those hairpin curves! Take that guardrail out!" We know from experience that if we take out the guardrails, the car won't go faster; it will fly off the side of the mountain and end in a fiery crash. You may be willing to take that risk with your site, but since ours is a shared hosting service, we can't risk letting you take others down with you. If you want the limit raised, be prepared to show us ample concrete evidence documenting both your sustained high traffic levels and the excellent performance of your highly-optimized code.
This error occurs when a CGI script exits before writing a complete set of HTTP response headers (not even an empty one). It can happen for a variety of reasons:
In all cases, the best thing to do is make sure your site's error log is enabled and see what it says about the problem. If the error output says that there is a system problem preventing execution of your script, or if there is no message in the error log at all, please submit a secure support request indicating the URL of the script you're having trouble with. In many cases, it will be easier to debug a problem if you can provide a simple example at a publicly available URL.
FTP, SFTP, and ssh all use the same username and password to access your site. This username is not the same as your member login; it is based on both your member login and the site name. The password is the same as your member password. The specifics are listed in the "FTP/SFTP/ssh Information" box on each site's information panel in our member interface.
To find this information:
Many uploading and web design tools have specific instructions available in HowTo - Uploading section of our member wiki.
If you need to use a separate program to upload files, we recommend using a program that supports the SFTP protocol.
We do not recommend using browser-based FTP to upload files. This feature has been completely removed from Internet Explorer 7, and current versions of Firefox and the MacOS Finder are limited to read-only FTP access, making it impossible to upload. Other browsers may provide better FTP support, but they still tend to be more difficult to use and have fewer features than proper FTP clients.
In all cases, you'll need to check the documentation for the program you are using for specific instructions, but at a minimum you will require the connection information for your site to upload successfully.
We do not provide any "built-in" web tools for site authoring as such tools tend to be very limited and offer only basic functionality. As such, they do not provide the sophisticated and powerful options expected by our members.
Yes. To access a website via ssh, use the connection information.
The SSH key fingerprints for ssh.phx.nearlyfreespeech.net are in this FAQ entry.
Scp and SFTP are supported. Port forwarding is supported but is only permitted for establishing secure remote connections to your MySQL database.
Important: Our ssh environment is provided solely for maintaining your website and is not to be used for any other purpose. This specifically includes using it for proxying, port forwarding, or anything similar. We try to run an open system; we allow outbound network connections from the ssh server for people who need to move content from/to elsewhere, and we allow ssh port forwarding so people can access their MySQL processes from offsite. But we can and do check for outbound network connections that use our system as a proxy. As this is a violation of our Terms & Conditions of Service, we will take appropriate action if we observe violation.
All uploading clients should automatically be in the correct folder after they connect. Do not change your upload directory setting unless you are absolutely sure your client is getting it wrong.
For FTP clients (including publishing programs such as Front Page and Dreamweaver that upload using FTP), the correct directory is /public.
For ssh and SFTP clients, the correct directory is /home/public.
(Once uploaded, scripts that run on your site will use a different path to access your files, depending on whether they are PHP or CGI.)
SFTP is the Secure File Transfer Protocol. It is sort of a hybrid between FTP and ssh.
You can use SFTP to send files to our service. It's much safer and more private than regular FTP because it encrypts both your password and your file transfers.
Since SFTP piggybacks on the ssh protocol, SFTP is also robust in the face of NAT routers and firewalls, which often cause problems for FTP.
Due to its advantages, SFTP is the recommended method for uploading content to your site.
There are a number of SFTP applications listed in our member wiki.
Yes, but.
Our system does not access your site's filesystem until after you have authenticated yourself. Also, correct authentication depends on both member name and site (since more than one member name may have permission to access a given site and a given member name may be able to access more than one site). Therefore, you cannot place a public key file in your site's filesystem to bypass password authentication.
We keep a separate database of ssh keys tied to your username for this purpose. If you have a public key you wish to use to authenticate your ssh connection in lieu of your password, please submit your RSA key in OpenSSH format via a Secure Support Request. Per current best security practices, we will not install keys that have a length less than 1536 bits or keys on the Debian weak key blacklist. We prefer that you use a key at least 2048 bits in length, and if you are generating a new key, the recommended length is 4096 bits.
Once installed for your membership, an ssh key may be used to authenticate access to any site you are authorized to access, including all of your own sites and any adjunct sites you may have access to.
We're sorry, free trial members may not submit public keys.
On Windows, the far-and-away best ssh application is VanDyke Technologies' Secure CRT. This program is rather expensive ($99) but worth every penny if ssh on Windows is a part of your daily life. PuTTY is a very popular free alternative. It is a little less pleasant to use, but is very workable. (PuTTY requires no local installation and is a perfect tool to slap on a USB memory stick for secure access from anywhere.)
Other alternatives do exist, but these are the most common and the ones we use ourselves.
First, please consider using an uploading method other than FTP, such as SFTP or SCP. FTP is a complex, insecure protocol that does not work very well on the modern Internet. If you have an alternative, use it.
With that said, almost all FTP problems are caused by NAT devices (especially cheap residential gateway routers) incorrectly processing FTP connections, or by personal firewall software blocking FTP access. These problems generally manifest as being able to connect to the FTP server, but not to upload or download any files. FTP has two operating modes, active and passive. The first response to any FTP connection problem should be to switch your FTP client from active mode to passive mode, or vice versa. Switching modes almost always clears up FTP issues.
Other potential problem areas for FTP include your local firewall configuration (hardware or software) and incorrect FTP connection information.
The current keys are:
The RSA key was upgraded on May 17, 2008 to increase its length. The old key was:
For details of that change, see this blog entry.
The most common explanation for this is that you are running firewall software that uses a bogus block list to block connections. The P2P application Peer Guardian is known to have this problem.
In such cases you will need to either disable the application or set up a manual override to allow the connection.
The most common error messages that indicate this problem are "No route to host," "Host unreachable," or "General failure" when attempting to access our FTP server.
If you find yourself accessing our ssh server routinely, you may want to find a way to access it using a shorter name. We do not allow nor do we support the creation of DNS aliases that point at our services, so if you want to use a shorter name, it's necessary to find another way to do it.
The options that may be available to you are highly dependent on the operating environment and ssh tools you're using. We'll outline a couple here, but you'll need to check your own system's documentation for specifics.
The first approach is the simplest: most systems have a local list of hostnames, and you can add a short alias like "nfsnssh" with the actual IP address of our ssh server. On Unix systems (including Mac) this file is /etc/hosts. On Windows systems, the file is %SystemRoot%\system32\drivers\etc\hosts\ (usually C:\Windows\system32\drivers\etc\hosts\).
The second approach works on OpenSSH. OpenSSH allows the creation of "nicknames," which exist specifically to serve this function. To use this feature, create (or edit) the file ~/.ssh/config (on the client machine you will be connecting from, not ours!) and add content like this:
Host nfsnssh
Hostname ssh.phx.nearlyfreespeech.net
Port 22
With this done, you can use "nfsnssh" as if it were a hostname in ssh and its related commands.
A lot of other ssh tools exist, many with graphical interfaces that make establishing as simple as clicking, regardless of the hostname.
Moved to wiki.
Moved to wiki.
Moved to wiki.
Moved to wiki.
Moved to wiki.
Check out this wiki entry for details.
Moved to wiki.
Moved to wiki.
Moved to wiki.
Moved to wiki.