[00:55:22] I have a wiki running on wmcloud. Now it is getting spam. Is there a recipe how to set it up so it uses WSOAuth or sth like that to allow only users with a SUL to log in and edit? [00:56:38] and, maybe until then, a simpler recipe where I can say "no anonymous edits and no account creation by non-users"? [13:25:22] !log testing ceph upgrade cookbook on cloudcephmon2002-dev (T280641) [13:25:23] dcaro: Unknown project "testing" [13:25:23] T280641: ceph: Upgrade to latest Nautilus/Octopus to fix CVE-2021-20288 - https://phabricator.wikimedia.org/T280641 [13:26:55] !log admin testing ceph upgrade cookbook on cloudcephmon2002-dev (T280641) [13:26:57] xd [13:26:58] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [14:06:35] hi all, within the Wikipedia Community Health Metrics project we are computing several metrics about Wikipedia pages and discussions (e. g. number of reverts, length of chains of discussions, etc.) the idea is that we are doing some of these analyses for all languages and then some more in-depth analysis for a selection of languages. The point is that the DB with all metrics is several tens of GB. At the moment [14:06:35] Wikimedia Cloud, but it has just 16GB of storage. [14:07:33] are you on a cloud vm/vps? [14:08:33] yes [14:08:54] how could we handle this? Two options come to mind: [14:08:54] 1. have the possibility to attach a volume to the VPS with the database there [14:08:54] 2. have a machine hosted by my institution, with the data and just the frontend on the VPS [14:09:20] for attaching a volume see https://wikitech.wikimedia.org/wiki/Help:Adding_Disk_Space_to_Cloud_VPS_instances [14:10:31] would it be a problem requesting a volume of several tens of GBs? [14:12:51] all projects have 80Gb quota by default, if you need more than that requests are evaluated on a case-by-case basis, if you have a reasonable need I don't imagine there being any issues [14:18:48] Majavah: thanks for the information [14:36:06] bd808: The next time we meet up in real life, I need to buy you a beer. :-) [14:41:33] Majavah: thanks for being helpful [14:41:45] yw [14:54:09] hi -- re: bullseye and VPS images, I'd be interested in testing even before bullseye is released, is providing bullseye images now-ish sth we could explore ? [14:56:08] godog: we are about to discuss that in our team meeting in 5 minutes [14:56:26] arturo: hah! great timing, super efficient [14:56:32] :-) [14:56:38] will let you know [14:56:55] *nod* thank you [14:57:07] godog: meanwhile, a phab task wont hurt. Something like: "Cloud: evaluate early adoption of bullseye images" [14:58:12] I think we had some buster prerelease images, so this wouldn't be the first time fwiw [14:58:17] arturo: for sure -- will do [14:58:22] Majavah: true [15:01:10] tracked in T280801 [15:01:12] T280801: Cloud VPS pre-release Debian Bullseye images - https://phabricator.wikimedia.org/T280801 [16:01:13] thanks! [17:47:00] !log admin upgrading monitors and mrg nodes on codfw ceph cluster (T280641) [17:47:05] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [17:47:06] T280641: ceph: Upgrade to latest Nautilus/Octopus to fix CVE-2021-20288 - https://phabricator.wikimedia.org/T280641 [17:59:30] !log admin all monitors upgraded on codfw1 with one cookbook `cookbook --verbose -c ~/.config/spicerack/cookbook.yaml wmcs.ceph.upgrade_mons --monitor-node-fqdn cloudcephmon2002-dev.codfw.wmnet` (T280641) [17:59:34] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [17:59:34] T280641: ceph: Upgrade to latest Nautilus/Octopus to fix CVE-2021-20288 - https://phabricator.wikimedia.org/T280641 [17:59:36] * dcaro off [18:33:02] Does anyone have experience programmatically changing/querying a user database from a program in Toolforge? I'm able to manually create a database following instructions on Wikitech (https://wikitech.wikimedia.org/wiki/Help:Toolforge/Database#User_databases) but my tool program keeps getting an "Access Denied" error from mysql. I tried manually [18:33:03] changing the access permissions on my db but as a user I don't have those perms either. [18:50:49] htriedman: what database are you trying to create/access? [18:52:03] I've tried twice — the two db names are s54717__wdp and s54717__wdp_p [18:55:27] and which exact step/command is failing? did it let you create the database? and which hostname are you using to connect to mysql? [19:03:05] htriedman: in general, if you can use the defaults file of replica.my.cnf for username and password, you'll be best off. You should already have appropriate permissions to databases named like that. Ideally, your code should use the file directly. [19:03:22] That removes at least one source of error [19:03:43] But hostname will matter, as well as exactly how your code is set up. [19:05:34] Right now, it fails while connecting to the database — in the error message, it says that my username is 'tools.'@'' [19:07:03] Use the replica.my.cnf file like bstorm said as that username isn't right [19:07:14] It should be s54717 iirc [19:07:28] It's definitely the right one one way or another. [19:07:55] There are a few tools that have somehow had shared usernames. I have a ticket about that [19:08:22] T278195 [19:08:23] T278195: Sort out the 5 tool accounts with strange mysql usernames - https://phabricator.wikimedia.org/T278195 [19:08:35] But the only way you get your credentials is via that file [19:08:44] If it's wrong, please make a ticket (or ping me on that ticket) [19:09:04] In the code, though, I'm using a .env file (Golang doesn't provide support for replica files) — I've copied the username and password into that and am constructing the DSN as username:password@tcp(hostname)/dbname [19:10:09] htriedman: You can read the file in with golang and then use the values if you have to. I'm quite sure you can read an ini file in golang one way or another :) [19:10:23] Yep, can do [19:10:30] I'll give it another shot [19:10:50] That said, if you copy the username and password into code, please be careful to set the permissions to read only so it doesn't expose them [19:11:02] Ok, let us know how it goes :) [19:11:47] Sorry, readonly *to the owner* [19:12:05] They can be read write. I was mis-typing [19:12:36] I mean, if you have a password in a code file, don't expect it to be private in Toolforge. It has to be set to permissions that are only readable by the file's owner if you want that. [19:12:49] Using the file directly takes care of it :) [19:14:24] Got it — as far as programmatically accessing the database hostname, should I just assume it to be tools.db.svc.eqiad.wmflabs? [19:43:55] it worked! [19:44:00] thanks for all the help :) [19:48:33] Great! [19:48:36] Good to hear