[06:47:27] hello [12:32:11] !log tools add packages jobutils / misctools v1.41 to {stretch,buster}-tools aptly repository in tools-sge-services-03 [12:32:20] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [12:32:29] !log toolsbeta added packages jobutils / misctools v1.41 to {stretch,buster}-toolsbeta aptly repository in tools-sge-services-03 [12:32:31] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Toolsbeta/SAL [12:40:47] are there any guidelines / tutorials for making production puppet code compatible with 'labs' (read: WMCS) environments? [12:42:58] SPF|Cloud: what do you mean by compatible? [12:43:35] a puppet code that works in both environments? [12:44:00] I don't think a detailed list of environment differences exists [12:44:10] for example, removing ferm::service rules, since to my knowledge, these are not used in WMCS? 'if $::realm is production' works technically, but I am not sure if that is the preferred way to do these things [12:44:41] in general we use openstack security groups for packet filtering in WMCS. But nothing prevents you from using ferm [12:45:00] it will just be more confusing when debugging potential network issues :-) [12:45:51] you can just add an `if realm` in the code, not include the ferm configuration in WMCS SPF|Cloud [12:46:17] I understand using ferm and (network) security groups at the same time is possible, but I doubt it is a wise choice :) [12:46:27] yes, is possible [12:46:32] I mean, no big deal [12:46:46] some folks follow a different pattern: introduce different high level roles/profiles dedicated for WMCS, than reuse detailed profiles as required [12:47:01] example: [12:47:26] FYI, I would like to reuse https://github.com/wikimedia/puppet/blob/production/modules/role/manifests/syslog/centralserver.pp as part of https://phabricator.wikimedia.org/T127717 [12:48:09] https://www.irccloud.com/pastebin/ktvm4VRO/ [12:49:13] SPF|Cloud: that's a lot of context. I would need to read through that ticket to be able to provide a more concrete answer [12:49:25] but other than ::profile::standard and ::profile::syslog::centralserver (in the latter I have made some changes as well...), the role is too extensive for me, since ::profile::bird::anycast sounds like something very production specific? [12:49:35] yeah [12:49:53] right, so basically an if $::realm is enough here [12:50:02] that's why creating a `role::syslog::centralserver_cloud` may make sense [12:50:20] instead of polluting all child profiles if if $::realm [12:50:23] the involved role and profiles are not too difficult to understand, just require some changes to make it fit my use case [12:50:35] ah, thanks [12:51:48] 👍 let me know if I can review a patch once you write it [12:52:20] sounds good, thanks a lot :) [12:53:08] you are welcome [14:59:09] SPF|Cloud: running ferm rules on cloud instances is actually a good practice. OpenStack security groups are functional similar to edge router ACLs and not a full replacement for local firewalling. [15:38:15] bd808: the way we have neutron security groups today is literally local firewalling. You just don't see the rules, because they are on the other side of the virtual NIC, but still 100% bastion firewalling [15:42:05] I also have some concerns about declaring using ferm inside cloud instances a good practice. I might be the opposite actually [15:55:35] !log tools deleted a bunch of messed up grid jobs (9989481,8813,81682,86317,122602,122623,583621,606945,606999) [15:55:41] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [16:31:49] !log tools installing jobutils and misctools 1.41 [16:31:52] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [16:42:33] bd808: a user on Discord wants a new Wikitech account username, but wants to keep their SSH username. Would it be possible to have their current shell account assigned to a new Wikitech account? [16:44:03] * andrewbogott shudders [16:45:15] harej: we can rename their user on wikitech [16:45:40] the `cn` attribute is easy to change. the `uid` (shell name) is not [16:46:02] should I have them file a phabricator ticket? [16:47:06] harej: yeah, that's probably the easiest way to start. You can tell them to subscribe me to it and I'll figure out how to tag it etc [19:30:54] <|404> can someone help me with a newly spawned instance? I cannot connect [19:37:38] |404: first step I would recommend is just get a coffee and try again in 30 min or so [19:38:07] then if it still fails, check the console output in Horizon and see if it finished to run puppet [19:38:11] <|404> mutante: hm, ok, it's now only for 23 minutes. some years ago when I started 5 mins where enough :) [19:38:44] yea, sorry, I don't know why it is that way in detail, just that it happened to me before, sometimes fast and sometimes not so fast [19:39:11] if you click on the instance, see the console output link [19:39:16] see if it tells you anything [19:39:32] <|404> hm, the log shows now the root login line, including root@instance:~#, but still no login for me [19:39:39] assuming you can SSH to other instances in the same project, right [19:40:00] <|404> yes, to multiple. also used this to verify my gateway setting via bastion still works [19:40:22] did you apply a puppet role to it before it was created by any chance? [19:40:25] <|404> funny, worked now [19:40:29] for example via project-wide puppet [19:40:34] there you go, cool [19:40:39] <|404> wonder why there was that difference between log and ssh login [19:40:42] <|404> thx :) [19:40:49] yw, i didnt do much :) [19:42:10] |404: probably because adding the root key is done in puppet before it is hooked up to LDAP users [19:56:58] !log tools.lexeme-forms deployed 547b42f25f (Portuguese nouns, i18n updates) [19:57:01] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [23:00:45] ello, where would be the best place to send a phishing email I got trying to be WMF? [23:01:04] ("tools.wmflabs.org IT DEPARTMENT" heh) [23:02:01] TerraCodes: hmmm... security@wikimedia.org I guess? Somebody on that list can decide if there is anything to do about it. [23:02:31] alright, should I see if I can attach the email, or should I just forward it? [23:03:59] If you can get the headers captured that would be helpful incase they decide to try and take action. A sinple forward probably loses most of the interesting bits. [23:04:30] *simple [23:11:22] yeah I'll see if I can download the message and attach it, or failing that, I'll just copy them into the forwarded email [23:11:35] any headers it would be a good idea to strip out before sending? [23:14:08] TerraCodes: nothing I can think of, unless you want to redact something about the mail server at your end I guess. [23:20:44] yeah looks like there's nothing sensitive in the headers that I can see, so I'll just send it as it [23:21:12] (I guess the headers indicate that I'm using outlook, but that should be pretty obvious from the @outlook.com email I'm sending the email from heh) [23:21:38] alright and it's sent, thanks for the help