theqkash

Mógłbyś przytoczyć tą sprawę?

Tymczasem w Krakowie: https://biuroprasowe.nazwa.pl/46632-oswiadczenie-pozew

Pamiętaj że w tym momencie przestają też działać Twoje strony jeśli są gdzieś indziej na koncie niż w folderze głównym konta hostingowego, więc trzeba to robić jak nikt nie patrzy

Sądzę, że moment w którym uporacie się z cloudflare co trwa już dobre kilka lat, powinien też rozwiązać opisywane przeze mnie dolegliwości, bo jest to problem wynikający z identycznej niepojętej logiki Waszego panelu, o czym zresztą wspomniał też @mariaczi

Chyba nie do końca rozumiesz co piszesz. Opiszę Ci to na przykładzie. 1. Powiedzmy że mam domenę w pewnej firmie na N i hosting w tej samej firmie. 2. Zmieniam sobie DNSy dla tej domeny z firmy N na firmę dowolną inną. 3. Wiadomości mogą przychodzić i na stary i na nowy serwer, bo tak działa DNS co do czego chyba się zgadzamy, dlatego warto utworzyć nowe skrzynki na nowym serwerze, a migracji zawartości dokonać po pewnym czasie. W przypadku firmy N mogę się zalogować na skrzynkę przez webmail firmy N, mogę sobie też puścić imapcopy np. 20 godzin po zmianie DNSów i ani pół wiadomości mi nie zniknie, wszystko powinno dotrzeć na jeden lub drugi serwer, a po puszczeniu imapcopy znajdzie się na tym docelowym. Jak to natomiast wygląda w home.pl? 1. Mam domenę w home.pl i hosting w home.pl 2. Zmieniam DNSy w domenie z home.pl na DNS w innej firmie 3. Poczta przestaje momentalnie działać, wiadomości wysłane po zmianie DNS nie docierają nigdzie do czasu zakończenia propagacji, nie ma możliwości logowania się na skrzynki na starym serwerze, a domena zaczyna kierować na główny folder konta hostingowego zamiast na podfolder. Żeby zmigrować zawartość skrzynek z home.pl trzeba zmienić konfigurację skrzynek tak aby w ogóle można się było do nich jakkolwiek dostać i dopiero wtedy można zacząć rozmawiać o migracji czegokolwiek po zmianie DNSów. W tej perspektywie naprawdę uważasz, że przesadzam?

Można też przewozić meble samochodem osobowym. Pytanie tylko po co? Migracja/synchro poczty po wykonaniu zmiany DNSów jest z logicznego punktu widzenia pożądana, gdyż pozwala zebrać maile które mogły trafić w tzw. międzyczasie. Chociaż tak w sumie myślę - u Was i tak chyba nie trafiają, bo zmiana DNSów powoduje że żadne wiadomości nie docierają już do skrzynek na Waszych serwerach, co zresztą również jest warte napomknięcia.

Jeżeli posiadasz przypiętą domenę asdf.pl do konta w home i ta domena jest rónież wykupiona w home, chcesz migrację przeprowadzić w następującej kolejności: 1. Kopiujesz pliki/db, konfigurujesz wszystko na nowym serwerze 2. Zmieniasz DNSy 3. Robisz migrację skrzynek pocztowych to u Was się tego nie da zrobić, bo w momencie wykonania punktu 2, traci się możliwość logowania się na skrzynki pocztowe w przenoszonej domenie. U każdego innego operatora którego znam działa to tak, że pomimo odpięcia domeny od serwera nadal się można do skrzynek logować w taki sam sposób jak dotychczas. U Was natomiast aby dało się zmigrować zawartość takich skrzynek po zmianie DNSów, trzeba je albo przekonfigurować aby były przypięte do innej domeny dostępnej na koncie, albo ustawić je tak żeby te skrzynki były dostępne we wszystkich domenach i posługiwać się przy migracji adresami typu [email protected] Z tego samego zresztą powodu o ile mi dobrze wiadomo do dziś u Was nie da się podpiąć domen do cloudflare - odpięcie domeny od Waszych DNSów powoduje rozjechanie się wszystkich usług znajdujących się w tej domenie.

Miałem tego nie pisać, ale naprawdę od kilku tygodni to co przechodzę z home.pl (choć na szczęście osobiście nie jestem klientem tej firmy) przechodzi wszelkie granice i chciałbym ostrzec wszystkich, a przede wszystkim osoby, które będą miały nieprzyjemność wynosić klientów z tego przybytku. Dlatego przesyłam podsumowanie z kilku prac jakie wykonywałem w ostatnim czasie dla moich klientów, który mieli hosting w home. 1. Jeśli macie na tyle szczęscia że na Waszym koncie jest w ogóle dostęp do ssh, zapomnijcie o możliwości skopiowania czegokolwiek więcej niż max kilku gb przez np. rsync na serwer zewnętrzny, czy zarchiwizowania większej ilości plików dowolną metodą (da się max do 2-3GB rozmiaru archiwum) - nie powiedzie się to, połączenie zostanie zerwane, 2. FTP działa koszmarnie, listowanie/pobieranie plików przez FTP trwa wieki, a potrafi jeszcze przy okazji kilka razy zerwać połączenie (taki midnight commander wywala wówczas między innymi: Połączenie zerwane przez drugą stronę (104) ), 3. WebFTP można powiedzieć że nie działa, większość funkcji sobie nie radzi bo technicy-magicy z home.pl postanowili nie zwiększać limitów czasu oraz pamięci na wykonywanie operacji, stworzenie nawet kilkudziesięciu megowego archiwum jest czasem niewykonalne, zakończy się błędem (oczywiście serwerowym typu 500, pakowanie się rozpocznie ale nie zakończy), 4. Rozwiązania typu Duplicator, AIO Migration dla WordPressa są nieskuteczne, chyba że strona waży <500MB, w przeciwnym razie operacja wykonywania kopii albo się zawiesi albo zakończy błędem - bardzo małe szanse na powodzenie, 5. Kompletnie bezradny support na w/w problemy, 6. Z dodatkowych rzeczy które mnie drażnią - przy migracjach z home.pl występuje dodatkowe utrudnienie, zwłaszcza jeśli domena jest wykupiona również w home.pl - zmiana DNSów powoduje natychmiastowe zresetowanie wszelkich ustawień domeny, a zatem jeśli strona wskazuje na folder na koncie hostingowym, przestanie na niego wskazywać, a zacznie wskazywać na główny folder konta hostingowego. W momencie zmiany DNSów przestaje również występować możliwość zalogowania się do kont pocztowych w home.pl, trzeba sprytnie kombinować logując się przez inne domeny lub przez domenę techniczną konta, co z kolei wymaga często zmiany konfiguracji kont pocztowych. 7. I na koniec - nowy panel: niektóre funkcje nie są dostępne choć powinny być i nawet level 1 supportu sobie nie radzi z ich odnalezieniem lub uruchomieniem i każe pisać "zgłoszenie które przekaże do administratorów", bo "coś powinno być w panelu, a na tym koncie tego nie ma". Dodatkowo panel lubi sobie wypluć komunikat po angielsku w zupełnie losowym momencie (np. przy tworzeniu konta FTP) i błąd ten zwykle średnio ma się do aktualnej sytuacji i parametrów konta (np. wywalanie błędu tworzenia konta FTP z adnotacją o możliwości przekroczeniu ilości kont FTP, podczas gdy jest jeszcze spory zapas kont jakie można stworzyć). Pierwsza linia supportu oczywiście nie wie jak to rozwiązać i trzeba do administratora pisać, blabla. To że panel jest przy okazji nieczytelny to inna sprawa, ale to już może subiektywna opinia jest.... Generalnie migracja serwisów ważacych po kilka gigabajtów lub więcej zwykle sprowadza się do kilku podejść do kopiowania plików za pośrednictwem FTP, bo żadna inna bardziej wygodna metoda nie jest w stanie się wykonać w całości w sposób poprawny, o ile w ogóle inna metoda jest dostępna. Zwiększanie ilości jednoczesnych sesji skraca żywotność każdej z nich. Sytuacje tego typu nie mają miejsca przy migracji z żadnej innej firmy hostingowej, zwykle rsync sobie doskonale radzi, ale nie w home. Sytuacje opisane tutaj miałem na minimum kilku kontach na home.pl, zarówno w starej jak i nowej ich ofercie, anomalie zostały też potwierdzone przez innych użytkowników na naszym forumowym discordzie. Problemy zbliżone do opisanych tutaj nie występują przy transferach danych od innych usługodawców, zatem z całą stanowczością wykluczam jednostkowość opisanych tutaj sytuacji jak i sam fakt że problem może być po mojej stronie. Godzina wykonywania prac również nie ma żadnego znaczenia. Sorry @home_pl ale do Was też w tej sprawie pisałem i niestety mnie zbagatelizowaliście, a problem jest naprawdę miażdżąco nieprzyjemny. Fajnie że skierowaliście sprawę do weryfikacji przez administratorów, ale jeśli wiem że wcześniej inne osoby też to zgłaszały i ci administratorzy przez taki okres czasu nie zdążyli tej sprawy rozwiązać ani nawet sensownie zdiagnozować, to jeśli nie są to Wasze celowe zabiegi mające na celu utrudnić migrowanie od Was, to można odnieść wrażenie, że macie kompletnie nieporadnych administratorów.

Są systemy cache'ujące które generują wynikowy plik html dla każdej z podstron i serwują go klientowi za pomocą htaccess'a, co jest moim zdaniem najbardziej korzystną z punuktu widzenia wydajności opcją, choć oczywiście nie uniwersalną.

Jeśli masz aż takie rozbieżności w TTFB sprawdź jakie TTFB będziesz miał dla strony statycznej umieszczonej na tych serwerach, a potem dla jakiegoś prostego skryptu napisanego w php, pozwoli Ci to już pewne wnioski wyciągnąć - dowiesz się bowiem czy ewentualne wysokie ttfb wynika z obciążenia ogólnego serwera lub z obciążenia wynikającego tylko i wyłącznie z działania interpretera skryptów. Jeśli w obu przypadkach będziesz miał niewielkie czasy, podczas gdy wordpress będzie miał wysoki TTFB, rozważ w WordPressie instalację systemu cache'ującego który wygeneruje statyczne pliki z instalacji wordpressa i będzie je serwował dla odbiorców. CSS/JS się scala, a fonty i tak zwykle są brane z Google Fonts, który jak przypomnę jest zasobem zewnętrznym na którego wydajność masz niewielki wpływ. Nie znam chyba szanującego się polskiego hostingu (bo temat jest o hostingach) który miałby serwery we Francji. No i nadal nie rozumiem jak to się ma do TTFB o które było pytanie w temacie. Przeczytaj dokładnie i ze zrozumieniem to co napisałem, bo chyba gdzies się zagalopowałeś

O jakim relatywnym wzroście szybkości mówisz? Na moje oko zarówno CDN jak i DNS Anycast to rozwiązania wybitnie nadmiarowe dla 95~99% serwisów, w praktyce nie dające wiele przy realnym użyciu poza ewentualnymi warunkami testowymi. Mając małą stronę która na dzień dobry generuje się pół sekundy i posiadającą 50-100 elementów statycznych plus jakieś zewnętrzne rozwiązania typu Facebook, Google Analytics, Hotjar, Callpage, zatosowanie zarówno CDN da zysk szybkości w granicach błędu statystycznego (choć często to są skrypty asynchroniczne oczywiście, ale opóźnienie wynikające z tych skryptów często uwidacznia się w narzędziach analitycznych). Dlaczego sugerujesz, że zastosowanie CDNa do każdej strony poprawi cokolwiek i jest warte rozważania? Moim zdaniem CDNa warto wprowadzić tylko wtedy jeśli serwujesz mnóstwo elementów statycznych i to do szerokiego grona odbiorców, w przeciwnym razie jest to zbędna inwestycja. DNS Anycast już kompletnie nie ma sensu jeśli skupiasz się na odbiorcach z jednego kraju i w tym kraju stawiasz DNSa, we wszystkich innych przypadkach zysk jest jednak stosunkowo niewielki. To według Ciebie serweer wysyłający mase plików statycznych wykonujących do tego operacje dyskowe nie jest przez to dodatkowo obciążany ? Oczywiście, że jest obciążany, ale w większości przypadków obciążenie wynikające z samego przesyłanie plików statycznych dla przeciętnej strony firmowej jest w granicach błedu statystycznego Po to się stosuje scalanie tych plików w jeden plik i istnieją rozwiązania które robią to z automatu, nie trzeba tu CDNów, bo te i tak niewiele dadzą.

Dokładnie o to chodzi. Z ciekawostek, miałem ostatnio klienta, który nie miał żadnych nadmiarowych wtyczek, ale motyw z którego korzystał łączył się do serwera aktywacyjnego aby potwierdzić legalność użytkowania, a nie mógł tego zrobić bo prace były wykonywane na niezgłoszonej nigdzie domenie testowej. Dojście do tej informacji chwilę zajęło, w międzyczasie oczywiście "zrób coś z tym serwerem, bo mam ttfb po 3 sekundy" Po co się interesować CDNami na tym etapie? Wydaje mi się, że to znaczne wychodzenie "przed szereg", kompletnie zresztą niepotrzebne przy przeciętnej stronie i nie mające wiele wspólnego z TTFB na hostingu. TTFB zwykle rośnie przez działanie interpretera danego języka (lub przez całkowite obciążenie serwera), a nie przez obsługiwanie plików statycznych.

Rozumiem, że zdajesz sobie sprawę z faktu, że TTFB nie zależy wyłącznie od hostingu? Nie zrozum mnie źle - jest wiele firm które technicznie są w stanie zapewnić niskie TTFB, ale tylko wtedy, gdy sama strona też jest doskonale zoptymalizowana.

Możesz nie zlewać, natomiast nie sądzę abyś mógł jakkolwiek wpłynąć na zewnętrzne skrypty takie jak disqus. Nie sądzę również aby to miało jakiekolwiek znaczenie w tym konkretnym przypadku.

Tak jak wyżej napisałem

W praktyce nie powinno mieć to większego znaczenia - jest to głównie wskazówka. Sam mam przypadek strony z identycznym problemem, natomiast nie obrywa ona w żaden sposób w wynikach wyszukiwania.

Olej i zapomnij. To są wskazówki, tak samo jak w Pagespeed Insights. To czy są trafne i poprawne to inna sprawa.

Nie wiem komu poza Tobą robi róznicę i tak jak wspomniałem, jeśli zamierzasz bombardowaniem takimi dziwnymi pytaniami czepiać się słówek u innych osób to nie jest to tutaj mile widziane. Koniec offtopicu.

Cieszę się, że wreszcie zrozumiałeś, bo o tym temat był od początku i chyba wszyscy wiedzieli o co chodzi i do czego zmierza, nikt poza Tobą się nie czepiał o słówka zadając dziwne pytania, co w tym przypadku było całkowicie zbędne. Dziękuję, że podzieliłeś się swoją opinią.

... Przeczytaj ten temat od początku, bo widzę, że chyba zgubiłeś wątek już na samym początku, albo po prostu lubisz zadawać tak idiotyczne pytania i wyciągać jakieś dziwne wnioski. A potem się dziwisz, że ktoś Ci daje ostrzeżenie. Ale nakreślę Ci, żebyś znowu nie zadawał serii dziwnych pytań: Mowa jest o tym, że jest możliwa ucieczka z hrd bez ściągania wszystkich swoich klientów w panelu resellera hrd w celu przygotowania papierowego wniosku i uzupełnienia go o skany dokumentów aby wyciągnąć kody authinfo, bo w NASK na szczęście istnieje możliwość przeprowadzenia cesji elektronicznej dla domen (tzn. nie jest ona zablokowana) i HRD jeszcze tej możliwości nie zablokowało. Nikt nie napisał, że NASK nagle zaczął umożliwiać cesje itd. Dzięki cesji możesz elektronicznie domeny scedować na siebie jako resellera i jako reseller zbiorczo wysłać wniosek o kody authinfo. Gdyby to była domena innego kraju, gdzie krajowy rejestr nie zezwala na cesje elektroniczne, lub też jeśli dany rejestrator nie zezwoli na cesje elektroniczne - wówczas takiej możliwości by nie było i trzeba by było kombinować jak wyprowadzić domeny od tego rejestratora lub faktycznie prosić wszystkich klientów o wypełnienie wniosku po to żeby zaspokoić temat uzyskania kodów authinfo. Mam nadzieję, że temat wyczerpałem.

NASK umożliwia swoim partnerom prowadzenie cesji elektronicznych dla domen będących pod kuratelą NASKu, co w mojej ocenie zmierza do dokładnie takiego samego wniosku jak przedstawiła osoba która wysunęła informacje na temat cesji..

Niektóre końcówki nie mają możliwości przeprowadzenia cesji innej niż papierowa, dlatego tak - jest to ważna informacja, że NASK umożliwił taką operację dla domen z końcówką .pl. Skoro wiedziałeś że NASK domen nie rejestruje to forma w jakiej zadawałeś pytania aż sama prosiła się o ostrzeżenie. A ja po raz kolejny przypominam Ci że to nie jest temat do prowadzenia dyskusji na temat Twojego ostrzeżenia.

To nie jest tez temat do ciągnięcia tej dyskusji. Jeśli masz jakieś pytania, skontaktuj się z moderatorem który Ci nadał to ostrzeżenie. NASK od pewnego czasu nie umożliwia bezpośredniej rejestracji domen więc jakby sam w sobie tego nie ma jak umożliwić.

Obstawiam, że nie chodzi o ten pojedynczy incydent. Jeśli chodzi o link - przynajmniej kilku polskich usługodawców świadczy taką funkcję, na pewno m.in. aftermarket.pl, ovh.

Twoja ciekawość bywa czasem męcząca - NASK umożliwia cesje elektroniczne, a mógłby tego nie robić i to jest coś co raczej każdy wyduka z wypowiedzi kolegi.