I just ran an apt-get update && apt-get dist-upgrade on the server,
seeing 24 of 28 updates were security-related. Initramfs was updated
and a new kernel image / headers were installed. I doubt this will
affect anything negatively, as I think everything installed is through
the package manager and we don't have anything we compiled against the
old headers.
Bill
OK i'd like to start making some changes to get this resolved. or else our
Wiki will be eaten alive.
Can someone contact KingJacob(a)gmail.com who knows him and have
him approve the SSL authentication request.
I believe SSL will slow down the amount of spam we're getting.
I'd like to install CheckUser so we can pull the IP Addresses of the spam
accounts and possibly start blocking requests from those IPs.
Objections? Suggestions?
I'm totally open!
-Wolfy
So I'd like to just buy us an SSL, donation style.
Can someone who knows kingjacob(a)gmail.com ask him to accept the domain
verification when it comes up?
-Wolfy
hey all,
I'm willing to donate my old smart phone or procure others in order to
create RFID-style interfaces for the doors.
We also need some simple central identity management tool (google docs
ain't gonna work for this one).
I think we should host a weekend hackathon soon and get this done. ;)
// Matt
Hiya sudo-sysadmins!
First off: Sorry for this exceedingly long mail. Here's the summary:
We set up the .sudo domain and a few new web services + a new mesh
access point router for 510pen. Included is also an explanation of the
outer door access system and what still needs to be done.
I should have been sending mails incrementally as I was doing stuff,
instead of one huge mail like this. I'll try to do better in the
future.
--
I set up wolfie's proposed .sudo domain on the DNS server running on
space.local, and pointed space.sudo and *.space.sudo to the
space.local machine (192.168.1.3).
Since mDNS and DNS can't co-manage .local, it makes sense to have
normal DNS manage .sudo and mDNS manage .local.
If you point a web browser to http://space.local or http://space.sudo
you will get the same page: A simple html page with links to local
services. For now it has things like:
http://track.space.sudo/ (qr-code item tracking)
http://pad.space.sudo/ (etherpad lite)
http://lib.space.sudo/ (library genesis, setup in progress)
http://map.space.sudo/ (tidepools decentralized map, setup in progress)
These services are all hosted via apache, but some (track, pad) have
built in web servers, so apache is acting as a reverse proxy.
I thought about making the domains like pad.sudo instead of
pad.space.sudo, but I think it's nice that the domain names tell you
which computer the services are hosted on.
I want to improve the http://space.sudo/ overview page in two ways:
1. I want to make it pull the static list of services from a wiki page
so that everyone can edit it, but it will still be up when the
internet or sudoroom wiki is down.
2. I want to make it dynamically list zeroconf services that are
currently being announced on the network.
Regarding outer door access: I had to partially disassemble the door
and drill a few holes to put in the wire, since the door did not have
any built-in wiring channels. The electric strike is mounted in the
fail-secure mode (as opposed to fail-safe), which means that it will
stay locked if the power fails, and power is required to open the
door. This is desirable because the push-bar on the inside of the door
mechanically overrides the electric strike, such that you can always
get out, even when there is no power, and likewise the key will open
the door from the outside without power.
The box next to the outer door contains a 12 volt AC power supply
which is hooked up to the electric strike in the door, and controlled
by one of the GPIO pins on a raspberry pi. The raspberry pi is running
raspbian, and control of the GPIO pin is handled with a python script.
A usb wifi adapter is connected to the raspberry pi and set to run in
master mode (access point mode), with the ssid "sudodoor". A so-called
captive gateway is running. It's based on dhcpd and two python
scripts: One is a simple DNS server that resolves all queries to the
(static) IP of the raspberry pi's wifi interface, and another is a
simple web server that asks for the secret password. If the correct
password is entered, then the door opens. The user never gets
"through" the captive gateway.
This is highly insecure, since the password is transmitted in
plaintext as a simple URL get request over an unencrypted wifi
connection. It also sucks because there is only a single password for
everyone instead of per-user passwords, and because it takes way too
long go through the process of entering the building, and because you
need a laptop or smartphone, and you need to wave around your laptop
or smartphone in what is not the safest neighborhood and lastly
because there is no battery backup so you cannot enter without a key
if there is no power.
I'd love to see three new access mechanisms: Magnetic stripe card, pin
entry and RFID.
Preferably, magnetic stripe and rfid should not be stand-alone access
methods, but should be combined with pin entry.
I'll likely put in an RFID reader within the next two weeks, but the
other two methods require a wired connection to the outside of the
door. I don't want to drill more holes in the door, so we need a hole
through the wall. We need to talk to George (the landlord) about this.
The sudodoor computer is not connected to the internet. Matt Senate is
coordinating with George (the landlord) to run two ethernet cables
from the door and up to sudo room. Once this happens, we will be able
to set up a system for per-user passwords. We don't have any plans for
any of this. If you have any ideas and want to work on it: By all
means throw an email on this list, or talk to someone at sudo room, or
just implement a solution and tell someone about it.
We also need to put in a simple method for sudo room and a couple of
the other tenants to buzz in people. Helping the other tenants get
this system working was part of the agreement that got us a new
electronically controllable door for free. It would be great if this
buzzing-in solution does not rely on the network or computer being
operational, such that it is very resistant to failures (leaving sudo
room with less time spent on support for other tenants). I imagine a
small timer chip connected to the door circuit and a long wire going
to each of the tenants, with a button attached. One press will trigger
the timer and open the door for e.g. 3 seconds. I'm not sure what to
do about the intercom/phone system. I don't know who set up the phone
in sudo room. We'd at least need to add a button on the street for
each tenant so all phones don't ring every time.
We also need a better box and cable management than the current
carboard+duct-tape solution :-)
We also really really need an off-site and off-line backup system for
all servers in the space.
Lastly, Mark Burdett put up a mesh router as part of the 510pen
(five-one-open) mesh initiative. It's on the shelf above the server
closet (with all the old telephone wiring). It may not yet be
operational.
Also: If any of you have one or more wifi usb adapters that you'd be
willing to donate to the mesh initiative (or maybe you want to join
the mesh group?), please contact me! We need them for testing and for
the first rooftop link.
Thanks!
--
Marc Juul
Last night I installed a mesh router, which has a "510pen - sudo room"
network. Up to sudoroom if you want to keep it here, but if so, the 510pen
mesh network is locked on channel 5 (so routers can easily find each
other). Therefore, to minimize interference, it would be good to set other
wireless routers to other non-overlapping channels, e.g. channel 11. Looks
like there is a router on channel 6 which would overlap and cause some
interference.
If sudoroom doesn't want to use this mesh router, that's fine, we can
easily find another home for it - just talk to me or email
mesh(a)lists.sudoroom.org
--mark B.
