Considerations When Accepting Bandwidth Donations?

dnotj asks: "I'm involved in a project that is growing fast and is going to soon outgrow it's current hosting location. I've had a couple of offers for donating bandwidth (and servers in one case). Basically free colocation or dedicated servers. Since this isn't a revenue generating project, it's going to be necessary to migrate this project and it's related website to a location with adequate bandwidth. What kinds of questions should I be asking these generous organizations that make these offers? I just want to make sure I cover all my bases before jumping on one of these offers."

Comments

Did you say FREE?

[HRbnjR]

"Where do I upload my files to?" :)

Why jump on one offer?

[anthony_dipierro]

Why not accept all the offers?

Re:Why jump on one offer?

[SpaceLifeForm]

Really. Mirrored and ready for the /. effect.

The basic legalities...

[gabraham]

First things first: Ask them what, if any, conditions there are to their "gifts".

If they are providing the hosting or bandwidth, be sure to read the small print! Make sure that you aren't signing away any rights that you might care about. I'm not just talking about copyrights and trademarks, I mean things like the right to publish your work elsewhere, change hosting services or servers at any time, how and when access is provided to the server, if and when backups are done (started/completed), what you can expect in case of an unacceptably long downtime, etc.

Strings?

[Zapper]

Are there any conditions that come with the offer?
For instance, having to run advertisements and other such stuff.

load balancing

[a.koepke]

What I would do is accept them all and setup each server as a subdomain. (www1, www2, www3 etc)

Where the main domain resides is an account that is in your control and redirects the request to one of the other servers.

This way if one goes down you can simply remove it from the list of mirror servers. It also maintains you in control of the setup instead of giving one person 100% control of the site by putting it on their server.

Re:load balancing

[KILNA]

The free service (up to 5 domains) at ZoneEdit would be helpful in conjuction with this strategy. I've been using the service for a while now and though the site isn't much to look at, I've never had a DNS outage with them.

Re:load balancing

[cynicalmoose]

or use Google's technique of expiring the DNS lease on its ip every 5 minutes (so the DNS servers go back and get another ip from Google), which then reassigns a different oene

Free is sometimes expensive

[eXtro]

Make sure that you can trust the person who's offering the bandwidth. Beyond that it'd be even better if you have somebody who lives near by who can physically pull the plug if need be or rescue any hardware. I took up a free hosting offer. My equipment and code was stolen (by the Chris Kuivenhoven mentioned in my .sig)

Re:Free is sometimes expensive

[Anonymous Coward]

You didn't have a backup for your code? Moron.

How Much

[miyako]

beware of something like "well give you 1Mb/month of free bandwidth for you project with a cost of 99.99 per byte over 1Mb
also look at stability, is this a service that is going to be going up and down, or might just disappear suddenly.
As others have said, you should also be sure that you are not prevented from posting your content on any other sites.
If you are worried about ads, you should also look into that

Will they own your site?

[AvitarX]

and all content ever created for it (even the content you don't own yourself).

Linux Gazette forgot to ask those questions ansd it did not work out to well for them

Just make sure...

[stienman]

Just make sure that they don't force you to keep your current site layout and colors for the duration of the hosting - remember, green can go out of style...

Oh, wait, you aren't talking about slashdot? Nevermind then...

-Adam

The same as paying for it.

[DDumitru]

You should ask the same questions and perform the same due-dilligence as if you were paying for the service.

o Keep you own backups of your site out of the hands of the hoster.
o Make sure that any contracts you sign keep your stuff yours.
o Keep your domain names under your control.
o Have a contingency plan in case things don't work out.

If you were paying for service, you would probably be asking for SLA and reviewing technical details about the hosting plant. With free service, it is a bit harder to ask for too much. Plus, how much of a rebate do you want against zero.

Once you are up and running, be sure to give the hoster appropriate thanks and credit. A link on your home page is probably the least you should do. Also, don't do things that cost the hoster money and/or aggrevation. Be self-sufficient with your servers and applications. Use the bandwidth that you are getting sparingly. Don't overdue the photos and graphics. Just because you are getting something for free doesn't mean you should use as much as possible.

Also, try not to attract riff-raff with your project. You are getting stuff for free. Returning the favor with a DDOS attack is probably not the best idea.

Look out for number one!

[Bald Wookie]

Get a ton of stock options and a time machine to 1999.

Realistically, make sure you have rights to access your data if they ever go under or quit hosting your project. Waking up to 404's and no backups is not much fun. See if they'll give you at least one month notice if they ever decide to quit. Then you'll have a much better time of migrating somewhere else. Other than that, it's a gift, don't expect to be able to make too many demands. Make your requests for "the good of the project" which should be your primary concern here anyway.

Keep the domain name YOURSELF.

[TheSHAD0W]

Make sure you're the owner of the domain name from the start. Use another service, such as mydomain.com or the registrar's own service, to point the domain at the server. Do not use an email address within the domain, or within any other domain under that entity's control, as a contact for the domain.

By taking these precautions, should that entity ever start misbehaving, you'll be able to move your content to another server without too much disruption.

Exchange

[rf0]

Whilst its nice that some people offer free hosting (and we do for a couple of projects) ask what they are getting in return. Some companies are happy with a text link saying "hosted by ...". However watch out for popups.

Then again hopefully most hosts can be trusted

Rus

The IRS

[raisinets]

Bandwidth donations are taxed. I did some guy's tax returns last year and we calculated he lost almost 100 per month on just a T-1 line.

J

Re:The IRS

[Anonymous Coward]

This guy's a troll.

Check out his other posts.

Re:The IRS

[Carnildo]

So you're a tax accountant in addition to being a middle manager at Honda and one of the designers of the iPod?

My Question

[vigilology]

"Is P2P legal in your country?"

Stuff to think about

[ajs318]

If you are just getting bandwidth, and they want to foist banner ads on you, make sure that the advertisements will come from a different IP address than your server, so your customers can block them. They want to see your editorial content, not adverts.

If you're getting hosting, make sure you get a full-blown service. A certain British cable company {clue: not Telewest} promised me 10MB, five IP addresses and my own cgi-bin when I signed up for their broadband service. Turned out they meant five e-mail addresses {not even proper virtual hosting}, one dynamically-assigned IP address that does not give me the hostname I ask for {seems to last >6 months at a time though}, and no cgi-bin - not even a shared one. They did up the offer to 50MB of space, but with neither Perl nor PHP it was slightly less useful than a chocolate fireguard {at least you can eat a chocolate fireguard}. Fortunately, their IP addresses do last awhile, so I was able to get someone to point an A record to my home server for me.

A full-featured site should include at least two scripting languages out of Perl, PHP and Python; a database {MySQL for speed or PostgreSQL for real database features}; and an AllowOverride setting liberal enough to let you specify most things in your own .htaccess file. You should have access to error.log and it's also nice if the user "nobody" {or whatever user name CGI scripts run as} has access to it -the then you can use a script for an errordoc 500, like this:

#!/bin/sh
echo -en "Content-type: text/plain\n\n"
echo -en "Your script went tits-up. Herewith its last words, as they drift along the wind to sweet oblivion:\n\n"
tail -n50 /var/log/httpd/error.log

A bash prompt is nice but not essential {you can often use the #!/bin/sh trick to get around its absence}.

Basically, you want everything except root access. {There are only three ways to get root access on an ISP's machine: work for an ISP, be related to someone who works for an ISP, or save the life of someone who works for an ISP}.

Of course, if you're getting a full server to yourself, then you do want root access; ideally, you should actually install the OS yourself, so you know it is not trojanned. You should also have the ability to make a phone call to a human being and have the machine reset {it must be a human being, because fsck sometimes needs the root password if it wants to do anything hairy}.

Be Careful

[Anonymous Coward]

Some people have different notions of what a 'fat pipe' is.