niepozwole

MongoDB na przełomie lat przeszło naprawdę sporo zmian. Pracuję z tą bazą od przeszło wersji 2.4 (lub nawet 2.2). Przyznam początki były ciężkie, sporo rzeczy nie działało albo działało inaczej niż przedstawiała to dokumentacja. Początkowo sam sharding również był drzazgą w oku, dane trzeba było podzielić praktycznie "ręcznie" wykorzystując pre splitting. Po wprowadzeniu dzielenia danych po hashu sam sharding jest praktycznie bezbolesny. Dodatkowo od wersji 3.2 nowy silnik wiredTiger staje się używalny (wcześniej było to jeszcze mocno niezgrane). Jeśli w Twoim środowisku jest zarówno sporo zapisów jak i odczytów to polecam zainwestować w dyski SSD (są bardzo pomocne przy sporej liczbie operacji zapisu). Dyski SSD do odczytów nie mają aż takiego znaczenia, ponieważ większość z Twojego aktualnego working seta i tak wyląduje w ramie. Także jeśli masz chęci i siły to polecam spróbować, nie taki diabeł straszny jak go malują.

 

Z choinki się urwałeś?

Czy ja wiem? Raczej nie bardzo. Chodziło mi o rozwiązanie tego problemu w możliwie nieinwazyjny sposób. Debian np. instalując paczki PHP (bo dobrze wiemy skąd pochodzą pliki w stylu sess_) dodaje specjalny wpis do crona czyszczący cyklicznie pliki sesji. Wystarczy odpowiednio skonfigurować php.ini, ewentualnie uprawnienia do katalogu z sesjami zamiast dodawać nadmiarowe crony.

Przede wszystkim o jakim systemie operacyjnym mówimy?

Zrobiłem tak jak napisaliście

do /usr/share/nginx/html wstawilem skrypt Wordpressa, żeby sprawdzić czy wszystko działa i przekierowało mnie do storny z Errorem.

 

/etc/php5/fpm/pool.d/www.conf

mam:

listen = /var/run/php5-fpm.sock

W error log pokazało

2014/09/14 14:40:19 [crit] 2565#0: *9 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: xx.xxx.xxx.xxx, server: localhost, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "xxx.xxx.xx.xx"

Ktoś napisał, że należy rozwiązać problem w ten sposób:

1. Open /etc/php5/fpm/pool.d/www.conf

2. Uncomment all permission lines, like:

   listen.owner = www-datalisten.group = www-datalisten.mode = 0660

3. Restart fpm - sudo service php5-fpm restart

Tak więc po zrobieniu tego widzę czystą/pustą stronę.

Napisałeś, że widzisz białą stronę. Czy te wpisy dotyczące permission denied już się nie pojawiają w logach? Jeśli przestały się pojawiać, to jeden problem rozwiązałeś, ale trafiłeś na następny.

Sprawdź co widać w /var/log/php5-fpm.log. Dodatkowo w php.ini włącz zapisywanie error_loga do pliku.

Wydaje mi się, że szukasz takiego rozwiązania:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-bind-rndc.html

root@xxx:/etc/bind# /etc/init.d/bind9 start
[ ok ] Starting domain name service...: bind9.
root@xxx:/etc/bind# dig @127.0.0.1 mojadomena.pl
dig: isc_taskmgr_create: no available threads

Ma ktoś jakiś pomysł jak rozwiązać ten problem ?

Przez ten błąd DNS nie chcą mi działać.

 

Sprawdzałeś logi binda? Wygląda, że wystartował poprawnie. Z tego co wkleiłeś problem jest z narzędziem dig, a nie z bindem. Na jakim serwerze to odpalasz? Czy jest to serwer wirtualny? Jeśli tak to podbij pamięć i sprawdź ustawienia w /etc/security/limits.conf.

Posiadam serwer xampp i od pewnego czasu przestały mi działać wszystkie konta, oprócz root.

 

oto error:

Access denied for user '[user]'@'localhost' (using password: YES)

 

Proszę o szybką pomoc

Ten problem może również pojawić się w przypadku braku uprawniń do wykonania konkretnej operacji. Na przykład możesz mieć taką sytuację, że podajesz poprawne dane logowania (user i pass), ale użytkownik, na którego się logujesz nie ma uprawnień do bazy danych na której chesz wykonywać operacje.

Ja ze swojej strony polecam dodanie opcji read_only do konfiguracji MySQL na serwerze SLAVE. Tak dla pewności, że baza jest na pewno tylko do odczytu. :-)

 

 

zgadza sie, port passive range jest ustawiony od 30000 do 50000, port 21 tez jest przekierowany. Caly pf.conf wyglada tak:

 

Najwazniejsze wytluscilem,

Z gory dzieki.

 

Niestety ekspertem od FreeBSD nie jestem dlatego dalej nie pomogę, natomiast przykładowo w Debianie, żeby to poprawnie działało muszą być załadowane dwa moduły:

nf_nat_ftp              1516  0
nf_conntrack_ftp        5252  1 nf_nat_ftp

 

Witam,

 

Mam jakis dziwny problem z laczeniem sie i nastepnie wyswietlaniem zawartosci katalogu. Po instalacj Pure-FTPD dzialalo wszystko dobrze, ale po chwili mi sie "zawiesza" a mianowicie dochodzi do momentu:

 

Userowie/pass sa tacy jak w /etc/passwd

pure-pwconvert >> /usr/local/etc/pureftpd.passwd

pure-pw mkdb

I wszystko chodzilo bez problemu. Mial ktos moze podobny problem ?

Pozdrawiam,

 

Uwierzytelnianie działa, jest natomiast problem jakby z przesyłaniem już konkretnych danych. Po samej procedurze uwierzytelnienia komunikacja przestawia się na tryb pasywny i jest problem z samym przesyłaniem danych już po nawiązaniu połączenia. Jesteś pewien, że po stronie serwera lub u Ciebie nie ma żadnej zapory blokującej ruch? Wątpię abyś blokował u siebie ruch wychodzący (tryb pasywny), natomiast serwer musi mieć możliwość otwarcia dowolnego portu i komunikacji przez niego. Możesz również ustalić określony zakres portów wpisując go to pliku PassivePortRange. Więcej o trybach komunikacji FTP znajdziesz tutaj.

Dobra od dupy strony zacząłem, aż wstyd się przyznać. Założyłem, że to mysql ma jakieś braki i przez to apacha ma duże CPU.

A jest odwrotnie. Duże CPU jest na apachu bo googlebot siedzi i napierdziela. Jak zablokowałem klasę googla jest spokój już długi czas.

 

To nie zmienia faktu, że w takim wypadku baza mysql jest u Ciebie wąskim gardłem. Warto przyjrzeć się tematowi i nawet jeśli nie chcesz optymalizować to chociaż popracować nad indeksami. To może być ciekawa przygoda. :-)

# Query_time: 8.770168  Lock_time: 0.000114 Rows_sent: 1000  Rows_examined: 64842158
SET timestamp=1398688918;

W tym wycinku strace nie widać nic niepokojącego (komunikat Timeout jest raczej standardem i powinien spływać dosyć często). Natomiast wpis, który wkleiłeś ze slow loga jest niepokojący: zapytanie zwróciło tylko 1000 rekordów a zostało przeanalizowane 64842158. Zdecydowanie na tej tabeli, z której pochodzi wpis brakuje dobrego indeksu.

Porównałem parametry podczas stabilnej pracy i skoku CPU i za bardzo nie ma różnic. Tak sobie pomyślałem, jeśli to są skoki, to poprostu leci jakieś niezoptymalizowane zapytanie, tym bardziej, że jedna baza danych nie posiada indeksów.

Czy może to być problemem ?

Jeżeli podejrzewasz problem ze słabą optymalizacją zapytań to polecam włączyć slow query log. Wszystko opisane jest tutaj: https://dev.mysql.com/doc/refman/5.5/en/slow-query-log.html. Do pliku zostaną zrzucone zapytania wolniejsze niż czas jaki ustawisz. Dodatkowo znajdą się tam cenne informacje odnośnie buforów, indeksów itd.

Taki plik slow loga polecam również przepuścić przez narzędzie: http://www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html. Znacznie ułatwia analizę danych oraz robi ładne podsumowania.

Jeszcze mała wskazówka: nic nie stoi na przeszkodzie abyś ustawił czas na 0, wtedy zostaną zalogowane wszystkie zapytania. :-)

Na pierwszy rzut oka obstawiłbym to:

Temporary tables created on disk: 42% (11K on disk / 26K total)

Sprawdź co podczas zwiększonego obciążenia konkretnie robi serwer MySQL. Przydatne będzie polecenie: https://dev.mysql.com/doc/refman/5.5/en/show-status.html

Być może w tym czasie MySQL tworzy sobie dużą liczbę małych tabel tymczasowych, dlatego nie jesteś w stanie tego wyłapać.

Dodatkowo polecam również podczas obciążenia odpalić narzędzie mytop z interwałem czasowym 1s. Zapytania mogą być bardzo szybkie, być może tak uda Ci się je wychwycić.

Dodatkowo warto połączyć ze sobą dwa narzędzia: traceroute i mtr. Raporty z tych narzędzi dadzą Tobie pełniejszy obraz. W sieci znajdziesz sporo informacji jak interpretować ich wyniki.

Proponowałbym raczej użyć tutaj kluczy. Wykorzystujesz rsynca, ale łączysz się po SSH, dlatego do uwierzytelnienia wystarczy para kluczy. Przykładowe polecenie:

rsync -A -P -r -a -v -e "ssh -i TUTAJ_SCIEZKA_DO_KLUCZA" /home/ts3/asd root@IP:/home/

Jeszcze lepiej byłoby, jeśli mógłbyś na maszynie zdalnej, do której się łączysz postawić daemona rsync - wtedy skorzystasz z możliwości uwierzytelniania jakie daje sam rsync.

Koliber2, również mam sporo powierzchni. Mógłbym umieścić Twoją stronę na swoim serwerze. Dodatkowo możemy obsłużyć DNS również po mojej stronie jeśli masz taką potrzebę.

Poradzisz sobie z tym robiąc rewrite w zainstalowanym u Ciebie serwerze WWW. W Nginx wyglądało by to np. tak:

server_name 	~^(\w+)\.subdomena\.domena\.pl$;
set $subdomena	$1;
root "/home/$subdomena/";

Nie wygląda na zepsutą bazę. W takim wypadku mógłbyś w logach MySQL-a zobaczyć zrzucanie core dumpów. Obstawiam błędne dane przy połączeniu do bazy danych. Sprawdź w konfiguracji na jakiego usera aplikacja próbuje się połączyć i zrób test czy Tobie się udaje to samo.

Na pierwszy rzut oka to ciężko powiedzieć. Masz tam Apache, być może Twoja maszynka nie wyrabia, ale chyba wygląda mi jakbyś miał tam jakieś dziwne pętle przekierowań...

Hej,

 

Jakie macie/jakie są rozsądne limity w slow.log?

Podejrzewam, że chodzi o slow log mysqla, prawdopodobnie o limity czasowe? Wszystko w sumie zależy od Twoich potrzeb, jakości napisanego przez Ciebie kodu, itp. Ja u siebie limit czasowy mam ustawiony na 0.4 s.

Musisz także uważać, jeśli ustawisz za mały limit, to pliczek slow loga może zbyt mocno spuchnąć... :-)

Zgadza się, nie działa to dla subdomen.

Nie działa to dla subdomen, ponieważ musiał byś to zrobić w konkretnym pliku konfiguracyjnym dla danej subdomeny (praktyka jest taka, że lepiej takie konfiguracje rozdzielać - nie trzymać wszystkiego w jednym pliku). Z tego co wiem, jeśli korzystasz z Nginxa to prawidłowo powinno to wyglądać tak: w pliku konfiguracyjnym swojej domeny np: example.pl dodajesz dwa bloki server

server {
server_name www.example.pl;
rewrite ^ http://example.pl$request_uri? permanent;
}

server {
listen	   80;
server_name  example.pl;
[...]
}

Oczywiście, drugi blok server powinien zawierać pełną konfigurację.

OK. Udało mi się z sukcesem ustanowić połączenie. Krótki opis dla potomnych jak można tego dokonać. Załóżmy, że mamy kontener (192.168.1.51), który stoi na maszynie fizycznej (192.168.1.50) a podsieć, do której chcemy się podłączyć to 192.168.40.0/24. Na maszynie tej koniecznie włączamy forwardowanie IP ( w debianie ):

echo 1 > /proc/sys/net/ipv4/ip_forward

Następnie w kontenerze ustawiamy routing:

ip route add 192.168.40.0/24 via 192.168.1.50

a na maszynie fizycznej maskaradujemy to połączenie np. tak:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o tun0 -j MASQUERADE

I to tyle.

Skonfiguruj sobie połączeniówkę poprzez interfejs TAP (np. 192.168.1.0/30).

Następnie na hoście VPN ustaw routing jakiejś podsieci przez IP połączeniówki (route 192.168.254.0/24 via 192.168.1.2).

Potem albo użyj jakiegoś interfejsu dodatkowego albo do eth0 przypisz IP 192.168.254.254.

Dalej w kontenerach veth, gdzie ip to jakieś ip z tej klasy, a default gateway to 192.168.254.254.

 

Jeśli zadbasz o poprawną wymianę routingową zarówno na hoście jak i kliencie VPN, to będzie działać.

OK. Dzięki za wstępne wskazówki. To dało mi obraz jak to może wyglądać. Będę informował czy mi się udało.

Są pewnie metody do wykonania. Można posłużyć się regułami iptables. Będzie to chyba w miarę optymalna opcja obrony. Tutaj masz pomocniczy artykuł. Myślę, że powinieneś spróbować uderzyć w podobny sposób: sample iptables rules.