Beiträge von gindi35510

Zitat von joomlatist

Hallo!
Ich habe ein Big Proplem. Von jetzt auf gleich hat mein Hoster (one.com) meine Seite stillgelegt, da dort offenbar Malware entdeckt wurde.
Ich habe nur noch den ftp-Zugang. Über diesen habe ich das Joomla 6.0-update hochgeladen, in der Hoffnung, damit alles zu lösen. Als Antwort erhielt ich eine Liste von sage und schreibe 300 Dateien, die angeblich immer noch befallen seien.
Ich habe über meine komplette Seite Malware-Scanner laufen lassen. Avira fand ganze 20 verdächtige Dateien, die sie repariert hat. Malwarebytes und Avast fanden nichts.
Hat jemand eine Ahnung, was ich tun kann, damit mein Hoster die Seite wieder freigibt?
Besten Dank im Voraus!

Frage: Welche Joomla Version wurde von Deinem Hoster stillgelegt?

Entspricht das Backup vom 03.Januar der gleichen Version wie die stillgelegte Version oder war das eine noch frühere Version?

Wie hast Du die Dateien für das Backup vom 03.Januar heruntergeladen? Website und Datenbank.

Die Notlösung mit Joomla 6.0 könnte eventuell daran scheitern daß die Systemvoraussetzungen für Joomla 6 nicht erfüllt sind weil bei deinem Hoster niedrigere php- und Datenbank versionen eingestellt sind?

Bei der Liste von deinem Hoster ist mir aufgefallen, daß bei fast allen Dateien ab einem bestimmten Unterverzeichnis die Unterverzeichnisse verdoppelt wurden und sinnlose index und cache Einträge enthalten. Vielleicht könnte es helfen wenn die doppelten Unterverzeichnisse samt Inhalt gelöscht werden.

Der Tip ist ohne Garantie darum teste das erst einmal lokal.

Zitat von joomlatist

Das Backup ist vom 3. Januar 26.

Die Frage ist nur ob dieses Backup mit Akeeba erstellt wurde. Wenn ja und wenn es mit Kickstart zurück gespielt wurde, dürften keine Fehler auftreten, es sei denn daß bei der Konfiguration mit Angie falsche Einträge gemacht wurden.

Wenn es nicht mit Akeeba erstellt wurde, frage ich mich wozu installiere ich Akeeba Backup aber benutze es nicht?

Vermutlich hat sich Elwood nur falsch ausgedrückt. Bei #3 wird im Text unter dem Spoiler durchaus akeebabackup erwähnt.

administrator/components/com_akeebabackup/tmpl/includefolders/includefolders/VANgcFpMhHyEXtqT.wav

administrator/components/com_akeebabackup/tmpl/includefolders/includefolders/cache.php

administrator/components/com_akeebabackup/tmpl/includefolders/includefolders/index.php

Leider deuten diese Einträge auf eine Hack hin.

In allen von mir überprüften Joomla Versionen (von 4.0 bis 6.1.2) gibt es dort nur eine Datei

administrator/components/com_akeebabackup/tmpl/includefolders/default.php

Bestimmt ist es bei allen anderen Dateien in der Liste genau so.

Hast Du mal versucht das Update von 6.1.0 auf 6.1.1 zu machen? Kommt der Fehler dann auch?

Ich hoffe, ich kann etwas zur Klärung des Problems beitragen.

Seit Joomla 2.5 mache ich wöchentlich mit Akeeba Backup ein Backup meiner Website bei STRATO.

Bis zu Joomla 4.2.4 (Nov. 2022) steht als Archivname site-http://www.meinewebsite-date-time-random.jpa

Seit Joomla 4.2.5 (Nov.2022) bis heute steht als Archivname site-meinewebsite-date-time-random.jpa

Wenn ich lokal ein Backup mache steht immer als Archivname site-localhost-date-time-random.jpa

Ich weiß nicht aus welcher Quelle die Hinweise zum Backup kommen.

In Akeeba Backup lautet der Text wie folgt:

The restoration is complete

Next steps

Close this window to return to Kickstart. Click the Clean Up button to start using your restored site.

Wenn man das befolgt wird angezeigt:

Restoration and Clean Up

Run the Installer

Clean Up

Wenn man auf "Clean Up" klickt, wechselt der Text auf

Restoration and Clean Up

Run the Installer

Visit your site's frontend

und der Installation-Ordner ist unwiederbringlich gelöscht.

Ich hatte das Problem bei Strato mit einer Website aus dem Webhostingpaket. Da wurden auch keine Updates angezeigt.

Das gleiche Problem hatte ich mit Backups dieser Website.

Das Problem war, daß in der php.ini kein Eintrag für upload_tmp_dir vorhanden war. Das Feld ist standartmäßig ohne Eintrag.

Ich habe dann bei mir lokal in der php.ini upload_tmp_dir = "/srv/www/htdocs/tmp" eingetragen und seit dem werden mir lokal alle Updates zum Download angeboten.

Strato wollte den Eintrag nicht ändern weil diese php Version für viel Benutzer da ist.

gindi

Schau doch mal in der Datenbank welche Kollation die Tabellen haben. Normal wäre utf8mb4_unicode_ci. Kann es sein, daß bei Dir utf8mb3_general_ci steht? Vielleicht wird die Datenbank deswegen nicht angezeigt.

Bei System/Wartung, ist hinter Datenbanken ein grünes Häkchen oder steht da eine Zahl?

BTW: Ein Backup mit Akeeba ist immer sicher und kann benutzt werden, besonders für Sicherungen.

Zitat von jow

vor ca. 10 Tagen habe ich ein Update von Joomla 6.0.4 auf 6.1.0 durchgeführt. Heute ist die Version 6.0.4 wieder aktiv. Wie passiert so etwas?

Zusätzlich gibt es Updates für Erweiterung (Phoca Gallery von 6.0.1 auf 6.1.0 und German Language Paket von 6.0.4.1 auf 6.1.0.1). Vor dem Update soll man die Kompatibilität zur Joomla Version prüfen. Wo finde ich die Kompatibilitätsaussagen?

Und reicht als empfohlenes Backup das tägliche des Hosters?

Wie hast Du das Update durchgeführt?

Wahrscheinlich nicht mit dem Joomla Updater, denn dann hätte er dich auf inkompatible Erweiterungen hingewiesen und vor dem Update ein Backup gemacht, es sei denn Du hast diese Funktion deaktiviert.

Vor dem Update mußt Du ein Kästchen anklicken in dem Du bestätigst ein Update gemacht zu haben, sonst macht Joomla kein Update. Die Textdateien kannst Du dann über Erweiterungen installieren aktualisieren.

Wie hast Du das Update gemacht?

Zitat von DerMueller

Sorry, ja, ich habe nur an mir selber gezweifelt. Aber die Datenbank hat die "10" nicht genommen.

Das ist eigentlich nicht möglich.

Hast Du die Änderung mit phpMyAdmin vorgenommen und wie bist dabei vorgegangen?

Noch eine Frage: Wird in der Tabelle xx_content in der Zeile checked_out hinter dem Namen ein index angezeigt? (Sieht aus wie ein Schlüssel)

Wenn nein, gehe ganz ans Ende der Zeile checked_out und klicke auf "mehr". In dem Fenster klicke auf index und speichere.

gindi

Es ist verwirrend daß in diesen Bildern im Feld Länge/Wert einmal 10 steht und im nächsten Bild ist es leer.

Gibt es in der Datenbank die Tabelle xx_content mehrfach mit unterschiedlichem contex?

gindi

Hast Du in der Tabelle x_content die Zeile checked_out gem. den Vorschlägen aktualisiert und hast trotzdem noch die Fehlermeldung?

Sollte sich die Tabelle #__session trotzdem wieder übermäßig füllen, schau doch mal in die Lösung bei Elwoods Link in #9 ob in der php.ini der Eintrag session.gc_probalility auf 1 steht.

Die Einträge bei mir sind mit 6.1.0 :

Name: checked_out

Typ: INT

Länge/Wert: 10

Standard: NULL

Attribute: UNSIGNED

Null: checked

Rechte Anpassen: checked

Nein.

Kettenrad ist der interne Namen der Engine, die für das packen der Dateien und Datenbanken verantwortlich ist.

gindi

Hallo Bea,

das sollte doch durch Admin Tools schon gemacht worden sein, es passt die .htaccess den Erfordernissen an und schützt die Userseite und das Backend.

Wenn jemand x mal ein falscher Passwort eingibt, wird die IP für drei Tage gesperrt. Egal ob als User oder als Admin.

In der Konfiguration kannst Du einstellen wie oft ein falsches Passwort eingegeben werden kann bis die IP gesperrt wird und wieviele Tage die IP gesperrt wird. Du hast auch die Möglichkeit eine IP dauerhaft zu sperren.

Gruß gindi

Meinst Du damit eine öffentliche Website oder die lokale Website?

hallo Bea,

schau doch mal in Admin Tools im Control Panel ob da oben eine Meldung steht "Your server config file may need to be rebuilt" ?

wenn ja,dann darauf klicken und die Anweisung befolgen.

Diese Meldung kommt oft wenn etwas geändert wurde.

Gruß gindi

Zitat von Rolf Dautrich

gindi35510 Javascript-Dateien siehst Du in den Entwickler-Tools Deines Browsers unter Konsole (hier:Firefox):

Danke für den Hinweis, da habe ich wieder was dazu gelernt.

Ich habe das mit den -min Dateien getestet. Mit System debuggen NEIN werden fast 30 .min.js Dateien angezeigt. mit System debuggen JA sind es nur zwei Dateien.

Zitat von JoomlaWunder

Welchen verwendest du? Teste unbedingt einen anderen Browser! Wenn wir mögliche Ursachen nicht ausschließem, dann drehen wir uns im Kreis.

Ich verwende Mozilla Firefox 140.9.0esr (64 bit) und wenn es am Browser liegen soll, wieso habe ich den Fehler nicht in BFB604 und BFB605test obwohl sie bis auf die absoluten Pfade identisch mit BFB604test sind?

Gruss gindi