[08:24:53] 10Traffic, 10Operations, 10ops-ulsfo: setup bast4001/WMF7218 - https://phabricator.wikimedia.org/T179050#3711643 (10MoritzMuehlenhoff) This is currently installed with jessie, but if we setup a new box, let's use stretch from the start? [13:49:44] 10Traffic, 10Operations, 10ops-ulsfo: setup bast4001/WMF7218 - https://phabricator.wikimedia.org/T179050#3726257 (10BBlack) >>! In T179050#3725651, @MoritzMuehlenhoff wrote: > This is currently installed with jessie, but if we setup a new box, let's use stretch from the start? +1 We may as well move to stre... [13:55:38] 10Traffic, 10Operations, 10ops-ulsfo: setup bast4001/WMF7218 - https://phabricator.wikimedia.org/T179050#3726279 (10MoritzMuehlenhoff) >>! In T179050#3726257, @BBlack wrote: > +1 We may as well move to stretch here. For the bastion/installserver role it should be pretty simple? I wouldn't expect any proble... [14:07:38] ema: you have anything going on live? if not I might disable puppet on all the caches for a bit and test some ipsec-related stuff... [14:07:56] bblack: nope, please go ahead [14:23:52] 10Traffic, 10Operations, 10Services (watching): restbase.svc.eqiad.wmnet directs requests to staging if the origin is staging too - https://phabricator.wikimedia.org/T179494#3726448 (10mobrovac) [14:32:31] mobrovac: I highly doubt that LVS is setup to do that, it usually doesn't care at all where requests are coming from [14:32:38] isn't that some special setup on the staging hosts? [14:33:20] does it resolve to some other lvs ip or something? [14:35:10] oh he isn't in here hehe [14:37:11] ok it's because they have the lvs service ip bound to lo of course [14:39:35] right [14:40:04] 10Traffic, 10Operations, 10Services (watching): restbase.svc.eqiad.wmnet directs requests to staging if the origin is staging too - https://phabricator.wikimedia.org/T179494#3726448 (10mark) The staging hosts have the LVS service IP (restbase.svc.eqiad.wmnet, 10.2.2.17) bound to their loopback IP - as every... [14:53:08] 10Traffic, 10Operations, 10Services (watching): restbase.svc.eqiad.wmnet directs requests to staging if the origin is staging too - https://phabricator.wikimedia.org/T179494#3726448 (10BBlack) I don't think they're //currently// puppetized for lvs::realserver, but it looks like the machines had such a config... [14:57:06] removing the package will remove the ip also [15:13:50] 10Traffic, 10Operations, 10Services (done): restbase.svc.eqiad.wmnet directs requests to staging if the origin is staging too - https://phabricator.wikimedia.org/T179494#3726709 (10mobrovac) 05Open>03Resolved a:03mobrovac Ok, after a round of `apt-get remove --purge wikimedia-lvs-realserver && ip addr... [16:38:58] bblack: do you see any drawbacks in adding layer-info to X-Cache? https://gerrit.wikimedia.org/r/#/c/387817/ [16:39:09] X-Cache-Status I mean [16:40:05] ema: not sure, but it'll be a few minutes before I stare at that [16:40:39] ema, bblack: https://news.ycombinator.com/item?id=15601729 [16:40:44] if there's anything important relying on XCS being as it is now we could use another header for this! [16:40:50] bblack: sure, no rush [16:41:20] that's a lot of posts in ~1h, people must have scrapers monitoring for those threads lol [20:28:05] 10netops, 10Operations, 10fundraising-tech-ops: bonded/redundant network connections for fundraising hosts - https://phabricator.wikimedia.org/T171962#3727851 (10Jgreen) [20:28:09] 10netops, 10Operations, 10fundraising-tech-ops, 10ops-eqiad: connect second interface for each frack to opposite switch for each eqiad host - https://phabricator.wikimedia.org/T176975#3727849 (10Jgreen) 05Open>03Resolved a:03Jgreen