[00:00:01] Right and can't change ownership with either user [00:00:02] Fun times [00:00:55] That's not really tenable for large numbers of files. Moving via /tmp is, but that's a security risk if it includes files with credentials. [00:01:31] Yeah, Unix file permissions are... sometimes a pain. Like I said, I'll code a 'chown to self' suid utility soon that'll allow to take ownership of files in a clean way. It's clearly urgent. [00:01:42] Yes :-) [00:02:04] So maintainers can just stuff them in the tool home, and the tool user can take its ownership from there. [00:03:15] * Coren goes to do that now. [00:54:00] Hi I wondered if someone has an ETA on when beta labs will be online again? [00:54:54] "beta labs"? [00:55:18] Done, but given the security implication this /really/ needs a review. [00:55:22] Dcoetzee: ^^ [00:55:34] http://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page [00:55:57] Wrong room? Should I go to ops? [00:56:11] So, this is probably the right room; I was just unaware of that project. [00:56:22] Which also means I cannot help you. :-( [00:56:31] Sorry Coren :) [00:56:36] Bet bet: ask Ryan_Lane. He knows all, sees all. [00:56:40] Thanks [00:56:44] Coren: K cool [00:57:04] Dcoetzee: /usr/local/bin/take [00:57:11] Dcoetzee: Assuming you grok perl. [00:57:35] It's not suid root until I get some review. [00:57:55] (i.e.: useless until then) :-) [01:16:40] Coren, security implications? am I missing something here? [01:17:07] Krenair: Anything that has suid to root, by definition, has security implications. [01:17:57] oh, I see [01:19:15] Guess I didn't read far enough up the chat log before [14:12:11] hello labs :) [14:12:44] Can anyone here change my labs username / create a new one? [14:39:25] !log deployment-prep I have setup a Jenkins job to automatically update mediawiki-config. Dashboard is https://integration.wikimedia.org/ci/job/beta-mediawiki-config-update/ [14:39:28] Logged the message, Master [14:39:49] !log deployment-prep Updated mediawiki/extensions.git which was lacking the Thanks extension {{gerrit|55263}} [14:39:51] Logged the message, Master [14:40:29] !log deployment-prep manually refreshing extensions on -bastion [14:40:31] Logged the message, Master [15:00:55] !log deployment-prep manually update puppet sources on -search01 and -searchidx01 [15:00:59] Logged the message, Master [15:52:20] "Ryan Lane deleted instance 'metavidwiki' in project Nova Resource:Metavidwiki" [15:52:41] GChriss: it's been disabled for two weeks now [15:52:41] across the board or something specific metavidwiki? [15:52:57] the instance was owned [15:53:01] oh. [15:53:04] ok [15:53:05] I sent an email about this when I disabled it [15:53:13] along with about 10 others [15:53:29] I deleted all of the owned ones a couple days ago [15:54:00] no one complained after being disabled for two weeks, so I assumed they weren't being used [15:55:24] what was the subject line? [15:55:26] * GChriss catches up [16:33:41] petan: would be great if you could try and delte those files, I seem to be having little sucess even after getting rid of 100,000 or so [16:33:50] LOL [16:33:59] you were doing that whole day? [16:34:06] I mean, I asked you yesterday [16:34:10] and today you replied :D [16:34:17] sounds like ur pc stucked on deleting them [16:34:20] nah I had to go to work :P [16:34:24] ah [16:34:28] ok I will delete them [16:34:32] :) [16:34:32] can you tell me WHICH? [16:34:34] <^demon> Ryan_Lane: https://gerrit.wikimedia.org/r/#/c/55271/ \o/ [16:34:39] wildcard or whatever [16:34:39] g.wd.* [16:34:42] ok [16:34:44] in /home/addshore [16:34:49] so /home/addshore/g.wd.* [16:34:52] only files [16:35:26] wait [16:35:39] /home/addshore/wd.g.* ;p [16:35:44] ^demon: ok. let me build this [16:35:46] and ya only files :) [16:35:57] addshore: 100,000 files? :) [16:36:10] what in the world are you doing? :D [16:36:13] grid engine has been spamming my home >.< [16:36:16] <^demon> Ryan_Lane: No rush, just now sitting down to lunch. [16:36:30] and I havent been active for about a week so I havn't noticed, intil I tried to do ls in my home directory... [16:36:31] easier if I do it now [16:36:35] hahaha [16:36:45] oh man, gluster must *love* that [16:37:01] Ryan_Lane: yes ;p [16:37:20] hi Ryan_Lane [16:37:20] * Damianz blames addshore for his poor filesystem performance [16:37:31] milimetric: howdy [16:37:35] I, unfortunately, needed my labs username changed [16:37:36] dont blame me, I didnt know oge would write all of these >.< [16:37:43] milimetric: why? [16:37:44] I have to go through you right? [16:38:01] I've exhausted all other options, it's the only way I can work with hue properly [16:38:12] what do you mean? [16:38:16] it authenticates based on the user you're signed in as [16:38:45] what's the actual problem? :) [16:39:02] renaming is…. hard to say the least [16:39:10] and possibly still impossible [16:39:14] Gerrit loves renaming users [16:39:14] ottomata can explain it better, and he knows it's hard, but apparently it's the only way [16:39:23] ^demon: can gerrit handle this properly? [16:39:24] right, off to work again :D [16:39:26] one sec, I'll get you an error message [16:39:32] milimetric: what's your username? [16:39:37] milimetric it is [16:39:44] and that fails because? [16:39:50] and how will renaming your user help? [16:39:55] <^demon> Ryan_Lane: We should be able to get by with just renaming the external account. [16:40:00] <^demon> But I haven't tested. [16:40:04] ^demon: ok [16:40:13] renaming it elsewhere is a pain, but doable [16:40:32] there's still a bug in LdapAuth and Special:RenameUser, but I can just disable LdapAuth while I rename the user [16:40:36] basically, I can't access hdfs:///wmf/webrequest/raw [16:40:38] I get this: [16:40:43] Cannot access: /wmf/raw/webrequest. Note: you are a Hue admin but not a HDFS superuser (which is "hdfs").AccessControlException: Permission denied: user=milimetric, access=EXECUTE, inode="/wmf/raw":hdfs:stats:drwxr-x--- (error 403) [16:41:02] oh ok [16:41:09] ok, so how will renaming your user help? [16:41:09] Ryan_Lane: I'm ok with abandoning that account [16:41:15] and just starting fresh, so no rename [16:41:16] addshore running... [16:41:19] is that possible? [16:41:24] I'd prefer to avoid that [16:41:28] cheers petan :D [16:41:29] renaming makes my username sync up with the one in hue [16:41:36] guess I will have to make a cron to cleanup daily :/ [16:41:38] what's your username on hue? [16:41:42] dandreescu [16:41:49] i don't understand why that can't be renamed... [16:41:52] one sec, lemme get ottomata [16:42:10] is this because hue isn't using ldap? [16:42:18] or the system isn't or something like that? [16:42:29] it's not using LDAP, correct [16:42:40] er. [16:42:42] it has a crazy authentication scheme [16:42:43] but hue is? [16:42:50] Hold up, I think there might be confusion. [16:42:57] it seems to me that the authentication scheme is what's broken [16:42:59] not your username [16:43:03] Just make a new user in hue with your ldap username? [16:43:03] http://blog.cloudera.com/blog/2012/03/authorization-and-authentication-in-hadoop/ [16:43:08] I was about to say. [16:43:12] Just make a new Labs user. [16:43:20] that's possible too [16:43:27] i somewhat agree with that Ryan_Lane, but we probably stand little chance of upstreaming something in time :) [16:43:34] .... [16:43:34] in time for me to still be alive that is :) [16:43:37] that's not what I mean [16:43:50] I mean the way that *we* are doing something is screwed up [16:43:55] Ryan_Lane: I can explain the shit with Hue later if you want. [16:44:15] dschoon: well, now is better, not sure how available I'll be today [16:44:17] No, it's the fact that Hue uses some confusing words for two separate things [16:44:17] oh, no, as far as I can tell, we're not doing anything besides what we've all agreed is the best way forward with Hadoop at WMF [16:44:18] I'm not in the office [16:44:21] ah [16:44:28] <^demon> Ryan_Lane: I found a maven plugin to generate .debs. This sounds...evil. [16:44:36] <^demon> And yet likely to make our packaging easier :p [16:44:55] ^demon: probably better than what we currently do [16:45:00] Okay, so just to make sure: milimetric create a new labs account for your shell name [16:45:15] and let me know when you've done that, and tried to log into hue [16:45:18] I don't think we should ever expect hue to translate from one username to another :) [16:45:29] Ryan_Lane: okay, so backing up [16:45:34] I'm assuming hue is doing ldap auth [16:45:40] and the hdfs systems are not [16:45:42] forget everything you know so far :) [16:45:44] there are two sets of permissions: [16:45:49] - HDFS file permissions [16:45:58] - Hue web GUI permissions [16:46:15] hue permissions are simple to explain: they control what shit you can do through hue. [16:46:23] hue permissions are attached to hue users. [16:47:26] and hue users are currently created and auth'd through labs LDAP [16:47:26] Ryan_Lane, your assumption (currently) is correct [16:47:52] HDFS permissions and users are distinct. [16:48:03] addshore my script will keep deleting these files until some are in that folder, that means old and new [16:48:06] I hope it's ok [16:48:09] HDFS relies on unix permissions and users. [16:48:23] if you only need old I will change it [16:49:19] ottomata: that's what I thought :) [16:49:19] heh [16:49:23] (at least for now it does, ldap user group mapping is possible in hadoop, but we haven't set it up yet) [16:49:24] ottomata: because nss was removed [16:49:25] that make sense? [16:49:27] right [16:49:40] so milimetrics problem is that he logs into hue with his ldap username [16:49:48] but hadoop grants permission based on shell username [16:49:53] dschoon: so, it's exactly the situation that I wrote before you said "forget everyting you know" :D [16:49:53] and his ldap and shell usernames don't match [16:49:58] haha [16:49:58] * Ryan_Lane nods [16:50:09] dschoon: I helped set this up, you know, right? :) [16:50:23] I'll just shoosh :) [16:50:34] :D [16:50:40] ottomata: right [16:50:41] Ryan_Lane, I missed the beginning of the convo, you don't want mlimetric to create a new 'dandreescu' ldap account? [16:51:03] well, does he want his production and labs accounts to match? [16:51:03] ldap account? you mean labs account right? [16:51:08] milimetric: same sam [16:51:09] *same [16:51:13] labs = ldap [16:51:25] we don't have production ldap [16:51:38] we only have one ldap right? [16:51:46] so I already have a dandreescu ldap account [16:51:52] don't I? [16:52:00] that's your production account [16:52:10] managed by puppet [16:52:21] oh ok, is it easier for that one to change to milimetric? [16:52:30] neither one are easy to chaneg [16:52:32] *change [16:52:48] we can delete your production one and create a brand new production one [16:52:52] so... [16:53:01] is that best ottomata? [16:53:02] ok wait [16:53:05] in labs this is slightly easier, if we only change your shell account name [16:53:05] afaik [16:53:08] I totally don't care which name I end up with [16:53:11] right now [16:53:12] if we change your CN, this is hard [16:53:19] shell == dandreescu [16:53:19] ldap == milimetric [16:53:21] we want them to match [16:53:37] let's use the proper terminology here [16:53:44] ok [16:53:53] ? [16:54:01] production/labs, uid/cn [16:54:11] ha ok [16:54:13] that makes so much more sense :) [16:54:23] i have no idea what a shell account is [16:54:26] production uid = dandreescu [16:54:37] ok [16:54:39] got it sure [16:54:40] ok [16:54:41] labs uid = milimetric ? [16:54:44] yes [16:54:45] currently [16:54:50] labs ldap cn = milimetric [16:55:04] ok. so, are we discussing changing both the cn and the uid? [16:55:04] can he just create a new labs ldap account called dandreescu and then delete the other one? [16:55:08] no [16:55:09] one or the other [16:55:13] we can't delete the other one [16:55:18] we can never delete accounts [16:55:23] ok, well, we can just stop using it [16:55:25] he can never use it again [16:55:26] :) [16:55:34] but yes, that's doable [16:55:38] and the easiest option [16:55:44] whatever's easiest for you guys [16:55:48] but that also means he loses all his contribution history [16:55:50] which sucks [16:55:52] i just have to change a few ssh config lines, no big deal at all [16:55:52] ok, milimetric, do you have anything in your labs homedir that you need saved? [16:55:54] OH [16:55:55] in gerrit? [16:55:56] crap [16:55:59] yeah that sucks [16:56:08] meh, i'm not married to it [16:56:09] :) [16:56:10] in gerrit, wikitech, etc [16:56:13] we can change the production uid [16:56:20] but i think that gets annoying too, no? [16:56:28] we can't really change it [16:56:32] we can create a new one [16:56:34] (this has already gone back and forth with production uid by robh and maybe someone else too) [16:56:35] and delete the old one [16:56:37] right irhgt [16:56:45] puppet shits itself on renames [16:56:56] which is just… absurd [16:56:59] :) silly puppet [16:57:01] In labs you could copy the homedir over and re-chown it, but wiki wise you'll loose history unless you can manually re-name the account [16:57:15] i actually think thats better than changing in labs, because the produciton uid accounts are just per machine anyway [16:57:18] another option is to keep the cn and change the uid in labs [16:57:20] ok, so add new and delete old seems fine too, would that be a lot harder for you guys? [16:57:21] i can babysit those changes through [16:57:31] oh...? [16:57:31] hm [16:57:38] what would that entail Ryan_Lane? [16:57:54] but then you'd log into the web as milimetric, and via shell as dandreescu [16:58:15] hm. that also may be a pain in the ass with gerrit [16:58:24] hm, that seems like a hack that nobody would enjoy [16:59:01] which username do you prefer? [16:59:15] root [16:59:19] Damianz: ;) [16:59:24] * Ryan_Lane sharpens his knives [17:00:06] * Damianz tries not to choke on tea [17:00:23] ok, so removing me and adding me back to production as milimetric, does that seem like the best choice? [17:00:23] milimetric [17:00:23] not if it's hard on you guys though [17:00:35] well, then let's change production [17:00:51] push in a change to delete the old account and to add a new one [17:00:56] using the same key [17:00:58] but a new uid [17:01:09] if you use the same uid we have to do this in two stages [17:01:19] and it'll take an eternity [17:01:33] *uid number [17:01:33] ok cool [17:01:35] sounds good [17:01:36] that's totally fine [17:01:38] thanks Ryan_Lane! [17:01:41] yw [17:01:41] we will change prod uid to milimetric [17:01:42] thank you! [17:01:44] i'll do that one [17:02:00] if you would have prefered the other name, we would have went the route of changing it in labs ;) [17:02:07] you chose wisely :D [17:03:41] * milimetric scurries back to the analytics cave, content with his wisdom [17:04:37] Change on 12mediawiki a page OAuth was modified, changed by Dantman link https://www.mediawiki.org/w/index.php?diff=662517 edit summary: [+1] /* Previous discussions */ Death not Dead [17:53:57] Coren: so, where does this hook exist? [17:54:02] 13:52:41] Extension -> create tool -> invoke the (create tool) hook -> hook returns with possible LDAP entries for the user -> extension finishes, adds entries, and claims success [17:54:02] [13:53:24] So all modification would /still/ be done by the extension, only the hook can add to the list. [17:54:02] [13:53:33] where does the hook exist? [17:54:07] heh [17:54:13] Give context. :-) [17:54:23] indeed [17:54:52] does the hook exist on in instance inside of labs? [17:55:17] I can see several plausible places for the hook to exist. (a) on a dedicated project that has all the right magic but where access is limited, (b) on a designated instance of the project itself are the two obvious ones. [17:55:41] but then we're breaking the logic into two separate systems [17:55:41] (a) is more secure, also less flexible and not in control of the actual project [17:56:15] Ryan_Lane: Well, I see it more as "delegating project-specific stuff to the project", with the Extension doing the actual global stuff. [17:56:15] What's an example of a project-specific thing we'd be doing? [17:56:29] a) splits the code into two places and doesn't give any more control than just doing this directly in mediawiki [17:56:35] andrewbogott: Well, in tools-, I want to create databases and add a couple grants. [17:56:52] Ryan_Lane: (b) does seem more sensical. [17:57:08] except that b) also then requires each project owner to manage this stuff [17:57:24] which means other project owners don't benefit from the work of others [17:57:34] Ryan_Lane: The obvious solution is that if the project owner doesn't give a hook, then no hook is done. [17:58:03] Ryan_Lane: Why? What would prevent the project owner from sharing his work with others that could use it? [17:58:54] they could add the hooks to gerrit, I guess, but it seems like a lot more work [17:59:16] man I need to learn how to draw mockups [17:59:29] Ryan_Lane: Just fake it. :-) [17:59:36] Bah-dum tsh! [18:00:00] * Damianz gives Ryan_Lane a can of idea paint [18:00:06] one sec. I think I can do this in omnigraffle [18:00:28] If you fake drawing a mockup, are you then drawing the real thing? [18:01:07] :) [18:01:17] I'm not sure double negatives work that way :) [18:01:26] that would not be unawesome [18:05:07] <^demon> Ryan_Lane: That package up? [18:05:15] hahaha [18:05:16] I forgot [18:05:48] <^demon> ha. [18:06:32] ok. screw doing a mockup [18:06:38] ^demon: I'm making it now [18:06:45] <^demon> kthanks. [18:06:59] Coren: so, what I'm proposing is to add these project specific things as configurables per project [18:07:10] so that users can enable them via "configure projects" [18:07:52] we can have OpenStackManager call a hook, and have a separate extension that has all of these things [18:08:06] that way it doesn't clutter up the extension [18:08:34] I agree that we still need a mechanism for sending notifications [18:09:01] I actually don't want notifications, but instead want to use salt-api to actually call code modules [18:09:08] or runners [18:09:39] I want as little logic as possible to actually run on instances [18:10:59] runners could actually do a lions share of most of the work [18:11:48] Yeah, that sounds like a reasonable approach. [18:12:53] andrewbogott: any status update on salt-api? usable at all yet? :) [18:13:23] we may be able to use salt-api without keystone auth, if we only allow it from OpenStackManager [18:13:35] we could limit it to 127.0.0.1 [18:13:52] OSM could pass in project/user [18:14:09] we could wrap everything in a runner, and do the authn/z there [18:14:20] Ryan_Lane: No real progress :( [18:14:30] * Ryan_Lane nods [18:14:56] does it work at all? [18:15:09] we could do basic auth to it using a password.... [18:15:16] from OSM [18:15:51] I haven't updated recently, there may be upstream progress. But it does more than nothing... [18:15:57] Damianz can probably testify as to specifics. [18:16:00] heh [18:16:20] we may be able to use it in a minimal way [18:16:29] It can authenticate using an openstack username/password but not a token. I keep sitting down to add token support but then getting distracted. [18:16:29] I really just want to avoid shelling out from OSM to salt [18:16:30] it needs work to use it properly [18:16:57] I think we can actually ignore keystone auth for our initial use casew [18:16:58] if we don't care about decent group/acl support it's 'usable' atm [18:16:59] *case [18:17:11] Damianz: yeah< i think we can work around that [18:17:26] so, here's my current thinking: [18:17:35] have salt-api run on 127.0.0.1 [18:17:43] make it require a username/password [18:17:50] give OSM that username/password [18:18:05] only allow it to call a runner [18:18:23] the runner wraps all calls, and takes in user, project, and the call it wants to make [18:18:38] we do authn/z in the runner [18:19:08] basically we're offloading the auth to OSM [18:19:11] I do something like that at work - but I use a celery worker and put all authz logic in the application, then salt-api is just a dumb interface (since i need to open up peer runs for other stuff...) [18:19:11] which we're doing anyway [18:19:48] andrewbogott: Commented on the patchset [18:20:07] Damianz: this would be similar, except we'd do the logic in the runner [18:20:07] Coren: Thanks, I'll catch up after lunch. [18:20:17] salt-api would just be a dumb interface to avoid shelling out [18:21:01] It sort of seems silly - you're allready checking auth in osm, why check it again? You can never expose that runner to anyone else [18:21:14] hm. true [18:21:29] yeah. that's actually easier [18:21:51] Damianz: So turn off auth entirely because the invoker is trusted. [18:22:12] yeah - just say 'osm' can do 'everything' and let osm decide what it's calling to call on your behalf [18:22:34] we can still limit what's callable, we just don't check the user/project [18:22:39] since the caller is doing it anyway [18:22:44] mhm [18:22:55] good idea [18:23:02] the only thing we'd have to watch is if we make this extensable taht the auth steps will stand up to stupidity [18:23:06] It does have the elegance of simplicity. [18:23:16] (ie let people add 'project' specific commands to the interface) [18:24:25] you know, if we only exposed a runner from the api, then we could actually do all of the keystone stuff in the runner [18:24:27] and use it as a wrapper [18:24:34] Damianz: But then, the worse they could do is break their own toys since OSM won't call with a different project. [18:24:35] then we could open this up past localhost [18:24:40] but that's a future topic :) [18:25:00] Ryan_Lane: That all sounds doable. [18:25:07] great [18:25:19] Coren: Well they could do priv escalation within a project potentially [18:25:27] But since it's all reviewed code anyway, not hugly a problem [18:25:48] ok. I gotta do lunch before someone stabs me [18:25:54] Damianz: Don't we presume that only project admins would have the right to set project-specific commands anyways? They don't need to escalate. [18:26:03] Ryan_Lane: Go do the eating thing. [18:26:17] I'll write up plans and send an email to labs-l [18:26:42] Depends... I was more thinking on the level of 'moving auth back a step', but in theory if they can do anything bad in the interface there's worse things they could do anyway [18:26:46] for both the salt stuff, and the project-specific sudo stuff [18:26:52] On the subject of eating..... [18:27:11] and we can continue the discussion through email where everyone can participate :) [18:27:19] Ryan_Lane: Heh. okay. [18:27:28] email is no fun [18:27:31] * Ryan_Lane should practice what he preaches [18:27:35] Ryan_Lane: BTW, I do have a workaround; I still have a project-local sudoers so I can cope regardless. [18:27:35] someone feed mailman cocaine so it's vaugly real time [18:27:43]