[Noisebridge-discuss] [Rack] minotaur is down

Henner Zeller h.zeller at acm.org
Mon Jul 8 06:10:49 UTC 2013


On 7 July 2013 22:47, Jonathan Lassoff <jof at thejof.com> wrote:

> Now that I'm sure the baron->API->gateman request flow is good and
> working, I stoppe by 2169 to check functionality.
> I dialed a working code, and engaged the buzzer. It seems to be latching
> now, which is good.
>
> However, the hardware lock is in a somewhat precarious position...
>

Hard to tell from the picture: is the lock missing ?
There were reported problems with the lock earlier (key didn't engage), so
maybe someone removed it to get some replacement ?

-h

>
>
>
> On Sunday, July 7, 2013, Jonathan Lassoff wrote:
>
>> I should add a little more detail:
>>
>> Work is happening in the baron repo:
>> https://github.com/noisebridge/noisebridge-baron/commits
>> the gateman repo: https://github.com/noisebridge/gateman/commits
>>
>> And in the git repo in /etc on minotaur.
>>
>> To see the status of the barons, run:
>>   sudo monit status baron_upstairs
>>   sudo monit status baron_downstairs
>>
>> "status" can be replaced with "stop" and "start" to do that to the
>> baron instance.
>> The baron.py script now daemonizes and writes a pidfile to
>> /var/run/baron_[instance].pid, where "instance" is an instance name
>> passed to the daemon with "--instance" (e.g. "downstairs").
>> By default the instance is "default".
>>
>> Hope this helps! Just needs to be tested! :p
>>
>> Cheers,
>> jof
>>
>> On Sun, Jul 7, 2013 at 7:46 PM, Jonathan Lassoff <jof at thejof.com> wrote:
>> > Ok, so, I added some monit configuration for the baron daemons, and
>> > now everything will start automatically.
>> > Monit will be a watchdog for the processes, re-starting them if they
>> fail.
>> >
>> > Cheers,
>> > jof
>> >
>> > On Sun, Jul 7, 2013 at 12:05 PM, Jonathan Lassoff <jof at thejof.com>
>> wrote:
>> >> On Sun, Jul 7, 2013 at 11:59 AM, Henner Zeller <h.zeller at acm.org>
>> wrote:
>> >>> On 6 July 2013 02:26, Jonathan Lassoff <jof at thejof.com> wrote:
>> >>>>
>> >>>> First, gateman needs to come up.
>> >>>>
>> >>>> I'm stuck interacting with the parallel port as a parallel port :(
>> >>>>
>> >>>> open("/dev/usb/lp0", O_RDWR)            = 3
>> >>>> ioctl(3, PPCLAIM, 0x7fff85442ba8)       = -1 ENOTTY (Inappropriate
>> >>>> ioctl for device)
>> >>>
>> >>>
>> >>> It is one of these USB -> parallel port adaptors, so might not be 100%
>> >>> compatible with a 'standard'  parallel port.
>> >>> However, writing bytes to it should still work (if I understand
>> correctly,
>> >>> there is only one bit used to operate the buzzer ?)
>> >>
>> >> Yup -- those adapters/port emulators aren't good for any bit-banging
>> >> operations that are timing-dependent.
>> >>
>> >> I took the conversation onto the rack@ mailing list.
>> >>
>> >> I ended up figuring out what was happening, the driver presented two
>> >> interfaces, one as the raw port and the other as a line printer. I was
>> >> using the line printer interface, and not the raw port access.
>> >> We're all good (other than the downstairs buzzer hardware being
>> broken) now.
>> >>
>> >> Cheers,
>> >> jof
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noisebridge.net/pipermail/noisebridge-discuss/attachments/20130707/6de8ebda/attachment-0003.html>


More information about the Noisebridge-discuss mailing list