Skocz do zawartości

eRIZ

Użytkownicy
 Wyświetl profil  Zobacz jego aktywność

  • Zawartość

    49

  • Rejestracja

  • Ostatnio

Posty napisane przez eRIZ

  1. Napisano · Raportuj odpowiedź

    wszystko działa fajnie ale mam jeden problem zawsze gdy chce dodać jakiś wpis dodaje wpis i on się dodaje prawidłowo ale w logach apache obserwuje od jakiegoś czasu taki błąd

    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.

  4. Napisano · Raportuj odpowiedź

    Bo są durni. Jak jesteś miękki i masz durną księgową to potem robisz z siebie błazna terroryzując wszystkich dookoła bo musisz mieć to samo co sam wydrukujesz na papierze.

    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. :P

  7. Napisano · Edytowano przez eRIZ (zobacz historię edycji) · Raportuj odpowiedź

    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.

  10. Napisano · Raportuj odpowiedź

    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]

  14. Napisano · Raportuj odpowiedź

    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...

     

     

  15. Napisano · Raportuj odpowiedź

    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ę?

     

     

  17. Napisano · Edytowano przez eRIZ (zobacz historię edycji) · Raportuj odpowiedź

    A jak wyłączysz fix_pathinfo to stare SAPI FastCGI przestaje działać? Mam wrażenie że tak i że jak doprowadzisz je do działania z fix_pathinfo=0 to i FPM poleci.

     

    Działa bez najmniejszych problemów, niezależnie od tego ustawienia. A z php-fpm są cyrki...

     

    Może poszukaj w sapi/cgi/cgi_main.c co dokładnie robi fix_pathinfo i zrób to samo po stronie nginxa (siakieś REDIRECT_STATUS, SCRIPT_PATH_TRANSLATED i tego typu herezje).

     

    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...

  18. Napisano · Edytowano przez eRIZ (zobacz historię edycji) · Raportuj odpowiedź

    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.

  19. Napisano · Raportuj odpowiedź

    Zastanawia mnie ten wpisu u Ciebie,

     

    Podrzuciłem plik testowy, żeby wykluczyć problemy ze ścieżką.

     

    Jeśli jest w tmp to nie ma się co dziwić że sypie 404

     

    Jakakolwiek ona nie jest - uprawnienia przestawiłem, z katalogu domowego jest to samo. Poza tym:

     

    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.

     

    Więc dlaczego via php-fpm miałoby nie działać?

     

     

  22. Napisano · Edytowano przez eRIZ (zobacz historię edycji) · Raportuj odpowiedź

    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... :(

×