Laboratory 24/Network

From London Hackspace Wiki
< Laboratory 24
Revision as of 21:34, 25 February 2011 by 188.223.195.229 (talk) (→‎Servers: Again, made it look better.)
Jump to navigation Jump to search

Lab24 has a number of network points, wired across the false ceiling. These terminate in the dirty room cabinet.

See also Infrastructure and System_naming and Member_accounts.

The spaces dns zone is lan.london.hackspace.org.uk.

We have 172.31.24.0/23 on the chaos vpn range which we use the bottom half of (172.31.24.0/24) as the lan ip range.

Switches

  • 3com (always on), in the space dns zone as 'switch'

Routers

  • Bebox 192.168.1.254 (always on)
    • ADSL Router
  • Fonera 172.31.24.1 (always on)
    • Router, Access Point (bgn), VPN

Servers

  • Babbage IPv6 router (always on)
    • Gutenberg (HP LaserJet 1022), chared via cups (ipp)
    • runs the DHCP and DNS server and resolver
    • runcs cacti for monitoring vairous network things.
  • Bell The door/building management controller (always on)
  • Flowers The door/building management controller (always on)

Workstations

  • Lovelace Makerbot
  • Flowers Media PC (currently unused)
  • Laz0rs laser cutter (hackspaceremote/hackspace maps to password-less user hackspace)
  • Postel The SGI O2
  • Touch table PC

Outside Lab24: Turing Bitfolk VM

Working on the network

Members of the group can ask for access to the network, and with that, the ability to make changes to most of it. Of course, that level of access brings with it a need for consideration of what effect any changes that you make may have. Each piece of hardware should have it's own logbook page on the wiki, where all changes must be logged.

  • Updates - software updates should be listed in the relevant logbook page, with a listing taken of the proposed updates before updates are carried out.
  • OS upgrades - upgrading an OS is not a trivial task, and should not be attempted without thorough consultation and planning via the email group. (process needs defining)
  • Reboots - should never be carried out without at least 48hours notice being given via email and irc.
  • Services - each piece of hardware runs services required by the space, typically running in a screen session. These shouldn't be killed/restarted or changed without consultation. Should you want to add to the services within the space, this is done in conjunction with the space's git procedures (need defining on a new page).