Server Hosting

We have a server rack in the store room, and members may colocate one server.

Each member can use 1-2U of full-depth rack space, or some shared shelf-space for small ARM systems.

Hacklab's internet is provided by Fluency. Each member may use:

• at least one public IPv4 address (from 209.16.157.0/24)
• many private IPv4 addresses (from 10.38.41.0/24)
• lots of public IPv6 addresses (from 2a04:5d00:70:1::/64 or 2a00:a600:6:1::/64)

Although our power usage is not metered we still have good reasons to limit consumption:

• our landlord has to pay for it so we don't want to be a burden or to use enough to be noticed
• power turns into heat, which has to be vented or air-conditioned out of the store room
• it's ecologically unfriendly to use more than we need

When choosing a server, consider the amount of power that will be consumed and the amount of use that will be made of it. Many personal servers will be idle for a lot of the time, so a modern server with good power saving features would be desirable. Better still, get a low power Atom, Xeon-D or ARM system (e.g. Raspberry Pi).

BE AWARE THAT POWER-HUNGRY SERVERS MAY BECOME UNACCEPTABLE AT SOME POINT IN THE FUTURE. DON'T SPEND MONEY ON THEM.

Virtual machines are available on titanium. See virtual_machines for details.

We don't have an official acceptable use policy at this time. Members should avoid illegal activities and consider whether their content will attract unwanted attention or damage Hacklab's reputation.

As a guide, anything that a normal hosting provider would allow should be okay. If your application or content would cause problems at another provider then you should discuss this with directors or the membership first.

Tor has been discussed previously and there were a number of arguments on ethical and reputational grounds, both for and against running nodes. A consensus has not been reached on the matter. Further discussion would be required before running a node.

Hacklab may retain netflows (network traffic metadata) for up to 30 days, for the purpose of investigating network abuse reports.

• Ask to be added to the colo group, which will give you access to NetBox.
• NetBox:
  • Check the list of device types, and create one if your hardware isn't already listed.
  • Create a device entry for your server and record the location where it will be installed. For non-rack devices, the server will usually go on the shelving.
  • Allocate public IPs from the Server LAN (one IPv4 per member, but as many IPv6 as needed) and link them to the device.
  • Allocate a switch port in ehana and ask a sysadmin to connect the interface on your server to the port on the switch in NetBox.
  • If you're using incoming/outgoing SMTP then refer to smtp to allow this traffic (which is blocked by default).
• DNS:
  • Local DNS: is driven from NetBox data.
  • Internet DNS: forward entries are up to you, reverse entries are managed by NetBox. (Fluency IPv6 reverse DNS has to be requested manually via Texaport.)
• Install:
  • Rack devices should be installed securely. If you don't have rails, get permission to stack on another person's server and don't stack multiple unsecured servers.
  • Route power cables at the right-side of the rack (view from the rear) and use cable ties to keep them neat and tidy. If you have dual PSUs, only connect one of them (dual PSUs will use more power, and there is limited benefit as we don't have independent power sources).
  • Route network cables to the left-side of the rack and connect to a Server LAN port. Record the port used in NetBox or EHANA (depending on the switch). If a new port needs to be configured, ask someone who is familiar with the switch to help.
  • If the shelving is used, then use the switch and power strips on the shelf. Tie your cables neatly.
  • Label your server with your name, and the server name (matching the one in NetBox).