"Karekareraisu" has requested an account and is waiting for confirmation.
The e-mail address has been confirmed. You can confirm the request here "https://sudoroom.org/wiki/Special:ConfirmAccounts".
"Tlevine" has requested an account and is waiting for confirmation.
The e-mail address has been confirmed. You can confirm the request here "https://sudoroom.org/wiki/Special:ConfirmAccounts".
As I just mentioned on the discuss list:
http://lists.sudoroom.org/pipermail/sudo-discuss/2013-July/003061.html
We now have elevator access control.
The sudodoor and sudoor projects have been updated with new code:
https://gitorious.org/sudodoor/sudodoorhttps://gitorious.org/sudoor
The main changes are:
doorman.py and portal.html now has code to enable the downstairs elevator
call button. it does so for 20 seconds if you use the "unlock elevator"
button and for 40 seconds if you do "open outside door" (it of course still
opens the outside door).
opendoor.py now sends an https request to door.sudoroom.org to unlock the
elevator button for 40 seconds after the 5 second outer door unlock
sequence. This means that all code depending on opendoor.py should now also
unlock the elevator for 40 seconds.
Here's how it works:
A relay is hooked to the elevator call button on the ground floor. It is
inside of the wall. I spliced the relay into the intercom cable, since
there were some wires in that cable that weren't being used anyway. Two of
those wires now connect the relay to a 12 volt power supply in the bottom
left of the server/bio closet upstairs and via a mosfet to the raspberry pi
(tamale). It is also connected to a manual override just outsider of the
sudo room main door.
When GPIO pin 11 is set to high on tamale, then if the switch outside the
space is set to "access control enabled", the relay is triggered and the
elevator call button on the ground floor will be _disabled_.
If GPIO pin 11 is set to low, or the manual override is toggled to "access
control disabled", or the raspberri pi is off, or something gets
disconnected, then the call button will function as normal.
Again: The relay is default closed, so if no power is applied the elevator
works as normal.
The mosfet is screwed into the wall to the left of tamale.
A couple of things that need changing:
I had to change the /etc/init.d/doorman script to run the doorman.py
webserver as root since the python GPIO library wouldn't work otherwise. If
someone has a good idea for how to fix this, please do so!
I hardcoded a password in opendoor.py in the sudodoor project (don't
worry i didn't commit it with a correct password). It's late and I want to
go home. Sorry.
Thank you and good night.
--
Marc Juul
"Tlevine" has requested an account and is waiting for confirmation.
The e-mail address has been confirmed. You can confirm the request here "https://sudoroom.org/wiki/Special:ConfirmAccounts".
"Mitar" has requested an account and is waiting for confirmation.
The e-mail address has been confirmed. You can confirm the request here "https://sudoroom.org/wiki/Special:ConfirmAccounts".
Hallol
This is just a notice of changes made to the sudoroom.org server.
I set up a django app for mapping out the mesh nodes on the sudo room
server. It runs on port 8000 as the user 'nodeshot' and is reverse proxied
by apache for meshmap.sudoroom.org.
I did the following to set this up:
aptitude install git python-pip
python packages installed with pip:
Django 1.4.1
distribute 0.6.10
wsgiref 0.1.2
put nodeshot (a django app) here: /opt/nodeshot
added /etc/init.d/nodeshot
added symlinks to load the proxy and proxy_http modules in
/etc/apache2/mods-enabled
added /etc/apache2/sites-*/nodeshot
update-rc.d nodeshot defaults
--
Marc
"Chrisjx" has requested an account and is waiting for confirmation.
The e-mail address has been confirmed. You can confirm the request here "https://sudoroom.org/wiki/Special:ConfirmAccounts".
door.sudoroom.org is not responding to hails!
After not being able to contact it in any way, I did a hard reboot.
I am still not able to contact it.
It is 4 am, so I am going home.
--
Marc
We had a problem where someone installed a plugin that requires people to
request an account, and then a wiki admin has to confirm the account.
Unfortunately whoever set it up did not configure the plugin to send emails
to notify anyone of pending accounts. This has caused two accounts to be
pending, one since the 28th of May. I have confirmed these accounts and set
up the plugin to send emails to the sudo-sys list every time someone
requests an account and confirms their email address. I also patched the
ConfirmAccount plugin to allow multiple destination emails. To add email
addresses to receive these emails, change the $wgConfirmAccountContact in
LocalSettings.php. To view the patched code, simple grep for Juul in the
extensions/ConfirmAccount directory.
We also had a problem where no-one was being emailed about pending messages
for the sudo-sys list. I added myself and Jordan (hope that's ok, but
otherwise you know how to remove yourself). Other people can add themselves
via the mailman admin interface:
http://lists.sudoroom.org/mailman/admin
There is still a problem where the link to the mailman admin page is broken
from:
http://lists.sudoroom.org/
--
Marc
"TestingAccountRequest" has requested an account and is waiting for confirmation.
The e-mail address has been confirmed. You can confirm the request here "https://sudoroom.org/wiki/Special:ConfirmAccounts".
