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

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?

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

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.

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

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

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.

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

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.

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

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ąć... :-)

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

Witacje! Mam serwer, na którym działa połączenie VPN. VPN postawiony jest na interfejsie tun. Na wspomnianym serwerze mam kilka kontenerów. Chciałbym udostępnić kontenerom połączenie VPN-owe, które zestawione jest na serwerze hoście. Uniknę tym samym tworzenia kilkunastu kluczy i stawiania połączenia VPN-owego w samym kontenerze. Próbowałem już wszystkiego, interfejsy tupu MACVLAN, BRIDGE, VETH, natowanie VPN-a i maskarada VPN-a. Żadna opcja mi się nie powiodła. Poczytałem już trochę również o interfejsie typu tap zestawiającym most. Być może powinienem zmienić swojego VPN-a na właśnie tego typu połączenie? Proszę zarzućcie jakieś pomysły, jakbym mógł to wykonać.

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.

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.