Pan Kot
-
Zawartość
2746 -
Rejestracja
-
Ostatnio
-
Wygrane dni
157
Posty napisane przez Pan Kot
-
-
Nie powinieneś do tego używać php-fpm tylko własnej usługi podpiętej pod systemd czy cokolwiek czego tam używasz jako init, nawet jeśli będzie to głupie polecenie typu php /sciezka/do/twojego/skrypt.php.
FPM się do tego całkowicie nie nadaje.
-
Na pewno nic globalnego - mój bot pięknie trzyma połączenie ze Steamem od 2-3 dni, ale ja sam też na chwilę straciłem, więc pewno coś na linii FR-PL.
-
Przecinek po ósemce ci zniknął. Edytuj póki jeszcze możesz.
Czego się spodziewasz po gościu w domenie @managerseo
-
Nie nazwałbym tego pracą, raz w tygodniu na 3 minuty raczej to pracą nie jest. Już dużo zainwestowaliśmy. Nie możemy ciągle inwestiwać, a nic z tego nie mieć. Zysków ze społecznościówek na razie nie widzimy.
A zyski z robienia sobie czarnego PR na forum i usilnego udowadniania, że nie warto robić z wami żadnych interesów bo nawet nie jesteście w stanie wydać złotówki za poświęconą przez kogoś pracę rozumiem, że będą - w porządku, to na pewno dobry pomysł szukać jeleni na forum takim jak WHT, powodzenia w biznesie życzę
.Mam wrażenie, że wysłaliście tu kogoś kto robi za taką samą stawkę jak ta proponowana
. -
SIGINT to interrupt, SIGTERM to termination. Żaden z nich nie gwarantuje, że w ogóle aplikacja się zakończy, bo to w gestii procesu leży obsługa tych sygnałów i reakcja na nie - sygnał, który kończy proces to SIGKILL, SIGTERM jedynie prosi proces o zakończenie się (i bezpieczne zamknięcie właśnie).
Różnicy między tymi dwoma dużej nie ma, ale SIGINT to sygnał, który jest wysyłany w momencie CTRL+C na aplikacji w foregroundzie właśnie, a SIGTERM jest niejako "zewnętrzny". Wszystkie aplikacje powinny obsługiwać te sygnały w taki sam sposób, bo obydwa proszą aplikację o zamknięcie, ale przyjęło się, że wysyła się SIGTERM'a, a SIGINT jest właśnie na potrzeby CTRL+C (dlatego, że ten sygnał może być wysłany ze standardowego wejścia właśnie).
-
1
-
-
Strasznie sobie słabe forum wybraliście na szukanie jeleni. Próbowaliście na jakimś forum "serwerowni cs:go"?
-
http na https to pikuś
ale mi chodzi o pkt 1) "...czy takie połowiczne wdrożenie przyspieszy strone"
Czy zmniejszenie ładowania elementu X z 10 ms do 5 ms przyspieszy mi stronę gdy element Y ładuje się 10 sekund? NIE.
A żeby odpowiedzieć sobie na to pytanie trzeba najpierw zlokalizować co jest najwoleniejsze, a potem optymalizować, a nie optymalizować w ciemno. Profilowanie to podstawa optymalizacji, jak chcesz optymalizować bez profilowania albo testów to równie dobrze możesz rzucić kostką, bo końcowy efekt może być gorszy od początkowego - i w tym przypadku może tak być, bo szyfrowanie generuje overhead, a nie przyspiesza (z definicji, SPDY i inne cuda pomijamy, nawet jeśli overhead jest minimalny to nadal jest).
-
1
-
-
Mogłeś to delikatniej ująć
Tak bym zrobił, jakby OVH rzeczywiście oferowało w produkcyjnej ofercie produkcyjne serwery - ale to było z góry oznaczone jako OVH discovery + ukryte w tradycyjnej ofercie, i każdy z własnej nieprzymuszonej woli się w to pakował, więc nie widzę potrzeby współczucia
.Co nie zmienia faktu, że jednocześnie się cieszę, że coś się rusza, bo może sam bym przeniósł zabawki z Francji do Polski, ale jak już to co tam się dzieje będzie można nazwać produkcją. A do tego czasu...
Nawet boty wiedzą lepiej co dla nich dobre
.-
3
-
-
A kolejny miesiąc dostali tylko ci co się upominali ?
A co mają jeleni rozpieszczać - sami się na płatne beta testy zapisaliście
.-
3
-
-
Tak, ale jesteś wtedy też uzależniony od ruchów producenta oprogramowania.
Całkiem niedawno u jednego klienta cpanel po automatycznej aktualizacji się wysypał, bo stwierdził, że będzie używał nieistniejącej w systemie ścieżki perla
Także na wszystko trzeba być gotowymPewnie, że tak - każdy kij ma dwa końce, choć w tym przypadku pewno wystarczy zgłosić i naprawią, skoro to regresja.
-
Generalnie to domyślam się, że walczycie
Ale nie mogłem się powstrzymać - wybacz. Mówisz o własnych rozwiązaniach, gdzie tak naprawdę nie masz nic na dzień dzisiejszy i nie możesz "oferować hostingu dla Polaków". Takie tam łapanie za słówka.Co do Autora. Możesz kupić gotowe rozwiązania za 1-3k zł, lub zainwestować kwotę 25+ k (nie ma górnej granicy) w jakieś własne rozwiązanie. Nie wiem jaką masz skalę, ile mamony w portfelu i jakie cele. Popularne ostatnio jest pisanie własnego GUI pod API DirectAdmina/Cpanela. Widzę to po ogłoszeniach o pracę. Mniej więcej działa to tak, że na serwerach chodzą owe "gotowce", a klient dostaje ładny i przejrzysty panel, często zintegrowany z systemem płatności itp. Czy jest to opłacalne? Nie wiem, ale na pewno daje duże możliwości. Więcej o szczegółach technicznych nie napiszę bo nie jestem "specjalistą" od tego, jedynie kilka razy korzystałem z api DA, więc doświadczenie mam małe.
To jest bardzo fajne rozwiązanie bo lepiej i łatwiej się integruje coś co już działa, ma dobrą dokumentację + API, niż pisanie od zera tego samego. Poza tym duża część odpowiedzialności za łatanie, naprawianie, poprawianie i wsparcie leży po stronie rozwiązania, a ty masz się tylko dostosować do API i swojego własnego kodu, co też sporo poprawia końcowy efekt w kwestii wsparcia i poprawek. Sam paneli ani GUI do nich nie robię, ale mam od cholery projektów, w których całość to 10% mojego kodu, i 90% definicji API kilkunastu serwisów. I nie jest to tak, że idę na łatwiznę - to działa lepiej niż jakbym re-implementował to samo co ktoś już dawno zrobił, i to dużo lepiej. Nie wyobrażam sobie pisania np. własnego konwertera walut, kiedy mogę spytać o kursy Yahoo czy cokolwiek innego co mi pasuje.
-
Przydałyby się jeszcze:
- Ansible i do wyboru SaltStack/Puppet/Chef
- Docker
- Jenkins/TeamCity
- Git
Jak mogłem o gicie i dockerze zapomnieć, dodane
. -
Tak, jest ważny i bez RAIDa żadnego serwera bym nie brał. Tak, do gier lepszy będzie SYS z serii GAME, ale z racji braku RAIDa raczej sam bym się na niego nie pokusił, a raczej na coś z RAIDem. i7-SSD-1 brzmi dobrze, mimo że nie ma anty-ddos game - chyba, że nie chcesz i7 i wystarczy Ci xeon, to masz prawie za pół ceny.
-
1
-
-
Ani 0 ani domyślny w okolicach 60 nie jest dobry. Prawidłowe ustawienie serwerowe waha się w widełkach od 1 do 10, w zalezności od setupu.
-
-
Tak, ale przy wykryciu takich rzeczy przez RTM, serwer Ci nie leci w tryb rescue. Serwer leci w tryb rescue przy wykryciu konkretnego ruchu sieciowego, i jeśli RTM jest dostępny/zainstalowany, dodatkowo w mailu dostajesz notkę z jego ostatniego reportu, który może pomóc Ci w naprawieniu problemu. Dlatego właśnie pisze, że usuwając RTM jedynie sam możesz sobie zaszkodzić, bo OVH ma głęboko gdzieś czy go używasz czy nie, a anti-hack nie jest w ogóle od niego zależny.
-
Usunięcie rtm i szpiegostwo + hack detection chyba nam nie groźne?
Bo w jaki inny sposób to wykrywają i co mamy na serwerze.
sed -i '/\/usr\/local\/rtm\/bin\/rtm/d' /etc/crontab && rm -Rf /usr/local/rtm
Serio sądzisz, że RTM jest odpowiedzialny za hack detection? OVH nie musi wiedzieć co masz na serwerze, i w wielu przypadkach nie wiedzą, bo mają lepsze rzeczy do roboty niż włamywanie się na serwery klientów. RTM jest dla Ciebie, i możesz sobie sam podejrzeć co reportuje bo output leci na konsolę - możesz również go sobie wyłączyć, ale sam na tym tracisz.
-
1
-
-
Poza tym 20k godzin pracy na dysk serwerowy to niemależe dotarcie.
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0005 136 136 054 Pre-fail Offline - 92 3 Spin_Up_Time 0x0007 125 125 024 Pre-fail Always - 185 (Average 182) 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 41 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 115 115 020 Pre-fail Offline - 34 9 Power_On_Hours 0x0012 096 096 000 Old_age Always - 31002 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 41 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 135 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 135 194 Temperature_Celsius 0x0002 181 181 000 Old_age Always - 33 (Min/Max 24/44) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
Wszystko zależy od tego co dysk przez te 20k godzin robił - jestem pewny, że mój jeszcze drugie tyle pociągnie
. -
Bez dokładnej rozpiski co było ruszane nie ma opcji oszacować jak bardzo awaryjny dany dysk będzie. Co więcej, nawet z rozpiską jest to trudne bo wadliwe sztuki zdarzają się wszędzie, włącznie z nówkami, dlatego też osobiście mam większe zaufanie do takiego dysku co ma przepracowane 20k godzin i jest w perfekcyjnym stanie niż do nówki bezpośrednio z pudełka, której nikt nie testował.
-
Panele: ISPConfig, Vesta, opcjonalnie Webmin
Web serwery: Nginx, Apache, opcjonalnie Lighttpd
PHP: FPM (nginx), worker (Apache), opcjonalnie HHVM
SQL: MariaDB, MySQL, opcjonalnie PostgreSQL
Języki: Bash (obowiązkowo), PHP, opcjonalnie perl/python (perl jest trochę nieżywy już więc polecam pythona)
Monitoring: Zabbix, Nagios, opcjonalnie Munin
DNS: Bind, opcjonalnie dnsmasq (caching)
Firewall: iptables, opcjonalnie ufw/bastille
Security: fail2ban, ssh, sftp, pojęcie chroot/jail, LXC, opcjonalnie jailkit
Wirtualizacja: KVM, LXC (po raz drugi), Docker, Proxmox, opcjonalnie Xen/OpenVZ
Poczta: Postfix, Dovecot, Spamassassin, clamd, rainloop, opcjonalnie exim4
SSL: Let's encrypt, różnice między typami certyfikatów (dlaczego jednak nie let's encrypt do wszystkiego?)
Systemy: Debian, Ubuntu, CentOS, Archlinux, FreeBSD i różnice między nimi, opcjonalnie Gentoo
Optymalizacja: memcached, varnish, cloudflare
Kontrola wersji: Git (obowiązkowo), opcjonalnie mercurial/subversion
Automatyzacja: Ansible, opcjonalnie SaltStack/Puppet/Chef
Opcjonalnie:
Non-SQL: MongoDB, Riak, Cassandra
Kernel: Linux, Grsecurity, kompilacja ze źródeł, instalacja, debugowanie, umiejętność odpowiedzi na pytanie dlaczego noop na hdd to zły pomysł.
Języki: C, pominięty perl/python (tym razem obowiązkowo), ruby
Narzędzia: ptrace, strace, gdb, valgrind, syslog
Środowiska: systemd, java, mono (C#)
CI: Jenkins, TeamCity
To jest stos haseł, które powinieneś znać, i potrafić się nimi posługiwać. Umyślnie nie rozwijam żadnego z nich - to ty musisz wiedzieć jak ten stos haseł ze sobą współpracuje i dlaczego dany program został tutaj zawarty.
Jestem pewien że pominąłem co najmniej kilkanaście rzeczy które powinny się tu znaleźć, edytuję posta jak sobie przypomnę.
Znajomość większości haseł powyżej bez problemu otworzy drogę do wielu firm IT, choć spędzisz co najmniej kilka długich lat jeśli zamierzasz poznać wszystko to co podałem wyżej w stopniu zadowalającym.
-
W tej cenie najlepsze będą Xiaomi. Zarówno szajsung jak i blackberry się strasznie stoczyły i ich średnia półka jest po prostu słaba.
-
A tak serio to również ten artykuł mnie wprawił w zdumienie jak łatwo wam przychodzi zrzucanie winy na decyzje poprzednich osób, całkowicie zapominając o tym, że była to wspólna decyzja na kilka lat wcześniej gdy dopiero raczkowaliście jako hosting, a kasa zamiast w maszyny to szła w social media.
Awarie zdarzają się każdemu, ale to jak ją ogarnęliście zostawia wiele do życzenia, i przynajmniej ja mam spory niesmak po tym wywiadzie.
-
2
-
-
U mnie ładnie w Warszawie. IMHO nie warto od razu zakładać najgorszych scenariuszy, akurat UPC przynajmniej u mnie nigdy nie sprawiało większych problemów - warto zadzwonić i się spytać, może po prostu mają jakąś awarię.
-
Jeśli pytasz czy na KVM/XEM zrobisz to czego teraz zrobić nie możesz - tak.
Logi ze screen
w Administracja Serwerów
Napisano · Raportuj odpowiedź
Po co Ci logi jak odpalasz aplikację w screen? Przecież masz całą historię w oknie.
A jak potrzebujesz dodatkowo czegoś takiego to zainteresuj się tee.