[00:24:33] 10Domains, 10Traffic, 06Operations: Guapopedia - https://phabricator.wikimedia.org/T144276#2594645 (10Dzahn) I can't find the term "Guapopedia" at all with major search engines. You would expect it has been at least talked about _somewhere_. But no, all we have is El Guapo, the nickname for former major lea... [00:28:57] 10Traffic, 10DNS, 06Operations: Instead of url forward for wikipedia.in ... add server ip. - https://phabricator.wikimedia.org/T144508#2603910 (10Dzahn) [00:29:42] 10Traffic, 10DNS, 06Operations: Instead of url forward for wikipedia.in ... add server ip. (point wikipedia.in to 180.179.52.130) - https://phabricator.wikimedia.org/T144508#2603913 (10Dzahn) [00:35:13] 10Traffic, 10DNS, 06Operations: Instead of url forward for wikipedia.in ... add server ip. (point wikipedia.in to 180.179.52.130) - https://phabricator.wikimedia.org/T144508#2602033 (10Dzahn) for context of this request and other ops Currently, in the DNS templates, wikipedia.in is a symlink to wikipedia.or... [00:54:21] 10Traffic, 10DNS, 06Operations, 06WMF-Legal, 13Patch-For-Review: Instead of url forward for wikipedia.in ... add server ip. (point wikipedia.in to 180.179.52.130) - https://phabricator.wikimedia.org/T144508#2603990 (10Peachey88) Probably want #wmf-legal to weigh in on it. But from my personal [non offic... [00:54:36] 10Domains, 10Traffic, 10DNS, 06Operations, and 2 others: Instead of url forward for wikipedia.in ... add server ip. (point wikipedia.in to 180.179.52.130) - https://phabricator.wikimedia.org/T144508#2603993 (10Peachey88) [01:38:28] 10Domains, 10Traffic, 10DNS, 06Operations, and 2 others: Instead of url forward for wikipedia.in ... add server ip. (point wikipedia.in to 180.179.52.130) - https://phabricator.wikimedia.org/T144508#2602033 (10Platonides) We (WM-ES) have requested the same thing for wikipedia.es a long time ago. It should... [01:43:19] 10Domains, 10Traffic, 10DNS, 06Operations, and 2 others: Instead of url forward for wikipedia.in ... add server ip. (point wikipedia.in to 180.179.52.130) - https://phabricator.wikimedia.org/T144508#2602033 (10BBlack) >>! In T144508#2604046, @Platonides wrote: > Security wise, these domains are not a probl... [08:57:03] 10Domains, 10Traffic, 10DNS, 06Operations, and 2 others: Point wikipedia.in to 180.179.52.130 instead of URL forward - https://phabricator.wikimedia.org/T144508#2604459 (10Aklapper) [09:11:29] so zayo will actually perform the maintenance tomorrow apparently [09:11:51] "The card is due to arrive late morning/ early afternoon 9/2/2016 and will be replaced during the maintenance window 9/3/2016 0:00 to 0500 MDT." [09:13:28] which means we cannot really downgrade ulsfo upload till next week [09:26:35] well that's not really true, we could repool ulsfo later on, downgrade and depool it again before tomorrow [09:34:00] or we can make sure the other link is primary so it wouldn't be affected on minor flaps [09:34:07] the only thing was, telia was doing maintenance as well [09:34:13] not even sure it was on that link, but didn't want to take chances [09:34:32] but once their maint window is over in a bit i'd have no problems with having ulsfo up on telia with zayo backup [09:36:23] cool, let's do that [09:38:15] 10Traffic, 10Varnish, 06Operations, 13Patch-For-Review: Convert upload cluster to Varnish 4 - https://phabricator.wikimedia.org/T131502#2604493 (10ema) Due to multiple issues with Varnish 4 including T144257 and recurring 503 plateaus, we've decided to downgrade most of cache_upload in ulsfo to Varnish 3.... [09:48:47] ema: made it backup now [09:48:53] so in a few hours, you can pool ulsfo [09:50:29] mark: thanks! [10:22:17] 10Domains, 10Traffic, 10DNS, 06Operations, and 2 others: Point wikipedia.in to 180.179.52.130 instead of URL forward - https://phabricator.wikimedia.org/T144508#2602033 (10grin) >>! In T144508#2604050, @BBlack wrote: > I disagree. In general, we can't expect volunteer/chapter portals hosted elsewhere to... [10:37:37] ema, bblack: I've build a new kernel package with a bumped ABI (so linux-image-4.4.0-2 now), that fixes modprobing before the next reboot [10:38:09] will run a few more sanity checks and then upload, linux-meta also needs to be updated to the new binary package name [10:39:01] nice [10:46:25] actually, I'll do another build to fix the displayed source version in uname, that has been a constant source of confusion [10:46:39] moritzm: yes please! :) [10:48:51] my current build uses teh default, which parses the value from the latest debian/changelog entry, so "+wmf5" would display "+wmf4", that's bound to be irritating :-) [11:50:07] bblack, mark: OK with repooling ulsfo? https://gerrit.wikimedia.org/r/#/c/308156/ [12:00:44] 10Domains, 10Traffic, 10DNS, 06Operations, and 2 others: Point wikipedia.in to 180.179.52.130 instead of URL forward - https://phabricator.wikimedia.org/T144508#2604626 (10BBlack) >>! In T144508#2604540, @grin wrote: >>>! In T144508#2604050, @BBlack wrote: > >> I disagree. In general, we can't expect vol... [12:02:57] i am [12:07:53] +1 [12:09:35] done [12:44:32] 10Traffic, 10ArticlePlaceholder, 06Operations, 10Wikidata: Performance and caching considerations for article placeholders accesses - https://phabricator.wikimedia.org/T142944#2604711 (10hoo) I've created {T144592} for a trial of submitting placeholders to search engines. Based on that, we can (probably) d... [13:26:21] 10Traffic, 06Operations: OpenSSL 1.1 deployment for cache clusters - https://phabricator.wikimedia.org/T144523#2604754 (10MoritzMuehlenhoff) Thanks for getting this started! My gut feeling is that we should wait for 1.1.0a . The release only happened a week ago and there will be inevitable bugs that only sho... [13:43:58] summarized up this morning, because sometimes it's hard to remember or find the specifics for practical stuff: [13:44:01] https://wikitech.wikimedia.org/wiki/Traffic_cache_hardware [14:49:12] And because I asked because I couldn´t find everything. Thanks again! [15:03:05] 10Domains, 10Traffic, 10DNS, 06Operations, and 2 others: Point wikipedia.in to 180.179.52.130 instead of URL forward - https://phabricator.wikimedia.org/T144508#2605044 (10grin) @BBlack thanks for the detailed reply. I try not to talk apart this task, so I try hard to be brief. >>! In T144508#2604626, @BB... [15:07:32] ema, bblack: When logged in all traffic is passed back to the app servers right? What´s the reason for that? I bet it is obvious but right now I can´t think of it I´m afraid. [15:53:17] 10Domains, 10Traffic, 10DNS, 06Operations, and 2 others: Point wikipedia.in to 180.179.52.130 instead of URL forward - https://phabricator.wikimedia.org/T144508#2605156 (10Aklapper) This Phabricator task is //specifically// about pointing wikipedia.in to 180.179.52.130. For general high-level discussion... [16:33:55] 10Domains, 10Traffic, 10DNS, 06Operations, and 2 others: Point wikipedia.in to 180.179.52.130 instead of URL forward - https://phabricator.wikimedia.org/T144508#2605282 (10BBlack) >>! In T144508#2605156, @Aklapper wrote: > This Phabricator task is //specifically// about pointing wikipedia.in to 180.179.52.... [16:35:16] Snorri: not all traffic. MW/Services signal via Cache-Control which URIs are user-login sensitive and which aren't. But in practice, for example, all article pages are. [16:35:48] Snorri: that's in part because of how the page is composed: the login/out status and username in the top right are actually composed together into a single output with the article text. [16:36:12] Snorri: but also, if we cached article content for logged-in editors, we'd have to have other ways to solve them seeing stale versions of the things they're editing. [16:36:50] there are open tasks about making all of those things better heh :) [16:36:55] Ahhh that makes sense. The second reason I thought of but wasn´t sure this is the reason. Together this makes sense. [17:02:13] upload ulsfo downgraded to v3 except for cp4005 [17:02:53] we can now take a close look to cp4005 and depool it if something goes wrong :) [17:06:45] 10Traffic, 06Operations: OpenSSL 1.1 deployment for cache clusters - https://phabricator.wikimedia.org/T144523#2605412 (10BBlack) >>! In T144523#2604754, @MoritzMuehlenhoff wrote: > As for re-enabling triple-des/rc4 I'm undecided with a tendency towards sticking with the openssl default (depending on when we g... [17:55:44] 10Traffic, 06Operations, 13Patch-For-Review: Planning for phasing out non-Forward-Secret TLS ciphers - https://phabricator.wikimedia.org/T118181#2605488 (10BBlack) From the CN subtask ( T144194 ), we've learned that CN won't be a useful tool for targeting the mass ancient browsers that matter. It may be abl... [18:34:36] 10Traffic, 06Operations: Strong cipher preference ordering for cache terminators - https://phabricator.wikimedia.org/T144626#2605597 (10BBlack) [21:38:27] 10Traffic, 06Operations, 13Patch-For-Review: Decom bits.wikimedia.org hostname - https://phabricator.wikimedia.org/T107430#2606028 (10BBlack) FWIW, the iOS app change hit its first beta release 3 weeks ago in 5.1.0.900, and was released with 5.1.0.913.1 about two weeks ago.