@aezell done, you have been added to the wmf group. It should work now to login.

@RStallman-legalteam Thank you! @Daimona please mail Rachel, see above. thanks

service is up and disk still in warranty -> normal

added @EvanProdromou as requested on T212007

I would say T211042#4808232 covers "At least one comment of support from a Wikimedia Foundation employee" and "A comment of approval from one Wikimedia Foundation manager" provided you get the c-level approval as well. We can check these off if you ask me, but more +1s from employees never hurt of course.

Hi @Daimona I see that a couple of the check boxes here look already done on T211042 which i added as a parent task. The technical part of adding you to the LDAP group would be trivial, so it just waits for the approvals to be done. I added Rachel Stallman from Legal to that parent task because i know she handles NDAs in some other cases that may or may not be different from volunteer NDAs, so i added her to find out.

@RStallman-legalteam Are volunteer NDAs the same process we follow for example for the WMDE employees?

Thanks for confirming @Afandian ! Yea, i agree @jijiki , resolving it. Thanks! If anyone else has questions just keep commenting or click reopen.

@MarcoAurelio The patch means more specifically just that a host deployment-mwmaint01.deployment-prep.eqiad.wmflabs is receiving mediawiki deployments when/if scap is running in deployment-prep.

root@install2002:/srv# df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs   10M     0   10M   0% /dev
tmpfs          tmpfs     401M  5.4M  396M   2% /run
/dev/vda1      ext4       78G  5.2G   69G   7% /
tmpfs          tmpfs    1003M     0 1003M   0% /dev/shm
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs    1003M     0 1003M   0% /sys/fs/cgroup
tmpfs          tmpfs     1.0G     0  1.0G   0% /var/lib/nginx
/dev/vdb       ext4      118G   63G   49G  57% /srv

Lowering prio because there is space now. Not quite closed yet because we may want to do the same thing on 1001 for consistency, not sure. We are also not using the existing space on /srv there.

oh, false alert. the ticket got auto-created because the check failed.

As MarcoAurelio said, we can create a wiki for chapters. That would run on our cluster just like all the other wikis. It would be separate from the other questions though. What is the URL of your website? The link seems to be a page on Wikipedia, are there other external pages?

T137433 cc: @Ladsgroup ?

In T209618#4819650, @Stashbot wrote:

<godog> stress-test ms-be10[44-50] - T209618

T209618#4819650 shows a stress test was done on these. looks like it got too stressed

ah, thank you @Matthewrbowker We had been wondering slightly about wmbot5

It's notable here that install1002 has more space than install2002 does. (should have picked the same size at VM creation?) but also install1002 uses more space (at least the aptrepo part should be automatically synced between the 2, shouldn't it? and everything else is not synced?)

apt-get clean -> 93%

@Afandian I replaced the key and also noticed in https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/479527/1/modules/admin/data/data.yaml that there was an additional typo on our side before, see there was no "ssh-rsa" at the beginning of the key string. That was an additional problem, so it wasn't just you. I merged and ran puppet on both bast1002 and stat1007, i saw puppet replace the key. Please try again now.

@MNeisler sure, done! That was easy because you are an existing shell user so it needed no code changes or new approvals

@Afandian Could you make a new one with either "ssh-keygen -t ed25519" or "ssh-keygen -t rsa -b 4096 -o" per https://wikitech.wikimedia.org/wiki/Production_shell_access#Technical_details ?

In T209298#4821089, @Afandian wrote:

Because I created the key in a different way to those given in the instructions, I thought that the key format was causing this problem.

@Afandian Hi, i can help you with this. First of all let me confim i see in the logs on bast1002 some failed logins from you, and they all say "failed public key". On stat1007 i see no attempts in the log. So this is a key issue at the bastion server already, yes. To simplify let's first just focus on a direct login on the bastion host and make sure that works, then we can get back to stat1007.

Ok, thanks @CRoslof

In T209522#4749495, @Aklapper wrote:

and if existing a link

requested in #freenode-sigyn channel with reference to the parent ticket

nevermind, i realized i can do it myself because it trusts people with wikimedia cloak.

I made a subtask to request wm-bot to join our channel.

For part 2. of this please contact @CRoslof

deployed, puppet ran and applied many changes as expected, no puppet errors.

Hi @tramm Did you see the comment above? Can we move forward with this?

Cool, thanks for confirming :)

P.S. Since you have "IdentifiesOnly" that should mean it's not trying to use the keys provided by the ssh agent, only the IdentityFile specified in the config.

In T211115#4818109, @JoeWalsh wrote:

The command I'm using is `ssh joewalsh@stat1006.equiad.wmnet`

@JoeWalsh i see your successful login on bast1002 in the logs, along a bunch of failed attempts, but i don't see any attempts on stat1006. That tells me it should be something about your local SSH config and the ProxyCommand line. Could you paste that line from your config or ideally the entire config and also can you let me know the command(s) you are actually typing to attempt the connection? Also, do you use an SSH agent (typed "ssh-add" to load key) or did you just tell it in the config or command line which key to use?

Ah, the best kind of solution, it's already done: ) thanks @bcampbell !

role::mediawiki_maintenance includes profile::mariadb::client which uses class { 'mariadb::packages_client':

"sql" translates to "exec mwscript mysql.php" and that translates to "php /srv/mediawiki/multiversion/MWScript.php mysql.php --wiki=metawiki --wikidb=enwiki"

The "sql" command works on maintenance servers, so mwmaint1002. At first i thought it was about them and the switch from terbium -> mwmaint1002 but this is an mwdebug host so like a regular app server.

By the way, there is (or has been) also T61104 which is a private mailing list for affcom members.

Hi @egalvezwmf @bcampbell There is no affcom related mail alias or address on our ("ops") side, at least not anymore if there ever was in the past. I don't think we are needed for this. and since we are still moving mail aliases way from ops and over to OIT, can you also take this one please before we create any new ones?

not sure if out-of-scope of this ticket, but looking at the private counter part in modules/secret/secrets/ssl/ shows quite a few keys associated with calendar years in the past

Thanks @mmarble ! This is now done, you have been added to the "wmf" LDAP group and the "ldap_only" section in the admins module.