[02:33:30] hi folks, is k8s preferred to gridengine for a toolforge web instance? [02:33:48] or are they both equally supported? [02:34:42] there's a package on the gridengine instances (gdal) that isn't available on k8s, and I was wondering whether it would be better to just stick with gridengine or to put in a phab ticket to get gdal installed on the k8s containers [02:35:24] sorry, forgot to mention - Python 3.6+ project [02:38:33] er, 3.5+ [02:42:17] because containers, the k8s images are kept pretty much as small as possible [02:43:25] yeah, figured as much [02:43:46] and I see we don't have "BYOC" yet according to wikitech [02:44:00] In The Future we'll have ways to install additional packages for tools https://phabricator.wikimedia.org/T194332 [02:44:37] excellent [02:45:07] so live with grid for now, pray for package installation in the future? [02:45:44] pretty much [02:45:50] I can deal with that [02:45:52] thanks ACN :) [08:02:19] hi all, I would like to be able to SSH from one VPS to another (they are part of the same project). I noticed that if I change the SSH configuration `/etc/ssh/sshd_config` it gets reverted automatically after a few minutes (not sure exactly how) [08:02:47] why is that? [08:03:37] in particular the change I make is going from: [08:04:08] `AuthorizedKeysFile /etc/ssh/userkeys/%u /etc/ssh/userkeys/%u.d/cumin` [08:04:09] to [08:04:19] `AuthorizedKeysFile /etc/ssh/userkeys/%u /etc/ssh/userkeys/%u.d/cumin %h/.ssh/authorized_keys` [08:05:25] I can work around that by moving one of the keys from `~/.ssh/Authorized_keys` to `/etc/ssh/userkeys/%u` [08:06:16] but first I thought that it was my mistake (i.e. that I didn't save the changes in the config, but after a couple of times now I am sure that I did change that and it gets reverted) [08:06:29] and second, I would like to know how it gets reverted [08:07:15] CristianCantoro: hi, I will dig a bit deeper, but at first though, it might be related to keeping the userkeys managed by root only (security reasons) and might be changed by puppet [08:08:14] (puppet runs periodically, so it will allow you to change it, and get reverted after a while only, on the next run) [08:09:57] yep, it's setup on the file https://gerrit.wikimedia.org/g/operations/puppet/+/refs/heads/production/modules/ssh/manifests/server.pp#19 [08:12:01] so you should be able to override that, though in a bit roundabout way, by setting the hiera value profile::base::ssh_server_settings, let me find you an example [08:13:51] something like the block of 'profile::base::ssh_server_settings' https://gerrit.wikimedia.org/g/operations/puppet/+/refs/heads/production/hieradata/role/common/ganeti.yaml#1 [08:26:08] dcaro: I think it also work if I just move `~/.ssh/Authorized_keys` to `/etc/ssh/userkeys/` [08:50:03] CristianCantoro: yep, that will also work :) [08:58:51] dcaro: (y) thanks! [09:59:56] dcaro: it seems that even if I copy my (public) key to `/etc/ssh/userkeys/cristiancantoro` then the file gets deleted after a while :-( [10:28:09] CristianCantoro: oh, hmm, so that might get setup with puppet too [10:34:56] yep https://gerrit.wikimedia.org/g/operations/puppet/+/refs/heads/production/modules/ssh/manifests/server.pp#52 [10:36:11] CristianCantoro: I think that the simplest might be adding the hiera variable to the host (in horizon puppet config) to add the extra path to "%h/.ssh/authorized_keys" [10:36:33] otherwise you'll have to send a puppet patch with some code adding the new user key [11:27:11] dcaro: I am going to look into that [13:06:10] !log thereisnosuchproject checking if stashbot is alive [13:09:30] stashbot: status [13:12:38] Lucas_WMDE: Unknown project "thereisnosuchproject" [13:12:38] See https://wikitech.wikimedia.org/wiki/Tool:Stashbot for help. [13:12:53] yay [15:47:24] Mhmm, after I installed moodle shows me the same page similar to when php is not installed. I have rebuilded it, but maybe I should delete and recreate the instance, no? [18:23:08] bd808 (and all): https://meta.wikimedia.org/wiki/Special:OAuthListConsumers/view/04e8ae1bc1447ae6d8c35a628f3920b5 is an OAuth request by a brand new user with editprotected grant and a callback URL that's some sort of redirection service. How concerned are we about vandalism potential? [18:23:41] I don't want to do any unnecessary gatekeeping but I'm also a bit uncomfortable about admin-level grants. [18:25:12] (The grants don't really match the description so the user might just be confused about their meaning. I'd still be glad to hear opinions about the question in general.) [18:26:29] >You will receive a one-time SMS to download the app [18:26:31] >By providing your phone number, you agree to receive a one-time automated text message with a link to get the app. Standard messaging rates may apply. [18:55:38] tgr: I looked at that one and mentally put it in the "tgr will make the right call" bucket. :) I go back and forth in my own head about the purpose of having a manual review queue for Wikimedia's OAuth grants. Sometimes I see it as weird overhead that was mandated in 2013 and never repealed. Other times I see it as a useful protection for Wikimedia users from sketchy apps. [18:56:17] I think that grant requests like this one more often than not trigger the protective thinking from me. [19:00:17] brand new user; no user page content of informative value; return URL that goes to a redirector service; grant requests advanced user right access. That's quite a few red flags. [19:40:11] The application process is a gentle filter to weed out people interested in contributing vs. those merely looking for free web hosting [19:41:09] I think requiring approval for command line access is more than reasonable. For subsidiary apps with less damage potential I think basic OAuth authentication would be fine. [19:41:32] There's a ton of approval you have to go through to use AWS and that's for paying customers! [20:19:32] approving an OAuth consumer is no burden on our infrastructure. The threat model here is that someone will make a mobile app for viewing kitten pictures on Commons and then proceed to vandalize the enwiki main page in the authorizing user's name. [20:21:28] As long as the grants don't include any permissions an autoconfirmed user wouldn't have, I don't think there's any reason for manual review. It's just work to remove it (admittedly much less work than keeping reviewing these applications but you know how that works). [20:21:49] My concern is about consumers with low-level admin grants, specifically. [20:33:11] The edit attack threat has compensating controls in the oauth edit tags. I don't think there is any way for the client to opt-out of that tagging, so any vandal by proxy app should be found pretty quickly and blocked. [20:34:03] sure. But vandalism with admin privileges can be a big deal, even if quickly reverted. [20:34:35] *nod* [20:35:55] I think the rule I'm gravitating towards is be maximally permissive when no elevated permission grants are involved, require some transparency into the author (and ideally source code / workings) of the app otherwise. [20:39:26] I often wish the registration process included a chat/discussion function so that it was easier to ask things from the review queue and have the request marked as pending feedback. But I have no delusions about it being reasonably easy to find engineer and designer hours to make meaningful changes to the ~8 year old mostly unmaintained extension. [20:43:08] Should just undeploy it really 😁 [20:43:51] * bd808 giggles and tosses a trout at @yuvipanda [20:44:02] 😄 [21:02:47] You could communicate through Special:Log messages! That's actually not too hard to add. [21:03:34] (Only half joking, the log messages are sent via Echo notifications so it wouldn't be too terrible. Although all admins would be notified.) [21:16:25] is Echo really still called 'Echo'? [21:17:01] In some places, yeah [21:52:55] Extension names never go away. They just stack. [22:52:39] I see you rejected it [22:52:41] and I agree [22:53:23] all that "provide us your phone number to send you the link" makes no sense [22:53:48] well, I understand it can be handy for some users to receive a sms link [22:53:58] but only providing the link through a sms? [22:54:28] marketing contact acquisition :) [22:54:44] paid with user data [22:54:58] but then it's not "you agree to receive a one-time automated text message" [22:55:15] it's "you agree to receive a one-time automated text message and with us selling your data to a bazillion of companies" [22:55:26] it has no privacy policy [22:56:24] for me they are spammers [22:56:34] something I'm not tempted to support [22:59:04] and they seem banne, anyway [22:59:06] *banned [22:59:46] providing a phone number returns a HTTP 400 with a JSON {"message": "This app is blocked from sending SMS messages."} [23:39:34] !log tools.jouncebot Update to 66f16a2 + local hacks [23:39:38] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.jouncebot/SAL [23:58:58] !log tools.jouncebot Update to ba76aff and clean up local hacks [23:59:00] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.jouncebot/SAL