[00:00:35] On version 1.34.0 [00:01:05] PHP 7.2.20 [00:01:35] ConfirmEdit and FancyCaptcha are both listed in Versions page under installed extensions [00:02:54] Yes [00:03:18] Fancycaptcha needs a python script to generate the captchas be run [00:03:50] If your goal is to use recaptcha than you need to set that instead of fancy captcha [00:03:58] bawolff - I also tried Google Recaptcha [00:04:11] same issue [00:04:13] Also, you probably need to adjust the captcha triggers [00:04:14] nothing showing [00:04:24] Im not sure what defaults are [00:04:24] aaah - where would I do that - adjust triggers? [00:04:58] got it - found it in teh documentation - thanks :) [15:41:06] Hey all, is anyone using saltstack to manager their mediawiki instances? I do to a degree but I'm hitting a snag regarding an upgrade I'm working on going from MW 1.30 to 1.34, but with regards to Semantic MediaWiki and upgrading it from 2.5 to 3.1. [15:43:38] is it somehow related to salt or just a general issue? [15:44:11] It has to do with the new SMW setup information file, .smw.json. [15:44:33] I'm just trying to figure out how to approach it since my environments and workflows complicate matters a bit. [15:45:04] I have two envs, dev and live, in which I manage 7 wikis load balanced across 4 web servers in each environment. [15:46:26] I'm working on getting a new copy of the dev environment set up (everything in AWS now, btw) so I can test the upgrade process for MW 1.30 to 1.34 and SMW 2.5 to 3.1 without affecting the existing dev env, just in case. However, upgrading SMW now updates a per-wiki .smw.json file (4 of my 7 wikis use SMW) [15:48:32] When updating SMW, the setup.php script will update the json file with a new key based on the updated database schema, which I'd then just use to update in a salt pillar and then use that to create updated json files for the live wikis once the setup.php is done during the update of those on my actual live upgrade/cutover day. [15:49:10] Just wanted to see if anyone else encountered this SMW change and how they are handling it, especially when dealing with dev vs prod environments and multiple load-balanced wikis. [15:50:19] Sorry for so much text, it's a complex setup and workflow I have in order to be able to manage production internet-facing business critical wikis. [16:11:49] Does anyone here manage any reasonably large production load-balanced wikis (ideally cloud-based and/or managed via tools like salt, chef, puppet)? I moved ours from an on-prem datacenter to AWS over a year ago, and now I'm upgrading there for the first time. Just looking for people who may have similar experiences to chat with. [16:34:07] justinl: the strategy you outlined above seems like it'd work, did you run into troubles with it? [16:35:00] (I don't have personal experience maintaining large load-balanced wikis, but I'm pretty familiar with good practices for updating mw in general and a lot of the advice extends just fine to large wikis) [16:36:31] I haven't yet implemented it as I've been thinking about it along with the rest of the upgrade procedure. I have extensive pillars in salt for managing both the apache, mediawiki, and aws stuff, so I just need to figure out how best to incorporate this SMW change into that workflow. Just wanted to see if anyone else had run into this, always nice [16:36:32] to be able to learn from others since I've generally had to develop my entire environment and processes in a vacuum. [16:37:32] well if the key is deterministic you could possibly just pre-create the relevant json file and push it out along with the rest of the updated files [16:37:51] may interfere with the smw update process though [16:37:56] I've updated our wikis many times over the years, starting at 1.16 about 8 years ago, constantly improving, refining, simplifying, and streamlining the procedures and workflows. [16:38:56] It does seem to be deterministic, as it's based on the database schema and SMW version, according to the actual php code, so I just have to do the dev upgrade, get the new key, update it in pillar and then it will work there and when I push it out to live during that upgrade. [16:41:50] Right about the SMW update process, so I just have to carefully plan the upgrade procedure. It's multipart, involving gitlab, a salt master of masters and multiple syndics, a build script for creating all of the new mediawiki apache documentroot directories (1 per wiki) and a deploy script to push all of that out to the web servers, salt again to [16:41:50] update the web servers, etc. So many parts that it requires much thought and care. [16:43:24] One of the most annoying parts is the need for NFS (S3 isn't feasible for us) to host the 3.1 million files (source images and all of the thumbnails MW generates) that need to be shared by all of the load-balanced web servers. NFS (AWS EFS now) creates its own pain points, too. [18:19:57] @Anomie Hi, are you around? I have a question about logging in to API [18:21:28] (or anyone from API team) [18:21:48] !ask | Dvorapa [18:21:48] Dvorapa: Please feel free to ask your question: if anybody who knows the answer is around, they will surely reply. Don't ask for help or for attention before actually asking your question, that's just a waste of time – both yours and everybody else's. :) [18:23:15] Dvorapa: What's the question? Have you read through https://www.mediawiki.org/wiki/API:Login? [18:24:48] Well I need someone, who would explain me in detail, what are the current ways to login through API, because Pywikibot login seems to be completely broken right now [18:25:30] Feel free to describe the brokenness. [18:25:44] Preferably by code and by what you get back. [18:26:11] use https connections, make sure you've set up a bot password [18:26:18] Dvorapa: That link should answer the question. TL;DR: OAuth, BotPasswords with action=login, interactive with action=clientlogin, and deprecated non-BotPasswords login with action=login. [18:26:32] First we still use action=login with password. No botpasswords, no OAuth [18:27:29] Second Pywikibot seems to somehow refuse to login as we get this: [18:27:30] WARNING: No user is logged in on site wikipedia:enskipped 'TestUserWatchedPages: Not able to login to wikipedia:en' [18:27:37] ok let's put it this way, what are you trying to log in to [18:27:54] enwiki [18:28:00] (for start) [18:28:41] Pywikibot login scripts and method work partially and not really how they should [18:29:01] site.logged_in() returns True or False pretty much randomly) [18:29:20] (not randomly, but incorrectly) [18:29:34] botpasswords work partially [18:29:46] OAuth seems not working [18:30:46] And so many times Pywikibot stucks on the following loop: [18:30:48] ERROR: Logged in as '34.74.253.255' instead of 'Pywikibot-test'.Forcing re-login. [18:31:16] So I decided to rewrite Pywikibot login implementation to support all current options and handle login correctly [18:31:27] (not rewrite, but check and fix at least) [18:32:05] But first I need to familiarize myself with API methods to login [18:33:13] I'll read that page and return back with questions, thank you [18:38:50] Pywikibot has supported OAuth for a long time [18:39:16] Then it has some issues too [18:39:21] https://www.mediawiki.org/wiki/Manual:Pywikibot/OAuth [18:40:04] bot passwords too (or rather, you don't really need specific support for bot passwords): https://www.mediawiki.org/wiki/Manual:Pywikibot/BotPasswords [18:41:11] "normal" login is expected to be fragile, it's deprecated and cannot handle any non-standard login flow like 2FA or forced password change [18:42:18] Bot Passwords is more like an account alias with a different password - you just set that up beforehand and then use that generated info for the login [18:42:31] Yeah, that's what we use and what's breaking Pywikibot tests all over the place [18:42:40] (normal login) [18:43:37] Mainly botpasswords and oauth have issues with implementation to use in Pywikibot tests, while basic password login fails all over tests [18:43:53] All of them need some major fixes [18:44:12] mwapi has an example of interactive login: https://github.com/mediawiki-utilities/python-mwapi/blob/master/mwapi/cli.py#L16 [18:44:40] are you trying to use http logins instead of https? [18:44:53] if you are, don't [18:45:00] I don't think so [22:05:28] Nikerabbit: Let me know when you have the task [23:31:39] how to reset admin password directly in mysql database ? [23:32:06] why not use the php changePassword script? [23:32:11] # php ./changePassword.php –-user=Teraii –-password=mypassword [23:32:11] Param password required! [23:32:20] because it's not working [23:32:23] :) [23:32:48] ho [23:32:59] pasting here showed my why :p [23:33:13] yes, it's the dash [23:34:11] hum [23:34:14] Password set for Teraii [23:34:24] but the password is not working :/ [23:34:57] set it to something simple for a test, e.g. "test2020" [23:35:15] make sure the correct locale is selected [23:35:47] i don't use any special char [23:35:57] php ./changePassword.php --user=Teraii --password=touchmytralala69 [23:35:57] Password set for Teraii [23:36:15] but the login page relocate me in Accueil [23:36:28] (or the session pirate blah ....) [23:36:30] see https://www.mediawiki.org/wiki/Manual:Resetting_passwords#Direct_database_modification if you just want a quick change [23:37:00] i have allready tested the sql command [23:37:03] :/ [23:37:08] what did it say? [23:38:04] 1 line processed [23:38:49] maybe you are doing this for the wrong wiki? [23:39:01] i.e. on shell it is one wiki, but in your web browser it is another wiki [23:39:11] there is only one wiki [23:39:37] gry: that direct modification link is outdated [23:39:59] hi Skizzerz, do I mark it as "this is outdated" in that section? where do I point it to? [23:40:00] i even don't know why the original password stopped allowing access [23:40:01] Should probably nuke it [23:40:03] well, I suppose the B format still *works* despite being deprecated [23:40:23] ha [23:40:28] :) [23:41:36] so this is a fresh install, perhaps i must redo [23:42:13] Teraii: what is the error when you try logging in with that password [23:42:25] (after using changePassword.php) [23:42:30] Skizzerz, French : Votre session de connexion semble avoir des problèmes ; cette action a été annulée en prévention d'un piratage de session. Veuillez soumettre le formulaire de nouveau. [23:42:57] your problem isn't the password [23:43:08] ha [23:43:23] make sure that 1) cookies are enabled in your browser, and if they are, 2) that whatever session storage mediawiki is using actually works [23:43:32] ok [23:44:16] (for the 2nd point, look for any definitions of $wgMainCacheType in your LocalSettings.php) [23:44:53] ok [23:46:18] there's some further information at https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems but it may be a bit hard to follow [23:46:28] $wgMainCacheType = CACHE_ACCEL; [23:46:39] ok [23:46:52] is your site public? [23:47:05] https://www.nartium.net/wk/ [23:47:17] i have switch in english [23:47:26] can you create a file called info.php with the following contents: [23:47:34] ok [23:47:37] and put it at the same folder where the wiki's index.php is? [23:47:42] (this is temporary, I'll ask you to delete it shortly) [23:47:44] ok [23:49:29] done [23:49:45] that file will show the server's PHP configuration. There is generally nothing sensitive listed there, but I'm interested in how your caching is set up there [23:49:53] i know [23:50:17] i'm the server admin [23:50:40] wasn't sure, thanks :) [23:50:44] ;) [23:51:05] people of all sorts come here for help so I didn't want to assume any level of knowledge or expertise [23:51:31] i understand VERY well :) [23:51:43] (even if my english is bad you see :p) [23:51:47] Teraii: anyway, your apcu config looks fine. My initial guess was that your PHP process is being created fresh each time a web request happens [23:52:13] which would mean that an in-memory cache like apcu (which is what CACHE_ACCEL uses behind the scenes) would get destroyed each time the process dies [23:52:28] ho [23:52:42] * Teraii didn't know that [23:53:06] mediawiki uses that cache to store session state, so if it gets cleared out then it can't find things like the CSRF token you should have, and it'll reject the login [23:53:11] but after the fresh install it seem works [23:53:29] the phpmyadmin is not affected ? [23:53:42] i'm using the php session [23:53:52] phpmyadmin likely uses built-in php session management which stores the session state in /tmp [23:54:30] if you want to keep using $wgMainCacheType = CACHE_ACCEL then you'll want to look into how php is being executed. If it is indeed one process per request you'll either need to change that or change $wgMainCacheType [23:54:34] in a shared nfs dir ibn my case (because this is a cluster) [23:54:35] (the default is CACHE_ANYHING) [23:54:39] ibn/in [23:54:40] er, CACHE_ANYTHING [23:56:00] changed [23:56:03] if you have a cluster of webservers, you can also spin up a memcached server and then use $wgMainCacheType = CACHE_MEMCACHED, and add $wgMemCachedServers = [ ':' ]; [23:56:16] yes it's working [23:56:18] that's generally recommended for such setups [23:56:26] logged \o/ [23:56:37] ok [23:56:57] i'm allready using memcached for postfix :) [23:57:05] you'll likely see some performance improvements if you do that, and it enables using rate limiting features in mediawiki as well [23:57:14] ok [23:57:34] more info on configuring that is at https://www.mediawiki.org/wiki/Manual:$wgMemCachedServers [23:59:09] anyway, glad everything is working :) [23:59:26] yea thank you :)