Fizyda

Instaluję sobie BINDa i chcę go zamknąć w chroocie. Robię to zgodnie z tym poradnikiem: https://wiki.debian.org/Bind9#Bind_Chroot Mój system to debian 8 z systemd. Problem mam bo zupełnie nie rozumiem tej linijki: Jestem słaby z angielskiego ale nie sądziłem że aż tak bardzo . A tak serio to po prostu nie wiem jak utworzyć ten plik, zmyliło mnie to z opcjami "-t /var/bind9/chroot". Chodzi o opcje podczas tworzenia pliku czy o co? Może to jakiś błąd autora tego poradnika. Stworzyć plik normalnie touch /etc/systemd/system/bind9.service i wkleić to co podano niżej, czy o co chodzi .

Dobra nie było tematu już wszystko wiem, dzięki za pomoc.

Zamotałem się przy konkretnie w tym momencie: Dlaczego? Bo pod tą linijką podana jest konfiguracja jaka ma zostać zapisana do tego pliku, a z tej linijki trochę wynika jakbym miał zrobić coś w stylu: touch /etc/systemd/system/bind9.service -t /var/bind9/chroot Tylko że to nie przejdzie i nie wiem czy ja nie wiem o jakimś sposobie tworzenia plików gdzie istnieje jakiś dodatkowy parametr -t w którym podaje się ścieżkę czy może to trochę błędnie jest wyjaśnione i część pogrubiona odnosi się do zawartości pliku, ale że ta jest podana niżej z tą ścieżką to zgłupiałem. Ale jeśli problemem jest dla Ciebie napisanie jednego z dwóch zdań: 1) utwórz plik normalnie, a ta ścieżka odnoś się do konfiguracji w pliku / parametr i ścieżka nie wiem po co są możesz zlać 2) musisz użyć polecania xyz to ja dziękuję za Twoją pomoc idź "pomagać" innym i obyś w razie potrzeby trafił na taką samą pomoc jaką Ty udzielasz. Temat ma już 7 postów a spokojnie można było go zakończyć w 3.

1. pokaż mi na Twojej liście chociaż jedno polecenie do tworzenia plików 2. nie jestem robiony patykiem i sprawdziłem znane mi komendy czyli touch oraz vim, pierwszy parametr t przyjmuje ale jest nim data, a nie ścieżka. Jeśli Twoja pomoc ma być taka to lepiej skończ, ogólnie to Twoje wiadomości w tym temacie nic nie wnoszą i są spamem więc dla mnie to powinieneś dostać warna.

Jakbym wiedział o co chodzi i jaka komenda posiada takie opcje do tworzenia pliku to bym nie pytał.

Podczas konfigurowania iptables (CSF) do działania z kontenerami LXC (dalej nazywane VM'kami) zacząłem zastanawiać się nad ruchem wychodzącym oraz bezpieczeństwem. CSF domyślnie blokuje większość portów wychodzących (OUTPUT) i pozostawia tylko kilka otwartych między innymi 53, 80, 443. Zacząłem zastanawiać się czy takie srogie restrykcje mają jakieś uzasadnienie pod kątem bezpieczeństwa, czy ma to jakiś sens. Moja konfiguracja wygląda w ten sposób że host pełni rolę routera. Na VMki przekierowywane są konkretne porty w zależności od usług które na nich działają. Zrobione jest to przez csf.redirect. Prosto i skutecznie, lecz w takiej konfiguracji VMki nie mają połączenia z internetem. Brak komunikacji z internetem dla VMek to spory problem bo nie można zaktualizować nic, ani zainstalować, dodatkowo jeśli np serwer HTTP będzie miał jakiś skrypt w PHP który pobiera coś z zewnętrznego serwera to zwyczajnie nie będzie działał. To samo tyczy się np TS3. Sposobem jaki znalazłem na to by VMki miały połączenie z internetem (dla ruchu wychodzącego) jest dodanie reguł w csfpre.sh: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Co jest zaczerpnięte stąd https://wiki.debian.org/LXC/SimpleBridge, plus zezwolenie na forwarding (csf ustawia domyślną politykę na drop) iptables -A FORWARD -i eth0 -o br-vm0 -j ACCEPT iptables -A FORWARD -i br-vm0 -o eth0 -j ACCEPT Takim oto sposobem mam połączenie z internetem na VMkach oraz przekierowane odpowiednie porty. Problem jest taki że ruch wychodzący z VMek jest jakby poza firewallem hosta, co za tym idzie jeśli np. na hoście zablokuję cały ruch wychodzący VMki i tak mogą się łączyć z internetem. Ponieważ nie da się zrobić przekierowań nat za firewallem, a przynajmniej tak przeczytałem na jednej ze stron to zacząłem zastanawiać się jak to naprawić. Jedyne co mi przyszło do głowy to instalacja CSF na VMkach, tylko szkoda zasobów i instalowania tego co już jest na hoscie. Dlatego zacząłem się zastanawiać czy jest w ogóle sens blokowania ruchu wychodzącego. Jeśli jest to jaki? W obecnej konfiguracji VMki i tak są ukryte w sieci lokalnej, a ruch przychodzący jest przekierowywany do nich taki jak ustawię na hoście. Więc czy instalować CSF na VMkach lub chociaż konfigurować na nich firewall (iptables)? -- lekki offtop -- Dodatkowo mam dziwną sytuację bo po jakimś czasie csf blokuje mi dostęp do SSH na hoście. Dziwna bo przeinstalowałem dziś CSF ponieważ miałem właśnie ten problem i myślałem że coś na grzebałem w plikach i w sumie wszystko działało przez jakiś czas. Teraz problem jakby powrócił, a ustawień nie zmieniałem. Klient SSH nie jest blokowany w hosts.denny bo sprawdzałem w iptables również brak jego ip. Nie aktualne, znalazłem przyczynę - zbanowało mnie co innego EDIT: Tak sobie myślę firewall na VMkach w sumie się przyda, bo ruch po przekierowanych portach i tak nie jest filtrowany przez firewall hosta więc przyda się coś do blokowania wszelkiego rodzaju syfu nawet na porcie 80/443 a tym bardziej przyda się to do zabezpieczenia TS3 by filtrować pakiety które mają ubić serwer. Chyba muszę zacząć stosować metodę gumowej kaczuszki Dużo przemyśleń mam a co za tym idzie często doznaję olśnienia chwilę po wysłaniu posta

Jakie funkcjonalności oraz ile podstron?

A czy przypadkiem taka sytuacja nie wystąpi jeśli adres ip serwera trafił na jakąś czarną listę?

Ceny netto czy brutto?

https://www.ovh.pl/vps/vps-cloud.xml Ale przy cenie 100zł i więcej na mc to ja bym zastanawiał się nad dedykiem od https://www.kimsufi.com/pl/serwery.xml A jak z zarządzanie to przepraszam, nie pomogę. Ale może lepiej kogoś sobie załatwić na umowę zlecenie i brać go do zwykłego vps/dedyka w momencie jak trzeba coś zrobić. Wydaje mi się że wyjdzie to taniej.

Francja to DC ovh? Jest możliwość dokupienia adresów ip? Jaka cena? Jaka wirtualizacja?

Jak w temacie, ponieważ sam nie umiem tego zrobić zlecę komuś kontenera LXC nieuprzywilejowanego na serwerze z systemem debian jessie. Kontener musi być nieuprzywilejowany, mieć system debian jessie oraz autostart. Mile widziana konfiguracja z wytłumaczeniem. Osobie która się na tym zna nie powinno zająć to więcej czasu niż 1h, ba nawet mniej wraz z wytłumaczeniem zwłaszcza że kontenery ogarniam nie mogę sobie jedynie poradzić z kontenerami nieuprzywilejowanymi. Cena myślę że 50zł, ale jeśli ktoś oczekiwałby więcej niech napisze jeśli nikt nie znajdzie się w tej cenie być może zapłacę więcej.

Nie aktualne ogarnąłem sam.

To co ty chcesz płacić tylko za same ip? Nawet jeśli cena za ten twój "slot" to ma być cena z opłatą serwera i adresm ip to i tak wychodzi niewiele ponad limit. Zakładając że serwer wynajmujesz na co najmniej 3 miesiące to cena za miejsce na serwerze + ip (slot) wyjdzie: (3 * 470 zł + 128 * 8 zł) / 3 [miesiące] / 128 [sloty] = 6,34 zł slot/mc Zakładając że serwer potrzebujesz na 3 miesiące a im dłużej będziesz go używał tym taniej będzie. Dla 4 miesięcy wynajmu masz już 5,67 zł za slot na miesiąc.

Wydaje mi się że 8 / 3 = 2.66 więc jest to poniżej Twoich oczekiwać i nie rozumiem czemu w takim razie uważasz że OVH ma za drogie ip skoro wychodzi taniej niż chcesz zapłacić. Ale jeśli chcesz mogę Ci zaoferować 4zł za adres ip miesięcznie na takim samym serwerze jak chciałeś na OVH, cena serwera ta sama co na OVH, ale warunek taki że okres wynajmu minimum 2 miesiące, później może być płatności miesięczna.

Cześć, mam mały kłopot z którym nie mogę sobie poradzić. Próbuję utworzyć nieuprzywilejowane kontenery na Debian Jessie, jednak już od momentu tworzenia ich mam z nimi niemały problem. - TWORZENIE - Pierwszy problem jaki spotkałem to problem z nadawaniem uid i gid - wystarczyło doinstalować uidmap. (1) Później na lxcusr (użytkownik na którym ma działać kontener, ma utworzone potrzebne katalogi i default..conf dla lxc z podanymi subuid i subgid dla niego, nie tworzyłem domyślnych wziąłem zakresy te które już miał z /etc/{subuid subgid)) nie mogłem w ogóle utworzyć kontenera, ale szybko wygooglałem problem i rozwiązanie: https://lists.debian.org/debian-user/2015/05/msg00162.html Po tych zabiegach mogłem już tworzyć kontenery, ale szybko pojawił się problem, mianowicie brak Debian Jessie na liście systemów dla kontenera którego tworzę. Jako root spokojnie mogę stworzyć kontener z Debian Jessie i jest on na liście dostępnych (lxc-create -t download -n container1). Wiem że są 2 różne listy dostępnych systemów dla kontenerów z zależności od typu konteneru (root i unprivileged), tylko ludzie normalnie mogą tworzyć unprivileged kontener z Debian Jessie na np Ubuntu. Moje pytanie jest takie czym to jest spowodowane? Wyczytałem coś że to problem z systemd pod debianem i trzeba zastosować jakąś łatkę z Ubuntu. Ale w szczegóły nie wchodziłem bo to były informacje sprzed roku i zastanawiam się po prostu czy to nadal jest aktualne. - URUCHAMIANIE - Stworzyłem dla testów kontener Debian Wheeze ale nie potrafię go uruchomić oto błędy jakie dostaje po próbie uruchomienia kontenera: lxcusr@debian:~$ lxc-start -n test1 lxc_container: Permission denied - Could not create cgroup '/test1' in '/sys/fs/cgroup/perf_event'. lxc_container: Read-only file system - cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event/ lxc_container: Read-only file system - cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio/ lxc_container: Read-only file system - cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls,net_prio/ lxc_container: Read-only file system - cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer/ lxc_container: Read-only file system - cgroup_rmdir: failed to delete /sys/fs/cgroup/devices/ lxc_container: Read-only file system - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu,cpuacct/ lxc_container: Read-only file system - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset/ lxc_container: failed creating cgroups lxc_container: failed to spawn 'test1' lxc_container: The container failed to start. lxc_container: Additional information can be obtained by setting the --logfile and --logpriority options. Dodatkowo żeby móc uruchomić kontener - przepraszam spróbować, muszę zastosować rozwiązanie (1) inaczej znów nie mam uprawnień. Skoro przed nawet uruchomieniem muszę zmienić jakieś ustawienia to czy to nie będzie problem w momencie gdy będę chciał uruchomić kontener wraz ze startem systemu? Jak temu zapobiec?

Przedwczoraj sprawdziłem jeszcze jak działa LXC z wersji Stretch i tutaj małe zaskoczenie to właśnie wersja LXC pod Jessie wygląda jakby była jakaś uboga jeśli chodzi o obsługę kontenerów nieuprzywilejowanych. Wersja z Stretch widzi wszystkie wersje Debiana Jessie Sid i Stretch, włącznie z Wheezy którego widzi ta z Jessie jako jedyną wersję debiana. Dodatkowo w LXC z wersji testowej debiana nie ma problemów z uruchomieniem kontenerów, jedyne co napotkałem to niemożliwość zalogowania się przez lxc-console do takiego kontenera. lxc-attach działa bez problemu (ssh nie sprawdzałem) a przez konsole nie idzie. Po podaniu loginu i hasła pojawia się komunikat: cannot make/remove an entry for the specified session I znów proszony jestem o podanie loginu i hasła. No i są jeszcze jakieś informacje o systemie. W razie potrzeby mogę podrzucić pełny widok z konsoli.

Żeby było ciekawiej zaktualizowałem systemd do wersji dostępnej w wersji testowej Stretch. Zarówno na 215+17+deb8u3 jak i 229-4 mam ten sam problem przy starcie konteneru z ograniczonymi uprawnieniami. Nie mam już pomysłu jak yo ugryźć i uruchomić nieuprzywilejowany kontener z system debian jessie na hoscie z debian jessie.

Jaka forma umowy oraz mniej więcej jak to wygląda cenowo - wiadomo każdy projekt wyceniany jest indywidualnie, ale orientacyjnie trzeba wiedzieć czy warte jest to zachodu .

Witam, wiem jestem upierdliwy do znudzenia i ciągle męczę jeden temat. Niestety nic nie poradzę gdy już zagłębiam się w jakieś zagadnienie to chcę znać jak najwięcej aspektów z nim związanych. Tym razem znów pytanie o LXC, ale raczej ma ono na celu upewnienie się, że dobrze wszystko zrozumiałem no i uporządkowanie mojej wiedzy ponieważ my english isn't good więc mogłem coś źle zrozumieć. CGroups Czy muszę je tworzyć dodatkowo dla kontenerów? Czy wystarczy użyć ustawień w lxc.container.conf do ustawień cgroup czyli: lxc.cgroup.* Namespaces Dobrze rozumiem że służy to tylko po to by dany kontener nie był uruchamiany na hoscie z uprawnieniami root oraz jego ścieżka była w home użytkownika z uprawnieniami którego ma być on uruchamiany. Jeśli dobrze rozumiem to mniej więcej trzeba to zrobić w następujący sposób: 1. utworzyć użytkownika 2. ustawić usermod --add-subuids 100000-165536 lxcuser usermod --add-subgids 100000-165536 lxcuser + chmody 3. utworzyć ~/.config/lxc/default.conf z odpowiednimi parametrami czyli między innymi: lxc.id_map = u 0 100000 65536 lxc.id_map = g 0 100000 65536 4. utworzyć plik /etc/lxc/lxc-usernet - tylko trochę nie wiem jeszcze po co? 5. jako user na którym ma być uruchamiany kontener utworzyć ten kontener. Jeśli się nie mylę do tej pory to czy można np uruchamiać kontener z uprawnieniami konkretnego usera istniejący już kontener oraz czy taki kontener może być w domyślnej lokalizacji /var/lib/lxc/container (czy ma to sens i jest bezpieczne)?

Jak to jest, nikt nic nie wie na ten temat, czy może nie mylę się i nic więcej nie ma do dodania?

Osobiście zabezpieczyłbym stronę inaczej. Przeniósłbym pliki wp do podkatalogu w katalogu domeny, plus wcześniejsza konfiguracja wordpressa tak by url był do katalogu głównego domeny, a ścieżka do plików do tego utworzonego. Następnie kopiujesz index.php wordpressa do katalogu głównego domeny i zmieniasz ścieżkę do ładowanych plików. Teraz wyciąłeś 90% szkodników które sprawdzają jedynie ścieżkę mojadome.pl/wp-admin bo żeby zalogować się do panelu musisz wpisać moja.domena.pl/nazwafolderu/wp-admin. Ostatni etap jeśli problem nadal występuje to ewentualnie założenie hasła w htaccess dla wp-admin. Logujesz się jak wyżej ale musisz dodatkowo podać hasło. Nawet jak coś będzie próbowało złamać hasło to wygeneruje mniejsze obciążenie niż gdyby łamało hasło do wordpressa bo teraz nie wczytywane są jeszcze pliki php. To z takich prostszych rozwiązań. Najlepsze dałoby gdyby całkowicie ukryć wordpressa plus przeniesienie jego plików do podkatalogu. Da się to zrobić, ale nie jest łatwe, a te łatwe sposoby nie są darmowe.

Bawię się kontenerami LXC jak na razie, właściwie to jeszcze się nie bawię bo nie mogę ich podpiąć do internetu. Od 2 dni męczę temat próbowałem różnych kombinacji i nic. Jedyne kiedy działają to gdy ustawię lxc.network.type = phys i podlinkuję bezpośrednio eth0. Próbowałem przy pomocy bridge (https://wiki.debian.org/LXC/SimpleBridge) oraz vlan (https://wiki.debian.org/LXC/VlanNetworking) w obu przypadkach dupa, niby dostaje adres ip z dhcp, ale kontener z niczym się nie może połączyć. Finalnie chciałbym uzyskać mniej więcej taką konfigurację, że mając na host: eth0 oraz eth1 (różne public ip) przekieruję ruch z konkretnych portów na konkretny kontener. Plus kontenery mogą się łączyć po lan. Czyli np. z eth0 port 11 przekieruję na kontener LXC A1 z eth1 port 12 przekieruję na kontener LXC A1 z eth0 port 22 przekieruję na kontener LXC B2 A1 może łączyć się po lan z B2 Na początek będę zadowolony jeśli uda mi się w ogóle przekierować z eth0 chociaż jeden port na jakikolwiek kontener i będzie on miał dostęp do internetu. Ponieważ w temacie jestem nowy to gdybym miał to co chcę skonfigurować porównać do czegoś co już znam to porównałbym to do routera domowego. Mamy sieć lan gdzie są komputery i wszystkie łączą się przez jeden adres ip, dodatkowo mogę przekierować wybrany port na wybrany komputer w sieci. Jak czegoś takiego dokonać w linuxie? Obecnie brak mi już pomysłu w którą stronę iść, z początku myślałem że rozwiązaniem będzie vlan, ale jak poczytałem to zaczynam wątpić czy to do tego służy co chcę zrobić, poza tym w ogóle LXC nie chce łączyć się przez vlan. Jest toś w stanie coś podpowiedzieć, pomóc?

Dla potomnych rozwiązanie jest tutaj, albo właściwie jego brak: http://www.debian.pl/viewtopic.php?t=24024. Jak coś na virtual boxie nie da się zrobić mostu mostu i średnio działa virtualziacja na virtualizacji. 4 dni zmarnowane idę szukać rozwiązania które pozwoli obejść tę niedogodność. EDIT: Po ustawieniu w virtual boxie adaptera na NAT wszystko działa jak należy, problem jest taki że nie mam jak dostać się teraz zarówno do hosta (vps virtualbox) a tym bardziej do kontenera w nim uruchomionego.

Na razie w domu, więc adresów ip nie braknie. Poza tym ja chcę w ostatecznej konfiguracji mieć minimum dwa, a maksymalnie trzy kontenery na które ma być przekierowany ruch przychodzący na konkretnych portach z jednego zewnętrznego ip. Zewnętrzne adresy ip na dedyku będą 2. W razie potrzeby mogę kupić dodatkowe ip, ale nie widzę takiej potrzeby. W domu dhcp przydziela tylko 3 urządzeniom stały adres ip po mac, reszta m adres na 24h. Zawsze pamiętam by posprawdzać sobie co dostało jaki adres.