kkw

@Tom X, ale to nie ten przypadek. HitMe.pl zasadniczo nie oferuje backupu, więc jakakolwiek rozmowa o regulaminach jest poza tematem. Pkt 11 i 15 zacytowanego fragmentu regulaminu mówią wyraźnie: albo sobie backup zapewnisz sam, albo nie licz na hostingodawcę (może coś uda im się odratować, a może nie).

Taki zapis w regulaminie nadawałby do zgłoszenia do UOKIK, gdyby... gdyby nie to, że HitMe.pl w większości oferty wcale nie oferuje (nie zapewnia) backupu Czyli w razie np. padu macierzy to rzeczywiście klient ma problem.

Umiesz liczyć - licz na siebie. I miej... własny backup?

Dużo korpomowy, ale ten wtręt jest jednak nieudolną próbą przerzucenia własnego błędu na mnie. Support HitMe nie miał problemu, aby "ręcznie" wytransferować domenę za cenę ponad 50% wyższą niż konkurencja. W tym samym czasie problem miał skrypt na stronie HitMe. Tym bardziej wskazuje to na problem po stronie skryptu HitMe. Konkurencja nie miała problemu, aby od ręki, tj. bez pomocy supportu, wytransferować domenę. W tym samym czasie problem miał skrypt na stronie HitMe (po odpowiedzi supportu HitMe ponownie sprawdziłem wyniki na stronie HitMe, a potem poszukałem konkurencji). Nawet teraz na stronie HitMe nie można zarejestrować dowolnej domeny .pro (potwierdzenie na obrazku sprzed chwili), przez co ta sugestia brzmi tym bardziej niedorzecznie. Z cennika HitMe usunięto wpis dot. domen .pro (nie ma ich teraz w ofercie (dowód, że były)), co chyba potwierdza, że to strona HitMe nie potrafi(ła) tych domen obsłużyć, a nie że ja miałem problem z "lock", jak Pan sugeruje. Dorzucam dwa obrazki z oferty HitMe (z tej chwili oraz z 27 czerwca, wg archive.org).

Korzystam od kilku lat. Kilkukrotnie zmieniałem maszynę w ramach Server Auction. Lokalizacja zawsze w Niemczech. Nie narzekam na sieć, ani sprzęt, choć nie mam też dużego obciążenia. Z supportem nie było dotąd potrzeby się kontaktować. Z minusów: IPki Hetznera tu i ówdzie nie są mile widziane (np. bany lub captcha).

W sumie drobiazg, ale... Chciałem przenieść do hitme domenę .pro. Mam kod authinfo, wyłączyłem "lock". Panel hitme nie działa. Zwraca, że przeniesienie tej domeny jest "niedostępne". Szukam przyczyn tego stanu rzeczy i orientuje się, że strona www hitme w temacie tych domen nie współpracuje. Nie można nawet zarejestrować jakiejś absurdalnej domeny .pro (potwierdzenie w obrazkach), co dopiero dumać na transferem takowej. Piszę do supportu. Support odpisuje, że chcą kod authinfo. Ok Support odpisuje, że "Możemy ręcznie zlecić transfer..." (spoko ), ale proponują cenę 8 zł wyższą niż w cenniku (139 zł vs 147 zł brutto) Sprawdziłem na stronie hitme, po tej odpowiedzi: nadal stoi 139 zł brutto za rejestrację/odnowienie domeny .pro. Nie wiem za co mi policzono drożej niż w cenniku. Czy za "ręczną fatygę", czy za to, że hitme nie potrafi sobie cennika na stronie internetowej ogarnąć. Jako klient, który wskazuje palcem, że rejestracja/transfer pewnych domen W OGÓLE NIE DZIAŁA (przez co traci się potencjalnych klientów ), spodziewałem się nawet jakiegoś drobnego rabatu. Ot, gest, masz pan na piwo z dyskontu, a my sobie wewnętrznie ogarniemy temat domen .pro. Koniec końców, u innego rejestratora wytransferowałem domenę za cenę 50 zł niższą (97 zł vs 147 zł).

https://twitter.com/NeighborGeek/status/1526267594180857856 - są pierwsze doniesienia, że można zostać 'for non-commercial personal use' przy obecnej wersji G Suite. Edycja: Potwierdzam. Zostaję

Nadal mam nadzieję, że Google zaproponuje coś dla "rodzin", do 10 kont e-mail we własnej domenie. Czekam na "no-cost waitlist", ale czasu do 01.06 jest już dość niewiele.

fns2 już działa.

Z opisu awarii fns1 wnioskuję, ze admin trochę stracił zainteresowanie projektem. Takie życie.

Można jeszcze pozostać przy fns1, usunąć fns2 i dodać inne nsy, które będą zapasowe dla fns1 (wszelkie slave|secondary free dns).

Mi zupełnie nie działa 79.98.145.34, więc nawet nie mogę wyeksportować stref. A panel działa w sieci UPC, a nie działa w Orange i T-Mobile. Rozważam przeskok do freedns 1984hosting.com.

A czy w ogóle są takie plany?

@Poziomecki

Hej, Korzystam z Debiana 9.0 oraz Apache 2.4.25. Chciałbym włączyć HTTP/2, ale korzystam jednocześnie z mod_ruid2. Problem w tym, że mod_http2 nie jest kompatybilny z mpm_prefork, zaś mod_ruid2 jest kompatybilny tylko z mpm_prefork (mam tu na myśli mody mpm_*). Jak rozwiązać ten węzeł nie tracąc funkcjonalności mod_ruid2?