megi

Zróbcie porządek z blogami - to co jest teraz nie zachęca ani do czytania, ani do pisania. Firmy chcące lansować się na forum mogłyby być zainteresowanie wnoszeniem od siebie jakiejś treści, mogłoby to częściowo załatwić kwestię howto. Gdyby wszystkie wpisy były otagowane, podzielone na tej podstawie na kategorie, łatwo dało się je przeglądać, to na pewno każdy znalazłby coś do poczytania dla siebie. Jeżeli będą czytelnicy i będzie dla kogo to pisać to chętni do do pisania też się znajdą.

Samo wiki napisane jest w Haskellu. Wiele wynalazków już mamy ale Haskella jeszcze nie, więc zapraszam do nas http://www.megiteam....g-wspoldzielony Opcja S powinna wystarczyć. Git i Mercurial są standardowo, nie pamiętam czy LaTeX jest zainstalowany - jeżeli nie, to go doinstalujemy. Lubię takie nietypowe rozwiązania to pomogę Ci to uruchomić. A jak się już uda to odpalić to będziesz mógł się zgłosić do konkursu http://www.megiteam.pl/blog/2011/5/19/konkurs/

Dlaczego ktoś miałby bezproblemowo przyjmować "fekalia" wysyłane przez klienta? Takiemu klientowi bez zbędnej dyskusji dziękuje się za współpracę a nie toleruje jego zachowanie. Obydwie strony powinny pamiętać, że na drugim końcu kabla siedzi człowiek i należy mu się szacunek. Szacunek trzeba mieć też do siebie i swoich pracowników i nie pozwalać na takie traktowanie.

Repozytorium jest w postaci binarnej, nie masz tam plików jak w kopii roboczej. Jeżeli chcesz zobaczyć pliki to musisz zrobić checkout czyli stworzyć kopię roboczą. Jeżeli chciałbyś z tego repo uruchamiać aplikację to oprócz repo na serwerze musisz mieć też kopię roboczą czyli masz centralne repo, na desktopie kopię roboczą i drugą na serwerze, lokalnie sobie dłubiesz, commitujesz zmiany do centralnego repo i w post commit hooku robisz svn update w kopii roboczej na serwerze. Wiem, że to mało popularne, ale zacznij naukę od przeglądnięcia dokumentacji - zaoszczędzi Ci to sporo czasu

IMHO to należy czytać tak: Też nie rozumiem To jest ustawa a nie wprowadzenie do logiki. Ustawy mają to do siebie, że bywają pisane przez oderwanych od pługa ekspertów. Interpretacja, że polską ustawę stosuje się do "polskich obywateli i firm" (skrót myślowy) oraz pod pewnym warunkiem również do niepolskich obywateli i firm, jest IMO dość naturalna. Jeżeli się z tym nie zgadzasz to rzuć linkiem do innej interpretacji.

Bo szukasz nie tam gdzie trzeba... Z ustawy o ochronie danych osobowych: Innymi słowy nie ważne pod jaką domeną masz serwis, ważne, że jako administrator danych osobowych mieszkasz w Polsce. A czy podlegasz obowiązkowemu zgłoszeniu do GIODO to już zależy od tego, czy nie zachodzi któraś z przesłanego zwalniająca z obowiązku rejestracji (opisane tutaj https://edugiodo.gio.../view.php?id=17). GIODO prowadzi platformę eduGIODO, gdzie można znaleźć wiele informacji na temat ochrony danych, obowiązków ADO, rejestracji zbiorów itp. https://edugiodo.giodo.gov.pl/ - polecam. Jako administrator danych osobowych masz obowiązek zabezpieczyć je przed dostępem osób nieupoważnionych. Administratorzy firmy hostingowej zazwyczaj do danych utrzymywanych na ich serwerach mają dostęp - z punktu widzenia ustawy są to osoby nieupoważnione. Chcąc w zgodzie z prawem przetwarzać dane osobowe na hostingu musisz mieć z firmą hostingową umowę powierzenia przetwarzania danych osobowych w celu świadczenia usług hostingowych. Dodatkowo, jeżeli swój serwis utrzymujesz na hostingu w kraju poza UE, to *prawdopodobnie* podpada to pod transfer danych osobowych do państw trzecich i musisz mieć pewność, że w tym kraju gwarantuje się co najmniej taką samą ochronę danych osobowych, jak w Polsce.

Na to pomoże zwiększenie liczby workerów. Nginx blokuje się na dostępie do dysku i zajęty worker nie obsłuży innego żądania dopóki nie przeczyta pliku z dysku.

Dodaj do Apache mod_status i skonfiguruj jak tutaj jest opisane http://httpd.apache....mod_status.html Pod URI /server-status/ będziesz miał informacje o połączeniach w danej chwili. Na tej podstawie powinieneś móc namierzyć co tworzy tyle połączeń. Poza tym to postaw z przodu nginxa, niech serwuje pliki statyczne a do Apache proxuj tylko odwołania do PHP - powinno Ci odciążyć serwer.

Opcja -c /ścieżka/do/php.ini to opcja dla /usr/bin/php5-cgi, a w sposób jaki to uruchamiasz ta opcja przekazywana jest do spawn-fcgi. Spawn-fcgi też ma opcję -c ale robi ona zupełnie co innego. Spróbuj: -f "/usr/bin/php5-cgi -c /etc/php5/cgi/php2.ini"

Nie myśl o nginxie jako innym apache'u. Nginxa zbytnio nie interesuje co tam po drugiej stronie słucha i do czego on przekazuje żądania. Nginx jest "tylko" serwerem http - samodzielnie serwuje pliki statyczne, odwołania do php przekazuje do "serwera" aplikacji. Jak musisz zmienić jakieś ustawienia php to nie w nginxie. Możesz to zrobić albo na poziomie aplikacji albo w php.ini. W jaki sposób uruchamiasz php? Przez php-fpma? Może da się na przykład uruchomić tę jedną aplikację z innym php.ini? P.S. My uruchamiamy php w konfiguracji nginx na froncie jako serwer plików statycznych i proxy dla apache uruchomionego na prawach użytkownika jako serwera php (mod_php). Działa całkiem, całkiem a odpada problem z rewritami i .htaccessami. Może i u Ciebie się sprawdzi?

Ogólnie masz racje, pod warunkiem, że zmienia przekierowanie a nie delegację domeny, o czym inni w tym wątku wspominali. TTLe dla rekordów NS są w NASKu. Jeżeli autor ma DNSy w Home to niekoniecznie będzie miał możliwość zmiany TTLi rekordów, ale plan jest dobry.

@JarekMk Poradziłeś sobie?

W nazwie w abonamencie masz 2 miliony sekund CPU rocznie. O ile dobrze liczę to wychodzi ponad 6% pojedynczego procesora (rdzenia). Nie jest to mały limit jak na hosting współdzielony. A czy ci wymagający klienci chcą też płacić czy tylko wymagają? Z tego co wiem w nazwie jest tak (niech mnie ktoś poprawi, jeżeli jest inaczej) , że można czas CPU wykorzystać wcześniej i skracany jest okres abonamentowy. Klient dostaje więc więcej mocy ale za wyższą cenę. IMHO rozsądne podejście.

Twoje porównanie jest nietrafione. Porównujesz root VPSa w Linode, gdzie zainstalowanie i skonfigurowanie oprogramowania, późniejsza administracja jest na Twojej głowie, z usługą u nas w której dostajesz gotowe środowisko, panel administracyjny, support, nie zajmujesz się administracją, chociaż masz możliwość doinstalowania dodatkowego oprogramowania (wspomniane mono). Po drugie w Linode na VPSie opartym na Xenie w pamięci musisz zmieścić *cały system*, w tym kernela, który dla siebie również potrzebuje pamięci; musisz uwzględnić page cache - nie wykorzystasz pamięci co do megabajta, bo inaczej odczyt z dysku zabije Ci ten serwer. My do zajętej pamięci wliczamy tylko procesy uruchomione z uidem użytkownika np. Railsy, Django (na współdzielonym) + serwer baz danych (na VPSach, które mają własne serwery baz). Nie wliczamy systemu ani reszty oprogramowania, które sprawia, że wszystko działa. Innymi słowy porównujesz dwie nie mające nic wspólnego usługi. Nie przesadzaj Jeżeli ktoś szuka root VPSa (my ich akurat nie oferujemy) to myślę, że wśród polskich firm również znajdzie ciekawe oferty. Natomiast klienci, którzy nie chcą zajmować się administracją, dla których ich czas jest kosztem (Ty tego nie wliczasz do ceny VPSa) poszukują gotowych rozwiązań i dla nich jest oferta nasza i wszystkich firm oferujących hosting współdzielony i dedykowany. EDIT Dopiszę jeszcze, że jeżeli - jak piszesz - pod względem zajętej pamięci mono jest lżejsze niż python to przy naszym rozliczaniu prawdopodobnie wystarczy Ci najmniejsza opcja z oferty hostingu współdzielonego. Jeżeli potrzebujesz większych parametrów a nie zależy Ci na lokalizacji w Polsce to w naszej ofercie VPSów za 30 zł netto miesięcznie jest VPS z 256 MB pamięci w OVH. Dla podkreślenia: pamięć w ofercie to pamięć na procesy użytkownika + bazy na VPSie.

Obawiam się, że nie będzie w tym temacie lawiny ofert, bo prawie żaden hosting w Polsce nie oferuje niczego więcej niż PHP. Node.js wdrożyliśmy ostatnio w MegiTeam, reszta z wymaganych rozwiązań jest u nas "od zawsze"

Hej Nginx blokuje się na odczycie z dysku tzn. ze dany worker nie obsłuży innego żądania dopóki nie przeczyta pliku. Ile masz workerów? Ustaw 2-4x tyle co CPU. Jeżeli masz wystarczająco pamięci to pliki tak czy siak idą z pamięci - ostatnio czytane pliki trzymane są w page cache'u. Wpisz free w konsoli i zobacz ile masz zajętej pamięci i ile z tego zajmuje cache. W przypadku serwowania staticu taki loadbalancing, jaki masz (losowe rozkładanie ruchu pomiędzy serwery), wcale nie musi być dobrym pomysłem. Gdybyś serwował stały content z każdego serwera (zakładając, że sieciówka wyrobi) to miałbyś mniejszy przemiał w page cache'u.

Wybacz OT, ale obawiam się, że na podstawie podanych przez Ciebie danych nikt nie oszacuje jakie obciążenie będzie generował Twój serwis. 20K zapytań do bazy, ale jakich? Nie trzeba wiele zapytań, żeby zabić bazę. 10 - 60 s. wykonuje się skrypt, ale to zapewne czas zegarowy, nic nie mówi o wykorzystaniu CPU. Wszystko wyjdzie w praniu i zawsze jest ryzyko, że usługodawca za generowane obciążenie nie tyle będzie chciał Cię wyrzucić, co zaproponuje inną ofertę.

Gwoli ścisłości to jeżeli uruchamia sudo /etc/init.d/php-cgi start to skrypt /etc/init.d/php-cgi jest uruchamiany na prawach roota i o to kafiemu chodziło (tak przynajmniej rozumiem jego wypowiedż), natomiast to co ten skrypt robi, z jakim uidem odpala procesy PHP to już zależy do tego co w tym skrypcie jest i tu pytanie o źródło. @dudeks Jak przestaje działać forum to się zaloguj do shella i sprawdź czy nadal masz te procesy PHP uruchomione (ps aux). Inna sprawa jak są uruchomione, ale nie obsługują żądań (może masz ich za mało?) a inna jak znikną (coś je ubiło? wysegfaultowały się?).

U nas (MegiTeam) każde konto ma własnego Apache uruchomionego na prawach użytkownika. Używamy go do PHP w konfiguracji nginx jako serwer plików statycznych i proxy dla Apache, który obsługuje odwołania do PHP. Jeżeli czujesz się na siłach skompilować sobie samodzielnie mono i mod_mono to nie ma przeszkód, żebyś to sobie u nas uruchomił. Każde konto ma pełny dostęp do konfiguracji swojego Apache więc możesz załadować moduł ze swojego katalogu domowego. W razie problemów pomogę Ci z kompilacją i konfiguracją. Na hasło WHT jest 50% zniżki na pierwszą płatność, BTW. Co w Pythonie hostujesz na Home? Jakieś skrypty CGI czy coś większego typu Django?

Jaką wersję PHP kompilujesz: najnowszą stabilną czy rozwojową? Co krok po kroku zrobiłeś od momentu rozpakowania źródeł? Mam nadzieję, że _nie_ zrobiłeś tego: svn co http://svn.php.net/repository/php/php-src/trunk/sapi/fpm sapi/fpm

Kluczowy fragment - brakuje Ci biblioteki libltdl. Jak się paczka z tą biblioteką w Debianie nazywa to wierzę, że sam znajdziesz

Kompilujesz świeże źródła, czy już coś tam walczyłeś według tych nieaktualnych opisów? Jeżeli to drugie to usuń to i rozpakuj od nowa. Ten błąd związany jest z wersją autoconfa (było o tym w tym opisie zalinkowanym przez Kamikadze). Jeżeli po uruchomieniu na świeżych źródłach nadal go masz to zrób tak, jak było w tym opisie (akapit "Przygotowanie autoconf i autoheader"). U mnie się nie pojawia, ale ja mam starego Debiana. Odnośnie wyższości kompilacji ze źródeł nad gotowymi paczkami (lub odwrotnie) to zgadzam się z malu, że samodzielna kompilacja daje dużą swobodę. Dla mnie admin, który nie potrafi czegoś skompilować ze źródeł jest upośledzony, ale nie każdy musi mieć zacięcie administratorskie. Jeżeli GyniO chcesz mieć PHP ale nie walczyć z kompilacją to instaluj z paczek jak radzą koledzy. Tak samo jak zainstalował :> W najprostszym przypadku configure i make może wrzucić do pliku i później tylko ten plik uruchomić.

Ten opis nie jest już aktualny - od wersji 5.3.3 php-fpm jest już dostarczany razem z PHP, nie trzeba samodzielnie patchować, a od 5.3.4 nie korzysta z libevent. @GyniO Ogólnie kompilacja sprowadza się do dodania opcji --enable-fpm do configure Przykład, który należy traktować jedynie jako sugestię (części rozszerzeń możesz nie potrzebować, możesz chcieć zmienić prefix): z usera w katalogu ze źródłami: $ ./configure --prefix=/usr/local/php5.3 --enable-fpm --with-pgsql=shared \ --with-zlib=shared --enable-dba=shared --enable-bcmath=shared --with-bz2=shared --enable-calendar=shared \ --with-curl=shared --enable-exif=shared --enable-ftp=shared --with-gd=shared --with-gettext=shared \ --enable-mbstring=shared --with-mcrypt=shared --with-mhash=shared --with-mysql=shared --with-mysqli=shared \ --with-openssl=shared --enable-pcntl=shared --with-pdo_mysql=shared --with-pgsql=shared --with-pdo_pgsql=shared \ --enable-shmop=shared --enable-soap=shared --enable-sockets=shared --with-xsl=shared --with-xmlrpc=shared \ --enable-wddx=shared --enable-zip=shared --enable-fileinfo=shared --with-jpeg-dir --with-png-dir --with-zlib-dir \ --with-freetype-dir --enable-sqlite-utf8 --with-libxml-dir $ make z roota (chociaż z innym prefixem to i z nieuprzywilejowanego użytkownika można byłoby to zainstalować): # make install Jeżeli przy konfiguracji pojawią się błędy typu "nie ma pliku cośtam.h" to musisz doinstalować odpowiednie paczki z nagłówkami. W jakiej paczce jest dany plik to możesz sprawdzić na http://packages.debian.org Po zainstalowaniu manager procesów będzie w /usr/local/php5.3/sbin/php-fpm, w /usr/local/php5.3/etc/php-fpm.conf.default jest przykładowy plik konfiguracyjny. Zmień nazwę tego konfiga, pozmieniaj ścieżki, uruchom php-fpm z usera na prawach którego chcesz serwować skrypty PHP. Rady są ogólnikowe, ale jak będziesz robił krok po kroku z jakiegoś idiotoodpornego tutoriala to niczego się nie nauczysz. Jak skonfigurować nginxa pod PHP znajdziesz na wiki nginxa.

http://www.megiteam....g-wspoldzielony Ze skryptami PHP powinieneś zmieścić się w S. SSH jest standardowo, tyle, że zamiast FTP udostępniamy SFTP (bez limitu kont). Na hasło webhostingpl jest aktualnie 50% zniżki na pierwszą płatność.

Wszyscy powtarzają, że zalewa Onetowi nową serwerownię, ale to jest bzdura. Onet ma więcej niż jedną serwerownie i problem mają w starej, przenoszą się do nowej.