trustnet

Smarthost.pl to nowoczesny i zautomatyzowany system hostingowy opierający się na sprawdzonych rozwiązaniach w zakresie zarządzania usługami. Regularna opieka administratorów, szybkie dyski SSD w macierzach RAID i regularne kopie bezpieczeństwa zapewniają bezawaryjne działanie Twojej strony internetowej. Wszystkie konta hostingowego chroni unikalny system anty-exploitowy, który chroni większość popularnych skryptów php przed włamaniami. Nasza oferta to: - hosting współdzielony, - rejestracja domen, - certyfikaty SSL, - serwery vps. Nasze atuty: - własna serwerownia, serwery w Polsce, - szybkie dyski SSD, - bezpieczny system CloudLinux, - wygodny panel zarządzania cPanel po polsku, - samodzielna zmiana wersji PHP (w tym PHP 7.0), - najnowsze wersje oprogramowania, - oprogramowanie anty-exploitowe skanujące kod witryn w locie, - działamy na rynku od kilkunastu lat, - bezpłatny 14 dniowy okres testowy. Parę faktów o nas: Smarthost.pl to firma zatrudniająca na etacie kilkunastu stałych pracowników. Większość z nich to dyplomowani informatycy po studiach kierunkowych. Smarthost.pl to firma działająca od kilkunastu lat na rynku, od początku zajmująca się hostingiem. Smarthost.pl to własna serwerownia, nie korzystamy z wynajmowanego datacenter "gdzieś". Nasze serwery w kilku szafach rack są zawsze pod ręką. Smarthost.pl to firma obsługująca na chwilę obecną kilka tysięcy Klientów z całej Polski i z Europy. Smarthost.pl to firma obsługująca zarówno duże portale jak i małe jednoosobowe firmy. Smarthost.pl to automatyczny hosting współdzielony, vps i dedykowany ale również zarządzanie serwerami w imieniu naszych Klientów.

zajrzyj do katalogu /var/log ... Wojtek

no właśnie, jak ktoś kupuje vpsa za 30 zł to sorry, ale nie znam przypadku, żeby płacił za "admina" 300 zł miesięcznie. Natomiast jak ma dedyka za 500-1000 zł miesięcznie, to zapłaci 300 za admina. Ale w nocy to taki klient śpi, a nie dzwoni z problemami. Znowu moje doświadczenie: pytanie: za ile mi zmienicie wersję z 5.2 na 5.3 (bo oto płatne dodatkowo, bo nie mieściło się w ramach "administrowania"). Dostał dwie wyceny: 1. robimy na żywca - między np. 1.00 a 3.00 w nocy, ale musimy mieć kogoś od klienta, żeby posprawdzał, czy mu wszystko działa poprawnie (na pewnie działa, bo dostał serwer testowy - sprawdził - wszystko śmiga). Ale ponieważ nie mam dostępu do jego paneli to niech sprawdzi sam w okienku serwisowym - cena powiedzmy 500 zł 2. zmienia serwer na wyższy/nowocześniejszy (+200 zł miesięcznie) i stawiamy drugi serwer i sobie powoli przenosi dane przy naszej asyście. W dowolnym momencie - raczej za dnia. i to niech kosztuje np. 1000 zł extra, bo przez np. miesiąc będzie miał dwa serwery. I klient co wybrał ? ... rzucił hasło: no przecież nie będzie z nami w nocy siedział i sprawdzał :-) I taki klient jest normalny. Ja ze swojej strony już spędziłem parę nocy w serwerowni - ale nigdy (10 lat) nie było to wymuszone przez klienta.

Dokładnie - ja też tak robię. Klient ma telefon do mnie (komórkę) i telefon do biura w godzinach pracy biura. Niektórzy klienci mają też komórkę do głównego admina (ale na to trzeba zasłużyć finansowo) :-) I naprawdę baaaaardzo rzadko się zdarza, żeby klient dzwonił z pierdołami o 21.00. Raczej telefony są w normalnych godzinach (8-16). Przecież jak ktoś płaci np. 200-300 zł za administrację serwerem to najczęściej płaci też troszkę więcej za hosting - przez wejście na poziom takich cen jest normalny, a nie jakimś pieniaczem. Oczywiście są sytuacje ekstremalne, ale w sumie po to właśnie jest taki admin. A i tak większość rzeczy jest załatwiane mailem.

Generalnie lepiej mieć admina pod telefonem. Podczas intensywnego działania w sieci zawsze znajdzie się jakiś mail, którego wytnie antyspam i trzeba go pilnie odszukać. To oczywiście niby banalne przypadki, ale jak to jest WAŻNY mail, na którego się czeka, to zawsze lepiej zadzwonić do admina, żeby sprawdzić co się z nim stało. To tak na szybko.

No właśnie, ale jak to się stanie ? trochę problem ... problem głównie dla innych na tym samym serwerze. Dlatego wolałbym jednak automatem ograniczyć. Oczywiście to musi być sensowne ograniczanie, np. ubijanie procesów powyżej jakiejś ich liczby - co na wielu serwerach współdzielonych jest. Ubija to procesy tego klienta który przekracza - zatem część jego klientów widzi poprawnie stronę, a część nie. Ale wszyscy inni na tym samym serwerze nie są zagrożeni ;-) Oczywiście tak jak pisałem wcześniej samo np. blokowanie po przekroczeniu transferu jest błędne.

Stawiałbym tezę, że pewnych rzeczy nie da się przewidzieć. Kliencie czasem się nieprzewidywalni. Miałem już przypadki gdzie ktoś odpalił coś co spowodowało tyle wejść na stronę (na której były duże dane typu np. generowane w locie fotki) i serwer nawet mający zapasy mocy nie jest w stanie tego przeżyć. Technicznie - klient nie przekroczy transferu (bo jest to np. chwilowe zatem zmieści się), ale serwer dostanie np. loadu 20-100 i foldery imapa innych klientów będą się synchronizowały wieczność, bo za jeżdżeniem po bazie, poleci moc procesora i ostatecznie odczyty/zapisy na dysku. I tego nie da się przewiedzieć, Miałem już takie przypadki, np. nowa galeria fotografii z podróży bardzo znanej aktorki serialowej - poparte newsletterem, że "już są" ... Dlatego jestem za limitowaniem pewnych rzeczy - niech Klient też trochę myśli, co się stanie ... ale inni klienci mają stabilność i nie zauważają problemu.

Myślę, że zależy jakie limity - limit transferu: raczej nie, bo faktycznie klient może nie wiedzieć, że przekroczy, ale limit pojemność: jasne, że tak - to się nie zmienia z minuty na minutę. Limit procesora/pamięci - tak, z bardzo prostego powodu - jak ktoś zrobi większe obciążenie "niby "chwilowo" - to jak wytłumaczyć innym, że tamten inny miał "chwilowo" a oni _teraz_ poczty nie mogą odebrać ...

1. na hostingu współdzielonym nie zmienia się ścieżki do vhosta poza obręb wirtualki klienta 2. nawet jakby się zmieniało, to trzeba by zmienić ustawienia dla całego konta, a tego też się na hostingu współdzielonym nie robi. 3. konta/domeny nie podpina się pod cokolwiek innego niż standard, bo potem przy upgrade serwera trzeba o tym pamiętać i pilnować kilkadziesiąt/kilkaset niestandardowych zachowań.

Sprawa nie jest taka prosta, bo na serwerze współdzielonym jest w zasadzie jeden plik php.ini globalny i ew. użytkownicy mogą sobie pewne funkcje zmieniać w lokalnych php.ini albo w .htaccess. Oczywiście jest tak, że jak globalnie jest coś ustawione to możesz sobie to zmienić lokalnie. Ale to lokalnie. Globalnych ustawień na serwerze z kilkuset kontami nikt nie zmieni dla jednego klienta. Szczególnie, że większe firmy mają wiele serwerów z jednakową konfiguracją (albo dobraną z czasem, albo wynikłą z zaszłości). W każdym razie jak ktoś będzie pytać to oni wiedzą jak mają skonfigurowane serwery, bo wszystkie jednakowo i standardowo. Niemniej przede wszystkim pytanie jest o sens konfiguracji tj. blokowania niektórych funkcji - chcesz kupić serwer i potem komuś go dać do zarządzania/programowania www ? Trochę dziwne. W sumie jak sam robisz strony, to po prostu nie używaj funkcji, które chcesz zablokować. A jak komuś, to nawet jakby lokalnie dało się je zmienić, to i tak ten ktoś, kto ma dostęp mógłby sobie zmienić je znowu Generalnie musisz poszukać serwera, gdzie te funkcje będą globalnie zablokowane.

Witam, borykamy się (bardziej w ramach ciekawostki, niż realnego problemu, bo wiemy jak poprawić skrypt) z takim problemem: jest skrypt, który czyta pliki z katalogu i je includuje, skrypt wygląda tak: if( is_dir($dir) ){ if($handle = opendir($dir)) { while (false !== ($file = readdir($handle))) { echo $dir .''. $file.' '; } closedir($handle); } } Ten skrypt działa bardzo ładnie na hostingu opartym na cPanelu działającym na CentOS-oe 5.8 Taka sama konfiguracja serwera, też na cPanelu, kompilacja tych samych wersji oprogramowania (apache, php, mysql) ale na CentOS-ie 6.2 powoduje, że wczytuje się tylko 10 pierwszych plików i proces się przerywa. Nie ma żadnych błędów w logach. Jakie macie doświadczenie, z nowym CentOS-em 6.x i co jest w nim takiego, że "nie działa". Może ktoś wie? Wojtek

Odpowiadam sam sobie bo sprawa jest rozwiązana. Różnica w CentOS 5.x a 6.x to system plików. W wersji 5.x było ext3 a w wersji 6.x jest proponowany domyślnie ext4. Funkcja php readdir() wg dokumentacji PHPczyta wg ich kolejności w filesystemie (in the order in which they are stored by the filesystem). Co ciekawe kolejność jest zawsze taka sama (sprawdzane na 4 różnych serwerach) - niezależnie od kolejności wgrywania plików. Druga ciekawostka: na systemie plików ext3 i ext4 kolejność jest stała, ale na każdym z systemów plików inna. Czyli podejrzewam, że ma to coś wspólnego z inodami, ale to już nie wnikam. Tak czy inaczej problem mi się rozwiązał Wojtek

tak, jest, wyłączony: root@michael [/home/wojtek]# cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. # SELINUXTYPE=targeted

Tak, to na 99,9% kwestia CentOS-a. Początkowo problem wykryliśmy na CloudLinuksie. Żeby wyeliminować hacki i blokady CloaudLinuksa postawiliśmy kilka wirtualek na CentOSie. Kompilacja jest identyczna w każdym przypadku - to jest cPanel, zatem łatwo zrobić powtarzalną kompilację i konfigurację. Identyczne php, apache, moduły. wersje te same php.ini identyczny. Uprawnienia też są na pewno poprawne. Też mnie to zdziwiło, ale na pewno problem jest w CentOSie 6.x - może ktoś ma hosting na nim - chętnie przetestuję, czy skrypt działa ?

z netem to jest tak, że tanieje. Ale dojście nie tanieje. Zatem może być tak, że te 50 Mbps będzie kosztowało mało, ale, żeby je przepchnąć potrzebujesz np. radiolinię na pasmo licencjonowane np. 38GHz i wtedy takie radio np. Ceragona kosztuje ok 13-15 tys netto. Czyli jak jest kontrakt na 24 miesiące to wychodzi ci niecały 1000 zł miesięcznie za dzierżawę. Oczywiście operatorzy będą mieli dla siebie lepsze ceny w Ceragonie, ale nie muszą ci tego mówić, a poza tym płacą za wysoką dostępność zamienników w razie awarii. Do tego często muszą wynająć miejsce na maszcie/kominie - dobrze jak tylko po jednej stronie a nie po dwóch. Zakładam, że miejsce pod antenę będzie kosztowało ok 500-600 zł netto miesięcznie. To też doliczasz do kosztów klientowi. Pasmo licencjonowane zakładając 38GHz i pasmo 50Mbps łącza zmieści się na kanale niewielkiej szerokości - w miesieście >100tys mieszkańców to koszt ok 2000 zł rocznie + opłata przyłączeniowa 2000 zł netto. to też leci na klienta. No i handlowiec musi coś zarobić. I stąd się biorą ceny pomimo, "taniego internetu". On jest najczęściej tani, jak sobie go sam odbierzesz w węźle wymiany danych np. w PLIX-e. Ale stamtąd wiaderkami go nie przyniesiesz :/ Wojtek

no wiesz ... czasem się zgłaszają firmy, które chcą duży portal, taki z funkcjonalnościami jak allegro, albo gazeta.pl i mają budżet koło 5 tys :-) To oczywiście skrajność. Trzeba by zdefiniować co to jest duży portal. Natomiast raczej nikt na starcie nie jest taki duży, że potrzebuje tyle maszyn. Nawet jak np. ebay jak wchodził do Polski to był niby "duży", ale nie sądzę, że na początku mieli jakiś ruch wymagający super-hiper wydajności. Wiadomo, że z czasem jak się rozwinie ... to tak ... ale nie na początku

Pytałem już jakie rozwiązania są używane co do PHP na hostingach. Wielu polecało fastCGI. Które realnie hostingi mają na pewno u siebie fcgi ? Pytam, bo mam u siebie zainstalowane i jest problem z przekazywaniem zmiennych PHP m.in fastcgi brakuje paru zmiennych środowiskowych jak PATH_INFO. dotyczy to m.in. stron zbudowanych na frameworku Kohana w wersji 2 i 3. I chciałem obejrzeć na jakich serwerach działa fcgi i czy ten problem przekazywania zmiennych jest jakoś rozwiązany czy po prostu też nie działa Wojtek

Z praktyki: projekt programistyczny warty 10-15tys powinien stanąć na serwerze za ok 500-700 zł. Zakładam, że to rozbudowany sklep z dużą liczbą niestandardowych rozwiązań. Takie przyjąłbym przelicznik cenowy (cena kodu = ok 2 lata hostingu tego kodu). Bez sensu jest stawiać "gotowca" np. na jakimś cmsie wdrożonym przez kogoś tańszego niż 5-10tys na 2 serwerach dedykowanych po 1000 zł każdy. Samo rozbicie usług na serwery będzie wymagało pracy w sensownym oprogramowaniu tego, już nie mówiąc o sprawie wydajności. Stawianie Wordpressa, czy innej joomli, a nawet typo3 pod "wielki portal" wymagający 3 serwerów nie ma sensu. A rozwiązania dedykowane i _skalowalne_ nie kosztują znowu 5 tys, tylko dużo więcej. Zatem jestem nadal za: dobrym kodem i mniejszą ilością serwerów ;-) uzupełniajac: cena 500-700 zł to miesięcznie oczywiście.

no właśnie chodzi jednak nie o serwery, a o programistów .... brutalna prawda, ale programista programista może wykończyć każdą maszynę ...

taaa, a od programistów najczęściej nie można odliczyć VAT-u zatem wszystko jasne, gdzie jest wąskie gardło i co jest kosztowne

To jeszcze dorzucę jeden przykład: jak będzie dużo fotek, to zwróć uwagę na taki "detal" jak ich umieszczenie. Miałem już serwer z portalem, gdzie nikt nie wiedział, czemu "wolno działa". Próba wydania komendy "ls" w katalogu z fotografiami powodowała zwis konsoli na 3-4 minut. plików było prawie pół miliona w jednym katalogu ....

Z mojego doświadczenia działa to tak: Jak nie budujesz drugiego onetu, to często nie będzie potrzeby stawiania kilku serwerów: mam doświadczenie z kilkoma dużymi portalami w skali Polski i mogę zaryzykować stwierdzenie, że w większość przypadków wystarczy jeden serwer. Ten serwer nie powinien to być jednak wrak i zabytek, ale coś nowoczesnego (tutaj znaczenie będą miały takie parametry jak raid sprzętowy, wydajne dyski np. SAS, szybki RAM - rzeczy banalne, ale często niedoceniane pod względem wydajności). Większość problemów z dużymi portalami to problemy, powiedzmy ogólnie, "programistyczne" a nie sprzętowe. Spotkałem się już z bazą gdzie tabele miały po 400milionów rekordów i podejście było, że tylko Oracle to łyknie na klastrze serwerów (przy dużym obciążeniu), a potem okazało się, że postgres z poprawną optymalizacją zapytań, indeksów, klastrowaniem itd i śmiga aż miło na pojedynczej maszynie. Niemniej to wymagało dużo pracy. Zatem bardziej bym się skupił na budowie tego portalu a nie na sprzęcie. Bo programiści to czynią cuda czasem (szczególnie tacy od php+mysql ;-) ). Trzeba zwrócić uwagę na cachowanie na wszelkie możliwe sposoby, optymalizację zapytań. Najlepiej wybrać agencję, która będzie to stale obsługiwała i np. zaproponuje też rozwiązania serwerowe - skoro Ty - jak piszesz się na tym nie znasz. Bo inaczej możesz kupić coś, za co zapłacisz "jak za zboże" a i tak może być niewydajne, bo aplikacja to wykończy. Tym powinien zająć się ktoś (w sensie firmy), kto to będzie tez obsługiwał i za działanie odpowiadał :-)

Tak się zastanawiam co robią inni - dzisiaj na jednym z serwerów hostingowych zwiększyłem czas łapania do slow-loga MySQLowego i dodałem opcję, żeby mi łapał nie tyle wolne zapytania, co zapytania bez indeksów. W ciągu dwóch godzin było ich: # cat /var/log/mysql/mysql-slow.log |grep "use " |wc -l 16686 trochę dużo nie uważacie ? Co robić z takimi userami ? W sumie pakiety hostingowe nie maja nigdzie zapisów, że nie wolno używać zapytań bez indeksów. Ci użytkownicy w sumie też nic nie przekraczają ... ale jednak obciążają znacznie serwer MySQL. Co Wy robicie ? Wojtek

Właśnie ku takiej odpowiedzi się skłaniam - tylko teraz: czy faktycznie tak robią inni ? To już dopytuje się z ciekawości. Wojtek

Tak, to niby oczywiste, ale czy pokazanie klientowi, że ma zapytania do bazy bez indeksów jest gdzieś zapisane w regulaminie, że "tak nie wolno" ? Rozumiem, że zawsze można niby powiedzieć "że obciąża i już" - ale jednak żadnych formalnych "limitów bezpieczeństwa" - jak to ładnie wszyscy nazywają - nie przekracza. Dlatego pytam bardziej o "umotywowanie" a mniej o kwestie techniczne shared > vps Wojtek