Beiträge von flotte

    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.

    Wenn ich das Eingangsposting richtig verstande habe, geht es darum das ein Import nach MySQL nicht funktioniert, weil utf8mb4 genutzt wird. Das steht in MySQL bis 5.5 nicht zur Verfügung. Im Dump kann man utf8mb4 geben utf8 ersetzen. Einfach mit einem Editir editieren. Aber bitte kein Notepad! Die Codierung der Dump-Datei darf nicht verändert werden.

    I.d.R. hat das herabssetzen von utf8mb4 auf utf8 keine besondere Auswirkung, es sei denn es wird tatsächlich der mit utf8mb4 erweiterte Zeichensatz zwangsweise benötigt. Das ist nur wirklich selten der Fall.


    Möglicherweise funktioniert aber die Installation einer Komponente unter MySQL 5.5 nicht? Dann bleibt normalerweise nur die Möglichkeit die Datenbankversion zu wechseln. Welche Möglichkeiten es hier gibt, kann Dir nur Dein Hoster beantworten. Du brauchst dann MYSQl 5.6 oder höher oder MariaDB 10.1 oder höher.

    Zunächst: Das sind Warnungen, keine Fehler. Warnungen sind oft bedeutungslos.

    In diesem Fall würd eich mal das Error-Reportung auf Maximum stellen und schauen, was sonst noch gemeldet wird. Möglichlerweise hilft das weiter.

    Langfristig fährt man mit eigener Shopsoftware wie Shopware besser als mit einer Komponente für Joomla. Daher empfehle ich das auch und ja, 500 Artikel sind nicht wirklich wenig.

    Einen "besten Shop" gibt es aber nicht. Zu unterschiedlich die Randbedingungen, das Backoffice, die Lager/Artikelverwaltung etc. pp.

    Ich habe das gerade mal in einem Testaccount nachgestellt und funktioniert via Symlink problemlos. Der Symlink zeigte innerhalb des Hostingaccounts auf ein anderes Verzeichnis.

    Ich kann mir eigentlich nur vorstellen, das serverseitig Symlinkverfolgung nicht erlaubt ist. Diese also bereits global oder in der vhhost-Konfiguration verboten wurden.

    Leute bleibt geduldig!

    Je besser das Release vorbereitet wird, desto weniger Bugs wird es geben - und ja es wird welche geben.

    Immer dieselbe Laier... wenn man keine Ahnung hat, holt man sich Hilfe - aber zeitnah.
    Das man Programme die sogar online erreichbar sind auch regelmäßig updaten muss, sollte man schon als grundlegendes Basiswissen eines Webmasters voraussetzen. Das nicht zu wissen, kann ich nicht mehr nachvollziehen. Auch sollten Update-Hinweise im Backend des Joomla im Laufe der Jahre mal irgendwann aufgefallen sein - oder nicht?

    Es sollte klar, das der Betreiber einer Homepage für eventuelle Schäden haftbar gemacht werden kann. Abmahungen wegen Spam etc. sind da noch das kleinere Übel. Stell Dir vor über Deine Seite werden Phishingseiten betrieben - ist kein Problem, Seite ist ja sofort hackbar.


    Hier im Forum gibt es genug Leute die Migrationen und Wartungsverträge anbieten. Auch auf unserer Website findet Du Partner die das machen (sind auch alle hier im Forum verteten). Wenn Du es nicht findest schreib mir ne PM.