[09:06:54] jbond42: how difficult is it to put a service behind idp? [09:10:22] kormat: depends very much on the service, but if it's for a fresh service it's notably simpler than migrating something which pre-exists. if there's a test install of the new orchestrator happy to have a look for next steps [09:10:28] kormat: depends on the service for for simple services should be enough to add profile::idp::client::httpd [09:13:07] it is for orchestrator, yeah. it needs X-Forwarded-User populated [09:16:31] kormat: thats should be pretty simple upi can set `authd_header => 'X-Forwarded-User'` https://github.com/wikimedia/puppet/blob/production/modules/profile/manifests/idp/client/httpd/site.pp#L23 [09:16:53] ah, actually the header name is configurable on the orchestrator side [09:16:56] ok cool :) [09:21:48] kormat: if thats that case i would use the header X-CAS-CN (environment variable HTTP_X_CAS_CN) as the default CAS-User header suffers from the case insensetive issue that icinga has [09:22:12] jbond42: oh, thanks! [11:49:11] how do you detect an `unset` value in an erb template? [11:49:57] oh, it's `undef`, not `unset`. let me re-google in that case :) [11:51:02] > Also, note that the special undef value in Puppet becomes the special nil value in Ruby in ERB templates. [11:59:59] kormat: yes `@param.nil?` should do it. i think they use to use :undef (or perhaps that is only in spec files) so you may see that around (https://puppet.com/docs/puppet/5.5/lang_template_erb.html#puppet-data-types-in-ruby) [12:03:38] cheers [12:12:51] <_joe_> yeah keep that link handy [12:12:57] <_joe_> you will always forget [14:32:46] jbond42: regarding https://gerrit.wikimedia.org/r/c/operations/puppet/+/634213; I have at least one VM (and, I suspect, many) where $facts['networking'] seems to be undefined. Any idea what that's about? Facter version maybe? [14:33:51] indeed, 'apt-get install facter' resolved the problem. Is that something you already ran cloud-wide? Or something we /should/ run cloud-wide? [14:34:36] andrewbogott: i did run it cloud wide but seems i missed at least yours so i think it would be worth running again [14:34:56] ok. Any guards I should put around that or is it safe to run everywhere just like that? [14:35:34] andrewbogott: that should be safe, suspect you will need -y as well though [14:36:10] * andrewbogott nods [14:36:48] andrewbogott: also see here https://phabricator.wikimedia.org/T266075#6567230 [14:37:24] cool, I'll do another fact refresh after I upgrade things [14:37:30] thanks [14:48:18] recently i have had to switch to using a mac (while laptop is repaired) and notice that the systemd spec tests fail. This is because systemd-analyze on a mac, to hack around this i have created a script (https://phabricator.wikimedia.org/P13043) and linked it to /usr/bin/systemd-analyze. i have added a not to the spec test in case anyone elses may find this usefull ... [14:48:23] ... https://gerrit.wikimedia.org/r/c/operations/puppet/+/635552/2/modules/systemd/spec/defines/systemd_timer_spec.rb#3 [14:48:40] systemd-analyze is *not* on a mac [15:12:15] icinga seems faster to me than it used to, thanks whoever made that [15:16:44] oh jbond42 very cool! i will try the PCC Hosts in my next patch [15:16:49] didn't know, thank you! [15:19:17] ottomata: no probs; you may also want to check https://wikitech.wikimedia.org/wiki/Help:Puppet-compiler#Host_variable_override [15:20:05] OH id din't know that either, thought it was only csv [15:20:08] coooool [15:26:33] https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/ [16:41:20] <_joe_> jbond42: you should really use ./utils/run_ci_locally.sh :) [16:41:31] <_joe_> that *has* systemd-analyze :P [16:41:48] <_joe_> as it runs a the same docker container as CI does, on your working tree [16:44:48] _joe_: :D yes i know, just habbit although [16:45:07] it can make debugging simpler when you can run localy [18:25:07] jbond42: do i need to comment 'check experimental' every time i make a new patch? [18:25:51] ottomata: yes and some times it silently fail's [18:25:54] ok [18:27:35] ottomata: you can also use `./utils/pcc last parse_commit` from the puppet repo to do a simlar thing (although it dosn't add the pcc to the gerrit CR) [18:28:44] or `./utils/pcc 635577 parse_commit` to run on a specific change (lastruns on HEAD) [18:29:31] ooo [18:30:37] I have been meaning to try this out but I still end up opening the tab and manually running it [18:31:39] so to be clear, for this to work, I need to specify Host: in the commit message and then this will run PCC on that host? [18:33:23] hmm jbond42 kinda works? [18:33:27] CRITICAL: Unexpected error running the payload: Unable to find fact file for: an-laucher1002.eqiad.wmnet [18:33:36] https://puppet-compiler.wmflabs.org/compiler1001/26046/ [18:34:06] after runnibng [18:34:07] ./utils/pcc latest an-laucher1002.eqiad.wmnet [18:34:11] (and setting api token, etc.) [18:34:47] ottomata: sounds like https://wikitech.wikimedia.org/wiki/Nova_Resource:Puppet-diffs#How_to_update_the_compiler's_facts?_(e.g._INFO:_Unable_to_find_facts_for_host_conf2001.codfw.wmnet,_skipping) [18:37:26] ugh ok going to give up just because i haven't had a working local ruby for years [18:37:30] and now is not the time :p [18:37:42] the check experimental works pretty good so far! [18:38:05] ottomata: no problem i can kick or a facts sync [18:38:18] sukhe: here's the gerrit change i'm doing that with [18:38:18] https://gerrit.wikimedia.org/r/c/operations/puppet/+/635572 [18:38:24] I"ve got Hosts: [18:38:26] in the commit message [18:38:36] and then comment 'check experimental' ingerrit [18:38:44] and it lauches a PCC job and then links the result [18:40:58] ottomata: an-laucher1002.eqiad.wmnet is missspelt [18:41:08] missing an n [18:42:13] ! [18:42:16] what i looked at it 3 times [18:42:25] `./utils/pcc 635572 an-launcher1002.eqiad.wmnet` or `./utils/pcc 635572 parse_commit` [18:42:29] DOH [18:42:30] yes took me a while :) [18:42:43] will it look at Hosts in the commit message? [18:42:50] yes [18:42:53] very cool [18:43:05] :) thx [18:43:07] ottomata: thanks! [18:43:07] heya razzi you might like this revelation ^ [18:43:31] add a Hosts: line in your git commit message [18:43:32] like https://gerrit.wikimedia.org/r/c/operations/puppet/+/635572 [18:43:39] and then on local CLI you can run [18:43:52] e.g. [18:43:52] ./utils/pcc latest parse_commit [18:43:58] and it will launch PCC for you and give you a link [18:44:07] no more navigating and filling out a browser form [18:46:06] also elukey ^^ in case you didn't know (somehow I bet you knew) [18:56:21] ottomata: Indeed, thanks for the mention [19:08:32] you'll need a jenkins api key [19:08:45] it was pretty easy to set one up in my jenkins account settings [21:05:30] I was thinking about https://phabricator.wikimedia.org/T265588, and in regards to port scans, is there a canonical place to document open ports on a per machine basis? [21:08:07] balloons: not exactly... AFAIK the intent is that the 'documentation' is the Puppet codebase itself, as in prod that's where most of the per-host firewall rules are defined, and diffscan is to catch coding mistakes close to when they happen [21:10:12] Thanks cdanis. Can you clarify what will happen on the next diffscan run? Will these unexpected open ports be accounted for somewhere?+ [21:11:04] diffscan compares the current run vs the prior run, so they'll disappear as not being newly opened anymore [21:12:11] so, it requires some paying attention and filing tasks (but most runs show no changes) [21:12:37] Got it, thank you cdanis. So it's not as intense human interpretation and triggers on changes. [21:13:09] That sentence came out weird, heh, but I get your explainations. [21:22:27] np :) the current system is hardly perfect, but it's a reasonable balance between workload and accuracy