Lucan "kein KVM", daraus lässt sich folgern alter vServer, also keine normalen IP-Tables.
fxkopp Wenn du trotz neustart noch die alte IP-Adresse beim eth0 Interface hast, und (egal ob deshalb oder trotz dem) dein IP-Routing nicht korrekt funktioniert, solltest du mal ein Ticket an den Support schreiben.
Ich hab beim googlen folgendes Hilfsmittel gefunden:
for i in `find . -type d `; do echo `ls -a $i | wc -l` $i; done | sort -nDieser Befehl sucht im aktuellen Pfad alle (Unter-)Verzeichnisse und gibt die Anzahl der darin enthaltenen Dateien dazu aus. Der dauert etwas länger, da er die Ausgabe auch noch sortiert. Außerdem kann das auch eine ziemlich lange Ausgabe werden, also am besten in ein less pipen.
Aber damit solltest du schnell raus finden in welchem Verzeichnis besonders viele Dateien vorhanden sind.
Edit:
Oder die umgebaute variante die etwas mehr einem "du -s *" entspricht:
for i in `ls`; do echo `find $i -type f | wc -l` $i; done | sort -nAlso wie wäre es erstmal mit einem "ping 46.38.225.230"? Ansonsten mal
host -v google.deausprobieren.
Oder auch mal testen ob überhaupt eine Verbindung zum (TCP) DNS aufgebaut werden kann:
nc -v 46.38.225.230 53(Alternativ telnet, falls kein netcat installiert)
Inodes beziehen sich auf die Anzahl der existierenden Dateien. Diese sind auch begrenzt. Du hast also (vermutlich im /tmp-Verzeichnis) zu viele Dateien. Meistens sind es alte PHP-Session-Dateien, lösch' davon einfache einige und es sollte wieder laufen.
Wenn es sich tatsächlich um PHP-Session-Dateien im tmp-Verzeichnis handelt, kannst du alle die älter als 7 Tage sind mit folgendem Befehl löschen:
find /tmp -name 'sess_*' -atime +7 -deleteKannst du bitte nochmal erläutern was genau dein vorhaben ist? Es hört sich im Moment so an, als würdest du wollen das der Browser eine andere URL anzeigt, als die welcher Inhalt er gerade anzeigt. *verwirrt*
Also für mich hört sich das gerade so an, als würde Netcup zur Spamreduzierung Greylisting – Wikipedia einsetzen. Wenn dem so ist würde ich versuchen eine E-Mail an den Support zu schreiben, unter Umständen kann das für einzelne Domains deaktiviert werden.
Sorry, no idea then. Thats to hard to investigate without access to the system.
Sorry, 10 is the maximum, so try DebugLevel 10
Please add "DebugLevel 20" to proftpd.conf, restart server, try to connect again, and paste log-messages. (If it is a huge log, use nopaste or such)
Also ich bin eigentlich net gerne diese Art von Klugscheißer, aber hier fällt mir nur ein: http://bit.ly/10DDAYJ
It isn't intended to create a user on the system. The FTP should only use the Virtual users from the mysql-table.
Have you replaced the placeholder "MYSQL_PASSWORD" in /etc/proftpd/sql.conf.
Please check /var/log/proftpd/proftpd.log and paste some lines of your tries (without the created unix-user).
RayMD: Froxlor legt keine Benutzer an, die verwendeten ids existieren nicht.
cantek: Maybe proftpd isn't configured correctly to use MySQL. You can check if there is a file "/etc/proftpd/sql.conf". This file should contain "SQLConnectInfo" with MySQL username and password to connect to the Froxlor-Database.
If something looks to be wrong, log into Froxlor with admin-account, goto Server -> Configuration. Choose your distribution, then "FTP-Server" and "ProFTPd". On hitting "Next" you get to some instructions how to configure ProFTPd correctly (Froxlor doesn't do this automaticly, you have to follow the instructions).
Reseller-Package or vServer?
Are you using confixx oder froxlor or whatever?
Try accessing it with your ip instead of your domain-name. phpMyAdmin installs by default to the main directory root, but when you access a vhost-domain, an other directory is used.
You should use an SSH-Tunnel instead. That way there is no need to change most of those settings. Only no skip-networking has to be mentioned, but this is default setting.
Or you could use phpMyAdmin instead of your client app.
Assuming you're really trying to connect to the database from another server, there are multiple things you have to consider:
Opening the MySQL-Server for external access is not a good idea in my opinion. If external services needs access to your data you could consider creating a webservice.
Ich habe leider keine Ahnung von Confixx, aber prinzipiell bietet dies auch Möglichkeiten SSL-Zertifikate einzustellen. Ob dies ein selbst signiertes oder gekauftes ist, sollte dabei keine Rolle spielen.
Es gibt jedoch, wie bereits beschrieben, Einschränkungen aufgrund der IP-Adresse. Wenn du deine IP-Adresse mit anderen Webhosting-Nutzern teils, also keine exklusive IP-Adresse besitzt, dann wird es dir nicht möglich sein SSL einzurichten, da Zertifikate nur pro IP-Adresse eingerichtet werden können.
Also es muss generell erstmal zwischen 2 Varianten der Angriffe unterschieden werden:
Zu 1.:
Das wichtigste ist natürlich zu verhindern, dass jemand an deine Zugangsdaten kommt. Es gelten also die wichtigsten Passwort regeln: nicht zu einfach, regelmäßig ändern, nicht aufschreiben, etc...
Eine SSL-Verschlüsselung der HTTP-Verbindung ist schon zu empfehlen, da diese verhindert das jemand der in deinem (W)LAN ist deinen Traffic und damit dein Passwort mitlesen kann. (Besonders brisant bei öffentlichen WLAN-HotSpots). Den Admin-Bereich zu verstecken (wie für Wordpress beschrieben) kann natürlich helfen einen Angreifer auszubremsen, sollte aber nicht mit "Sicherheit" verwechselt werden (Security through obscurity – Wikipedia).
Weitere Möglichkeiten einen Administrations-Bereich abzusichern ist den Zugriff darauf zu beschränken, z.B. durch ein VPN (und dann via AccessRules nur das VPN-Intranet zuzulassen) oder auch mittels SSL-Client-Zertifikat (das bedeutet du brauchst auf dem Rechner ein ganz bestimmtes Zertifikat, das wie ein PrivateKey bei SSH funktioniert).
Zu 2.:
Die Anwendung selbst, die öffentlich zugänglich sein muss, wie der Wordpress-Blog selbst, lassen sich nur schwer absichern. Denn selbst wenn der Webseiten Zugriff SSL-Verschlüsselt ist, kann jeder Angreifer ja weiterhin auf die Webseite Zugreifen und eventuelle Exploits ausnutzen. Wichtigste Sicherheitsmaßnahme sind Updates: Sowohl beim Server (Distro, Apache, etc) als auch bei den verwendeten Anwendungen (Wordpress).
Dann gibt es noch PHP-Einstellungen (z.B. open_basedir) und Extension (suhosin; bin kein persönlicher Fan von, aber kann helfen) die gewisse Angriffe gegen PHP-Webanwendungen verhindern können, oder die Auswirkungen verringern können.
Mittels PHP via (f)CGI im Apache (statt als Modul) ist es auch möglich jede PHP-Anwendung als ein andereren Linux-Benutzer auszuführen, so lassen sich zusätzlich die Auswirkungen im Angriffsfall einschränken.
Nun noch mal zu SSL (https) Speziell:
Die verwendung eines SSL-Zertifikat hat grundlegend 2 Aufgaben: 1. Geben Sie dem Benutzer die Sicherheit das er mit dem richtigen Server spricht, denn er kann sehen für wen das Zertifikat ausgestellt ist und 2. es sorgt dafür das die gesamte HTTP-Kommunikation (zwischen diesem Server und dem Client) verschlüsselt wird. Letzteres ist wie schon erwähnt dann wichtig wenn Daten nicht mitgelesen werden sollen. Es empfiehlt sich daher für Administrations-Bereiche und anderen Anwendungen wie ownCloud, phpMyAdmin, Webmailer, etc. den Traffic zu verschlüsseln. Würdest du z.B. ownCloud ohne SSL in einem öffentlichen WLAN (z.B. bei Starbucks oder der DB) verwenden, könnte jeder in Funk-Reichweite nicht nur deine Login-Daten abfangen ohne das du es merkst, sondern auch alle hoch und runtergeladenen Dateien mitlesen.
Der 1. Punkt ist dagegen nicht so relevant da viele Endnutzer leider sowieso nicht darauf achten.
Es ist möglich kostenlos selbst ein SSL-Zertifikat zu erstellen und für beliebige Domains zu verwenden. Dazu gibt es unzählige Tutorials. Der nachteil ist dabei nur, dass das Zertifikat von keiner authentifizierten Stelle unterschrieben wurde und man beim Aufruf einer Seite die mit diesem Zertifikat verschlüsselt ist, eine Warnmeldung im Browser erscheint, die bestätigt werden muss (bestimmt schon häufig gesehen). Mir reicht dies für ownCloud, phpMyAdmin und roundCube-mail aus, da diese sowieso fast nur von mir verwendet werden. Du kannst zwar so viele Zertifikate erstellen wie du willst, aber da die SSL-Verschlüsselung stattfindet bevor der Apache weiß welcher VHost angesprochen wird, kannst du nur ein Zertifikat pro IP-Adresse verwenden. Willst du statt einem selbst erstelltem Zertifikat lieber ein echtes verwenden, das von deinem Browser ohne Warnung akzeptiert wird, musst du eines von einem entsprechenden Anbieter kaufen. Netcup bietet hier ein echt fairen Preis für 1 Jahr an. Dieses Zertifikat wäre dann jedoch auf genau eine Domain beschränkt (Zertifikate mit Wildcard-Subdomain, also für *.domain.tld kosten ein Schweine Geld). Wenn du eine Domain über https aufrufst die vom Zertifikat nicht abgedeckt ist, erscheint eine Warnmeldung (ähnlich der beim selbst erstellten Zertifikat), es macht daher beim selbst erstellten Zertifikat nicht viel aus für welche Domain dies erstellt wurde. Die Verschlüsselung des Traffics ist in jedem Fall gegeben, egal ob selbst erstellt, gekauft, richtige Domain oder falsche Domain.
So, das sollte dir einen groben Überblick verschaffen und dir dabei helfen zu wissen wonach du als nächstes Googlen möchtest oder du Detail-Fragen zu stellen magst.
