Beiträge von flotte

    Sie wird automatisch gesichert und beim Installieren beim Hoster wird eine Datenbank automatisch erstellt.

    Ich denke nicht das der Kickstarter von Akeeba eine Datenbank beim Hoster anlegen kann.
    Überlicherweise macht man das immer über das Control-Panel beim Hoster - ansonsten könnte je ein PHP-Script einfach eine Datenbank anlegen. Kann natürlich sein das es solche Hoster gibt... das will ich nicht ausschließen, aber sicher ist das nicht der Standard.

    Entwickler nutzen allzu gerne immer nur ganz aktuelle Serversoftware und verkennen die Realitäten, das dies auf den Hostingservern längst nicht überall der Fall ist. Dort kommen oft LTS-Versionen zum Einsatz oder Versionen die noch lange seitens der Distributionen unterstützt und gepacht werden. Ich weiss nicht welches "special feature" bei JD nun ausgerechnet diese hohe DB-Version erforderlich macht oder ob man das nicht auch kompatibel hätte programmieren können... Dann verliert der Hersteller eben massenhaft Anwender und schafft sich entsprechend viele Supportanfragen.... Tja.

    Ja mittlerweile scheint ein Updater von 3.2.69 auf 3.9.5 zu funktionieren. Allerdings wird mindestens MariaDB 10.3 benötigt, eine V10.1.x (z.B. unter Debian Stretch) scheitert - was unverständlich ist.... Ein so relativ simples Tool wie ein Download-Manager sollte keine höheren Ansprüche an die Datenbankversion haben, als der Joomla-Core selbst... Was um Himmles willen ist so kompliziert an abwärtskompatibler Programmierung? Massenhaft JDownloads-Anwender werden also deswegen Probleme bekommen.

    Ja das ist ein neuer Hinweis.


    Beim Updateversuch kommt nun auch ein neuer Hinweis:

    Fehler

    Zitat

    Sie haben versucht Ihre jDownloads Installation auf die Version 3.9.1 zu aktualisieren. Vorausetzung hierfür ist eine installierte Version 3.2.70. Sie haben aber noch die Version 3.2.69 installiert. Aktualisieren Sie daher zuerst auf die angegebene Version 3.2.70.

    Fehler beim Aktualisieren von Komponenten.


    Allerdings gibt es momentan 3.2.70 gar nicht....

    https://www.jdownloads.net/doc…rom-jdownloads-3-2-to-3-9


    Dies ist offenbar das Problem:

    Zitat

    Für eine noch bessere Integration mit Joomla! Es wurden einige Änderungen am Namen von Datenbankelementen vorgenommen. In der Dateitabelle der Dateien wurde beispielsweise der Name des ID-Felds von file_id in just id geändert, file_title wurde zu title und so weiter.

    im JD Forum steht dazu dies:

    Zitat

    there is nothing for the user to do - jD does all that is necessary

    Tja, nur leider stimmt das offenbar nicht.

    In mehreren Installationen habe ich dieselben Fehler gesehen. JD ist dann nicht mehr aufrufbar, weil Datenbankfehler angemeckert werden. Ein Blick in die Datenbank zeigt dann auch das die Namen nicht geändert wurden.


    Werde mich wohl direkt an JD wenden.

    Wir nutzen auf allen PCs eine Kombination von Eset-Produkten und Malwarebytes-Premium. Mal spricht das eine Tool an, mal das andere... Performanceverluste sind nicht bekannt. Und bei Emails werden grundsätzlich alle Office-Anhänge rausgefiltert. Das ist allerdings eine Option die man beim Hosting einstellt.

    Bislang damit gut gefahren.... toi toi toi

    Hallo vnv-urbex


    da die Seiten bei uns liegen habe ich mir das mal kurz angesehen. Liegen ja auf zwei verschiedenen Servern.

    Ich kann aktuell keine Performanceprobleme feststellen - eigentlich ganz im Gegenteil. Die TTFB-Zeiten liegen im Bereich 90 bis 300ms, meist unter 200ms und sind damit ausgesprochen gut, wobei die komplexeste Seite sogar die besten Zeiten hat. Habe jeweils aber nur kurz den Home-Link geprüft. Beide betroffenen Server haben Loadwerte im Bereich 0,5 und kleiner - ausgenommen mal den einen oder anderen Peak. Eine serverseitige Problematik schließe ich aus der ersten Analyse daher aus.

    Mach einfach mal eine Routenverfolgung und sende diese per Email an mich. Also "tracert domain" unter Windows oder "traceroute domain" unter Linux. Ggf. gibt es ja ein Routingproblem.

    Kurz ein anderer Aspekt:

    Was mich an manchen Designern/Agenturen massiv stört ist, das den Endkunden oft Websites erstellt werden mit Systemen wie Joomla, WordPress usw, aber der Endkunden darüber im Unklaren gelassen wird, das solche Scripte der regelmäßigen Wartung/Updates bedürfen und nicht monate- oder Jahrelang einfach unverändert wie eine statische Seite liegen gelassen werden darf.

    Die Endkunden werden oft nicht richtig aufgeklärt. Mir ist klar das viele Endkunden schnell ne günstige Seite haben wollen, aber keinen Bock auf Wartungsverträge haben, immerhin kostet ja auch der Hoster schon sagenhafte 3,90 Eur/Monat...

    Mir ist klar, das Designer/Agenturen oft jeden Auftrag brauchen und stellen dann die Notwendigkeit der späteren Wartung der Seite gerne in den Hintergrund - natürlich ausgeschlossen die hier aktiven serösen Agentueren/Designer.


    Im Ernst, wir erleben das als Hoster laufend, das Endkunden mitteilen, das Sie keine Ahnung vom Script haben oder Updates nicht machen, weil ihnen das niemand gesagt hat.


    Also: Wer sinnvoll über Risiken aufklärt und dies auch nachweislich tut (->Vertrag) lebt sicherlich was Haftungsfragen aus diesem Teilbereich angeht eher im grünen Bereich.

    die kickstart.php und auch das Archiv müssen nach dem Setup sofort gelöscht werden. Normalerweise passiert das automatisch, aber manachmal machen die USer nicht den letzten Schritt oder es klappt aus anderen Gründen nicht (wwwrun-Problem).

    Und ja, darüber wird gehackt und aktiv nach solchen Files gesucht (auch anderen Setups wie den Installer des Duplicators von Wordpress etc.pp.). Übrigens auch unser fc-PassReset und joom-config-Tool. User lassen das trotz eindeutiger Anweisungen einfach liegen.

    Wenn Du im Backend im Menü "Erweiterungen" -> Erweiterungen -> verwalten schaust und nach der id (letzte Spalte) sortieren lässt, kannst Du leicht alle Drittanbiter-Erweiterungen erkennen. Alles ab id 10.000

    Ich schau noch mind. 1x die Woche ins BE und mache dann gleich noch ein Backup.

    Dann noch das Backup auch auf den PC runterladen.

    Ich empfehle auch nicht alle alten Backups zu löschen. Behalte immer so die letzten 3-4 Backups.

    Dem kann ich mich nur anschließen. Ein wachsamer Webmaster prüft regelmäßig seine Website(s). Mindestens durch Einloggen ins Backup mit Prüfung auf Updates, Sichtung der Serverstatistiken (Unregelmäßigkeiten fallen dort schnell auf) und auch kurzer Check und Sichtung auf Dateiebene. Viele Hacks hinterlassen sofort erkennbare fragwürdige Dateien bereits auf Webroot-Ebene. All das sind ein paar Minuten Aufwand, wenn man es regelmäßig und geübt macht.


    PS:

    Backups würde ich sehr lange aufbewahren. Welchen Grund sollte es geben Backups zu löschen? Dann lieber mal 50 Eur in ne größere Festplatte investieren.

    An dieser Stelle geht es öffentlich nicht mehr weiter.

    Hört sich nach einem schwerwiegenden Problem an. Wenn ein Hack nicht "frisch" ist und früher schon übersehen wurde oder gar aus Backups wieder aktiviert wurde, ist eine Bereinigung nur sehr sehr schwer möglich. Eine ordentliche Untersuchung erfordert das aktuelle Logs und unveränderte Datumsstempel aller Dateien vorliegen und -ganz wichtig- ein zeitlich VOR dem Hack vorhandenes sauberes Backup und natürlich SSH-Zugriff und (oft vergessen) die FTP-Logs. Die Analyse soll in erster Linie den Zeitpunkt des Ersthacks feststellen und die Einbruchsstelle lokalisieren, damit man dann mit einem unverseuchten Backup alles bereinigen und die Lücken sofort fixen kann.

    Eine Bereinigung eines verseuchten Joomla ohne diese Vorgehensweise bzw ohne Kenntnis des Ersthack-Zeitpunkts und die benutzte Sicherheitslücke betrachten wir als fast unmöglich. In jeder die zigtausenden Dateien kann irgndwo ein kleines Codeschnipsel liegen, welches als Backdoor dienst. Das zu finden ist wie mit der Nadel im Heuhaufen. Ich weiss das einige auch eine solche Bereinigung für möglich halten, aber davon halten wir gar nichts - es sei denn Zeit und Geld spielen keine Rolle. Dann lieber die Seite neu aufsetzen.

    Deine Versionsangabe stammt offenbar aus der Systeminformation des Joomla. Warum dort so etwss angezeigt wird und nicht die konkrete MySQL-Version ist mir ein Rätzel. In phpMyAdmin findest Du die Versionsangabe. Es wird jedoch 10.3.11 sein.


    Zu Deiner weiter unten genannten Fejlermeldung beim Import:

    Womit genau wurde der Dump erzeugt? Was ist "mittels der GUI MySQL-Admin"?

    Meinst Du damit phpmyAdmin?

    Falls ja, achte darauf das das Anlegen der Datenbank nicht mit im Dump steht. Man muss zuerste links inder Navigationsleites die Datenbank auswählen, so das rechts im Hauptfenster die Tabellen zu sehen sind. Dann darüber den Export ausführen:

    Exportieren: https://www.fc-hosting.de/support/faq_phpmyadmin-export.php

    Importieren: https://www.fc-hosting.de/support/faq_phpmyadmin-import.php


    Wenn in Deinem Dump "CREATE DATABASE" im obenen Bereich steht, dann wurde der Dump nicht richtig erzeugt.


    Ich weiss nicht ob dies Dein Problem ist... schau einfach mal.