Pan Kot

W takim razie polecam się zastanowić czy masz odpowiednią konfigurację swoich usług, bo jeśli tak jest to reload takiego nginxa, postfixa czy czegokolwiek co może być współzależne od certyfikatu LE powinien być a) bezkonfliktowy i b) bezproblemowy - usługa powinna sama stwierdzić które elementy trzeba zreloadować, i czy jakieś w ogóle. Tak jest w przypadku nginxa i postfixa, oraz wielu innych podobnych usług, które mogą zależeć od certyfikatów, i reload bez powodu nie wpływa w żaden sposób na ich dostępność czy status. Jeśli serio w skrypcie restartujesz usługi w oparciu o certyfikaty, które zostały odnowione to robisz to źle. Łamiesz zasadę pojedynczej odpowiedzialności w systemach UNIX i zmuszasz LE to odwalania roboty kogoś innego. To usługa ma dostać powiadomienie o możliwości zapotrzebowania na reload, i podjąć decyzję czy w jej stanie takowy reload jest możliwy i potrzebny. Dodawanie własnej logiki restartu różnych usług w zależności od tego które certyfikaty zostały odnowione jest okropne i kopnie Cię w tyłek jak tylko zaczniesz głębiej na tym bazować. Ale rób co uważasz, dzięki takim osobom jak ty mam z czego żyć .

Nie rozumiem o co Wam chodzi, kori jako jedyny stoi na straży porządku na WHT.

A, to jak wiesz lepiej to nie będę na następny raz podpowiadał gdzie można znaleźć odpowiedź na takie rzeczy, widać niepotrzebnie próbuję pomóc . I tak, da się to zrobić bez próby zrobienia tego na około tak jak zasugerowałeś, tylko trzeba zacząć czytać te długie teksty zamiast szukać na google jak to zrobić szybko i "aby działało", ale co kto lubi .

Wszystko w dużej mierze zależy zarówno od losowości w postaci serii, producenta, typu, ale i również rzeczywistego wykorzystania tego dysku. BARDZO często dysk, który ma przepracowany już jakiś czas okazuje się dużo stabilniejszy niż całkowicie nowy, i każdy Ci to powie. Kwestia jest taka, że to jest pewnego rodzaju generalizacja i opieranie się o statystyki - każdy powinien we własnym zakresie co jakiś czas sprawdzać SMARTa i informować firmę o swoich obawach - jeśli odczyty są niepokojące to żadna szanująca się firma (a nawet masówka taka jak OVH) nie będzie Ci robić problemów i na siłę czekać aż będzie za późno - sprawdzą, stwierdzą że masz rację i wymienią. Im też jest na rękę zrobić to zanim usługa padnie, a klient się wkurzy, niż ryzykować. Nigdy nie sugeruj się ilością przepracowanych godzin: 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 9 Power_On_Hours 0x0012 097 097 000 Old_age Always - 26390 Mam do tego dysku większe zaufanie niż do jakiejkolwiek "nówki" .

Jakbyś przeczytał dokumentację narzędzi, które używasz, zamiast działać na zasadzie "sprawdzę w google i zrobię coś na szybko" to byś znalazł zarówno --pre-hook jak i --post-hook, oraz klarowną i konkretną informację: Ale po co, tylko frajerzy czytają dokumentację, łatwiej napisać na forum i niech ktoś inny przeczyta .

Wy to sobie umiecie utrudniać życie . find /path/to/gdziestam -type f -name "*.txt" | cut -d '.' -f 1 > wynik.txt Chociaż jak chcesz zrobić wersję reliable gdzie kropka może występować częściej niż raz to powinieneś zrobić: find /path/to/gdziestam -type f -name "*.txt" | rev | cut -d '.' -f 2- | rev > wynik.txt

Albo export PATH=/opt/cmake/bin:$PATH

Ale nginx już jest i nie trzeba specjalnego urządzenia do niego .

Nikt Cię nie aresztuje, po prostu Ci konto zablokują .

Od zleceń jest inny dział.

Z jednej strony tak, z drugiej strony ta wiedza będzie ponownie reusowana przy twoim każdym następnym projekcie, bo ja odkąd nauczyłem się laravela to stawiam go w zasadzie wszędzie, jedynie pod proste rest API leci Lumen, ale to tylko i wyłącznie dlatego, że wiem iż nigdy nie wykorzysta potencjału Laravela. W zasadzie to myśląc przyszłościowo Lumen będzie najlepszym wyborem, bo możesz cały swój serwis w kilkanaście minut przerzucić na Laravela i dalej rozwijać jak zajdzie taka potrzeba, a życie mnie nauczyło że jak teraz siadam do czegoś nowego to zakładam, że za kilka miesięcy mój kod rozrośnie się tak bardzo, że będę chciał mieć dobry fundament w postaci frameworka, a nie wszystko przepisywać.

Polecam Lumen - lżejszy Laravel, który powinien się świetnie sprawdzić jako redirector, ale też zastanów się dwa razy czy nie lepiej tego upchnąć na samym Laravelu - nie jest aż tak ciężki jak uważasz, a osobiście nie spotkałem się z lepszym frameworkiem do tego typu rzeczy do tej pory, przynajmniej w PHP. Jeśli jednak ma to być coś naprawdę prostego, a nie aż tak elastycznego jak Laravel, to Lumen się świetnie powinien sprawdzić.

Pewnie dlatego, że w twoim przypadku bym się pobawił HHVM, memcached czy varnishem, a nie wtyczkami do WP, ale co kto lubi .

Jak nie masz żadnego logowania, ciasteczek ani innych rzeczy i prezentujesz czystą wizytówkę to i owszem można tak zrobić, nie wiem czemu założyłem, że jak ktoś ma problemy z wykonywaniem skryptów to jednak ma więcej dynamicznych danych do przetworzenia i takie rozwiązanie go nie zadowoli .

Weź tylko pod uwagę, że żeby Super Cache w ogóle zadziałał to i tak musi się ten php wykonać - przynajmniej do momentu załadowania wtyczki, która przekieruje request do statycznego zasobu. To będzie strasznie niepraktyczne stwierdzenie, ale zakładając że gość serwuje ludziom gołego wordpressa to instalacja wtyczki i włączenie cache'owania pogorszy mu wyniki, bo ten sam WP szybciej wygeneruje pusty content niż załaduje wtyczkę, przekaże request i odczyta odpowiedź. Oczywiście tak jak napisałem, to jest strasznie niepraktyczne stwierdzenie, bo nikt nie hostuje gołego wordpressa, ale prawdą jest że jak chcesz do jakiegoś bottlenecku dojść i go rozwiązać to go namierzasz i profilujesz różne rozwiązania żeby znaleźć to odpowiednie, a nie na ślepo integrujesz coś co ma pomóc - to dotyczy każdego software'u, nie tylko php. Tak więc ja bym najpierw sprawdził w czym problem, a potem zaczął coś wdrażać, bo jeśli skrypty wykonują się dostatecznie szybko to żaden cache i żadne rozwiązanie Ci nie pomoże w walce z twardym limitem, i trzeba zmienić pakiet lub hosting.

Mówiłem to już 3 razy BH, i powtórzę po raz kolejny tutaj - najzwyklejszy w świecie combobox w panelu klienta czy wyraża zgodę na kontakty telefoniczne - Tak/Tylko w ważnych okolicznościach/Nigdy, z ładną adnotacją, że w przypadku zaznaczenia innej opcji niż "Tak" powiadomienia odnośnie usług idą wyłącznie mailowo i w przypadku usunięcia maila, jego niedotarcia albo innych okoliczności niespowodowanych winą usługodawcy, brak zapłaty w terminie jest traktowany jako rezygnacja z usługi. Tu serio nie trzeba wyższej logiki, doktoratu z psychologii i socjologii żeby dogodzić klientowi i domyślić się co sobie życzy - wystarczy spytać tworząc mu adekwatne opcje do wyboru, i ustawić domyślnie "z głową", czyli najczęściej to co odpowiada usługodawcy. A jeśli klient pomimo tego w trakcie rozmowy stwierdzi, że sobie takich kontaktów nie życzy - można najzwyczajniej w świecie mu przypomnieć że ma możliwość zmiany w panelu (albo i zmienić za niego jeśli firma uważa to za słuszne).

Najłatwiej postawić na VPSie jakiś serwer XMPP - ejabberd chociażby, i do niego podłączyć się jakimkolwiek klientem np. Pidginem. Jak się pobawisz to dobre bezpieczeństwo można zrobić zarówno po stronie samego XMPP, ale i po stronie klientów, np. pidginowym OTRem.

Proxmox to jedyne sensowne rozwiązanie moim zdaniem.

https://packages.debian.org/jessie/rsyslog rsyslog nie ma dependency na eximie, a logrotate jest sugerowany, nie wymagany, z kolei on również nie wymaga, a sugeruje mailx. Polecam przestać instalować pakiety razem z sugerowanymi, może dużo pomóc. root@archi:~# dpkg -l rsyslog exim* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=====================================================-===============================-===============================-=============================================================================================================== un exim4 <none> <none> (no description available) ii rsyslog 8.16.0-1+b3 amd64 reliable system and kernel logging daemon

Od limitów nginxa jest 503, a nie 502 Bartku . No chyba, że masz limity po stronie php.ini, to się nie wtrącam.

do { refresh(); } while (httpcode != 200);

Akurat tu się nie zgodzę - TS3 z ich pierdzielniętym systemem licencji jest dużo gorszy jeśli się przyczepić do punktu drugiego. Reszta jak najbardziej.

Spotkałeś się kiedykolwiek z awarią obydwu swoich nameserverów?

Chyba też jirę polecę, ale pewnie coś innego też się znajdzie, tyle że nic z czego korzystałem.

Dobrym pomysłem to nie jest pakowanie TSa w MySQL - overhead w postaci socketów i przesyłania danych + niepotrzebnego obciążenia bazy, która ma lepsze rzeczy do roboty nie wyjdzie nikomu na plus. Musiałbyś mieć kilkaset serwerów na jednej maszynie, żeby w ogóle zacząć się zastanawiać czy z punktu wydajnościowego MySQL będzie lepszy. Opóźnienie wynikające z dostępu do bazy MySQL w porównaniu do SQLite jest odczuwalne nawet bez pomiarów. W 99.9% przypadków SQLite będzie lepszy pod każdym względem, a ten specyficzny 0.1% bardzo dobrze zdaje sobie sprawę z tego dlaczego MySQL jest lepszym wyborem. I nie, nie należysz do tego 0.1% - ja też nie.