As the Red Bean community grows, so do the pressures on the server and its administrator. This document discusses how we can insure the sustainability of Red Bean and the sanity of its administrator(s). It also describes Red Bean to new members, who may have received only an incomplete introduction.
In the mid-1990's, a couple of friends grew weary of having their email address change every time they switched jobs or schools. Their solution was to create a special domain to be their permanent home on the Internet. This domain would never be associated with any formal institution or product, so there would be little danger of its ever disappearing or being sold to someone else. Thus began red-bean.com.
As time went on, their friends realized what was up and, thinking it a good idea, joined the party. Red Bean's range expanded too: web pages, mailing lists, software repositories, anything requiring a stable address and continuously online server. All this made Red Bean a happy place to be, but it also brought the usual problems of managing a shared resource. This document describes the policies the cooks (the people who have root on the server) have consensed on.
The short answer is, use your judgement.
The long answer is, try to behave in Red Bean the way you would as a trusted guest in the house of a good friend. You don't need to ask permission to hang up your coat or make a sandwich. You might check before changing the position of a painting, though; and you would definitely ask before inviting a new guest to stay the night.
If you're skilled in carpentry, your friend would probably appreciate your offer to fix the leaky roof -- but remember, he'd like to know what you're planning to do before he comes home one day and sees you on top of the house hammering away.
It may not be immediately obvious how to translate this metaphor into a policy for network server usage. In anticipation of this contingency, we have prepared the following guidelines:
|
|
If you didn't understand what all of those meant, don't worry. Just try to observe the ones you do understand. Especially:
NEVER serve illegal content from any domain hosted on the Red Bean server, neither directly nor via BitTorrent or any other peer-to-peer sharing software. Serving illegal content places the entire server at risk: our network connection could be cut off, and our hardware could even be seized, as part of a legal action.
Also, please bear in mind that some people actually have to get work done on the server, and overloading system resources (including disk space) would impede them. Be gentle.
And always remember the Prime Directive: the domain must be preserved. Don't do things that might attach commercial value to the name "Red Bean". Distributing content (software or otherwise) is encouraged, but if it starts looking like the content might be worth money, it should get its own domain. Advertising products or services is a no-no; linking to a commercial website is okay, but don't advertise red-bean.com as a business's primary site.
The reputation of the server to send email without it being considered spam is another important shared resource. Be considerate of this if setting up any new mail flow. The above request to not forward email without asking, other than via Exim, exists to warn people away from accidentally bypassing spam handling mitigations.
You can run an activist or controversial web site/service here, as long as there is no demonstrable risk to Red Bean, and (of course) as long as the Red Bean name is not associated with it. "Demonstrable risk" means it's clear how the activity puts the server itself at risk. For example, if someone were to serve out copyrighted content without permission, that would be demonstrable risk — one can point to the statutes that prohibit it, one can point to the case law that shows how the server machine itself may be confiscated, etc. Merely serving up opinions that many people might disagree with does not consititute demonstrable risk, but remember, this policy can also be modified retroactively, if cooks are unhappy with how the server is being used. There may be such a thing as a free lunch now and then, but there is no such thing as a permanently guaranteed free lunch. If you're not sure whether a particular use of the server is appropriate, please discuss it on cooks@red-bean.com first.
Rebooting the server is potentially disruptive to others.
Our old physical server must never be rebooted without extensive planning. We have no means to intervene in a timely fashion if it fails to come back on the network, which we consider to be a significant risk.
Our new VM benefits from far faster reboot times (around 1 minute), and remote intervention via VM management interfaces. Therefore, whilst reboots should still be minimized, rebooting to apply system security updates that require it is considered appropriate.
Follow this procedure:
Users are welcome to run persistent sessions e.g. by using 'screen', but should expect these to occasionally be terminated by system maintenance reboots without explicit communication.
There is (or so we've heard). Red Bean is not just a set of rules; it is a community that depends on the willingness of its members to pitch in. The following tips can help you help everyone:
Finally, enjoy yourself and say hello to the others! If you've found yourself with a Red Bean account, then there is surely a chain of acquaintance leading from you to any other member. What's your deal?
Postamble
If you have material to add to this document, please go ahead; check on the cooks@ mailing list first if you think you should. Please see also:
If you're one of the administrators, there are various documents - including a record of technical policy decisions - in the maintenance area that might be of interest, including the 'cooks' mail archives. The maintenance area requires a password. If you don't know it, just hit Cancel when prompted, and you will be presented with instructions for obtaining the password.