Marvin P Droid

Marvin is the space automation and monitoring system.

If you just want a user manual without all the details see Access Control

Git

Code and configuration for the majority of Marvin's systems is stored in a git repository on github at http://github.com/leedshackspace/lhs-marvin.

Hackspace Server

The majority of Marvin's functionality is provided by the machine gateway.hackspace, which resides in the cab at the hackspace. The following services are provided:

• DNS
• DHCP
• Router spanning wired, wireless, external (internet) and VPN network segments
• Door lock master and logging
• Database
• Webcam motion capture and image feeds

Configuration

All configuration done via the ansible playbook and supporting files stored in the git repository. Manual changes should not be made to this system, it should be possible to rebuild everything from just the github repository.

User Accounts

External access to the internal hackspace network is via this machine. Accounts are available on application. Authentication is by SSH key only.

All user data on this machine should be considered transient and at risk of deletion. Do not expose sensitive data on this machine (or any other hackspace machine).

Secret Keys

Full configuration of the machine requires several passwords and secret keys not stored in the public git repository.

FIXME: Document where these live. (ask User:Pbrook)

DNS and DHCP

Care should be taken to ensure that DHCP and both forward and reverse DNS entres are consistent when making changes.

Internal DNS uses the .hackspace domain. It is implemented with bind9 on the gateway machine.

The wired subnet is 172.31.26.0/24, and the wireless subnet is 172.31.27.0/24. Addresses are assigned by the ISC DHCP server on the gateway machine.

RFID Access System

Access to the hackspace is controled by an RFID tag based system. It covers both the internal upstairs door and the external door shared with the Pedallers Arms.

Door Locks

Each door has an electronic lock, with RFID reader and a numeric keypad.

Each unit includes battery backup provided by 8x AA NiMh rechargeable batteries. These should be sufficient to keep the lock operational for several days. The batteries are trickle charged when external power is present.

The door locks communicate with the server using a custom serial protocol. Power (12v) and data (rs232) are supplied over a single 5-pin DIN connector. The cabling is the same as (but not electrically compatible with) a MIDI cable.

Logging, updating the list of approved tags, and other functions are achieved by communicating with the daemon on the server. The serial protocol is documented in the arduino source code.

The lock stores a set of RFID tag/PIN pairs in non-volatile storage. In the event of a server/power failure the lock will continue to operate automously.

The upstairs lock includes a second RFID reader on the inside of the room. This allows members to tag out as they leave.

RFID/NFC Cards

The cards work on 13.56Mhz and are MiFare Classic 1000 ISO 14443-3A standard compliant. These are usually purchased from aliexpress.

Auxiliary Arduino

The blue box on top of the server cab provides connectivity between the server and other systems. It contains:

• An arduino with temperature readings and MOSFET to control the space open sign. Historically this provided other functions, however these are no longer used, and probably broken.
• A pair of USB-serial modules with RS232 level shifters for doorlock communication
• USB hub. The serial devices do not have useful serial numbers, so are identified based on which port they are connected to.
• 12v 2.5A DC power brick. While average power draw is fairly low, peak power draw of the door lock solenoid is ~1A.

Space Open Sign

The illuminated sign at the top of the stairs is turned on when the space is open. The LEDs are wired to operate off a 12v supply.

Space management daemon (doord)

The doord daemon provides several functions:

• Control of door locks
• Control of the auviliary Arduino
• Scanning ARP entires to determine presence of machines on the network.
• Logging
• Opening and closing the space
• Database management for door locks and space state
• IRC messages

Space state logic

The space will open when the door is unlocked (this requires valid RFID tag and PIN).

When the space has been opened by a keyholder, any member can open the door with their RFID tag. No PIN is required.

When the space is open to the public the door can be opened by pressing '#'. Public access also requires the space to have been opened by a keyholder.

The space will close if the door is closed and no members are present (determined by network devices or recently scanned RFID tags).

Scanning a tag on the inside of the upstairs doorlock will caused that member to be immediately logged out. If there are no other members present then the space will close. Pressing the '*' key on the keypad within a few seconds will cause all members to be logged out, and the space to close immediately.

Public Open Days/Evening

A public open evening is hardcoded for Tuesday from 5pm. This assumption is present in both doord.py and gateway/www/status.php.

Other public open days can be added via the open_days database table.

In both cases public access is conditional on the space already being open, so it if nobody turns (or the keyholder is late) the building should still be secure.

External webserver

The external webserver for leedshackspace.org.uk lives in Nav's loft on the end of his DSL connection. This needs to be moved to a properly hosted system. A migration process in underway to move to a dedicated server, which is being documented in New VM Migration.

VPN

Connectivity between the machine in the hackspace (gateway.hackspace) and the external webserver (leedshackspace.org.uk) is provided by and OpenVPN tunnel. The tunnel is initiated by gateway. The VPN is used for querying doord running on the internal server for the space status for the IRC bot and website, and for proxying requests for webcam images.

IRC

The IRC bot is based upon irccat.

This is a horrible mess of xml configuration files, Java, and scripts written in a variety of languages. It also accepts messages via a TCP socket, which are then passed on to the IRC channels.

Marvin is mainly situated in /usr/local/src/irccat on the web server running on a VPS.

Parts of this bot are everywhere, the code is out of date, not currently version controlled and is in a (bit of a) mess.

The bot is setup to join #leeds-hack-space and #leedshackspace as Marvin_P_Droid on freenode IRC, with #leeds-hack-space set as the primary channel in the irccat config xml file.

IRC Bot Commands

Commands can be run from either the irc channel #leeds-hack-space or they can be /msg sent to Marvin_P_Droid.

Commands are directly executed from their script names, this is why you have to be careful what you put in the commands folder and it may be best to have a 'command' filename that just refers to other script file names that are stored in sub folders. They are stored in /usr/local/src/irccat/commands.

Most of these commands date from before we moved into our current space (Mabgate Green), and many of them are broken.

Command	Description
?status	Show whether the space is open, and if so, who's there
?rules	List the Hackspace rules
?space, ?mars, ?galaxy	Show how many humans are in space (and how many harpoons)
?phone	Show the Hackspace phone number
?moo	Have a cow reply to you
?harpoons	Show how many harpoons are in space
?idea
?noidea
?xyzzy	Magic