Thanks @Huji Lee <[email protected]>! TIL openssh has super simple ProxyJump directive :).
po 7. 9. 2020 v 21:32 odesÃlatel Huji Lee <[email protected]> napsal: > This is also a good time remind everyone to update their ProxyJump > configuration [1] to include the new TLDs. At least I would have forgotten > it if I had not seen this remidner. > > [1] > https://wikitech.wikimedia.org/wiki/Help:Accessing_Cloud_VPS_instances#ProxyJump_(recommended) > > On Mon, Sep 7, 2020 at 2:31 PM Andrew Bogott <[email protected]> > wrote: > >> Reminder: This naming change is happening tomorrow, less than 24 hours >> from now. Update your .ssh/config now so you aren't confused tomorrow! >> >> -Andrew >> >> >> -------- Forwarded Message -------- >> Subject: Phasing out the .wmflabs tld on September 8th >> Date: Wed, 19 Aug 2020 08:55:18 -0500 >> From: Andrew Bogott <[email protected]> <[email protected]> >> Reply-To: [email protected] >> To: [email protected] >> >> tl;dr: >> >> VMs created on or after September 8th will stop having .eqiad.wmflabs >> domains, and be found only under .eqiad1.wikimedia.cloud >> >> >> The whole story: >> >> Currently cloud-vps VMs stand astride two worlds: wmflabs and >> wikimedia.cloud. Here's the status quo: >> >> >> - New VMs get three different DNS entries: >> hostname.project.eqiad1.wikimedia.cloud, hostname.project.eqiad.wmflabs, >> and hostname.eqiad.wmflabs [0] >> >> - Reverse DNS lookups return hostnames under eqiad1.wikimedia.cloud >> >> - VMs themselves believe (e.g. via hostname -f) that they're still under >> eqiad.wmflabs >> >> That hybrid system has done a good job maintaining backwards >> compatibility, but it's a bit of a mess. In the interest of simplifying, >> standardizing, and eliminating ever more uses of the term 'labs', we're >> going to start phasing out the wmflabs domain name. Beginning on September >> 8th, new VMs will no longer receive any naming associated with .wmflabs [1]. >> >> - New VMs will get one DNS entry: hostname.project.eqiad1.wikimedia.cloud >> >> - New VMs will continue to have a pointer DNS entry that refers to the >> .wikimedia.cloud name >> >> - New VMs will be assigned an internal hostname under .wikimedia.cloud >> >> In order to avoid breaking existing systems, these changes will NOT be >> applied retroactively to existing VMs. Old DNS entries will live on until >> the VM is deleted and should be largely harmless. If, however, you find >> yourself rewriting code in order to deal with VMs under both domains (due >> to the change in hostname -f behavior), don't worry -- adjusting an old VM >> to identify as part of .wikimedia.cloud only requires a simple change to >> /etc/hosts. I'll be available to make that change for any project that >> chooses consistency over backwards-compatibility. >> >> >> [0] >> https://phabricator.wikimedia.org/phame/post/view/191/new_names_for_everyone >> >> [1] https://phabricator.wikimedia.org/T260614 >> >> >> _______________________________________________ >> Wikimedia Cloud Services announce mailing list >> [email protected] (formerly >> [email protected]) >> https://lists.wikimedia.org/mailman/listinfo/cloud-announce >> _______________________________________________ >> Wikimedia Cloud Services mailing list >> [email protected] (formerly [email protected]) >> https://lists.wikimedia.org/mailman/listinfo/cloud >> > _______________________________________________ > Wikimedia Cloud Services mailing list > [email protected] (formerly [email protected]) > https://lists.wikimedia.org/mailman/listinfo/cloud >
_______________________________________________ Wikimedia Cloud Services mailing list [email protected] (formerly [email protected]) https://lists.wikimedia.org/mailman/listinfo/cloud
