pleple

Trzeba oskryptować. W Perlu np masz moduł http://search.cpan.org/~tomzo/Quota-1.5.1/Quota.pm.

Ja nie wiem czy czytanie ze zrozumieniem to taki duży problem? Przecież ja nie piszę, że on ma sobie tak skonfigurować system w usłudze shared hosting. Jedyni usługodawcy, którzy zgodziliby się na takie zmiany dla pojedynczych użytkowników to Ci posiadający bardzo mało kont. Kiedy bowiem jest ich wiele ważna jest unifikacja konfiguracji. O, a tu potwierdzasz to co napisałem (i do czego się przyczepiłeś..).

Samo wykupienie VPS nie wystarczy, należy je jeszcze odpowiednio skonfigurować. Nie wystarczy bowiem iż każda strona będzie w osobnym virtualhoscie. Stąd też ja i prohost nieco rozszerzyliśmy temat. W przypadku resellera prawdopodobnie problemu nie będzie bo powinno to być odpowiednio skonfigurowane przez usługodawce.

open_basedir będzie się sprawdzał dopóki ktoś nie znajdzie kolejnego obejścia (przez jakiś moduł niezabezpieczony itp.). Przeniesienie PHP do FastCGI jest jednym ze sposobów na to żeby PHP działało w procesie odrębnym od serwera HTTP, na UID/GID użytkownika. A, jak mniemam, to miał Prohost na myśli..

http://www.hostip.info/ lub komercyjna (choć jest wersja darmowa): http://www.maxmind.com/app/ip-location Jeśli chodzi o ten drugi to jest jakiś moduł do Apache, który umożliwia w banalny sposób kontrolować dostęp na poziomie serwera HTTP.

Nie chcę się jakoś bardzo czepiać ale skoro to oferta pracy to warto przekazać ją jasno. Chodzi Ci więc o pełną poprawę bezpieczeństwa czy o "update kernela + firewall" ?

Trzeba by dokładniej zbadać sytuację. Najlepiej na szybko skonfigurować sobie coś prostego monitorującego system w niewielkich odstępach czasowych. Jeśli jakiś program ma wyciek pamięci to będzie to ładnie widać na wykresach - ilość zużytej pamięci będzie stopniowo rosnąć z czasem aż zacznie działać oom killer w jądrze i zabijać procesy. Zrzucanie cache tak jak to robisz na pewno nie jest dobrym rozwiązaniem. Właściwie to nie jest w ogóle rozwiązaniem, co najwyżej może być uznane za obejście problemu (choć wątpię w jego skuteczność). Ważnym jest też określenie co oznacza niedostępność. Nie da się otworzyć strony WWW na tym serwerze (zabity httpd), nie da się połączyć po SSH czy w ogóle serwer nie odpowiada na pingi. Jeśli nie wycinasz ICMP na firewallu (a w tym wypadku tak bym zrobił) to nawet jeśli OOM killer pozabija Ci procesy, powinieneś dostawać odpowiedź na pingi. Jeśli natomiast system przekręcił się na poziomie jądra to możliwe są dwa główne źródła problemu - albo to bug w kernelu albo, co jest wielokrotnie bardziej prawdopodobne, jest to błąd sprzętowy.

Tylko z ilością adresów IP trochę u nich bieda...

Jak już się czepiamy to pamięć jest używana zarówno do buforowania jak i cachowania. Ponadto nie używa się całej pamięci a jedynie zdecydowanej większości - w czasie normalnej pracy, pewna ilość dostępnej pamięci jest niezajęta i natychmiastowo gotowa do użytku.

Jeszcze raz przeczytaj wartości zwrócone przez ping, które przytoczyłeś. Jak Ci pięknie ertcap zaznaczył, średni czas jaki pakiet potrzebuje na dotarcie do pingowanego hosta wynosi 0.448 ms. Minimalny czas to 0.131 ms a odchylenie standardowe wynosi 0.863 ms. Oznacza to, że połowa wszystkich pingów wykonała się w czasie od 0.131 do 1.311 ms. Najdłuższy ping czekał na odpowiedź 16.846 ms. Ale zważywszy na resztę wyliczeń (niska średnia, niewielkie odchylenie), tych dużych czasów musiało być bardzo niewiele.

Jak by nie kombinować, nie można zezwolić użytkownikowi na odczyt/zapis jedynie w jego katalogu domowym i jednocześnie dać mu możliwość normalnej pracy. Chyba, że w jego katalogu domowym znajdzie się cały system operacyjny...

root może więcej Można sobie zdefiniować w systemie plików obszar dysku dostępny tylko dla roota. W ten sposób gdy skończy się miejsce, najważniejsze procesy (a więc te działające z UID 0) będą dalej mogły działać. Jak wywalisz odpowiednio dużo to zobaczysz, że to 100% spada.

Najlepiej NX. Jest DUUUŻO lepsze ale nieco trudniejsze w konfiguracji. Jest zdecydowanie. Choćby dzięki przejściu z QT3 na QT4. Jest jednak również jeszcze niezupełnie ukończone (część komponentów ciągle nie jest gotowa). Nadaje się już jednak do użytku a wiadomo że najlepiej testować na użytkownikach końcowych, dla tego oznaczone jest jako wydanie stabilne (wtedy więcej użytkowników przetestuje:)).

Znalezienie darmowego "hostingu", który teoretycznie daje takie parametry, nie jest takie trudne. W praktyce jednak nigdy nie dostaniesz nawet 10% z tego bo wcześniej Twoje konto zostanie usunięte lub zablokowane. Nie łudź się, im więcej darmowy hosting Ci oferuje, tym w praktyce na gorszym poziomie są u nich usługi.

Niezupełnie... Nadal są takie kwiatki jak "Monthly Bandwidth - 2Mbit" Moje uwagi dotyczyły oferty na Xen a nie na OpenVZ. Pozgłaszałem wszystkie bugi ale nic nie zostało naprawione. Zamiast tego oferta ta została po prostu usunięta a wszystkich przeniesiono na OpenVZ. Jak większość osób, przykładasz widocznie małą uwagę do bezpieczeństwa. Dla tego uważam iż dla dobra klientów HTTPS powinno być domyślne. Tak tylko, że większość ludzi nie zrobi tego sama. Zresztą ten numer portu to trzeba albo zgadnąć albo dopytać się albo jakoś googlać specjalnie. Ponadto, używają nieprawodłowego cerytfikatu co jest po prostu żałosne (chyba że poprawili to niedawno bo komentarz, który wygrzebałeś ma już pół roku).

No tak, zdecydowanie darmowy hosting pozostanie darmowym hostingiem. Ja zawsze powtarzam iż te dwie uslugi znacznie się różnią.. Jednak w obu przypadkach wszystko rozbija się o kasę - jeśli jakość jest na tyle niska że przez to tracą pieniądze, dokupią dodatkowe serwery.

Bankowo. Tylko, że oni nie zakładają nowej insfrastruktury dla 200k kont tylko ulepszają już istniejącą. Po prostu zmieniają serwery ze starej oferty Hetznera na te z nowszej. Jeśli więc obecne jako tako dają radę to te nowsze na pewno dadzą sobie radę lepiej..

Serwer HTTP nie ma tutaj za dużego znaczenia. Przede wszystkim poprawnie skonfigurowany Apache jest wcale niewiele wolniejszy niż te "lekkie" serwery, po drugie największym problemem jest obciążenie dysków (a ta, przy takim workloadzie nie może zostać praktycznie w żaden sposób zmniejszona przez zmianę serwera HTTP). Oczywiście obciążenie CPU też ma znaczenie ale i tak w głownej mierze powodowane jest przez PHP, liczenie statystyk (np. spróbuj sobie odpalić takiego awstats lub jakikolwiek inny parser logów apacha kiedy masz tyle stron), szukanie nielegalnych plików i tego typu prace "poboczne" (oczywiście mówie ogólnie, nie wiem czy akurat yoyo ma jakieś statystyki albo przeszukuje dyski w poszukiwaniu plików na których hostowanie nie pozwala.. bo można się bez tego obejść).

To jest jedynie nieco ponad 30k stron na jeden serwer, który ma dwa rdzenie, 8GB RAM i dwa dyski SATA. Jak ktoś słusznie zauważył jest to DRAMOWY hosting a to jest ZUPEŁNIE co innego niż shared hosting.

A na końcu miej problemy z zauważeniem różnicy.. O tak, być może zyskasz te parę procent ale nawet ważniejsze będzie, że uda Ci się wychwycić nowe bugi objawiające się tylko przy niestandardowych opcjach kompilacji. Świetnie ale czy na pewno tego właśnie chcemy na maszynie produkcyjnej? Śmiem wątpić.. Od wielu lat używam Gentoo jako podstawową dystrybucję na desktop więc wydaje mi się, że nieco wiem o rekompilacji pakietów. Zarządzałem też kilkoma serwerami na Gentoo i nie twierdzę, że takie podejście jest zawsze złe. Uważam jednak, że bardzo często zyski są niewspółmierne do strat.

Jeśli chcesz założyć coś jak yoyo to generalnie żaden z wymienionych wyżej się nie nada. CBA używa natomiast http://isp-control.net/ jeśli dobrze pamiętam. Jest on jednak architekturą podobny do DA, CPanel, Plesk itp więc nastawiony jest raczej na setki kont na jednym serwerze niż tysiące. Znam pewien panel, który jest dedykowany do darmowych hostingów ale nie podbam nazwy bo zdecydowanie go nie polecam. Wniosek - potrzebny jest autorski panel, niestety.

Może trzeba by zdefiniować czego konkretnie szukacie.. Np. czego brakuje Wam w AWStats...

Oczywiście, nigdy nie przeczyłem. Może ale nie musi, trzeba się o to postarać i spełnić trochę warunków. Jak sam zauważyłeś, trudno to jednak zrobić w przypadku usługi takich RPS-ów, kiedy niezupełnie można kontrolować co robią użytkownicy zasobów. Wprowadzenie (jeśli dobrze rozumiem) darmowych testów to bardzo dobry pomysł, dzięki temu będą mogli przynajmniej przygotować się na występujące problemy i być może pomyśleć o próbach rozwiązania. Czego by nie zrobili, skoków loadu i blokad procesów korzystających z I/O nie da się w pełni wyeliminować w takim środowisku.

NFS, oczywiście Procesy NFS nie mogą się dobić do serwera (ze względu na przeciążenie NAS), w związku z tym się blokują i czekają w kolejce. SSH próbuje coś odczytać z dysku (lub pewnie raczej jakiś proces odpalony w SSH, jak powłoka), NFS nie może dostarczyć, więc proces również się blokuje w oczekiwaniu na dane. Dla czego nie w home? Ciężko powiedzieć gdy nie znam konfiguracji... Przyglądam się temu wątkowi od początku i w sumie póki co, sprawdziły się moje wszystkie przewidywania. Każdy administrator prawdopodobnie wie, że filesystemy sieciowe oznaczją problemy, tutaj nie można więc było ich uniknąć.

Przecież jest napisane w specyfikacji, że jest 100Mbit połączenie. Łatwo przewidzeć ilu użytkowników przypada na dysk. Trzeba tylko zgadnąć jak duże dyski mają w NAS.. Jeśli to SAS to pewnie coś w okolicach 70GB, jeśli SATA to pewnie co najmniej dwukrotnie więcej..