[10:39:37] FYI, I'm installing Java 17 security updates on the Puppet servers, these need an immediate restart of the Puppet server, so there will few Puppet failures (usually 10-20 fleet-wide), I'll spread these out to minimise impact [10:40:47] ack [14:21:46] debian pkging question: For the "thirdparty" repos, do we always build our own Debian pkgs from source, or do we ever mirror the upstream third-party repos? [14:22:11] ref https://apt-browser.toolforge.org/ [14:23:22] slyngs: have you seen this? https://phabricator.wikimedia.org/T400119#11114838 [14:24:40] we do mirror and almost always? see modules/aptrepo/files/updates for example for thirdparty/ [14:24:43] inflatador: ^ [14:24:59] the way I at least have done it is run the thirdparty by moritzm and then just add it [14:25:05] thirdparty/ is generally mirrors, component/ is generally packages built by us [14:26:28] thanks sukhe . I'm looking at the current OpenSearch packages which were built by 0lly [14:27:23] based on https://wikitech.wikimedia.org/wiki/OpenSearch it looks like they're building the packages themselves. Which is fine, I just need to talk to them about it [14:28:16] inflatador: IMO and do check with Moritz once, but I think should be a component and not thirdparty then but I may be wrong [14:29:08] ACK, we (Search Platform) builds our own packages that go to https://apt-browser.toolforge.org/bullseye-wikimedia/component/opensearch13/ [14:29:38] and looking at modules/aptrepo/files/distributions-wikimedia [14:29:47] opensearch[12] are thirdparty it seems [14:30:04] So I'l need to talk to 0lly and figure out why they're building they're own and if we (Search Platform/DPE SRE) can help [14:33:31] Or maybe the docs are out of date and they're actually just mirroring [14:34:07] inflatador: exactly what Taavi wrote, thirdparty/* gets synced unchanged from an upstream repo, component/* is self-built stuff [14:35:02] moritzm thanks, I was maybe confused by https://wikitech.wikimedia.org/wiki/OpenSearch [14:35:16] which sounds like it's self-built, but also the docs could be out of date [14:38:09] cwhite ^^ just wondering, do y'all build your own OpenSearch pkgs or mirror upstream? [14:39:29] brett: found two bugs (one small, one blocker) in reviewing stuff for the m-dot sunset pilot this week. [14:39:51] small one: it seems m.wikipedia.org redirecting to www works somewhat by accident today. [14:40:21] Details in https://gerrit.wikimedia.org/r/c/operations/puppet/+/1180969 [14:42:44] inflatador: it looks like it yes, the I checked the current deb on cirrussearch1111 and it's definitely the vendor deb and not anything internally built any more [14:42:48] blocker: the cookie check for opt-in doesn't match what the current code does. We check for mf_useformat=desktop, which doesn't exist in the codebase. It works today because the cookie is not actually needed in practice (the "Mobile view" link on the footer points the browser the m-dot URL, which is sticky for subsequent pageviews by itself even without a cookie since en.m.w.o/wiki/Banana will link to other articles on the same domain, it [14:42:48] doesn't depend a cookie to work to stay on that domain). Whereas in the new model, the cookie is required for the opt-in to work as otherwise they'll continue to get the desktop version. [14:42:56] I'll update the code today. [14:43:31] moritzm ACK, thanks. The larger context is that we're looking at OpenSearch 3, which released in June [14:49:28] inflatador: prior to some minor release of OpenSearch 2x, upstream only provided docker builds. We built our own debs back then. Upstream started providing debs and rpms and we've since moved on to using upstream debs. [14:52:47] cwhite ACK, thanks for confirming. We (DPE SRE/Search Platform) are happy to help out with the packaging if you like. I don't mean to put you on the spot though...feel free to talk over with your team and we can discuss later if necessary [15:05:12] EU handoff: we had a blip of ATSBackendErrorsHigh, otherwise all good [15:17:45] if you use wmf-laptop, please upgrade to 1.0.3 which I've just uploaded, it restores the ability to fetch SSH fingerprints from config-master (it didn't set a user agent before, so now got denied access) [15:18:22] ACK, thanks [15:19:12] thanks [15:20:56] hm, what’s the current source URL for that package? I have a script running just the update-known-hosts part straight from git and apparently https://gerrit.wikimedia.org/g/operations/debs/wmf-sre-laptop/+/refs/heads/master/scripts/wmf-update-known-hosts-production?format=TEXT isn’t the correct URL anymore [15:21:10] ^^ Was just about to ask the same thing [15:21:21] * Lucas_WMDE looks at wikitech [15:22:01] aha, no more -sre, it’s just https://gerrit.wikimedia.org/g/operations/debs/wmf-laptop/+/refs/heads/master/scripts/wmf-update-known-hosts-production?format=TEXT [15:22:05] (but still master and not main) [15:23:04] now it works better \o/ [15:23:08] inflatador: ^ [15:23:54] Lucas_WMDE nice find, thanks! [15:25:10] the repository got renamed a few months ago (since the package name was rather misleading since it's generally useful to anyone with WMF prod access and not jut SREs) [15:25:36] yeah I noticed my file had last been touched in June ^^ fortunately it hadn’t broken anything yet [15:25:40] thanks for the update :) [15:29:32] I'm unable to download the script via the URL above, though? the downloaded file is just a long string starting with "IyEvYmluL2Jhc2gKCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyM"? [15:29:56] you have to base64-decode it [15:30:09] Gerrit’s version of a “raw text” URL is to give you base64 [15:30:14] ah [15:30:14] I’m guessing for security reasons [15:31:34] my systemd units look like this fwiw https://gist.github.com/lucaswerkmeister/3c4f366bdb88fb6855f5f444a11628aa [15:31:54] though I’m sure most people should install the full package :) [15:38:48] Fancy! I just have a cronjob that runs on my Mac