#lurkerchangelog / ależ fakap!! od soboty(!) były problemy z działaniem apki. od teraz wszystko powinno być OK. jesli jeszcze raz komuś będzie pulsować logo w nieskończoność, bardzo proszę o pilny kontakt (oczywiście jeśli F5 nie rozwiąże sprawy
)
ja pitole!!!
…pod spodem opis ciekawego kejsu, jak to próbowałem narzędziami sieciowymi monitorować, w którym miejscu firewall wycina ludzi (jedne IP mogły wchodzić na stronę, inne w ogóle), a okazało się cos zupełnie innego 
1) w sobotę u siebie na Debianie zrobiłem upgrade systemu (robię raz na miesiąc średnio);
2) zaktualizował się także node.js, z wersji v14.12 na v14.13;
3) robiłem w międzyczasie dużo buildów i deployów na serwer (update funkcji, bo codziennie coś tam kodzę);
4) wszystkie paczki (moduły npm) instalują się po stronie serwera (npm install);
5) ale… jeden z nich się mocno wyróżnia. nazywa się bcrypt. to jest plugin, ktory wymaga skompilowania i przy zmianie wersji node-a, trzeba ją zrobić ponownie;
6) na serwerze (do teraz) miałem wersję node v14.12 (a u siebie, od soboty, v14.13), bcrypt nie działała jak trzeba;
7) ten moduł (bcrypt) na lurku służy m.in do resetowania hasła (hashuje nowe hasło usera). za każdym razem, jak ktoś resetował hasło, ubijał workera;
8) na serwerze jest 6 workerów - są one przypisane do klientów przez adres IP (tzw. ip-hash, zamiast klasycznego round-robin), 1 user = 1 przypisanie workera na stałe (bo korzystamy z socketów i to nie może byc zmieniane w locie);
9) jak worker padł, ludzie nadal byli do niego przypisani (to nie było klasyczne padnięcie, że pm2 może zrobić reset workera, a proxy-server przekierować ruch na nowy worker), ale ciche padnięcie, które nie zwracało żadnych błedów, a po prostu zwieszało worker na amen (robił się wieczny pending i timeout ubijał połaczenie, zero info w logach, gdziekolwiek);
tak wiec nie było problemu z firewallem… niemniej tak: z jednych adresów (przypisanych do "martwych" workerów) nie dało się wchodzić, podczas gdy inne adresy IP działały bez zarzutu. (a więc po długiej batalii, gdzie najpierw sprawdzałem czemu PWA na telefonie nie śmiga, a potem proxy z Bułgarii, a potem jeszcze inne rzeczy), eh.. cieezki temat
to tak w skrócie
jesli ktoś jeszcze doświadczy pulsującego loga, proszę o info, bo to wówczas bedzie znaczyło, ze to nie było to
(ale to było to
). daję sobie 48h na testy, jak sie w tym czasie ani razu nie wysypie, bedzie ok. nie bede resetować workerów, czyli finalnie wszystkie padną i apka (dla każdego) przestanie działac, co bedzie potwierdzeniem, że jest nadal lipa (ale nie powinna być).
POZDRO!
)ja pitole!!!
…pod spodem opis ciekawego kejsu, jak to próbowałem narzędziami sieciowymi monitorować, w którym miejscu firewall wycina ludzi (jedne IP mogły wchodzić na stronę, inne w ogóle), a okazało się cos zupełnie innego 
1) w sobotę u siebie na Debianie zrobiłem upgrade systemu (robię raz na miesiąc średnio);
2) zaktualizował się także node.js, z wersji v14.12 na v14.13;
3) robiłem w międzyczasie dużo buildów i deployów na serwer (update funkcji, bo codziennie coś tam kodzę);
4) wszystkie paczki (moduły npm) instalują się po stronie serwera (npm install);
5) ale… jeden z nich się mocno wyróżnia. nazywa się bcrypt. to jest plugin, ktory wymaga skompilowania i przy zmianie wersji node-a, trzeba ją zrobić ponownie;
6) na serwerze (do teraz) miałem wersję node v14.12 (a u siebie, od soboty, v14.13), bcrypt nie działała jak trzeba;
7) ten moduł (bcrypt) na lurku służy m.in do resetowania hasła (hashuje nowe hasło usera). za każdym razem, jak ktoś resetował hasło, ubijał workera;
8) na serwerze jest 6 workerów - są one przypisane do klientów przez adres IP (tzw. ip-hash, zamiast klasycznego round-robin), 1 user = 1 przypisanie workera na stałe (bo korzystamy z socketów i to nie może byc zmieniane w locie);
9) jak worker padł, ludzie nadal byli do niego przypisani (to nie było klasyczne padnięcie, że pm2 może zrobić reset workera, a proxy-server przekierować ruch na nowy worker), ale ciche padnięcie, które nie zwracało żadnych błedów, a po prostu zwieszało worker na amen (robił się wieczny pending i timeout ubijał połaczenie, zero info w logach, gdziekolwiek);
tak wiec nie było problemu z firewallem… niemniej tak: z jednych adresów (przypisanych do "martwych" workerów) nie dało się wchodzić, podczas gdy inne adresy IP działały bez zarzutu. (a więc po długiej batalii, gdzie najpierw sprawdzałem czemu PWA na telefonie nie śmiga, a potem proxy z Bułgarii, a potem jeszcze inne rzeczy), eh.. cieezki temat

to tak w skrócie
jesli ktoś jeszcze doświadczy pulsującego loga, proszę o info, bo to wówczas bedzie znaczyło, ze to nie było to
(ale to było to
). daję sobie 48h na testy, jak sie w tym czasie ani razu nie wysypie, bedzie ok. nie bede resetować workerów, czyli finalnie wszystkie padną i apka (dla każdego) przestanie działac, co bedzie potwierdzeniem, że jest nadal lipa (ale nie powinna być).POZDRO!

Ostry_Burrito
0
Odpaliłem VPN-a i wszedłem bez problemu.
Thanos
1
wiktor
1
Thanos
0
(btw. bład nadal wystepuje, ale jestem juz bliski jego namierzenia
lilyy
1
Macer
1
bmpte
3
Czy to monitor na procesy, czy na logi (np. brak nowych logów ;p)
Thanos
0
tylko że te workery nie były do końca martwe. status był ok. to były workery zombie
po prostu przyjmowały request i …nic dalej się nie działo. nie mogłem tego wyłapać na żadnym etapie (ale niby działały
bmpte
0
Thanos
0
bmpte
1
Thanos
0
sam worker dziala dobrze (przetesetowalem go, kazdy z osobna, bo znowu wywaliło
no nie wiem do konca. mega zagadka. musze to dzisiaj naprawić
bmpte
1
moze open sockets, może coś na conntracku, może nginx ma defaultowe niskie jakieś a nie ustawiłeś większych …
no, szukaj