User Details
- User Since
- Oct 7 2014, 2:00 AM (478 w, 5 d)
- Availability
- Available
- LDAP User
- Tim Landscheidt
- MediaWiki User
- Tim.landscheidt [ Global Accounts ]
Aug 17 2019
Sep 21 2018
Jun 11 2018
Mar 23 2018
May 4 2017
Mar 1 2017
(As @tstarling already assessed in T37043#399694, this is not exploitable.)
If apache2 ist blacklisted, who will inform Cloud-Services/Toolforge administrators of the need to manually update apache2?
(… or anyone else can do that.)
I'm pretty sure the patches work except that I can't get them to work on toolsbeta-puppetmaster7 due to some PostgreSQL hiccups (our puppetry for that is far too fragile for my taste). I'll set up a new puppetmaster and test that tomorrow.
(CCing @mmodell because of 5baa9cedd427110ab84b2cb4e0b24f65cbfa6986.)
@gerritbot does not seem to want to add https://gerrit.wikimedia.org/r/#/c/230477/ to this task; hmmm. Anyway, that patch only handles the part of the grid master configuration dealt with by qconf -sconf, not the whole configuration of tools-grid-master that forms the scope of this task.
(My changes https://gerrit.wikimedia.org/r/#/c/237871 and https://gerrit.wikimedia.org/r/#/c/148917/ would make this possible.)
Feb 28 2017
(The connection refusal is probably T159254 and could be fixed by sudo apt-get install apache2.)
(FTR: To fix other instances with this problem (= every host with apache2 running), apt-get install apache2 is enough.)
(Unassigning because I don't understand the failure mode, or rather, if my understanding had been correct, the bug had been fixed. Perhaps a fresh pair of eyes is helpful.)
I think that is close enough to a verification. 2FA should not interfere with the passwords themselves. Thanks for testing.
I removed the now-obsolete files under /usr/local/bin and tested successfully /usr/bin/jmail with echo Test 15 | mail -s Test tools.scfc-test-can-be-deleted-anytime (as seen above, no existing ~/.forward referred to /usr/local/bin/jmail by its absolute path).
(There does not seem to be anyone planning to work on this.)
I did not rebase this change in the past year, so unassigning. This isn't rocket science, but requires a thorough understanding of the current MediaWiki-Vagrant Puppet structure and its interactions.
I did not rebase this change in the past year, so unassigning. This isn't rocket science, but requires a thorough understanding of the current MediaWiki-Vagrant Puppet structure and its interactions.
My understanding here was flawed: I assumed that the same Lua modules for for example Redis could be used for Resty as for the usual applications. But Resty needs special coroutine stuff that does not block. So there isn't that much cruft to clean up.
I still think this is worthwhile to pursue, but it's too "complicated" for my liking in the existing setup. Ideally (IMVHO), /etc/apt wouldn't be set up by copying the VM builder's directory, but with a more declarative approach in vmbuilder.cfg.erb that ensures that the repositories are ready to use at boot. You can achieve some of the same effect with a Puppet exec that changes /etc/apt/sources.list if necessary, but that only adds to a pile of interacting systems that are hard to understand and "race conditions" (> 30 minutes :-)) for the sources for packages that are hard to debug.
@chasemp: Thanks for the explanation. Running maintain-dbusers for several projects in parallel would indeed be problematic for user accounts.
Feb 27 2017
IMHO yes: Words are ambiguous and sometimes hard to parse, "+1"s are "binary".
@mmodell: When you review code, you can do so informally: "Yeah, looks alright, bro." +1/+2 are formalized statements, and just like formalized statements in other spheres, they have more weight: "I'm so confident that this change should be merged that I ticked this box." So you incur more cost (effort to test a change thoroughly and risk of loss of reputation), and that cost must be limited and offset by an incentive, in the case of code review usually the mutuality and the ability to search for open/ready-to-merge/need-work changes. An important factor there, like in other spheres, is that the form you signed can't be changed after the fact. If the form is not immutable, there is no incentive to sign it, so you end up (at most) with informal communication that can't be searched, queried, categorized, etc.
(Cf. also https://gerrit.wikimedia.org/r/#/c/339832/ for reducing the size of the page :-).)
The domain resolves for me now:
Building the packages, adding them to aptly and deploying them went without problems.
I also had to remove prometheus-blackbox-exporter from precise-tools and trusty-tools (but not from jessie-tools). This package is only used on tools-prometheus-01.tools.eqiad.wmflabs and tools-prometheus-02.tools.eqiad.wmflabs (both Jessie).
I have "documented" the two branches master and ubuntu/precise at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Admin#Deploy_new_jobutils_package and will now test if aptly accepts the new packages (otherwise this would have been … :-)).
Feb 26 2017
The check was introduced by @Platonides in 24fb4ecdb03b053c891d89b7ba6104753a9c1366. @Platonides: It looks like there was no deeper rationale behind the restriction on ssh-rsa/ssh-dss except that those were the keys in use at that time?
I have put the rewrite at /usr/local/bin/jmail.new and set a symbolic link from /usr/local/bin/jmail. I ran several tests and I'm confident that the patch works.
… and Jenkins works on that branch without fail. Wonderful.
I created the branch ubuntu/precise for labs/toollabs with ssh -p 29418 scfc@gerrit.wikimedia.org gerrit create-branch labs/toollabs ubuntu/precise master. The access configuration is the same for all refs/*, so this should apply to ubuntu/precise as well.
Feb 25 2017
I documented the status quo (per my knowledge) at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Admin#What_makes_a_root.
Is this a reincarnation of T70100?
Okay, that's now twice in a row that I can't see properly:
Feb 24 2017
I think renaming the shell account name should be enough; deleting should not be necessary.
I updated the package on all Toolforge instances. Note to self: apt-get install --only-upgrade $package is bad because it can leave the instance with an unconfigured package if the configuration files have changed; clushing is very bad because that leaves 16 instances that way. Try it on one host first, then come up with clush -b -g all 'sudo apt-get install --only-upgrade -o Dpkg::Options::="--force-confold" --force-yes -y prometheus-node-exporter' and be happy.
… and backed up the new directory with sudo rsync --chmod 440 --chown root:"${INSTANCEPROJECT}".admin -ilrt /srv/packages/ /data/project/.system/aptly/"$(hostname -f)".
Removed the packages from aptly and moved the files to ~tools.admin/archived-packages/: