Pan Kot

A ja inaczej zinterpretowałem ten fragment .

Czyli to żaden VPS, a zwykły reseller serwerów minecraft . A jeśli się mylę to poproszę o ofertę w tym temacie bądź na PW, ponieważ nie spotkałem się jeszcze z taką ofertą. A co do pytania to apache zjada... przy Twoim ruchu nie więcej jak 8-16 mb.

Nie wróżę Ci przyszłości tego serwera w takim razie. Ledwo go kupiłeś i już chcesz ludziom sprzedawać usługi. Nie powiem jak skończyli Twoi poprzednicy . http://bit.ly/XktMej

A wg mnie nie. Skoro dany user za danego posta dostaje plusa czy minusa to powinien wiedzieć od kogo i za co. Jeśli ktoś sobie będzie prowadził wojnę z tego powodu to już jego sprawa, ale ja chociażby wolę mieć wgląd w to kto mnie ocenia i jak. Ale jak tam chcecie... .

To jaki problem na tej domenie i na swoim VPS'ie postawić hosting? Toż to jedna komenda...

Chyba nie zrozumiałeś o co mi chodzi no ale mniejsza... P.S. Domenę masz? Nie wiem jak dotpay wygląda, ale chyba nie zezwalają na lokowanie usług na darmowych domenach, chociaż zaraz to sprawdzę...

Masz pieniądze na serwer minecrafta, a nie masz na płatny hosting, gdzie ceny wahają się do kilku dyszek za rok?

Bardzo się mylisz, mój TS z 200 active slotami zużywa dokładnie 2.5% z 2 gb ramu, a to jest... 50 mb ramu. O wiele ważniejszy w tym wypadku jest procesor, a także łącze i ilość transferu. 200 GB transferu miesięcznego starczy na mniej więcej te 32 do 50 slotów, na pewno nie więcej. Procesor też mniej więcej tyle powinien wyrobić.

Rozumiem, że nie działają pliki PHP. Co się dzieje przy próbie otwarcia? Restartowałeś usługi po zmianie configu prawda?

To ja dorzucę jeszcze jednego linka, może nie każdy czyta => http://niebezpiecznik.pl/post/nask-rozpoczyna-walke-z-botnetem-virut-i-przejmuje-jego-domeny/

Jeśli potrzebne jest Ci bardzo duże SLA to zacznijmy od tego, że jeden serwer w tym momencie z góry jest skazany na "porażkę". Zainteresuj się rozwiązaniami w chmurze albo jakąś własną redundantną infrastrukturą np. 2 serwerami w innych lokalizacjach. Ogółem takie rzeczy nie są tanie.

Jeśli chodzi o lekkie przeglądarki to od siebie tylko dodam, że na pewno nie Firefox. Ostatnie jego wersje to jakaś masakra, chyba że chcesz korzystać ze starych. Ja śmigam pod Chrome, może nie na aż tak starym komputerze, ale podobnym i problemów nie ma. Jest też wiele innych "nie mainstreamowych" przeglądarek, chociażby Safari. http://internet-browser-review.toptenreviews.com/ Nie wiem na ile miarodajny jest ten test, ale po wartościach bym się zgodził.

Również myślę, że ext4 czy wcześniej wspomniany już xfs będzie o wiele bardziej odpowiedni niż ext3.

Dedyk to dedyk. Nie wiem czego oczekujesz, dostajesz dokładnie ten sam serwer, który masz specyfikacji. Jedynymi rzeczami na które możesz zwrócić uwagę to http://pingdom.slaskdatacenter.pl , który Ci powie jak jest z SLA sieci no i do tego reakcja supportu, która z miesiąca na miesiąc jest coraz szybsza. Co byś chciał jeszcze wiedzieć? Czy i7 to i7, a nie i3? .

Musisz popytać firm o dedykowane ustawienia, raczej mało która Ci zaoferuje "w pakiecie" ochronę anty-ddos. Ewentualnie byle jaki hosting podpiąć pod np. CloudFlare i stamtąd jechać. Swoją drogą polecam.

Nie jesteś sam Kamikadze .

A ja powiem, że zarówno jedna, jak i druga firma ma moje zaufanie. Wybierz tą, której oferta Ci się bardziej podoba.

No jak to jakie, wszystkie są najlepsze .

Owszem, tylko kłóci się z Twoim podejściem do security. Jeśli skrypt sklepu może "odczytać" tak naprawdę cokolwiek z samego dedyka to już masz dziurę, która nawet dobrze zabezpieczona jednak zezwala na komunikację vhost klienta => panel. Albo robisz wszystko niezależne i dany vhost ma dostęp tylko do swoich rzeczy i w nim operuje, a panel ewentualnie może coś wyedytować (nie działa to w drugą stronę więc security zachowane), albo robisz koncepcję podobną do @nrm'a, która również ma swoje zalety i wady, ale jednocześnie stwarza ryzyko większej liczby dziur, bo w tym wypadku jednak mając dostęp do jak to mówisz "modułu" można w nim pogrzebać, nawet jak jest read only to jednak stwarzasz dziurę na poziomie wykonania dziurawego kodu => panel. Pomysłów jest dużo, musisz tylko albo nastawić się na security i sporo "roboty", może niekoniecznie stałej, ale wymagającej albo typowy model Saas, jak wspomniał nrm, który jest na pewno łatwiejszy w obsłudze, ale stwarza kilka dodatkowych zagrożeń. Wybór należy do Ciebie, zarówno jedno jak i drugie rozwiązanie ma swoje wady i zalety.

W moim przypadku każdy user ma swój katalog. Nie wiem /home/klient789/www/. Każdy folder przypisujesz pod konkretnego vhosta np. klient789.mojsklep.pl. Każdego vhosta odpalasz przez osobnego workera, który działa z prawami danego klienta. Efekt jest taki, że wszystkie requesty do klient789 są wykonywane przez klient789, więc w przypadku hacka tracisz tylko ten konkretny profil. Jeśli masz jedną aplikację, jako jakieś skrypty php czy coś takiego to jest to fizycznie niemożliwe, to znaczy jest możliwe, ale trzeba by było pisać skrypty, które oddzielają każdą stronę i na tej bazie generować statystyki. Wg mnie jest to strasznie słabe rozwiązanie i o ile taka jedna aplikacja, która ma sobie działać jest OK, to można w niej właśnie zrobić przycisk "dodaj nowy sklep", która działa dokładnie tak, jak napisałem na początku. Funkcja "dodaj nowy sklep" tworzy nowego klienta, katalog, workera i całą resztę praw dostępu, user może sobie z poziomu Twojego panelu wyedytować co tam chce, ale fizycznie pliki (czyli jego sklep) nie są odpalane przez roota, a przez konkretnego workera.

Powiem tak... Po pierwsze jeśli to jest dziura "w skrypcie" to tak czy siak skoro wszystko będzie jechać na tym samym to i wszystko polegnie, nie masz na to wpływu. Po drugie jeśli chodzi o maszynę to dobry administrator załatwi takie podstawowe rzeczy jak jaile, IDS'a, NIDS'a, kontrolę zasobów i milion innych rzeczy, które będą specjalnie przygotowane pod tą aplikację. Mówisz o włamaniu - Obecnie trzymam na własnym serwerze każdego usera "osobno", pomimo że jest to jeden serwer. Co mam na myśli? Ano to, że każdy user jest zamknięty w JAIL'u w swoim home, ma dostęp jedynie do SFTP, a na jego koncie odpalona jest instancja (worker) nginxa + php-fpm. Dodatkowo user ma dostęp do bazy danych, a konkretniej jedynie swojego usera i swojej bazy. Efekt? W przypadku przejęcia nawet wszystkich tych rzeczy nie ma opcji dostępu do reszty serwera, z jaila nie ma opcji wyjść, do tego grsecurity & pax + CSF i parę dodatkowych autorskich skryptów przykłada rękę do tego, żeby wszystko działało zgodnie z przeznaczeniem. Limity CPU, RAM'u etc są przydzielane per-user, a poszczególni workerzy są również z danego usera odpalani. Przypominam, że jest to jeden serwer dedykowany i nic poza tym, żadnej wirtualizacji.

Jeśli chcesz się pobawić to możesz Webminowi kazać nasłuchiwać tylko po 127.0.0.1, a przed nim postawić jakieś proxy np. nginx'a. Dzięki czemu tu masz już duże pole do popisu w kwestii zabezpieczeń (Basic auth, naxsi itp.), tylko pamiętaj że trzeba to zrobić z głową, bo jeżeli masz jakiś override ignore na 127.0.0.1 to dostaniesz efekt odwrotny od zamierzonego. Poza tym jak zawsze można się pobawić z iptables, IDS'em, NIDS'em i całą resztą.

P.S. W swoim profilu nadal można zobaczyć kto przydzielił danemu userowi punkciki. Abuseee... .

Opcja braku podglądu reputacji jest wg mnie złym rozwiązaniem. Można usunąć podgląd minusów, ale plusy bym zostawił.

a) Do monitoringu mojego serwera używam 2 wewnętrznych aplikacji i 2 zewnętrznych. Jest to odpowiednio Munin do kontroli wszystkich zasobów z poziomu serwera oraz parę monitor checków z Webmina. Jeśli chodzi o zewnętrzne to przede wszystkim jest to Pingdom (do samego stanu usługi) oraz OVH'owski RTM (i inne checki np. HTTP check). Efekt jest taki, że w przypadku złego smarta krzyczą mi już 3 alerty, w przypadku zwisu jakiejś usługi krzyczą mi 2 alerty, a jeśli serwer umrze całkowicie daje znać RTM oraz Pingdom. b) Panelów GUI do zarządzania nie lubię, ale ułatwiają sprawę i mam je głównie do możliwości executowania przez osoby trzecie skryptów, bez fizycznego dostępu do maszyny. Tutaj polecam Webmina, głównie przez to że jest darmowy, ale także przez to, że nie modyfikuje żadnych usług "na sztywno". Mam tu m.in ma myśli to, że niektóre usługi są wręcz uzależnione od panelu i bez niego poprawnie działać nie będą. c) RAID1 to must be dla każdego serwera produkcyjnego. W przypadku gdy jakiś feralny dysk przestanie działać to możesz go odbudować bazując na drugim. Tu oczywiście istnieje ryzyko, że padnie "wszystko", ale głównie jest to bezpieczne rozwiązanie. Na jednym z moich serwerów stosuję technikę, która można powiedzieć jest dopiero w stanie pracy . Składa się to z 1 dedyka i 1 chmury. DNS'y kierują odpowiednio na chmurę (primary) i na dedyka (secondary). Chmura odsyła usera na dedyka, ale jeśli dedyk z jakiś powodów umrze (ping będzie timed out przez minimum 2 minuty) to w tym momencie przez API automatycznie odpalana jest już druga specjalnie przygotowana chmurka, która ma aktualnie zapisane dane i przejmuje "działanie". Jeśli chmura #1 wykryje, że dedyk ponownie działa to kieruje ponownie userów na dedyka i po 5 minutach wyłącza chmurkę #2. W przypadku gdy załóżmy chmurka by nawaliła mamy secondary DNS sztywno na dedyku i niski TTL, przez co wciąż usługi są dostępne. Oczywiście co 24h chmurka #2 jest odpalana i dostaje nowe dane bezpośrednio z dedyka, a po zakończeniu syncowania po prostu się wyłącza. Jest to mocno "średnie" rozwiązanie ponieważ taki DNS failover ma swoje wady, ale z kolei zaletą jest to że położenie takiej infrastruktury jest możliwe tylko i wyłącznie gdy umrą obydwa serwery, a to z kolei jest tak jak z raidem1 . Do tego minimalizuje koszty bo tak naprawdę mamy tutaj wyłącznie koszt jednej, najtańszej chmury + extra koszty chmury #2, która jest włączana na 1h codziennie + jak dedyk odmówi posłuszeństwa.