Posts by Lukay

Hi,

dafür wäre erst mal die Info, welches Produkt du verwendet, sinnvoll.

Webhosting, managed (v)Server, unmanaged (v)Server?

Falls es kein Webhosting ist: welches Betriebssystem wird verwendet? Wo genau liegt das Problem beim ausführen der Befehle?

Quote

WordPress-Datenbank-Fehler Table 'k147859_db_????.n3fq9cfj34fcihbravyx_lockdowns' doesn't exist

Hast du auch die komplette Datenbank umgezogen?

Valkyrie wrote:

.bayern

Wollte ich mal, hab dann gesehen wie teuer die sind (im Gegensatz zu meinen .de Domains), habs dann gelassen..

Die PHP Version solltest du nicht nach eigenem Willen wechseln, sondern immer das eingestellt haben, was die Software, die du betreibst, braucht bzw vorschlägt.

Doim1990 wrote:

Er konnte ja nicht per SSH verbinden wie er oben schrieb. Deshalb sollte die Netzwerk Config überprüft werden

Oh. Lesen sollte man können..

Dann korrigiere ich meine Empfehlung, auf die Aussage von Doim1990

Dann hat die Netzwerk konfig ja scheinbar gepasst, wenn du per ssh verbinden konntest.

An deiner Stelle würde ich von da an weiter machen. (bei dem APT Fehler)

Cedrikst wrote:

Konnte keine Verbindungen zum update Server herstellen

Warst du per ssh zu dem Server verbunden oder über die VNC Konsole im SCP?

Cedrikst wrote:

Das hat so auch erst geklappt nur konnte ich dann nichtmal mehr "apt-get update" machen ohne einen error.

Welcher Error denn? Wenn der Ziel-server schon mal lief, kann ja gar nicht so viel schief gegangen sein?

Liegen in deinem Webroot denn die Ordner "/webseite/css/"?

Liegt in dem Ordner {webroot}/webseite/css/ denn auch die Datei "site.a69d84.css"?

killerbees19 wrote:

Also ist die in diesem Thread geschilderte "Selfie Verifikation" tatsächlich üblich?

Hatte ich tatsächlich bei einem ausländischen Provider schon mal. (Selfie mit Perso)

Ringelnatz wrote:

du solltest auf gar keinen Fall SQL-Statements vom Client zulassen

Da stimme ich definitiv zu. So hatte ich den Post im ersten Moment gar nicht interpretiert

Hallo,

natürlich kann jeder, der möchte, die Anfragen in der Browser Konsole einsehen und kopieren. Dagegen kannst du auch meiner Meinung nach nicht viel machen.

Wenn die Abfragen via Ajax wirklich so sensibel sind, solltest du vielleicht einen Login bauen?

Du könntest im PHP Script abfragen, ob der User, der die Ajax anfrage stellt, eingeloggt ist, und dann dementsprechend reagieren.

Das würde den User natürlich nicht davon abhalten, die Ajax abfragen zu manipulieren, aber du hättest bessere Kontrolle, wer überhaupt an die Daten gelangt.

aRaphael wrote:

Zumindest solange bis die etwas komplexeren bots kommen.

Funfact: einer meiner Server, mit einem alternativen SSH Port, steht seit ein paar Tagen plötzlich unter "Angriff", nachdem Jahrelang ruhe war

m_ueberall wrote:

Was sagt denn sudo systemd-analyze verify ts3server.service ?

Good to know, dass das existiert

Tealk wrote:

kommt das in unit oder service?

In den Service

Da dein Ziel im "/home" liegt, vermute ich, dass das helfen wird

H6G wrote:

What? Why?

Das denke ich mir so häufig, wenn ich mir shell skripte anschaue.

Bei uns auf dem Land ist jeden ersten Samstag im Monat Probealarm für die Feuerwehr-Sirene.

Aber gestern ist alles Stumm geblieben?..

Scheinbar zählten die Feuerwehr-Sirenen nicht zum test dazu?

mainziman wrote:

aber ich hab' Vorbehalte bei den ganzen Updatereien

Sicherheitsupdates klar, die müssen immer sein. Aber es kann leider nicht alles 20 Jahre lang in alte Versionen backported werden.

Irgendwann muss die Software nunmal geupdated werden

mainziman wrote:

weil es f. mein Webmail kein Update mehr vom Release meiner Distri her gab

Davon würde ich sowieso weg gehen. Webapplications werden bei mir nur von deren offizieller Website runtergeladen und entweder von dort geupdated oder mit deren eigenem System. (z.B. owncloud bringt einen Self-updater mit).

Auf der Website der Software siehst du dann auch, welche abhängigkeiten bestehen. (php version, php extensions etc.)

Mit Webapplications hatte ich in dem Sinne noch nie Probleme.

Dank vhosts und php-fpm kann man ja auch problemlos verschiedene php Versionen parallel betreiben.

mainziman wrote:

dass Sicherheitslücken durch veraltete Compiler/Interpreter udgl. kommen

und nix mit etwaigem Pfusch im Quellcode zu tun haben?

Teils. Lücken im Interpreter können sicheren Code unsicher machen und unsicheren Code noch unsicherer machen

Edit: Beispiel USN-4166-1