Pan Kot

Aplikacje się same z siebie nie psują, a przynajmniej nie powinny. Idąc Twoim tokiem myślenia nadal powinniśmy trzymać się na windowsach 98 i debianie 3.1 bo nie ma sensu przesiadać się na nowsze wersje.To trochę słabe porównanie, ale sens jest zachowany - skoro wychodzą aplikacje lepsze to chyba oczywiste jest, że trzeba je polecać na każdym kroku. Jeśli administrator jest konserwatywny i zamknięty na jakiekolwiek zmiany to serwer prędzej czy później nie wytrzyma zarówno sprzętowo jak i software'owo. Czemu się wymienia procesory na nowsze modele? Czemu ludzie używają 64 bitowych systemów skoro mają swoje stare 32? Czasem łatwiej zamiast wyciskać maximum ze starych technologii spojrzeć na to z "innej" strony i zauważyć fakt, że poświęcając godzinę na np. taką rekompilację kernela konkretnie pod dany serwer można uzyskać do 30% lepszej wydajności, teoretycznie nie robiąc nic szczególnego. Znajdź sobie na google jakiekolwiek porównanie apache'a z mod_php vs. nginx z php-fpm. Sam zobaczysz jak się to przedstawia.

Nie, to jest tak jakbyś jeździł maluchem i się skarżył na to, że jest za wolny, a my Ci mówimy że można tego malucha za darmo zmienić na hondę civic w każdym komisie. I to jest swoją drogą to, o czym zawsze mówię. Administratorzy nie szukają lepszych rozwiązań, co z tego że istnieje lighttpd, cherokee, nginx... zostaję przy apache'u na preforku bo na moim innym serwerze działa... Aha. Piszesz temat więc staramy Ci się wytłumaczyć co jest nie tak, a ty nadal się upierasz przy swoim. Czemu więc zakładasz temat skoro negujesz jakąkolwiek propozycję?

apt-get install vnc4server vnc4server Nie takie trudne. Out of box bez konfigurowania.

No i było tak pięknie i znowu popsułeś. Było zostawić to account suspended, podobała mi się tamta koncepcja.

Ja proponuję podobnie jak @Kamikadze wyposażyć się w inną taśmę (koszt prawie zerowy) i sprawdzić, jak się dogadasz z jakimś sklepem komputerowym to pewno nawet na miejscu Ci dadzą sprawdzić.

VNC != Tryb graficzny. To są dwie zupełnie różne i niezwiązane ze sobą rzeczy, a żeby odpalić VNC to nawet nie potrzebujesz nic innego niż najzwyklejszy w świecie xterm, który nie obciąża systemu w prawie żadnym stopniu .

Ja Wam źle nie życzę, co więcej, życzę wszystkiego dobrego bo gdybym miał inne zamiary to nie pisałbym w tym temacie tylko śmigał na koncie roota w tym momencie . Wasza wola.

Akurat brute-force to najmniejszy problem w tym momencie .

Co do zabezpieczeń to polecam jednak nie być takim pewnym . 22/tcp open ssh OpenSSH 5.3 (protocol 2.0)

A na DDoS'y przygotowani? Service Info: Host: agnieszka.csdc.pl; OS: Unix Plus za fajny hostname. Ale kimsyf z OVH to nie wiem czy jest dobrym startem .

Weź tylko poprawkę na to, że nie każda firma ma te informacje publicznie dostępne w bazie whois, także nawet jeśli to swoje api zrobisz to i tak nie będziesz w stanie na ich podstawie sprawdzić tego, czego chcesz. Zastanowiłbym się raczej nad jakimś lepszym sposobem np. randomowo generowanym kodem w wiadomości e-mail, która jest wysyłana na jakiś randomowy adres 3749dd@domenaklienta.pl, który on musi stworzyć i tego maila odebrać. Więc dostaje informację, tworzy maila, klika button "wyślij potwierdzenie" i potwierdza. Trochę pojechałem z offtopiciem tak naprawdę, ale wymaganie danych bezpośrednio w bazie DNS jest trochę dziwnym wymogiem z Twojej strony .

Raczej OVH tu wypadnie najlepiej i wątpię, żebyś znalazł coś lepszego w tej ofercie. Nie wiem też czy kimsyfy lokują w BHS, ale jeśli tak to masz swoją amerykę z kimsyfem, więcej do szczęścia nie potrzeba .

Sprawdź /etc/fstab czy / jest podmontowany z opcjami usrquota,grpquota.

Ale przecież on nawet dedyka nie ma tylko jakiś shared hosting za "pińć" złoty. archi@archi:~$ host 94.249.202.150 Host 150.202.249.94.in-addr.arpa. not found: 3(NXDOMAIN) archi@archi:~$ host spolecznosc-graczy.pl spolecznosc-graczy.pl has address 94.249.202.150 spolecznosc-graczy.pl mail is handled by 10 mail.spolecznosc-graczy.pl. archi@archi:~$ host mail.spolecznosc-graczy.pl mail.spolecznosc-graczy.pl has address 94.249.202.150 A do tego ta firma u której się hostuje nawet nie rozdzieliła maila od serwera www . Ale generalnie tak, teraz jest o wiele lepiej. Treść jest czytelna, a serwer chodzi bardzo sprawnie.

To jest tak fundamentalna zmiana, że zajęłaby przynajmniej kilkadziesiąt lat, spójrz chociażby na aktualną sytuację z IPv6. Ilu ISP dziś oferuje dostęp przez IPv6? Nie mam tu na myśli serwerowni, a jakieś neostrady czy upc. Nie wiem jak jest u neo, ale w upc jak nie było ipv6 tak nie ma. To teraz sobie wyobraź co by się działo przy rozwaleniu tcp i udp, skoro to na tym się teoretycznie opiera całe działanie sieci.

Na workera sobie możesz zmienić bez problemu, ale PHP w standardowej konfiguracji to Ci działać nie będzie. Mod_php nie jest kompatybilny z apache'owym workerem (tylko prefork) i m.in dlatego musi być wspomagany przez cgi bądź fastcgi. Sam sprawdź.

Czemu co jakiś czas przychodzą na to forum tacy wariaci i próbują na siłę wszcząć jakiś bunt? Przyznać się, która firma ich wysyła? @m0t Skończ swoje teorie spiskowe i zajmij się swoimi sprawami. Nie wiem w ogóle na jakiej podstawie tworzysz takie zarzuty, przecież to się ni cholery kupy nie trzyma.

Zacznij od apt-get install quota. Powinien spełnić wszystkie zależności. A potem dla pewności daj apt-get install -f

worker.c to właśnie to o czym mówię, wymaga CGI bądź FastCGI. Poczytaj sobie o tym.

No jak jedziesz na prefork apache'u mając 512 mb ram to nie dziwie się, że po 300 procesów się robi i loadavg leci w górę . A i ograniczając workerów apache'a nie rozwiązujesz problemu, userzy będą dostawać error 503 z tego co pamiętam - resource temporarily unavailable. Polecam poczytać o apache'u i (fast)cgi bądź przesiąść się na nginxa z php-fpm. Jeśli tak bardzo boisz się tych rewrite'ów to jest jeszcze np. lighttpd.

Po prostu przerzucił Ci się z socketa TCP na socket unixowy. Albo zmieniasz to z powrotem na TCP, albo w serwerze FastCGI ustawiasz nasłuchiwanie po sockecie unix, a nie tcp.

Pamiętaj, że na load average nie wpływa tylko ram i cpu, ale także I/O. Pamiętaj też, że to, co u Ciebie jest zużyciem 20% cpu w rzeczywistości może być 100% dla serwera-matki. To jest VPS więc wszystko jest możliwe. Zacząłbym od wyżej wspomnianego iotop'a podczas obciążenia. Możesz nawet zwykłym dd sprawdzić szybkość odczytu/zapisu na dysk, jeśli będzie zbyt mały to definitywnie dysk jest wąskim gardłem.

Zawsze możesz sam kernela zrekompilować, ale dziwne że aktualnego configu nie ma, stockowe kernele powinny mieć plik /proc/config.gz. Jesteś pewny, że w /boot nie ma żadnego pliku config-xxx, a w nim wpisu na temat quoty? Powinno być przynajmniej "config_quota is not set".

Update :

Dziwne, standardowy kernel debiana 6 powinien mieć quotę skompilowaną. Myślałem, że się na jakiegoś lipnego OpenVZ'ta ustawiłeś. Dla pewności zawsze możesz pobrać/zaktualizować linux-image z repo debiana, ale jestem prawie pewny, że nie tu leży problem. Proponuję odnaleźć swój aktualny config kernela, powinien leżeć gdzieś w /boot pod nazwą config-xxx i przeszukac go zwykłą komendą w stylu cat /boot/config-xxx | grep "quota". Powinno być CONFIG_QUOTA=y. A jakbyś go w boot nie znalazł to sprawdź jeszcze /proc/config.gz