Skocz do zawartości

Glibnes

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

  • Zawartość

    62

  • Rejestracja

  • Ostatnio

Posty napisane przez Glibnes

  2. Napisano · Raportuj odpowiedź

    Czy przy okazji tego tematu może mi ktoś wytłumaczyć, czy zakładanie DG zawsze wiąże się z opłatami za ZUSy, srusy i z innymi złodziejskimi podatkami?

    O ile dobrze wyczytałem w Interwebsach, dla "nowej firmy" te opłaty to na początek koszt w granicy tysiąca złotych miesięcznie - i jak tu młody człowiek może cokolwiek rozpocząć, jak od samego początku jest okradany z tego co zarobi?

  5. Napisano · Raportuj odpowiedź

    Witam,

     

    od kilkunastu dni mam problemy z dyskiem na moim VPSie (w ViHost). Otóż, zaczęło się od tego, że codziennie, ok. godziny 2:45 w nocy na serwerze po prostu kończy się miejsce (MySQL wywala error 28, PHP o ile akurat coś zapisuje do pliku wywala błędy zapisu). Jednakże, moje dane zajmują obecnie ok. 8GB dysku, a całkowitą pojemność mam 30GB.

    Specjalnie siedziałem po nocy aby sprawdzić, czy jakiś proces nie zaczyna o tej porze zjadać miejsca a potem w jakiś cudowny sposób je zwalniać, ale nic z tego - wszystko jest w porządku, żaden z procesów nie pożera miejsca, a żaden nowy się nie odpala (o tej godzinie nie robię żadnych backupów ani nie uruchamiam dodatkowych zadań).

     

    Sprawdziłem jak sprawa ma się z wynikami z "df". Okazuje się, że owszem - na głównej partycji miejsca jest łącznie 30GB, zajęte to te 8, ale dostępne... dostępne jest 0. W panelu VPSa pokazuje mi to samo (czyli 8gb zajętego i 30 GB łącznie). Również dopiero teraz zauważyłem, że podczas dnia, kiedy nie ma problemów z zapisem, df pokazuje "niepoprawne" wyniki dostępnego miejsca (raz jest go kilkaset MB, potem przechodzi do 3GB, a w chwili obecnej mam 12GB, chociaż powinno być 22GB).

     

    I teraz pytanie - co może być przyczyną takiego stanu rzeczy? Jak się tego pozbyć i ew. jak zabezpieczyć się przed tym na przyszłość? I czy nie jest to po prostu przepełnienie serwera matki?

  6. Napisano · Raportuj odpowiedź

    Jeśli nie chcesz korzystać z AJAXa, po prostu ustaw mniejszy Timeout.

    Korzystając z cUrla możesz ustawić timeout na poziomie milisekund za pomocą opcji CURLOPT_CONNECTTIMEOUT_MS

    No i oczywiście, jeśli sprawdzasz kilka serwerów za jednym uruchomieniem skryptu, wtedy przy wyłączonych serwerach ten czas się wydłuża (co jest chyba logiczne). Wtedy już lepiej skorzystać z AJAXowego sprawdzania.

  10. Napisano · Edytowano przez Glibnes (zobacz historię edycji) · Raportuj odpowiedź

    Sprawdź jakie błędy SQL wyskakują podczas wykonywania zapytań.

    O ile korzystałeś z phpMyAdmina lub mysqldumpa do przerzucenia danych z jednej bazy na drugą, to podczas importu powinny zapisać się dane o silniku, ale głowy sobie nie dam za to uciąć. Dodatkowo, od bodajże MySQL 5.5 domyślnym silnikiem jest właśnie InnoDB, a nie (jak było to do tej pory) MyISAM.

  15. Napisano · Raportuj odpowiedź

    Spróbuj: 
     location / { root /var/www/$1/htdocs; }

    Jeśli nie zadziała to problem jest we wpisie: 

     server_name ~^(.*)\.battlespace\.pl$;

    Nie znam składni żeby Ci pomóc, ale jak sposób wyżej nie zadziała to zerknę do dokumentacji i przeanalizuje jeszcze raz.

     

    Wywaliłem ten kod od multisubdomen, wstawiłem osobny wpis dla uni3 i zadziałało, więc masz rację - problem leży w tej części kodu.

     

    Rozwiązałem problem:

     

    server {
   listen  80;
   server_name ~^(?<subdomain>.+)\.battlespace\.pl$;
   #if directory doesn't exist
   if (!-d /var/www/$subdomain.battlespace.pl) {
    rewrite . http://battlespace.pl redirect;
   }

   # Sets the correct root
   root /var/www/$subdomain.battlespace.pl/htdocs;
}

  16. Napisano · Edytowano przez Glibnes (zobacz historię edycji) · Raportuj odpowiedź

    Oryginalny config (restart nginxa nic nie dał):

    server {
listen  80;
server_name battlespace.pl;
root /var/www/default/htdocs;

access_log  /var/www/default/logs/access.log myown;
error_log /var/www/default/logs/error.log;
index index.php index.html index.htm;

# --- Don't log Images, JavaScript & CSS ---
location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico)$ {
	access_log  off;
}

location / {	  
 try_files $uri $uri/ =404;
}

location ~ .php$ {	
	try_files $uri $uri/ =404;

	fastcgi_split_path_info ^(.+\.php)(.*)$;
	fastcgi_pass   php_fpm;
	fastcgi_index  index.php;
	fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
	include /etc/nginx/fastcgi_params;
	fastcgi_param  QUERY_STRING	 $query_string;
	fastcgi_param  REQUEST_METHOD   $request_method;
	fastcgi_param  CONTENT_TYPE	 $content_type;
	fastcgi_param  CONTENT_LENGTH   $content_length;
}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one

location ~ /\.ht {
 deny all;
}
}

server {
listen  80;
server_name   ~^(.*)\.battlespace\.pl$;
#if directory doesn't exist
if (!-d /var/www/$1) {
	rewrite . http://battlespace.pl/ redirect;
}

# Sets the correct root
root /var/www/$1/htdocs;
}
server {
listen 80;
server_name www.battlespace.pl;
rewrite ^/(.*) http://battlespace.pl/$1 permanent;
}

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

    A to czytałeś? http://www.webhostin...-waszych-domen/

     

    I powiedz jak mamy Ci pomóc nie znając domeny? Pewnie masz jakiś błąd w konfiguracji dnsów.

    Przepraszam, zapomniałem o tym: battlespace.pl (domena z sygnaturki).

    Po przeładowaniu dnsów subdomena uni3 wskazuje na stronę główną, wg. configa nginxa powinna wskazywać na katalog z tą subdomeną (więc pewnie to problem z dnsem).

  19. Napisano · Edytowano przez Glibnes (zobacz historię edycji) · Raportuj odpowiedź

    Witam,

     

    mam pewien problem z ustawieniem subdomeny na nginxie.

    Używam obecnie PowerDNSa, zarządzam nim przez prosty PowerAdmin.

    Dodałem rekord CNAME subdomena.domena.pl w zone domena.pl

    Ustawiłem następujący config dla nginxa:

    server {
listen  80;
server_name domena.pl;
root /var/www/default/htdocs;

access_log  /var/www/default/logs/access.log myown;
error_log /var/www/default/logs/error.log;
index index.php index.html index.htm;

location ~ .php$ {	
	try_files $uri $uri/ =404;

	fastcgi_split_path_info ^(.+\.php)(.*)$;
	fastcgi_pass   php_fpm;
	fastcgi_index  index.php;
	fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
	include /etc/nginx/fastcgi_params;
	fastcgi_param  QUERY_STRING	 $query_string;
	fastcgi_param  REQUEST_METHOD   $request_method;
	fastcgi_param  CONTENT_TYPE	 $content_type;
	fastcgi_param  CONTENT_LENGTH   $content_length;
}
}

server {
listen  80;
server_name   ~^(.*)\.domena\.pl$;
#if directory doesn't exist
if (!-d /var/www/$1) {
	rewrite . http://domena.pl/ redirect;
}

# Sets the correct root
root /var/www/$1/htdocs;
}
server {
listen 80;
server_name www.domena.pl;
rewrite ^/(.*) http://domena.pl/$1 permanent;
}

    Wg. autora powyższego configu (nie, nie jest mój, jedynie dostosowałem go do swoich potrzeb) powinien on działać dla każdej subdomeny.

     

    Jednak u mnie po prostu strona się nie wczytuje ("Nie odnaleziono serwera" - Firefox), a domena główna działa bez problemu. Co zrobiłem źle?

  20. Napisano · Raportuj odpowiedź

    Mam problem z przeniesieniem bazy danych z jednego serwera na drugi, chociaż nie jestem do końca pewien, czy jest to problem ze złym eksportem i importem czy problem serwera.

     

    Skopiowałem bazę danych z jednego serwera na drugi i teoretycznie wszystko powinno być jak trza (w PhpMyAdmin widać na obydwu serwerach w polach tekstowych normalne, polskie znaki - kodowanie pól ustawione na UTF8-polish). Na obydwu serwerach mam dokładnie ten sam kod źródłowy strony.

    Jedyne zauważalne dla mnie różnice to takie, że na drugim serwerze (na który przenoszę dane - VPS na Vihoście) mam nieco nowszego nginxa i mysqla (na obydwu mam wersję 5+).

    Po wejściu na stronę - krzaki zamiast polskich ogonów np. w wiadomościach użytkowników.

     

    Czy jakieś same ustawienia serwera (np. coś w locales) albo nginxa mogą powodować taki stan rzeczy, czy to jednak jest wina złego importu?

    Dodam, że dane zrzuciłem przez PMA z ustawieniem kodowania pliku na UTF8, podczas importu (próbowałem zarówno przez mysql i source przez linię komend oraz przez samego PMA, w obydwu przypadkach dodawałem SET NAMES 'utf8').

  24. Napisano · Raportuj odpowiedź

    Szczerze mówiąc, ostatnio coraz więcej osób narzeka na mBank za długi czas przelewów.

    Wydaje mi się, że właśnie po tej stronie powinieneś poszukać rozwiązania problemu.

     

    Wpisałeś poprawnie tytuł przelewu?

    Sam nigdy nie miałem problemów z mBankiem, ale i tak cztery dni to dostatecznie dużo czasu nawet gdyby to tutaj był problem.

    I wszystkie dane które mi podali w Emailu wpisałem poprawnie - sprawdzałem dwa razy numer konta, odbiorcę i tytuł.

×