andreasn	#startmeeting
sub-mod	i'm here
mvollmer	.hi mvo
andreasn	.hello andreasn
mvollmer	.hello mvo
andreasn	uh, did it start?
mvollmer	nope
dperpeet_	has it really started?
andreasn	did I run the wrong command?
mvollmer	zodbot isn't here
andreasn	oh
mvollmer	let's do it manually
stefw	.hellomynameis Stef Walter
andreasn	sure, I'll try to collect the notes in a manual fashion
stefw	copy paste?
andreasn	pretty much I guess
stefw	just turn off join/leave notifiactions
and you'll have what you need
andreasn	#topic Agenda
mvollmer	* SOS
stefw	* Continuous Delivery ... while Stef is away
andreasn	* systemd services
mvollmer	* hubbot
let's go?
andreasn	sure
#topic SOS-reports
mvollmer	ok, I have started hacking
first thing was to download big files from a remote machine
this is pretty similar to how we load packages
so I made a cope of that and reduced it to be a simple file server
not sure if that is overkill, but doesn't look too bad
one open issue is that we might want to read files as superuser
i haven't looked into that yet
there is a 'standard' trick that might be an alternative
data:// urls
they can be driven by javascript
but it's going to be ugly for big data
stefw	and there's limits on it
isn't there?
mvollmer	somebody said 4 GiB
stefw	wow, even in IE?
mvollmer	newer versions
stefw	if it works that would be best, no?
dperpeet_	how compatible is that across browsers and platforms?
mvollmer	i don't know
first we need to load the 50 Mibs into the browser, turn it into a 70 Mibs base64 endoced string, and then let the user download it.
i don't think one can feed such a data url incrementally
but it would allow us to get away without changing the bridge
but that's not a huge issue, or is it?
dperpeet_	I think the ability to download stuff would be valuable to have in the bridge
stefw	yeah
dperpeet_	are there security issues around this?
stefw	we have to carefully look at security
mvollmer	so I am using URLS like https://f22:9090/cockpit/@localhost//var/tmp/sosreport-f22.mvo.lan-20151019165830.tar.xz
note, empty package name
maybe too trick
y
stefw	i don't think that'll fly security wise
dperpeet_	downloader package?
stefw	i as an attacker can check for the existence of any file on the victim's system (at the very least)
dperpeet_	that could be disabled
mvollmer	you need to be authenticated
stefw	yes the victim is authenticated
and the attacker is not
dperpeet_	if it's a separate package, an admin could choose to disable it
stefw	but can use the victim's authentication
mvollmer	but the attacker can't open a websocket?
stefw	the victim does that
already has it open
dperpeet_	you could hijack the browser session, right?
stefw	no
just GET requests with the user's cookie
dperpeet_	or just the connections therein
what would be a better way to access the files?
mvollmer	so the fsread1 payload is safe, but the files server is not?
stefw	mvollmer, yes, because it transits the WebSocket which the attacker has no access to
mvollmer	cant you get a new one with the cookie?
stefw	GET requests are broadly accessible ... there's a hundred ways
mvollmer, no, there's origin protection on WebSockets
mvollmer	okay
stefw	that's one of the only reasons WebSockets can be safe
otherwise they would be a routine disaster
we probably need to use a POST
that reposts data received from the server
er, from cockpit-ws
so given all of this it may be worth examining how bad using data:// urls really are
mvollmer	right
what about adding a "publish" method to the bridge, which gives you back a random string, and you can use that random string with a GET?
stefw	yup, or POST is better
mvollmer	okay
stefw	but that's what i'm talking about there ... i think cockpit-ws needs to be involved though
to tighten up security properly
if we were to do this
dperpeet_	we could see if data:// works at all
stefw	dperpeet_, yup
dperpeet_	if it's "only for SOS" I think we're talking about a "minor" usage path for Cockpit
frequency-wise, not import
dperpeet_	so it'd be safe to impose higher requirements regarding the browser
i.e. enough memory
petervo	how big are these sos files?
i think that max length varies quite a bit from browser to browser
mvollmer	the one I made without options is about ) Mib
hah
petervo	though at least they pretty much support it
mvollmer	9 Mib
dperpeet_	I think this is more of a convenience feature anyway... if you're going to produce 100MiB of data, I think you could copy the data some other way if need be
more important is triggering the report generation
mvollmer	i don't know
dperpeet_	maybe we should look at the limits a bit first?
mvollmer	it would be embarassing to have a button to make the report, but no way to download it
dperpeet_	for data:// urls
mvollmer	yeah, I can do that
dperpeet_	we can add the download file support to the bridge later on
as a separate issue
mvollmer	stefw, so we need to be secure even when the attacker has our cookie?
dperpeet_	and target security concerns there
stefw	mvollmer, the attacker should never get the cookie
but the attacker is running in a browser that has the cookie
mvollmer	i guess I don't have a good model of web security
stefw	the attacker can make the browser do a GET with the cookie, even though the attacker does not have the cookie
the attackers access to the results of the GET may be restricted
but there's plenty that the attacker can infer from the GET request
and only certain mechanisms of producing a GET request are restricted to the current javascript domain
there's a reason we don't use GET for anything important
mvollmer	could we just always return success?
stefw	for example our "/ping" handler, on purpose, does not provide any information about cockpit
mvollmer	but it also has the special cross-origin headers, no?
anyway, I don't need to learn all this here.
stefw	mvollmer, sure, but that's to make legitimate uses easier
i would say we need to figure out the limitations of data:// urls
before we sit down and design a mechanism to do safe GET or POST requests
mvollmer	okay
petervo	this seems to say 2M on chrome
https://code.google.com/p/chromium/issues/detail?id=44820#c1
but maybe that's old
mvollmer	I'll try
next topic?
andreasn	yep
# topic Continuous Delivery
stefw	i'll be away at systemd.conf
during the 0.83 release
until now the CD container
and cockpit credentials
have been on my machine
i'd like to move them somewhere else
any suggestions?
dperpeet_	files.cockpit.org?
cockpit-project.org
I mean
stefw	the downside is that's a publicly accessible server
is that a problem?
dperpeet_	it should be fairly secure, as such things go
stefw	yeah, i wouldn't be against that
just figured i'd ask everyone
dperpeet_	worst case is that someone kills the github repo, but we have local copies
do we have another vpn protected server that we can all access?
stefw	we do
but even more people have access to it
so i guess it's a tradeoff that way
mvollmer	as root even, no?
stefw	yup
so i'll use files.cockpit-project.org for now? is everyone okay with that?
mvollmer	yes
dperpeet_	in that case I'm for files.cockpit-project.org, I think the security is sufficient for the current demand
mvollmer	(it's not your personal signing key, right?=
stefw	not mine
cockpit users
mvollmer	ok
stefw	er
cockpit user's
the one that creates the releases, pushes them out, etc.
dperpeet_	if we keep local copies and they become asynchronized, that would be bad
stefw	all done?
andreasn	#topic Systemd Services
dperpeet_	so, I talked with andreasn last week
basically we want to keep the design very close to what it is right now
andreasn	for now at least
dperpeet_	yes
we use the listing pattern
and the expandable rows for each entity (service, timer...)
these then have the info you could previously see by clicking on the item
stefw	do you have a screenshot?
dperpeet_	but now it's tabbed (info, journal) and you don't lose your place in the list
stefw	i can use in my talk?
dperpeet_	I didn't make one before I broke the stuff earlier
I'll have one by tomorrow morning
stefw	cool
andreasn	I'm happy to try things out as soon as you have a branch that works
dperpeet_	the one thing we decided to get rid of is the partition into enabled/disabled/static
instead this can go into the row as a column / extra info
the goal is that besides the current buttons we can add one for "all"
dperpeet_	so you can see the entire list, without bothering about the type
stefw	right, we'll need filters for that shortly
but i guess not in the first revision
dperpeet_	exactly
andreasn	yes
dperpeet_	the current buttons are basically hardwired filters
andreasn	next up?
dperpeet_	on the implementation side, I've used petervo's work in https://github.com/cockpit-project/cockpit/pull/2884 as a template
for the angular singleton pattern
one last thing: poke me about that screenshot if you don't have one by tomorrow morning, stefw
stefw	ok
dperpeet_	thanks!
dperpeet_	(end of topic)
andreasn	#topic hubbot
mvollmer	yep
so
I have shut down hubbot
and run the cockpit-verify container instead
works like a charm
super work, stefw
stefw	yay
andreasn	neat
stefw	i've been thinking of some next steps ... to be tackled later
such as github scanning
mvollmer	yeah
stefw	and coordination between servers, etc
so they can all target all OS's essentially
mvollmer	it's not essential, but still nice to see what the machine is up to
stefw	but lets not get ahead of ourselves
dperpeet_	stefw, we can collaborate some on that on Wednesday
stefw	right, i imagined if we have github scanning
mvollmer	I'd just like to have the output of testinfra.py somewhere
stefw	then we can have the scanner publish a priority list somewhere
mvollmer	yes
stefw	anyway, are we okay with waiting on that for a week?
dperpeet_	as long as the tests work, the status is just a nice addon I think
mvollmer	and the sink could give some nicer view into what it currently running, and was has finished
stefw	or we could put it in an issue
and talk about it therte
well, an idea is to make the sinks even less central to things ... so i hope we can avoid doing too much with the sink
mvollmer	it would also be nice to automate the deployment of the infra-verify container even more
stefw	yeah, maybe using the 'atomic' command
dperpeet_	the scanner could very well be a separate container
stefw	dperpeet_, yes it would be
mvollmer	so I'll properly put hubbot to rest in the next days
stefw	anyway ... i think we've passed a massive milestone
distributed testing is hard ... has been hard ... but we've made it work ... so far
mvollmer	yes, this very very nice
heh, our challange is to test concurrently on a single system :-)
stefw	i'd like to move away from that target
and have each check-verify --github=next pick an OS that the scanner has singled out
mvollmer	by just cranking up the jobs?
stefw	so the scanner goes through github
and marks what needs to be tested
there can be two scanners if we like failover
and then the verify containers, just pick things that need to be tested, and work their way through the list
dperpeet_	stefw, we have to keep an eye on github API calls (there are limits)
it's better to have hooks somewhere
stefw	well that's a separate issue imo
but we can use fedmsg
to proxy github webhooks into messages
as other projects do
anyway, so i guess my point here is that we should do these things one step at a time ... i don't think this is a "stop the presses" style work anymore
mvollmer	I have one more topic: fancy logs
stefw	oh, they're nice
andreasn	sure, end of topic for hubbot?
stefw	and the fact that they can be updated by anyone
mvollmer	yes
andreasn	#topic fancy logs
mvollmer	so, there is now a simple log.html file in .../test/files
it will be dropped into the directory with the log, right from the start
and the "Details" links on github point to it
the idea is that we evolve that page into something really nice
whenever we need a break from the production code :-)
stefw	great
dperpeet_	I very much like the separation of log + display that we now have
stefw	yes, most of the logic is there
just needs styling, right?
dperpeet_	yes
andreasn	I can take a look
stefw	mvollmer, can you link to an example?
dperpeet_	https://fedorapeople.org/groups/cockpit/logs/pull-3112-8e19e155-fedora-22-x86_64/log.html
listing pattern *cough*
mvollmer	adding colors and links to the log might be slightly more involved
mvollmer	yep, that one. :)
andreasn	it's just a big <pre id="log"> right now, right?
mvollmer	one known issue:
the log.html file is pulled from the branch of the pull request
that doesn't work sometimes
and then it just reads "Not found"
stefw	pull from master?
mvollmer	then you can't see your change in action
stefw	i guess it's hard to test out changes
right
so why does it sometimes not work?
mvollmer	i think it's a ..... race
stefw	i would suggest that the urllib call in the sink is doing the wrong thing
it should throw an error
instead of output the contents of 404
mvollmer	raw.github.com might be a slightly slow
dperpeet_	we should catch that an fallback on master... or try again / longer?
mvollmer	yep
stefw	mv,
mvollmer, if the urllib call fails (and we should be able to detct that properly)
leave the extras statement in
and process it again at status end
mvollmer	yes, that'll work
okay, eot
andreasn	# topic Open Floor
stefw	my systemd.conf talk ...
it's short, so it'll show some screenshots of Cockpit
but then dive right into how we remote System APIs
and go then deeper into DBus
talk about Introspect()
used with making Method calls
then about how we monitor properties
talk about ObjectManager
and tell them to use it
what happens if no ObjectManager
Introspect() salat
talk about making sure DBus apis ar eremotable
asking for networkd API
Suggest splitting out sdbus
talking amout message catalog + journal and our issues dashboard
that's really what i'm going to cover in a nutshell
andreasn	sounds good
andreasn	how long is the talk? 20 mins? 30 mins?
stefw	20 min
will be tight
andreasn	yep
dperpeet_	sounds compact
stefw	may have to cut something
dperpeet_	I can take a look at the slides tomorrow if you want
stefw	ok, they're very basic, but i'll send them around tomorrow
will be done with them today
dperpeet_	great, thanks
andreasn	I can take a look to
too
ok, I guess that was it
#endmeeting