Pan Kot

Widzisz, różnica jest taka że mi jako userowi to rybka co piszesz, do kogo piszesz i o czym piszesz. Próbujesz "zaszpanować" po raz n-ty na tym forum, tym razem pokazując i podkreślając, że umiesz używać proxy i się zarejestrować pomimo bana. Nie wiem komu w ten sposób chcesz zaszpanować, ale chyba nawet w podstawówce dzieciaczki już takie sztuczki znają . Jeśli chcesz, żeby Cię traktowano poważnie to przestań z siebie robić pajaca. Pisząc takie tematy tylko potwierdzasz, że nie jesteś poważny.

No tutaj to pierw trzeba podstaw systemów operacyjnych, a nie klepania na ślepo komend. Jeśli nie rozumiesz danej komendy to się jej nie klepie na ślepo tylko gogluje co robi.

Ojej, umiesz używać proxy, no proszę . Popisz jeszcze trochę to może ktoś się tym przejmie. A najlepiej skończ pajacować .

Odporne, ale zależy w jakim sensie. Całość wygląda tak: server { listen 80; root /home/user/www; # I inne bzdety include /home/user/nginx/user.vhost; } A chyba servera w serverze się nie da zaincludować afaik.

proxy_pass można zabronić, dyrektywę root można ustawić stałą. Symlinka user nie stworzy (chyba, że pointującego do jego folderu/pliku) bo tak działa grsec enforce. P.S. To co napisałem już mam. Myślałem o czymś bardziej złożonym .

Jeśli w ten sposób do tego podchodzisz "czy to by coś dało" to nie, nic nie da bo będzie milion innych dziur w samej aplikacji . Security polega na łataniu niewielkich dziur, a wprowadzenie całości zmian dopiero daje zadowalający efekt. Jeśli nie rozumiesz jak to działa i po co to jest to nie klep na ślepo komend tylko poczekaj na sytuację, aż będziesz musiał zrozumieć .

Oczywiście, że nie. Generalnie taką komendą tylko dodajesz usera i wskazujesz mu home, który i tak jest przecież identyczny jak opcja bez parametru -home. Poczytaj o chroot jak chcesz mieć pełną izolację. Jak się pobawisz to wrzucisz userowi shella + wymagane biblioteki dla TS'a. Ja się w chrooty nie bawię bo są zbyt problematyczne na dłuższą metę, zwykły user bez shella (/bin/false) + grsec untrusted i enforce mi wystarcza.

Jeśli blokujesz go w bloku server { } to nie może popsuć czegokolwiek co wpływa na inne bloki server { }. Co najwyżej może popsuć config, a od tego mam fallback. Pewnie, jakby się uprzeć to można to zabusować, ale mam zaufanie do tego co hostuję u siebie. Poza tym nie wiem jaka mogłaby być najbardziej szkodliwa rzecz, którą można wrzucić w blok server { }. Może @patrys mi pomoże .

@Rolej Otóż to. Przyjrzyj się chociażby takiemu nginxowi czy apache'owi. Master proces działa jako root, ale wszystkie swoje dzieci (workerów) forkuje z userem www-data, czyli de facto procesy obsługujące samego apache'a działają na userze www-data, a nie roocie. Na roocie działa tylko master proces, który odpowiada za forki. Taką politykę ma większość aplikacji, proftpd który działa na userze ftp, bind9 który działa na userze bind, mysqld który działa na userze mysql i wiele innych. Tak to chociażby wygląda u mnie. Nawet serwer TS'a i music bot jest oddzielony i działa na innym userze. Zauważ, że nawet interpretery php są u mnie oddzielone i każdy vhost ma swojego usera. Dodatkowo jeśli to user serwisowy czyt. nikt nie musi się na niego logować via SSH to bardzo dobrym pomysłem jest mu zabronić logowania poprzez zmianę shella na /bin/false. W przeciwnym wypadku np. jeśli to user FTP to bardzo dobrym pomysłem jest użycie jaila sftp-internal, o którym napisałem w pierwszym poście. Jeśli obowiązkowo musi on mieć shella to dobrym pomysłem jest opcja GRSecurity Untrusted + Enforce przez co nie może on odpalać żadnych własnych binarek, a korzystać wyłącznie z tego co już jest w systemie. To czasem się przydaje np. jeśli chcesz użytkownikowi pozwolić tylko na bardzo podstawowe akcje na systemie, a ubezpieczyć się na ew. exploity - nie skompiluje i nie uruchomi niczego co sam wgra.

Rewrite? Czysty nginx nie ma żadnych regułek i chociażby przyjazne dla SEO linki Ci działać nie będą. To jest jedna linijka, o której wspomniałem wyżej. A czasem i wiele innych, które są wymagane.

Jeśli rzeczywiście masz taką opinię to nie masz żadnego pojęcia po co i dlaczego powinno się konwertować .htaccess na nginxowy config . Nikt tu nie mówi o parsowaniu .htaccess co request bo to rzeczywiście jest bezsens, ale opinia że .htaccess jest zbędne i nie należy w ogóle tego dotykać jest nieco śmieszna .

Nie bierz tego aż tak dosłownie . Na produkcję bym czegoś takiego nie wrzucił, przecież dlatego właśnie bashowy skrypt zrobiłem. Cóż... Zobacz: root@archi ~ # date +%s 1377435188 root@archi ~ # stat -c %Y fixpax.sh 1375998906 A teraz prosty skrypt bashowy wrzucony do crona, który co np. 5 min. sprawdza każdy plik *.vhost z /home/*/nginx i jeśli różnica date'a ze statem jest mniejsza niż... no właśnie . Reszta już powinna być prosta.

date i stat pliczek.vhost . Unix time jest bardziej użyteczny niż większość osób sądzi. Chyba, że chodzi Ci o sam fakt sprawdzania plików to na początku sobie dodałem moduł do kernela, ale stwierdziłem, że to słabe rozwiązanie i prosty skrypt w bashu sprawdzający działa nieco lepiej.

Ja to zrobiłem na bazie pliku typu user.vhost, który sobie includuję w głównym bloku server {} usera via include /home/user/system/user.vhost, a zmiana tego pliku automatycznie wywołuje service nginx reload. W ten sposób user może sobie sam definiować regułki i nawet całego swojego vhosta bez dostępu do innych plików i userów. Oczywiście symlink /home/user/system/user.vhost -> /etc/nginx/sites-available/user -> /etc/nginx/sites-enabled/user. Plus ostatnio dodałem do tego fakt, że jeśli reload zwrócił inny kod niż 0 (czyli error) to powraca poprzednią wersję pliku, a user.vhost zmienia na user.vhost.bugged.

sldc.pl

Mogę rzucić pingdomem i wskazać downtime'y z mojej winy (updaty kernela i inne restarty). Na przestrzeni ostatnich 4 miesięcy (3 miesiące kimsyf z RBX i teraz z GRA za 15 zł) uptime osiągnął kolejno 99.97%, 100%, 99.98% w danych miesiącach oraz 99.86% obecnie w sierpniu z powodu godzinnego downtime'u podczas kilku zmianach w kernelu wykonywanymi przeze mnie, także można liczyć 99.99%. Jak ktoś sobie życzy udostępniam pingdoma poprzez PW . Co jak co, ale do OVH w sprawie sieci się przyczepić nie mogę. Do wielu innych aspektów tak, ale nie do sieci i stabilności.

Wielki szum o htaccess ogranicza się najczęściej do napisania jednej linijki, żeby serwis w ogóle działał i do kilkunastu jeśli serwis ma być również zabezpieczony z odpowiednimi uprawnieniami. Pomijając fakt, że masz gotowe formułki do znalezienia na googlu, chyba do każdego możliwego popularnego skryptu to zamiana .htaccessu na nginxowy config to też roboty na kilkadziesiąt minut max.

Jaką odpowiedź chcesz uzyskać? OVH ma jedną z najmniej awaryjnych infrastruktur (sieć), ale do kimsyfów nie świadczą dłużej supportu technicznego, więc jak masz dość duże pojęcie o administracji i umiesz sobie sam poradzić, a Twój kontakt z supportem ogranicza się do wymiany uszkodzonych dysków to pewnie, czemu nie. Nie zmienia to jednak faktu, że nic mocno produkcyjnego bym na tym nie postawił, chyba że z RAID'em, ale to wtedy już nie kimsyf, bo kimsyfy raidu nie mają jak wiemy. Generalnie jako maszyna do własnych projektów, testów czy nawet hostowania mniej znaczących stron sprawdza się wyśmienicie, nic nie kosztuje, a i parametrami sprzętowymi przewyższa wszystko za swoją cenę. Jeśli natomiast chodzi o wsparcie to masz zerowe - jak coś się popsuje możesz obwiniać tylko siebie.

IMO jak najbardziej, o ile nie będzie problemem wolna przestrzeń.

Możliwe, że prawda, a możliwe też że są to niezbyt ważne errory, mi np. rozjechał się całkowicie dysk ssd, zrobiłem secure erase i działa jak nowy, bez żadnych spadków wydajności czy bad sectorów, a error rate skacze cały czas. Także nie można się tym sugerować, prawda. Ale nie można też twierdzić, że takie coś jest w porządku .

Załącz smarta do oferty, dopisz że używany i wystaw na licytację od 10 zł imo. Dysk uszkodzony nie jest, realokowanych sektorów nie ma, ale ma dość spory error rate co wpływa na jego szybkość. Możliwe, że jest uszkodzony, ale w niewielkim stopniu.

http://www.webhostingtalk.pl/topic/44614-nauka-administracji-serwerow/?p=383839

Administracja serwerami to przede wszystkim doświadczenie, naprawiając jeden problem wiemy jaka jest jego przyczyna i jakie jest potencjalne rozwiązanie. Naprawiając jakikolwiek przyszły problem odwołujemy się w pamięci właśnie do wszystkich poprzednich, a dopiero jak nic nie znajdziemy to szukamy przyczyny. Nie da się tego "nauczyć". Nauczyć się można stawiać usługi i kilka podstawowych operacji na linuxach (w pełni do nauczenia samemu), ale bez pracy na BOK czy innego kontaktu z klientami i problemami nie ma szans pójść dalej. Nie zmienia to jednak faktu, że jest multum rzeczy, które można się nauczyć samemu. Ot, moje 3 grosze.