SyntaxHighlight not working on MediaWiki 1.26+ (due to SELinux?)
Open, Stalled, Needs TriagePublic

Description

SyntaxHighlight not working on 1.26 Wiki Install.
You can see it here: http://mywiki.ergun.de/index.php?title=Test

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 6 2016, 1:31 AM

Hi @Quantumstorm, thanks for taking the time to report this!
Unfortunately this report lacks some information. If you have time and can still reproduce the problem, please add a more complete description to this report. Ideally, exact and clear steps to reproduce should allow any other person to follow these steps (without having to interpret those steps) and see the same results. Problems that others can reliably reproduce can get fixed faster.

Aklapper removed Quantumstorm as the assignee of this task.Mar 7 2016, 10:59 AM

Hi Aklapper, thanks for responding!
I've installed MediaWiki 1.26.2, PHP 5.6.18 (cgi-fcgi). MySQL 5.5.47-0+deb7u1-log and ICU 4.4.1 This includes SyntaxHighlight 2.0.
I use the <syntaxhighlight> tag, but nothing happens, exept a gray Box around the code and a "new" Category "Seiten mit Hervorhebungsfehlern" (its an German page ;) what means "Pages with Highlight-Errors".
My Page is hostet on a Service-Provider.

Hi Quantumstorm and AKlapper,
I also am seeing this exact same issue with SytanxHighlight and Mediawiki 1.26.2. I had no issues with MediaWiki 1.25.

System (running on a private intranet):
-Windows 2012 R2
-Issue appears with the latest versions of Chrome, Firefox, and IE.
-IIS 8.5
-PHP v5.6.13
-Python v2.7
-Composer v1.0
-MySQL v5.6.26

Troubleshooting and checks:
-MediaWiki shows that the extension is installed, however when used it acts like a <pre> tag was used instead of a <source> or <syntaxhighlight> tag.
-I have run update scripts against the Mediawiki DB.
-I have run composer on the syntaxhighlight directory, and have even installed pygments via pyton pip with no luck.
-I have verified that all IIS users (NETWORK SERVICE, IUSR, IIS_IUSRS) have full access to all mediawiki, php, and python folders.
-I have verified that CGI Handling for IIS is working for Python and PHP.
-I have tried manually setting '$wgPygmentizePath' in 'localsettings.php' to the pygments path in both the python path, and the syntaxhight_GeSHI extension path.
-I have tried referencing sytaxhighlight with 'wfLoadExtension' and a 'require_once' call in 'localsettings.php'.
-If I revert back to Mediawiki 1.25 and post the exact wikimarkup to a page, the extension appears to function correctly.
-I have also done extensive searches looking for possible answers, or missed configuration steps with no luck.

Hi All,

I'm also having the same issue. Brand new installation on Fedora Server 23.

Currently running:

Fedora 23 Server
MediaWiki 1.26.2
PHP 5.6.19 (apache2handler)
ICU 54.1
Composer 1.0
Apache 2.4.18

This is the third install with the same issue. Was trying to set this up at work when I originally encountered the issue and thought I'd give it a try at home. Two install later and a whole lot of time troubleshooting python, pygments, mediawiki, etc and still no closer to solving this issue. It does put the gray box around the code snippet, it also changes the font to a fixed width, however it does nothing to "colorize" the text.

Re-install to mediawiki version 1.25 also fixes the problem. Just wondering if anyone on the dev team is looking into this issue?

Hi All,

Tried and additional work-around.

Installed mediawiki 1.25 and verified that syntax highlighting was working (it was).

Then upgraded to mediawiki 1.26. The upgrade broke the highlighting and left the same result, code is in a gray box, however the highlighting of the commands, etc was all removed. So it appears that something in the mediawiki 1.26 app is broken.

Hi All (again), of interesting note: Wikipedia is running 1.27.0-wmf.17 as of March 15. I'll see if I can give that a try.

Reedy added a subscriber: Reedy.Mar 20 2016, 2:00 AM

Hi All (again), of interesting note: Wikipedia is running 1.27.0-wmf.17 as of March 15. I'll see if I can give that a try.

I suspect that won't help. Well, not suspect, I'm almost guaranteeing that won't help.

I guess the issue is related to the change to using Pygments for the backend

See https://www.mediawiki.org/wiki/Extension:SyntaxHighlight#Installation and https://www.mediawiki.org/wiki/Extension:SyntaxHighlight#Configuration

jayvdb added a subscriber: jayvdb.Mar 20 2016, 2:29 AM

Does your hosting provide Python support?

Lenrogers,
I will attemp and installtion on a clean VM using the MediaWiki trunk tomorrow, and post results.

Reedy,
I agree that it may be a configuration setting, but for the life of me I have not been able to determine what I may be missing. I have tried multiple installations on clean systems following these configuration/Installation instructions, plus extras like installing Python unfortunately with the same results.

Jayvdb,
I have Python 2.7 running correctly on my installations with still no luck. My Web-server (IIS) appears to process python scripts with no issues, yet, I still cannot seem to get SyntaxHighlight to work correctly.

Hi All,

I was under the understanding that pygments was used for version 1.25 as well (I thought that was when they made the change, although I could be wrong).

I have tried installing version 1.27 from the git master on two different vms and get the same error (Exception encountered, of type "InvalidArgumentException") when I try to load the wiki page in any browser. I have been unable to resolve the issue and the error provides no other detail as to its cause.

I have the latest version of Python from Fedora's repositories, composer is also installed. As far as I an tell, everything needed is updated, working and the configuration settings are correct from all of the documentation I have read, yet it doesn't work.

For now I'm going to be be installing and running version 1.25 as it seems to work. Version 1.27 is supposed to be rolled out in May. I will do a test update at that time, however if it continues to fail I will look for alternative solutions. Was hoping to use mediawiki for an internal knowledge base with several large code samples, but I need a working solution.

ori added a subscriber: ori.Mar 21 2016, 5:50 AM

Hi All,

I was under the understanding that pygments was used for version 1.25 as well (I thought that was when they made the change, although I could be wrong).

No, Pygments is the backend for 1.26+. Could you possibly set $wgShowExceptionDetails = true; in your LocalSettings.php and see if you can get more details with that error?

Hi ori,

I had tired that earlier and got the following message:

Exception encountered, of type "InvalidArgumentException"
[54775ed9] /wiki/index.php/Main_Page InvalidArgumentException from line 840 of /usr/share/mediawiki/includes/libs/objectcache/WANObjectCache.php: Invalid cache miss callback provided.
Backtrace:
#0 /usr/share/mediawiki/includes/libs/objectcache/WANObjectCache.php(773): WANObjectCache->doGetWithSetCallback(string, Closure, integer, array)
#1 /usr/share/mediawiki/extensions/Gadgets/includes/MediaWikiGadgetsDefinitionRepo.php(90): WANObjectCache->getWithSetCallback(string, Closure, integer, array, array)
#2 /usr/share/mediawiki/extensions/Gadgets/includes/MediaWikiGadgetsDefinitionRepo.php(22): MediaWikiGadgetsDefinitionRepo->loadGadgets()
#3 /usr/share/mediawiki/extensions/Gadgets/includes/GadgetRepo.php(33): MediaWikiGadgetsDefinitionRepo->getGadgetIds()
#4 /usr/share/mediawiki/extensions/Gadgets/GadgetHooks.php(52): GadgetRepo->getStructuredList()
#5 [internal function]: GadgetHooks::userGetDefaultOptions(array)
#6 /usr/share/mediawiki/includes/Hooks.php(195): call_user_func_array(string, array)
#7 /usr/share/mediawiki/includes/user/User.php(1540): Hooks::run(string, array)
#8 /usr/share/mediawiki/includes/user/User.php(5126): User::getDefaultOptions()
#9 /usr/share/mediawiki/includes/user/User.php(2744): User->loadOptions()
#10 /usr/share/mediawiki/includes/context/RequestContext.php(368): User->getOption(string)
#11 /usr/share/mediawiki/includes/Message.php(650): RequestContext->getLanguage()
#12 /usr/share/mediawiki/includes/context/RequestContext.php(462): Message->setContext(RequestContext)
#13 [internal function]: RequestContext->msg(string)
#14 /usr/share/mediawiki/includes/context/ContextSource.php(186): call_user_func_array(array, array)
#15 /usr/share/mediawiki/includes/OutputPage.php(973): ContextSource->msg(string)
#16 /usr/share/mediawiki/includes/page/Article.php(504): OutputPage->setPageTitle(string)
#17 /usr/share/mediawiki/includes/actions/ViewAction.php(44): Article->view()
#18 /usr/share/mediawiki/includes/MediaWiki.php(503): ViewAction->show()
#19 /usr/share/mediawiki/includes/MediaWiki.php(288): MediaWiki->performAction(Article, Title)
#20 /usr/share/mediawiki/includes/MediaWiki.php(738): MediaWiki->performRequest()
#21 /usr/share/mediawiki/includes/MediaWiki.php(519): MediaWiki->main()
#22 /usr/share/mediawiki/index.php(43): MediaWiki->run()
#23 {main}

however as I traced it out I still could not resolve the issue.

ori added subscribers: aaron, MaxSem.

Did you download the MediaWiki 1.26 version of the Gadgets extension?

Hi Legoktm,

This was a clean install from the git 1.27 master. The Gadgets extensions are there and they appear to be correct.

Can you paste the sha1's of the git commits of Gadgets and MediaWiki core that you're using? I suspect there's a version mismatch somewhere. You can run git rev-parse HEAD in the repositories to get the sha1's.

The MediaWiki core's SHA1 is:

f2a160f777cc74be64707bedbf2a63d856b34692

and the Gadgets' SHA1 is:

48ee9ed91968a52F196e177a08ab4feb751ee89d

I have figured out the error with the Gadgets, Initial copy was not successful and re-writing the files corrected the issue. (thanks to Legoktm for making re-look at that..., was way to tired when I did this last night)

I have fixed the problem and the website is now loading, however highlighting is still not working.

ori added a comment.Mar 21 2016, 4:28 PM

I have fixed the problem and the website is now loading, however highlighting is still not working.

Can you try setting $wgDevelopmentWarnings = true; as well, and then edit a page with syntax highlighting in it?

Ok, have added $wgDevelopmentWarnings = true; and edited the page.

It provided absolutely no additional information.
The only message on the screen is:

Category: Pages with syntax highlighting errors

The following is the source from the wiki test page (excluding the ====....):

<syntaxhighlight lang="python" line="1" >
def quickSort(arr):

less = []
pivotList = []
more = []
if len(arr) <= 1:
    return arr
else:
   pass

</syntaxhighlight>

<source lang="javascript" collapse="true" first-line="2" highlight="[4,6]" title="title">
SyntaxHighlighter makes your code snippets beautiful without tiring your servers.
http://alexgorbatchev.com
var setArray = function(elems) {

this.length = 0;
push.apply(this, elems);
return this;

}
</source>

<syntaxhighlight lang="python" line="1" >
def quickSort(arr):

less = []
pivotList = []
more = []
if len(arr) <= 1:
    return arr
else:
   pass

</syntaxhighlight>

The only message on the screen is:

Category: Pages with syntax highlighting errors

These code snippets were taken from the wikipedia Extension SyntaxHighlighter pages

After a bit more troubleshooting and inserting the following code into LocalSettings.php:

error_reporting( -1 );
ini_set( 'display_errors', 1);

I managed to get the following error to appear on the test code page:

Notice: Failed to invoke Pygments: sh: /usr/share/mediawiki/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize: Permission denied [Called from SyntaxHighlight_GeSHi::highlight in /usr/share/mediawiki/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php at line 296] in /usr/share/mediawiki/includes/debug/MWDebug.php on line 300

After a bit more troubleshooting and inserting the following code into LocalSettings.php:

error_reporting( -1 );
ini_set( 'display_errors', 1);

I managed to get the following error to appear on the test code page:

Notice: Failed to invoke Pygments: sh: /usr/share/mediawiki/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize: Permission denied [Called from SyntaxHighlight_GeSHi::highlight in /usr/share/mediawiki/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php at line 296] in /usr/share/mediawiki/includes/debug/MWDebug.php on line 300

What are the permissions of the file /usr/share/mediawiki/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize ? Does it have the executable bit set so that the user (apache?) running the web server (apache?) can execute it?

Looking at it the permissions are set to 755 (-rwxr-xr-x)

Also, yes. Running apache on Fedora 23 Server.

Hello All,
I have continued to troubleshoot this issue with my installation exhibiting this issue. (IIS).

I have tried a complete clean installation with the MW trunk, and still have the same issue.

After enabling debug output, I receive:

Notice: Failed to invoke Pygments: [Called from SyntaxHighlight_GeSHi::highlight in F:\websites-enabled\wiki\extensions\SyntaxHighlight_GeSHi\SyntaxHighlight_GeSHi.class.php at line 296] in F:\websites-enabled\wiki\includes\debug\MWDebug.php on line 300

This suggests that pygments cannot be loaded, however, initial tests of using pygments via command line appear to work. More to come on this...

To try to take out any permission issues, I have set all MediaWiki, PHP, and Python directory's to EVERYONE full access ( Windows permission equivalent to 777), and still receive the same error.

Hi All,

Ok, further update. The error above (recorded by myself and ZGuttenberg) is generated because of the "line=1" or "first-line=2" statements in the syntaxhighlight string. Once I remove them the error went away, and no other error was returned. However the code still did not highlight properly either.

Based on the testing I've done in the last couple of days, The operating system (Windows or any version of Linux Server that I have tried, including Fedora, Ubuntu and CentOS) doesn't matter. It also doesn't matter what web server is being used (IIS or Apache) and it also doesn't matter if it is mediawiki 1.26 or the 1.27 Master version.

Even performing a clean install of pygments onto the server and pointing LocalSettings.php to it makes no difference. It just does not work.

Not sure where to take it from here.

Has anyone else had this problem? I, like Lenrogers, have not been able to get syntaxhighlight working on any installation I have tried.
Does anyone else have any ideas?

ori added a comment.Apr 6 2016, 12:33 AM

@ZGuttenberg, @Lenrogers: is it possible that this is caused by SELinux preventing PHP from shelling out? SyntaxHighlight uses Symfony/ProcessBuilder, which in turn calls PHP's proc_open. If you search for 'proc_open permission denied', two things come up: SELinux restrictions and the safe_mode ini setting. What happens if you try the example snippet from https://symfony.com/doc/current/components/process.html#usage ?

@ori Thanks for the ideas. I am working in a Windows environment, but I went ahead and looked at my symfony setup up. It appears that it is working correctly.

I also took an example php script that uses proc_open, and that seems to be okay.

I do think that there may be a permissions issue somewhere, but I am yet to find it.

I am working on a clean VM to see if I can take all of the ideas from this thread and see if I can get it working.
As time permits I will attempt a linux install as well.

ori changed the task status from Open to Stalled.Apr 11 2016, 8:02 AM

Hi Ori,

I will perform some further SELInux testing when I get a chance. Just in the process of moving my data centre to a new location and expect it to take about two weeks before I am able to get back to it.

I have run into SELinux issues before with a Moodle install so I had done similar checks on the MediaWiki stuff. However, even if it is a SELinux issue on the Linux side of the house, it still doesn't explain the issues in the Windows installs.

My current Windows setup has the firewall, antivirus, etc., all disabled (basically I built a security disabled sandbox to do the testing) and MediaWiki and IIS are both running as SYSTEM, as are php and MySQL.

-Len-

Hi Ori,

I have completed my testing on the Linux box and verified that all parameters, and rights are correct including ownership and access of the necessary directories and files and have found them to all be exactly as they are supposed to be, That said, even with all of the security parameters correct, it does not allow the highlighting of the code. However, if I completely disable SELinux (and only when SELinux is disabled) the code hiughlighting works properly.

Throughout the testing I have allowed the apache user to have full right, the root user to have full right, etc..., changing the rights as documented in various security doics and on the forums and nothing corrected the problem until I completely disabled SELinux.

-Len-

Aklapper renamed this task from SyntaxHighlight not working on 1.26 Wiki Install to SyntaxHighlight not working on 1.26 Wiki Install (due to SELinux?).May 12 2016, 9:39 AM

Out of curiosity, I spun up two new, from scratch systems last night.

The first system was running the original software that was downloaded and installed at the end of March (somewhere around March 15-18) and retested the syntaxhighlighting. It was the exact same issue with syntaxhighlighting not working and I confirmed all of the ownership rights, etc were correct for all files and folders. Once I disabled SELinux, the syntax Highlighting worked just fine. The following is the original software versions from March:

Fedora 23 Server
MediaWiki 1.26.2
PHP 5.6.19 (apache2handler)
ICU 54.1
Composer 1.0
Apache 2.4.18

The second system was using the software downloaded yesterday and installed last night (May 11, 2016). The syntaxhighlighting is working fine in the newest install. The following is the software versions from last night's install:

Fedora 23 Server
MediaWiki 1.26.2
PHP 5.6.21 (apache2handler)
ICU 54.1
Composer 1.0
Apache 2.4.18

Basically, the only thing that changed between the two installs was the version of PHP.

Both versions of Fedora came from the same master image, and had the same updates applied. The rest of the software was installed though downloaded packages accessed through Fedora's Repositories. (I always download a copy of the packages that I install on my systems..., maybe it's just me, but...)

-Len-

Paladox added a subscriber: Paladox.EditedAug 21 2016, 12:35 PM

@ori hi after changing the pygmentize file permission from 0644 to 0755 I now get this error

[21-Aug-2016 13:44:42 Europe/London] PHP Notice: Failed to invoke Pygments: /usr/bin/python: can't find '__main__.py' in '/home/randomwi/public_html/en/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize'
[Called from SyntaxHighlight_GeSHi::highlight in /home/randomwi/public_html/en/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php at line 296] in /home/randomwi/public_html/en/includes/debug/MWDebug.php on line 309

Xennis added a subscriber: Xennis.Nov 9 2016, 11:22 PM

I had the same issue and found a solution: I upload the "pygmentize" file (in the "pygments" folder) by using "binary" as transfer type in my FTP client.

(It is not necessary to change the file permission to a higher one. I kept 740.)

Xeyownt added a subscriber: Xeyownt.Dec 1 2016, 8:29 AM

Also had the same issue. In my case however it was due to php settings that disabled shell_exec() and/or proc_open() calls.

More exactly, I had a file on my server named /etc/php5/apache2/conf.d/99_security.ini with the line:

disable_functions = shell_exec, escapeshellarg, escapeshellcmd, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate

This is something I copied from some server hardening guide. It seems that many of these functions are required for SyntaxHighlight_GeSHi to work. I just tried to clear out that line, and now GeSHi works as expected. Don't forget to restart apache server (service apache2 restart). Note that disable_functions can also be found in the php.ini file.

Also, for the record, this is what I added to LocalSettings.php to get relevant debug info. None of the suggestions above was really working for me, the one that worked best was $wgDebugLogFile:

$wgShowExceptionDetails = true;
$wgDevelopmentWarnings = true;
error_reporting( -1 );
ini_set( 'display_startup_errors', 1 );
ini_set( 'display_errors', 1 );

$wgDebugLogFile = "/var/lib/mediawiki/images/debug.log";

In the debug log, I got many occurences of messages like

[error] [90f44b94280edf183395e8c7] /wiki/index.php?title=Griffin&action=edit   ErrorException from line 300 of /usr/share/mediawiki/includes/debug/MWDebug.php: PHP Notice: MediaWiki determined that it cannot invoke Pygments. As a result, SyntaxHighlight_GeSHi will not perform any syntax highlighting. See the debug log for details: https://www.mediawiki.org/wiki/Manual:$wgDebugLogFile [Called from SyntaxHighlight_GeSHi::highlight in /usr/share/mediawiki/extensions-core/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php at line 227]
...
[error] [7e61aad3a3e092bacf3fa263] /wiki/index.php?title=Reddragon&action=edit   ErrorException from line 300 of /usr/share/mediawiki/includes/debug/MWDebug.php: PHP Notice: Failed to invoke Pygments:  [Called from SyntaxHighlight_GeSHi::highlight in /usr/share/mediawiki/extensions-core/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php at line 296]

interleaved with callstacks, but that were not very helpful. What I did instead is to grep the string MediaWiki determined that it cannot invoke Pygments, and narrow down the exception to call to function wfShellExecDisabled, and some test on proc_open, etc.

A relevant comment regarding SELinux made at extension discussion page: SELinux "fix" for pygments with MW 1.26.

Aklapper renamed this task from SyntaxHighlight not working on 1.26 Wiki Install (due to SELinux?) to SyntaxHighlight not working on MediaWiki 1.26+ (due to SELinux?).Jan 18 2017, 12:25 AM

This fixed it for me:

  • rename pygmentize to pygmentize.py
  • set the $wgPygmentizePath Variable in your LocalSettings.php.

$wgPygmentizePath = "$IP/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize.py";

I solved the problem by simply changing the SELinux label of pygmentize to mediawiki_script_exec_t.

For the benefit of less-experienced users: The label can be directly changed using the command

chcon -t mediawiki_script_exec_t /YOUR-PATH-HERE/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize

Alternately, you can add this configuration to the SELinux policy, then apply the policy to the file using the commands

semanage fcontext --add -t mediawiki_script_exec_t /YOUR-PATH-HERE/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize
restorecon /YOUR-PATH-HERE/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize

In discussing this problem, postings in other forums (currently including https://www.mediawiki.org/wiki/SELinux#Pygments_for_SyntaxHighlight itself) indicate that you should modify the SELinux label on the entire pygments/ directory recursively. Furthermore, they indicate that the desired label is httpd_sys_script_exec_t. My finding is that only the single file needs to be modified, and that their label suggestion does not work. I will propose that MediaWiki's documentation be corrected. I obtained the key information from https://bugzilla.redhat.com/show_bug.cgi?id=1301186.

For reference, my findings come from CentOS 7.3, MediaWiki 1.28.0, PHP 5.5.21 (apache2handler), and SyntaxHighlight 2.0.

I have:
Fedora release 26
MediaWiki 1.28.2
SyntaxHighlight 2.0 (2d06848)

I solve this problem with help install in my python package pymagnetize and add in config with link to pymagnetize bin

pip3 install pygments

and then add to LocalSettings.php this string

$wgPygmentizePath = "/bin/pygmentize";

Local version from extension: pygmentize -V
Pygments version 2.1, (c) 2006-2015 by Georg Brandl.

Version from pip install: /bin/pygmentize -V
Pygments version 2.2.0, (c) 2006-2017 by Georg Brandl.