Skocz do zawartości

Spoofy

Donatorzy
  • Postów

    253
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    49

Odpowiedzi opublikowane przez Spoofy

  1. Nice catch. Wygląda na default'owo skonfigurowany CSF+LFD ze skryptem zgłaszającym do AbuseIPDB: https://www.abuseipdb.com/csf .

    Generalnie partycypowanie w tym projekcie jest dobre, natomiast IMHO powinno się to robić troszkę z głową, np. wycinając zbędne, wrażliwe dane i false positive'y. Generalnie https://www.abuseipdb.com/reporting-policy .

    W kwestii logowań, sądzę że wątpliwe byłoby przekazywanie jakichś pełnych debug/verbose logów z hasłami gdzieś zewnętrznie, lecz oczywiście pewności nie ma.

  2. Heh, fajnie obserwować, jak przetartym przeze mnie szlakiem "target" szuka dostępności w DE-CIX.

    Kto jak kto, ale akurat Ty powinieneś wiedzieć, że gwarancja AntyDDoS do 40 Gbps w standardzie to troszkę za mało na dzisiejsze standardy ;) Cena dodatkowej ochrony do 100 Gbps to dodatkowe 160 euro - cóż, o ile pamiętam to oferty tego typu dalece wykraczają poza budżet dostępny dla tego targetu, także dziwię się, że rozpatrujesz takową. Wiesz również, że bottery posiadają okruchy dużych botnetów i potrafią np. z Miraia bezpośrednio wygenerować ruch rzędu 1Tbps+, no ale przecież AntyDDoS'y to temat rzeka... ;)

    Jeżeli Holandia to zamiast https://www.greenhousedatacenters.nl/ polecałbym sprawdzony GSL. Ahm i odradzam Rotterdam - straszne miasto, nic do zobaczenia, fajne jedynie na imprezy wieczorem.

  3. Cześć,

    Support JetBackup z tego co pamiętam, (również ze względu na historię w tym produktów) był zawsze na wysokim poziomie.

    Coś więcej? Jaki panel? Jaka wersja? Jaka metoda (backup/sync czy clone)? W jaki konkretnie sposób ustawiasz backup job? Dopóki nie ustawiasz filtrowania kont, to job jest raczej tworzony domyślnie dla wszystkich kont.

  4. Z własnego doświadczenia wiem, że raczej realizacja zamówień publicznych w podobnych przypadkach potrafi być mocno weryfikowana, tym bardziej składniki realizowane na podstawie konkretnego, popularnego, rządowego programu i oddelegowanych zasobów machiny urzędniczej - zatem raczej nie jest to przypadek.

  5. Ogólnie - baza, bazie nie równa - zależnie od rodzaju operacji (read vs write), ich ilości, rodzaju konfiguracji (cache?), ewentualnego HA etc. - lecz najważniejsze, jaka to baza i jakie oprogramowanie, co determinuje inne czynniki dotyczące tejże konfiguracji, zarówno pod kątem softu jak i hw.

    SSD != SSD, zarówno pod kątem bezpieczeństwa jak i szybkości. Tutaj też potrzebny jest konkretny wymóg wydajnościowy i konkretny benchmark, czy założone wartości są spełnione.

    Dogłębnie znając i stosując LXC w rożnych aspektach, stawianie VM pod bliżej nieokreśloną bazę danych wydaje się marnotrawieniem zasobów. MySQL, MSSQL, ES, Mongo, Influx etc. - większość pójdzie bez problemu w bezpiecznej "przestrzeni nazw" i nie potrzebuje pełnej wirtualizacji.

    Domyślam się, że wiesz jak działa Proxmox i jest to właściwie niemiecki Debian z pewną filozofią dotyczącą RAID i filesystemów. Istotniejszy jest wykorzystywany filesystem, niż ułożenie macierzy.

    MySQL i snapshoty - czyli już jakiś konkret - snapshotting wspierany jest przez konkretne filesystemy, tak więc na Twoim miejscu, prędzej pytałbym np. czy LARC/ZVOL z dysków SSD mają znaczenie przy takich operacjach na macierzy HDD. W przypadku ZFS pamięć RAM i jej dostępność powinna zostać ujęta w rozplanowywaniu zasobów. Pan @Poziomeckiświetnie to opisał.

    Oczywiście pamiętamy o złotej zasadzie: snapshot != backup .

     

    CEPH na 10G to tylko do małych operacji. Tak jak wcześniej - tak, snapshotting dostępny jest tylko przy wybranych filesystemach.

     

    8 godzin temu, mbl napisał:

    Mam już swojego blaszaka.

     

    Zapytałbym, jaki kontroler dysków jest wykorzystywany i w jaki sposób skonfigurowany - ma to zazwyczaj duże znaczenie wydajnościowe pod kątem baz danych. Przy ZFS musisz mieć raw dostęp do dysków lub JBOD/IT mode.

  6. 23 godziny temu, Hostline.pl napisał:

    Wszystkie usługi działają poprawnie. Nie mieliśmy również żadnych awarii. Podaj proszę w PW swoje ip.


    Myślę że to wyjaśnia konkretnie. Czemu opieracie się o serwis, który w wielu przypadkach jest zablokowany? Zarówno w popularniejszych jak i na mojej czarnej liście, znajdują się wszystkie adresy i domyślnie serwis check-host.net jest zablokowany, lecz nie ma to absolutnie żadnego wpływu na działanie usług docelowych.

    Także taka sugestia ode mnie - jeżeli sprawdzacie kwestie webowe, nie korzystajcie z tak oczywistych źródeł/serwisów, które nie dają realnego obrazu sytuacji.

    • Lubię 1
  7. 5 minut temu, GrochowskiNinja napisał:

     Très magnifique, sacrebleu.

    Gorzej że order i tak musisz opłacić z pradawnej (chyba pamiętającej jeszcze manager v3? i oczywiście białej) strony.

  8. Odkopię, gdyż wpadła mi w ręce analiza raportu BEA-RI.

    Ciekawa historia o francusko-niemieckiej łodzi EUROPA, bez której ugaszenie i zablokowanie rozprzestrzeniania się  pożaru na dalsze budynki, byłoby niemożliwe.
    Bateau_Europa1_franco-allemand%2C_Rhin_-_mars_2014.JPG
    (zdjęcie wyszukane na szybko - może nie przedstawiać rzeczywistej jednostki, ale chyba jednak jest to ta jednostka ;) )

    Generalnie posiłkując się translatorem, troszkę z przerażeniem czytam wnioski i w związku z tym, chciałbym zapytać - w jaki sposób @OVH spełnia normy i certyfikacje (zaczynając od uptime institute tier-3, kończąc na wszystkich ISO/* etc.) - skoro nie posiada automatycznego systemu przeciwpożarowego?

    Jak zaznacza autor - raport ma na celu poprawę bezpieczeństwa a nie ocena kto jest winny, lecz raport zawiera takie określenia:

    Cytat

    OVH w Strasburgu nie było automatycznego systemu gaśniczego
    Istniały gaśnice, jeśli nie automatyczne: opierały się na mężczyznach obecnych 24 godziny na dobę i gaśnicach.

    Raport z dochodzenia BEA-RI potwierdza te informacje, które były znane, patrz temat OVH i ochrona przeciwpożarowa z 2013 roku, na długo przed pożarem.

    Wyciąg z raportu z dochodzenia BEA-RI:
    Pomieszczenia te, zwane również „pomieszczeniami energetycznymi”, wyposażone były w wykrywanie pożaru, ale nie posiadały automatycznego systemu gaszenia.

    Cytat

    OVH w Strasburgu nie było automatycznego systemu gaśniczego
    Istniały gaśnice, jeśli nie automatyczne: opierały się na mężczyznach obecnych 24 godziny na dobę i gaśnicach.

    Raport z dochodzenia BEA-RI potwierdza te informacje, które były znane, patrz temat OVH i ochrona przeciwpożarowa z 2013 roku, na długo przed pożarem.

    Wyciąg z raportu z dochodzenia BEA-RI:
    Pomieszczenia te, zwane również „pomieszczeniami energetycznymi”, wyposażone były w wykrywanie pożaru, ale nie posiadały automatycznego systemu gaszenia.
    [...]
    Pomimo szybkiego przybycia służb ratowniczych, projekt budynku, brak automatycznego systemu gaśniczego, opóźnienie w zabezpieczeniu miejsca pod względem elektrycznym i zasoby wodne w okolicy nie zapobiegły powszechnemu pożarowi SBG2 i rozprzestrzenianiu się pożar do sąsiednich budynków.
    [...]
    W zakresie ochrony przeciwpożarowej obiekt wyposażony jest w system detekcji połączony ze stałą obecnością personelu przeszkolonego w zakresie obsługi gaśnic. Nie jest jednak wyposażony w automatyczny system gaśniczy. Ochronę przeciwpożarową sektora zapewnia sieć publiczna składająca się z jednej linii zasilającej i hydrantu przeciwpożarowego.
    [...]
    OVH zdecydowało się nie wyposażać żadnego z pięciu budynków swojego centrum danych w Strasburgu w automatyczny system przeciwpożarowy. Przypominamy, że system przeciwpożarowy może pełnić kilka funkcji:
    • Gaszenie ognia,
    • Kontrola lub odwzorowywanie pożaru, co pozwala powstrzymać jego postęp i dać czas na organizację i interwencję służb ratowniczych.
    Co więcej, w przypadku instalacji takiej jak data center, umożliwia wdrożenie zasobów wodnych na bardzo wczesnym etapie sekwencji awarii, nawet bez czekania na zatrzymanie dostaw energii elektrycznej i bez narażania personelu na ryzyko porażenia prądem.
    [...]
    Publiczne służby ratownicze dysponowały jedynie hydrantem przeciwpożarowym, który zapewniał niewystarczający przepływ (poniżej 60m3/h). Operator nie posiadał również własnego zapasu wody gaśniczej ani sposobu pompowania w kanale Renu. Biorąc pod uwagę szybką i niekorzystną ewolucję incydentu, szybko poprosili o wsparcie pontonu EUROPA, który przybył w rejon o 3:00 nad ranem. [...] łódź ta odegrała decydującą rolę w zarządzaniu pożarem, biorąc pod uwagę brak własnych środków gaszenia przez operatora i ograniczoną przepustowość sieci przeciwpożarowej (DECI) na tym obszarze. W przypadku braku takich środków skutki pożaru byłyby prawdopodobnie większe na sąsiednich budynkach.
    [...]
    System ochrony automatycznej i zależnej od wykrywania jest projektowany zgodnie z pożądanym celem: gaszenie pożaru, redukcja pożaru lub kontrola pożaru.
    [...]
    Ponieważ centrum danych, takie jak centrum OVH, nie jest ani systemem ERP, ani IGH, wymagania regulacyjne w zakresie gaszenia zasobów wodnych są zasadniczo objęte przepisami dotyczącymi ICPE w odniesieniu do ładowania i eksploatacji akumulatorów. Dochodzenie wykazało, że te wstępne wymagania nie zostały spełnione.
    Ale poza tą kwestią zgodności, BEA-RI uważa, że te środki, nawet obecne, prawdopodobnie nie umożliwiłyby uniknięcia pożaru SBG2 z powodu braku szybkiego wdrożenia w odniesieniu do kinetyki ognia. Wypadek ten pokazuje zatem, że w przypadku braku wystarczającej wielkości zachodzenia na siebie, powszechny pożar jest prawdopodobnym scenariuszem, z którym operator centrum danych oraz, w przypadku awarii, lokalna publiczna służba ratunkowa muszą być w stanie sobie poradzić. Dlatego ważne jest przewidywanie tej sytuacji pod kątem strategii interwencji i wielkości zasobów wodnych.


    Stanowisko OVH było takie, że gdy zostali przesłuchani przed pożarem, mieli system wykrywania w każdym miejscu w połączeniu ze stałą obecnością personelu przeszkolonego w zakresie obsługi gaśnic.
    OVH dysponuje skutecznym systemem wykrywania pożarów i personelem 24/7 na miejscu, który może bardzo szybko interweniować. Zostało to zademonstrowane 10 marca 2021 r.

    Gaśnica nadaje się do rozpoczęcia wielu katastrof. Na przykład wybuch pożaru zwykle wywoływany przez wadliwy zasilacz komputera. Personel prawdopodobnie będzie na miejscu przed najmniejszym płomieniem i nie będzie to miało żadnego wpływu poza serwerem, który jest przyczyną katastrofy. Raport z dochodzenia BEA-RI pokazuje, że OVH nie było przygotowane na pożar na dużą skalę, który bardzo szybko stał się niekontrolowany: brak procedury wyłączania prądu w budynkach, brak wystarczającego zaopatrzenia w wodę (na szczęście była ta francusko-niemiecka łódź ).


     

  9. W dniu 25.05.2022 o 16:40, theqkash napisał:

    Generalnie natomiast są jakieś branżowe zasady, które się stosuje do rzeczy, o które pytasz, ale są one raczej ogólne i nieformalne, a ponadto każdy operator może działać według własnych zasad. 

     

    Generalnie nomenklatura czasem zdradza pewne kwestie. Jest to też jedna z metod pozyskiwania informacji - standardem jest badanie stref DNS (w tym historycznych) np. pod kątem adresów (często również wewnętrznej) infrastruktury. Inny nie techniczny przykład, to seria faktur.

     

    W dniu 25.05.2022 o 16:40, theqkash napisał:

    Podobnie sprawa ma się z DC - w moim mniemaniu lokalizacja powinna być traktowana tak samo jak Data Center, ale to też każdy operator ustawia pod siebie. Możliwe też, że ta lokalizacja się nie wyświetla, bo jest traktowana jako fail-over, ale to powinien też operator wyjaśnić.

    Lokalizacja:
    1. «miejsce, w którym znajduje się lub ma się znaleźć jakiś obiekt»
    2. «określenie położenia jakiegoś obiektu»
    3. «ograniczenie skutków jakiegoś zjawiska do pewnego obszaru»

    Moim skromnym zdaniem, zarówno szczegółowość jak i nomenklatura, zarówno dla publicznych jak i wewnętrznych zasobów, powinna być opisana, inaczej nawet takie publiczne statusy nie mają większego sensu. Jeżeli tak nie jest, to prawdopodobnie z jakiegoś powodu.
     

    W dniu 25.05.2022 o 18:36, root85 napisał:

    Oj wiele nowych kont się pojawiło w ostatnim czasie tylko po to, aby wypowiedzieć się o dh :) Bardzo wiarygodne. Skorzystam z okazji. Pracowałem kiedyś w dh

    Nie ma tutaj "duzo nowych kont" - raczej znani użytkownicy. Jak widać, kontrola pod kątem multikont jest tutaj utrzymana.
     

    W dniu 25.05.2022 o 18:36, root85 napisał:

    Faktycznie dzisiaj dali d..., awaria trwała kilka godzin. No, ale która firma ma sla na poziomie 100%? Zawsze to pole do ataku :) 

     
    Widzisz, są takie które do czegoś aspirują albo próbują, są tacy giganci, którzy opisując technologię, nie muszą ubierać czegoś w papkę marketingową i potrafią mieć "SLA 100%" pod kątem usług. Żyjemy w XXI wieku, tutaj wszystko jest szybko, HA, on demand, także może za "Twoich czasów" branża wyglądała inaczej, ale rynek weryfikuje dość szybko.
     

    W dniu 25.05.2022 o 18:36, root85 napisał:

    Dotacje - to nie jest tak, że każdy może się ubiegać, a urzędnicy są od ich przyznawania? Chyba, że jest tutaj ktoś specjalizujący się w nich, nie wiem, nie znam się, jestem laikiem. Skoro dostali to znaczy, że potrafili się o nie ubiegać. Mam firmę, chyba sam spróbuję. 

     

    Nom niestety, widać że nie wiesz o czym mówisz. Wszystkie fundusze są w ramach danych programów, także znana jest praktyka w tym zakresie i dysproporcje między rożnymi rodzajami dotacji czy ich źródeł. Założysz działalność, to szybko się o tym przekonasz ;)

     

    20 godzin temu, root86 napisał:

    Ty to masz chyba za dużo wolnego czasu xD  :P 

     

    Może został poszkodowany w wyniku awarii? Czemu nie pomyślałeś o tym, skoro pracowałeś w takim miejscu, hm? Niestety, wiele Twoich słów, rozmija się z m.in. z moim, bardzo krótkim, jak i innych pracowników doświadczeniem w tym zakresie.
     

    W dniu 25.05.2022 o 18:36, root85 napisał:

    Na koniec poczekajmy na info od dh, od kilku dni cisza. Jestem ciekawy ich punktu widzenia. 

    Jak widać, PR'owo DHosting postanowił wybrać quiz na fanpage'u, zamiast wziąć udział w dyskusji lub odnieść się do wypowiedzi w temacie opinii.

     

    1 godzinę temu, root87 napisał:

    Piszę z numeru 87, bo na poprzednich niestety nie działa hasło ;) 

     

    Nie wiem czy dalej pracujesz w IT, ale nawet gdy pracowałeś w dhostingu jak twierdzisz, świat znał pewne standardy - przywracanie haseł działa wszędzie tak samo i jest to podstawa w korzystaniu z internetu.

     

    1 godzinę temu, root87 napisał:

    Co do ,,prawdziwego" konta, każdy ma takowe, a zauważyłeś jedynie moje :) 

     

    Otóż NIE. Nie zezwalamy na multikonta, nigdy, przenigdy, nigdzie - to miejsce jest wolne od tego typu "zagrywek" a takie działanie jest zwyczajnie bez sensu i jak  widać, jest to przez nas respektowane.

     

    1 godzinę temu, root87 napisał:

    Nie bulwersuję się, tym bardziej nie pouczam, nie czuje się do tego kompetentny - wyrażam swoje zdanie, a czy nie taka jest idea forum, właśnie żeby dyskutować, nawet jak ma się na niektóre tematy odmiennie zdanie?

     

    Wolność słowa jest nam dana i zagwarantowana - cieszmy się i korzystajmy z niej, ale mądrze. Każdy z nas reprezentuje tylko a może i aż siebie.

     

    1 godzinę temu, root87 napisał:

    Czy gdybym poleciał od razu z całą mocą jak do du*y jest dhosting to dostałbym propsy? 

     

    Czy oglądając walkę patologii MMA, nie masz wrażenia że świat poszedł w złym kierunku? Widzisz, jeżeli przeżyłeś troszkę w życiu, wiedziałbyś w jaki sposób działa świat i nie zadawałbyś bezsensownych pytań. Dyskusja jest na temat i rządzi się konkretnymi prawami - powinieneś to wiedzieć.

     

    1 godzinę temu, root87 napisał:

    Pewnie, że możesz zbanować każde konto, jesteś adminem.

    NIE. Rootnode to miejsce do wolnej dyskusji na dany temat. Dyskusja potrafi być niekiedy mocną krytyką poirytowanych klientów, ale nie jest to flameboard. Potrafimy celnie i boleśnie obnażyć prawdę, ale nie stosujemy zamordyzmu czy cenzury.

     

    1 godzinę temu, root87 napisał:

    Podkreśliłem między słowami, że moja wypowiedź jest tak samo wiarygodna jak każdego nowego konta, a z drugiej strony każde konto było kiedyś nowe. 

     

    Zabawa słowem nie jest proporcjonalna do ich wartości.

     

    1 godzinę temu, root87 napisał:

    Napisałem do GrochowskiNinja, powiedział, że udzielał porad, ale nikt nie słuchał - jeśli tak to przykre, jeśli jest userem to ma prawo do rozgoryczenia. 

     

    Sam doceniam kolegę @GrochowskiNinja za humorystyczną formę zaraportowania kolejnej awarii DHosting - w dzisiejszych czasach niepewności i konfliktów, każdemu przyda się odrobina uśmiechu ;) 
     

    1 godzinę temu, root87 napisał:

    Każdy człowiek ma prawo do własnej opinii, każdy może wbić szpileczkę, każdy może odbić piłeczkę. Każdy ma prawo być sarkastyczny. 

    1 godzinę temu, root87 napisał:

    Peace i dobrego dnia :) 

    Dokładnie TAK.

    Pozdrawiam i również miłego!
    o/

    • Lubię 1
    • Super! 1
  10. 10 minut temu, Kapitan_Bomba napisał:

    Centos 7. Dałem:

    ale też nie pomogło...

    Być nie może. Sam miałem ostatnio ten problem i dodawałem tą konfigurację - "u mnie działa", więc zapomniałem gdzie i jak to ustawiłem, ale kurcze tylko te dyrektywy za to odpowiadają. Sprawdź proszę raz jeszcze i ewentualnie daj w custom ten ssl.conf od Dovecot'a zanim przebudujesz config.

     

    16 minut temu, Spoofy napisał:

    Kurcze, przepraszam bo z biegu odpisuję. To jest jakieś RH-based distro czy Debian?

    To nie jest jakiś nowszy Debian?

    Edit: widzę że podałeś - CentOS 7. Kurcze, na szybko teraz nie pomogę bo nie widzę co jeszcze zmieniałem a te dyrektywy za to odpowiadają. Odezwij się wieczorem na PW to możemy porównać configi. Wiem że też na forum DA o tym pisali i tam była solucja z której sam skorzystałem.

  11. Przepraszam, za dużo systemów :D W jednych RH like zmieniam https://access.redhat.com/articles/3642912 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/security_considerations-in-adopting-rhel-8 ale w DA ogarnąłem to inaczej.

    Dla DA sprawdź jednak exim'a:
    ```
    /etc/exim.variables.conf.custom
    tls_require_ciphers=ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:
    ```

  12. 13 minut temu, Kapitan_Bomba napisał:

    Czy udało się komuś rozwiązać problem z w/w błędem? Wiem, że dotyczy on chyba wszystkich hostingów opartych o panel DA, ale z tego co widzę to są też wątki np. z pleska. Błąd występuje głównie dla serwerów mailgun, ale nie tylko.

    Uprzedzając, dodanie do CB:

    nie pomaga.


    Tak. To jest globalne ustawienie obsługiwanych cipherów i poszczególne dla usługi. Zerknij na: `/etc/dovecot/conf/ssl.conf` (w DA to dovecot odpowiada za autentykację dla Exima) - dyrektywa `ssl_min_protocol`.

  13. 5 godzin temu, itomek napisał:

    Obłęd. Tak postrzegam Twoją wypowiedź i raport, który przytaczasz.

     

    4 minuty temu, itomek napisał:

    Jak więc poprawnie czytać raport CERT? Na pewno nie tak, jak pokazał to Spoofy.

    Tak więc, ten "obłędny" raport na stronie 94 ukazuje inne zagadnienie ;) Phising != malware umożliwiający jego rozsiewanie. Wiesz, inne firmy tak hucznie nie reklamują i nie opowiadają o nieomylności i niezawodności swoich rozwiązań, w taki sposób.
     

    14 godzin temu, itomek napisał:

    Bazy są oczywiście non-stop aktualizowane, a systemy zatrzymują dziennie setki tysięcy ataków (link do ciekawego opracowania: https://www.nazwa.pl/blog/700000-zatrzymanych-atakow-czyli-typowy-dzien-dla-intrusion-prevention-system-w-nazwapl) .

    5 minut temu, itomek napisał:

    że dowolną informację statystyczną można zaprezentować tak, jak interpretatorowi jest to wygodne

    10 godzin temu, Spoofy napisał:

    każdy może się pochwalić ostatnimi próbami blokad wszystkich takich ataków i zliczać, bawić się statystyką, pokazywać kibany, grafany, splunki, sightline'y, fortiosdashboard'y etc. - to nie zmienia faktu, że tych żądań nie zablokował żaden WAF i IPS stosowany przez nazwa.pl, a zdecydowanie powinien.

     

    Nie rozmywajmy się na jakieś wyszukane porównania z innych dziedzin, po prostu skończmy na tym co zostało już napisane. Pewnego piątku powiedziałeś moim zdaniem @itomekpewną techniczną głupotę, ja czując się urażony i "ztriggerowany" się do niej przyczepiłem, uzyskałem informacje na ten temat i tyle. Przepraszam jeżeli Cię uraziłem, dlatego proponuję, proszę - zakończmy tą dyskusję.

  14. 20 minut temu, itomek napisał:

    Podeślij mi linki do ofert hostingów współdzielonych, które korzystają z takich rozwiązań, które pozwalają gwarantować określone zasoby.

    Z google też nie potrafisz korzystać, prawda? Tak leniwy jesteś czy serio odrealniony?

    Proszę, pierwsze z brzegu przykłady:

    https://www.ovhcloud.com/pl/web-hosting/
    https://www.cba.pl/pl/oferta/hosting
    https://progreso.pl/pl/hosting-hybrydowy
     

    21 minut temu, itomek napisał:

    Własny cloud + dane na zewnętrznych macierzach + osobne klastry serwerów do poszczególnych usług + konteneryzacja + własna sieć CDN z wieloma węzłami w Polsce itd.

    Cóż, nie będę mówić o tym że moja własna firma z powodzeniem wdraża takie rozwiązania, no ale serio - wyniesienie usług na osobne node'y w ramach dzielonych klastrów to nie jest rocket science, tym bardziej na podstawie już istniejących rozwiązań. Apropos "CDN'ów" w Polsce, to już było powiedziane dużo na tym forum, jakie realnie ma to znaczenie. Do stackpath'a czy CloudFlare'a to troszkę też wam daleko, a nawet tego typu darmowe usługi dają realne korzyści np. pod kątem SEO czy szybkiego resolvingu za granicą, przy analityce etc.

     

    24 minuty temu, itomek napisał:

    może korzystanie z CloudLinuxa dla Ciebie jest cloudem?

    A czemu nie, skoro dałoby się to ładnie poukładać i spiąć na podstawie gotowych rozwiązań, równie wydajnie?  ;)

     

    25 minut temu, itomek napisał:

    Ciekawe, ile czasu będzie trwało zmigrowanie jednego klienta z takiego serwera, który ma 1 TB danych na inny serwer, w przypadku gdy wystąpi problem z noisy neighbour. U nas ułamki sekund. A w firmie którą wskażesz?


    Wiesz, większość stosuje tylko dyski NVMe a na nich zewnętrzne macierze ZoL, czy object storage dla konkretnych wymogów - to też jest raczej standard a nie nowość na rynku ;) no ale przy centralnym storage'u raczej przenoszenie ustawień kontenera miedzy node'ami, trwa niewiele więcej niż samo nawiązanie połączenia. Serio mam pokazywać przykłady? 
    Jeżeli klient ma potrzebę gwarancji zasobów - może zakupić usługę gwarantującą ich przydział. Jeżeli klient chce usługi HA z centralnym storage'em rozliczanym per GB, też jest to bajecznie proste, tanie i przystępne, ponieważ to technologia wyznacza standard ;)

     

    30 minut temu, itomek napisał:

    Zarzucasz mi brak przedstawiania know-how firmy, a sam również piszesz ogólnie. Można to, można tamto. Doskonale wiem, że można, pytanie kto to robi i jakim kosztem. Na razie w PL widzę dominację cPanela i DirectAdmina, a rozliczenia przez WHMCS. Można jeździć Fiatem Cinquecento i można jeździć Rolls-Roycem Phantom Extended Series II. Jeden i drugi przy nieodpowiednim prowadzeniu będzie miał wypadek. Pytanie, kto co oferuje i czy faktycznie wywiązuje się z tego. W nazwa.pl jest SLA, które określa możliwości usługi, a użytkownik może ich wymagać. Zaraz napiszesz pewnie, że SLA jest niepotrzebne. Tam możemy ciągnąć tę dyskusję w nieskończoność.

    Cóż, tak mocno nie możesz doszukać się prostych faktów, informacji czy np. mojego CV to nic nie poradzę. To że dominują gotowce, wynikać może z tego że warto z nich korzystać, skoro robią coś dobrze od wielu lat i są znane, hm? Może zamiast skupiać się na aspektach kompletnie nieistotnych, sam wolę skorzystać z takiego gotowca i skupić się na konkretnych wymogach a nie nad developmentem całości ;) 

    Znów mocno wykraczamy poza technikalia, tym razem wkraczając w sferę biznesową. Tutaj kalkulacje są również bajecznie proste - ile developmentu, zmian i rozwoju widać w takich projektach z takimi zasobami a jakimiś internalowymi customami, hm? Uważasz że przykładowo nazwa.pl byłaby w stanie developmentem w jakikolwiek sposób dorównać takiemu projektowi, czy może częściej jest to raczej doganianie standardów kreowanych przez te gotowce? Trywialnych przykładów nie trzeba szukać daleko - obsługa certyfikatów LET w panelu nazwa.pl vs jakikolwiek "gotowiec".

     

    34 minuty temu, itomek napisał:

    Tonący brzytwy się chwyta. Odwołam się znów do samochodów. Badanie carVertical z 2021 roku przedstawia Lexusa jako najczęściej uszkadzany samochód w Europie. Może powinniśmy w Polsce zrobić dodatkowe badania techniczne dla Lexusów, skoro są takie niebezpieczne, albo zakazać ich rejestracji? Otóż to ludzie, którzy nieumiejętnie z nich korzystają, robią problem, a nie rozwiązania, które dostarcza producent. A może Lexus powinien przestać sprzedawać swoje samochody w Europie, bo Europejczycy mają statystycznie największą szansę w nich zginąć? Obłęd. Tak postrzegam Twoją wypowiedź i raport, który przytaczasz.

    Obłędem nazywasz i traktujesz oficjalny, cykliczny raport waszego partnera, powtarzający jak mantrę podstawy bezpieczeństwa internetowego? Sugerujesz że nazwa.pl jest idealnym hostingiem do trzymania takich webshelli i złośliwych skryptów, tym samym promujesz i abrobujesz tego typu występki? Cóż, na samochodach się nie znam, to jest forum o tematyce hostingowej.

  15. 2 godziny temu, itomek napisał:

    Nie znalazłem wielu firm oferujący hosting współdzielony, które stosowałyby LXC, a przynajmniej nikt nic o tym nie pisze. Gdzie jest cPanel, DirectAdmin, brak jest LXC. A tak wygląda zdecydowana większość hostingów.

     

    Cóż, szukasz widocznie nie tam gdzie potrzeba. Informacji na temat rynku jest dość sporo w internecie.

     

    3 godziny temu, itomek napisał:

    Zapewnienie zgodnie z umową to gwarancja dostępności zasobów. Gwarantujemy dostępność zasobów zgodnie ze SLA. Bardzo łatwo to sprawdzisz, uruchamiając jednocześnie kilka procesów na CloudHostingu vs inne hostingi, gdzie tej gwarancji nie ma.

     

    Powtórzę się - do "gwarancji zasobów" istnieją odpowiednie rozwiązania techniczne, w ramach wymaganych potrzeb.
     

    3 godziny temu, itomek napisał:

    U nas osobne klastry odpowiadają za WWW, za FTP, za SSH, za pocztę e-mail, za bazy danych. To spore wyzwanie, które jest możliwe dzięki technologii cloud. Dane są utrzymywane zewnętrznie, procesy startują w kontenerach, co umożliwia ich natychmiastową migracje zgodnie z decyzjami loadbalancera. Nie wiem, jakie jeszcze hostingi masz na myśli, ale jeżeli ktoś tak faktycznie świadczy swoje usługi, to jego klienci są na pewno bardzo zadowoleni. Nasi są. 

     

    Nie rozumiem - dokładnie w taki sam sposób mogą działać gotowe panele, czy usługi ogólnodostępne - zatem "cloud" jest łatwo osiągalny w dzisiejszych czasach, czego dowodzą przykłady tutaj przytaczane. LB ruchu czy efektywne skalowanie i balansowanie jest dość łatwe. Różne hostingi wykorzystują technologię LXC w taki czy inny sposób - niewiedza rynku na temat konkurencji czy też standardów - nieistotne.

     

    3 godziny temu, itomek napisał:

    Jeżeli można coś zrobić dla ekologii, to trzeba to robić. Nawet niewielkie oszczędności CO2 są ważne. I może jest to odpowiedni moment, aby też o tym powiedzieć. Nasze rozwiązania CloudHosting, dzięki dynamicznemu dzieleniu zasobów i rozkładaniu ich wg potrzeb, pozwalają na nowe podejście do sterowania serwerami działającymi w klastrze. 

     

    Nie rozumiem jak dopychanie na wyrost totalnie zbędnych, powielanych procesów w przykładzie dla np. typowej aplikacji webowej PHP, może pomóc w ekologii. Samo zużycie energii przy "gwarancji zasobów" raczej nie jest jej oszczędzaniem. "Dynamicznie przydzielane zasoby" a "ich gwarancja" wśród usług hostingowych czy też web hostingowych jest już dawno zdefiniowana, zaś raz jeszcze powtarzam - technologie konteneryzacji i separacji zostały stworzone do współdzielenia zasobów i ewentualnego ograniczania ich zużycia a nie gwarantowania, co sam przyznajesz.

     

    3 godziny temu, itomek napisał:

    Separacja nie jest niczym złym. Wręcz przeciwnie, pozwala na zachowanie wyższego standardu bezpieczeństwa pojedynczej usługi. VPSy to optymalne rozwiązania, co do tego nie ma wątpliwości, ale nie każdy ma szansę i możliwości je obsługiwać. Do tego potrzebny jest admin, a na CloudHostingu zarządzanie realizowane jest w sposób przyjazny dla użytkownika. CloudHosting ma zatem miejsce gdzieś między hostingiem a VPSem. 

     

    Nie do każdego VPS'a potrzebny jest "admin" - wystarczy odpowiednie rozwiązanie do zarządzania środowiskiem systemowym, automatyzacja. Czasami admin może być potrzebny, lecz znów - jest to oczywiście proporcjonalne do wymagań.

     

    3 godziny temu, itomek napisał:

    Usługa, którą oferujemy w nazwa.pl, powstała w oparciu o rozwiązania, o których tutaj piszemy, nie jest powszechnie spotykana na rynku. Oczywiście, coś takiego jak konteneryzacja jest znane średnio zaawansowanemu administratorowi Linuxa, ale potrzeba jest to tak poustawiać i zaplanować, aby wszystko działało dla wielu setek tysięcy hostingów. Możemy mówić o stosowanych technologiach, bo sam jesteś w stanie to sprawdzić. Nie napiszemy jednak, jak to zostało zrobione, że "działa", bo to już wchodzenie w know-how, które kosztowało nas wiele pracy i testów. Nie jesteśmy AWS, bo dostarczamy rozwiązania dla zwykłych użytkowników, których nie interesuje wiele kwestii technicznych, ale którzy chcą mieć usługę zawsze dostępną, zawsze działającą szybko i wydajnie i z przyjaznym (prostym) interfejsem. Ktoś, kto potrzebuje czegoś więcej w naszej ofercie znajdzie VPSy oparte o KVM. To wszystko jednak stanowi osobne oferty skierowane do zupełnie innych grup odbiorców.

     

    Wprowadzanie konkretnej usługi a marketingowe kluczenie na temat jej specyfikacji technicznej to dwie różne rzeczy. Cóż, może "średnio zaawansowany administrator" potrafi poustawiać sobie proste środowisko, lecz ogólnie każda konteneryzacja służy właśnie do prostego skalowania współdzielonymi zasobami i relatywnie łatwo za pomocą wspomnianych rozwiązań stworzyć całkiem przyzwoitą infrastrukturę. Niestety, większość publikacji czy dyskusji z Tobą, kończy się zakrywaniem się  "know-how" firmy. Otóż nie, dopytywanie o szczegóły techniczne dotyczące realizacji marketingowych tez w przedstawianej ofercie jest obowiązkiem. Po raz wtóry wyszło szydło z worka, ponieważ technicznie nie jesteś w stanie udowodnić takiego działania, zaś przykłady stosowania takich czy innych rozwiązań z pogranicza "konteneryzacji LXC" dobitnie to ukazują.

     

    3 godziny temu, itomek napisał:

    Zacznę od tego, że wszystkie zgłoszenia dot. phishingu realizowane są przez nas natychmiast po ich otrzymaniu lub samodzielnym wykryciu. IPS i WAF działają na wzorce powtarzalne, a ich skuteczność na indywidualne schematy zależy od wielu czynników. Bazy są oczywiście non-stop aktualizowane, a systemy zatrzymują dziennie setki tysięcy ataków (link do ciekawego opracowania: https://www.nazwa.pl/blog/700000-zatrzymanych-atakow-czyli-typowy-dzien-dla-intrusion-prevention-system-w-nazwapl) . W przypadku takich firm jak nasza, działa efekt skali. Musisz mieć na uwadze to, ze utrzymujemy kilkaset tysięcy hostingów, nie tylko dla domen, ale też dla subdomen. Nie każdy ma WordPress'a, którego przy informacji o jakimś CVE jesteśmy w stanie w kilka chwil "załatać". Nawet nie wyobrażasz sobie, co można wgrać na hosting ;) 

     

    54 minuty temu, itomek napisał:

    Nie mamy pewności, czy właściciel usługi sam nie umieścił tego skryptu, chcąc go w jakimś celu wykorzystać. Taki webshell na nic kompletnie nie pozwala, poza manipulowaniem zawartością w ramach tego konkretnego konta, gdzie jest umieszczony czy uzyskaniem dostępu do zawartości, która i tak jest dostępna w każdy inny sposób dla właściciela hostingu. Tak czy inaczej, wyjaśnię z Działem Obsługi Klienta ten temat i poproszę, aby skontaktowali się z właścicielem serwera i ustalili, czy on sam chce ten skrypt utrzymywać i czy go samodzielnie wgrywał.


    Po pierwsze - nie wszystkie WAF'y czy IPS'y działają na podstawie sygnatur - zdecydowana większość produktów ogólnodostępnych, w tym urządzeń, które również stosujecie, lecz nie wszystkie. Po drugie, rozumiem że przykładowo przy modsec standardowe reguły OWASP blokują dostęp do `/etc/passwd` ale już nie do innych plików, lecz własnie inne potencjalnie poufne informacje, w tym skrzętnie ukrywane przez Ciebie (tym razem realne) "know-how" firmy, ukazujące pełną konfigurację środowiska systemowego i usług, powinny być blokowane przez reguły WAF. Przeglądanie zawartości wszystkich plików lub danych, newralgicznych ścieżek systemowych jest banalnie proste do zablokowania i przy obecnych standardach, nawet szablony konfiguracyjne, dystrybuowane w popularnych systemach, posiadają takie blokady. Po trzecie - ukazywanie marketingowej a nie technicznej statystyki dotyczącej porównania z sygnaturami jest dość słabe - każdy może się pochwalić ostatnimi próbami blokad wszystkich takich ataków i zliczać, bawić się statystyką, pokazywać kibany, grafany, splunki, sightline'y, fortiosdashboard'y etc. - to nie zmienia faktu, że tych żądań nie zablokował żaden WAF i IPS stosowany przez nazwa.pl, a zdecydowanie powinien. Dlaczego? Otóż dlatego że: po czwarte - nie bez powodu przywołałem kwestię Phishingu i jego rozpowszechniania w ostatnim raporcie CERT, gdyż taki webshell idealnie się do tego nadaje. Nawet "średnio zaawansowany administrator", ba nawet junior powinien wiedzieć o tak poważnym zagrożeniu jakie niesie za sobą taki webshell. Widzisz, każde z szumnie prezentowanych przez Ciebie rozwiązań nazwa.pl kompletnie zawiodło, dlatego że najwyraźniej nie stosujecie podstawowej detekcji potencjalnego malware'u i być może dlatego w oficjalnych statystykach raportu CERT wypadacie tak słabo. Większość, nawet gotowych rozwiązań, np. skanujących w czasie rzeczywistym tego typu plik w pierwszej kolejności umieściłoby taki skrypt w kwarantannie o potencjalnym zagrożeniu, zaś ewentualny false positive przy dobrej praktyce "security-wise", musiałby być zweryfikowany przez właściciela. Nie będę dalej przedstawiał podstaw dotyczących security, ale tutaj naprawdę widać po raz wtóry realne (nie)działanie zabezpieczeń stosowanych w usługach nazwa.pl.

    Proszę, zajmijcie się tym tematem jak najszybciej, ponieważ przyczyniacie się tym samym do degradacji poziomu bezpieczeństwa polskiej przestrzeni internetowej. Nie będę tego dłużej tłumaczył, proszę o kontakt z CERT, jeżeli czegoś nie rozumiesz.

    Z mojej strony zakończę dyskusję, gdyż słowne przekomarzanie się mnie nie interesuje a jedynie suche, techniczne fakty, których niestety już tutaj brak, zaś Twoje potwierdzenie w tym zakresie mnie satysfakcjonuje. Oliwa sprawiedliwa, jak to powiadają.

    • Lubię 1
  16. 6 godzin temu, itomek napisał:

    Eh.. Jak zwykle dużo się dzieje w odniesieniu do rozwoju oferty nazwa.pl, zwyczajnie zapomniałem podlinkować. Link został podany https://www.nazwa.pl/blog/konteneryzacja-na-cloudhosting-nazwapl

     


    Cóż, dobrze że w końcu wzięliście się za ogarnianie technologii LXC, którą wiele firm w tym ja stosuję od ładnych paru lat produkcyjnie. Niestety, wszystko wskazuje na to że dalej znów perfidnie kluczycie lub nie rozumiecie w jaki sposób ona działa, stąd dyskusja.
     

    6 godzin temu, itomek napisał:

    Fakt, że na przykładach można łatwo wytłumaczyć pewne kwestie. Blog to miejsce, gdzie trafiają wszyscy, często mniej techniczni użytkownicy. Porównanie, które wpływa na wyobraźnię jest najlepsze 🙂

     


    Sam przecież mówiłeś, że w publikacji będą zawarte wszystkie informacje, a jedyne czego się doszukałem to twierdzenie "gwarantowania zasobów przez 99.9% czasu".

     

    6 godzin temu, itomek napisał:

    Gwarantowane zasoby nie są zasobami rezerwowanymi. Gwarancja dotyczy 99.9% czasu opisanego w SLA i jest realizowana poprzez przenoszenie danego kontenera na fizyczny serwer z największą ilością zasobów RAM i CPU.

    Dziękuję bardzo, tak więc to jest clou. Nie ma technicznej gwarancji tych zasobów, poza zapewnieniem. Takie "gwarancje" można sobie wpisać między bajki, bo od "gwarantowania zasobów" są inne, bardziej odpowiednie ku temu technologie, a LXC do tego nie służy, o czym niżej. 

     

    6 godzin temu, itomek napisał:

    Klastry posiadają na tyle dużo fizycznych serwerów, aby zapewnić nieprzerwanie dostępne zasoby dla wszystkich usług. Oczywiście, w razie potrzeby można dołączać do klastra nowe serwery dedykowane.

    Zatem taki klaster w praktyce niczym się nie różni od sterty spiętych ze sobą serwerów i przerzucania kont między nimi, co robi każdy kto posiada jakikolwiek resource plan . Czy w trakcie przenoszenia kontenera na inny node jest on niedostępny powodując niedostępność usługi?

     

    6 godzin temu, itomek napisał:

    Analogicznie w przypadku mniejszego ruchu, dla zapewnienia niższego zużycia energii, a przez to ochrony środowiska, niepotrzebne serwery są czasowo odłączane. 

     

     

    Cytat

    Po uruchomieniu nowych Data Center, dostępna moc infrastruktury spółki wzrośnie do 140 MW.


    Czyżby zmiana polityki? Ostatnio nazwa.pl cały czas "zwiększała MW", a teraz nagle tacy "zieloni"? :D Takie twierdzenia też wydają się śmieszne, dla każdego kto widział datacenter ATM, także absolutnie "zieloni" nie jesteście i raczej długo nie będziecie;)

     

    6 godzin temu, itomek napisał:

    Jeżeli chodzi o konteneryzację, jaka jest używana w Cloud Linux (LVE) + LiteSpeed, to trzeba zauważyć, że jest ona wykonywana dopiero dla procesów potomnych serwera WWW. Skutkuje to tym. że potencjalny błąd bezpieczeństwa w głównym procesie serwera WWW powodowałby naruszenie bezpieczeństwa dla wszystkich usług zlokalizowanych na określonym serwerze. W kontenerach uruchamiane są dopiero podprocesy serwera WWW. W przypadku technologii używanej przez nazwa.pl, najpierw tworzony jest kontener LXC, a dopiero w nim, wewnątrz namespace'ów Linuxowych, uruchamiane są wszystkie usługi. Gdyby porównać obydwie technologie wirtualizacji, to LiteSpeed musiałby być uruchamiany w całości dla każdego klienta hostingowego z osobna.

    Błąd - w LVE można uruchomić dosłownie każdy proces w ramach jego limitów. Oczywiście najczęściej LVE nie tyczy się głównego serwera z oczywistych względów - zasoby dla niego powinny być zawsze dostępne ;) Uruchamianie całego serwera www wewnątrz kontenera  jest kompletnym marnotrawieniem zasobów - czemu potencjalny klient ma płacić za uruchomiony serwer www Apache, skoro interesuje go procesowanie strony a nie kwestie obsługi sieciowej, hm? Idąc dalej, setup tego typu niczym nie różni się od osobnego serwera VPS w skalowalnym środowisku. Serwery VPS wybierane z uwagi na konkretne potrzeby, dopóki użytkownik ich nie ma to nie widzę absolutnie żadnego sensu, dlaczego klient miałby płacić za zużycie zasobów przez serwer www w ramach własnych zasobów.

     

    6 godzin temu, itomek napisał:

    Namespaces w Linuxie zostały wymyślone po to, aby zapewnić dla wirtualnych środowisk wydzieloną przestrzeń w jądrze, odseparowaną od przestrzeni dla procesów w systemie i innych tego typu kontenerów. Uruchamianie procesu potomnego serwera WWW z Parent PID głównego serwera webowego zapewnia komunikację pomiędzy procesami, ale stanowi również połączenie, które zaprzecza idei konteneryzacji, gdzie wewnątrz kontenera tworzony jest PID 1, od którego dopiero tworzone są procesy potomne systemu i wszystkie procesy użytkowników. 

    Init PID 1 w kontenerze jest zły? Z założenia są to odseparowane środowiska i tak działa to w każdej innej metodzie konteneryzacji, w tym we wspomnianym tutaj k8s. Niestety, technologia konteneryzacji powstała właśnie po to, aby współdzielić zasoby, a Ty dalej usilnie próbujesz twierdzić że "99.9%" i przerzucanie między serwerami jest "gwarancją zasobów". No nie, nazwa.pl to nie AWS a takie twierdzenia ponownie ukazują tylko marketingowy bullshit a nie realne zrozumienie i wytłumaczenie stosowanej technologii.

     

    W dniu 9.05.2022 o 20:36, Spoofy napisał:

    Szerzenie wadliwych, publicznie dostępnych zasobów, mogących stanowić zagrożenie, stoi w naturalnym przeciwieństwie do mojego postępowania, zatem link kierujący do tych zasobów zostaje usunięty z publikacji.

     

    6 godzin temu, itomek napisał:

    naruszenie bezpieczeństwa dla wszystkich usług zlokalizowanych na określonym serwerze.

    Proszę, nie mów mów już o "bezpieczeństwie", bo kompromitacja pod tym względem tutaj osiągnęła już pułap nieosiągalny dla innych firm z top100. Nie pytam nawet ile z głupiego szukania wyszłoby podobnych linków i gdzie jest nieistniejący jak widać WAF nazwa.pl.

    image.png.af62661a280d7675a7355e476734e0fc.png
    Ostatni oficjalny raport ukazuje, iż w Polsce nazwa.pl jest na drugim miejscu pod kątem kampanii Phisingowych, tak  więc w związku z tym przykładem pytam - czy ta biedna gmina i CERT zostały poinformowane o tym fakcie i czy nazwa.pl ma zamiar coś zrobić z podobnymi, rażącymi przykładami braku odpowiedniego podejścia do bezpieczeństwa?

    • Lubię 1
    • Super! 1
  17. 6 godzin temu, st220 napisał:

    Po raz kolejny widzę że branża hostingowa jest mocna w gębie a nie technologiach. Wytknięcie niewiedzy kończy się atakiem. Przytoczone linki nie wnoszą nic w dyskusje. Przykładowo kubernetes jak i lxc w nowszej wersjach jak ta w proxmox 7 korzysta z cgroups v2. W wielu aspektach branża hostingowa w Polsce zatrzymała się w połowie poprzedniej dekady.


    Wnoszą podstawową wiedzę odnośnie tego, jak działa ograniczanie zasobów za pomocą cgroups.
     

    6 godzin temu, st220 napisał:

    Nie będę się wysilać i próbować opisać jak działa kubernetes. Dorzucę tylko że nazwa napisała marketingową papkę na temat lxc u siebie:

    https://www.nazwa.pl/blog/konteneryzacja-na-cloudhosting-nazwapl

    Z której wynika że stworzyli właśnie coś na kształt kubernetesa, a poszczególne kontenery lxc wyglądają jak pody z paroma aplikacjami. Patrząc również na ich oferty pracy mocno szukają kogoś kto im to przepisze na nowszą technologie i również stąd może wynikać że ich systemy są przestarzałe.

    Widzisz, dobrze wiem do czego jest k8s i na pewno nie do hostingu aplikacji PHP w środowisku współdzielonym. Jeżeli stosujesz terminologię k8s, znaczy że albo nie do końca wiesz jak działa i z czego konkretnie korzysta k8s albo nie znasz wymogów środowisk tego typu, gdyż zwyczajnie k8s się do tego nie nadaje i to nie jest ten case. Raczej z doświadczenia stawiałbym coś na wzór https://docs.opennebula.io/6.2/open_cluster_deployment/lxc_node/index.html;)

    Szkoda @itomekże nie poinformowałeś o publikacji, tak jak deklarowałeś - niestety, nie obserwuję bloga nazwa.pl, także nie wiem kiedy i co publikujecie.


    Co do treści samej publikacji, to podobają mi się inspiracja moimi słowami apropos porównania do mieszkania, bloku czy domu usług tego typu ;) 

    Cytat

    Dzięki konteneryzacji zapewnione są także gwarantowane zasoby pamięci RAM i procesora.


    W publikacji brakuje technicznych szczegółów, odnośnie tego w jaki sposób jest to realizowane. Nie ma ani słowa o tym, w jaki sposób gwarancja CPU czy pamięci jest zapewniona, zatem raz jeszcze - w jaki sposób procesy uruchamiane w kontenerze mają zagwarantowane zasoby CPU czy pamięci? Czy przykładowo kontener LXC podczas startu alokuje całą gwarantowaną pamięć operacyjną i jest ona niedostępna dla innych kontenerów?

     

    "Jeżeli więc widzisz, że hosting oferuje oprogramowanie CPanel + LightSpeed, to możesz być pewny, że nie posiada on funkcjonalności konteneryzacji."
    Oj, kolejne kłamstwo się szykuje. Czym jest LVE jak nie właśnie metodą "konteneryzacji"?

    Przemyśl @itomekswoją odpowiedź, gdyż tutaj uderzasz w struny dość dużych graczy i ich technologii ;)

    • Lubię 1
  18. 14 minut temu, oui napisał:

    Dla mnie chmura to rozwiązanie :

    • Wysoce skalowane, mam na myśli że w danym regionie mogę odpalić od 1-2 VMek/kontenerów/funkcji do 100+, 1000+
      • Do tego duża część produktów jest sprzedawana w HA jako opcji (np. MySQL)
    • Posiada rozliczanie za użyte zasoby oraz/czy rozliczanie minutowe/godzinowe
    • Posiada API do zamawiania i zarządzania usługami oraz integracje z providerami takimi jak terraform czy pulumi
    • Rozbudowane opcje dostępu do poszczególnych zasobów (IAM)
    • Wysokie SLA na komponenty (VM, LB, Bazy danych itd)

    Czy któryś hosting spełnia te podpunkty? Czy istnieje jakiś hosting który serwuje obsługuje ruch np. w PHP z dwóch serwerów i potrafi się autoskalować? (nie mam na myśli CDNa).


    Możesz postawić cpanel na instancji openstack'a od biedy, ale dalej nijak ma się to do "cloud" + ciekaw jestem jakby wypadało to "wydajnościowo" :D

    Let's face it - mówię o tym od dłuższego czasu - zmienia się świat, zmieniają się technologie. Jeżeli masz jakiegoś WordPressa i potrzebujesz PHP to raczej nie jest to aplikacja do skalowania, tak jak w przypadku aplikacji, pisanych z myślą o tym co wymieniłeś ;) Na całe szczęście idzie cała fala SaaS'ów i Jamstack'owych rozwiązań, które troszkę namieszają w tym zakresie, ale dalej - dla zwykłego "shared hostingu www" nijak się to ma.

    W ogóle - w jaki sposób chciałbyś realizować dostęp IAM? :D No chyba tylko do bucket'ów w public_html :D

×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.