confirmed that the addtional_gropups parameter is not compatible with groups managed by the admin module. this is because the admin module use an exec to check on group permissions. It doesn't know about the groups managed by the systemd::user (or user) type and thus removes them. then the systemd::sysuser/user resources adds them back causing a puppet change on every run

There is already an group named sre-admins (used for SRE's without root), that gives the same SSO access to web service ops the ops group, but doesn't have +2 on the operations repos. We could either use this group or copy it. To avoid confusion i would vote to create a new group but use sre-admins as an reference when assigning permissions in the puppet repo.

In T308013#7920581, @hashar wrote:

Before October 1st 2012, the code is my own and per my contract at the time: "source code contributed as part of this contract relationship will be licensed under an applicable open source license" and I hereby place it under Apache License 2 with copyright Antoine Musso <hashar@free.fr>. Then I don't know whether there is a lot left from this era beside the Rake puppet-lint, contint and jenkins modules.

From October 1st 2012 till December 31 2019 I had a joint copyright agreement with the Wikimedia Foundation. So essentially everything is ALSO owned by "Wikimedia Foundation Inc." and I guess that can be assigned to both of us Antoine Musso <hashar@free.fr> and Wikimedia Foundation Inc..

Since March 2020, the code is owned by my employer WFRR CRM Services (the France local SafeGuard branch). I am guessing there is some legal agreement with Wikimedia Foundation Inc and if so the code can be attributed to Wikimedia Foundation Inc.. Then given I don't think I have introduced any module but modified existing code, all those probably get placed under Apache License 2 which thus implies the code is also under Apache License 2.

Not directly because of the datacenter-ops group but you get it from the LDAP ops group and John is in that group. So that should work

For me the access to puppet-merge and +2 on the puppet repo needs more information as to what tasks need to be preformed. As mentioned the combination of theses two privileges allows one to the same amount of control as global root.

In T288470#7938289, @BTullis wrote:

Thanks @jbond - Do you think it would be better to create a new intermediary for Cassandra, similar to the way we did for Kafka?

its probably more related to load order so slightly different issue on production but i think that the same fix wil solve both. however feel free to assign the task to me once WMCS is happy and i can double check production :)

production host

This issue is also affecting production reimages see P27926

@jcrespo see T308601 taavi is applying fixes as we speak

@BTullis thanks and yes i agree any new migrations should go directly to pki.discovery.wmnet. Happy to help

In T308350#7931549, @thcipriani wrote:

@lmata/@MoritzMuehlenhoff Can you add it to your Monday agenda please?

This has been added, will update after the meeting

<3 thanks all!

This was approved will create the CR tomorrow

In T308013#7930591, @jcrespo wrote:

Could you expand on why Apache 2 specifically (e.g. vs MIT or BSD?)- is it because trademarks?

In T307762#7930473, @elukey wrote:

Nice catch, TIL about wmflib::resource_hosts, thanks John!

In T308350#7928087, @thcipriani wrote:

Sounds good from from my side: seems analogous to the current setup of contint-roots on the Jenkins hosts.

Added @LSobanski + @akosiaris per the approval line in data.yaml

This is working now. I had to fix up api redirect in "[LOCAL HACK] Attempt to secure Puppet DB better" on the deployment prep puppetmaster. please reopen if there are still issues

We have now disabled sending and accepting LANG and LC environment variables in production, closing

$ git log [11:24:20]
commit 542f2c5b55fd7a6035f0aff2d0896fb0dd89c6b4 (HEAD, tag: v3.0.12-wmf)
Author: John Bond <github@johnbond.org>
Date: Thu Jun 3 21:16:42 2021 +0200

In T307873#7914164, @jbond wrote:

My reading of https://seclists.org/oss-sec/2017/q4/324 suggests that if a BDAT command is issued after the mail or RCPT command then exim will respond with this error message. Looking at the log line above we see the commands issued where C=EHLO,STARTTLS,EHLO,MAIL,RCPT,BDAT,RSET,NOOP,MAIL,RCPT,BDAT) i.e. we do see a BDAT after RCPT

My reading of https://seclists.org/oss-sec/2017/q4/324 suggests that if a BDAT command is issued after the mail or RCPT command then exim will respond with this error message. Looking at the log line above we see the commands issued where C=EHLO,STARTTLS,EHLO,MAIL,RCPT,BDAT,RSET,NOOP,MAIL,RCPT,BDAT) i.e. we do see a BDAT after RCPT

demonstrating the we support chunking

I have looked in our logs and the following is an example of what we see on our side

@jhathaway wonder if anything may have changed recently

Also see

Further to this on the passive node we get an error on every puppet run due to the following

We have had a response from leagle which state3s that it is fine to licence all *@wikimedia.org contributions under the Apache licence. As such i think we can start to do this with some module that we know have been developed completly internaly e.g. apereo_cas (which almost exclusively developed by myself). In order to move a module to this new licenced model i propose that we update modules to:

• add an spdx-licence header to each file in the module
• add the apache licence file to the route of the module
• create and spdx file in the module directory root

Ill create a change to convert apereo_cas to demonstrated and critice the list above.

puppetdb package is not currently available in bullseye

In T300977#7836272, @Volans wrote:

If I may add my use case too, I would like to be able to restrict the access to the webproxies from the cumin hosts (cluster::management puppet role) and potentially other sensitive hosts. Ideally to an allow-list of URLs or something similar.

this is likely related to https://wikitech.wikimedia.org/wiki/Performance/Graphite/Synthetic_Instance

As for the puppet-merge on the puppetmasters, does the datacenter-ops have +2 on the operations/puppet repository on Gerrit?

To be explicit +2 on gerrit and sudo puppet-merge allows one to promote them self to global root, which seems undesirable. what exactly is puppet-merge access required for. perhaps we can work on migrating this functionality elsewhere?

I think the best option is to use OIDC, however that comes with a couple of caveats.

1. We don't currently have OIDC support enabled in CAS so there could be some teething issues enabling this first services
2. We are currently planning to upgrade CAS and would want to have that bed in before adding OIDC support (we hope to have idp-test working within ~2 weeks)

This shouldn't be required as we allready have code to install ssacli based on the value of the raid fact. We should revert all the changes here and investigate why machines dont have the correct fact value. What machine where you seeing issues on?

In T67270#7832446, @Ladsgroup wrote:

@jbond In the meantime, maybe we can add a rule to lint -1ing any new puppet/or otherwise file that doesn't SPDX-License-Identifier?

The following also seems to work, however the functionality is not documented on the puppetdb api pages so it may not always work

use cumin to ask "what is the kernel version of all machines owned by $subteam" or "which hosts owned by $subteam are still on buster"

As we pass this value as a paramter to profile::contacts we can allready use cumin to preform theses searches. e.g.

As per an offline conversation with @Volans. newer versions of netbox allow us to preform custom data validations as such i'm going to set this ticket to stalled until we upgrade netbox to at least version 3.0

Im not sure i understand this response. The value entered which caused an error was ns-recursor0.openstack.codfw1dev.wikimediacloud.org. instead of ns-recursor0.openstack.codfw1dev.wikimediacloud.org both are valid FQDN and strictly speaking the one with the terminating period is the more correct form.

indeed it seems that the data is no longer in gsuite. ill take a new look at https://gerrit.wikimedia.org/r/c/operations/puppet/+/761029

In T211750#7876563, @MoritzMuehlenhoff wrote:

In T211750#7876514, @jbond wrote:

We already have logic to detect python2 vs python3 files based on the shebang and could reuse this for any black jobs (forgetting for a moment that a shbang of /usr//bin/python means different things on bullseye vs stretch)

Even on Bullseye /usr/bin/python means Python 2 by default (any such script running on Bullseye will simply not find the command).

There is a separate package which symlinks python/python-dev to the Python 3 versions (https://tracker.debian.org/pkg/what-is-python) but we don't use it.

In T275575#7823142, @razzi wrote:

@jbond I see you've worked on our identity provider, is it possible to require multifactor authentication for a service?

In T211750#7853874, @Volans wrote:

In T211750#7853334, @jhathaway wrote:

Our we ready to consider running black on our puppet repo?

moritz suggested we should just add all software we maintain so ill create a cr to do that

Im not too familiar with code search so not sure wht does and doesn't make senses but tagging a few project owners
@Joe pcc
@Volans anything extra you can think of e.g. cumin, debmonitor, debdeploy, homer
@CDanis klaxon, statograph?
@ssingh censorship monitoring?
@RLazarus httpbb?
@JMeybohm cfssl-issuer?

@TheDJ Access has been granted you should be able to access the requested resources now, please let me know if yu have any issues

This has been completed

In T304237#7797420, @Volans wrote:

In T304237#7797398, @JMeybohm wrote:

In T304237#7795994, @Volans wrote:

Thanks! I think we can now destroy the ones in the Puppet CA mentioned in T304237#7790839 at this point.

Would that be puppet cert clean <CN>?

That might work too, Spicerack uses puppet ca --disable_warnings deprecations destroy {hostname}.

either of theses should work, ping me if you need a hand.

@Sgs access has now been set up you shuld have recived an email indicating how to configure kerberos, please re-open if you are still having issues