Mar 18 22:23:36 blackace	as the first order of business, I submit that GIMLI is a terrible name for a system management tool, and any package containing Frodo.php is clearly unacceptable for production use ;)
Mar 18 22:26:08 code|work	figures
Mar 18 22:27:40 blackace	would you put Frodo in a production environment?  of course not :P
Mar 18 22:27:56 code|work	i would if i wrote it :)
Mar 18 22:28:45 code|work	you have a valid point there
Mar 18 22:29:06 code|work	but it makes a very nice development name
Mar 18 22:29:53 code|work	and since i'm coding the mockups, i'm using GIMLI as the name
Mar 18 22:30:13 agaffney	heh
Mar 18 22:43:14 code|work	what's the hex for red?
Mar 18 22:44:27 blackace	#FF0000
Mar 18 22:44:37 blackace	#<R><G><B>
Mar 18 22:44:54 code|work	thx
Mar 18 22:45:46 blackace	agaffney: enter the installer room
Mar 18 22:50:19 blackace	ok, the room is moderated, but I just set it so everyone is automatically voice when they enter...that's the only way I can see that it allows us to devoice people vs. banning them outright
Mar 18 22:57:30 code|work	blackace: have you read my draft requirements doc?  (still waaaay in progress)
Mar 18 22:58:05 blackace	code|work: what draft requirements doc?
Mar 18 22:58:41 codeman	http://dev.gentoo.org/~codeman/GIMLI/requirements.odt  <-- updated with initial design for queuing system.
Mar 18 23:03:23 code|work	so how would the SSH based thing work
Mar 18 23:03:35 code|work	just the hostname fingerprint?
Mar 18 23:04:29 agaffney	is there much difference function different for identify verification between a host key/fingerprint and a cert generated by openssl?
Mar 18 23:04:33 code|work	i'm not good at conceptualizing wrapping the xmlrpc communication in some SSH thing
Mar 18 23:04:38 agaffney	bah, functional difference
Mar 18 23:05:03 agaffney	code|work: we wouldn't want to wrap it that way
Mar 18 23:05:09 code|work	certs you can revoke
Mar 18 23:05:10 blackace	ssh master key, clients are given a public key, they connect to the server and say hey, I'm me...the server ssh's to the client and if it succeeds says "ok, I gave you that pubkey"...this can be done two ways so they mutually agree on their identities
Mar 18 23:05:12 agaffney	that would involve tunnels
Mar 18 23:05:39 code|work	if you thought the client got comprimized you could just revoke the cert and they'd be isolated
Mar 18 23:05:47 blackace	ssl is probably the way to go, but it's a pita to generate certs
Mar 18 23:05:57 agaffney	code|work: why do we even need to revoke a cert? you could just lock out the client through other means
Mar 18 23:06:10 code|work	quite true
Mar 18 23:06:20 *	blackace notes the trust goes the other direction
Mar 18 23:06:35 blackace	clients trust the server, not necessarily the other way around
Mar 18 23:06:41 agaffney	it should probably go both ways
Mar 18 23:06:49 agaffney	but definitely the former
Mar 18 23:06:52 blackace	yeah, but the important part is client->server
Mar 18 23:06:53 code|work	blackace: what concerns me about the SSH keys is that they help you login to the machine.. SSL certs wouldn't do that
Mar 18 23:06:56 blackace	exactlt
Mar 18 23:07:13 agaffney	code|work: SSH keys != host fingerprint
Mar 18 23:07:52 code|work	what's the difference then between SSH keys and GPG keys?
Mar 18 23:08:13 blackace	not much, just that admins will generally know more about ssh than gpg
Mar 18 23:08:13 agaffney	code|work: you're thinking about keys for user identification
Mar 18 23:08:30 agaffney	we'd just want to use the host identification key
Mar 18 23:08:40 blackace	agaffney: gpg can be used for machine id as well, it's just not designed that way...at all :P
Mar 18 23:08:40 agaffney	the thing ssh checks when it connects to a server
Mar 18 23:09:24 code|work	agaffney: so what would happen if the gimli server had to be reinstalled and the key was changed.
Mar 18 23:09:33 code|work	you'd have to go out to each client and fix it, right?
Mar 18 23:09:43 agaffney	or restore the old key
Mar 18 23:09:49 agaffney	the same thing would happen with just plain ssh
Mar 18 23:09:57 agaffney	if you had a bunch of people SSHing to a machine
Mar 18 23:10:08 code|work	but that might not happen w/ certs, right?
Mar 18 23:10:16 agaffney	and it's host key changed, everyone's clients would start warning them about a man in the middle attack
Mar 18 23:10:20 blackace	no, certs would be the same way
Mar 18 23:10:25 agaffney	code|work: same thing
Mar 18 23:10:27 code|work	oh, ok
Mar 18 23:10:33 agaffney	you'd either generate a new one or restore the old one
Mar 18 23:10:36 blackace	there's no way around the problem of the master losing it's cert or key
Mar 18 23:10:46 code|work	well i think the ssh keys works then for host identification
Mar 18 23:10:56 code|work	how exactly would that work code-wise tho?
Mar 18 23:11:03 agaffney	code|work: of course, that brings ssh in as a dep
Mar 18 23:11:12 agaffney	although, that's present on most servers
Mar 18 23:11:15 blackace	isn't ssh in system?
Mar 18 23:11:15 agaffney	it'd be silly not to have it
Mar 18 23:11:19 code|work	just do a trial connection and then if that works disconnect and try the XMLRPC server?
Mar 18 23:11:24 agaffney	blackace: for x86 and possible amd64
Mar 18 23:11:34 agaffney	code|work: bleh, no
Mar 18 23:11:35 blackace	agaffney: ppc as well
Mar 18 23:11:53 code|work	agaffney: i'm very satisfied with having ssh as a dependency
Mar 18 23:12:06 agaffney	code|work: yeah, I didn't have a real problem with it
Mar 18 23:12:10 agaffney	just throwing it out on the table
Mar 18 23:12:11 code|work	since then we can include it as a base protocol for job transfer if need be
Mar 18 23:12:42 blackace	see, this is one of the reasons why using http would be good...it already supports everything we need
Mar 18 23:12:55 blackace	we can do tls
Mar 18 23:13:54 agaffney	http makes it less flexible for auth
Mar 18 23:13:57 code|work	blackace: read the queuing system stuff in the doc.  everyone i've talked to about this says that the XMLRPC server is the way to go
Mar 18 23:14:02 agaffney	with xmlrpc, we can do it however we want
Mar 18 23:14:24 blackace	agaffney: right, like reinventing the wheel....some more?
Mar 18 23:14:32 agaffney	indeed!
Mar 18 23:14:32 blackace	code|work: I don't have openoffice.
Mar 18 23:14:58 code|work	well that's not good
Mar 18 23:15:15 blackace	yes it is
Mar 18 23:15:23 *	blackace dislikes java bloat
Mar 18 23:16:52 agaffney	it can be compiled without anything java
Mar 18 23:17:11 code|work	i've got creating/editing/deleting of roles working in my mockup
Mar 18 23:17:28 blackace	ok, good for it, I'm not compiling it on my 1.4GHz pentium-m laptop right now :P
Mar 18 23:17:56 code|work	openoffice-bin
Mar 18 23:18:00 blackace	so, can we talk about _why_ xmlrpc is the shiznit for this?
Mar 18 23:18:15 code|work	because it's designed to be flexible, which is EXACTLY what we want
Mar 18 23:18:23 blackace	...
Mar 18 23:18:27 blackace	flexible != exact
Mar 18 23:18:36 code|work	it's designed to transfer data
Mar 18 23:18:57 agaffney	...
Mar 18 23:19:04 code|work	i don't like the idea of being limited by HTTP
Mar 18 23:19:20 blackace	no, it's designed to be an IP socket replacement to connect pieces of one app written in different languages
Mar 18 23:19:24 agaffney	blackace: because xmlrpc allows us to easily use different languages for different modules
Mar 18 23:19:34 blackace	agaffney: what modules?
Mar 18 23:19:41 code|work	any module
Mar 18 23:19:43 blackace	agaffney: we're talking client app, and server app
Mar 18 23:19:50 agaffney	frontend/backend for one
Mar 18 23:19:57 blackace	can you guys start being way more specific for me?
Mar 18 23:20:13 *	agaffney enjoys being vague
Mar 18 23:21:44 code|work	blackace: i still can't see what you have against the XMLRPC
Mar 18 23:21:47 blackace	vague doesn't explain why you see things so differently from how I do
Mar 18 23:21:54 agaffney	blackace: basically, xmlrpc makes it easier to handle the requests
Mar 18 23:22:00 code|work	blackace: a good example btw is polling and responding to polls
Mar 18 23:22:21 agaffney	and that makes things easier on us
Mar 18 23:22:30 blackace	code|work: I have nothing against xmlrpc specifically, I dislike the fact that it forces us to reinvent the wheel for almost everything we need to do with it.
Mar 18 23:22:56 agaffney	the xmlrpc server also allows for "easy" persistence
Mar 18 23:22:59 blackace	this isn't for an ongoing connection
Mar 18 23:23:02 code|work	the thing's practically already all written, it's all in gliserv.py
Mar 18 23:23:13 blackace	we don't want the xmlrpc session up all the time
Mar 18 23:23:21 blackace	it's not designed for what we're doing
Mar 18 23:23:23 code|work	blackace: he's talking abuot the server daemon persistance
Mar 18 23:23:36 agaffney	right, server-side data persistence
Mar 18 23:23:41 blackace	code|work: and I'm talking about connection persistence
Mar 18 23:23:52 agaffney	and I'm not, so it doesn't matter
Mar 18 23:23:54 code|work	blackace: well then http timeouts could be a bitch
Mar 18 23:24:02 blackace	timeouts during what?
Mar 18 23:24:13 blackace	wtf are we going to be sitting doing nothing with a connection open?
Mar 18 23:24:18 code|work	transfer of large jobs (when the job includes the data)
Mar 18 23:24:29 blackace	timeouts are idle time...
Mar 18 23:24:37 blackace	if data is flowing...no timeouts
Mar 18 23:24:52 blackace	think of what the client is doing as an emerge sync...
Mar 18 23:25:00 code|work	eh. not gonna argue that one
Mar 18 23:25:01 blackace	it's getting info on what's available
Mar 18 23:25:07 agaffney	there aren't going to be any persistent client->server connections
Mar 18 23:25:26 blackace	and yet persistent client->server connections is what xmlrpc is designed to do
Mar 18 23:25:43 blackace	we need something more transactional to be honest
Mar 18 23:25:47 agaffney	xmlrpc is over http
Mar 18 23:25:55 agaffney	http isn't supposed to be used persistently
Mar 18 23:25:59 blackace	the server is supposed to be in a passive role from a connection standpoint
Mar 18 23:26:23 blackace	the client is just getting info from the server...no interactivity is required past authentication
Mar 18 23:26:28 agaffney	from what I can tell with the xmlrpclib in python, it only connects when it sends a request
Mar 18 23:26:32 agaffney	and then disconnects
Mar 18 23:26:51 code|work	agaffney: what happens after it registers?
Mar 18 23:27:07 code|work	something gets stored server-side to say it connected before?
Mar 18 23:27:18 agaffney	that's not currently handled
Mar 18 23:27:37 code|work	how does it work in gliserv?
Mar 18 23:28:00 agaffney	with the current stuff (which will all get scrapped eventually), the client passes along its MAC to identify itself
Mar 18 23:28:14 agaffney	and gliserv has a list of MACs that have "identified"
Mar 18 23:28:17 agaffney	it's clunky
Mar 18 23:28:33 blackace	why is the client identifying itself to the server?  shouldn't that be the other way around?
Mar 18 23:29:28 blackace	ok
Mar 18 23:29:32 code|work	blackace: i see it as equally important both ways
Mar 18 23:29:57 code|work	dude i just started the admin stuff
Mar 18 23:30:00 code|work	that's it
Mar 18 23:30:21 blackace	ah, I thought you were trying to show me something to answer my question :)
Mar 18 23:30:32 code|work	no
Mar 18 23:30:42 blackace	ok ok, sorry :)
Mar 18 23:30:57 code|work	unless your question was "does that checkbox in the delete role screen not kick ass?"
Mar 18 23:31:28 blackace	ah, no, but the bright fucking red table that makes my eyes bleed does :P
Mar 18 23:31:47 *	blackace blinks tears
Mar 18 23:31:55 code|work	thats as "are you sure" as i get
Mar 18 23:32:33 code|work	ok can we please agree on XMLRPC for now and move on with the connection process here?
Mar 18 23:32:50 code|work	blackace: if it doesn't work out, you have permission to beat us
Mar 18 23:32:54 *	blackace still hasn't heard why it's necessary
Mar 18 23:33:10 blackace	gah
Mar 18 23:33:20 blackace	it's a pull-based system
Mar 18 23:33:27 code|work	no
Mar 18 23:33:39 code|work	pulls occur, but responses are also sent
Mar 18 23:33:42 blackace	...we agreed on it being pull-based a long time ago
Mar 18 23:33:56 blackace	code|work: ...you're joking right?
Mar 18 23:34:15 code|work	and because we await replies on "did i get this?", xmlrpc is good.
Mar 18 23:35:22 code|work	it is pull-based the way youre talking about it.. but it's not just pull and the server assumes all goes well.
Mar 18 23:36:05 blackace	course not, but feedback like that can be accomplished by pull as well...and we don't have to reinvent the ssl/tls wheel
Mar 18 23:36:22 code|work	whoever said we had to do tat?
Mar 18 23:36:44 blackace	SecureXMLRPC?
Mar 18 23:37:01 code|work	already written
Mar 18 23:37:07 code|work	samyron wrote it
Mar 18 23:37:09 blackace	a reinvented wheel
Mar 18 23:37:11 code|work	for python
ar 18 23:37:21 blackace	untested, unaudited, new
Mar 18 23:37:32 code|work	it's tested.  it's used by gliserv
Mar 18 23:37:40 agaffney	it is tested, it uses python's SocketServer and OpenSSL modules
Mar 18 23:37:47 agaffney	it just ties them together
Mar 18 23:38:01 agaffney	so it's only as unaudited as python itself
Mar 18 23:38:26 blackace	so by extension, the random python script on the forums is tested and audited as well eh?
Mar 18 23:38:43 *	agaffney rolls his eyes
Mar 18 23:38:59 code|work	fine
Mar 18 23:39:00 *	blackace writes a python script that recursively unlinks files starting at /, but hey, it's been audited, it's as secure as python...
Mar 18 23:39:08 *	blackace rolls his eyes
Mar 18 23:39:28 code|work	if you really are gonna continue fighting this lets jsut change entire topics and talk about the user management
Mar 18 23:39:57 blackace	s/fighting/trying to discourage working harder not smarter/
Mar 18 23:40:14 blackace	code|work: what users are we talking about?
Mar 18 23:40:21 code|work	blackace: read the doc
Mar 18 23:40:28 blackace	code|work: ...
Mar 18 23:40:32 code|work	i can post it in a different format if you like
Mar 18 23:40:36 blackace	that would help
Mar 18 23:40:42 code|work	.rtf?
Mar 18 23:40:47 blackace	sure
Mar 18 23:41:35 agaffney	http://rafb.net/paste/results/p5jaCm96.html
Mar 18 23:41:46 agaffney	blackace: that's the important part of SecureXMLRPCServer
Mar 18 23:42:09 codeman	http://dev.gentoo.org/~codeman/GIMLI/requirements.rtf
Mar 18 23:42:09 agaffney	nothing custom or magic
Mar 18 23:42:36 agaffney	just initializing the pyopenssl stuff
Mar 18 23:42:39 *	blackace mumbles also no error checking
Mar 18 23:42:59 agaffney	the error checking is in glisev
Mar 18 23:43:01 agaffney	rv
Mar 18 23:43:09 agaffney	if there's an exception, it falls back to the non-SSL
Mar 18 23:44:37 *	codeman gets a soda while blackace reads :)
Mar 18 23:45:15 *	agaffney waits for the oven to preheat
Mar 18 23:45:22 codeman	i really want you guys to pick this doc apart
Mar 18 23:45:31 codeman	so that it ends up being solid
Mar 18 23:45:41 codeman	and that makes it a lot easier to code
Mar 18 23:45:49 blackace	code|work: first thing that hits me reading about roles, what if my admins are in groups like db, frontend, workstation, or one set of admins should only be able to 'update' one system?  would I have to create update_system1, update_system2, update_system3, update_db, update_frontend, etc. roles?
Mar 18 23:46:34 codeman	hrm
Mar 18 23:46:35 blackace	ie. user->role->machine doesn't make sense, whereas user+role->machine/machine group/role does
Mar 18 23:47:48 codeman	sounds like a good idea to me
Mar 18 23:48:06 blackace	or maybe instead of roles have a more freeform tags concept, so that you can tag users and machines, and specify roles that have to match combinations (filter if you would) of tags between user and machine before an action is allowed
Mar 18 23:48:33 codeman	well yeah
Mar 18 23:48:47 codeman	the "role" on the client end is abstract
Mar 18 23:49:00 codeman	it's basically defining the permissions with which the job has to run
Mar 18 23:49:38 codeman	so like the "update" role may only have the ability to run "emerge -u world" on certain systems, but i guess that doesn't mean it could do other things on other clients... or is that bad to have it be ambigous?
Mar 18 23:49:58 blackace	hmm
Mar 18 23:50:02 codeman	or i guess
Mar 18 23:50:28 codeman	the "db" role could do everything on the database server and very little, maybe updates only, on the other servers.
Mar 18 23:51:31 blackace	well, it seems permissions would be more machine oriented vs. user right?
Mar 18 23:51:51 codeman	which permissions/
Mar 18 23:53:04 codeman	i think i like your way better
Mar 18 23:53:19 codeman	of having more or less set defined roles as to what they can do
Mar 18 23:53:41 codeman	and then assigning users as well as roles to clients ... and separately users to roles.
Mar 18 23:53:57 codeman	... and roles to clients.
Mar 18 23:54:14 blackace	so, allow grouping machines and cascading permissions, so I create a 'db' machine group and add machines to it...then I add an "update" job to the 'db' machine group and specify groups of users and individual users who can run it?
Mar 18 23:54:36 blackace	ie. work from the machines out instead of users out?
Mar 18 23:54:59 blackace	s/machines/clients/ in everything I just said :)
Mar 18 23:55:31 codeman	in your logic then, users wouldn't have to belong to roles
Mar 18 23:56:05 codeman	it would just be roles->machines and then users->machines  and if the user is assigned to the machine then they can do any of the things the roles assigned to that machine can do?
Mar 18 23:56:10 blackace	mmm, no I guess not...they would more be granted permissions
Mar 18 23:56:31 blackace	I guess I'm saying groups of users where you're saying role?
Mar 18 23:56:40 codeman	yes
Mar 18 23:56:55 codeman	and permissions also meaning role
Mar 18 23:57:16 blackace	eh, I'm not lumping permissions and groups together though
Mar 18 23:57:22 codeman	you have two separate things i was doing with one "role"
Mar 18 23:57:54 blackace	right, because I don't think any user with the db role should be able to do any job with the db role
Mar 18 23:58:13 blackace	I'm thinking more unix permissions
Mar 18 23:58:42 codeman	why would you assign a client the db role unless you wanted people who could do db role things to be able to do those things on that client?
Mar 18 23:58:43 blackace	users, groups, files that are set excutable for a user or group or others
Mar 18 23:58:59 blackace	I wouldn't
Mar 18 23:59:05 blackace	group != role
Mar 18 23:59:13 blackace	role == permission
Mar 18 23:59:40 codeman	agaffney: any thoughts here?
Mar 19 00:00:14 blackace	so, if an individual client or a group of clients has an "update" job, and the "update" job lists me or my user group (or role) as being able to use it, then I can, otherwise, I can't
Mar 19 00:00:57 blackace	think mysql grant table
Mar 19 00:00:57 codeman	well the grouping of clients is already in the design
Mar 19 00:01:11 codeman	tho not multiple groups per client
Mar 19 00:01:19 codeman	dunno how well that would work
Mar 19 00:01:29 blackace	GRANT PERMISSION update ON * TO admins;
Mar 19 00:01:42 blackace	GRANT PERMISSION update ON db.* TO db_admins;
Mar 19 00:02:06 blackace	REVOKE PERMISSION update ON db.* FROM BenUrban;
Mar 19 00:02:19 BenUrban	...
Mar 19 00:02:22 BenUrban	do you mind?
Mar 19 00:02:29 blackace	aww, was just an example :P
Mar 19 00:02:43 blackace	it's another BenUrban, yeah, that's it :P
Mar 19 00:02:59 BenUrban	suuure
Mar 19 00:03:03 code|work	lol
Mar 19 00:03:39 blackace	anyways, you see what I mean?  don't you think permissions should be pretty granular?
Mar 19 00:04:38 codeman	yes
Mar 19 00:05:09 blackace	I'm not saying we should mimic mysql grant tables outright, but being able to grant a privilege to a group and deny it to one or two members of that group or vice versa would be pretty nice
Mar 19 00:05:25 codeman	i have been agreeing with you for 20 minutes.. i'm just trying to figure out how i can implement it in the grand scheme
Mar 19 00:05:45 blackace	yeah, that's the hard part...thinking it is easy :)
Mar 19 00:06:04 *	blackace is still waiting for the telekinetic programming helmet
Mar 19 00:06:25 codeman	blackace: one of the things i had been talking about earlier was for the second stage of authentication being encrypting the XML job with a GPG key of the "role"
Mar 19 00:07:09 codeman	kindof like <job> <role>update</role><jobdata>@$&%&PGB@)$BR)$^U@$)*@^$</jobdata></job>
Mar 19 00:07:24 blackace	hmm, that's a thought...you wouldn't even really need a first stage that way either...who cares if a client or an imposter grabbed it, they wouldn't be able to do anything with it
Mar 19 00:07:33 codeman	so that only clients with that role could decrypt the message
Mar 19 00:08:03 codeman	blackace: it's two-level security.. an absolute *minimum* in this type of system
Mar 19 00:08:28 blackace	codeman: for what purpose?  what is being protected?
Mar 19 00:08:39 codeman	you should see this prog bcoca pointed me to earlier in the week.. guy was using passwordless root SSH keys for everything
Mar 19 00:08:56 *	blackace isn't saying we should do that :P
Mar 19 00:09:17 codeman	blackace: the job data will include what needs to be done
Mar 19 00:09:26 codeman	if it is a script, it may include the script itself
Mar 19 00:09:37 codeman	if it is a small config file, it may contain the config file itself
Mar 19 00:09:47 *	blackace wonders what the advantage is of both authenticating and decrypting when those two steps are accomplished in one during a normal gpg exchange
Mar 19 00:10:11 codeman	because it's extra-secure :)
Mar 19 00:10:16 blackace	the fact that the client can decrypt the job is proof of it's legitimacy
Mar 19 00:10:33 blackace	see, you're saying why without really saying why again
Mar 19 00:10:44 codeman	it's proof it has the role, but not proof that the job came from the GIMLI server
Mar 19 00:11:01 codeman	two different things we are verifying
Mar 19 00:11:22 blackace	ok, so you meant two-way or bidirectional when you said two-stage
Mar 19 00:11:42 codeman	um, i guess
Mar 19 00:11:53 codeman	i'm not very term-savvy
Mar 19 00:12:36 *	codeman wishes agaffney would stop cooking food for his fat ass and join the discussion :P (just kidding)
Mar 19 00:12:56 blackace	ok, so the client being able to decrypt the job provides both security via encryption and authentication of the client to the server, and the host key fingerprint would provide authentication from the server to the client
Mar 19 00:14:26 codeman	wouldn't it also make sense to store the fingerprint of the clients on the server?
Mar 19 00:16:15 blackace	sense maybe but it isn't strictly necessary, it doesn't provide any additional security
Mar 19 00:17:12 blackace	it's like two squirts of ketchup instead of one, you'll have more, but it won't taste different
Mar 19 00:17:37 BenUrban	yes it will
Mar 19 00:18:23 blackace	how?
Mar 19 00:18:32 codeman	blackace: ok move on in the doc while i edit the previous part up a bit
Mar 19 00:19:55 blackace	codeman: on 4. lets think about adding a checking mechanism in the server so it can be configured to alert the admin if a client or client(s) don't connect for X period of time, nagios-like
Mar 19 00:20:47 codeman	stored in the database?
Mar 19 00:21:33 codeman	so the server would store LAST_UPDATED or whatever when the client connects?
Mar 19 00:21:37 blackace	uhm, well a timestamp would need to be kept or the last log entry would need to be looked up to determine when a client last requested job data
Mar 19 00:21:45 blackace	right
Mar 19 00:21:47 codeman	or perhaps just have something look at the queues and see if anythings way overdue
Mar 19 00:21:56 blackace	or both, yeah
Mar 19 00:22:38 codeman	but we're also making the connection interval configurable
Mar 19 00:22:54 blackace	but the admin should know what interval he configured what clients to use to request job data, so it should be easy for him to configure alerts...so if a machine disappears, gets disconnected, has a network hardware issue, etc. he can know about it
Mar 19 00:23:02 *	blackace assumed that :)
Mar 19 00:23:07 codeman	also nagios-like we should be able to say "i'm turning the gimli client off on these machines, don't yell at me."
Mar 19 00:23:15 blackace	yeah, absolutely
Mar 19 00:23:40 codeman	this almost sounds like it'd work better as a nagios plugin
Mar 19 00:23:43 blackace	with a reason for other users to see why X dismissed Y alert..."bad nic, replacement coming in monday"
Mar 19 00:23:58 blackace	well...we did talk about integrating nagios didn't we?
Mar 19 00:24:12 codeman	eh
Mar 19 00:24:15 codeman	somewhat
Mar 19 00:24:21 blackace	anyone this serious about server management is going to dig nagios
Mar 19 00:24:31 codeman	we talked about gimli being able to export it's client-information in a format nagios would understand
Mar 19 00:24:54 codeman	but that doesn't really constitute "integration"
Mar 19 00:24:55 blackace	so we could include the request intervals in there and write a nagios plugin right?
Mar 19 00:25:15 codeman	how would the plugin work?
Mar 19 00:25:23 codeman	it'd need to poll something
Mar 19 00:25:44 codeman	it can see "oh i have extra files in the queue"
Mar 19 00:25:48 codeman	but that isn't a bad thing
Mar 19 00:25:58 codeman	s/files/jobs
Mar 19 00:26:55 blackace	hmm
Mar 19 00:27:05 codeman	because you can schedule jobs for the future
Mar 19 00:28:10 blackace	yeah, it would need to just be a simple "client X missed request interval Y on date Z"
Mar 19 00:28:29 blackace	so maybe that isn't something we should integrate with nagios at all
Mar 19 00:29:04 blackace	it's really more to diagnose a gimli client issue vs. a host up check which is how nagios would treat it
Mar 19 00:29:42 codeman	true
Mar 19 00:30:08 codeman	if we really really wanted to we could do it w/ nagios
Mar 19 00:30:41 codeman	hell we could have a missed-interval make a file somewhere that nagios would see
Mar 19 00:30:51 codeman	but that's an ugly hack.
Mar 19 00:31:23 codeman	it's probably better to keep it out of nagios
Mar 19 00:31:54 codeman	since while the client may not have run correctly, it may be up and running normally
Mar 19 00:32:01 codeman	s/it/the client
Mar 19 00:32:15 codeman	and if it isn't, then nagios will be bitching regardless
Mar 19 00:32:29 blackace	yeah
Mar 19 00:32:46 codeman	and in that case the gimli client program is the least of your problems
Mar 19 00:33:37 blackace	ok, so not something for nagios, but a convenience feature we can mark 'later'
Mar 19 00:34:01 codeman	i'll make brian write that.. he loves nagios
Mar 19 00:34:41 blackace	haha
Mar 19 00:34:54 codeman	ok so clarify something for me here
Mar 19 00:36:05 codeman	the client will accept any job that comes in with the correct role (because it can decrypt it), without checking the user, because it's assumed that the GIMLI server will have already checked the user and not allowed someone who doesn't have access to that client to make the job.
Mar 19 00:36:30 blackace	hmm
Mar 19 00:36:30 codeman	does that make sense?
Mar 19 00:37:13 codeman	it seems simpler to have the client not care about users
Mar 19 00:37:15 blackace	well, yeah, because otherwise every client would have to have keys for every possible user server-side so that it could use a userkey+rolekey combo to decrypt jobs
Mar 19 00:37:21 blackace	yeah
Mar 19 00:37:22 codeman	exactly
Mar 19 00:37:32 codeman	that was the whole point of doing the role thing
Mar 19 00:37:49 codeman	so that the user changing wouldn't mean sending out the keys to everybody
Mar 19 00:38:04 codeman	ok. cool.
Mar 19 00:38:08 codeman	i think i can code that :)
Mar 19 00:38:50 blackace	yeah, although I'm not sure about restricting job encryption to role keys...what if one user is granted one privilege outside of any established role?  wouldn't it be easier to use per client keys?
Mar 19 00:40:05 blackace	and what if one client performs multiple roles, ie. both db and frontend...you'd want both db and frontend people to be able to do stuff, but how would the client know which key to use to decrypt jobs with?
Mar 19 00:40:37 blackace	and even if we establish a selection process, what do we do when new roles are created?  how do we distribute keys everywhere?
Mar 19 00:40:37 codeman	blackace: the role the job was encrypted with
Mar 19 00:40:53 codeman	blackace: i layed this out in the doc i think
Mar 19 00:41:11 codeman	the root role is initially set up when the client is set up
Mar 19 00:41:39 blackace	eh, this is getting into having way too many keys
Mar 19 00:41:42 codeman	when you assign a role to a client it gets sent as a job from the root role
Mar 19 00:42:05 blackace	I don't see any benefit to it either?
Mar 19 00:43:48 codeman	hrm.  let me think on this issue overnight
Mar 19 00:44:17 blackace	the user the gimli server runs as is the only user (physical linux user) who can encrypt things with the "root" key for a specific client (ie. one root key per client)...so any job would have to either go through the gimli server, or your gimli server has been sploited
Mar 19 00:44:26 blackace	ok
Mar 19 00:44:42 blackace	it's after midnight there right?
Mar 19 00:44:55 codeman	yes
Mar 19 00:45:17 codeman	blackace: yes.. that is quite true
Mar 19 00:45:17 blackace	it's only quarter to ten here, just getting warmed up, sorry about that :P
Mar 19 00:46:19 codeman	blackace: the roles part defines the access that the job has though
Mar 19 00:46:54 codeman	you want someone with the "update" role not to be able to execute a script that does rm -rf
Mar 19 00:47:06 codeman	this can be done in many ways on the client
Mar 19 00:47:39 codeman	but this is not something i've thought out well
Mar 19 00:47:55 codeman	specifically *HOW* to define the limits and enforce them.. this will be a large issue i think.
Mar 19 00:47:58 blackace	hmm...that sounds like a permissions nightmare on the client...creating a user per role to drop permissions to in order to run a job
Mar 19 00:48:29 blackace	yeah...I don't have a simple solution for that
Mar 19 00:48:41 blackace	I don't even think there _is_ a simple solution for that :)
Mar 19 00:48:50 agaffney	bleh, that's a lot of scrollback
Mar 19 00:48:52 *	codeman pokes the no-longer-idle agaffney
Mar 19 00:49:15 *	codeman gives agaffney 3 min to catch up while he takes out his contacts.
Mar 19 00:49:26 agaffney	meh, I'm too lazy to read :P
Mar 19 00:49:54 blackace	we're talking either posix perms (huge nightmare of users, groups, and file permissions), or creating our own sandbox to execute scripts and other actions in so we can enforce an access control policy
Mar 19 00:50:25 *	blackace likes neither :)
Mar 19 00:50:54 *	agaffney neither
Mar 19 00:51:07 agaffney	who needs permissions? :P
Mar 19 00:51:33 blackace	a sandbox would be the better of the two, but it would have to be really simple...a defined set of commands that we can validate arguments to so we can ensure nothing nasty or unpermitted takes place, which limits what can be done with it
Mar 19 00:52:28 blackace	ugh, this is something I hadn't even began to think about
Mar 19 00:54:56 agaffney	we really only need permissions in the web interface
Mar 19 00:55:34 agaffney	it makes sense to enforce permissions when adding/removing jobs/events
Mar 19 00:55:35 blackace	and then run everything as root on the client
Mar 19 00:55:44 blackace	then how do we handle script?
Mar 19 00:55:50 blackace	s/script/scripts/
Mar 19 00:55:59 agaffney	what do you mean?
Mar 19 00:56:16 agaffney	if you don't trust someone to not do something stupid with a custom script, don't give them the rights to add one
Mar 19 00:56:34 agaffney	we can't protect people from themselves
Mar 19 00:56:56 blackace	I write a little script called "checkfiles.sh" and ask it be run on all the frontend webservers...in that script I maliciously place an 'rm -rf /*' because I'm getting layed off tomorrow...presto
Mar 19 00:57:27 agaffney	we can't (or at least shouldn't) protect against that
Mar 19 00:57:38 agaffney	that's not our place
Mar 19 00:57:40 blackace	well, if we don't allow custom scripts for just about everything, then we have to predefine a huge and comprehensive set of actions...which we can't do cross platform.
Mar 19 00:57:53 agaffney	it's the place of the admin to remove the access of people who are getting fired before something like that happens
Mar 19 00:58:27 agaffney	or at least to disallow running custom scripts for that person before they're notified they're being terminated
Mar 19 00:58:45 agaffney	a "sandbox" is too much of a pita
Mar 19 00:58:47 codeman	oo, how about this
Mar 19 00:58:53 agaffney	and a bit pointless
Mar 19 00:59:00 codeman	have predefined role/scripts
Mar 19 00:59:10 codeman	or role-certified scripts
Mar 19 00:59:24 codeman	we had that for php stuff at psu
Mar 19 00:59:26 blackace	oh god, you're not going to say role-admin are you?
Mar 19 00:59:32 codeman	no
Mar 19 00:59:50 blackace	so who approves or certifies scripts?
Mar 19 01:00:11 agaffney	this just seems like over-engineering
Mar 19 01:00:11 blackace	and do we allow users to submit them? queue them? manage all of that?
Mar 19 01:00:24 blackace	I agree with agaffney on that point
Mar 19 01:00:42 blackace	but not on the don't-do-anything-to-prevent-nasty-stuff point
Mar 19 01:00:42 codeman	as complex as it is, i think it'd end up being a LOT simpler than what you're proposing
Mar 19 01:00:48 agaffney	this is a bit beyond what we should care about
Mar 19 01:01:00 agaffney	blackace: it's the admin's job to prevent nasty stuff
Mar 19 01:01:11 codeman	agaffney: i disagree with you
Mar 19 01:01:26 codeman	we must have permissions
Mar 19 01:01:35 agaffney	I didn't say that
Mar 19 01:01:39 blackace	and we're giving the admin a tool to allow other people to be admins...a tool he can't be expected to fully understand
Mar 19 01:01:50 blackace	or s/can/won/ anyways
Mar 19 01:01:58 agaffney	blackace: and if you fuck up with a tool you didn't bother to fully understand, it's your own damn fault
Mar 19 01:02:31 blackace	agaffney: so what do you propose?
Mar 19 01:02:35 codeman	ok let me explain what i meant earlier by predefined scripts
Mar 19 01:03:13 codeman	say i have the "update" role.. i click the "update this client" button in gimli.. it sends a predefined script to the client that does emerge -u world.
Mar 19 01:03:26 agaffney	blackace: pre-defined "rights" (run custom script, add package, upgrade package, overwrite file, add new file, etc.)
Mar 19 01:03:40 agaffney	blackace: enforce those rights in the frontend
Mar 19 01:03:41 blackace	agaffney: and how do you accomplish this cross-platform?
Mar 19 01:03:43 codeman	since i don't have anything besides the "update" role, gimli shouldn't let me send any other job to the client
Mar 19 01:04:09 agaffney	blackace: cross-platform?
Mar 19 01:04:13 codeman	agaffney: s/rights/roles :)
Mar 19 01:04:26 blackace	agaffney: hey, codeman made a big deal out of not putting gentoo in the name
Mar 19 01:04:27 agaffney	roles is a stupid word :P
Mar 19 01:04:43 codeman	so is gaffney
Mar 19 01:04:45 blackace	yeah, can't we just use "groups"?  we're linux users for god's sake
Mar 19 01:05:18 codeman	mmm
Mar 19 01:05:21 agaffney	blackace: well, you may want to grant a user a specific right that's not allowed by the "group" he's in
Mar 19 01:05:30 blackace	not windows 2003 "server" edition schmucks who have a "ROLE" in life, in the bathroom, in bed, in meetings...
Mar 19 01:05:33 agaffney	so it makes more sense to grant rights per-user
Mar 19 01:05:55 blackace	no, it makes sense to allow combinations
Mar 19 01:06:07 agaffney	well, that's what I meant
Mar 19 01:06:16 agaffney	to have the ability to add more rights than what's allowed by the "group"
Mar 19 01:06:17 blackace	like mysql grant tables :)
Mar 19 01:06:21 blackace	yeah
Mar 19 01:06:32 blackace	or take some away
Mar 19 01:06:40 agaffney	that too
Mar 19 01:07:19 blackace	joe is an idiot, but he got hired into the db admins group...lets take away his update privilege, he'll rice the shit out of our servers until they look great but don't run
Mar 19 01:08:23 codeman	ok so what are we looking at structurally here?
Mar 19 01:08:31 codeman	please use the new terminology
Mar 19 01:08:38 blackace	in terms of?
Mar 19 01:08:46 codeman	users have rights, but also belong to groups
Mar 19 01:08:54 codeman	clients have ???
Mar 19 01:08:59 blackace	nothing
Mar 19 01:09:12 codeman	clients are assigned ???
Mar 19 01:09:18 agaffney	the only place where "users" come in is the frontend, correct?
Mar 19 01:09:20 blackace	to groups
Mar 19 01:09:22 codeman	yes
Mar 19 01:09:29 blackace	and jobs are assigned to clients and/or groups
Mar 19 01:10:15 blackace	users are assigned to groups, and privileges including jobs are assigned to users and/or groups
Mar 19 01:10:30 codeman	so when a user tries to make a job what's the checking process then?
Mar 19 01:11:12 blackace	is this job assigned to the target (client or group of clients)?
Mar 19 01:11:37 agaffney	codeman: ideally, the user just won't get the option to create a job they're not allowed to
Mar 19 01:11:56 blackace	yes? ok, is this job/privilege assigned/granted to this user?  this user's group?  is it explicitly denied to this user or this user's group?
Mar 19 01:12:09 codeman	so we stop them based first on individual permissions and second on group permissions?
Mar 19 01:13:01 blackace	no, we see if their group is allowed, if it isn't we see if they individually are allowed, if they are or their group is, we check to see if they or their group are denied
Mar 19 01:13:05 codeman	or is it backwards, we grant them.. like i have "run script" individual permission so i can run scripts anywhere?
Mar 19 01:13:29 blackace	no, then comes client permissions
Mar 19 01:13:42 blackace	actually, screw it, let's just use the mysql grant table concept
Mar 19 01:13:43 codeman	woah, where did client permissions come from?
Mar 19 01:14:00 agaffney	how do we say a user can do this on machine A and something else on machine B?
Mar 19 01:14:20 blackace	GRANT PRIVILEGE `run scripts` ON machineA;
Mar 19 01:14:25 blackace	err
Mar 19 01:14:33 blackace	GRANT PRIVILEGE `run scripts` ON machineA TO user;
Mar 19 01:14:49 blackace	GRANT PRIVILEGE `install packages` ON machineB TO usersgroup;
Mar 19 01:15:00 codeman	we're right back where we started
Mar 19 01:15:01 blackace	and so on and so forth
Mar 19 01:15:22 blackace	well what's wrong with that?
Mar 19 01:15:28 codeman	nothing at all
Mar 19 01:15:43 codeman	i like it
Mar 19 01:16:02 codeman	BenUrban: please document all this for us :)
Mar 19 01:16:03 blackace	heh, so wtf have we been arguing about? :P  lets do it!
Mar 19 01:16:11 blackace	s/document/code/
Mar 19 01:16:13 BenUrban	yeah sure whatever
Mar 19 01:16:29 codeman	we all know BenUrban doesn't do any coding for us.  only for his own projects
Mar 19 01:16:44 BenUrban	well that's not entirely true
Mar 19 01:16:52 BenUrban	but i don't do any significant coding for you :P
Mar 19 01:17:08 codeman	alright, i'll give ya that
Mar 19 01:17:53 codeman	blackace: if you wanna mess around with the doc some since it's not too late in your timezone and send it to me in the morning, that'd be awesome.
Mar 19 01:18:36 blackace	codeman: ok, you make any changes since that rtf?
Mar 19 01:18:42 codeman	i like the terms "groups"  better than "roles" and "permissions" better than "priviledges"
Mar 19 01:18:48 codeman	blackace: no
Mar 19 01:18:51 blackace	ok :)
Mar 19 01:18:59 *	blackace stabs privileges
Mar 19 01:19:15 codeman	mainly because i can never remember how to spell priviledges
Mar 19 01:19:40 blackace	GRANT PERMISSION kill ON earth TO blackace;
Mar 19 01:20:51 *	codeman goes to sleep
Mar 19 01:20:52 blackace	777 can rm 007
Mar 19 01:21:09 blackace	ok, stopping with the linux james bond jokes
Mar 19 01:21:40 codeman	hopefully we can devote some time tomorrow to talking about installer integration.
Mar 19 01:22:44 codeman	and my nifty queuing system.. i utilized many aspects of queuing systems used at my company.
Mar 19 01:22:50 blackace	I think installer integration will be the least of our concerns
Mar 19 01:23:10 *	blackace loves queues and stacks
Mar 19 01:23:22 blackace	and linked lists
Mar 19 01:23:30 blackace	and binary trees
Mar 19 01:26:28 codeman	we should also discuss how to set up the project itself
Mar 19 01:26:39 *	BenUrban deques blackace
Mar 19 01:26:42 codeman	svn repos, gentoo-hosted proj, etc.