@cmooney Yes, that looks good to me. We can still go for Dec 4 - feel free to pop something on my calendar.

@cmooney Yes, that looks good to me. We can still go for Dec 3 - feel free to pop something on my calendar.

In T401832#11388046, @MoritzMuehlenhoff wrote:

I created an update based on the last version in Debian unstable before it got removed from the archive and fixed it to build on trixie (the more recent GCC caused some STL-related changes in the versioned symbols). You can find the source and the debs for testing in /home/jmm/pcre on build2002. Changes relative to the last version in sid are here: https://phabricator.wikimedia.org/P85387

To add on, what about the maintenance of package.json and the dependencies that it pulls in?

@MatthewVernon Looks like you were a maintainer of pcre3 in Debian before it was axed in Trixie. Sadly, we're in need of that package for trafficserver (the current patches for enabling pcre2 support are immature and we just want to continue using pcre until it's ready). dgit's version of pcre3 fails compilation. It looks like https://salsa.debian.org/ondrej/pcre3 bumped the version up and had work on it as if it were going to be pushed to Trixie before the decision was made to discontinue support. Would you advise using that as a base? It compiles fine and uses the final release of pcre, so I would imagine that to be the most-correct approach.

@SLyngshede-WMF I would guess "yes", since we modify the source (example)

@RobH Works for me. Mind adding a calendar invite? Thanks.

@Niepodkoloryzowany This issue should be resolved. If that's not the case, please do re-open this report. Have a great weekend!

Hello! This is an ongoing incident that we're handling. Thank you for your patience!

Add @CRoslof for visibility.

We confirmed the API response depends on whether the TLD supports automated DNSSEC or not.

For TLDs that support automated DNSSEC, the endpoint will always return 200, regardless of whether DNSSEC is currently enabled for the domain.

For TLDs that do not support automated DNSSEC, DNSSEC may still be handled manually, but the API currently returns 400 even for an authenticated and valid request.

For example, you will receive 400 for this API call since the extention, .jp.net does not support automated DNSSEC.
I understand this behavior is confusing and misleading. I made a feature request to our engineering team to always return 200 for any authenticated and valid requests to the DNSSEC endpoint regardless of the TLD 's DNSSEC automation s

I went ahead and created T409486 which proposes extending ncmonitor to validate/notify on our redirection endpoints. Thanks for the suggestion!

There's a potential issue with MarkMonitor's API - it's responding with a 400 if a domain does not have DNSSEC enabled but gives a 200 + record information if it does. I suspect that's a bug on MM's side and am reaching out to our contact for clarification.

As we're moving towards a containerized approach (T408617), deployment via systemd will be removed.

Now that there's a redirect I'm not sure whether we should keep or kill the ncredir redirect. What if they decide to re-add it later in the future?

I'm going to first verify that this was intentional before merging. Thanks for bringing this up!

Ah, I see that it's stuck in the staging time indeed. Thanks for the clarification.

This is pushed.

To be clear, this isn't a regression in recent changes, is it?

I've created both donate.wikipedia25.org and donate.wikipedia25.com. Closing now; Please re-open if something's amiss. Thanks!

Not resolved due to broken tests.

This has also caused our varnish test suite to fail as browser-detection.inc.vcl does not exist.

Hi, @JKelsoteel-WMF! Thanks for the detailed ticket - it helps make things clear for us. I've pushed the DNS changes, so I'll go ahead and close this ticket. If you feel that something's wrong, don't hesitate to re-open. Thanks!

WMF utilizes Markmonitor's trademark protection offerings, including GlobalBlock, which provides protections against homograph attacks. For instance: replacing the first i in wikipedia.org with the lookalike і results in this:

Should the broken tests as mentioned in T398161#11227347 be brought up in a new ticket?

Thank you, all. :)

I was able to get in contact and the domain transfer will begin shortly. Unfortunately, services will be disrupted for a short while as we initiate the process for our HTTPS certificate.

Yes, good for me. I'm assuming you meant November 4 as per your other ticket comment. That works.

Okay! @JAbrams and I had a delightful time setting up the host mapping: trustandsafety.wikimedia.support and committee.wikimedia.support are both live. HTTPS certificates are issued/handled by Zendesk itself (via LetsEncrypt). HSTS has been enabled as well. Note that Zendesk agents/admins will still continue to see the zendesk URL when using their interface - that's just how Zendesk works. This is only for the user-facing support pages.

25.wikipedia.org is now redirecting to https://wikimediafoundation.org/wikipedia25 - Closing now - Please do re-open if we missed anything. Thanks!

Same here. Feel free to plop something on my calendar!

wiki25.com, wiki25.org, wikipedia25.com and wikipedia25.org now redirect to https://wikimediafoundation.org/wikipedia25

In T407156#11274497, @SCampos-WMF wrote:

The redirects mentioned in my request above apply only to external-facing audiences, which we primarily reach through our WordPress site. @BCornwall I believe that we should avoid a 404 error, would it be possible to activate the redirect by November 5? That would give us time to run some tests on our side before Nov 10th and ensure everything is ready for launch on that day.

I do not have merge permissions for that repo, so someone from analytics will need to do so.

I have not heard back since 2025-10-01. @JAbrams, @jrbs, can we set up a time?

@SCampos-WMF The changes are ready to go - when can we expect a functional page to be posted? Would you prefer we push the changes now and just have it redirect to a 404'ed page? It'd be best to be absolutely sure that it will be a Wordpress page at that address so we don't have to re-work everything again.

The google sites page leaves many questions, for sure... but I'm operating under the assumption that the Sites page is secondary and can be ignored by infra. We're going to support the established WP infra.

https://sites.google.com/wikimedia.org/wp25-foundation-celebration/ recently launched per a org-wide email. I contacted them about the registrations of all these domains and it doesn't appear that they wish to use them. I'll proceed to create redirects for all of those domains to wikimediafoundation.org/wikipedia25 unless anyone feels otherwise.

I'm fine with manually editing the interfaces but ensuring that the next time there's an install run it'll properly enumerate.

@cmooney That looks good to me. As to whether /etc/network/interfaces will be reconfigured... I believe it will *not* reconfigure for us. That information is hardcoded in the installer.

@RobH Thanks for soliciting the feedback! The cp hosts depooling schedule is fine. For DNS, we would prefer to depool these as well rather than unplug them live.

Waybar module example:

Sure, no problem. Have at it. LMK if you need any help.

@cmooney Sounds good! Should I be scheduling with you or @VRiley-WMF?