Archi

Nie postawiłbym żadnej swojej usługi na OpenVZ nawet jakbyś mi za to dopłacał co miesiąc.

Co się nawzajem wyklucza bo mając większą wiedzę na temat systemu debian nie pakujesz się w gówno którym jest OpenVZ

Dorzuciłbym ekstra skrzynkę, dodał regułę przekierowania wszystkich maili/skrzynek, które Cię interesują wraz z oryginalnymi nagłówkami, a tam postawił dowolny klient pocztowy do przeglądania, jakiś rainloop chociażby. Oczywiście wzrośnie Ci trochę presja na miejsce na dysku, ale nie będziesz miał sytuacji, w której użytkownik kasuje jakiegoś maila i nic o tym nie wiesz, ani sytuacji w której użytkownik chce coś skasować, a nie może (i zaraz "a dlaczego nie można skasować"). Rozwiązanie lepsze, ale niewyobrażalnie bardziej czasochłonne to skrypt, który kopiowałby tylko te kasowane maile na tą skrzynkę, a w niej samej symlinki do wszystkich innych. Da się to zrobić, ale nie wyobrażam sobie żeby ktoś o zdrowych zmysłach się w to pakował jak o wiele łatwiej po prostu dać niewidzialne CC. IMHO skrzynka składująca wszystkie maile jest OK, jak miejsce jest problemem to dodać dodatkowe filtry, które wywalą np. załączniki, konkretne skrzynki mailowe czy jakieś generyczne maile wg. regexa. Albo po prostu ograniczyć archiwum do X ostatnich dni/tygodni/miesięcy.

\r to w ogóle nie jest prawidłowy znak, który powinien występować samoistnie. Albo \r\n, albo samo \n.

Nie, reboota potrzebuje również z innych względów (np. żeby sprawdzić czy usługi dobrze wstają, systemd działa poprawnie itp.) więc nie jest mi to do niczego potrzebne.

Większość tego co wymieniłem tak, większość tego co wywalam z kompilacji, żeby się w ogóle nie budowało wraz z ich zależnościami już nie, a przecież nie będę Ci wymieniał każdego pojedynczego drivera. Ja mam raczej autorskie rozwiązanie oparte hybrydowo na pakietach budowanych ze źródeł i paczkach deb z repo. Mam określoną konfigurację każdego pakietu - serwer testowy każdego dnia dokonuje self-update'a (w pełni automatycznie), wraz z rebootem. Po reboocie lecą unit testy na wszystko co kiedykolwiek mnie zawiodło czy nie ma żadnych regresji (począwszy od tego czy serwis X wstaje, poprzez to czy wspiera funkcjonalność X, a na benchmarku raw wydajności i testach obciążeniowych kończąc). Jeśli wszystkie testy przejdą bez problemu to leci automatyczny deploy na wszystkie maszyny w tej samej konfiguracji. Pakiety ze źródeł są budowane tam gdzie dorzucam łatki -march=native, czyli praktycznie wszędzie gdzie coś grzebię (aktualnie kernel, .net core runtime, nginx, php-fpm i mariadb). Wszystkie maszyny jadą na debianie testingu na produkcji

Zależy od przeznaczenia serwera. Politykę ASPM na performance, cpu governor na performance, I/O scheduler w zależności czy mam system na hdd czy ssd cfq lub noop, kernel patchuję patchem od graysky2 żeby mu wrzucić -march=native, przerwania CPU ustawiam na ogół na 250 MHz, do tego wyłączam wszystkie zbędne funkcje, żeby się w ogóle nie budowały, cały debug, czy nawet takie rzeczy jak support procesorów AMD (no bo po co jak mam intela). Ogółem dużo rzeczy można pozmieniać. To wyżej to tylko to co mi do głowy przyszło. Diffmerge, zwykły diff, make localmodconfig czy diff oryg configa z configiem OVH i zaaplikowanie na nowy, po czym make oldconfig. Też dużo możliwości.

I to jest bardzo dobre podejście. Sam tak robię, choć teraz preferuję robić 3-way-merge configa distro i configa OVH, jeszcze samemu poprawiając co trzeba.

Halo, przecież hostlista już jest.

A potrzebujesz mieć wgląd w ten portfel przez więcej niż jedną osobę? Keepass jest świetny bo sam z niego korzystam i każdy user może mieć swoją własną bazę, ale o dodatkowym administratorze nie ma mowy.

Chyba w dużej mierze to zależy od lokalizacji, bo przykładowo u mnie to właśnie UPC jest wzorem jakości, internet zawsze taki jak w specyfikacji, downtime'y raz na kwartał koło 4:00 w nocy, wszystko działa, dział obsługi przyjemny, cena w porządku. Nawet zadzwoniłem z prośbą o przydzielenie statycznego IPv4 i również obyło się bez problemów. Nie mogę tego natomiast powiedzieć o Orange, któremu zarzucić mogę wszystko od fatalnego działu obsługi klienta po brak zrozumienia co oznacza sformułowanie "proszę nie wysyłać mi smsów z przypomnieniem o fakturach do zapłacenia każdego miesiąca".

Pierwsze co mi przyszło na myśl to xpress-pizza.pl i oczywiście jest wolna. Spoko, uzasadnienie jest, ale z tych dwóch wolałbym jednak plkę

Za długie, za drogie, i zbyt mało popularne. Do tego większość jest bardzo specyficzna i ma kosmiczne wymagania, całkowicie z dupy bo nikt w 2018r nie szpanuje domeną. Weź sobie za przykład gTLD .domains. Otworzysz na tym jakieś qkash.domains, ale jak już będziesz chciał dołożyć hosting to cała marka leci do /dev/null bo trzymanie marki hostingowej na domenie .domains jest po prostu słabe. Do tego i tak wolałbym o wiele bardziej pójść od razu w qkash.net niż jakieś qkash.domains. IMHO do niczego dobrego to się nie nadaje, poza domenami wizytówkami jakiś specyficznych firm, ale nawet w tym wypadku nie potrafię znaleźć jednego powodu dlaczego wybrać nowe gTLD zamiast generycznego .pl, .com.pl czy innego .net.

Nie wiem czy wszyscy zgodnie testujecie nie to co trzeba, czy nie rozumiecie na czym polega łatka. Spadek wydajności, a raczej dodatkowy overhead aniżeli jakieś rzeczywiste spowolnienie dotyczy wyłącznie wykonywanych syscalli na poziomie OSu, a nie czystego benchmarka. Program wykonujący nawet bardzo zaawansowane obliczenia zajmujący 100% procesora nie odczuje w żadnym stopniu łatki, natomiast taki który dokonuje pierdyliard operacji na plikach, pomimo niewielkiego obciążenia CPU już tak. Jak chcecie dobry benchmark to polecam testować INSERTy do MySQLa. Alternatywą będzie cat w pętli lub inne akcje znacząco ukazujące spowolnienie tam, gdzie rzeczywiście się ono znajduje. Nie, nie jest to jakaś ogromna liczba, którą widać na pierwszy rzut oka, ale w zależności od dokonywanego testu do 20% udało mi się zaobserwować, w szczególności na bazach danych. Będzie to bardziej odczuwalne na słabszych maszynach, bo koszt syscalla jako takiego jest minimalny i nawet z łatką bardzo trudny do zauważenia/zbenchmarkowania, ale jest i można w łatwy sposób go sprawdzić. I nie, nie są to liczby, które kogokolwiek musiałyby zmusić do zainwestowania w lepszą infrastrukturę czy podwyżkę cen. Nawet w przypadkach serwerów stricte bazodanowych, dodatkowy overhead jest minimalny, bo operacje zapisu (czyli de facto operacje zapisu plików) są w ogromnej mniejszości w porównaniu do selectów, które na ogół ciągną się z cache'a. Z drugiej strony twierdzenie, że nic się nie zmieniło i spadek wydajności jest bujdą też jest głupotą - overhead jest, ale w przypadku rzeczywistego praktycznego użycia danego serwera, a nie umyślnym robieniu konkretnych benchmarków, jest on po prostu marginalny.

A co ma cloudflare do ustawień DNS? Możliwe, że twój serwer mailowy łączy się po IPv6, którego tutaj zdefiniowanego nie ma. Warto dodać rekord AAAA. Jeśli to nie pomoże to przejrzyj logi, wyślij wiadomość testową ze swojej domeny i sam sprawdź powód.

Jak chcesz jakieś benchmarki to można śmiało opierać się na tych od phoronix, mimo że były robione jakiś czas temu to niedużo się w tej materii zmieniło - https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.7-FS-5-Way Nie ma jednoznacznego oczywistego wyboru jeśli zakładamy, że obydwa filesystemy wspierają to co chcemy uzyskać, np. quotę. Ja zawsze wybieram ext4 z powodów kompatybilności - większość różnego dziwnego software'u jest na ogół, o ile w ogóle testowana, to wyłącznie na ext4. Na przykład wiadomo, że niektóre gry Linuxowe ze Steama na XFS po prostu nie działają w ogóle, i oczywiście są to pojedyncze przypadki, ale jednak. Czy taka sytuacja Cię dotyczy? Niezbyt, wątpię, żebyś z takiego softu miał zamiar korzystać, ale biorąc pod uwagę, że nie masz jednego konkretnego powodu używania XFSa, to bardziej kompatybilnym i przetestowanym wyborem jest ext4. A ja na tą chwilę takiego konkretnego wyboru używania XFSa nie widzę. Tak jak pisałem jakiś czas temu na naszym Discordzie, sam uważam ext4 za zabytek, ale na tą chwilę nic lepszego nikt nie stworzył, przynajmniej jeśli mówimy o generalnym użytku posiadania FS do wszystkiego. Jeśli mówimy o specyficznym użyciu, to można polemizować (np. o tym jak dobry jest ZFS ze swoimi snapshotami, ale kulejącym trimem na linuxie, gdzie działa znakomicie na BSD). Generalnie nie widzę powodu do używania XFSa zamiast ext4, ale też nie widzę powodu dlaczego miałbym bronić ext4 jeśli ktoś wybrał xfs - jeśli wszystko mu działa, to argumentu przeciw również nie ma. Jedyne co mogę jasno stwierdzić to to, że w generalnych benchmarkach czyli FSie do wszystkiego, ext4 wiedzie prym.

Sorry za lekki odkop ale warto wspomnieć - Linux umożliwia hot-swap pamięci na poziomie softu już od bardzo dawna. Tak długo, póki płyta się nie zbuntuje możesz odmontować dany obszar/kość i wymienić nawet w desktopowych rozwiązaniach, gdzie nie jest to realizowane przez hardware. Cały proces w całkowicie desktopowych warunkach to włożenie trzeciej kości "backupowej" jeśli serwer jej potrzebuje (używa tej pamięci aktywnie), następnie wyjęcie uszkodzonej i włożenie prawidłowej, po czym wyjęcie backupu. Oczywiście przed każdą operacją odpowiedni wpis do sysfs. Jak nie ma potrzeby ekstra pamięci na czas zamiany to i backupowego ramu nie trzeba, linux sobie przerzuci wszystko na jedną kość albo swap.

Jakkolwiek negatywna jest Wasza opinia o danej firmie, zalecane jest powstrzymanie się od negatywnych komentarzy, a w szczególności nawoływanie do zbiorowej "nienawiści" pod tytułem "nikt was tu nie chce". Każda firma posiada przywilej publikowania własnej oferty w tym dziale o charakterze stricte marketingowym i nie ma obowiązku odnosić się do jakiejkolwiek wypowiedzi. Jednocześnie wszystkie tematy na forum, poza nielicznymi regulaminami o charakterze stricte informacyjnym, są otwarte na dyskusję i takowa właśnie ma tutaj miejsce, w którym użytkownicy są całkowicie uprzywilejowani do zamieszczania własnych opinii, odczuć i pytań, popartych merytorycznie przynajmniej własnymi doświadczeniami. Jedynym zabronionym czynem jest marketing szeptany. To czy nazwa.pl jako firma ma zamiar odnosić się do zamieszczanych tutaj odpowiedzi lub też nie świadczy wyłącznie o nich samych i każda osoba jest w stanie stworzyć sobie własny obraz na temat tego co sądzi o takiej podstawie. Na forum nie ma cenzury i pozwalamy zarówno użytkownikom jak i firmom odnieść się do przedstawianych zarzutów - jeśli ktoś z tego przywileju nie korzysta to jest wyłącznie jego wybór. Dalszą dyskusję na temat spraw stricte organizacyjnych poleciłbym przenieść do odpowiedniego działu. Ten dział służy wyłącznie do zamieszczania ofert przez usługodawców, jak i również dyskusji na temat oferty i firmy, a w szczególności zamieszczaniu subiektywnych odczuć jak i zadawaniu pytań.

Mamy wolny rynek i wolny wybór, jeśli polityka cenowa OVH Ci nie odpowiada to zawsze jest konkurencja

Hash stosujesz jak nie potrzebujesz znać konkretnej informacji, ale potrzebujesz zweryfikować ją czy się zgadza. To się stosuje np. w przypadku haseł i logowania, bo tu po stronie serwera nie potrzebujesz znać hasła, potrzebujesz jedynie wiedzieć czy hasło podane przez użytkownika zgadza się z tym w bazie danych, i w tym celu sprawdzasz właśnie czy hash się zgadza z tym zapisanym. Szyfrowanie stosujesz w przypadku gdy musisz mieć dostęp do danej informacji, czyli ją odszyfrować. Jak wysyłasz do kogoś np. wiadomość tekstową to musisz ją zaszyfrowac, tak żeby druga strona mogła ją odszyfrować. Nie możesz tutaj zastosować np. hasha, bo nie znasz treści wiadomości. Jeśli być ją znał, to mógłbyś otrzymać zaszyfrowaną wiadomość i wyliczyć hash tej wiadomości, a następnie zweryfikować hashem czy wiadomość jest poprawna. Podobne techniki stosuję się przy podpisywaniu wiadomości używając PKI.

Tu nie potrzeba konstruktywności - ja nie jestem administratorem matki, żeby ustalać limity i przydzielać klientom zasoby. Mnie jako klientowi ma działać usługa, a nie być blokowana z automatu bo przekroczyłem jakieś wyimaginowane limity, których nawet nie ma jak sprawdzić, bo oczywiście w panelu paska nie ma. Ale chcesz konstruktywne rozwiązanie to proszę bardzo - wrzucić każdego usera, który przekroczył limit do cgroupy o najmniejszym ioprio, tak żeby requesty wszystkich userów poniżej limitu szły priorytetem. Da się zrobić i to dość prosto - a to jest rozwiązanie wymyślone w ciągu 10 sekund, bo po kolejnych 10 możesz mieć usprawnienie również na samą ilość tych danych, jak np. doliczanie do ceny ekstra złotówek za każde X przekroczonych IOPSów, nie wiem ile, bo nie ja to analizuję. Ja mam konstruktywne rozwiązania, które klienta by zadowoliły - klient woli dostać fakturę na 20 zł więcej niż się dowiedzieć, że strona nie działa bo przekroczyłeś IOPSy w 27 dniu miesiąca. Oczywiście POWAŻNY klient, jak celujemy też w gimbazę za pinć zł to dorzucić switcha o nazwie naliczanie/blokowanie. BTW jak te 20 sekund wyżej zamienisz na 20 minut to już masz cały pomysł jak to ma działać produkcyjnie, a po 20h masz całą implementację i wdrożenie.

Dzięki, że mówisz, może mi teraz wytłumaczysz czym są te całe cookies bo nie mam zbytnio pojęcia Czepianie się skrótów myślowych chyba jeszcze nie przerabiałem. Masz jakiekolwiek pojęcie o bezpieczeństwie? Bo czuję się jak na pierwszym roku studiów inżynierskich z wykładu o security. Mam nielimitowany zestaw prawidłowo zaszyfrowanych danych, wiesz co to oznacza? A jak nie to wytęż szare komórki i może dojdziesz do jakiś prawidłowych wniosków. Nie, nie martw się, dzisiaj większość najpierw robi a potem myśli. Mam tylko nadzieję, że na żadnej produkcji takich rzeczy nie robisz, bo się zdziwisz któregoś dnia

Cookie sesyjne to jedynie jeden ze sposobów na zapisanie sesji po stronie klienta. I co w związku z tym? Nadal mogę wyedytować cookies do dowolnych wartości, twoje szyfrowanie nie ma tutaj nic do gadania, chyba nie chcesz mi powiedzieć, że trzymasz zaszyfrowane poufne dane w ciasteczkach, bo chyba warna za głupotę sprzedam

To czy aplikacja jest monolityczna czy rozproszona nie ma dużo do gadania. Nie oczekuję od slave'a mysql, że zabije mi mastera, bo to jest niedorzeczne, ale jak najbardziej powinien zakończyć proces z nie-zerowym kodem błędu jeśli dojdzie do jakiegoś nieobsłużonego błędu czy crasha. Obowiązkiem procesu w przypadku awarii jest zakończyć wszystkie swoje procesy i procesy dzieci, nie musi od razu rozwalać całej architektury, to tak jak padnięcie pojedynczego node'a.

Powinieneś zawsze wybierać sesję PHP w takim wypadku, chyba że masz mocny argument dlaczego chcesz to robić za pomocą cookies. Przede wszystkim primo - cookies są całkowicie po stronie klienta. To oznacza, że to on ma władzę nad tym czy po pierwsze w ogóle je ma włączone (nie musi), kiedy wygasają (mogą nigdy nie wygasnąć albo 10 sekund po tym jak sie zapiszą bo user sobie wyczyści), i jakie dane zawierają (mogę wyedytować cookies do dowolnych danych jakie sobie życzę). Przy sesji PHP to ty kontrolujesz co jest zapisywane, nie potrzebujesz wsparcia cookies po stronie użytkownika, kontrolujesz to kiedy dane wygasają czyli jak długo są aktualne (co jest kluczowe jeśli chcesz oferować jakiegokolwiek rodzaju rezerwacje "koszyka" przed zakupem), i przede wszystkim user ich nie widzi, więc możesz tam zapisać dużo więcej. Nie widzę jakiegokolwiek dobrego powodu realizacji koszyka po stronie cookies, to wygląda jak całkowicie nieadekwatne rozwiązanie. Cookies na ogół stosuje się wyłącznie jako "preference użytkownika", czyli identyfikator zalogowanej sesji, jakieś domyślne ustawienia sortowania produktów, być może język serwisu itp. Oczywiście dla userów niezalogowanych, bo dla zalogowanych możesz to zrobić również zwykłą bazą danych.