Pan Kot

Bumpuj co godzinę, w końcu wszyscy na wht wchodzą po to, żeby sprawdzić czy któraś domena przypadkiem nie jest do kupienia.

Śmiem twierdzić, że zabezpieczenia samego systemu czy to debiana czy freebsd zależą w dużej mierze od administratora i nie można stwierdzić, że freebsd jest się w stanie zabezpieczyć lepiej niż debiana czy vice versa.

Zwiększenie napięcia to zwiększenie stabilności, uV jest dobry, ale nie można przesadzić. Również wiem coś o tym bo mi na full crysis się wywalał co jakiś czas zanim mu zdozowałem +20 .

Wyjaśniłem Ci dokładnie czemu temat ze steamem wyleci to mnie zignorowałeś, a teraz po fakcie się pytasz?

W skrócie. Tworzysz nową domenę s1.dszymczuk.pl i ustawiasz jej IP swojego serwera, bez CF'a, direct. Zmieniasz RevDNS dla IP swojego serwera na s1.dszymczuk.pl Ustawiasz SPF dla wszystkich domen, które chcesz obsługiwać na include:s1.dszymczuk.pl Ustawiasz hostaname swojego serwera na s1.dszymczuk.pl Restartujesz swój serwer i upewniasz się, że postfix przedstawia się jako s1.dszymczuk.pl. Możesz chociażby telnetem sprawdzić lub w konfiguracji postfixa.

Minimum to 2 maszynki w różnych serwerowniach, najlepiej jak najbardziej oddalone od siebie. Do tego dodałbym jakiegoś kimsyfa z OVH jako jeden serwer spoza Polski i imo wyniki byłyby już jak najbardziej obiektywne. Jeśli chcesz maximum obiektywności to tak jak wyżej różni dostawcy, różne łącza.

Podasz IP kilku zainteresowanym osobom to pewno ktoś poświęci kimsyfa za 15 zł .

A ja nieco rozwinąłem, nie miej mi za złe .

Po pierwsze. root@archi ~ # host 5.133.13.140 140.13.133.5.in-addr.arpa domain name pointer dszymczuk.pl. root@archi ~ # host dszymczuk.pl dszymczuk.pl has address 141.101.117.174 dszymczuk.pl has address 141.101.116.174 dszymczuk.pl mail is handled by 10 mail.dszymczuk.pl. 5.133.13.140 wskazuje na dszymczuk.pl, dszymczuk.pl NIE wskazuje na 5.133.13.140. Zmień RevDNS 5.133.13.140 na prawidłową domenę, która wskazuje na to IP. Dalej, dla każdej domeny masz coś takiego jak SPF. SPF określa kto jest upoważniony do podpisywania się @twojadomena.pl. Jeśli wysyłasz maile wyłącznie ze swojego serwera robisz w nim albo include:IP albo include:nazwarevdns, gdzie nazwarevdns to host, który działa w obie strony tj. IP => RevDNS | RevDNS => IP. RevDNS NIE musi, i czasem NIE POWINIEN być domeną, którą obsługuje. Powinna to być zarezerwowana domena wskazująca bezpośrednio na serwer, taka jak s1.mojadomena.pl, który wskazuje na 5.133.13.140, a 5.133.13.140 wskazuje na s1.mojadomena.pl. Poza tym jeśli posiadasz pocztę na swoim serwerze to musisz również skonfigurować swój program pocztowy do porozumiewania się z innymi via swój własny host. Host zmieniasz w pliku /etc/hostname lub nawet komendą hostname -b s1.mojadomena.pl. Dzięki temu drugi serwer dostaje informację, że jesteś s1.mojadomena.pl i od razu sprawdza czy s1.mojadomena.pl pointuje na Twój adres IP, a następnie czy jest zaincludowany w SPF @mojadomena.pl czy @dowolnainnadomena.pl, z której chcesz wysłać pocztę. Dopiero wtedy przepuszcza mail. Przykładowo jeśli chcesz wysyłać maile z @domena1.pl, za pośrednictwem serwera s1.mojadomena.pl oraz s2.mojadomena.pl, to dodajesz SPF dla domena1.pl, który wygląda np. tak: v=spf1 include:s1.mojadomena.pl include:s2.mojadomena.pl ~all Wtedy serwer, z którym się chcesz połączyć wie, że tylko z tych dwóch adresów może dopuszczać pocztę, sprawdza na jaki adres IP one pointują, potem ewentualnie sprawdza, czy adres IP również pointuje na domenę (RevDNS) i jeśli wszystko się zgadza z danymi dostarczonymi przez twój serwer pocztowy (EHLO, IP) to przepuszcza pocztę. Jeśli zastosujesz się do wszystkiego co napisałem wyżej error zniknie.

Jeśli się nie boisz bitcoina to również bym się do tego przymierzał, chyba jedna z najbardziej elastycznych możliwości jeśli chodzi o płatności, ale trzeba umieć go wykorzystać.

Jeśli naukę administracji serwera zaczynasz od graficznego panelu to nie wróżę Ci przyszłości @bibus . Administracja serwerami to nie jest coś co można się nauczyć. Tu w grę wchodzi doświadczenie i umiejętność logicznego myślenia w rozwiązywaniu problemów. Google to bardzo potężne narzędzie i praktycznie w przypadku prawie każdego problemu pomoże, ALE trzeba umieć się nim posługiwać, to raz, a po drugie nie klepać na ślepo komend tylko rozumieć co robią. Zacznij od postawienia LAMP'a, tyle że przez konsolę, a nie jakieś panele graficzne, których kodu nie rozumiesz . Potem postaw sobie na tym swoim ustrojstwie stronkę, najlepiej na jakimś wordpressie czy innym śmiesznym skrypcie i zobacz jak działa. Jak się już z LAMP'em pobawisz i powiesz "ok, co dalej?" to zastąp tego swojego LAMP'a czymś trudniejszym do skonfigurowania, ale i nowocześniejszym, chociażby nginx'em z php-fpm. Tu już jest nieco więcej zabawy chociażby dlatego, że php się nie instaluje jedną komendą . Potem sięgnij dalej, chociażby do podstaw zabezpieczeń które szczegółowo opisałem na WHT. Potem spróbuj postawić chociażby pocztę via postfix u siebie na serwerze, tak żeby działała i funkcjonowała tak jak trzeba. Jeśli to Ci się uda to można powiedzieć, że jest dobrze. Potem jest nauka systemów. Definitywnie musisz się zaznajomić z CentOS'em, Debianem, Ubuntu też by się przydało gryznąć, a po tych trzech należy zahaczyć jeszcze o FreeBSD lub/i Gentoo. I tak powolutku do celu. Jak już się nauczysz podstawowego ogarnięcia w sprawach linuxów to zacznij od darmowych praktyk w którejś z firm. Dzięki temu nauczysz się obsługi chociażby DirectAdmina, który jest takim must-be pod tym kątem. O Webmina możesz również zahaczyć (u siebie) bo jest darmowy i ogarnięty, ale panele na ogół są dla userów, a nie administratorów.

Podeślij ten skrypcik . Sprawdzę jak u mnie. Kimsyf 2G za 15 zika.

Zawsze nawet w najgorszym wypadku powinno się umożliwić logowanie na usera (który może się dostać poprzez su(do) do roota) poprzez klucz prywatny do SSH wyniesionym np. na port 3xxxx . Jeśli to jakiś VPS to możesz ew. poprosić via BOK firmę, żeby zmienili to i owo podmontowując Twój dysk, jeśli to dedyk i się odciąłeś całkowicie to raczej zdalny format, a jeśli hosting to j/w BOK.

Unix socket jest przede wszystkim szybszy, liczby tego aż tak bardzo nie pokazują jak widać, ale ja odczuwam dość znaczną różnicę. Poza tym, że mogą skończyć się limity (które można zwiększyć, a nawet już standardowe są ogromne) nie ma żadnych wad. Dlatego też powinniśmy dyskutować bardziej w stronę "dlaczego nie" zamiast "dlaczego tak" . Oba rozwiązania są dobre, a ja po prostu dyskutuję na temat tego które jest lepsze. Jako fanatyk optymalizacji kernela i wszystkich serwerowych usług nie mogę zostawić tak tego tematu .

Pewnie, że widzę, ale wątpię, że wynikają bezpośrednio z testu, to by nie miało żadnego sensu, musiałby powtórzyć wielokrotnie bo nie chce mi się wierzyć, że unix socket wypada gorzej pod kwestią szybkości w jakimkolwiek teście vs. tcp. Jakiego obciążenia trzeba do wyczerpania zasobów? Raczej mało kto hitnie aż tak dużo hostując zwyczajną stronę na php-fpm+nginx, nawet mocno obciążoną. Poza tym limit można zwiększyć via sysctl do naprawdę dużo większych wartości (teoretycznie, w praktyce mi to nigdy potrzebne nie było ). Ale zgadzam się, że można dojść do takiego stanu.

@patrys A jakie to błędy? Używam na produkcji i developerce już od roku i nawet przy sporym obciążeniu chodzi niewiele, ale zauważalnie szybciej od tcp.

Socket unixowy będzie zawsze szybszy niż tcp/ip.

To wierz dalej. Mój TS nie zużywa nawet połowy JEDNEGO wątku z czterech w moim dwurdzeniowym atomie N2800 taktowanym na 1.86 GHz, a jak wiemy w vpsach są montowane na ogół xeony i i5/i7, a więc ten 1 GHz będzie znacznie bardziej wydajniejszy niż mój. Mogę więc z dumą stwierdzić, że jeden user zużywa mniej niż 0.01 GHz, a TS'a 32-slotowego nawet nie odczuje. Jeśli chodzi o ram to właśnie w tym momencie siedzi 162 userów na jednym vserverze i 20 na drugim, ram wzrósł do magicznych 2.3% z 2 GB. A więc mamy już (uwaga) 46 MB zużycia. I nie piszę tego, żeby Cię przekonać bo mi absolutnie na tym nie zależy. Ale jeśli nie masz żadnego doświadczenia z działaniem TS3 pod obciążeniem to nie kopiuj na ślepo wymagań z kartki tylko się wstrzymaj z odpowiedzią. No chyba, że mam upaść tak nisko, żeby robić screeny z htopa i mojego panelu TS3.

Posiadam OpenVPN for Android i działa całkowicie bezproblemowo. Nie wiem jak jest z resztą mobilnych urządzeń, ale ja problemów w OpenVPN nie widzę.

Ja bym to zrobił podobnie jak @samu. Wyrzucił obrazki na osobnego vhosta typu images.domena.pl w nginxie i wyrzucił jakikolwiek most do php'ka. Nginx sam z siebie serwuje wyłącznie statykę i nie umie nic zrobić ze skryptami .php, a zatem co najwyżej zwróci plaintext do usera. BTW, jeśli GD ma jakąś funkcję, która zwraca error jak nie może przemielić obrazka to również można wyczekać errora i wyrzucić błąd, ale w sumie sprawdzasz rozmiar obrazka już wcześniej więc nie jest to potrzebne. Dobrym pomysłem jest również zgrepowanie pliku po common tagach chociażby <?php ?>, ale to ponownie nie jest wymagane w przypadku twojej aktualnej implementacji. Tak czy siak jak dla mnie nginx bez php będzie tu najbardziej odpowiedni. Nawet jak ktoś jakimś cudem sfake'uje tagi i zuploaduje php'ka to i tak nic go nie otworzy.

Dowaliłeś największy bullshit jaki przeczytałem w tym tygodniu. Serwer TS'a zużywa u mnie aktualnie dokładnie 2.2% ramu z 2 GB, co nam daje dokładnie ~44 MB Ramu, hostowane jest 512 slotów, z czego dziś zajęte było 132. Debian minimal zużywa w okolicy ~40 MB ramu na wszystko co mu potrzebne, w efekcie 256 ramu wystarczy w zupełności na postawienie do tego php-fpma, nginxa i bazy mysql, a 512 będzie wystarczające na 100%, dopóki strona nie dostanie nagłego zainteresowania po 1k userów na raz. I opieram się tutaj o rzeczywiste zasoby, a nie wskaźnik oversellingu w firmie X .

Kupując mini-atx'a, stacjonarkę lub równowartość raspberry PI za taką cenę jaką wydałeś na laptopa osiągam przynajmniej 2-3x większą wydajność niż na lapku. Poza tym mini-atx'y prawie w ogóle prądu nie ciągną, a jeśli ktoś się nastawia na energooszczędność to kupuje energooszczędne podzespoły do tej stacjonarki/mini-atxa i osiąga i mniej prądu i lepszą wydajność. Lapki są budowane w zupełnie innej konwencji. Tracisz przynajmniej 1/4 / 1/3 ceny tego lapka na totalnie zbędną matrycę i inne podzespoły. Ze wszystkich możliwych opcji postawienia serwera laptop wypada najgorzej. Nie mówię, że się nie da czy że jest zły, po prostu na tle tych rozwiązań które podałem wypada najgorzej. Identyczne podzespoły na stacjonarce są do 2-3x bardziej wydajne, a czasem i równowartość prądu ciągną, zależy od reszty bebechów.

Laptop to najgorsze rozwiązanie. Jak chcesz przyoszczędzić i jednocześnie mieć kombajn do zabawy/developerki to raspberry pi proponuję, niecałe 200 zł, a jako mini serwerek sprawdza się świetnie. Jeśli natomiast celujesz wyżej to coś na MINI-ITX bym zaproponował. Można całkiem fajne maszyny złożyć. Poza tym masz jeszcze tradycyjne terminale oraz w ostateczności stacjonarki czy nawet laptopy. To co ty dałeś niedość, że żre prąd to jeszcze jak wyżej przeczytałeś generuje ogrom hałasu. To fajnie, że teraz każdy chce budować serwerownie w domu, ale to naprawdę nie jest dobry pomysł . Taki raspberry jest jak znalazł, nawet sam posiadam do developerki, prostych skryptów w bashu/perlu i okresowego sprawdzania serwerów, sprawdzania nowych rozwiązań zanim przetestuję na produkcji czy jako domowy vpn. Nawet nie wiecie ile można upakować w tym raspberry . Ale hostowanie na domowym łączu w domowych warunkach produkcji? Nie wiesz na co się porywasz.

Instalujesz odpowiedni pakiet w wersji serwerowej np. OpenVPN, ustawiasz i konfigurujesz, potem na komputerze ściągasz klienta tego pakietu OpenVPN i łączysz się ze swoim serwerem. W ten sposób cały twój ruch leci przez vps'a. Pierw się upewnij, że masz na tym swoim vpsie TUN/TAP.