In Brief¶

1. Create a local_settings.py that contains any values you want to override from settings.py.

2. Install your dependencies:

   $ pip install -r pip-requirements

3. $ ./manage.py syncdb –migrate

4. Go nuts.

The default settings use sqlite3 as the database, with /path/to/spiff/spiff.sqlite3 as the file.

Common Environments¶

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'spiff',
        'USER': 'spiff',
        'PASSWORD': 'hunter2',
        'HOST': '',
        'PORT': ''
    }
}

<VirtualHost *:80>
  LoadModule wsgi_module modules/mod_wsgi.so
  WSGIScriptAliasMatch ^/auth(/([^~].*)?)$ /usr/share/spiff/spiff/wsgi.py$1
  Alias /auth/static /usr/share/spiff/spiff/static
  WSGIPassAuthorization On
  WSGIDaemonProcess spiff-1 user=apache group=apache threads=25
  WSGIProcessGroup spiff-1
</VirtualHost>

Configuring your Space¶

To rename your hackerspace, configure the only available Site object in the Django admin interface. If you have more than one Site object, configure one to use the correct domain name, delete the others, and optionally let the developers know how it got there since Spiff should only ever have one.

Other properties are configurable through the SpaceConfig object in the Django admin UI:

Membership¶

Spiff provides a basic system for staff to manage a member database, self-service membership management, and accepting dues via Stripe.

Each member has a few basic fields that should be filled out:

• Email
• First Name
• Last Name
• Birthday
• Profession

These fields are public to the general internet, except for hidden users.

Administrators can add extra fields such as phone number, mailing address, emergency contact information, etc. These extra fields have three flags available:

• Required - The profile will not save and a user can’t register without this field being filled out. Examples: emergency contact information, digital signature proving they read the rules, preferred objective description of the color #33ff62.
• Public - Other members can read the field, but not the entire internet. Members can edit their own public fields. Fields that are not public can still be read by those with the can_view_private_fields permission. Examples: IRC nickname, membership sponsors, or exact reasons for disliking ABBA.
• Protected - Only those with the can_edit_protected_fields permission can view and edit the field. Members can read the value of their own protected fields, but can’t edit them. This is useful for things that members should know about themselves, but others shouldn’t know about others, and members shouldn’t be able to change. Examples: a key/RFID token ID number, a note proving that they signed a liability waiver, a third meta-item that points out this is the third item in the third list of lists of threes and thus three times as funny.

Resources¶

In every hackerspace, theres a bunch of equipment sitting around that not everyone might know how to use or even what it is called. Spiff solves that problem.

You can create a Resource object in Spiff for each real-world resource. After it is created, metadata can be attached to it and edited by users with the correct permissions. Members can also keep track of their training on the site, along with their relative skill ranks.

Users require the inventory.certify permission to be able to add and remove certifications from members.

Skill ranking works on an honor system that requires users undergo a vetting process by other users:

• Your hackerspace acquires a nice new lathe.
• A member adds the lathe to the database, prints out the QR code and sticks it on the machine.
• Another member who happens to be a master metalworker sees that there is a Lathe, scans the code (or visits the resource page) and clicks “I have used this!” to indicate that they have used a Lathe at some point in their life.
• A second member (who is a total newbie to metalworking) also clicks “I have used this!”. Spiff says that both the newbie and the master are ranked at the same skill level, so they click “They are better than me”.
• Spiff now indicates that the master is better trained at the lathe than the newbie and sorts them accordingly.

At no point can the newbie say that they are better than the master without the master explicitly promoting the newbie to their level. Additionally, the newbie can’t demote the master. Members are ranked relative to each other based on this feedback system.

Not all resources in a hackerspace are trainable! For instance, it makes no sense to say that someone is more skilled at using the classroom or meeting area. When creating a resource, you can specify if a resource can be trainable or not.

Events¶

Spiff also allows for tracking of events. Anyone with a proper permission can create an event (and later edit it). Members can easily RSVP for an event with a link on the event page. There is no special permission required to state that you are attending an event.

If an event requires the use of some resource (which could be a classroom, or maybe its a class on using the lathe), it is possible to reserve the use of a resource by adding it to the event. This reservation system is purely an advisory one at the moment. Nothing will stop someone from reserving an already reserved item, or physically blocking you from using it.

Events can have multiple organizers, who are able to edit an event’s description and reserve resources. Organizers may only be added or removed by the event creator.

Sensors¶

See Sensors for complete documentation.

Management Commands¶

There are a number of management commands available through manage.py.

list_members

Lists the email addresses of active members. At SYNHAK, we pipe the output of this through to mailman’s sync_members script to subscribe active members to the members only list.

stripe_sync

Currently useless. Will soon be used to support automatic billing and advanced invoicing through Stripe. It creates a Customer in stripe for each Member in Spiff.

permission_list

Lists all permissions in Spiff and Django.

auth.change_user¶

The user can edit the profiles of other users.

auth.delete_user¶

The user can delete other users.

events.add_event¶

The user can create events and edit their own events.

events.can_reserve_resource¶

The user can attach resources to their own events.

events.change_event¶

The user can edit other user’s events. This along with can_reserve_resource is required for being able to attach resources to events that they don’t own.

inventory.certify¶

The user may grant and remove certifications for resources from members.

inventory.change_resource¶

The user can add and modify resource metadata.add_metadata, change_metadata, etc are not used at all in Spiff.

inventory.can_train¶

The user can promote other users’ trainings and add themselves to a resource at the lowest level.

membership.add_duepayment¶

The user may add previous due payments to Spiff.

membership.can_change_member_rank¶

The user may view modify the ranks a member belongs to.

membership.can_edit_protected_fields¶

The user can edit and view profile fields that are protected.

membership.can_view_hidden_members¶

The user is able to view members that have the hidden flag set.

membership.can_view_member_rank¶

The user is able to view another user’s ranks.

membership.can_view_private_fields¶

The user can view any field that does not have the Public flag set.

Boolean Sensors¶

Spiff’s REST API translates certain values into native values for requested serialization formats, and for the Open Sensor.

Accepted values that mean false:

• The string “false” (case-insensitive)
• The string “0”
• An empty string

Anything else is interpreted as true.

Pamela¶

Pamela is described as a “very cool way to visualize any kind of data”. You can find it at http://www.hackerspace.be/Pamela

Spiff is totally 100% compatible with Pamela’s basic API.

To use pamela’s ARP scanner with Spiff:

$ ./pamela/scanner/pamela-scanner.sh -i "eth0" -o \
    "http://example.com/sensors/1" -t mac.csv -d \
    "/var/lib/dhcpd/dhcpd.leases"

Please see Pamela’s documentation for more details.

Sensor Actions¶

Spiff can do stuff when sensors are updated. There are 4 kinds of actions that can be added via the Django admin interface:

• http: Sends a HTTP GET request to the given url
• exec: Runs a command via subprocess.call_
• python: Executes some python code. A spiff.sensors.models.Sensor object is available in the ‘sensor’ variable.
• script: Writes a blob of text to a temporary file, performs chmod +x, and runs it.

REST API¶

Documentation is forthcoming. Check out /v1/?format=json in your browser for some hints.

General purpose information about the space is available by fetching /status.json, as per the SpaceAPI.

Deprecated REST API¶

Spiff’s versioned API addresses a number of shortfalls in the previous API:

• It was a bear to maintain
• Didn’t implement a number of important features, such as result pagination
• POSTing updates had limited authentication control

Just about everything in Spiff is accessible through REST. It is as easy as adding .json to the end of your URLs:

$ http://example.com/sensors/1.json curl http://localhost:8000/sensors/1.json { “description”: “A list of devices in the space”, “name”: “pamela”, “value”: { “stamp”: “2012-10-31T15:28:53.901053+00:00”, “sensor”: “#Sensor#1”, “id”: 6, “value”: “{‘test’: true}” }, “id”: 1

Due to the cyclic nature of the database, some values are references to other objects. This is indicated by the syntax “#Type#ID”, such as “#Sensor#1”.

Other serialization formats may be added later if there is enough demand.