[00:00:03] moonmoon: I am. [00:02:33] if it still happens on 8.3, giving the full error message would likely help. those messages often include a filename and line number which is critical in knowing what is going on [00:05:22] No such luck in this case. That's the full error message. I see nothing in the php-fpm logs either. [00:14:03] moonmoon: Where does that info come from? I don't see any real difference in compatibility between PHP 8.3 and PHP 8.4 [02:53:32] andre: https://www.mediawiki.org/wiki/Compatibility#PHP plus a handful of deprecation notice tasks on phabricator for 8.4 [02:57:58] https://phabricator.wikimedia.org/tag/php_8.4_support/ [02:58:39] most seem to be logspam but T376711 is an actual issue (albeit limited in scope) [02:58:40] T376711: PHP 8.4: NumberFormatter will now throw for invalid locale - https://phabricator.wikimedia.org/T376711 [15:25:15] Hi first time here on mediawiki. I am doing a simple script for backing up mediawiki. It's a docker compose depolyment with sqlite so it should be a easy one. [15:26:27] also I am backing up all the filesystem elemnts of mediawiki. [15:27:49] I want to have a xml dump to. since I already have the database+filesystem backup should i use "dumpBackup.php --full with or without --include-files"? [15:27:59] how would the restore process differ [16:16:04] I don't even know if include-files works in dumps anymore. I would reccomend not using it [16:16:51] recyclehero: Generally a DB backup should have everything an XML backup has and more. XML backups are mostly used when you want to backup wiki content without any private info so you can publish the backups [16:28:34] Installed php 8.3.16. I get the same error. [16:29:59] I execute line 330 of includes/installer/WebInstaller.php, which is a call to session_start() with options. But I never get to the next line. And, the catch block at the next line never gets executed either. [16:36:41] It seems the error handler there does not report file or line number.... [16:38:17] Is there a way I can configure/setup without using the web-based setup? [16:38:40] And, I take it back, the catch block is executed. (My monkeypatching was bad.) [16:40:11] I can always comment out the option setting, configure, save the config and put the original source back. I suppose. [16:41:34] it’s possible to install from the command line using the maintenance/install.php script but I don’t think that’s recommended for most users [16:41:42] if you can get the web installer to work that’s probably better [16:43:23] I can hack it. Unclear about filing a bug report. The only thing I can think of that I did was "php_admin_value[session.cookie_secure] = on" in my php-fpm config. You wouldn't think that would be a problem -- so I don't know the cause or how to reproduce. [16:44:44] I believe I wrote some test code yesterday that tried starting a session with cookie_secure turned on, and it worked. So what's causing the issue? [16:46:33] FWIW, includes/Setup.php line 526 (session_start()) is called twice. But so what? [16:52:34] Meanwhile, how do I support a not-too-serious security issue? Only a problem at installation. [16:52:45] s/support/report/ [16:53:21] !bug [16:53:21] https://phabricator.wikimedia.org [16:53:32] Thanks. [16:53:54] specifically https://phabricator.wikimedia.org/maniphest/task/edit/form/75/ for security issues [16:56:12] (Humm. "Log In or Register\nMediaWiki" is greyed out. Sending an email...) [16:58:40] karlpinc: its greyed out? That's weird [16:59:01] hmm, its not greyed out for me, but maybe different browser or IP or something [16:59:20] WFM in private browsing too [17:02:17] I've never been to the phabricator before, so that could be it. [17:03:21] (I'm greylisting, so hopefully you send via an MTA that retries.) [17:07:34] (yup) [17:09:04] https://phabricator.wikimedia.org/auth/start/?next=%2F should allow you to start the signup (an account a mediawiki.org) [17:09:36] I think it greys out when not logged in to "Wikimedia", and you have no account. Just a guess. [17:24:25] Reported. Thanks. [17:25:50] Do I get an email when "something happens"? [17:25:59] regards the bug [17:27:18] karlpinc: you should – did you get an email just now? (I added a project to it that I think is related) [17:27:36] Yes. Thanks. [17:27:56] * Lucas_WMDE leaves the rest of the issue to more knowledgeable people 😌 [17:37:51] The web installer says "GNU diff3 text comparison utility not found. ..." But diff3 is there at the command line. Do I need to install php-pecl-xdiff? (It's unclear if that package uses diff3.) [17:38:30] It also says git is not installed, and it is. [17:38:57] (It is all feeling very SELinux-y.) [17:40:05] You might be right on that ;) [17:41:01] no. you may get that message if MW is unable to call out to shell commands, otherwise you can ignore it and manually configure the path to diff3 afterwards [17:41:01] (or you may get it if diff3 is on a nonstandard path) [17:55:25] Why would it be unable to call out to shell? Unless it's a SELinux thing, which will do that. The paths are stock. What should I look at? (I've not even checked the logs.) [17:57:08] sorry, ran into some network wobbles [17:58:20] karlpinc: if proc_open is in the php.ini disable_functions, PHP isn't allowed to use shell commands [17:58:42] (there's a handful of other ones, but proc_open is the one MW uses) [17:58:57] Ah. Ok. I'll look there. [17:59:11] I see nothing in the logs. [18:00:14] passthru, shell_exec, popen, and system are the others. I might've missed one or two, but in any case if you have anything in disable_functions probably expect certain things to break [18:02:21] if disable_functions looks good (and make sure you're looking in the correct php.ini; php run over cli and php-fpm likely have *different* ini files), then next thing to check is to run diff3 --version yourself and make sure it actually gives output [18:02:46] if php-fpm is being run in a chroot or mount namespace, that could also be a reason it cannot find the files [18:04:12] I grepped for disable_functions in all the php config files I can find and only see it in /etc/php.ini where it is set to nothing. [18:04:47] diff3 (GNU diffutils) 3.6 [18:05:14] and it's in like /usr/bin/diff3? [18:05:35] I don't see why it wouldn't be selinux. (That's my bane. Why would it allow shell execution from /var/www/html/* by default?) [18:05:50] could very well be selinux [18:05:51] Humm. /bin/diff3. [18:06:00] /bin/diff3 is fine too [18:06:27] (MW looks in /usr/bin, /bin, /usr/local/bin, and a handful of other more niche places) [18:06:33] I'm not going to worry about it just now. [18:09:57] *nods* at this point there's only two culprits remaining: selinux and a chroot/container-like setup [18:11:52] Yah. No chrooting or containers involved. [22:02:47] The web installer provides instructions that are unsafe if followed. Do I report this as a security problem or just a regular bug? [22:03:27] If in doubt, file it as a security bug [22:20:42] (Kind of a shame I can't respond to a email from a bug and have the response recorded in the bug.) [22:38:20] Is it a bug when on error the software tells you the problem is one thing (and how to fix it) but when the problem can really be something else? Should I file a feature request for additional verbage or a bug report? (web installer issue) [22:40:41] (It is sort of exciting seeing how many bug reports are filed, and how quickly. Does the number ever go down? Just curious, no need to reply.) [22:52:21] Looks like there's already a bug. Problem solved. :) [23:03:36] T248809 [23:03:37] T248809: review i18n message config-sqlite-parent-unwritable-group in installer - https://phabricator.wikimedia.org/T248809 [23:44:12] I thought email responses to phab are supposed to work... [23:45:19] https://www.mediawiki.org/wiki/Phabricator/Help#Using_email [23:50:06] Reedy: I sent one just about as soon as you made your first comment. But it never showed. So I went to look at a old tarball and used the web interface. [23:50:29] (Anyway, I don't really care at the moment.) [23:55:25] Fighting with SELinux. I hope https://www.mediawiki.org/wiki/SELinux is up-to-date. audit2allow --why is telling me that "The boolean httpd_unified was set incorrectly." and to "setsebool -P httpd_unified 1". (The installer can't create the sqlite files.) [23:56:17] This probably affects uploads too. Anyway, before I do anything I have to understand what I'm doing and it's been too long away from SELinux. [23:57:01] (https://www.mediawiki.org/wiki/SELinux says nothing about "unifying".)