Beiträge von crazy-to-bike

Zitat von Re:Later

Geh mal nach Komponenten > Aufgaben. Schaue, ob vor der Aufgabe ein rennendes Männchen ist. Wenn ja, klicke es, damit es verschwindet.

Hatte ich mehrfach. Schon unter Joomla 5.

In der Tat. Das war's wohl. Vielen Dank.

Seit ich meine Joomla-Instanzen von Jooma 5.4.x auf Joomla 6 geupdated habe, erhalte ich bei keiner Instanz mehr eine Benachrichtigung per Mail, wenn es ein Update gibt. Im Dashboard wird ein vorhandenes Update angezeigt.
Der Mailversand funktioniert weiterhin. Die Test-Mail zur Überprüfung der Mail-Konfiguration (hier per SMTPs) unter System - Konfiguration - Server kommt umgehend an.
Das Plugin "Aufgabe – Joomla-Update-Mitteilung" ist aktiviert. Ich habe es schon deaktiviert und neu aktiviert.

Woran kann das liegen und wie kann ich das debuggen?

Zitat von SniperSister

Das gleiche Problem hast du auch bei einer Platzierung des Backups außerhalb des Webroots: wenn Akeeba drauf zugreifen kann, kann's ein Angreifer der Joomla und somit Akeeba kontrolliert, auch.

Stimmt. Wenn man darüber nachdenkt, ist das logisch.
Aber warum wird dann immer empfohlen, das Backupverzeichnis außerhalb des Joomla-Web-Root zu legen?

Am Besten also die Backups durch einen Cronjob mit cp wegkopieren und von Zeit zu Zeit alte Backups löschen. rsync würde das zwar mit der Löschung der alten Backups durch Akeeba "automatisieren", aber im Falle des Falles das Zielverzeichnis leer syncen.

Auf der obersen Verzeichnisebene, die ich auf dem Webspace erreichen kann (auf die serverseitige root-Verzeichnisebene kommt man ja nicht), habe ich - wie beim alten Hoster schon - eiinen Ordner www erstelt, darin Unterordner für mehrere verschiedene Installationen. Also

[nicht erreichbare Verzeichnisebenen]/www/joomla1
[nicht erreichbare Verzeichnisebenen]/www/joomla2
[nicht erreichbare Verzeichnisebenen]/www/wasauchimmer

Ich kann in Akeeba Backup keinen Pfad über Joomla1 bzw. Joomla2 angeben. Beim alten Hoster ging das problemlos.

Ok, mal getestet: Das Backupverzeichnis wird beim Backup ausgeschlossen. Das ist schon mal gut. Sinnvoll ist das Backupverzeichnis innerhalb des Joomla-Verzeichnisses aber definitiv nicht.

Danke für die Infos.
Für so "aus Interesse" Projekte feht mir derzeit leider die Zeit. Ich muss auch noch meinen VPS auf den neuen root-Server umziehen.

Hallo,

ich bin mit meinen Joomla-Webseiten zu Netcup umgezogen. Beim alten Hoster hatte ich das Backupverzeichnis für die Akeeba Backups eine Verzeichnisebene höher als das Joomla-Dokumentenroot angegeben. Das geht bei Netcup (bslang) nicht. Ich komme, egal ob ich den absoluten Pfad manuell eingebe, oder den Directory Browser hinter dem Eingabfeld nutze, nicht in eine höhere Verzeichnisebene als das root-Verzeichnis von Joomla.

Wenn ich im Directory Browser "Up one level" klicke, kommt "The specified directory doesn't exist!". Wenn ich den Pfad manuell eintrage und ein Backup starte "The automatic backup can not be started because your output directory is not writable".

Die Backups innerhalb der Joomla Installation anzulegen, ist ja aber aus mehreren Gründen käse:

1. sind die Backups bei einer Kompromittierung von Joomla ebenfalls betroffen
2. wächst die Backupgröße exponentiell, da ja mit dem Dateibackup immer auch die vorhandenen Backups ins Backup gepackt werden

(Wie) kann ich erreichen, dass ich wieder ein Backupverzeichnis oberhalb des Dokumentenroot von Joomla angeben kann?

Sorry, das Einspielen hat erst vorhin geklappt und ich kam noch nicht dazu, hier zu schreiben.

Ja, die Webseite läuft inzwischen, aber ohne den Weg über Akeeba. Einfach den gesamten Joomla.-Ordner mit tar.gz gepackt, die Datenbank gedumpt, beides per scp auf den neuen Webspace kopieret, entpackt und Datenbankdump in die Datenbank einsgespielt.

Eine index.html war aufrufbar, neueste kickstart.php von der Akeeba Seite der Error 500, außer kickstart.php und jpa war nichts im Dokumentenroot. War absolut nichts zu machen, Auch nicht durch andere Dateirechte, andere PHP Version etc.

Allerdings habe ich bei beiden Webseiten noch ein Problem mit dem Backupverzeichnis für Akeeba Backup. Dazu mache ich gleich einen neuen Thread.

index.pho war ein Tippfehler.
Da das bei der anderen Joomla Webseite funktioniert hat, sind die Webserveranforderungen grundsätzlich erfüllt. Leider ist es odeutlich verzwickter bzw. weniger offensichtlich.

Hallo,

ich versuche, eine Joomla Installation mit Akeeeba kickstart.php (frisch von der Akeeba-Webseite gezogen) auf einem neuen Webspace wiederherzustellen. kickstart.php und die Backupdatei name.jpa aus dem Akeeba Backup sind im Dokumenten-Root-Verzeichnis.
Der Aufruf von https://www.meineseite.de/kickstart.php bringt einen Error 500

Lege ich eine index.php ins Verzeichnis, wird diese angezeigt.

Sowohl index.pho als auch kickstart.php haben 644 als Rechte. Es läuft PHP 8.3 (wie auf dem alten Webspace).

Any ideas?

Loglevel bzw. Errorreporting habe ich zurückgesetzt. Das andere mache ich im neuen Thread.

Oh Gott, ja... wenn man nur alle 10 Jahre mal so einen Umzug macht...
Pfad in der .htaccess in /administrator korriiert, und schon geht das Backend.

Die nicht gefundenen Seiten im Frontend sind auch weg, nachdem ich die .htaccess und configuration.php wieder aus der wiederhergestellten Joomlainstallation hin kopiert habe.

Vielen Dank für die Hilfe. Meine eigene Webseite läuft jetzt wieder.

Das einzige, was ich hier noch immer nicht verstehe: Warum ging das Frontend auch nicht richtig, so lange der Pfad für den Verzeichnisschutz in der .htacccess in /administrator falsch war?

Und was ich auch nicht verstehe: Warum kann ich kickstart.php bei der Webseite meiner Frau gar nicht aufrufen (wieder Error 500)? Irgendwas muss ich da noch übersehen...

Ok, das Frontend geht auch nur teilweise. Manche Links funktionieren, andere nicht (Seite nicht gefunden). Das passiert wohl bei Links, die in einem Beitrag sind und auf eine andere interne seite (relativ) verweisen. Jedenfalls waren die nicht funktionierenden Links bislang nur solche.
Und bei dem Plugin mit Schnell-Links auf der linken Seite.
Crazy-to-Bike

Teilerfolg: Mit der configuration.php der Testinstallation funktioniert das Frontend. Das Backend liefert weiterhin Error 500. Vermutlich passt die configuration.php aus dem Joomla 3 nicht zu 100% zu der des Joomla 5.4. Aber das ist immerhin mal ein Ansatz.

Für gute Hinweise bin ich weiterhin dankbar.

Noch was - ist mir eben erst aufgefallen:
Wenn ich die kickstart.php mit https://www.meineseite.de/kickstart.php aufrufe und der Error 500 kommt, steht in der Adresszeile dann
https://www.meineseite.de/kickstart.php/src/kickstart_web.php

Im Fehlerprotokoll des Apache taucht der Fehler so auf:

Ach ja, das fällt mir erst jetzt wieder ein: Auch beim Aufruf der kickstart.php kommt ein Error 500. Ich habe dann im Terminal kickstart.php aufgerufen, was alle Dateien entpackt hat. Danach konnte ich kickstart.php auch im Browser aufrufen und fehlerfrei durchlaufen.

komplett ohne .htaccess passiert genau dasselbe wie mit der .htaccess aus der Migration.

Ich habe jetzt mal ein neues Joomla über den Installer von Netcup aufgesetzt Das funktioniert. Allerdings wird nur Joomla 3 angeboten und mit dessen .htaccess klappt's auch nicht (bleibt alles wie mit der migrietren .htaccess)

Mit der bekomme ich sowohl im Frontend und Backend einen error 500.

Mit der aus der migrierten Installation im Frontend " Seite nicht gefunden" und im Backend eoor 500.

Ok, danke schon mal.

das ist die aktuelle .htaccess:

## No directory listings
<IfModule mod_autoindex.c>
 IndexIgnore *
</IfModule>
##  Can be commented out if causes errors, see notes above.
# Options +FollowSymLinks
<IfModule mod_headers.c>
Header always set X-Content-Type-Options 'nosniff'
</IfModule>
#
#  mod_rewrite in use
RewriteEngine On
########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
#
########## End - Rewrite rules to block out some common exploits
#  Uncomment following line if your webserver's URL
#  is not directly related to physical file paths.
#  Update Your Joomla! Directory (just / for root)
# RewriteBase /

########## Begin - Joomla! core SEF Section
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$  [NC]
RewriteRule (.*) index.php
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
RewriteRule '\.css\.gz$' '-' [T=text/css,E=no-gzip:1,E=no-brotli:1]
RewriteRule '\.js\.gz$' '-' [T=text/javascript,E=no-gzip:1,E=no-brotli:1]
#
########## End - Joomla! core SEF Section
## empfohlene Security-Fixes
<FilesMatch "\.svg$">
 <IfModule mod_headers.c>
   Header always set Content-Security-Policy "script-src 'none'"
 </IfModule>
</FilesMatch>

AddDefaultCharset UTF-8
AddOutputFilterByType DEFLATE text/css application/x-javascript text/x-component text/html text/richtext text/javascript image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon application/javascript application/rss+xml

Was ist da ggf. problematisch / muss ich da ändern?