Pan Kot

1. User nie zainstaluje żadnych pakietów bez dostępu do roota, a jeśli chrootujesz go z rootem to robisz coś potencjalnie bardzo szkodliwego i powinieneś się zastanowić czy w ogóle wiesz co robisz. Jailkit powinien służyć wyłącznie do chrootowania userów, czyli zamykania ich, i w żadnym wypadku zchrootowany user nie może być rootem, jeśli chcesz zamykać rooty to musisz się zainteresować wirtualizacją, a nie jailkitem. 2. Można dodawać własne filtry bez obaw, najwyższej fail2ban się wywali z błędem konfiguracyjnym jak coś będzie nie tak, ale od tego jest service fail2ban configtest, a jeśli on tego nie obsługuje to service fail2ban reload. 3. Oczywiście, że nie. Kernel OVH jedyne co w sobie może mieć poza configiem pod maszynę to grseca, o ile masz zamiar użyć kernela z wariantu grspax, bo zwykły wariant grseca od OVH nawet nie ma zaimplementowanego PAXa w trybie enforce, więc jest to wyłącznie pewna ilość łatek i nic więcej. Optymalizacja jest wyczuwalna. Kernel jako taki nie ma zbyt dużego overheadu, bo robi tylko to co zlecają mu aplikacje wyżej, ale jest w stanie niektóre z tych operacji chociażby upakować ładnie w cache'u dzięki -march=native, co przekłada się na mniejsze ilości cache missów i potencjalnie większą wydajność chociażby w sprawie dostępu do pamięci.

O ile ktoś nie używa apache'a z opcją mod php5 prefork.

Zależy od systemu bazodanowego. W MySQL będzie to: ERROR 1467 (HY000): Failed to read auto-increment value from storage engine Czyli zwykły failed insert.

BIGINT zawsze przechowuje 8 bajtowe liczby, czyli w przypadku unsigned jest to zakres <0, 18446744073709551615>. 17 to podpowiedź dla MySQLa, że to pole będzie miało zawsze do 17 cyfr, pomimo że jak widzisz BIGINT jest dostatecznie duży na przechowywanie 19 cyfr i niewielką część liczb 20-cyfrowych. Używanie BIGINTa jest nieco bardziej wydajne niż używanie NUMERICa. Komputery lepiej sobie radzą z 64-bitową liczbą niż z numericiem składającym się z 17 cyfr. W tym drugim przypadku MySQL musi czytać cyfrę po cyfrze, podczas gdy w tym pierwszym jest to najzwyczajniejsza w świecie 64-bitowa liczba. To działa na podobnej zasadzie, jak typ BOOL. W MySQL boolean nie istnieje, i jest zapisywany jako unsigned TINYINT(1). TINYINT jest najmniejszym rodzajem danych jaki MySQL obsługuje, a jedynka podpowiada, że będzie nas interesować tylko jedna cyfra (0 albo 1, pomimo że w to pole poprawnie można wpisać zakres <0,9>, a sam TINYINT UNSIGNED pozwala na zakres <0,255>).

Będzie. Jeśli u ciebie STEAMID jest typu VARCHAR to robisz to źle, powinien być BIGINT(17) UNSIGNED. A różnica w operacjach na BIGINT UNSIGNED i INT UNSIGNED jest tak niewielka, że nie ma nawet co sprawdzać.

O wiele byś sobie ułatwił sprawę ustawiając STEAMID jako klucz główny. Ludzie z jakiegoś powodu mają wbite do głowy, że każda tabela musi mieć auto incremented pole ID, i nie ważne co to jest. Jak sobie uświadomisz, że tabela NIE MUSI mieć ID, a musi mieć coś, po czym jednoznacznie odwołasz się do konkretnego wiersza, to ci się życie ułatwi. SteamID jest unikalny dla każdego gracza, zgadza się? A więc możesz go użyć jako klucza głównego w 1szej tabeli, i jako klucza obcego w drugiej tabeli, która jako głównego klucza używa SteamID + Umiejętność. W ten sposób twoje zapytanie robi się o wiele prostsze. UPDATE umiejetnosci SET poziom=10 WHERE STEAMID=0; Co więcej, klucz główny w postaci SteamID spowoduje o wiele szybsze działanie całej bazy jeśli ustawisz go jako BIGINT UNSIGNED. Zwykłe ID jest najczęściej typu INT unsigned, a więc wydajność fetchowania po tym i po tym jest mocno zbliżona. Łap przykład prosto ode mnie:

Żadna świadoma osoba mająca licencję TS3 nie użyczy jej obcej osobie do postawienia swojego serwera ot tak, na krzywy ryj.

Polecam mysqlnd, pod każdym względem lepszy.

Dzięki .

Nająć kogoś do wstawienia entera? Zrobię od ręki po promocyjnej cenie.

Czemu akurat 21:9? Być może lepszym pomysłem będzie kupno dwóch 16:10 albo 16:9.

Wskaż mi podstawę prawną, która definiuje stwierdzenie "wiarygodne zawiadomienie" i zmusza operatora świadczącego usługi hostingowe do zablokowania klienta.

Czemu mieliby nie kupować? Dedyk za 12 zł miesięcznie to śmiech na sali i niedowierzanie, że coś takiego komukolwiek może się opłacać. Skoro są na tyle eksluzywne, że nie da się ich dostać poprzez normalny najem to nic w tym dziwnego, że ludzie się prześcigają w ofertach, w końcu ilość jest ograniczona, a ludzie też nie chcą się tych kimsyfów pozbywać ot tak.

Znajdziesz zarówno osoby ultra ambitne i zdolne, które przyswoją dany materiał w kilka dni, oraz takie które będą nad tym siedziały miesiącami i nadal nie umiały zbyt dużo. Mówię to na własnym przykładzie, po miesiącu zabawy z linuxami miałem już własny serwer z własnym skompilowanym jajkiem, nginxa z php-fpm, serwerem pocztowym, firewallem, kilkoma własnymi usługami i panelem. Jest to w pełni wystarczające do postawienia usługi webowej, a skupiając się na konkretnym celu (patrz - hosting), a nie na całości można i osiągnąć dużo więcej. Nie mierz wszystkich swoją miarą, nigdzie nie napisałem że w miesiąc można się nauczyć tego co inni przyswoili w kilka lat, napisałem że można konkretnie przysiąść do tematu i uzyskać zadowalające efekty, co oczywiście nie uda się każdemu. Albo się płaci za doświadczenie i wiedzę, albo zdobywa się ją samemu. A to jak szybko się ją zdobywa zależy już od własnych predyspozycji.

Żaden operator nie zablokuje swojemu klientowi usługi bez prawomocnego nakazu ze strony policji/prokuratury. Operator może co najwyżej na życzenie osoby z zewnątrz przeprowadzić małe dochodzenie, co leży w jego dobrej woli, a nie żadnym obowiązku. Takie rzeczy składa się do właściwych organów, a nie nęka się operatora, który świadczy usługę. Wyjątkiem jest sytuacja, w której operator odnosi szkody finansowe, które mogą m.in wyniknąć z rozsyłania przez serwer spamu, rozprzestrzenianie wirusów czy używania strony do phishingu.

Poważnie się zastanawiam na spieniężeniu mojej piaskownicy...

Nie, w żadnym wypadku nie opieram swojej opinii o jakiejkolwiek firmie na wypowiedzi jednej osoby. Odnoszę się tutaj do konkretnej sytuacji, która miała miejsce i staram się odpowiedzieć sobie na wewnętrzne pytanie "jak to możliwe". I spodziewałem się raczej wypowiedzi kogoś kto zna sprawę, a najlepiej osoby która odpowiedziała na danego ticketa, a nie generycznej defensywy, którą może wygłosić każdy pracownik w firmie . (I nie zrozum mnie źle, nic do firmy nie mam bo jak już wspomniałem jestem osobą trzecią, której sprawa nie dotyczy, po prostu jestem ciekawy)

A nawet symlinka/hardlinka zrobić w przeciwnym wypadku.

1. Możesz mieć różne URLe na różnych rootach. Np. zwykły root (/) na /website/web a np. /files na /website/files/. 2. Zależy jak chcesz żeby było. Logikę najłatwiej przerzucić na aplikację, a pliki na nginxa. XSendfile to tylko jeden ze sposobów, na które można zrealizować pobieranie plików przez coś zewnętrznego. Równie dobrze można kombinować naokoło, a nawet jakieś nginxowe proxy postawić... Pytanie tylko brzmi po co, skoro XSendfile jest najprostsze.

Zarówno jedna, jak i druga firma jest dobra w łowieniu jeleni, ale każdy szanujący się klient prędzej czy później się na nich pozna.

Większość pytań jakie zadałeś w ostatnim poście należy zadać właśnie szukanemu przez ciebie superbohaterowi. Jeśli masz choć trochę ambicji, czasu i cierpliwości, a wnioskuję że masz, to bez problemu można się nauczyć administracji linuxami w miesiąc. Co więcej powiem, można się tego nauczyć nawet całkiem konkretnie. Problem robi się wtedy, kiedy najzwyczajniej w świecie nie starcza ci na wszystko czasu, a spotykasz się z o wiele głębszymi problemami, których nie da się rozwiązać poradnikiem z googla. Żaden studenciak za miskę ryżu Ci nie zintegruje aplikacji z chmurą na zadowalającym poziomie. Pewnie, znaleźć znajdziesz, ale równie dobrze mógłbyś to zrobić sam i na bardzo zbliżonym poziomie. Za wiedzę się płaci, i za jakość również. Obawiam się, że będziesz raczej potrzebował jednej osoby, która będzie nad tym czuwała co jakiś czas, bo nie brzmi mi to na jednorazową konfigurację typu set & forget. W zależności od tego jak działa twoja aplikacja, na DDoSy jest co najmniej kilka rozwiązań, ale tu znowu potrzebujesz osoby co zajrzy w projekt i powie co o tym sądzi. Nie można być jednocześnie dobrym programistą piszącym aplikację webową od podstaw i ekspertem od administracji. Można być naprawdę dobrym tylko w jednej z tych rzeczy, a przeciętnym w drugiej. Przeciętny nie oznacza tutaj "słaby", a raczej osobę, która da radę powierzonemu zadaniu, ale zrobi je zauważalnie gorzej niż zrobiłaby jakakolwiek osoba z doświadczeniem w podobnych projektach wdrożeniowych, a takiej się odpowiednio płaci.

Klienci od VPSów za pińć złoty wymagający dedykowanej administracji i SLA 99,99 to już klasyk, ale nie rozumiem w zasadzie dwóch kwestii w tej całej dyskusji 1. Skoro deklarujecie się w ofercie, że robicie kopię zapasową co 24h to rozumiem, że ta kopia sprzed 24h jest dostępna klientowi. Kij ma zawsze dwa końce, ale skoro klient insynuuje, że w 2/3 przypadkach kopii nie uzyskał to albo firma ma głęboko gdzieś to co proponuje w ofercie, albo klient za dużo wypił tego dnia i zmyśla urojone historie. Zapewne jest to pierwsza opcja więc może warto albo te kopie robić, albo jednak wyrzucić mylące zapewnienia z oferty? Bardzo ładnie opisał to Regdos, skoro sprzedajecie jak to tgx ujął "fiata", to czemu reklamujecie go jako mercedesa? Wprowadzacie swoich własnych potencjalnych klientów w błąd, a potem się dziwicie, że narzekają na nie wywiązywanie się z przedstawionej im oferty? 2. Jak to jest możliwe, że w całej firmie nie ma ani jednego administratora, który jakkolwiek zna nginxa? Tu już nawet nie chodzi o dedykowaną administrację, a o jakiekolwiek pojęcie o własnej branży. Pewnie, nic mi do tego kto tam pracuje i jaka strategia panuje w firmie, po prostu jako osoba trzecia jestem ogromnie rozbawiony i zażenowany tym, że klienci są ograniczeni do tego co zna "support" . Boje się spytać co by się stało jakby macierz dyskowa padła, a okazałoby się, że admina od macierzy jeszcze nie ma .

Jak ci zależy to napisz w poście o co chodzi. Mam NPL'kę i szczerze wątpię, żeby twoja "współpraca" nie kłóciła się z warunkami licencji.

dd.