Pan Kot

Chmura to nie dedyk, e24 z tego co pamiętam używa OpenVZ, ale mogę się mylić.

Jesteś pewny, że jest to dedyk bądź VPS z XEN, prawda? Jeśli tak to ustawienie hostname może pomóc. Edytuj plik /etc/hostname i wpisz tam jakąś nazwę dla serwera, polecam wpisać domenę na której stoi.

No jak to Sponsi, sieć serwerów, jeden serwer kilkunasto-slotowy wykupiony w jakiejś pukawce czy innym resellerze. SIEĆ SERWERÓW . 3/10.

Co zwraca dpkg -l hostname ?

Zacznij od apt-get update && apt-get dist-upgrade I dla pewności apt-get install --reinstall hostname.

Naprawdę?

Po co Ci panel do tego? du -k | sort -n | perl -ne 'if ( /^(\d+)\s+(.*$)/){$l=log($1+.1);$m=int($l/log(1024)); printf ("%6.1f\t%s\t%25s %s\n",($1/(2**(10*$m))),(("K","M","G","T","P")[$m]),"*"x (1.5*$l),$2);}' Poda Ci największe foldery. Alternatywa: du -a / | sort -n -r | head -n 10

Restartowałeś system o tej 13:16? Jeśli nie to możliwe, że serwer-matka był restartowany. Po logach definitywnie widać, że albo coś restartowało jakieś usługi (przynajmniej kilka z nich) albo był reboot.

Chodziło mi bardziej o sysloga, sam widzisz że mysql.log niewiele nam tu pomoże . W ciemno strzelam na problemy z ramem. Możliwe, że na VPS'ie (bądź na matce! ) jest za mało ramu i MySQL nie ma gdzie ulokować swoich narzędzi. Tak jak mówię - syslog nam tu więcej powie.

Ten log mówi tyle co "proces mysqla nie został właściwie zamknięty". Wcześniejsze logi by tu dużo więcej powiedziały.

Spoko pierdo .

Haha . Ja myślałem, że autorowi chodzi o błędy stylistyczne, a konkretniej błędy STRICT i NOTICE w php. Przecież tu czarno na białym jak byk stoi, że winą są Twoje skrypty.

No, czyli jednak masz zerowe pojęcie co z tym zrobić. A może łaskawie zobaczyłbyś który plik generuje errory i wkleił do niego ten kod? A jeśli nie masz takiej ochoty to może jednak na samym początku głównego skryptu, a nie po connect.php, który prawdopodobnie generuje błędy?

Widocznie nie umiesz wklejać i masz zerowe pojęcie co z tym zrobić.

error id=0 oznacza, że ostatnia komenda została wpisana dobrze...

Domyślam się, że chodzi Ci o błędy PHP. Plik php.ini linijka display_errors.

Dziwne, ataki na usługę powodują najczęściej niedostępność tylko danej konkretnej usługi, a nie całej maszyny (jak to jest przy ddosie po przepustowości). No chyba, że OpenSSH nie ma już "gdzie" ulokować nowej sesji.

To jest nowa oferta serwerów dedykowanych na rok 2013/2014 .

I dlatego właśnie nrm robimy za adminów, a nie pracowników BOK .

Ja tam się pod tym podpisuję . Trochę zmian zawsze się przyda.

Mało która firma da Ci na wirtualce nielimitowany transfer. Proponowałbym się dogadywać via e-mail z BOK'iem wybranych firm.

No to niestety w przypadku ataków DDoS nie będzie tanich rozwiązań. Jeśli to rzeczywiście prawda (w co wątpię mówiąc szczerze) to bez fizycznego firewalla nic nie poradzisz, możesz tylko minimalizować ruch firewallami software'owymi np. CSF czy Shorewall. Jeśli mam być szczery to nie ufałbym temu "wykresowi ataku ddos" i zainstalował coś własnego, jakiegoś vnstat'a, ntopa bądź cokolwiek, co da jakieś realne statystyki. Równie dobrze ddos może lecieć w jakiś inny VPS na Twojej maszynie matce i odcinać również Ciebie.

FreeBSD jest wymogiem koniecznym? Jakie usługi hostujesz na serwerze, stronę? Jakiś serwer gry? To ważne.

To powodzenia bo prawdopodobnie czas jest kontrolowany po stronie serwera . W cookie jest tylko numer sesji i profilu.

W przypadku ataku DDoS to właśnie transfer przychodzący powinien osiągać kolosalne liczby, w tych statystykach tego nie widać.