eRIZ

Jeśli to to, co myślę, to rozwiązanie jest dość prozaiczne - niech ten plik wypluwa cokolwiek do przeglądarki przed upłynięciem tego timeoutu. Z mojego doświadczenia - serwer wypluwa coś takiego, jeśli interpreter nie zwraca serwerowi zawartości przez podany czas w konfiguracji FastCGI. Możliwe również, że jakaś wtyczka zwyczajnie wykonuje swoje zadanie za długo.

Ew. round-robin, ale pozostaje jeszcze kwestia synchronizacji zbiorów na maszynach, które nie są w tym samym DC, jak w tym przypadku.

Postawiłem sobie środowisko z PHP na FreeBSD via php-fpm z chrootowaniem do katalogu użytkownika. Skompilowałem z obsługą imagick. I tu zaczynają się problemy, bo wykonanie nawet najprostszego kodu: try{ $img = new Imagick('img.jpg'); }catch(ImagickException $ex){ var_dump($ex); } Wysypuje mi całość: object(ImagickException)#2 (7) { ["message":protected]=> string(87) "NoDecodeDelegateForThisImageFormat `magick-VO6fZKY8' @ error/constitute.c/ReadImage/532" ["string":"Exception":private]=> string(0) "" ["code":protected]=> int(1) ["file":protected]=> string(23) "/chroot/script.php" ["line":protected]=> int(8) ["trace":"Exception":private]=> array(1) { [0]=> array(6) { ["file"]=> string(23) "/chroot/script.php" ["line"]=> int(8) ["function"]=> string(11) "__construct" ["class"]=> string(7) "Imagick" ["type"]=> string(2) "->" ["args"]=> array(1) { [0]=> string(11) "img.jpg" } } } ["previous":"Exception":private]=> NULL } Ok, myślę sobie, brak odpowiednich libów. ldd na imagick.so, kopiuję biblioteki do /lib względem katalogu "więziennego": cp /usr/local/lib/libMagickWand.so.5 libMagickWand.so.5 cp /usr/local/lib/libMagickCore.so.5 libMagickCore.so.5 cp /lib/libthr.so.3 libthr.so.3 cp /lib/libc.so.7 libc.so.7 cp /usr/local/lib/liblcms2.so.2 liblcms2.so.2 cp /usr/local/lib/libtiff.so.4 libtiff.so.4 cp /usr/lib/liblzma.so.5 liblzma.so.5 cp /usr/local/lib/libjbig.so.1 libjbig.so.1 cp /usr/local/lib/libjpeg.so.11 libjpeg.so.11 cp /usr/local/lib/liblqr-1.so.3 liblqr-1.so.3 cp /usr/local/lib/libglib-2.0.so.0 libglib-2.0.so.0 cp /usr/local/lib/libintl.so.8 libintl.so.8 cp /usr/local/lib/libiconv.so.3 libiconv.so.3 cp /usr/local/lib/libpcre.so.0 libpcre.so.0 cp /usr/local/lib/libfftw3.so.6 libfftw3.so.6 cp /usr/local/lib/libfontconfig.so.1 libfontconfig.so.1 cp /usr/local/lib/libfreetype.so.9 libfreetype.so.9 cp /usr/local/lib/libexpat.so.6 libexpat.so.6 cp /usr/lib/libbz2.so.4 libbz2.so.4 cp /lib/libz.so.5 libz.so.5 cp /usr/local/lib/libltdl.so.7 libltdl.so.7 cp /lib/libm.so.5 libm.so.5 Niestety, skutek jest identyczny - wysypuje wyjątek, choć wszystkie biblioteki są (a przynajmniej powinny być) dostępne. Poguglałem, niestety - nic interesującego nie znalazłem, a mi pomysły się już skończyły. -- edit: ścieżki do obrazka, ale w rzeczywistym środowisku są ok.

Nie kopiowałem w to samo, tylko w ogólnodostępne (binarka nie odwołuje się wewnętrznie do ścieżek bezwzględnych). Problemem było cache'owanie bibliotek przez php-fpm (nie przeładowywałem po dodaniu bibliotek), ale nie wpadłbym na to, gdybyś mnie nie nakierował na przetestowanie via chroot. [: Problem rozwiązany.

Nie do końca. Z tego, co wiem, to w przypadku papierowych dokumentów, musisz je przechowywać przez rok, natomiast elektroniczne - 5 lat. Dlatego firmy "terroryzują" papierami.

Na przeglądarkach bez akceleracji GPU tnie się niemiłosiernie. [;

Nie wysyłaj tego w formularzu. Zrób sobie tabelę z transakcjami i trzymaj to wszystko na serwerze potem się odwołując do odpowiedniego księgowania. Sesja będzie mało istotna, bo ID transakcji (parametr kontrolny też) będzie przesłany przez DotPaya.

Jaki silnik bazy? Która wersja MySQL? Próbowałeś zdumpować bazy do SQL, wyczyścić dane demona i je ponownie zaimportować?

Ale dzisiaj mamy (jeszcze) poniedziałek. ;p Na moje oko, to kontynuacja tego, co miało miejsce w ostatnich dniach - chyba że masowy pad kart sieciowych na ostatnich węzłach, ale jakoś mi to nie pasi w kontekście powyższego. -- edit: Maszyny odżyły.

Z tego pingi mi mówią, to chyba znowu DDoS: 2 1 ms 1 ms 1 ms 192.168.10.1 3 1 ms 1 ms 1 ms 192.168.252.1 4 1 ms 1 ms 1 ms gw1.rz.izeto.pl [91.192.165.129] 5 1 ms 1 ms 1 ms main-gw.rz.izeto.pl [91.192.165.1] 6 17 ms 17 ms 17 ms TKPSA.plix.pl [195.182.218.29] 7 17 ms 17 ms 17 ms kat-jor-r1.3s.pl [85.14.102.77] 8 2003 ms 2003 ms 1993 ms unix-storm-r.3s.pl [85.14.85.238] 9 1956 ms * * k3.unixstorm.org [91.227.122.8] 10 1973 ms 1986 ms * k3.unixstorm.org [91.227.122.8] 11 1970 ms * * k3.unixstorm.org [91.227.122.8] 12 * * * Request timed out. 13 1974 ms * * k3.unixstorm.org [91.227.122.8] 14 1980 ms * * k3.unixstorm.org [91.227.122.8] 15 2008 ms * * k3.unixstorm.org [91.227.122.8] 16 2037 ms * 2030 ms k3.unixstorm.org [91.227.122.8] 2 1 ms 1 ms 1 ms 192.168.10.1 3 1 ms 1 ms 1 ms 192.168.252.1 4 1 ms 1 ms 1 ms gw1.rz.izeto.pl [91.192.165.129] 5 1 ms 1 ms 1 ms main-gw.rz.izeto.pl [91.192.165.1] 6 17 ms 17 ms 17 ms TKPSA.plix.pl [195.182.218.29] 7 17 ms 17 ms 17 ms kat-jor-r1.3s.pl [85.14.102.77] 8 * * * Request timed out. 9 * * * Request timed out. 10 2059 ms 2062 ms 2052 ms k3.unixstorm.org [91.227.122.8]

Niestety, też leżała. Hmm, pamiętam że wczoraj też miałem problemy w godzinach popołudniowych... k3 wstał.

Potwierdzam, zdechł. Wczoraj działo się to samo, w identycznych godzinach. DDoS? Z Crowleya gubi większość pakietów, z OVH w Bordeaux to samo.

Witam. Stawiam obecnie serwer na FreeBSD + nginx + php-fpm. I o ile wszystko działa OK, tak php-fpm sprawia mi problem, którego nie jestem w stanie rozwiązać. Mianowicie, workery są uruchamiane poprawnie. Jednak ni w ząb, nie da się do nich połączyć. W celu wykluczenia błędu w konfiguracji, uruchomiłem ręcznie interpreter jako responder na FastCGI działający na identycznym porcie i uprawnieniach, co w konfiguracji php-fpm. O dziwo, wszystko działa prawidłowo, więc konfiguracja serwera jest prawidłowa. Oto odpowiedź serwera w przypadku korzystania z php-fpm: HTTP/1.1 404 Not Found Server: nginx/1.0.5 Date: Thu, 18 Aug 2011 10:11:45 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.3.6 Natomiast ten sam skrypt wywołany przy responderze uruchomionym ręcznie działa bez zarzutu (w tym przypadku plik z wyłącznie phpinfo()). Macie jakieś pomysły? Kopię już drugi dzień w Google i konfiguracji; na IRC-ach głównych zainteresowanych nie dowiedziałem się, niestety, niczego...

Powiedzenie, że ilość kodu powodująca problem jest odwrotnie proporcjonalna do jego powagi jednak jest istotne. Znalazłem przyczynę - po 5 dniach walki i 3 grzebania w źródłach. Problemem był chroot i ścieżka bezwzględna jako SCRIPT_FILENAME miast względem chrootowanego katalogu. Dzięki za poświęcony czas.

Kolejny dzień roztrzaskiwania mojego mózgu o dziwny problem. Do czego udało mi się dotrzeć. W pliku fpm_main.c jest odwołanie do: /* path_translated exists, we can continue ! */ if (php_fopen_primary_script(&file_handle TSRMLS_CC) == FAILURE) { Owszem, zwraca failure. Ale najciekawszy jest powód błędu: zlog(ZLOG_NOTICE, "WTF: %d", errno); zlog, to wbudowana funkcja do rzucania błędami do konsoli, jeśli php-fpm ma wyłączone w konfiguracji daemonize. Po wykonaniu żądania dla wyłączonego cgi.fix_pathinfo ta zmienna ma wartość errno = 2. Wyczytałem w Sieci, że taki kod jest zwracany, gdy poszukiwany plik nie istnieje (nie żaden brak uprawnień, czy coś; po prostu nie istnieje). Idąc dalej php_fopen_primary_script siedzi w fopen_wrappers.c i zwraca status FAILURE w kilku przypadkach. W moim przypadku sypie z tego powodu: if (filename) { resolved_path = zend_resolve_path(filename, strlen(filename) TSRMLS_CC); } resolved_path jest po prostu... puste. Co powoduje wysypanie następującego warunku: f (!resolved_path) { if (SG(request_info).path_translated != filename) { STR_FREE(filename); } /* we have to free SG(request_info).path_translated here because * php_destroy_request_info assumes that it will get * freed when the include_names hash is emptied, but * we're not adding it in this case */ STR_FREE(SG(request_info).path_translated); SG(request_info).path_translated = NULL; fprintf(stderr, "plecy3\n"); return FAILURE; } Dobierając się dalej: zend_resolve_path to tak naprawdę łańcuszek do php_resolve_path. Namierzyłem dziwny punkt: if ((*filename == '.' && (IS_SLASH(filename[1]) || ((filename[1] == '.') && IS_SLASH(filename[2])))) || IS_ABSOLUTE_PATH(filename, filename_length) || !path || !*path) { if (tsrm_realpath(filename, resolved_path TSRMLS_CC)) { return estrdup(resolved_path); } else { fprintf(stderr, "resolve plecy4: TSRM: %s, resolved_path: %s\n", tsrm_realpath(filename, resolved_path TSRMLS_CC), resolved_path); return NULL; } } Thread Safe Resource Manager - nie wiem, po kiego grzyba coś takiego, ale niech będzie; w pliku TSRM/tsrm_virtual_cwd.c siedzi to dziadostwo. Jest stałą debugująca, która pozwala na dumpowanie do stderr każdego etapu wyciągania. Po jej włączeniu i przekompilowaniu interpretera na starcie otrzymuję: cwd = path = /usr/local/sbin/php-fpm virtual_file_ex() = /root/php5.3-201108181230/sapi/fpm/php-fpm cwd = path = /usr/local/etc/php.ini virtual_file_ex() = /usr/local/etc/php.ini a dla plików puszczonych via FCGI: cwd = path = /sciezka/index.php Czyli powinno to coś działać. Ale nie działa. Funkcja tsrm_realpath stopuje na: if (virtual_file_ex(&new_state, path, NULL, CWD_REALPATH)) { free(new_state.cwd); return NULL; } Tylko nie wiem, dlaczego... Przecież ścieżka jest prawidłowa i dostępna...

Znalazłem coś takiego: if (!ptr) { /* * if we stripped out all the '/' and still didn't find * a valid path... we will fail, badly. of course we would * have failed anyway... we output 'no input file' now. */ if (orig_script_filename) { _sapi_cgibin_putenv("ORIG_SCRIPT_FILENAME", orig_script_filename TSRMLS_CC); } script_path_translated = _sapi_cgibin_putenv("SCRIPT_FILENAME", NULL TSRMLS_CC); SG(sapi_headers).http_response_code = 404; } Dobrze kopię?

No właśnie kopię w źródłach i póki co, niczego niepokojącego nie widzę, zważywszy na to, że problem jest dość odosobniony... Wszelkie wskazówki mile widziane, bo w C wymiataczem nie jestem i coś mi może umknąć.

Działa bez najmniejszych problemów, niezależnie od tego ustawienia. A z php-fpm są cyrki... W źródłach nie grzebałem, ale kombinowałem z REDIRECT_STATUS i niestety, bez większych sukcesów. Skoro przy zwykłym FCGI działa niezależnie od fix_pathinfo, to chyba nie ma co grzebać w źródłach w tym celu...

Już próbowałem wszystkiego - podsłuchałem ktracem, jak sobie nginx z php rozmawia i w obu przypadkach ścieżki w żądaniach są prawidłowe. Gdy wyłączę fix_pathinfo, wywala no input file specified. Gdy włączę - sytuacja jest taka, jak opisałem. Pogrzebałem trochę ktracem i wyniki są następujące. Dla php-fpm SCRIPT_FILENAME/sciezka/index.php QUERY_STRING REQUEST_METHODGET CONTENT_TYPE CONTENT_LENGTH SCRIPT_NAME/index.php REQUEST_URI/index.php DOCUMENT_URI/index.php DOCUMENT_ROOT/sciezka SERVER_PROTOCOLHTTP/1.1 GATEWAY_INTERFACECGI/1.1 SERVER_SOFTWAREnginx/1.0.5 i dla ręcznie spawnowanego FastCGI: SCRIPT_FILENAME/sciezka/index.php QUERY_STRING REQUEST_METHODGET CONTENT_TYPE CONTENT_LENGTH SCRIPT_NAME/index.php REQUEST_URI/index.php DOCUMENT_URI/index.php DOCUMENT_ROOT/sciezka SERVER_PROTOCOLHTTP/1.1 GATEWAY_INTERFACECGI/1.1 SERVER_SOFTWAREnginx/1.0.5 (wyciąłem nagłówki odpowiadające za porty i adresy IP komunikacji przeglądarki z serwerem; ścieżka oczywiście jest prawidłowa) Gdy wyłączę fix_pathinfo, zwraca no input file specified, gdy włączę, to pod php-fpm zwraca błąd przeglądarki.

Podrzuciłem plik testowy, żeby wykluczyć problemy ze ścieżką. Jakakolwiek ona nie jest - uprawnienia przestawiłem, z katalogu domowego jest to samo. Poza tym: Więc dlaczego via php-fpm miałoby nie działać?

Również się wybieram. [; Gdyby ktoś chciał, abym poruszył pewne szczególne kwestie dot. bezpieczeństwa w swojej prelekcji, proszę dać znać.

http://wklej.org/hash/fdb9d6d2b09/

No teraz już wygląda na to, że jest w porządku, ale przez circa godzinę było nieciekawie...

Jakiś (D)DoS teraz na serwer? Jeden z użytkowników mojego serwisu zgłosił, że nie może się do niego dostać; poczta czasem działa, z SSH zrywa połączenie, load niski. U mnie również to samo, dlatego pytam.

No to nie za ciekawie - co żądanie musi startować kolejny proces, co powoduje dodatkowy narzut. Zmień na FastCGI, doinstaluj akcelerator, wtedy będziemy się dalej zastanawiać.