00:51 < sam_moore> Hell yes
00:51 < sam_moore> PWM controlled through web browser
00:51 < sam_moore> GPIO controlled through web browser
+01:19 < sam_moore> .... And ADC read through web browser
+01:19 < sam_moore> Blergh
+01:28 < sam_moore> I think I'll take the rest of today off from MCTX3420 :S
+11:53 < sam_moore> I've analysed the crap out of sampling rates for this ADC
+11:53 < sam_moore> At least as much as I can just using the timestamps according to gettimeofday
+11:54 < sam_moore> Contrary to my first email, reading the ADC is actually really slow. And also probably the greatest source of variation in sampling rate.
+11:56 < jtanx> wow
+11:56 < jtanx> only 100Hz?
+11:56 < sam_moore> Well it looks more like 1KHz on the oscilloscope, but there's a lot of variation, it has trouble getting a trigger
+11:57 < jtanx> the cpu datasheet rates it at 200kSPS
+11:57 < sam_moore> Hmm
+11:58 < sam_moore> Well judging by the control it is something about the ADC reading that makes it really slow
+11:58 < jtanx> That's annoyng
+11:58 < sam_moore> Yeah
+11:58 < sam_moore> Also annoying is that the ADC file is generally in a different place each time they're enabled
+11:59 < sam_moore> I ended up modifying the program to take the path to the ADC file as an argument
+11:59 < sam_moore> And making run.sh do the initialisation
+11:59 < sam_moore> I figured that was better than calling system()
+11:59 < jtanx> that makes sense
+11:59 < sam_moore> Yep, we might want to set other options that run.sh can pass to it anyway
+12:00 < sam_moore> Ok, I have to stop now, I'm spending way to much time on this
+12:00 < jtanx> Haha
+12:00 < sam_moore> It's getting to the point where I'm considering writing an ADC kernel module that doesn't suck :S
+12:01 < jtanx> :S let's hope it doesn't get to that stage
+20:12 < jtanx> the pressure regulator has a 1-5vdc analogue output
+20:12 < jtanx> is this considered one of the pressure sensors?
+20:14 < jtanx> or maybe it's just not used
+21:50 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Mon Sep 23 2013
+08:51 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+20:55 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+22:33 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+--- Day changed Tue Sep 24 2013
+14:18 < jtanx> with kernel 3.8 they decided to make life hard with device tree overlays
+14:19 < jtanx> http://e2e.ti.com/support/arm/sitara_arm/f/791/t/277811.aspx
+14:19 < jtanx> https://docs.google.com/a/beagleboard.org/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub
+14:47 < jtanx> huh
+14:47 < jtanx> http://www.youtube.com/watch?v=6gv3gWtoBWQ
+14:47 < jtanx> http://digital-drive.com/?p=146
+15:39 < sam_moore> I wonder if I can write a module that just uses /dev/adcX /dev/gpioX and /dev/pwmX
+15:40 < jtanx> that would make life simple
+15:40 < jtanx> but no
+15:42 < sam_moore> http://www.tldp.org/LDP/lkmpg/2.6/html/x569.html
+15:42 < sam_moore> Probably out of date (2.6?)
+15:45 < sam_moore> Also rt.wiki.kernel.org - realtime linux supposedly gives you better timing accuracy, although it would possibly break with our setup involving nginx
+15:46 < sam_moore> Actually it looks like there are quite a few ways for it to not work
+15:48 < jtanx> I think trying to write a kernel module would cause more grief than it's worth
+15:50 < jtanx> http://saadahmad.ca/using-pwm-on-the-beaglebone-black/
+15:51 < jtanx> I have no idea what's been updated and what hasn't
+15:51 < jtanx> as in, do we have that fix in our kernel
+15:53 < sam_moore> I don't know
+15:54 < sam_moore> We only need 1 PWM though
+16:00 < sam_moore> Or at least, last we heard there was only one. Doesn't make the system very expandable though.
+19:07 < jtanx> you know what I'll try loading an Ubuntu image from rcn to my sd card
+19:08 < jtanx> instead of from armhf
+19:08 < jtanx> armhf.com*
+19:17 < jtanx> ah screw it
+19:17 < jtanx> i'll stick with debian (but do the same thing)
+21:07 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Wed Sep 25 2013
+12:15 < jtanx> I think I know why we were having issues with pwm yesterday
+12:16 < jtanx> if you do this command
+12:16 < jtanx> echo bone_pwm_P8_13 > /sys/devices/bone_capemgr.8/slots
+12:16 < jtanx> you make it unavailable from /sys/class/pwm
+12:16 < jtanx> so in the run.sh script it was exporting all the pwm devices via the first method
+12:16 < jtanx> and then it becomes unavailable via sysfs
+12:17 < jtanx> anyway... I tried booting from the rcn image
+12:17 < jtanx> it comes with pwm enabled already
+12:17 < jtanx> and via that capemgr I got pwm to work
+12:17 < jtanx> I don't know what /sys/class/pwm/pwm0 corresponds to (which pin)
+12:19 < jtanx> the electronics teams' bbb wasn't done properly when we tried to upgrade the kernel
+12:19 < jtanx> probably something to do with the device tree stuff
+12:19 < jtanx> so I flashed it with the rcn image (which runs 3.8.13-bone26
+12:20 < jtanx> (demo image from here)
+12:20 < jtanx> elinux.org/BeagleBoardDebian
+13:09 -!- jtanx_ is now known as jtanx
+13:16 < jtanx> oh
+13:16 < jtanx> so it now works
+13:16 < jtanx> echo bone_pwm_P9_22 > slots
+13:16 < jtanx> if I do that line for pwm0
+13:26 < jtanx> oh right
+13:26 < jtanx> echo bone_pwm_P9_21 >slots
+13:26 < jtanx> for pwm1
+13:30 < jtanx> ahhhhhh
+13:30 < jtanx> if you comment out the line
+13:30 < jtanx> modprobe pwm_test
+13:30 < jtanx> from run.sh
+13:30 < jtanx> it works
+13:43 < jtanx> geeze kernel 3.8 has issues with usb hotplugging
+13:43 < jtanx> https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/usb/beagleboard/8aalvyWwaig/MUXAPuMTSOYJ
+13:43 < jtanx> which explains why we're having issues with cameras
+13:43 < jtanx> (partly at least)
+13:47 < jtanx> and now pwms not working again
+13:48 < jtanx> via sysfs
+13:50 < jtanx> oh
+13:50 < jtanx> I know why
+13:51 < jtanx> you have to export it /sys/class/pwm
+13:51 < jtanx> first
+13:51 < jtanx> *before* you do stuff like echo bone_pwm_P9_21 >slots
+13:52 < jtanx> yep
+13:53 < jtanx> so the order is: echo 0/1 > /sys/class/pwm/export
+13:53 < jtanx> then do that other stuff
+13:57 < jtanx> egh
+13:57 < jtanx> finnicky
+13:57 < jtanx> ok I have to stop now
+16:04 < jtanx> well that was an interesting experience
+16:04 < jtanx> it's most reliable when you work directly with /sys/devices/ocp2.helper/PWM9_22*
+16:05 < jtanx> I think if you echo am33xx_pwm to the slots thing when it's already loaded
+16:05 < jtanx> weird shit can happen
+16:05 < jtanx> too
+16:07 < jtanx> setting the period via sysfs (eg /sys/class/pwm) didn't work most of the time either
+16:07 < jtanx> you could change duty but not period
+16:07 < jtanx> although I swear I had it working at one point
+16:07 < jtanx> via the other way I think it works ok
+16:08 < jtanx> oh yeah, and I was doing this using the demo image from http://elinux.org/BeagleBoardDebian
+16:09 < jtanx> the electrical group's one has been reflashed with that version as well
+16:09 < jtanx> (for ours I worked off my sd card)
+16:10 < jtanx> that image also enables the ethernet-over-usb
+16:36 < jtanx> I think we have to be careful which pins we export/enable
+16:37 < jtanx> https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true
+16:37 < jtanx> pages 80-82
+16:37 < jtanx> the pins have different meanings based on what mode they're in
+16:41 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+18:05 < jtanx> ...so I brought the BBB home, even though I should be studying for 2402 :S
+18:05 < jtanx> the microphone came in today too
+18:19 < jtanx> ok
+18:19 < jtanx> so these documents: https://github.com/derekmolloy/boneDeviceTree/tree/master/docs
+18:19 < jtanx> describes what the pins are used for by default
+19:00 < sam_moore> Ah... they already got the microphone
+19:00 < sam_moore> Welp. Guess we're stuck with it.
+19:00 < sam_moore> So... we can record <50Hz sounds reliably, maybe
+19:00 < sam_moore> How useful
+19:01 < sam_moore> Have I been missing out on an email stream where the sensors team actually clears things with us?
+19:04 < jtanx> not that I know of
+19:04 < jtanx> haha
+19:04 < jtanx> in other news
+19:04 < jtanx> the sensors team ordered a pressure sensor with no mount
+19:04 < jtanx> adrian had a spat because it'd cost something like $200 to make the mount
+19:05 < jtanx> for a $10 part
+19:05 < jtanx> so he said, order it from online , I don't care if it's from overseas
+19:05 < sam_moore> Oh boy
+19:06 < sam_moore> If there's an issue with the camera and/or microphone they'll blame us
+19:06 < jtanx> yeah
+19:06 < jtanx> about that camera
+19:06 < sam_moore> Oh dear...
+19:06 < sam_moore> Go ahead?
+19:06 < jtanx> still couldn't get it to work today
+19:06 < sam_moore> God dammit
+19:06 < jtanx> although I didn't spend much time on it
+19:06 < jtanx> I got pwm to work
+19:06 < jtanx> mostly
+19:06 < sam_moore> I thought it might be something like adding the user to the "video" group
+19:06 < sam_moore> That's good!
+19:07 < sam_moore> What was happening?
+19:07 < jtanx> yeah, the problem is it doesn't show up at all (the camera)
+19:07 < sam_moore> Hmm
+19:07 < jtanx> and partly because 3.8 has an issue with usb hotplugging
+19:07 < sam_moore> Haha
+19:07 < jtanx> about pwm
+19:07 < jtanx> it seems that the sysfs method is not so reliable
+19:07 < jtanx> you can get it to work
+19:07 < jtanx> you have to export those first
+19:07 < jtanx> so echo 0 > /sys/class/pwm/export
+19:08 < jtanx> then (and only then)
+19:08 < jtanx> can you do
+19:08 < jtanx> that echo to the slots
+19:08 < jtanx> for those pins
+19:08 < jtanx> then it seems to be happy
+19:08 < jtanx> if you echo am33xx_pwm to the slots when it's already enabled
+19:08 < jtanx> that also screws things up
+19:08 < sam_moore> Ok
+19:09 < sam_moore> Thanks for working that out
+19:09 < jtanx> yeah
+19:09 < sam_moore> If you want to change from sysfs to the other method that's fine
+19:09 < sam_moore> But sysfs was much simpler to code
+19:09 < jtanx> should have spent that time studying for mech2402 though :P
+19:09 < sam_moore> Because you just sprintf an integer to the path
+19:09 < jtanx> yeah
+19:09 < jtanx> witht he other way it's all that dynamic path crap
+19:09 < sam_moore> Rather than keeping track of "bone_pwm_test_P9_22.15.arbitrary_string" crap
+19:09 < sam_moore> Exactly :P
+19:09 < jtanx> but
+19:10 < jtanx> you can enable pwm and analogue on boot
+19:10 < jtanx> if I can find the link
+19:10 < sam_moore> Sure, if that's easy
+19:10 < sam_moore> I figured if we put them in the /etc/init.d script that'd be fine too
+19:10 < sam_moore> Actually... maybe we should put it in the /etc/init.d script
+19:11 < jtanx> oh yeah
+19:11 < jtanx> and the demo image from that rcn image
+19:11 < sam_moore> Because if someone gets a different beaglebone then they'd have to reenable it on boot
+19:11 < jtanx> is better than screwing around with recompiling kernels
+19:11 < sam_moore> Can you give a link?
+19:11 < jtanx> I think it's the first image that you had originally
+19:11 < jtanx> http://elinux.org/BeagleBoardDebian
+19:12 < jtanx> there's this script in /boot
+19:12 < sam_moore> Oh
+19:12 < jtanx> that allows you to copy the sd card to flash
+19:12 < jtanx> it also enables the usb over ethernet
+19:12 < sam_moore> Oh right, the image I downloaded before we used yours
+19:12 < sam_moore> Cool
+19:12 < jtanx> yeah
+19:12 < jtanx> I flashed electronics' one with that
+19:12 < sam_moore> Does PWM and stuff work on it?
+19:13 < jtanx> probably
+19:13 < jtanx> I was using the same image
+19:13 < jtanx> on ours
+19:13 < jtanx> you run this script and it copies exatly what's on the sd card to the internal flash
+19:13 < jtanx> resizes the partition as necessary
+19:13 < jtanx> http://digital-drive.com/?p=146
+19:13 < jtanx> that page shows how to enable on boot
+19:13 < jtanx> it's just a change to uEnv.txt in the boot partition
+19:18 < sam_moore> Good work
+19:19 < sam_moore> While I remember, for multiple logins and crap... can you just try to login as a local user account?
+19:19 < sam_moore> Then we could make a wrapper around adduser and deluser for the "administrator" account
+19:19 < jtanx> wow
+19:20 < jtanx> I don't know
+19:20 < sam_moore> I was just thinking
+19:20 < sam_moore> Linux has a user account system already
+19:20 < jtanx> yep, but is it a good idea to be making ~300 on a BBB?
+19:21 < sam_moore> Well... putting LDAP on the BBB probably won't be less intense
+19:21 < sam_moore> I know it's called "Lightweight"
+19:21 < sam_moore> But that's in comparison to "DAP"
+19:21 < jtanx> well to be perfectly honest, adrian is asking way too much
+19:21 < sam_moore> Which was designed in the 1980s by a telephone directory company and used the original OSI networking model
+19:21 < jtanx> you simply can't support a 300-odd user base on something like a BBB
+19:21 < sam_moore> Yeah
+19:22 < sam_moore> But maybe something like 30 users would work?
+19:22 < jtanx> yeah
+19:22 < jtanx> let's just keep it at that limit
+19:22 < sam_moore> Another thing regarding the crazy requirements...
+19:22 < sam_moore> If we have multiple Beaglebones running FastCGI
+19:23 < sam_moore> We can design our GUI so that it has links to the appropriate Beaglebone for each function
+19:23 < sam_moore> I don't think we actually need to do anything in nginx or the Beaglebone software
+19:24 < jtanx> hmm
+19:24 < sam_moore> At least in terms of displaying sensor data
+19:24 < sam_moore> For actuator control, we would need to introduce networking between individual beaglebones
+19:24 < jtanx> it actually depends on what he means by 'extensible' and/or distributed
+19:24 < jtanx> like
+19:24 < jtanx> you could say this BBB is for this experiement
+19:25 < jtanx> this other BBB is for this other experiment
+19:25 < sam_moore> But quite frankly you'd be mad to trust a distributed system with networking delays to coordinate control over hardware
+19:25 < jtanx> well yeah
+19:25 < sam_moore> Well at least something like this where we care about safety
+19:25 < sam_moore> But if you keep the actual control over hardware independent and on seperate devices
+19:25 < jtanx> but I mean
+19:26 < jtanx> wait
+19:26 < jtanx> if we interpret it as meaning
+19:26 < jtanx> that each BBB runs an instance of the software
+19:26 < jtanx> then they would still be separate
+19:26 < jtanx> as in each BBB controls one 'experiment'
+19:26 < jtanx> you customise each BBB based on the experiment that needs to be done
+19:26 < sam_moore> Yes, that would work
+19:26 < sam_moore> Yep
+19:26 < jtanx> then there's no interaction between BBBS
+19:27 < jtanx> the only thing is you have some sort of control at the front
+19:27 < jtanx> that determines which BBB you connect to
+19:27 < sam_moore> Yes, if there's interaction between BBBs it gets problematic
+19:27 < jtanx> yeah
+19:27 < sam_moore> Yes, you have one BBB which gives the user the "main menu" part of the GUI
+19:27 < jtanx> I reckon that's a stupid requirement to ask
+19:27 < jtanx> yeah
+19:27 < sam_moore> Then the others just have customised GUIs or whatever
+19:28 < jtanx> once you have to get them to talk to each other, you're then having to try and invent a whole new protocol
+19:28 < jtanx> for that
+19:28 < sam_moore> Yeah, and it depends on exactly what the hardware is
+19:29 < sam_moore> You might be able to hack it onto the web protocol (eg: BeagleBone #1 sends http://beaglebone2/api/actuators?id=X?set=Y)
+19:29 < sam_moore> But... let's not think about that
+19:30 < sam_moore> It's clearly beyond the scope of this project
+19:31 < sam_moore> So, after all that, I reckon if we use snoopy for ADC/GPIO/PWM and spike for the dilatometer then that would be cool (probably not actually necessary though)
+19:31 < jtanx> yeah
+19:32 < sam_moore> The dilatomter... it's going to cause headaches if Kieren really wants to "return" an array of points
+19:33 < sam_moore> If the goal is to provide the user with a demonstration of what the dilatometer is doing, then you can just edit an image
+19:33 < sam_moore> If the goal is to provide more data... I don't see the point really
+19:34 < sam_moore> It's going to be the same sort of distribution every time
+19:34 < sam_moore> Realistically all anyone would do is average it
+19:34 < sam_moore> Maybe take a standard deviation
+19:36 < jtanx> I really don't know why a dilatometer's even needed
+19:36 < sam_moore> Educational reasons? :P
+19:37 < jtanx> haha sure
+19:37 < sam_moore> Anyway, hopefully Callum will deal with the dilatometer stuff
+19:37 < sam_moore> The interferometer code is a good starting point
+19:39 < jtanx> Yeah
+19:39 < jtanx> hopefully
+19:42 < sam_moore> We should arrange some meetings next week
+19:42 < sam_moore> Also I'd like to see more of the other group members committing to git and talking in this channel
+19:45 < sam_moore> People are missing a lot of design decisions here :S
+19:45 < jtanx> Yeah
+19:51 < jtanx> Ok
+19:51 < jtanx> so I made a LUT from pin number on the board to GPIO pin number
+19:52 < jtanx> so if you wanted to use P8_13
+19:52 < jtanx> you can use the lut to figure out what gpio number that corresponds to
+19:53 < jtanx> we should probably restrict which pins can be used
+19:53 < jtanx> because quite a few are reserved
+19:53 < sam_moore> Sure
+19:53 < sam_moore> Remove the #defines in bbb_pin_defines.h ?
+19:54 < sam_moore> Don't export those pins in pin_test.c
+19:54 < sam_moore> It is only really for testing anyway
+19:54 < jtanx> yeah
+19:55 < sam_moore> Although... I predict if we leave it in the software, *someone* at some point will try and control hardware directly through it :P
+19:55 < sam_moore> For all the educational stuff it's nice though
+19:56 < sam_moore> Oh, we could have an image of the pinout diagram
+19:56 < sam_moore> And when someone clicks on a part of the image they get to control that pin
+19:57 < sam_moore> Anyway... I really should study for MECH2402 or I will fail it
+19:57 < sam_moore> So bye
+19:57 < jtanx> yeah
+19:57 < jtanx> bye
+20:50 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Thu Sep 26 2013
+17:52 < jtanx> http://www.ti.com/lit/ug/spruh73i/spruh73i.pdf p1986 (chapter 15) on pwm
+17:55 < jtanx> page 1996 on ePWM
+17:56 < jtanx> ahhhhh
+17:56 < jtanx> for ehrpwm0a/0b
+17:56 < jtanx> the frequency is linked
+18:08 < jtanx> ehrpwm is enhanced resolution pwm
+18:08 < jtanx> Implemented using the A signal path of PWM, that is, on the EPWMxA output. EPWMxB output has
+18:08 < jtanx> conventional PWM capabilities
+18:08 < jtanx> (p2053)
+19:06 < jtanx> if you want to make the pwm stuff not suck
+19:06 < jtanx> there's this file called pwm_test.c
+19:06 < jtanx> that's the driver
+19:59 < jtanx> for future ref: http://armsdr.blogspot.com.au/2013/04/archlinux-on-beaglebone-and-linux-38.html
+21:19 < jtanx_> urgh wow
+21:19 < jtanx_> ok, so I think pwm1/3/5 shouldn't be used to avoid period conflicts
+21:19 < jtanx_> (pwm0/1 is for channel A/B of one pwm device, 3/4 another, 5/6 another)
+21:20 < jtanx_> btw the correspondence between pwmX and pin number is:
+21:21 < jtanx_> P9_22, P9_21, P9_42. P9_14, P9_16, P8_19, P8_13, P9_28
+21:23 < jtanx_> pwm 2/7 correspond to eCAP devices
+21:24 < jtanx_> which I think are to capture PWM input
+21:24 < jtanx_> but they can also be used to generate PWM output, afaik
+23:08 -!- jtanx_ [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Fri Sep 27 2013
+13:29 < jtanx> so, apparently if we don't order stuff that we need before the mid semester break (ie today), adrian just won't order it
+13:29 < jtanx> in other news, I think I've mostly sorted out pwm
+13:43 < jtanx> trying to standardise the pin code
+20:10 < jtanx_> lol
+20:10 < jtanx_> we have a file authored '14 years ago'
+20:10 < jtanx_> in git
+20:10 < jtanx_> talk about commitment
+21:47 < jtanx_> so on non-BBB platforms, I disabled the pin code
+21:47 < jtanx_> required some pretty dubious hacks to stop gcc from complaining
+21:48 < jtanx_> 1st attempt: define the functions to nothing
+21:48 < jtanx_> gcc complains about statements that do nothing
+21:48 < jtanx_> various combinations later on statements that do nothing, I move to making function stubs
+21:49 < jtanx_> shaft all the parameters to the stubs
+21:49 < jtanx_> to stop complaints about unused variables
+21:49 < jtanx_> (eg if you did int freq=1000; PWM_Set(...,freq) where the define for PWM_Set doesn't use freq
+23:12 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Sat Sep 28 2013
+--- Log closed Sat Sep 28 12:20:39 2013
+--- Log opened Sat Sep 28 12:26:58 2013
+12:26 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
+12:27 -!- Irssi: Join to #mctxuwa_softdev was synced in 9 secs
+21:36 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Log closed Sun Sep 29 08:28:33 2013
+--- Log opened Sun Sep 29 08:31:40 2013
+08:31 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
+08:31 -!- Irssi: Join to #mctxuwa_softdev was synced in 2 secs
+08:31 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
+08:31 -!- You're now known as sam_moore
+15:27 < Rowan> hey jeremy, did you upload the updated gui onto a github? i cant find it anywhere ??
+15:32 < sam_moore> Hi Rowan, I think it's in a few subdirectories
+15:33 < sam_moore> Ah, it's under "testing/MCTXWeb"
+15:33 < sam_moore> https://github.com/szmoore/MCTX3420/tree/master/testing/MCTXWeb/public_html
+15:37 < Rowan> thats the most uptodate version?
+15:39 < jtanx> um
+15:39 < jtanx> maybe
+15:39 < jtanx> I'll update with what I've got now
+15:42 < jtanx> ok
+15:42 < jtanx> updated
+15:42 < jtanx> pintest stuff still not complete
+15:42 < Rowan> are you guys busy?
+15:42 < Rowan> (will you be on here long?
+15:42 < jtanx> right now I'm working on that pintest page
+15:42 < jtanx> I'm here
+15:43 < Rowan> in g19?
+15:43 < jtanx> no
+15:43 < jtanx> I'm at home
+15:43 < Rowan> okay
+15:43 < sam_moore> jtanx: As in, the pin control code isn't working? I didn't think I screwed it up that badly?
+15:43 < jtanx> nah
+15:43 < jtanx> the pin control web page
+15:43 < sam_moore> Oh, nice
+15:43 < jtanx> just thought it'd be easier to have a webpage to control stff
+15:43 < sam_moore> Yes
+15:43 < jtanx> especially for electronics
+15:43 < sam_moore> Yes, definitely
+15:44 < Rowan> are we going to make the gui UWA based or make it our own ?
+15:44 < Rowan> adrian made it sound like he wanted it UWA based with the logo and stuff
+15:44 < jtanx> we probably have to add uwa logo
+15:44 < sam_moore> We should probably put the UWA logo on it
+15:44 < sam_moore> Yes
+15:45 < Rowan> so make it similar to the main UWA page or make it similar to LMS?
+15:46 < Rowan> does anyone know if IT are in this week?
+15:46 < jtanx> we need to make it Colourful
+15:47 < jtanx> I don't think it needs to be exactly like UWA page or LMS
+15:47 < jtanx> just something similar would be good
+15:47 < sam_moore> I think LMS is probably a bad example, lots of people hate it
+15:48 < jtanx> haha
+15:48 < jtanx> I think LMS is fine, although there seems to be alot of problems with it on the backend
+15:48 < Rowan> yeah but adrian loves it
+15:48 < Rowan> keeting uses it for all 5 units hes teaching
+15:49 < Rowan> has anyone heard from james about the gui, i think he uploaded something to dropbox
+15:49 < jtanx> really
+15:49 < jtanx> I haven't checked db
+15:49 < jtanx> why's he not using git
+15:50 < Rowan> i dont know. has he uploaded anything to it/
+15:50 < Rowan> he might be.
+15:50 < Rowan> sometime last week he said he made up a gui todo list type thing but i dont know where he put it
+15:50 < sam_moore> It doesn't look like there is anything in dropbox
+15:50 < jtanx> right
+15:51 < Rowan> im trying to get in contact with him but i might just move on. so we want something somewhat related to lms?
+15:51 < Rowan> or no?
+15:52 < sam_moore> I think so, although it primarily needs to be able to control experiments
+15:52 < sam_moore> For the educational stuff, you could use a wiki style
+15:53 < sam_moore> https://github.com/szmoore/MCTX3420/wiki
+15:54 < Rowan> wiki isnt graphical enough
+15:54 < sam_moore> Yeah, probably
+15:54 < Rowan> its hard to say what adrian wants....
+15:54 < sam_moore> It looks like James has committed something to his own fork of the repository
+15:55 < jtanx> ok
+15:55 < sam_moore> https://github.com/firefields/MCTX3420/commit/e6a8120fdf1cef6d73421bd2b1edb1c45a6f3960
+15:55 < sam_moore> I can pull that into the main fork
+15:55 < sam_moore> Hopefully
+15:55 < jtanx> I think that may actually be
+15:56 < jtanx> sorry
+15:56 < jtanx> my computer decided to freeze at that instant
+15:57 < jtanx> but yeah that's the stuff
+15:57 < jtanx> he worked on
+15:57 < sam_moore> Oh wow... there are a *lot* of files
+15:57 < jtanx> before mine
+15:57 < jtanx> it's all the jquery ui stuff
+15:57 < sam_moore> jquery-ui
+15:57 < sam_moore> Yes
+15:57 < jtanx> wich I told him to get rid off
+15:57 < sam_moore> Dammit I just merged it :S
+15:57 < jtanx> but yeah, he hasn't committed anything since
+15:58 < jtanx> (that commit was done with me at the last meeting)
+15:58 < Rowan> so are we deciding on jeremys version it seems alot more complete
+15:59 < sam_moore> Yes, stick with Jeremy's and build on it
+15:59 < Rowan> sweet :)
+16:46 < Rowan> what was the password and username ?
+16:48 < jtanx> there's none
+16:48 < jtanx> if you haven't set up the htpasswd thing
+16:48 < jtanx> (ie it doesn't work)
+16:48 < jtanx> still not sure how to implement it either
+16:48 < jtanx> now that adrian wants it scalable to '300 students'
+16:53 < jtanx> I need another network switch...
+16:53 < Rowan> okay.
+16:53 < Rowan> i might make up a cover page, which links to the one we have after you log in
+16:54 < Rowan> like this but simpler: http://www.futureeffect.com.au/
+16:54 < Rowan> with a scrolling picture thing and stuff
+16:55 < MctxBot> I live again...
+16:55 < Rowan> whos mctxbot again?
+16:56 < jtanx> :P
+16:56 < jtanx> It does nothing
+16:56 < Rowan> its a cover page
+16:56 < Rowan> its what adrian said
+16:56 < jtanx> It connects whenever mctx.us.to is running
+16:57 < Rowan> what what
+16:57 < Rowan> ?
+16:58 -!- MctxBot changed the topic of #mctxuwa_softdev to: MCTX3420 - Software and co.
+16:59 < jtanx> mctxbot is no one, it's the server I operate
+17:02 < Rowan> hahahahah
+17:02 < Rowan> oh.
+17:03 < Rowan> ive put the uwa logo onto the gui
+17:09 < sam_moore> I'm looking at the login stuff
+17:10 < sam_moore> So... we probably don't want to use shell accounts, since once you have shell access you can do all sorts of things that are completely unrelated to this educational stuff
+17:10 < Rowan> could someone check ive forked it right
+17:10 < sam_moore> I think storing our own file in the same format as /etc/shadow is probably ok
+17:11 < Rowan> the gui.html & style.css
+17:12 < sam_moore> It looks like you've made a new branch for each of the files?
+17:12 < Rowan> i think so
+17:12 < Rowan> do you need to update the main file and i request it to you
+17:13 < Rowan> just so everything is uptodate and and organised
+17:13 < sam_moore> You submitted a pull request, that's fine
+17:13 < sam_moore> Yep
+17:13 < Rowan> both html and css files
+17:13 < sam_moore> You should probably keep edits in the "master" branch, or at least don't make a seperate branch for each file
+17:14 < sam_moore> (That way you only have to do one pull request for all of them, not one per file)
+17:14 < Rowan> how do i do that :|
+17:14 < sam_moore> Are you using a GUI or the command line?
+17:15 < Rowan> gui
+17:15 < jtanx> I think you were working on an old version
+17:15 < jtanx> before I pushed the new one
+17:15 < sam_moore> Hmm
+17:15 < jtanx> so some stuff got deleted
+17:15 < Rowan> S***
+17:15 < jtanx> https://github.com/szmoore/MCTX3420/commit/f43006da69d629d0c5421506c8a56d517b94924e
+17:15 < jtanx> it's ok
+17:16 < sam_moore> jtanx: It should have complained if there was a conflict?
+17:16 < jtanx> I dunno
+17:16 < Rowan> i only added 1 line to the css file anyways
+17:16 < jtanx> yeah
+17:16 < jtanx> so the form.controls, div.centre .bold etc
+17:16 < jtanx> stuff was added later
+17:18 < Rowan> when im home ill try put a cover page with pictures and the login page on it and link the login page to the gui we have atm.
+17:18 < Rowan> any constructive critism ?
+17:19 < Rowan> also ill try be on irc for the rest of the sem to keep up todate with you guys :)
+17:21 < sam_moore> The future effect looks cool
+17:21 < sam_moore> I guess we need to pick some relevant images though
+17:21 < Rowan> yeah ill talk to some other teams and see if they have any cool pics, like the can were testing, the cad model ect
+17:22 < Rowan> ttyl
+17:22 < jtanx> has this been pushed to your (sam's) repo?
+17:22 < sam_moore> I accepted a pull request a while ago
+17:22 < sam_moore> But I noticed Rowan has two branches in his fork; there's one file changed in each branch
+17:23 < jtanx> oh ok
+17:23 < jtanx> because I don't see any change except for some css stuff in your repo
+17:24 < sam_moore> Rowan: I'll try and get in earlier tomorrow to help with the "branching" stuff in git
+17:25 < sam_moore> It looks like your git GUI might have some wierd settings
+17:28 < MctxBot> damn ircnet
+17:29 < MctxBot> 'Too many user connections (local))'
+17:29 < MctxBot> so i'll steal mctxbot for now
+17:42 -!- jtanx_ is now known as jtanx
+17:43 < jtanx> finally
+17:52 < sam_moore> So, we can implement our own login system fairly easily, I'm not sure if we want to or not, although I'm leaning towards just doing it
+17:53 < sam_moore> It wouldn'
+17:54 < sam_moore> t necessarily be the best solution in terms of flexibility
+17:54 < sam_moore> But it's probably a hell of a lot more "lightweight" than LDAP
+17:55 < sam_moore> Using LDAP you'd have to dedicate processes just to being a login server
+17:56 < sam_moore> So... we provide some wrappers around a text file of usernames and password salts, and allow "admin" to use wrappers that change the files
+17:57 < sam_moore> ... I suppose we can have a "forgot password" functionality
+17:57 < sam_moore> Though it is certainly a pain
+17:59 < sam_moore> I feel like we should have "forgot password" but make it ridiculously painful to use, for revenge
+17:59 < sam_moore> ...errr I mean security reasons
+17:59 < sam_moore> Did I say "revenge?"
+18:00 < sam_moore> "Forgot password" should activate one of the ADC channels and record the average over 10s
+18:01 < sam_moore> And you have to enter what it was
+18:01 < sam_moore> No wait, any student could do that
+18:01 < sam_moore> Hmmm
+18:03 < sam_moore> "Your password has been sent via Australia Post to your registered address"
+18:04 < jtanx> hahaha
+18:04 < jtanx> evil
+18:04 < jtanx> I was kinda hoping there was some ready made
+18:04 < jtanx> gateway software
+18:05 < jtanx> like you know the SSO services that uwa uses
+18:05 < sam_moore> Yeah, that's an LDAP gateway
+18:05 < jtanx> yeah but like a simplified version
+18:05 < sam_moore> Haha
+18:05 < jtanx> that just uses an sql database or something
+18:05 < jtanx> slap it on and we're done
+18:06 < sam_moore> Yeah I guess we should look for that
+18:06 < sam_moore> Do we allow users to change their password?
+18:06 < sam_moore> Ooh
+18:06 < sam_moore> Our system is on the UWA network...
+18:06 < sam_moore> Could we just wrap to UWA's LDAP servers?
+18:06 < sam_moore> And... um...
+18:07 < jtanx> do they trust us that much?
+18:07 < sam_moore> They can't really stop us
+18:07 < sam_moore> You can bind to the LDAP servers already
+18:07 < sam_moore> It's not like they can...
+18:07 < jtanx> really?
+18:07 < sam_moore> Put in a login or something
+18:07 < sam_moore> That you have to go through first
+18:07 < jtanx> well then
+18:07 < sam_moore> :P
+18:08 < sam_moore> Hang on, there's some horribly verbose way to test it in a shell
+18:08 < jtanx> my god why is it so hard to vertically align content in css
+18:14 < sam_moore> ldapsearch -x -D cn=20503628,ou=Students,ou=Users,ou=UWA,dc=uwads,dc=uwa,dc=edu,dc=au -h ldap.pheme.uwa.edu.au -W -v -b cn=20503628,ou=Students,ou=Users,ou=UWA,dc=uwads,dc=uwa,dc=edu,dc=au
+18:14 < sam_moore> Replace 20503628 with your own student number
+18:14 < sam_moore> So
+18:14 < sam_moore> Basically we can wrap to ldapsearch using their username and password
+18:14 < jtanx> I wonder what adrian has to say about that
+18:15 < sam_moore> Well, obviously he doesn't want just *any* student being able to access it :S
+18:15 < sam_moore> But...
+18:15 < sam_moore> We could have a plain text file of students
+18:15 < sam_moore> That he can change
+18:15 < sam_moore> Also...
+18:16 < sam_moore> UWA IT might have a problem
+18:16 < sam_moore> It would be ridiculously easy to put a back door in to steal student's passwords :S
+18:16 < jtanx> yeah
+18:16 < sam_moore> But... I guess people would just use their pheme password anyway
+18:17 < sam_moore> I mean, I would
+18:18 < sam_moore> http://xkcd.com/792/
+18:18 < sam_moore> I reckon we implement the system to bind to UWA's ldap servers, obviously don't do anything unethical
+18:19 < jtanx> :P
+18:19 < jtanx> what about jellyfish, calmaeth
+18:19 < sam_moore> And warn Adrian that if he lets random students work on this they can potentially do unethical things
+18:19 < sam_moore> What do they use for login?
+18:20 < jtanx> they roll their own I think
+18:20 < jtanx> but obviously there's some way to import users
+18:20 < sam_moore> Hmm
+18:20 < sam_moore> I like the idea of using UWA's pheme server though
+18:21 < sam_moore> Just add a list of allowed student numbers in front of it
+18:21 < sam_moore> Actually, staff as well
+18:21 < jtanx> yeah true
+18:21 < sam_moore> No wait
+18:22 < sam_moore> That could end in the staff member accidentally deleting themselves
+18:22 < sam_moore> Um...
+18:22 < sam_moore> Just hard code in Adrian's staff number as always allowed :P
+18:22 < sam_moore> Ergh, so many annoying things that have nothing to do with blowing up a pressure vessel -_-0
+18:23 < sam_moore> Ok, I'll try do some more on the login tomorrow
+18:23 < jtanx> ok cool
+18:23 < jtanx> I'll try to come in early tomorrow too
+18:23 < jtanx> though I really should be working on my other projects too...
+18:24 < sam_moore> Well, we're doing alright on the list of things Todo
+18:24 < sam_moore> Not sure how well we're doing by Adrian's standards
+18:24 < sam_moore> Oh, all that GUI stuff isn't getting done very afst
+18:24 < sam_moore> *fast
+18:24 < jtanx> yeah
+18:25 < sam_moore> Also haven't heard anything about image processing from Callum
+18:25 < jtanx> I wonder if james has done anything at all
+18:25 < sam_moore> Oh well... I'll do logins this week
+18:25 < jtanx> Adrian doesn't seem to like how most of the groups are going
+18:26 < sam_moore> Well, not much has happened with other groups I suppose
+18:26 < sam_moore> We've written a lot of software, but it's all low level
+18:26 < jtanx> I also think he underappreciates the effort required for the software though
+18:27 < sam_moore> I think so
+18:27 < sam_moore> Though we really should have more GUI stuff done
+18:28 < jtanx> yeah
+18:28 < jtanx> we really do need to make progress on that
+19:12 < jtanx> firebug slows down my computer so much
+19:22 < jtanx> ok I just updated the gui stuff a bit
+19:22 < jtanx> ...now back to testing if this pin test html page works
+19:32 < jtanx> well hey
+19:32 < jtanx> it works
+19:33 < jtanx> Should probably do reference counting on the export/unexport stuff though
+19:36 < jtanx> actually maybe not
+19:46 < sam_moore> I think DAP (which is what LDAP was based on) wasn't actually meant to be a login system when they designed it :P
+19:46 < sam_moore> But it's used for that more than anything else
+19:46 < sam_moore> Essentially it was supposed to be like an electronic telephone directory
+19:47 < sam_moore> Then they realised that it was a bad idea for any random person to be able to edit stuff, so authentication got added to it
+19:47 < sam_moore> And now it's pretty much just used for authentication
+19:48 < sam_moore> There seems to be a sane C library for it, so if we just implement a client and rely on the good IT staff at UWA to keep pheme working...
+19:49 < sam_moore> (Does UWA even still hire IT staff?)
+19:49 < sam_moore> (Someone told me they "integrated" the librarians into IT)
+19:50 < sam_moore> We'll need to put our login page under HTTPS at some point
+19:52 < jtanx> I was just thinking
+19:53 < jtanx> put the whole damn thing under ssl
+19:53 < jtanx> and be done with it
+19:54 < jtanx> hmm interesting
+19:54 < jtanx> if you query the adc on different channels
+19:55 < jtanx> and you query too fast
+19:55 < jtanx> it'll spit back that it's temporarily unavailable
+19:55 < jtanx> probably can't change the mux that fast?
+19:56 < sam_moore> Maybe
+19:56 < sam_moore> It's kind of ironic that the ADC hardware has a multiplexer to give the extra channels
+19:57 < sam_moore> And then we are sticking another multiplexer on that
+19:57 < jtanx> :P
+19:57 < sam_moore> But I suppose if it means we don't need 4 of the same amplifier that's nice
+20:03 < jtanx> ok well the pintest page works good enough
+20:04 < jtanx> some race conditions
+20:04 < jtanx> but eh
+20:04 < jtanx> who cares
+20:04 < jtanx> ohhh I know what's slowing down the bb
+20:04 < jtanx> bbb*
+20:04 < jtanx> the crazy high sampling rate
+20:04 < jtanx> the test files also constantly eat up all the space on my 1gb sd card
+20:06 < jtanx> ..or maybe not
+20:57 < sam_moore> It turns out UWA uses LDAP to keep track of what units you're enrolled in
+20:57 < sam_moore> That's interesting...
+20:58 < sam_moore> Potentially we could restrict access to people enrolled in MXTC3420
+20:58 < sam_moore> That would mess with the new courses :P
+20:59 < sam_moore> And it appears you can connect to ldap.pheme.uwa.edu.au from UWA's network
+20:59 < sam_moore> But... it also appears to use the unsecured LDAP port?
+20:59 < sam_moore> Surely not
+20:59 < jtanx> what
+21:00 < sam_moore> Or maybe (hopefully) they are doing TLS
+21:00 < sam_moore> http://wiki.wireshark.org/LDAP
+21:00 < jtanx> one would hope that there's some sort of encryption going on
+21:00 < sam_moore> Well, there's HTTPS on the SSO page
+21:01 < sam_moore> But if there isn't actually encryption on the ldap connection
+21:01 < sam_moore> You could just plug into a switch and do some packet sniffing and get everyone's passwords :O
+21:01 < jtanx> haha wow
+21:02 < sam_moore> I think they might be using TLS, because my test program doesn't work
+21:07 < sam_moore> ... Or I'm just deleting one more character than I should be in the password -_
+21:11 < sam_moore> Test program works now
+21:11 < sam_moore> Either the ldap library kindly handles TLS for you automagically, or they aren't using it
+21:12 < jtanx> :S
+21:12 < jtanx> if you used wireshark wouldn't it show whether or not it's encrypted
+21:16 < sam_moore> I've just run it through wireshark
+21:16 < sam_moore> It's not encrypted
+21:17 < sam_moore> My password for pheme appears plain as day
+21:17 < jtanx> well that sounds dodgy as hell
+21:18 < sam_moore> Well, you do have to have root access to a machine that can pick up the traffic
+21:18 < sam_moore> But yes, that sounds dodgy
+21:18 < sam_moore> Hang, on a minute
+21:18 < sam_moore> What about Unifi
+21:19 < sam_moore> Well...
+21:19 < sam_moore> I think this should be filed under "Not our problem"
+21:20 < jtanx> ._.
+21:21 < sam_moore> Surely there's some kind of handshake encryption on Unifi though
+21:22 < sam_moore> Anyway, I have a test function that returns true if you can login to pheme, so if we integrate that with our code and maybe modify it to look at enrolled units, that's a good start
+21:23 < sam_moore> Actually I also need to make it work without using deprecated functions
+21:25 < sam_moore> At least the library maintainers still keep the deprecated functions, but it's annoying when something that works perfectly fine and has tonnes of documentation is replaced by something that has almost no documentation
+21:25 < sam_moore> Almost like the new UWA courses...
+21:25 < jtanx> hahaha
+21:25 < jtanx> what's worse is where the new function is a PITA to use by design
+21:26 < sam_moore> Yes
+21:27 < sam_moore> The "deprecated" version has "LDAP * ld = ldap_init(host, port); ldap_set_options(ld, LDAP_OPT_PROTOCOL_VERSION, &version); and ldap_bind_s(ld, dn, password, authentication_method);"
+21:27 < sam_moore> That makes perfect sense to me
+21:27 < sam_moore> No doubt the new and improved version takes 100x as much code
+21:28 < sam_moore> Although admittedly I was confused as to why the ldap_set_options required a pointer to the integer instead of just passing the integer
+21:28 < sam_moore> It probably modifies it in some cases though
+21:31 < jtanx> which package installs ldap
+21:31 < sam_moore> libldap2-dev
+21:31 < jtanx> thanks
+21:31 < sam_moore> For development libraries
+21:32 < sam_moore> ldap-utils for tools like ldapsearch
+21:32 < sam_moore> At the moment I can only find documentation for libldap-dev (the deprecated stuff)
+21:32 < sam_moore> To get it to work, you just put a #define LDAP_DEPRECATED 1 before the #include <ldap.h>
+21:33 < jtanx> http://man.devl.cz/deb/l/libldap2-dev ?
+21:33 < sam_moore> Oh, well there you go
+21:33 < sam_moore> Thanks
+21:34 < sam_moore> No wait, it has all those functions the compiler was complaining about
+21:34 < sam_moore> ?
+21:34 < jtanx> ok then
+21:34 < sam_moore> Except there's this fsfuncLDAP instead of LDAP
+21:36 < sam_moore> ...
+21:36 < jtanx> oh that documentaiton is so terrible: http://www.openldap.org/doc/
+21:37 < jtanx> the html version is at least
+21:37 < sam_moore> Yeah
+21:38 < sam_moore> Um... given that the only documentation for libldap2 documents the "deprecated" functions, I'm going to continue using those functions
+21:39 < sam_moore> Installing libldap2-dev installed all those man pages
+21:39 < jtanx> yep
+21:39 < jtanx> >.>
+21:41 < jtanx> ldap_init(3) was obsoleted by ldap_initialize(3)
+21:41 < jtanx> http://www.openldap.org/lists/openldap-bugs/200509/msg00151.html
+21:42 < sam_moore> Seriously
+21:43 < sam_moore> Please tell me they changed more than just the name...
+21:44 < sam_moore> Oh great, they did, now I need to work out how to use it
+21:44 < jtanx> int ldap_initialize(ldp, uri)
+21:44 < jtanx> LDAP **ldp;
+21:44 < jtanx> char *uri;
+21:44 < jtanx> wow, that's old school way of specifying the type of the input arguments
+21:45 < jtanx> I've only seen that style once elsewhere
+21:45 < jtanx> In code from the ~1990s
+21:45 < sam_moore> LDAP was invented in the 80s
+21:45 < sam_moore> So that would make sense
+21:45 < jtanx> you'd think they'd update the manpages by now though
+21:46 < sam_moore> They don't even note in the man page that ldap_init is depreated
+21:46 < jtanx> yeah
+21:46 < jtanx> the joys of poor documentation
+21:46 < sam_moore> At least the function names make sense
+21:46 < sam_moore> initialize
+21:47 < sam_moore> Obvious what that does
+21:47 < sam_moore> ... I think the "uri" includes the port
+21:47 < sam_moore> Like "ldap://server" or "ldaps://server"
+21:47 < jtanx> yep
+21:48 < jtanx> the whole ldap_init vs ldap_initialize reminds me of fopen vs fopen_s on windows
+21:48 < sam_moore> That's going to screw with anyone that puts their ldap server on a non-standard port for security-by-obscurity reasons
+21:48 < jtanx> couldn't you do
+21:48 < jtanx> ldap://server:port
+21:48 < sam_moore> Oh
+21:48 < sam_moore> Probably
+21:56 < sam_moore> Sigh... they deprecated ldap_bind and made ldap_simple_bind and then at some point that got deprecated too
+21:57 < sam_moore> Now it's ldap_sasl_bind_s
+21:57 < jtanx> what's with that naming convention
+21:57 < sam_moore> sasl stands for something
+21:57 < jtanx> _s for secure
+21:57 < jtanx> yey
+21:57 < sam_moore> The LDAP expert at UCC was basically like "It's terrible, no one ever uses it, but the LDAP standards wanted to put it in, so it's there"
+21:57 < sam_moore> And that's all I know
+21:58 < jtanx> gee ok
+21:59 < sam_moore> But as opposed to ldap_simple_bind(ld, dn, password)
+21:59 < sam_moore> You have something like 10 arguments?
+21:59 < sam_moore> Please let half of them be NULL...
+22:12 < jtanx> that's all for today
+22:12 < jtanx> bye
+22:12 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+23:19 < sam_moore> Hi Rowan
+23:19 < Rowan> hello
+23:19 < sam_moore> I'm working on getting logins with UWA's pheme system
+23:19 < sam_moore> So it will be kind of like LMS
+23:24 < Rowan> are we trying to keep the gui to only a few pages or can we use several.
+23:25 < Rowan> like a cover page(a link to just the stream, a link to dump data and a login). then the login page goes to the experiment page
+23:26 < sam_moore> I think several pages
+23:26 < sam_moore> Probably even one page per sensor?
+23:26 < Rowan> sweet, i shall enjoy this gui :)
+23:41 < sam_moore> See you tomorrow
+23:47 < Rowan> yep
+--- Day changed Mon Sep 30 2013
+11:17 < sam_moore> Hi Rowan, do you have anything we should put in the report?
+11:59 < Rowan> ill have the outline of all the pages i wanted on git this afternoon
+12:05 < sam_moore> Ok
+13:33 < Rowan> so far i have a cover page which links to a login page which links to the index page. but theres no styles for them and no security on the login
+14:09 < Rowan> im not sure the files ive added went into sams git. im pretty sure they all forked over to mine. :S
+21:44 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Tue Oct 01 2013
+13:40 < sam_moore> Another option for the login system (a really terrible option that I don't condone on any real world system, but it might just get us marks)
+13:40 < sam_moore> Is to provide some cgi scripts that wrap around "useradd" "userdel" and "usermod"
+13:40 < sam_moore> And have our "Login" function check /etc/shadow
+13:41 < sam_moore> I emailed UWA IT help desk about Pheme anyway
+13:41 < sam_moore> I wonder what they'll make of it...
+13:51 < jtanx> hehe
+13:52 < sam_moore> The more I think about it, the more I think LDAP is the way you'd do this properly though
+13:52 < sam_moore> It basically is a text file
+13:53 < jtanx> yeah
+13:53 < sam_moore> If you started with a text file, you'd quickly find yourself reinventing the wheel and probably converging with what LDAP already does
+13:53 < jtanx> I guess the real problem is that rolling our own solution is not really feasible in the time left, especially if you want to ensure it's at least ok in terms of security
+13:57 < sam_moore> Yes
+14:08 < sam_moore> For reference: http://www.debuntu.org/how-to-set-up-a-ldap-server-and-its-clients/
+14:09 < sam_moore> And http://mindref.blogspot.com.au/2010/12/openldap-create-user.html
+14:09 < sam_moore> (How to set up our own LDAP server)
+14:11 < jtanx> slapd
+14:12 < jtanx> what a weird choice of a name
+14:12 < sam_moore> Haha
+14:15 < jtanx> oh
+14:15 < jtanx> if you set up an ldap server
+14:15 < jtanx> http://phpldapadmin.sourceforge.net/wiki/index.php/Main_Page
+14:15 < jtanx> get them to manage the ldap database themselves
+14:15 < jtanx> :P
+14:15 < jtanx> to add or remove users
+14:22 < sam_moore> Yeah, that's kind of how ldap was designed
+14:22 < sam_moore> Technically I can probably modify my UWA "pheme" password from a command line using ldappasswd
+14:22 < sam_moore> Unless they use kerberos
+14:23 < sam_moore> (We don't want to start going into kerberos...)
+14:54 < sam_moore> Welp, I've put an LDAP server on my laptop for testing purposes
+14:54 < sam_moore> With an account "snoopy"
+14:55 < sam_moore> Seems to work... now to test it with our software
+14:55 < sam_moore> Hey, maybe we could just put an LDAP server on the BeagleBone and get a GUI LDAP editor
+14:56 < sam_moore> Oh right, you suggested that at 14:15
+14:56 < sam_moore> I like it though
+14:58 < jtanx> yah not too bad
+14:58 < jtanx> say we had an ldap server on the bbb
+14:59 < jtanx> we could even write the password manager in a different language
+14:59 < jtanx> if we wanted to make one
+14:59 < sam_moore> Yeah, exactly
+14:59 < jtanx> because it only has to interact with the ldap database
+14:59 < sam_moore> We shouldn't do that in the FastCGI program
+14:59 < jtanx> yup
+15:00 < sam_moore> I sent an email about it to everyone, suggesting PHP or python CGI to wrap around LDAP
+15:01 < sam_moore> I wonder when this system is going to start being put together though
+15:02 < sam_moore> We'll end up with a server and no hardware to control
+15:02 < jtanx> Looks like it
+15:02 < sam_moore> Those images Justin sent us look nice
+15:02 < jtanx> Yeah they look quite good
+15:07 < sam_moore> With the FastCGI program
+15:07 < sam_moore> Do you think it's better to pass options through the command line
+15:07 < sam_moore> Or have a bunch of #defines that need to get configured?
+15:08 < sam_moore> eg: To specify the LDAP server
+15:08 < sam_moore> (At the moment it's just a #define)
+15:08 < jtanx> hmm
+15:08 < jtanx> It's probably better to pass as a command line
+15:09 < sam_moore> Ok
+15:09 < jtanx> unless we're absolutely sure that the ldap address is fixed
+15:10 < sam_moore> What we can do is write a bash script that sets a bunch of variables
+15:10 < sam_moore> Then run.sh sources that and passes them all as arguments
+15:10 < jtanx> sounds good
+15:35 < sam_moore> What about things like the path to the GPIO and ADC? I figure they should stay as #defines
+15:35 < sam_moore> Since they probably won't be changing
+15:36 < sam_moore> At least not until the next BeagleBone kernel comes out
+15:36 < jtanx> hehe
+15:36 < jtanx> yeah that should stay as defins
+15:36 < jtanx> if the path does change
+15:36 < jtanx> then that probably warrants a recompile anyway since stuff may have changed with how you access it
+15:36 < sam_moore> Ok, should I put all the defines that you might want to adjust on a recompile in the same place?
+15:37 < sam_moore> common.h?
+15:37 < jtanx> what defines do we have right now
+15:37 < jtanx> that may change
+15:39 < sam_moore> Nothing major, I just want it to be flexible
+15:39 < jtanx> hmm
+15:39 < jtanx> even if you did that
+15:39 < jtanx> if you needed to change the define
+15:39 < jtanx> you'd probably be looking at changing hte code anyway
+15:40 < sam_moore> Sure, but that doesn't mean you can't put the defines in an easy to find place
+15:40 < sam_moore> For example, say someone wants to recompile this for a RPi
+15:40 < jtanx> But for stuff like 'where's the pwm path'
+15:40 < sam_moore> Given the trouble we had with pwm path confusion
+15:41 < jtanx> I'd look in the header relevant to pin control
+15:41 < sam_moore> I think it's helpful to make it easy for someone to see what we're doing
+15:41 < sam_moore> I suppose
+15:42 < jtanx> ok I guess it doesn't matter if it goes in common.h or not
+15:42 < sam_moore> Yeah, but I think I agree with you now :P
+15:42 < jtanx> ( I guess this is what ./configure and configure.h are for :P )
+15:51 < sam_moore> Sigh...
+15:51 < sam_moore> I put in a #warning to generate a warning if you tried to compile the software on something that isn't the BeagleBone
+15:51 < sam_moore> ...
+15:51 < sam_moore> And the use of #warning caused a warning
+15:52 < sam_moore> warning: #warning is a GCC extension [enabled by default]
+16:05 < jtanx> :p
+16:08 < jtanx> because of the -pedantic flag
+21:13 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Wed Oct 02 2013
+--- Day changed Thu Oct 03 2013
+09:30 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+10:26 -!- MctxBot_ is now known as MctxBot
+10:45 < jtanx> finally
+12:09 < MctxBot> guh
+12:09 < MctxBot> crappy laptop keeps crashing
+12:20 -!- jtanx_ is now known as jtanx
+12:28 < jtanx> about login_handler
+12:28 < jtanx> The result from FCGI_ParseRequest
+12:28 < jtanx> for string types
+12:28 < jtanx> should be treated as const char*
+12:29 < jtanx> I guess it really doesn't matter, unless it returns an empty string
+12:29 < jtanx> it's also not true that user/pass would be of max length BUFSIZ
+12:30 < jtanx> because of how it was defined, params has a max length of BUFSIZ
+12:30 < jtanx> but user/pass may be anywhere in that string
+12:30 < jtanx> so their max length < BUFSIZ
+12:30 < jtanx> so the bounds check makes no sense
+12:31 < jtanx> (sure, it prevents an infinite loop, but by that stage, you could be writing to locations where you don't want to anyway)
+12:31 < jtanx> besides, FCGI_ParseRequest should guarantee that they're null terminated
+12:38 < jtanx> also, whitespace (>.< :P)
+12:38 < sam_moore> True, but this is the whole "defensive" programming thing where you assume that some future unspecified developer is going to do something stupid and you attempt to minimise the damage they can cause :P
+12:38 < jtanx> while (*user && isspace(*user)) user++;
+12:38 < jtanx> char *ptr = user;
+12:38 < jtanx> while (*ptr && isalnum(*ptr)) ptr++;
+12:38 < jtanx> *ptr = 0;
+12:39 < jtanx> well
+12:39 < jtanx> by that stage you're screwed anyway
+12:39 < jtanx> not much point doing something that doesn't make sense too
+12:39 < sam_moore> You're more screwed if your program is writing to undefined locations in an infinite loop than if it's writing to a finite number of undefined locations
+12:39 < jtanx> still
+12:39 < jtanx> at least if it's infinite
+12:39 < jtanx> you'll know it crashes
+12:40 < jtanx> actually that's hardly the case
+12:40 < jtanx> because it will come across a zero at some point
+12:40 < jtanx> more often than not
+12:40 < jtanx> but anyway...
+12:40 < jtanx> does valgrind pick that up?
+12:41 < sam_moore> Hah
+12:41 < jtanx> and to be honest, by adding the BUFSIZ check, that's implying their max length when it's actually not
+12:41 < jtanx> which may be confusing in itself
+12:41 < sam_moore> The operating system should pick up a segfault on the first invalid write anyway
+12:41 < jtanx> unless
+12:41 < jtanx> the following region is writeable too
+12:42 < jtanx> eg you have a struct, members follow each other
+12:43 < sam_moore> If you really want to remove the bounds check go ahead
+12:43 < sam_moore> Either way that code does what it's meant to
+12:43 < jtanx> ok, well yeah
+12:44 < jtanx> hmm
+12:44 < jtanx> problem
+12:44 < jtanx> anyone can logout the currently logged in user
+12:44 < jtanx> oh wait
+12:45 < jtanx> sorry
+12:48 < sam_moore> My network is being terrible so I can't say much
+12:48 < sam_moore> One last argument in favour of the BUFSIZ check... if someone modifies the function that "should" be guaranteed to null terminate the string and doesn't... then you fall into an infinite loop
+12:49 < jtanx> well that's a case of too bad
+12:49 < jtanx> if it infinite loops
+12:49 < jtanx> then it shows you've done something wrong, so it'd be a good case to check what you've done
+12:50 < jtanx> if you hide that with a BUFSIZ check, you may not know there's a problem until later down the track
+12:50 < sam_moore> If you port the code to run in a kernel module or something, it's a case of instead of getting a seg fault, you suddenly wipe out all your memory
+12:50 < jtanx> with a kernel module, you'd be testing it pretty rigorously in a vm, i would think :P
+12:51 < sam_moore> Yeah, but it pays not to assume things about the sanity of other programmers
+12:51 < sam_moore> That's why all that extremely irritating "public, private" stuff is used
+12:52 < jtanx> to be honest, I'd rather have it fail fast than come up with weird issues that may/may not happen all the time
+12:52 < sam_moore> Anyway, just remove the bounds check, this is getting ridiciluos
+13:31 < jtanx> hmmm
+13:31 < jtanx> if ($http_cookie ~* "id=([^;] +)(?:;|$)" ) {
+13:31 < jtanx> set $id $1;
+13:31 < jtanx> }
+13:32 < jtanx> right now, only the control key can be sent as the one and only cookie
+13:38 < jtanx> we could get nginx to extract the desired cookie
+14:33 < jtanx> actually nah
+21:17 < jtanx> herp derp
+21:17 < jtanx> was idling in mctxuwa
+21:17 < jtanx> not mctxuwa_softdev
+21:40 < jtanx> anyway...
+21:40 < jtanx> a (the) login/logout functionality is almost done for the gui
+21:40 < jtanx> to make it work, I need to add the identify module to the modules that doesn't need login
+21:41 < jtanx> also, maybe fields to indicate if logged in or not when ident is called + if logged in, a 'human friendly' name to display for the user
+22:34 < jtanx> ok
+22:34 < jtanx> it's just about done. It auto redirects you (via javascript) to the login page if you're logged out (and vice versa)
+22:34 < jtanx> this can be disabled for debugging purposes by changing mctx.debug=true in mctx.gui.js
+22:34 < jtanx> it works quite well, I think
+22:35 < jtanx> I still haven't implemented the whole 'friendly name' thing though
+22:35 < jtanx> (e.g the 'Welcome Joe Bloggs' with the actual user name or something)
+22:40 < jtanx> test at: https://mctx.us.to:8043/test/
+22:42 < jtanx> except now there's a logout bug grr...
+22:46 < jtanx> fixed
+23:32 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
git.ucc.asn.au / matches / MCTX3420.git / blobdiff
UCC git Repository :: git.ucc.asn.au