Topic on Project:Support desk

 Hay,

ich habe folgendes Problem ich habe auf meinen Webspace von Strato Mediawiki 1.29 installiert alles ohne probleme nur wenn ich nun ein bild hochlade wird mir weder eine vorschau noch das bild angezeigt wenn ich direkt auf das bild gehe kommt nur der fehler 500 über FTP sehe ich das bild kann mir bitte jemand sagen was ich dagegen machen kann?

MediaWiki 1.29.0

PHP 7.0.21 (cgi-fcgi)

MySQL 5.6.37-log

Hay, I have the following problem I have installed on my webspace of Strato Mediawiki 1.29 everything without problems only if I now upload a picture is neither a preview nor the image displayed when I go directly to the image comes only the error 500 over FTP I see that Picture can someone please tell me what I can do about it? MediaWiki 1.29.0 PHP 7.0.21 (cgi-fcgi) MySQL 5.6.37-log

http://i.imgur.com/XInqC7g.jpg

http://i.imgur.com/ss1RFJg.jpg

http://i.imgur.com/nfoyn10.jpg

See https://www.mediawiki.org/wiki/Manual:Errors_and_symptoms#Image_Thumbnails_not_working_and.2For_appearing and https://www.mediawiki.org/wiki/Manual:How_to_debug

Okay thank you synonymous, I need ImageMagick? If so, how do I install this on my webspace because that is not a server

I have a similar problem with my strato-provider (SunOS localhost 5.10 Generic_150401-49 i86pc ) and mw1.27.4 :- php 7 on 2018.spiritwiki.de - file: test

After installation i had at first a database problem (also on a 2nd installation) which i was able to clear with

ssh : php maintenance/update.php --skip-external-dependencies

Imagemagic is on (on xampp 7.025 everythings functions)

but on both installations the images are uploadable but stay blank. If i click on the link at the upload-site of the image i get an internal server error or misconfiguration....

I added

error_reporting( -1 );

ini_set( 'display_errors', 1 );

$wgShowSQLErrors = true;

$wgDebugDumpSql  = true;

$wgShowDBErrorBacktrace = true;

$wgDebugComments = true;

at the end of localsettings but no other errors are shown -

I would now activate the debug log of MediaWiki and then I would visit an Image page, where the thumbnail is not yet present in the system.

Afterwards, the debug log will among other things contain the exact command, which MediaWiki used tocreate the thumbnail (and obviously, you already know that, this command fails). You can then examine the comman and execute manually it from the shell yourself to see the output from ImageMagick.

> If i click on the link at the upload-site of the image i get an internal server error

I don't understand what you are saying. What link are you clicking?

I see neither the thumbnail nor the image on

http://2018.spiritwiki.de/index.php?title=Datei:Greek_Eros_vase.png

added all but no real errors..(.in the footer of the site)

It is something for experts....

The reason is very simple the htacces which mw1.27 installs in the images directory :

# Protect against bug T30235

<IfModule rewrite_module>

    RewriteEngine On

    RewriteOptions inherit

    RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase]

    RewriteRule . - [forbidden]

    # Fix for bug T64289

    Options +FollowSymLinks

</IfModule>

Removal lets the images appear

i replaced it with (from mw119)

# Protect against bug 28235

<IfModule rewrite_module>

    RewriteEngine On

    RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase]

    RewriteRule . - [forbidden]

</IfModule>

...............................................

(And now still https://shorturls.redwerks.org........hopefully - because SunOS5 makes problems)

Note that a MediaWiki upgrade will break your patch again.

The only difference, which is in your .htaccess file now is that

Options +FollowSymLinks

is not set.

The RewriteOptions Inherit was another problem.

https://stackoverflow.com/questions/15868763/what-does-rewriteoptions-inherit-in-htaccess-file-do

The only question is why these problems do not come up on an installation on debian7 and php5.6 of another provider.

SunOS localhost 5.10 Generic_150401-49 i86pc has incompatibilities. A solution would be an extension with its own redirection - api.

Correct me if I'm wrong, but you are now using the same .htaccess file as delivered with MediaWiki. Only have you removed the Options +FollowSymLinks line.

Or have you also made other changes?

As You can see above i have changed both. But the

Options +FollowSymLinks is the hindering factor - also on debian 7.

The problems with the database exist not in mw1.29.2 -

but the entrys from redwerks function (on SunOS5) only with wiki/$1 and not with /$1 (500 server error)

Diese "Lösung" öffnet u.U. gleich eine ganze Reihe von Sicherheitslücken. Entschuldige, wenn ich das deutlich sage, aber: Wer keine Ahnung hat, sollte anderen lieber keine Ratschläge erteilen.

Wer motzt und sich großtut sollte bedenken, daß obiges bis mw 1.21 so gehandhabt wurde und erst dann geändert wurde - mein MW1.19 wurde innerhalb 5 Jahren nicht geknackt. Die Löung mit Options +FollowSymLinks ist jedenfalls keine Lösung. Es reicht auch ein # vor der Zeile.

Ansonsten hat Strato eine Inkompatibilität im Apache, die bei neueren Versionen von MW den Pfad mit /$1 nicht zulässt sondern nur /w/$1 zulässt.

Zur Klarstellung: Mein letzter Beitrag bezieht sich auf den direkt davor stehenden Beitrag von 87.79.122.31, den du vielleicht gar nicht gelesen hast, weil 87.79.122.31 ihn mittlerweile verborgen hat. 87.79.122.31 hat dort empfohlen, die Sicherheitsvorkehrungen aus der .htaccess-Datei komplett auszuschalten. Das ist - und daran ändert sich nichts - eine sehr schlechte Idee. Diese Vorkehrungen sind nicht ohne Grund da. Das hat mit Motzen rein gar nichts zu tun, das sind schlicht die Fakten.

MediaWiki 1.19 sowie 1.21 werden seit Jahren nicht mehr unterstützt. Diese Altversionen haben bekannte Sicherheitslücken, die nicht mehr behoben werden. Ob dein MediaWiki geknackt wurde oder nicht, wirst du dann ggf. in Zukunft irgendwann mal feststellen. Festzustellen, dass es das nicht wurde, dürfte eine ziemlicher Aufwand sein. Und selbst wenn sich das feststellen ließe, muss der Grund dafür noch lange nicht die Sicherheit deines Systems sein - es kann auch schlicht Zufall sein.

All diesen Kommentare ändern aber auch nichts daran , das Options Follow Symbolic links den Bildpfad blockiert (nicht auf Xampp - aber bei mir bei zwei Providern - einmal mit../htdocs und var/www...)

Das ist zwar evtl. ein Sicherheitsrisiko :http://www.maxi-pedia.com/followsymlinks, aber dann müsste man alle Unterverzeichnisse speziell so absichern.

Solange der Webserver die Bilder ausliefert genügt auch ein 644 auf Dateien und Verzeichnisse (das Strato mir oft einfach auf mein 755 korrigiert - auch bei NICHT-MW-Installationen - wohl der Sicherheitsschild).

(NUR) Wer eine bessere Lösung hat möge sich melden....

In einer Standard-Installation gibt es keine Symlinks innerhalb des Ordners images/. Ob Apache jetzt angewiesen wird, in diesem Ordner Symlinks zu folgen oder ob nicht, macht dann gar keinen Unterschied. Es ist aber trotzdem so, dass du, wenn du die .htaccess-Datei veränderst, du bei jedem Update daran denken musst, dass du diese Änderung ja wieder einpflegen musst. Mir wäre das zu nervig.

Ich habe ein vergleichbares Problem, allerdings mit der aktuelleren MediaWiki version. Auch der hier beschriebene Workaround scheint nicht zu funktionieren. Die htaccess enthält allerdings nur folgenden Code:

<IfModule rewrite_module>

   RewriteEngine On

   RewriteOptions inherit

   # Fix for bug T64289

   # Options +FollowSymLinks

</IfModule>

das Auskommentieren der Optionszeile war ich; Leider hat das auch nicht viel gebracht. Ich sitze damit auch auf einem Strato Server.