#musicbrainz-devel

:)

now that there are better tools for this.

you just know how much free time I have. ;)

so, I posted a pile of servers for free or really really cheap.

we should probably work out a deployment manifesto at some point

ZERO inquiries.

"only deploy with .debs, deployment activation must be done via fabric" etc"

ocharles: yeah, thankfully everything is pretty simple

I did a bit of reading into Linux containers yesterday

they are very cool

LXC?

yea

interesting. very light weight VMs.

is the focus more on sysadmin than security or both?

meaning, can untrusted services run in a container?

the idea is controlled isolation

understood.

but how is isolation defined? :)

if you want to isolate a process to only see eth0 and mount /machines/debian as /, it can do that

however you define it. it can do isolation on various levels - pid, file systems, network interfaces, maybe a bit more

interesting.

http://docker.io builds on top of it, like vagrant builds on top of virtualbox

ruaok: containers share the same kernel as the host, vulnerabilities in the interface are perhaps more likely than with real VMs.

warp: thats exactly what I was trying to get at, thanks. ;)

slightly OT… with bartendro, the idea of shipping an RPI as part of a product seems very cool.

until you think about the fact that you're shipping a unix box.

and all the security and field update implications that come with it.

would chef be a useful tool for doing in-field updates?

I'm already planning on having everything in a deb.

what's an in-field update?

but ideally, it would be quite simple to update bartendro in the field.

deployed to customers.

ruaok: that's probably why embedded systems use busybox and put as little as possible other binaries on the device.

nikki_: logged in fine

well, updating a bartendro means it has to have a net connection; you want to make sure to only do it when the device is not in use - do you want it manually initiated, or silent in the background?

warp: busybox is more for a small footprint IIRC

and I fucking hate it. thats why I love RPI.

its a full blown box.

kepstin-work: yes, net connection assumed, manually initiated.

ruaok: then you basically just need some ui that does an apt-get update; apt-get (dist-?)upgrade, reboot.

ruaok: sure. but it also means the attack surface can be greatly reduced, which means you don't need to worry about security updates as much.

probably combine it with a notification system that runs the update periodically and tells you if there are pending updates

warp: but, its about carefully striking a balance between hackability and security.

(and of course, you'll have to provide an sd card flash image and instructions for de-bricking, should it not come up from an update)

kepstin-work: yeah, that might just be enough.

kepstin-work: yep, that is all cake

for instance, I want the bot to be 100% hackable.

that means, there needs to be an easy way to log in.

ruaok: yep, it's a tradeoff.

but the bot should not have a back-door that people from the street can exploit to waste your booze

on the one hand you want it hackable, on the other hand you need it to run as a reasonably-secure kiosk mode

kepstin-work: ding. exactly that.

ruaok: the easiest way to secure it seems to be to just not connect to to anything. if you want to hack on it, plug in the ethernet cable, disconnect when done.

I think I need to lock down all the access to the box and then distribute an SSH key with which people can log in.

but even that leaves the door open.

do you plan to hook up a touchscreen directly to the rpi, or how is the ui connected?

warp: the main point of the bot is to have a wifi connection with which you order your drink.

we dont have to worry about internet attacks, but local area attacks.

kepstin-work: the bot only has a web UI

ruaok: you want very careful firewalling then. The only thing exposed on the wifi should be the web ui; admin should require a hardwire connection

ah!

ruaok: what kepstin-work says. the wifi thing should be firewalled and not allow ssh login.

that seems quite sensible.

allow SSH connections only over wired interface.

heh. my drinkbot is going to have a firewall. :)

:D

I can already push to github from it. which is freaking awesome. :)

a firewall and a ro mount of / is probably enough for a drinkbot

even then, I need to secure the WS for the bot.

of course, the alternate method of admin is to hook up a keyboard and monitor via hdmi/usb.

right now, anyone can sign into the access point and do a GET /ws/clean and probably waste $50 of booze. :)

lol

do you plan to have the drinkbot act as a wireless access point, or connect to an existing wifi network?

kepstin-work: that is physically hard.

the former.

it is essentially a captive portal

ruaok: GET shouldn't be use for that kind of stuff :)

and the drink menu appears on the "sign into wifi access point" screen

warp: :)

warp: yeah. there are loads and loads of things that needs to be cleaned up.

get ws/clean should tell you the amount of bot usage since the last cleaning cycle. should use POST to do a clean ;)

it was always about getting the next hardware iteration running.

ruaok: good luck, have fun!

now that that is done, I can finally improve the software.

kepstin-work: probably model /clean as a boolean, and PUT a new value to change the system state

i don't think you append to the 'clean' resource :)

so yeah, there's basically two levels of auth - 1. ensure that the person accessing is in the party - this could probably be done via a wifi password, and 2. restrict some commands to admin - this needs webservice auth.

kepstin-work: each of the pumps keeps track of how many turns (or fractions of a turn) its made.

for hose life and accounting.

kepstin-work: yeah, the web service auth is the painful part.

I already have simple web site login for making drinks.

so, it needs to have javascript based auth. whats good for that/

?

could probably get by with just a shared secret known to both the bot and the admin user; perhaps generated during install/setup.

you could do some fun 2-factor authentication with the drink bot, seeing as you have to be in physical distance of the bot :)

"How many times did the red LED flash?"

ocharles: heh

"How many shots did the bot force you to down before showing you this page?"

kepstin-work: we want to allow anyone with the password to the bot to log in and make drinks.

ocharles: lol

how many fingers is the bot holding up?

ruaok: yes, but also limit certain commands to the admin/bot owner I presume?

kepstin-work: yes

the admin screen is already protected via login (not on the demo I just linked to, but in production)

should get a usb fingerprint scanner and hook it up ;)

yep, all sorts of POS integration bits have been requested.

now if you could do reliable age verification with a fingerprint scanner, then we'd be all over that

ijabz: building recording index at 42%

seems to be moving a bit faster now. :)

heh, better hope you have good concurrency control so people can't exploit race conditions to get free drinks ;)

though I guess the whole physical machine thing imposes quite a bit of serialization :)

if someone requests a drink while a drink is in process, does it refuse, or does it queue?

ocharles: there is no concurrency control. :( not yet. thats is why we have logins limited to a few people.

kepstin-work: undefined. :)

once I get some uninterrupted time to work with the bot, I'll fix all that.

ijabz: http://github.com/metabrainz/mmd-schema.git

there is a lot of technical debt accumulated in that codebase.

ocharles: yay!

ocharles, um shouldn't it be on bitbucket ?

ijabz: most of our stuff is on github only. if some contributors prefer bitbucket, we should have a copy on bitbucket as well.

ijabz: bitbucket is being trialed for reviews

until then, github is our canonical repository host

nikki_: which is?

emails

Oh I didnt really want to have to learn the gitthub way just to start al over again for bitbucket

ijabz: they are the same, but point taken

thought we had decided on bitbucket, when does that review end

no

no decision, and no deadline :)

AFAIK, no decision has been made yet.

that should go in the next meeting I think - but I can't edit the topic

irssi seems to only let me do it once, then breaks

ocharles: weird

Freso_laptop has changed the topic to: ?? SMILING FACE WITH SUNGLASSES week | http://musicbrainz.org/#devel dev meeting moved to TUESDAY | Agenda: Reviews, schema change testing (ocharles), review location decision

warp: more specifically, I want emails to be sent about new reviews and comments on reviews, like review board and github do, but bitbucket recently broke that and you only get them if you have commit access, which I don't have

ocharles: you're welcome.

nikki_: ah, so giving you commit access would solve it (for you) ?

warp: But we can only grant commit access to 5 people or so.

Freso_laptop: wtf?

warp: ?

Freso_laptop: oh, more ppl is a paid account you mean

warp: Yeah.