Pan Kot

Jeśli komuś zależy na ultra tajnych logowaniach do serwera to sobie konfiguruje SSL i puszcza host bezpośrednio, CF nie stoi na drodze i nie robi żadnych problemów. Jeśli natomiast jest to strona WWW to i tak jest publicznie dostępna, więc nie wiem o co się martwisz, to że CF podejrzy co user robi na stronie? Bo to jedyna aktywność w zasadzie. Używając CF każdy powinien wiedzieć jakie są korzyści, a jakie wady. Informacja o SSL jest dobra, i na pewno się przyjrzę temu za parę dni, ale do mission-critical logowań po SSH, panelu czy schowanych usługach i tak będę używał własnoręcznie skonfigurowanego SSLa po directcie .

root@archi:~# host 188.165.232.XXX 68.232.165.XXX.in-addr.arpa domain name pointer server.XXX.info. root@archi:~# host server.XXX.info server.XXX.info has address 188.165.232.XXX server.XXX.info mail is handled by 10 mail.server.XXX.info. Jest OK. Nie pytaj skąd mam IP .

W debianie zafixowane odpowiednio w .1 i .2 i 7u2 oraz 7u3. http://metadata.ftp-master.debian.org/changelogs/main/b/bash/bash_4.3-9.2_changelog http://metadata.ftp-master.debian.org/changelogs/main/b/bash/bash_4.2+dfsg-0.1+deb7u3_changelog Stan na teraz: bash: Zainstalowana: 4.3-9.2 Kandydująca: 4.3-9.2 Tabela wersji: *** 4.3-9.2 0 500 http://ftp.pl.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status 4.3-9.1 0 500 http://ftp.pl.debian.org/debian/ testing/main amd64 Packages 4.2+dfsg-0.1+deb7u3 0 500 http://security.debian.org/ stable/updates/main amd64 Packages 4.2+dfsg-0.1 0 500 http://ftp.pl.debian.org/debian/ stable/main amd64 Packages

Sprawdź sobie na jakimś serwerze obsługującym IPV6 czy poprawnie wykrywa revDNS dla danego adresu IP. Przykład: root@archi:~# host -6 2001:4860:4860::8888 8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa domain name pointer google-public-dns-a.google.com.

Tworzysz sobie subdomenę typu mojserwer.domena.pl, może to być również domena najwyższego szczebla (domena.pl), ale proponuję trzymać się subdomeny. Dodajesz tej subdomenie w panelu: 1. Rekord A kierujący na IP twojego serwera - 1.2.3.4 2. (Opcjonalnie) Rekord AAAA kierujący na IP twojego serwera - 1:2:3:4:5:6 Następnie odczekujesz chwilę na propagację (kilka godzin) i zmieniasz rewers DNS dla serwera o powyższych IP na domenę, którą dodałeś, mojserwer.domena.pl To gdzie stoi serwer DNS obsługujący główną domenę typu domena.pl nie ma żadnego znaczenia, jedyne co ma znaczenie to to, żeby wiedział czym jest mojserwer.domena.pl i poprawnie rekordem A kierował na serwer. Hostname i hostsy są całkowicie opcjonalne, podane w tym poście kroki są w pełni wystarczające do ustawienia własnego rewersu. Poza tym, revDNS nie jest potrzebny do parkowania domen. Jeśli ns.mojadomena.pl poprawnie wskazuje rekordem A na serwer obsługujący daną domenę, to jest wystarczające.

Nie. RevDNS ma wpływ wyłącznie na query danego adresu IP. DNS: root@archi:~# host google-public-dns-a.google.com google-public-dns-a.google.com has address 8.8.8.8 google-public-dns-a.google.com has IPv6 address 2001:4860:4860::8888 RevDNS: root@archi:~# host 8.8.8.8 8.8.8.8.in-addr.arpa domain name pointer google-public-dns-a.google.com. Opcjonalnie możesz powiedzieć systemowi, że ma używać tej domeny zamiast domyślnego hostname'a, osiągasz to komendą hostname, man hostname po więcej informacji. Opcjonalnie również możesz dodać domenę do /etc/hosts, tak żeby serwer nie tracił czasu na rozwiązywanie często querowanej nazwy. 1.2.3.4 mojaDomena.pl Ja osobiście ustawiam revDNS dla moich serwerów na np. codename.mojadomena.net, następnie hostname tego serwera na codename.mojadomena.net, oraz dodaje adres IP tego serwera do hostsów, co by już nie szukał na co wskazuje dana domena tylko od razu querował sam siebie.

Zależy od klienta i ustawień. Jeśli mówimy o klientach w sensie użytkownikach, thunderbird przykłada wagę do certyfikatów i żąda potwierdzenie wyjątku bezpieczeństwa dla certyfikatu POP3/IMAP (przy logowaniu) oraz SMTP (przy wysyłaniu pierwszej wiadomości).

Procesor nie odgrywa dużej roli w udostępnianiu plików, więcej idzie na szyfrowanie połączenia czy to FTP czy NFS niż na sam fakt przesyłania/odczytu pliku. Nie przejmowałbym się zbytnio procesorem.

Czemu edytujesz config nginxa, skoro w error.logu jasno masz napisane, że to upstream zakończył połączenie timeoutem? /etc/php5/fpm/php.ini i polecam się zainteresować zmienną max_execution_time.

Szansa na to, że nowy dysk zacznie sypać errorami jest duża większa niż to, że dysk z przepracowanymi 10k bez errorów nagle się zepsuje. Nie popadaj w skrajność, bo przepracowane godziny też o niczym nie świadczą, w 10h nie jedna osoba jest w stanie zrobić więcej niż ja przez miesiąc.

Zacząć możesz od mysql -h localhost -u root -phaslo. Potem lekturka o tym jak działa cron i jak z linii poleceń zrobić backup. A do wysyłania możesz użyć czy to ssh i sftp, czy nawet scp, ftp czy co tam masz dostępne.

Fora wielotematyczne to najgorsze strony jakie kiedykolwiek powstały. Wole już czytać blog traktujący o totalnie nieinteresującym mnie temacie niż przeglądać forum takie jak to wyżej.

Jeśli osiągniesz już jednakowy content na dwóch różnych serwerach to wystarczy w DNSach zrobić load balancing i userzy sami się będą rozrzucać po serwerach. HAProxy jest OK jeśli masz mission-critical serwer, który jest Ci w stanie zapewnić 24/7 uptime. W przypadku DNSów ulokowanych np. na takim Cloudflare, masz to jak w banku przy 2 niezależnych serwerach DNS, które zawsze odpowiedzą tym co trzeba. Wszystko zależy od zastosowania.

Dużo w tym prawdy, największa awaryjność jest w pierwszych kilkudziesięciu/kilkuset godzinach, a potem dopiero po kilkudziesięciu tysiącach i dłużej.

Jeśli chodzi o DC to wszystkie są w porządku bym powiedział, to już sprawa rzędu kilku milisekund. Ja osobiście kimsyfa mam w GRA1 (chyba już nie rozdają tam niczego), i nie było jeszcze awarii łącza, a z rok minął.

To zależy. Deadline polecam używać, jeśli I/O na ogół się nudzi i co jakiś czas dostaje requesty, wtedy będzie to szybsze. Jeśli I/O jest cały czas "in use", czyli większość scenariuszy, CFQ prawdopodobnie sprawdzi się tutaj lepiej. Chyba, że kontrolujesz co się dzieje i nie martwisz się o równomierny dostęp do I/O tylko o jak najszybsze zakończenie requesta, wtedy deadline wciąż wygrywa. Jeśli ten apache nie powoduje obciążenia to zaniżony wynik benchmarka jest co najmniej dziwny, deadline będzie miał "mniejsze liczby" pod obciążeniem, ale jeśli tego obciążenia nie ma to powinien być minimalnie szybszy w liczbach od CFQ, tak jak to pokazuje benchmark pierwszego dysku.

Najgorsze w streamingu są kilogramy łącza napisane przez kolegę wyżej. To nie są byle jakie ilości bo na bardzo przeciętno-niskiej jakości BYĆ MOŻE zmieścisz się w 1mbps/user, a to da Ci 100 userów MAX, odliczając jakiś limit bezpieczeństwa ~80-90, i to przy założeniu gwarancji tego 100 mbps, a takowa gwarancja jest dość droga. Już nawet nie wspominam o obowiązkowym nielimitowanym transferze bo wszystko pójdzie bardzo szybko. Koszta, koszta, koszta. Taki streaming jest najczęściej bardzo mało opłacalny, chyba że robisz to na dużą skalę i liczby cztero-pięciocyfrowe na miesiąc cię nie przerażają.

Nie ma czegoś takiego jak "nie są w stanie". Upewnij się, że nie masz antycznego kernela (poprawki do deadline'a co jakiś czas wpadają). Poza tym z natury działania deadline nie zaoferuje Ci najlepszej szybkości dla X requestów, to właśnie robi CFQ. Deadline minimalizuje overhead poprzez nieco szybsze serwowanie requestów, tyle że idąc deadlinem, czyli jeśli te benchmarki robisz na jakkolwiek obciążonej maszynie to requesty MySQL czy czegokolwiek co tam masz będą na pierwszym miejscu, a benchmark dopiero na ostatnim. Normalne zachowanie tego governora. Jeśli liczby bardziej do ciebie przemawiają niż fakt, że w rzeczywistości deadline jest szybszy to zostań przy CFQ bo tylko on gwarantuje równomierne rozłożenie I/O.

W zasadzie to płacisz tylko za support i niewielką część dodatków. Przy RAIDzie 1 szansa, że padną oba dyski na raz i będzie downtime jest dość niska, a jeśli założymy że takowej nie będzie to serwer sobie da radę jadąc na 1/1,5 dyskach do czasu wymiany przez techników. Tym bardziej, że z fizycznym downtimem musisz się liczyć tak czy siak, czy to tu czy tu. Tak jak Miłosz napisał wyżej, tu już musisz sam przekalkulować. Support w OVH jest lepszy niż w SyS, to jest pewne, pytanie czy wart ceny skoro infrastruktura jest teoretycznie identyczna, szansa na awarie tak samo, jedynie support i dodatki przeważają na stronę OVH. Ja osobiście bym się skłaniał do dwóch tańszych serwerów. Jeśli ogarniasz temat możesz zrobić nawet load balancing na nich i wtedy nawet fizyczny downtime Ci nie zaszkodzi, o ile oczywiście usługa którą będziesz hostować na to pozwala. Co dedyk to dedyk, a co dwa dedyki to dwa dedyki. Jeśli mają to być jakieś strony, maile czy coś innego co się da spiąć na paru serwerach to raczej bezkonkurencyjnie wygrywają dwie maszyny jeśli chodzi o uptime. A jeśli jeszcze wyrwiesz je w dwóch rożnych DC to jest duża szansa na uptime rzędu 100% przez naprawdę długi czas.