[06:21:25] I send a series of welcome messages to new members on their user talk pages. Would this be considered vandalism? (Is it prohibited?) [06:28:16] Grassei: it shouldn't be but no idea why you're asking in this channel. You're probably best asking in the channel for that wiki. [06:28:44] Okay [10:07:59] I see Slack is about to start blocking the version of firefox in Debian stable :-/ [10:43:29] Google's well on the way to owning the entire web eh [18:12:43] How long should I expect it to take for my certs to update after I change an entry in hieradata/role/common/acme_chief.yaml? [18:14:00] on the host itself? an agent run should be sufficient [18:20:24] hm, I don't see my new snis in https://gerrit.wikimedia.org/r/c/operations/puppet/+/1068823/2/hieradata/role/common/acme_chief.yaml but I'll look again [18:24:05] andrewbogott: that is an internal domain though [18:24:20] acme-chief won't work for that [18:24:52] maybe you wanted it in authorized_hosts instead of the SNI? [18:25:14] maybe! I will try that [18:25:20] thx [18:26:32] but those are the same I just looked. so you will have to revert this patch anyway since it is causing agent to fail on the acme-chief host [18:26:44] oh, no, they're already under authorized hosts. [18:26:46] yep [18:26:48] OK, will revert [18:26:51] Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, ldap-codfw1dev SNI (cloudservices2004-dev.codfw.wmnet) contains internal domain (file: /etc/puppet/modules/profile/manifests/acme_chief.pp, line: 56, column: 17) on node acmechief1001.eqiad.wmnet [18:27:23] So... there's no way to have the cert be valid for those internal names? (This is for a test/dev thing that is replicating a case where the host is on an external name) [18:29:03] not with acme-chief. for internal PKI, see cfssl [18:29:09] https://wikitech.wikimedia.org/wiki/PKI/Clients [18:29:48] The whole idea is to follow the same puppet paths as prod, but I'll add a special case someplace. [18:43:42] we've been over this several times already, a public CA like Let's Encrypt can't issue certificates for private domains that aren't valid on the Internet [18:53:17] the good part: don't need to use cergen anymore, puppet "just does it" [18:53:45] much better with cfssl than before [18:57:18] I don't think you need to have a $realm check kind of thing, if it's an internal name it would be cfssl in both realms and if it's an external name it can be acme_chief in both, or it can be letsencrypt with certbot in cloud, to avoid setting up a local acmechief [19:04:56] Several cloud environments have their own acmechief instances [19:12:28] yep. just adding as another option, there is also existing code that uses certbot with LE directly for projects without those. but for this case, internal names, it can be the same puppet code in prod and cloud now and all that manual works is gone. so yay!