Beiträge von ThomasChr

    Ich find das ganz gut dass die zwei Klassen-Kundschaft abgeschafft wird :whistling:

    UPDATE: Nachdem killerbees seinen Beitrag über mir gelöscht hat - dort hat er geschrieben "wann bekommt nclabs denn das neue VCP zu sehen".
    Darauf bezog sich der obere Kommentar.

    Die Cronjobs des Users müssen ja in der chroot ausgeführt werden, sonst könnte der User ja alle Sicherheitmechanismen der chroot über Cronjobs umgehen.
    Nebenbei bemerkt: Eine chroot ist nicht unbedingt aus Sicherheitsgründen nötig. Es gibt einen Hoster der nutzt keine chroot. Man hat also einen echten User...

    Thomas

    Hmmm, das WCP... *grusel*.
    Klick mal auf den Domainnamen, dann auf "Protokolldateien" und dort auf die "error_log".
    Da müssten deine 500er eigentlich zu finden sein.

    Der große Vorteil vom Shared Webhosting ist schonmal dass wir ein Konfigurationsproblem von Apache/PHP ausschließen können :)

    Also wenn ich auf blog.habitatxchange.org gehe, so komme ich bei irgendeinem medium.com raus. Scheint doch zu gehen.
    Ist ja kein Wunder, denn in deinen DNS Einstellungen steht deutlich drin dass für die Subdomains die IPs von Medium gelten sollen:

    Was genau geht nun nicht? Und CNAME Einträge sehe ich jetzt erstmal auch nicht...

    Thomas

    Ohne die genaue Domain und Subdomain zu kennen ists natürlich schwer hier zu helfen.
    Aber als erste Frage wie bei allen DNS-Dingen: Hast du bis zu 24 Stunden gewartet bevor du es probiert hast?

    Thomas

    PS: Die englische Anleitung scheint mir für das einrichten eines CNAME Eintrages ziemlich komplex, ich habs mir jetzt ned so ganz durchgelesen :)

    PS: Ich hab gerade nochmal geschaut warum fatrace nur folgendes loggt:

    Code
    1. Öffnen der html-Datei.
    2. Schreiben des Access-Logs.
    3. Schließen der html-Datei.

    Eigentlich hätte er ja das Lesen der html-Datei auch loggen müssen.
    Dummerweise liest der Apache die Datei nicht mit einem normalen READ, sondern er mappt sie sich in den Memory:
    (strace output)

    Code
    open("/var/www/html/index.html", O_RDONLY|O_CLOEXEC) = 17
    mmap(NULL, 8, PROT_READ, MAP_SHARED, 17, 0) = 0x7f4aec5b7000
    close(17)

    Und da fatrace auf inotify aufbaut, und dort in der Manpage steht:

    Code
    The inotify API does not report file accesses and modifications that may occur because of mmap(2), msync(2), and munmap(2).

    Jetzt ist meine Welt wieder heil :)

    Thomas

    Hmmm, installier dir mal das Tool 'fatrace', starte es, und ruf deine Seite auf.
    Es sollte dir ausgeben welche Dateien zugegriffen werden und von welchem Prozess.
    Sieht bei mir so aus:

    Code
    apache2(17340): O /var/www/html/index.html
    apache2(17340): W /var/log/apache2/access.log
    apache2(17340): C /var/www/html/index.html


    (Ich halte das für bedeutend schneller als eventuell verstreute Apache-Configs zu durchwühlen, auch wenn 'apachectl -S' hier wohl schon etwas helfen würde!)

    Also eigentlich sollte der Fehler entweder in /var/log/apache2/error.log oder in einem der Error-Logs der jeweiligen Seiten protokolliert sein.
    Es kann sein dass es overkill ist, aber du kannst auch alle Apache-Child Prozesse mit 'ps' auflisten, und dann alle Prozesse gleichzeitig mit 'strace' überwachen.

    Hier ein Beispiel bei mir: ps -efl | grep apache

    Code
    5 S root  	2900 	1  0  80   0 - 74235 poll_s Aug09 ?    	00:01:08 /usr/sbin/apache2 -k start5 S www-data 17335  2900  0  80   0 - 74291 lock_f 06:25 ?    	00:00:00 /usr/sbin/apache2 -k start5 S www-data 17336  2900  0  80   0 - 74289 lock_f 06:25 ?    	00:00:00 /usr/sbin/apache2 -k start5 S www-data 17338  2900  0  80   0 - 74289 lock_f 06:25 ?    	00:00:00 /usr/sbin/apache2 -k start5 S www-data 17339  2900  0  80   0 - 74289 lock_f 06:25 ?    	00:00:00 /usr/sbin/apache2 -k start5 S www-data 17340  2900  0  80   0 - 74253 ep_pol 06:25 ?    	00:00:00 /usr/sbin/apache2 -k start5 S www-data 18480  2900  0  80   0 - 74289 lock_f 08:56 ?    	00:00:00 /usr/sbin/apache2 -k start0 S root 	19487 19436  0  80   0 -  3938 pipe_w 11:28 pts/0	00:00:00 grep --color=auto apache


    Die PIDs aller Childs überwache ich nun mit strace:

    Code
    strace -p 17335 -p 17336 -p 17338 -p 17339 -p 17340 -p 18480

    Das ist (auf meinem Testsystem) sehr ruhig, weil die nicht viel mehr machen als auf einen Connect warten:

    Code
    [pid 17336] fcntl(9, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0} <unfinished ...>[pid 18480] fcntl(9, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0} <unfinished ...>[pid 17340] epoll_wait(15,  <unfinished ...>[pid 17339] fcntl(9, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0} <unfinished ...>[pid 17335] fcntl(9, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0} <unfinished ...>[pid 17338] fcntl(9, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0} <unfinished ...>[pid 17340] <... epoll_wait resumed> [], 2, 10000) = 0[pid 17340] epoll_wait(15, [], 2, 10000) = 0[pid 17340] epoll_wait(15,

    Wenn ich jetzt aber meine Seite aufrufe sieht man dass was passiert, so sollte das normale ausliefern einer html-Seite aussehen:

    Code
    [pid 17340] accept4(4, {sa_family=AF_INET6, sin6_port=htons(35581), inet_pton(AF_INET6, "::ffff:xx.xxx.xxx.xxxx", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28], SOCK_CLOEXEC) = 16[pid 17340] fcntl(9, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0[pid 17336] <... fcntl resumed> )   	= 0[pid 17336] epoll_wait(15,  <unfinished ...>[pid 17340] getsockname(16, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:xxx.xx.xx.xxx", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0[pid 17340] fcntl(16, F_GETFL)      	= 0x2 (flags O_RDWR)[pid 17340] fcntl(16, F_SETFL, O_RDWR|O_NONBLOCK) = 0[pid 17340] read(16, "GET / HTTP/1.0\r\nHost: domain.de\r\n"..., 8000) = 432[pid 17340] stat("/var/www/html/", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0[pid 17340] lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0[pid 17340] lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0[pid 17340] lstat("/var/www/html", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0[pid 17340] stat("/var/www/html/index.html", {st_mode=S_IFREG|0777, st_size=7, ...}) = 0[pid 17340] lstat("/var/www/html/index.html", {st_mode=S_IFREG|0777, st_size=7, ...}) = 0[pid 17340] open("/var/www/html/index.html", O_RDONLY|O_CLOEXEC) = 17[pid 17340] close(17)               	= 0[pid 17340] writev(16, [{"HTTP/1.1 304 Not Modified\r\nDate:"..., 142}], 1) = 142[pid 17340] write(12, "xx.xxx.xxx.xxx- - [17/Aug/2016:"..., 152) = 152[pid 17340] times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1784522822[pid 17340] shutdown(16, SHUT_WR)   	= 0[pid 17340] poll([{fd=16, events=POLLIN}], 1, 2000) = 1 ([{fd=16, revents=POLLIN|POLLHUP}])[pid 17340] read(16, "", 512)       	= 0[pid 17340] close(16)               	= 0[pid 17340] read(7, 0x7ffd931e364f, 1)  = -1 EAGAIN (Resource temporarily unavailable)[pid 17340] fcntl(9, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}

    Schön zu sehen auch dass der Indianer hier einen "Not Modified" Header als Antwort schickt.
    Mag sein dass es Overkill ist, aber wenn man im error log wirklich garnix findet, findet sich hier vielleicht ein Hinweis.

    Thomas

    Oder einfach mal im VCP direkt auf die Console gehen und mit dem Server verbinden. Geht das?
    Connection refused klingt danach dass entweder die Verbindung nicht klappt (z.B. plötzlich Firewall aktiv) oder dass der SSH-Dienst nicht läuft (weil er beim Booten irgendwo hängen bleibt).

    Wenn du dich über die Console im VCP einloggen kannst (das sollte eigentlich gehen) kannst du mal schauen was Firewall und SSH machen.
    Ein kurzes "netstat -tulpen" zeigt ob der SSH läuft!

    Thomas

    Debian 6 ist seit Februar 2016 nicht mehr im Support. Deshalb wird es wohl auch die Paketdateien nicht mehr geben.
    (Quelle: Debian – Wikipedia )

    Wenn du deine Pakete aber auf archive.debian.org änderst solltest du weiterhin Zugang zu den (nicht mehr gepflegten) Paketdateien haben.
    (Quelle: http://unix.stackexchange.com/questions/2699…ter-end-of-life )


    Ratsam ist es aber nicht eine Linux Distribution nach EOL weiter zu betreiben da natürlich keine Sicherheitslücken mehr gefixt werden.
    Außer natürlich du weißt genau was du tust und flickst alle Lücken selber...


    Thomas

    Die Antwort ist einfach:
    Es kommt drauf an :)

    Einerseits kriegen sie die Mailadressen beim abgrasen von Internetseiten. Andererseits natürlich bei allen Arten von Verzeichnissen.
    Wenn du deine Mailadresse bei der Denic für deine Domain angegeben hast bist du natürlich auch dran :)

    Vermutlich gibts noch einiges mehr an Wegen wie die an Mailadressen kommen. Spam ist meiner Meinung nach irgendwie ne eht traurige Geschichte und macht mehr oder weniger das Mailsystem kaputt. Früher hatte man gedacht jeder Mailserver leitet einfach für jeden Mails an jeden weiter... tja, das wäre heute natürlich tödlich :(

    Die CPUs sind dediziert. Das heißt also ein CPU-Kern sollte dir jederzeit zur Verfügung stehen, weil er "dir gehört".
    Das System selbst gehört dir nicht komplett, das heißt also Bus-Zugriffe deiner Mit-VMs bremsen dich natürlich schon aus.

    Thomas

    PS: Habs nun in ne Tabelle. Ich hoffe die bricht nun bei jeder Bildschrirmauflösung richtig um. Ist ein ziemliches gefrikel. Sieht aber deutlich besser aus. Danke für den Tipp!

    Andreas:
    Ich denke der "langsame" Ram kommt durch die Virtualisierung.
    Hier der komplette Output auf einem netcup vServer:

    Der Ram ist also ein deutliches Stückchen langsamer als auf einem dedicated Root-Server.
    Das ist aber mit KVM-Virtualisierung auch zu erwarten.

    Interessant ist auch dass ich "normalerweise" genauso 0.11ms erhalte so wie du. Nur der max Wert liegt auch mal bei 7.39ms.
    Ich würde vermuten da ist der Bus einfach beschäftigt (wegen irgendeinem anderen vServer auf dem gleichen Host) und mein RAM-Zugriff muss warten...

    Thomas

    Auf deren Website (unter Hostsysteme und Klick auf SSD) heißt es:

    Zitat

    Wir setzen daher einen zweischichtigen Storage-Aufbau bei unseren vServer-Hostsystemen ein. Die Basis bildet ein Hardware-RAID-10 (siehe auch Hostsysteme) aus 4-8 Festplatten. Um dessen Leistung zu steigern, schalten wir ein RAID-1 aus SSDs vor die eigentlichen Festplatten und nutzen dieses als Zwischenspeicher für Schreib- und Lesezugriffe. Dies beschleunigt unsere vServer auf SSD-Niveau und wappnet diese damit auch für umfangreiche Anwendungen.

    Vom IO Durchsatz kann man das nicht beurteilen, aber die schlechte fsync() Zeit deutet zumindest mal auf einen zu kleinen Write-Buffer hin. (der sitzt im RAID-Controller)

    Meine Tests waren ja direkt nach erscheinen der neuen vServer Generation von netcup. Ich habe gerade nochmal getestet und es war ein Stückchen schlechter (weil mittlerweile mehr Last auf den neuen Systemen ist) aber netcup war immer noch klar auf Platz 1.

    Der Anbieter mit "IP" hat mich gebeten noch zwei Monate zu warten. Ein Vergleich kommt aber sowieso noch nicht in Frage denn deren vServer haben keine SSDs. Das soll sich aber in zwei Monaten ändern.

    Den Mitbewerber 1b guck ich mir mal an, bislang ist mir dieser noch nicht so oft über den Weg gelaufen :)

    Thomas