Fizyda

Z Ciekawości jak poradziłeś sobie z wygasaniem podpisanej strefy? Długi czas życia czy może cron, albo opendnssec? Mógłbyś powiedzieć jak w praktyce wygląda wymiana kluczy? Edytujesz DS czy może dodajesz nowe, a po aktualizacji usuwasz stare. Chodzi mi o to jak to zorganizować by nie było przerw w działaniu usługi, fakt nie potrzebuję tak niezawodnego rozwiązania w tej chwili, ale nie wiadomo co przyszłość przyniesie. Ostatnia rzecz jaka mnie męczy to jak często wymieniać klucze, teoretycznie KSK może być zmieniany rzadziej niż ZSZ, ale nigdzie nie udało mi się znaleźć informacji o jakimś rekomendowanym czasie po którym powinno się zmieniać jeden albo drugi lub oba nawet. Z wyjątkiem wycieku kluczy.

Zgadza się da się załatwić to za pomocą skryptów, ale tylko w przypadku gdy rejestrator udostępnia api, ja założyłem najgorszy scenariusz że takiego api nie ma, w tedy aktualizacja rekordów DS musi zostać dokonana ręcznie. Dla mnie dziwne jest to że sprawdzając ipko (nie znam adresów paneli klientów innych banków stąd taki wybór) nie mają oni wdrożonego dnssec. Google.com i facebook.com również nie mają dnssec. Czemu uważasz że to zależy od struktury serwerów. Nie da się rozbić raczej serwera DNS na kilka maszyn, a różnica między zwykłym DNS a DNSSEC jest taka że po aktualizacji strefy w przypadku drugiego należy wykonać dodatkową komendę i nic więcej. Dopytuję się i podważam trochę Twój argument ponieważ na pewno nie posiadam rozległej wiedzy w tej dziedzinie, dlatego też nie przekonałeś mnie nim. Jeśli możesz rozwiń trochę bardziej myśl, co może być przeszkodą we wdrożeniu DNSSECa.

Zobacz czy są oflagowane jako spam, jak tak można napisać skrypt co przeniesie wszystko automatycznie. Jeśli nie chyba powinno dać się zaprząc spamassasina by przeskanował wiadomości na dysku i je oflagował.

Nie zagłębiam się nigdy w licencje na tf, ale obstawiam że jest tak samo jak ze zdjęciami z fotolii na licencji standard czy istockphoto, czyli 1 klient 1 zakup. Tylko znając życie wielu szefów tnie koszty i nikt o tym nie mówi i Ci nie powie.

Baze możesz wywalić na oddzielny serwer, wp nie powstał do takich celów. Do takich celów tworzy się rozwiązania dedykowane, a nie używa się gotowych cmsów bo jest to tylko ryzyko w takim przypadku. Serwer może mieć 2 dyski, z jednego będzie korzystała baza z drugiego pliki. Bardziej niż pojemność dedyka martwiłbym się obsługą ruchu. Do przechowywania terabajtów danych stawia się macierze, jest to i bezpieczne i szybsze rozwiązanie. Swoją drogą backupy nadal nie będą mniejsze, ani o 1 Kb. Żeby zrobić pełny backup, nadal będziesz musiał zassać wszystkie media na stronie (filmy, zdjęcia, inny statyczny kontent), zrobić kopię bazy danych oraz skopiować pliki samego skryptu. W przypadku WP wszystko jest ładnie rozdzielone i właściwie jak nie modyfikujesz kodu WP wystarczy backup folderu wp-includes i bazy danych. No może jeszcze wp-config, chociaż tego łatwo odbudować. Jeśli nie chcesz kopiować mediów ze strony to kopiujesz zawartość wp-content bez folderu uploads oraz baze danych i nie pobierasz gigabajtów zdjęć i filmów. Pytanie tylko jaki sens ma taka niepełna kopia. A jeśli chcesz łatwo robić kopię tech gigabajtów danych to lepiej zrobić to po ssh przy pomocy jakiegoś narzędzia do synchronizacji plików, w tedy raz na 24h (zależnie od ustawień) pobierasz tylko różnicę w plikach, a nie cały zestaw danych. Dalej uważam że takie rozwiązanie jest lepsze zarówno wydajnościowo bo nie obciąża serwera, a do tego oszczędza transfer. Dodatkowo nie masz problemu z porządkiem w plikach. Nie ma sensu zmieniać struktury katalogów/plików w cms'ie bo prędzej czy później coś się walnie. Wystarczy że zainstalujesz plugin który np będzie robił coś na uploadowanych zdjęciach i co on zrobi jak na serwerze nie będzie plików? WP nadaje się pod małe strony, blogi, jakieś mikro portale. Totalnie nie nadaje się do większych projektów, a przynajmniej nie do takich które wymagają jakiś specyficznych rozwiązań od strony technicznej.

Wytłumacz mi w jaki sposób pliki te zasyfiają CI serwer? Edit: Może od razu wyjaśnię pewną sprawę, nie zrobisz tego na wordpressie bez znacznej integracji w silnik. Czyli po każdej aktualizacji wp musiałbyś go modyfikować, co w praktyce całkowicie eliminuje taką konfigurację bo taniej wyjdzie stworzyć własny cms i go utrzymywać. To co chcesz zrobić niesie ze sobą wiele konsekwencji, między innym takich że zwiększa się obciążenie serwera z aplikacją podczas dodawania/modyfikowania treści w momencie gdy korzysta ona z jakiś statycznych obiektów. Swoją drogą cdn służy do czegoś innego niż odśmiecania serwera ze statycznych plików.

Może się mylę, ale rozwiązanie tego tak jak chcesz zrobić jest utrudnianiem sobie życia. Ja bym ustawił cdna przez w3cache a cda skonfigurował jako revproxy na nginx. W tedy w razie potrzeby cdn pobierze pliki z serwera głównego na którym jest wszystko. W razie czego wszelkie pliki masz w jednym miejscu więc łatwo zrobić kopię lub przenieść stronę na inny serwer. Ogólnie większa elastyczność.

Mam zainstalowanego CSF i LFD, w obecnej chwili dostaję od lfd masę wiadomości o tym że jakiś proces działa zbyt długo, zjadł za dużo pamięci lub uruchomił ileś podprocesów. Oczywiście do walki z fałszywymi powiadomieniami służy csf.pignore, jak to ze wszystkim bywa tak i w tym przypadku nie można bezmyślnie wklepać wszystkiego jak leci. Dlatego też chciałbym się dowiedzieć jak whitelistować procesy z głową na przykładzie php. Mamy php-fpm z dwoma basenami, powiadomienia jakie dostajemy: Time: Account: Resource: Process Time Exceeded: 66163 > 1800 (seconds) Executable: /usr/sbin/php5-fpm Command Line: php-fpm: master process (/etc/php5/fpm/php-fpm.conf) PID: 2589 (Parent PID:493) Killed: No Time: Account: Resource: Process Time Exceeded: 66102 > 1800 (seconds) Executable: /usr/sbin/php5-fpm Command Line: php-fpm: pool jakasnazwa PID: 2657 (Parent PID:2589) Killed: No Time: Account: Resource: Process Time Exceeded: 66102 > 1800 (seconds) Executable: /usr/sbin/php5-fpm Command Line: php-fpm: pool www PID: 2658 (Parent PID:2589) Killed: No Do białej listy można dodać na 3 sposoby: exe:/full/path/to/fileuser:usernamecmd:command line Gdy dodam exe:/usr/sbin/php5-fpm z tego co się domyślam "wytnę" wszystkie powiadomienia. Druga opcja w tym przypadku odpada bo nie mamy informacji o Account. Trzecia cmd:php-fpm: pool www wydaje się najrozsądniejsza bo dodaję dla każdego basenu osobną regułę. Pytanie tylko czy dobrze zrozumiałem jak się tworzy te reguły i dobre rzeczy w nich wpisałem. Kolejna kwestia to który sposób wybrać i czym się kierować przy wyborze? Zastanawia mnie jeszcze jedna sprawa, na jednym z serwerów na którym działa lfd zainstalowany jest bind9 i z tego serwera nie ma powiadomień że bind działa ponad 1800 sekund. Dlaczego tak się dzieje? Jest to normalne zachowanie czy szukać problemu w lfd np. popsułem coś w konfiguracji chociaż świadomie nic nie zmieniałem.

Dla przykładu, jak najlepiej dodać php-fpm do wyjątków. Najlepiej, by nie dostawać powiadomień, ale dostać powiadomienie jak się zadzieje coś dziwnego, np uruchomiony zostanie dodatkowa pula dla php-fpm. Ostatnia rzecz jaka mnie interesuje to czy dobrze rozumiem działanie reguł wyjątków to: exe:/usr/sbin/php5-fpm wywali wszystkie powiadomienia niezależnie od "puli" user:www wywali wszystkie powiadomienia dla użytkownika www, nawet jak uruchomi coś innego cmd:php-fpm: pool www wywali powiadomienia dla tej konkretnej puli, ale no dla php-fpm: pool www2 dalej będzie wysyłał

Podyskutowaliśmy nad tłumaczeniem i na tym koniec? Nikt nic?

Słuszna uwaga, nie sprawdzałem domyślnej zawartości csf.pignore. Gdyby jednak nazwa była podana to dobrze myślę jak się dodaje reguły i w jaki sposób one zadziałają? W sumie nie pomyślałem, od razu skojarzyło mi się z "basenem" dla skryptów takie miejsce gdzie sobie mogą bezpiecznie przebywać.

Posiadam na matce jeden interfejs i 2 adres ip (publiczne). Serwer jest w ovh, drugi adres ip dodany jako eth0:0. Na serwerze mam też CSF'a i to za jego pomocą przekierowuję porty. Właściwie wszystko działa, jest tylko jeden problem wszystkie połączenia przychodzące na przekierowanych portach na kontenery pochodzą z adresu ip eth0:0. Czyli np z innego komputera łączę się z serwerem WWW i php widzi mojego adresu ip tylko podaje jako mój adres drugi (eth0:0) adres ip serwera matki z którego porty są przekierowywane. To raczej nie powinno tak działać. Kontener ma stworzonego bridga auto br-0 iface br-0 inet static bridge_ports none bridge_fd 0 bridge_maxwait 0 address 192.168.1.1 netmask 255.255.255.0 konfiguracja kontenera: lxc.network.type = veth lxc.network.name = eth0 lxc.network.flags = up lxc.network.link = br-0 lxc.network.ipv4 = 192.168.1.2/24 lxc.network.ipv4.gateway = 192.168.1.1 Przekierowanie portów w csf.redirect: publiczne_ip|80|192.168.1.2|80|tcp Co dziwniejsze dodanie takiej reguły powoduje że jeśli np połączę się z matki z kontenerem po telnecie: telnet 192.168.1.2 25 w logach mam też informacje o połączeniu klienta z adresu ip którym jest mój publiczny adres eth0:0. Ma ktoś jakiś pomysł? Bo mi już nic do głowy nie przychodzi. Podejrzewam, że wina leży po stronie csf, dokładniej tego jak generuje regułę iptables dla przekierowania portu. Chociaż jak znam życie na pewno ja coś skopałem i ustawiłem nie tak jak się to powinno robić, a wszystko mi działa bo głupi ma zawsze szczęście ... EDIT: Z WWW to taki przykład, problem trapi wszystkie usługi. Zdaję sobie również sprawę że NAT nadpisuje adres ip źródłowy i mapuje go sobie, ale chyba da się to obejść. W końcu jeśli mamy matkę i VPS to jakoś VPSy mają publiczne ip bez problemu i wszystko ładnie działa.

Już tyle rzeczy mi nie działało pomimo iż powinno, że już wszystkiego się spodziewam . Rozwiązanie jest w drugim linku. Ale łap tutaj jeszcze dodatkowo: Porty przekierowujesz w csfpre.sh # These are the forwards for 80 port iptables -t nat -A PREROUTING -p tcp -s 0/0 -d xx.xx.xx.xx --dport 80 -j DNAT --to 192.168.42.3:80 iptables -t nat -A POSTROUTING -o eth0 -d xx.xx.xx.xx -j SNAT --to-source 192.168.42.3 iptables -A FORWARD -p tcp -s 192.168.42.3 --sport 80 -j ACCEPT # These are the forwards for bind/dns iptables -t nat -A PREROUTING -p udp -s 0/0 -d xx.xx.xx.xx --dport 53 -j DNAT --to 192.168.42.3:53 iptables -t nat -A POSTROUTING -o eth0 -d xx.xx.xx.xx -j SNAT --to-source 192.168.42.3 iptables -A FORWARD -p udp -s 192.168.42.3 --sport 53 -j ACCEPT Abyś miał internet na kontenerze robisz maskarade tak by kontenery miały konkretny adres ip: iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to XX.XX.XX.XX lub dla wybranej podsieci # iptables -t nat -A POSTROUTING -s 192.168.42.0/24 -o eth0 -j SNAT --to-source XX.XX.XX.XX lub dla wszystkich ale z domyślnym ip matki: # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Nie wiem tylko czy MASQUERADE nie psuje adresu ip klienta przy przekierowywaniu portów. Pisał o tym tutaj (link z posta hemi): http://serverfault.com/questions/452183/keep-source-ip-after-nat dodatkowo by internet działał musisz zezwolić na forwarding pomiędzy interfejsem a bridgem: iptables -A FORWARD -i eth0 -o br-0 -j ACCEPT iptables -A FORWARD -i br-0 -o eth0 -j ACCEPT I tyle. XX.XX.XX.XX to twoje publiczne IP z którego mają być przekierowane porty przychodzące, lub w drugiej części adres ip jaki mają mieć kontenery na zewnątrz. Po # są reguły których nie używam.

Nie zastosowałem jego rozwiązania bo miałem je już wpisane w csfpre.sh by contenery gdy łączą się same z internetem miały konkretny adres ip. Zastosowałem za to jego reguły przekierowania portów i poszło, wszystko działa jak powinno. Nie wiem czemu, ale już nie wnikam. Dzięki za pomoc, jutro dam Ci plusy bo w nocy wyczerpałem limit :/. Pytanie tylko czy będzie na tym działać https i reszta usług z (s).

Niestety nie pomogło, nawet wyłączyłem CSF i dodałem reguły z palca, nic się nie zmieniło cały czas widoczne jest ip matki.

Witam, potrzebuję małej podpowiedzi jak skonfigurować wysyłkę powiadomień (maili) dla LFD. Mój system to Debian Jessie, z tego co zauważyłem nie posiada on domyślnie zainstalowanego sendmaila, przez co daemon LFD pada mi w momencie próby wysyłania powiadomienia. Nie wiem czy instalować na każdym serwerze sendmaila (albo postfixa bo sendmail jest dość stary i chyba dziurawy), czy może lepiej skonfigurować LFD by używał zewnętrznego serwera SMPT którego posiadam na jednym z serwerów. Bez względu na rozwiązanie chcę by maile ze wszystkich serwerów i tak szły na skrzynkę mailową na moim SMTP. Dlatego też zastanawiałem się czy nie konfigurować LFD do używania mojego SMPT i dodać je do mynetworks. Problem z mynetworks polega na tym, że serwery te to kontenery LXC, w teorii mogą być w jednej podsieci i ze sobą się komunikować w praktyce nie mogę tego skonfigurować. Nie wiem czy teraz na każdym serwerze konfigurować postfixa z przekazywaniem maili na matkę i na matce postfix z przekierowywaniem maili na smtp, czy może jakiś inaczej to zrobić? Konfiguracja wygląda w następujący sposób: LXC-s1 IP: 192.168.1.2; Gateway: 192.168.1.1; chce ustawić: LFD-mailto: admin@domena.pl LXC-s2 SMTP: domena.pl IP: 192.168.2.2; Gateway: 192.168.2.1; LFD-mailto: def/root LXC-s3 IP: 192.168.3.2; Gateway: 192.168.3.1; chcę ustawić: LFD-mailto: admin@domena.pl W takiej konfiguracji co dziwne działają pingi np z S1 do 192.168.2.1 (bridge na matce). Nawet jeśli ustawię S1 i S2 by działały w tej samej pod sieci i na tym samym bridge to nie mogą się wzajemnie spingować. Nie wiem w czym tkwi problem. Kontenery są w różnych podsieciach ponieważ początkowo nie miały one się ze sobą komunikować, aż do czasu jak nie ogarnąłem jak fajny jest lfd . Myślałem też nad ustawieniem na S1 i S3 serwera SMTP po publicznym adresie IP dla mojego SMTP, ale czy to ma sens? No i jak zezwolić tym hostom w takim wypadku wysyłać maile bez uwierzytelnienia SASL.

Jakoś poszło i jakoś działa, niestety wydaje mi się że to przez błąd w konfiguracji restrykcji dla postfixa. Przykład jak ustawiłem to na matce: LF_ALERT_TO = root@s2.mojadres.pl - jest to alias na virtualne konto LF_ALERT_FROM = LF_ALERT_SMTP = 192.168.2.2 Przy takim ustawieniu zauważyłem że matka łączy się z smtp na s2 przez zewnętrzne ip z którego porty 25, 587 są przekierowane na s2. Pytanie dlaczego się tak dzieje. Po małych testach doszedłem do wniosku że dzieje się tak w momencie gdy w csf.redirect mam ustawione przekierowania w analogiczny sposób: publiczneIP|20|192.168.121.2|20|tcp dla adresu ip S2, nie ma znaczenia jakie porty przekieruję, matka łączy się w tedy z s2 przez to publiczne ip, pomimo że robię telnet 192.168.2.2 25. Jest to dla mnie co najmniej bezsensu. Niemniej dzięki temu zauważyłem że po podłączeniu się przez telnet (z zewnątrz - sprawdzone z innej maszyny/ip) mogę wysyłać maile z nieistniejących kont na konta które istnieją i są obsługiwane przez mój serwer SMTP. Nie wiem, może się mylę, ale moim zdaniem jest to dziura. Oczywiście maile takie można wysyłać bez uwierzytelniania. Powiem więcej byłem w stanie wysłać na na swój adres, w swojej domenie maila jako z konta na gmailu. Wszystko to bez jakiejkolwiek autoryzacji.

Chyba nic by to nie dało bo odpowiedziałbym że wszystko jest ok ponieważ wszystko działa. Usługi dostępne z zewnątrz matka też ma do nich dostęp, do niczego się nie można przyczepić. Brak maski to ciekawa historia, dobrze że sobie przypomniałem że ją usunąłem jak konfigurowałem kontenery na produkcyjnym serwerze, inaczej nigdy bym do tego nie doszedł. Usunąłem je bo miałem je usunięte na testowym serwerze, a tam były usunięte w momencie jak ustawiałem w cfg kontenera by korzystał z interfejsu matki, w tedy ustawiłem statyczny adres ip bez maski, a gdy przełączyłem się znów na bridge, nie dopisałem go. Na początku każdy kontener przełączałem na fizyczny interfejs bo nie działał na nich internet, dopiero potem kapnąłem się, że problem jest z dnsami które nie są ustawione na nowych kontenerach i wystarczy edytować resolv.conf i dodać dnsy z matki by działał internet na kontenerach. Normalnie człowiek jest głupi przez całe życie, a przynajmniej mnie to czeka . PS. Idę prze konfigurować produkcyjny i jak coś nie będzie działało to jeszcze tutaj wrócę

@mariaczi dzięki wielkie za zaangażowanie i pomoc w próbie naprawienia czegoś co działać musi, ale jak zwykle okazało się, że to ja jestem kretynem . Okazało się, że nie miałem ustawionej maski na kontenerach lxc ... głupi ja .. ale co zrobić . Jeszcze raz dzięki za chęć pomocy, nie zawsze udaje się trafić na kogoś pomocnego

Firewall to csf ICMP_IN/OUT = 1. Matka bez problemu pinguje kontenery, kontenery matkę, ale już nie inne kontenery. Nawet w konfiguracji gdzie każy kontener ma swojego bridga i swoją podsieć kontenery są w stanie spingować ip bridga na matce który ma adres ip z innej podsieci. Ogólnie ip Gateway: 192.168.1.1 to adres ip bridge na matce.

Firewall na matce jest, sprawdzałem pingiem (ping 192.168.2.2)

Nginx nie korzysta z htaccess, musisz je przekonwertować, albo przepisać.

Racja mój błąd, pomyliłem procesy z wątkami ... niedziela rano, wybaczcie

To znaczy że w tym samym czasie możesz mieć uruchomionych 16 procesów, domyślam się że ograniczenie dotyczy to jednoczesnych żądań do serwera dla Twoich wszystkich stron. Więc jeśli w tym samym czasie 20 użytkowników będzie chciało dostać się do którejś strony 4 dostanie strony z błędami.

Instalacja TS3 nie jest skomplikowana, pytanie tylko czy należy coś bezwzględnie zrobić by zabezpieczyć serwer, no i chrootować czy nie? Z postów na forum wynika że TS3 jest dość dziurawy. Gdy pytałem o samego chroota dowiedziałem się, że jeśli aplikacja go oferuje to warto robić (http://www.webhostingtalk.pl/topic/53940-linux-jailchroot-kiedy-stosowac/?p=461823). Z tego co widzę TS3 nie oferuje chroota, ale @Archi napisał też, że pojedyncze aplikacje jak TS warto chrootować. Więc jak to jest? Poza chrootowaniem coś jeszcze z security dla TSa czy mu wystarczy? EDIT: Jakaś dokumentacja, manual do ts to istnieje ?