access June 2015

access@sudoroom.org

5 participants
4 discussions

Re: [sudo-access] [sudo-discuss] Sudo Member Space Access procedure

by Jake

Hi Niki! I meant to respond when you sent a message like this awhile ago, regarding someone who refused to properly close the door after opening it. Before I talk about the technical situation, which I believe applies to this problem, I want to try to answer your specific question. The procedure for granting door access, when I do it, is by demonstrating how the unlocking and re-locking procedure works, and making sure people understand that they must re-lock the door after opening it. But of course sometimes people will forget, or worse, actively shirk their duty to re-lock the door. In the latter case, if a person refuses your request to re-lock the door they unlocked, I will electronically revoke their access until they explain themselves at the appropriate meeting. This would also be appropriate for people who repeatedly forget to re-lock the door after themselves. We have been working on the door technology a lot this last week, improving reliability. But we have been holding back on adding features because I understand that we are very close to replacing the front door. The new front door will not "unlock" and "re-lock" but will be the usual type of door which you "buzz" open, and when it closes it locks again. One of the features we can add in the meantime is a record of incidents when people use their card to unlock the door, and it does not get re-locked within 5 minutes. If the people are not members of La Commune, we will know to contact them for re-education. It's my understanding that we have received a permit to replace the front door, and that someone bottomlining that project has taken measurements. I do not know how long it will take or who is doing it, but this is why I have not changed the front door system to activate the doorknob instead of unlocking the pins. If it activated the doorknob instead, it would automatically lock when the door closed again. But it's a lot of work to do considering the door will be replaced very soon. Once again, if any person with electronic access is being irresponsible with unlocking the door, I am willing to de-activate their card until they come to the appropriate meeting to resolve the problem. And I will be more pro-active in reminding people to lock the door they open, and I will look into the access logging feature. thank you, -jake On Friday, Niki wrote: Hey friends, Can someone point me to where the procedure for granting new Sudo member access to the space is (if there is one?) The front door was left open by a Sudo member (no personal hard feelings!) and I just want to make sure that it's being communicated to members that the door should be closed and locked if no one is watching the front. I am working on an orientation pamphlet for folks who are new to the space (it's taking longer than anticipated!) so hopefully by the time we re-key, we'll have something more tangible to provide people. <3 N

9 years, 6 months

Re: [sudo-access] [omni-consensus] Need list of all members who need key access to the building!

by Jake

Hi Otis and Fluor, We are always improving the door system, and adding new features. At this moment the system only works on the corner door at 48th and Shattuck, and only works with magnetic stripe cards. Any member of your group who wants a keycard can contact me or the access mailinglist to set up your card. You can use any magnetic-stripe card like a creditcard, debit card, gift card, even if it's totally expired and you found it on the sidewalk. The door system will not write to the card, only read it. Unfortunately BART cards and hotel key cards don't work. We have a few cards you can use if you don't have one, but we're always looking for more to give out, so check your junk drawers for old cards. Soon we will be adding RFID to the card system, so you will be able to get in with a weird rubber watch thing, by holding it near the reader, and we have tons of those. But it's not ready yet. We will also be adding this type of system to other doors on the building, including the doors on 48th street, and to many inner doors of the building one by one (for example Sudoroom and CCL). the point is, people who want access should contact me or the access list to get an access card. thank you, -jake On Tue, 9 Jun 2015, Otis Pig wrote: > Timeless, Infinite Light members who need key access: > Emji Spero > Joel Gregory > Zoe Tuck > Paolo Yumol > > I believe that's everyone! > > On Mon, Jun 8, 2015 at 7:01 PM, Fluor Lara <fluorescentpeacock(a)hotmail.com> wrote: > Hi, Here's the list of collective member names for MPM. Sorry, I thought I had sent this before. Some of the members are pending, but solid enough that > by the time we get keys made they will be fully through our process. > > Still confused about the key card thing, if the plan is for it to be building-wide? Lara > > Lara Durback > Ian Dolton-Thornton > Emji Spero > Kate Robinson > Ava Rosen > Ali Meyers-Ohki > MG Roberts > Robin Babb > Simona Otyrba > John Schmidt > Hillary Savage > Willow Germs > Niki Shelley > Chloe Minervini > > > _______________________________________________ > consensus mailing list > consensus(a)lists.omnicommons.org > https://omnicommons.org/lists/listinfo/consensus > > > >

9 years, 6 months

trying to auto-start health.js

by Jake

on omnidoor, see /etc/init.d/doorhealth /etc/rc5.d/S18doorhealth -> ../init.d/doorhealth unfortunately, root@omnidoor:/etc/init.d# service doorhealth start Starting /root/sudobot/health.js /usr/local/bin/psy start --logfile /var/log/sudobot.log --name doorhealth -- node /root/sudobot/health.js path.js:360 throw new TypeError('Arguments to path.join must be strings'); ^ TypeError: Arguments to path.join must be strings at path.js:360:15 at Array.filter (native) at Object.exports.join (path.js:358:36) at Object.<anonymous> (/usr/local/lib/node_modules/psy/cmd.js:38:40) at Module._compile (module.js:456:26) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12) at Function.Module.runMain (module.js:497:10) at startup (node.js:119:16) however, running the same command at the commandline seems to work: root@omnidoor:/etc/init.d# /usr/local/bin/psy start --logfile /var/log/sudobot.log --name doorhealth -- node /root/sudobot/health.js no idea why this is. also, i renamed /root/doorjam-health to /root/sudobot in a vain attempt to reduce confusion. probably health.js should be called doorhealth.js since the command psy log doorhealth only works if the process --name is doorhealth... substack, did you have anything trying to auto-start health.js on omnidoor? because Marc and I made this to do that, since sudobot just complains continuously until it can get ahold of "doorhealth"

9 years, 6 months

Update on omnidoor

by Marc Juul

Last night substack and myself hacked on door access. The door computer was down and it looks like some minor filesystem corruption. substack fixed the problem with help from yar. It may not have been anything serious. A breaker had tripped and maybe the filesystem was just in the middle of a write when the computer lost battery. smartctl reports no major problems with the harddrive. I worked on getting a beagle bone black set up with doorjam to replace the laptop. I had some troubles so I didn't quite finish, but it's pretty close. It is running a modified debian I put it inside of the vending machine with the poster on it, toward the bottom. The box actually says "vending machine beagle bone" which is false. Feel free to continue working on it, but read /root/INSTRUCTIONS before use. If you have access to omnidoor.local you have access to this beagle bone. The easiest way to talk to the bbb during development is to hook it up using a mini-usb cable. It will power on and you will see that you suddenly have a new network interface with the IP 192.168.7.1 and you can now ssh into the bbb at 192.168.7.2 (you will also get a storage device attached when you plug it in, but just ignore that). It is set up with Debian 7 (we can move to the new version when the beagle bone developers move to it) with the /boot and / partitions residing on the internal flash memory. It is configured to run with read-only /boot and / partitions. The micro-sd card should be where all writable permanent data resides. That means the access control list (and maybe the logs?) The micro-sd card is mounted at /mnt/sd_card by the /etc/init.d/doorjam script I have gotten to the point where everything is installed but doorjam has not been configured to store its data on /mnt/sd_card Other ToDo items: * Make script for hardware watchdog ** Maybe interface watchdog script with irc bot? * Mount it in nice box near door * Give it battery backup -- marc/juul

9 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

access June 2015