blackfire

Następnym razem dopiero w trumnie

Hm, pewien jesteś? Ja zakładam, że i tak efektywnie każda maszyna jest wydzielona w swoim VLANie (bo inaczej po co /32), więc jedynym sąsiadem serwera jest router, który i tak tam być musi. IMHO można przenosić tak samo łatwo jak przy adresacji /32. Tak czy inaczej masz trasę do każdego hosta osobno. Różnica polega na tym, że router musi mieć dodatkowo adres z każdej obsługiwanej /24 a przydzielając /32 może mieć jeden adres w ogóle, bo i tak się go ustawia z łapy.

Hm. Czyli routing na serwerze masz w stylu: 188.116.0.30/32 dev lo # mimo że adres na eth0; tego nie widać w tablicy main 188.116.0.1/32 dev eth0 # trasa do routera default via 188.116.0.1 dev eth0 # reszta świata via router tak? Jeżeli router nie wie, że ma inną podsieć dla tej adresacji (/24 vs /32), to będzie wysyłał ICMP redirecty ("po cholerę mam forwardować pakiet do 188.116.0.40, sam se go tam wyślij"). Jak zareaguje host, ciężko wyczuć, chociaż możliwe, że będzie działać jak w reklamie. Jeżeli router wie o tych czarach (np. ma wyłączone wysyłanie redirectów), to oczywiście nie ma problemu. Minus (zwłaszcza jeżeli to nie Ty zarządzasz serwerami a ktoś inny) jest taki, że tablica routingu jest dość nietypowa (trasę do routera trzeba dodać z łapy/OSPFem bo nie wynika z adresacji interfejsu). Jeżeli jest to wykonalne, to chyba zdrowiej jest dać serwerom /24, bo i tak żeby /32 miało sens to musisz je odizolować jakimiś VLANami od siebie, a wtedy przynajmniej masz routing, który ogarnie 95% gospodyń domowych z Gdańska (/24 na eth0, default via coś normalnie osiągalne via eth0). Jakie masz argumenty "za"? Ciekawm.

Fakt, przesadziłem. To tylko te 99% wyjątków psuje opinię reszcie. "jest dobre" + "zostawienie problemów jest prawie murowane". xorg, Archi: ja nie piszę tu o zawodowych programistach, którzy i w brainfucku napiszą elegancki kod. To jest wątek o początkującym, który zaczął niestety od PHP. Skoro się uczysz, to ucz się tak, żebyś nie musiał się tego potem zaraz oduczać. Pisanie w czystym PHP to trochę jak growl wśród metalowych wokalistów. Jeżeli umiesz czysto śpiewać ale wolisz growl (który wbrew pozorom jest trudny), to jak najbardziej OK. Ale jeżeli drzesz ryja bo nie umiesz inaczej, to jesteś dupa nie wokalista.

Tak. Znaczy IMHO naprawdę lepiej użyć jakiegoś frameworka, który ogarnie za Ciebie dużo więcej takich tematów, które wydają się proste do momentu, kiedy chcesz to zrobić dobrze. Ale już samo PDO Ci wiele pomoże. Prosty argument: masz definitywnie załatwioną kwestię SQL Injection (no, chyba że się bardzo postarasz). Poza tym PDO to ucywilizowanie interfejsu (spójny sposób komunikacji z różnymi bazami danych, wyjątki zamiast zwracania false/null/-1 itp.). Niezależność od konkretnej bazy danych to trochę mit, ale i tak Ci to masę roboty oszczędzi przy migracji MySQL->PostgreSQL. http://wiki.hashphp.org/PDO_Tutorial_for_MySQL_Developers na pierwszy rzut oka wygląda sensownie. Zobacz zwłaszcza sekcję "Running statements with parameters" i porównaj z podejściem klejącym zapytanie w PHP. BTW, co to jest SQL Injection to jest nawet na polskiej Wikipedii: http://pl.wikipedia.org/wiki/SQL_injection ale pomiń te bzdury o addslashes(). To *nie* to samo co DBI::quote() i nie zabezpiecza w pełni przed SQL Injection.

Skrypty pisane od zera przez hobbystów dają też ogromną satysfakcję adminom, jak muszą blokować konta takim hobbystom i tłumaczyć się RBLom, czemu od nich wychodzi tona spamu. Oprócz tego przyjemnie spędzi czas rzesza innych adminów, którzy ten śmietnik muszą odebrać i przeanalizować. Jak chcesz pisać od zera to nie pisz w PHP tylko w asemblerze (albo gołym kodzie maszynowym), w końcu z PHP dostajesz kilkadziesiąt MB gotowca. Przynajmniej jak już skończysz to ja nie będę musiał odbierać wysłanego przez to spamu bo już pewnie opuszczę ten łez padół. "A co do tych filtracji" - Windows prawda. Gdyby to było takie proste, to SQL Injection by wyzdychało śmiercią naturalną. Słowa bym nie powiedział, gdybyś w ten sposób szkodził tylko sobie. Ale takie rękodzieło to wrzód na dupie całego Internetu i wszyscy ponosimy tego konsekwencje.

Nie. "Odpowiednie filtrowanie" to obejście problemu, który w ogóle nie powinien istnieć, a który _rozwiązuje_ (nie _obchodzi_) użycie współczesnego interfejsu do baz danych (chociażby PDO). Wiesz, że w jakimś dwubajtowym kodowaniu jeden z chińskich ideogramów zawiera ASCII 0x5c, czyli backslash? Zgadnij, jak to wpływa na "zabezpieczenia" oparte o addslashes/stripslashes/wytnij_slashes_real_escape_string. Zamiast się zastanawiać, czy na pewno Twoje "rozwiązanie" z filtrowaniem/escape'owaniem danych od klienta działa, możesz zlikwidować całą klasę problemów. Użycie jakiegoś frameworka (jakiegokolwiek używanego nie tylko przez autora i jego psa) chowa przed Tobą tego typu pomysły i generalnie wymusza zdrowsze podejście (oddzielenie logiki biznesowej od prezentacji itp.). Kiedyś jeszcze lepienie w gołym PHP miało sens, jak nie było powszechnych frameworków i darmowych SaaSów do wszystkiego, ale teraz naprawdę nie jestem w stanie znaleźć jakiegokolwiek uzasadnienia poza masochizmem.

Największą pomocą będzie jak ZOSTAWI GOŁE PHP W CHOLERĘ. To nieodwracalnie uszkadza mózg i wpaja najgorsze możliwe wzorce. Piszę całkowicie serio. PHP przykryte jakimś używalnym frameworkiem (na co dzień piszę w Django, więc z głowy nie wiem, który jest używalny, dlatego odesłałem do webmastah) może być fajną platformą do developmentu. Ale takie gołe: <? mysql_query("INSERT INTO tab VALUES($_GET[foo])") ?> powinno być prawnie zakazane pod karą rozstrzelania.

Primo: Po czym wnosisz, że przedpiśća nie ma kolumny na klucz główny? NULL jako pierwszy parametr sugeruje (niestandardowe, ale używalne w mysqlu) użycie domyślnej wartości. Jeżeli pierwszą kolumną w definicji był właśnie klucz główny, to NULL jest o niebo zdrowsze niż '' (chociaż w zasadzie to taką kolumnę należałoby pominąć). SQL l3szcza jest fatalny, ale to akurat chyba najmniejszy z jego problemów. Secundo: UTFG: SQL injection. Właśnie wystawiłeś całą swoją bazę internetom do zapisu. l3szcz zresztą też. Tertio: mysql_query. Proszę Cię (i przedpiścę), nie w XXI wieku. Nie po to powstało PDO, żeby to truchło jeszcze ruszać. Zapomnijcie o istnieniu tak niskopoziomowych i skopanych na etapie samego projektowania funkcji. Quarto: l3szcz, użyj jakiegoś frameworka, nie męcz się z gołym PHPem. Np. tutaj sobie poczytaj: http://webmastah.pl/

Może. OpenVZ tykałem dawno temu i raczej z daleka.

OTOH, dużo tego nie ma, parę plików zerowej długości, na pewno nie 30 GB. Ile Ci brakuje _teraz_ miejsca? O ile się różni zajęte miejsce z "df -B 1048576" od policzonego przez "du -xsm /"? Ile masz plików w /tmp (nawet pustych)? Ich liczba rośnie z czasem? Zakładam że /tmp masz na tym samym filesystemie co resztę, a nie na jakimś tmpfs na przykład. BTW, jak to jest OpenVZ to kojarzy mi się, że ten ich SimFS kłamał w żywe oczy jak mu się miejsce na hoście kończyło, ale nie tłumaczyłoby to, dlaczego reboot pomógł. BTW2, ktoś kojarzy, co to za blockdev 0,147? Coś z OpenVZ?

666. Jaki sens ma +x dla /dev/null? @Aimer, Sprawdź przy okazji (ls -l /dev/null), czy /dev/null jest urządzeniem, bo może coś je podmieniło zwykłym plikiem. Pierwsza kolumna wyniku ls ma wyglądać tak: crw-rw-rw- (i ew. kropka jak używasz SELinuxa)

Masz jakieś otwarte usunięte pliki. Skopana rotacja logów? lsof | grep -F '(deleted)' Przedostatnia pozycja (przed nazwą) to jest numer inode'a, jeszcze wcześniejsza to rozmiar. Mój bash ma jakieś 950 KB na dysku: bash 15414 blackfire txt REG 8,1 950896 6815748 /bin/bash

Ja bym pewnie zaczął od uruchomienia obu procesów pod strace -ff -ttT -s 10000 -o fcgi.strace /path/to/php-fcgi --opcje-php (dla php-fpm analogicznie). Masz duże różnice w czasie wykonania samego kodu PHP, co nie ma żadnego sensu patrząc po architekturze php-fcgi i php-fpm (po odebraniu requestu obydwa robią dokładnie to samo). Dasz sobie wyciąć obie nerki, że obydwa phpy korzystają z tych samych ustawień (php.ini)? Porównywałeś `phpinfo()`? php-fpm na pewno korzysta z opcache? Wyłącz go w obu SAPI i wtedy porównaj wyniki, może się okaże, że się to jakoś żre z fpmem. Może masz php-fpm skonfigurowane tak, że uruchamia jakąś dużą pulę procesów, która wypycha cache z pamięci?

USERA, USERB to są różne konta unixowe? Mówisz o chown'owaniu po synchronizacji więc zakładam że tak i że możesz zrobić ssh USERA@serwer i ssh USERB@serwer. Jeżeli nie, to daj znać bo wtedy to będzie trochę inaczej wyglądać. W takim układzie nie potrzebujesz żadnego gitolite'a (o gitosisie zapomnij, nie jest od lat utrzymywany), masz po prostu dwa niezależne repozytoria, każde na swoim koncie. Przeczytaj tego posta, żeby się zorientować w praktykach związanych z obsługą zdalnych repo gita, powinien Ci wyjaśnić, dlaczego masz użyć dwóch repo na każdym koncie: http://www.megiteam.pl/blog/2009/11/01/zeby-bylo-git/ Jak już na każdym koncie masz katalog na repo (powiedzmy ~/app.git) i katalog na drzewo robocze (powiedzmy ~/app), to po prostu ustawiasz odpowiednie remote'y w swoich lokalnych repozytoriach, coś typu: git remote add origin ssh://USERA@SERWER/~/app.git Dla serwisu USERB analogicznie. Pamiętaj, żeby odciąć dostęp do katalogu ~/app/.git (w katalogu roboczym), na przykład .htaccessem. Jeżeli -- czego się trochę spodziewam, czytając o zmianie właściciela plików -- pchasz zmiany do tych repozytoriów logując się na konto roota, to przestań i nie rób tak więcej. Jak najbardziej da się wykonać chown po pchnięciu zmian, ale to jest na tyle zły pomysł, że nie podam Ci rozwiązania.