@cwdent has the send_nsca part also been done?

Yep, was resolved in T200304 , kind of a duplicate.

It's the right thing to add operations because we need to do DNS and Apache. But after that is done you can remove it. ACK.

shn has been created in DNS:

Still needs user input there. Moving to new column "Stalled / Needs Input" on the Wiki-Setup workboard i created for this.

In T204477#4587755, @MarcoAurelio wrote:

While we're on Datacenter-Switchover-2018 we ain't allowed to create new wikis.

^ there might be an issue with this, it seems "gdnsd reload-zones" isn't the correct syntax anymore.. hold on for a bit..

@Reedy @Jalexander Could you give access to @Raystorm ?

https://za.wikimedia.org
https://za.m.wikimedia.org

Ok, i will remove myself from this ticket for now but that doesn't mean i have an opinion on this one way or another. Once there is some consensus and you need technical help again, please simply re-add me. Cheers

looks like @elukey made this as the fix:

https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=releases1001&service=HTTP+releases-jenkins.wikimedia.org
https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=releases2001&service=HTTP+releases-jenkins.wikimedia.org

Needs to be /login but not /login/

https://releases-jenkins.wikimedia.org/login/ -> HTTP ERROR 404

adding /login/ to the URL changes it from "403 Forbidden" to "404 Not Found"

Of course i am not involved in this issue so i can't comment much but let me say as an outsider i am a bit confused because you are saying "I don't really object the creation" followed by "i stand by the decision of stalling". I haven't heard of user groups with a board before, only chapters and this is what Urbanecm said above as well. Though you seem to be saying that existence of a board is necessary to create the group.

This is a warning level alert on the hosts releases1001 and releases2001.

icinga will stop using the mysql module once on stretch. Once T202782 is resolved and einsteinium isn't the prod Icinga server anymore this part will be done.

Ok, no problem. It can stay in "stalled" status, that's ok.

Implemented as suggested on https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/466951/ and https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/467011/

Ok. The need for "sudo as www-data" wasn't obvious to me from the request or the linked wikitech page. I see it when looking at actual mwrepl source though.

In T207052#4669419, @Urbanecm wrote:

Objections were raised.

Done. I logged in at the admin interface using the master password from pwstore and added aklapper@ as an additional admin.

I saw we also have "maintenance-log-readers". It allows for access to mwmaint* hosts and reading logs (includes running journcalctl, dmesg, anything as syslog user).

In T200742#4463551, @Varnent wrote:

That's not a bug - it is a design feature. Once the translations are completed - you will see them integrated across the design. :)

Since the request is specifically for viewing logs i recommend using the group "mw-log-readers" which was made specifically for this purpose.

I assume you can rename it without needing an admin? If not let me know.

Cool, sounds good:) I guess we can resolve it here then.

Edited the custom policy of the new pad, L36 to allow "members of legal" and @JeanFred

I think we should first let Stephen try if it works to edit the pad above now. Let's find out why the custom policy works or doesn't work, it says Legal Team should be able to edit. Let's not just fix it by using admin rights?

I created L36 - https://phabricator.wikimedia.org/legalpad/view/36/

added to wmf and ops LDAP groups.

subscribed to ops and ops-private

is MobileFrontend enabled?

This should resolve the ticket. Please reopen if something doesn't work.

approved in SRE meeting

Yes, i was thinking the same. I did not expect to add this as an Icinga check. I expected to add a script that is run by cron and sends out email to tell us.

Service
Memory correctable errors -EDAC-
On Host
db1069
(db1069)

Current Status: CRITICAL (for 0d 8h 6m 11s)
Status Information: cluster=misc device=megaraid,8 instance=heze:9100 job=node site=codfw

confirmed on icinga1001 that the fix for check_ssl is actually:

new approach to make check_ssl work:

@Cwhite regarding the Juniper alerts that have "Can't locate Nagios/Plugin/Getopt.pm", Google sent me to our own phab where Fundraising tech fixed it in T195522

@Aklapper thanks. i didn't know the "for affiliate campaign" part of it. That makes it work related.

bpfilter made it into 4.18 kernel and there are claims that it would "eventually replace both iptables and nftables"

Automatic mail to primary list admins of all lists without description sent with:

affected lists as of today:

https://wikitech.wikimedia.org/wiki/Server_Lifecycle#Active_-%3E_Decommissioned

Thanks again. As always it's greatly appreciated that you add all the technical details and background.

I have replied by email and referred to this ticket. I also pointed out we don't agree that this check is even useful (but that it was fixed nevertheless).