Piotr GRD

...mniejsze zło... Nie z punktu widzenia tego jednego przypadku / tej jednej osoby. Nie mam za złe, że reaguje. Mam za złe, jeśli idzie na łatwiznę. Od jesieni 2012 ESET poprzestaje na wykryciu eval(base64_decode bez analizowania co jest wewnątrz. Jeśli wspomniany Linuxpl działa podobnie (nie wiem, ale jeśli), to ja dziękuję. Mam za złe, że nie mogę wyrejestrować pojazdu, jeśli sam go rozbiorę na podwórku (znaczy mogę, ale po uiszczeniu wysokiej opłaty). Mam za złe, że w wielu przepisach i regułach uwzględnione jest 99% przypadków, a bardzo często nie zostawia się *żadnej* furtki dla tego jednego procenta, najczęściej dlatego, że byłoby to zbyt skomplikowane i/lub wiązałoby się z oddaniem ludziom większej swobody w działaniu i jednocześnie koniecznością większego zaufania wobec nich. Np. zaufania ze strony hostingu, że to użytkownik sam zadba o swoją Joomlę i Wordpressa, a nie zrzuci wszystko na hosting ograniczając tym samym to jakie pliki może wgrać a jakie nie. Np. zaufania ze strony organów państwowych, że to człowiek sam zadba o środowisko, a nie zrzuci konieczność dbania na organy państwowe, ograniczając tym samym swoją swobodę. 99% tego *niestety* potrzebuje, ale ten jeden procent bardzo często nie jest uwzględniany.

@ Archi Nawet jeśli nie istnieje uzasadnione i praktyczne zastosowanie takiej metody programowania, to nie oznacza, że każdorazowo z automatu należy to traktować jako wirusa. To tak jakby z góry zakładać, że jeśli mam ochotę własnoręcznie rozebrać stary samochód, to z całą pewnością wszystkie płyny spuszczę do rzeki, plastiki wyrzucę w lesie, a tylko blachy wywiozę na złom. No nie, akurat ja zadbałbym, aby rozebrać samochód w sposób należyty, ale nie mogę, bo nie jestem autoryzowaną stacją demontażu pojazdów. To, że większość robi coś nienależycie, nie oznacza, że nie istnieją lub nie będą istniały wyjątki, w których akurat dana metoda będzie miała uzasadnienie. A niestety lubimy wszystko i wszystkich danego rodzaju wrzucać do jednego worka i z góry zakładać coś, co *tylko* w 99% przypadków ma miejsce. Nie wiem jak teraz, bo już się tym nie bawię tak dużo jak kiedyś, ale przed kilku laty dość często widywałem taką formę "zabezpieczenia" linku autora w stopce w darmowych szablonach do Wordpressa. Początkujący użytkownicy Wordpressa dość często usuwali informacje o autorze darmowego szablonu ze stopki, więc aby tym początkującym nie znającym się na PHP utrudnić proceder, tak właśnie kodowali całą stopkę szablonu. Ja osobiście nie stosowałem tego nigdy, ale widywałem wielokrotnie. I w kodzie nic niewłaściwego czy chociażby tylko potencjalnie niebezpiecznego nie było. PS. Kiedyś rozwiercałem zamek w drzwiach mieszkania. I tak, to był lokal, do którego miałem prawo wejść i nim dysponować. Jeśli pojawiłaby się policja oczekiwałbym, że poprosiliby o dokumenty, aby sprawę wyjaśnić (innymi słowy: zajrzeliby co w tym ciągu base64 się znajduje). Jeśli z automatu rzuciliby mnie na glebę i założyli kajdanki (czyli z automatu skasowali cały plik, bo jest tam eval-base64) uznałbym to za niewłaściwe.

Też stawiam na Joomlę lub którąś wtyczkę do niej. A co do takiego zabezpieczania się poprzez usuwanie eval(base64... Jeśli to automat usuwający wszystko bez analizy faktycznego kodu zawartego wewnątrz, to mnie takie coś wkurza. Tak np. działa już od jesieni 2012 oprogramowanie antywirusowe od ESET. Kod: <?php eval(base64_decode('ZWNobyAnaGVsbywgd29ybGQnOw==')); ?> - czyli zwykłe "helo world" - jest uznawany za trojana. Jak dla mnie to zbyt daleko idące pójście na łatwiznę z ich strony. Zasygnalizowanie, że w takim kodzie może coś niebezpiecznego się kryć - tak - ale usuwanie z automatu wszystkiego zawierającego eval(base64_decode - nie. Jeśli na tym Linuxpl mój powyższy kod też nie zostałby dopuszczony - podziękowałbym za taką usługę, nadmierna "troskliwość", pójście na łatwiznę. Plus za skanowanie plików pod względem wirusów, że w ogóle to robią, ale podejrzewam, że idą na łatwiznę tak jak ESET (może nie).

Nie znam się na wykorzystaniu @media w CSS, ale z logicznego punktu widzenia: Jeśli używasz tej samej nazwy klasy dla dwóch elementów, to oczywiście będą takie same. (Chyba, że to tylko pomyłka tutaj przy prezentowaniu kodu, a w rzeczywistości używasz dwóch różnych nazw klasy.)

Wkradła się na końcu niewidzialna spacja - %E2%80%8B - większość odwiedzających to forum powinno chyba sobie z takim linkiem poradzić. Choć owszem, autor mógłby się pokusić o edycję. A poza tym to podawanie ceny 99 jest trochę nie w porządku, bo wygląda na to, że cena minimalna w aukcji jest ustawiona raczej na wyższym poziomie.

forpsi.pl ma chyba najtańsze *.eu, 21+VAT, czyli 25,83. Transfer dodatkowe 3,69, ale później w odnowieniach się zwraca na dłuższą metę. PS. Warto też chyba wspomnieć kto ma tańsze IDN, a kto wszystko w jednej cenie, czasem to się niektórym przydaje, żeby mając ges.pl nie przepłacać niepotrzebnie za dodatkową gęś.pl.

Odnośnie domen *.pl rejestrator to ReTop.pl Miłosz Gądziak dns.pl/porozumienie/partner/partner/176/pl/ Te same dane na stronie gnum.pl/kontakt Nie wiem jak w przypadku *.eu czy *.com i innych. AuthInfo dostępne automatycznie w panelu, tak jak tutaj na WHT użytkownik Gnum.pl wspominał w jakichś tematach. Ale nie wcześniej niż 6 dni po rejestracji/transferze i nie później niż 7 dni przed końcem okresu rozliczeniowego (czyli wzięte wymogi NASKu dla transferów plus 1 dzień).

Ja niedawno zacząłem przenosić *.pl-ki do gnum.pl (wcześniej korzystałem z forpsi.pl, tam mają chyba najtańsze *.eu jakby ktoś chciał). Póki co wszystko w porządku.

Nie ma to większego znaczenia, ale dla ścisłości, to jeszcze błąd ten występuje. W części "Top reputacje poprzedniego miesiąca" - webhostingtalk.pl/pomocni - nie ma Misiek08, Archi, Miłosz itd. w porównaniu do tego widocznego na stronie "Ranking dla miesiąca 4/2015" - webhostingtalk.pl/pomocni/ranking_punktow/miesieczny/04/2015/ To, że do tej części "poprzedni miesiąc" jest używany osobny kod widać chociażby po innej kolejności osób mających tę samą ilość punktów. Widziałem to już wcześniej, gdy jeszcze trwał kwiecień i poprzednim miesiącem był marzec, ale wstrzymałem się z komunikowaniem tego, by sprawdzić, czy nie jest to tylko jakiś cache.

W razie czego na zbliżonym poziomie cenowym jest też Aftermarket - 123 zł brutto. Na namecheap.com widzę cenę 24,99 USD Na domain.com oferują .tv w cenie 19,99 USD za rok pierwszy, ale już 29,99 za każdy kolejny.

Wydaje mi się, że należałoby zupełnie rozdzielić dwie kwestie: - sens istnienia, kto tego używa, kto nie, jak powinien wyglądać; - techniczna poprawność działania. Pierwsze poruszane było niejednokrotnie i ja osobiście wolałbym uniknąć ciągnięcia dyskusji na ten temat w tym konkretnym temacie. Wolałbym w nim podyskutować o drugiej kwestii - technicznej. Wielu z nas jest programistami, nie wiem jak Wy, ale ja ciekaw jestem jaki to konkretnie błąd tkwi w kodzie, że powoduje takie efekty. @ RafoX To, że osoby na liście pojawiają się i znikają w miarę zmieniania się rankingu widziałem i przy okazji spróbuję udowodnić. Tym razem zapisałem sobie obecny stan i za dni kilka go porównam. Przeliczyłem ranking dla stycznia, lutego i marca 2015. Oraz ten fragment kwietnia, który do tej pory minął. Pozycje przekreślone to te, które być na liście powinny, a jakimś cudem ich nie ma. =================================================================== edycja 2015-04-21, wtorek, 08:52 Pojawianie się i znikanie. Proszę bardzo. Spoofy właśnie otrzymał dodatkowe 2 punkty, więc zamiast 7 ma 9. I... zniknął z listy. Za to niewidoczny wcześniej Sebak, nadal mając 8 punktów, pojawił się. =================================================================== edycja 2015-04-21, wtorek, 09:00 Spoofy otrzymał kolejny punkt, ma 10. Pojawił się ponownie. Sebak pozostał widoczny, ale za to zniknął SiXwishlist. =================================================================== edycja 2015-04-21, wtorek, 16:04 Spoofy otrzymał kolejne 2 punkty, ma 12. Powrócił na listę SiXwishlist. Zniknął za to tgx.

Zauważyłem to przypadkiem już wiele miesięcy temu i chyba występuje w sposób ciągły dla wielu osób. Osobiście nie zwracam uwagi na system reputacji, ale pewnego miesiąca zerknąłem i (podane ilości będą przykładowe, bo nie pamiętam rzeczywistych) gdy miałem punktów 2, byłem na liście, mając 4 z niej zniknąłem, mając 5 znów się pojawiłem, mając 6 zniknąłem, mając 8 znów się pojawiłem itd. Próbowałem dociec czy zależy to od parzystości lub nie lub od osiąganego konkretnego miejsca na liście, ale nie udało mi się do żadnych takich logicznych wniosków dojść. Później jeszcze w dwóch innych miesiącach potwierdziłem swoje spostrzeżenia, nie tylko na swoim przykładzie, ale wyszukałem też inne osoby podobnie mające punkty (zauważone w historii reputacji), a nie występujące na liście. edycja: Przykłady z chwili obecnej: - RafoX ma 7 punktów w kwietniu, a nie ma go na liście; - pedro84 ma 7 punktów, a jest; - Piotr GRD ma 2 punkty w kwietniu, nie widnieje na liście; - theONE ma 3 punkty w kwietniu, nieobecny na liście; - Łukasz Ostrowski, 2 punkty, nie widnieje na liście; - kafi ma 10 punktów, a nie ma go na liście. A zwróćcie uwagę na tę listę, gdy dla wymienionych osób zmieni się ilość punktów, jestem pewien, że pojawią się, a z kolei inni z listy znikną. W kodzie odpowiedzialnym za tworzenie czołówki z każdego miesiąca jest gdzieś jakiś błąd. Być może również dla statystyk kwartalnych i rocznych, ale to już za dużo danych do analizy, nie chce mi się tak dogłębnie przeszukiwać historii reputacji. edycja 2, offtopic: Różnica znaczeniowa pomiędzy kątem a kontem jest spora i takie błędy po prostu rzucają się w oczy.

Pytanie chyba dotyczy subdomeny, więc teoretycznie można to jakoś obejść dla... tylko nielicznych klientów, większość i tak nie dotrze tam gdzie byśmy chcieli. Po pierwsze: znak & nie ma swojego odzwierciedlenia w punycode (a przynajmniej te kilka konwerterów, które wypróbowałem poddały się w tej kwestii). Co za tym idzie wszelkie zapytania DNS i HTTP będą zawierały ten znak tak jak jest, bez konwersji. Po drugie: większość oprogramowania sprawdza poprawność nazw domen i nie pozwoli na wywołanie znaku & w nazwie. Tak oprogramowania po stronie klienta jak i serwera. Przykładowo (po stronie serwera): próbowałem w DirectAdmin utworzyć subdomenę a&a - nie pozwolił. Przykładowo (po stronie klienta): te wersje przeglądarek Firefox i Opera, które mam u siebie zainstalowane, nie wywołały prawidłowo adresu zawierającego znak &, pomimo że umieściłem odpowiedni wpis w swoim pliku "hosts", jedynie stary IE6 nie miał oporów i dotarł na wskazany serwer. Zatem... to bez sensu. Należy odnaleźć "puszczone w świat" wpisy/linki/itp. i je zmienić.

Opisać odpowiednio musisz to na serwerach nazw (DNSach), których używasz dla domeny. Więc jeśli dla domeny ustawione masz DNSy ns1./ns2.twojrejestratordomen.pl - to u rejestratora, jeśli natomiast wykorzystujesz ns1./ns2.twojwybranyhosting.pl - to na tym właśnie hostingu, a jeśli ns1./ns2.innyuslugodawcadns.pl - to u tego innego usługodawcy.

A co to za dodatkowy ukośnik bezpośrednio po "usermd" ?... RewriteCond %{HTTP_HOST} ^(www\.)?goq123.usermd/\.net$ Powinno być raczej: RewriteCond %{HTTP_HOST} ^(www\.)?goq123\.usermd\.net$

Z .htaccess (zauważ kropkę na początku nazwy tego pliku, jeśli przypadkiem nie jesteś świadom tego detalu) można to uzyskać wszędzie. W katalogu głównym, na który wskazuje wybrana domena: RewriteEngine on RewriteBase / RewriteCond %{HTTP_HOST} ^(www\.)?example\.com$ RewriteCond %{REQUEST_URI} !^/pod-katalog/ RewriteRule ^(.*)$ /pod-katalog/$1 [L] jeśli domena ma po prostu wskazywać na zawartość "pod-katalogu" bez zmiany URL w pasku adresu przeglądarki. Jeśli adres w przeglądarce ma się zmieniać, jeśli ma to być faktyczne przekierowanie, to ostatnią linijkę należy zmienić na: RewriteRule ^(.*)$ http://example.com/pod-katalog/$1 [R=301,L] Ewentualne problemy jakie możesz napotkać: - często ludzie zapominają o RewriteBase, a w wielu miejscach (choć nie wszędzie) wpis ten jest konieczny; - jeśli w swym katalogu głównym masz już .htaccess z jakimiś wpisami, powyższe dodaj na początku pliku lub też skonsultuj z kimś kolejność wpisów, aby wszystko działało tak jak tego oczekujesz; - jeśli w "pod-katalogu" masz już też jakiś plik .htaccess, konieczna może okazać się modyfikacja jego zawartości. Nie ma tak, że "nie działa". Może być niewłaściwie napisany lub zaimplementowany nie tak jak należy, z pominięciem jakiegoś istotnego detalu. Ale ten sposób zadziała praktycznie wszędzie.

Aby się nawzajem nie obrażać, spróbuję do tematu podejść poważnie. Owszem, nazwy domen czasem, w sprzyjających okolicznościach zyskują na wartości. Czasem też tracą, rzecz jasna. Pytanie w tym przypadku brzmi następująco: jeśli przed 14. marca - kiedy to zarejestrowałeś domenę - nazwa ta nie była dla nikogo innego warta nawet ceny rejestracji, to czy w ciągu tych kilkunastu dni akurat zdążył się już gdzieś pojawić ktoś, dla kogo jest ona warta ten tysiąc lub chociażby kilkaset?... Dość mało prawdopodobne. Domena była już wcześniej rejestrowana, DomainTools ma zapisy sięgające wstecz do 2009-ego roku. Jednak poza tym serwisem trudno jest gdziekolwiek znaleźć po niej jakikolwiek ślad. Zatem nie okazała się aż taką żyłą złota. I najprawdopodobniej nie okaże też w najbliższej przewidywalnej przyszłości.

@ blfr Mają pełne whois - oczywiście tylko z tych konkretnych momentów, kiedy akurat wykonywali zapytanie - zatem rejestratora też. Myli się czasem ich automatyczny interpretator danych (dla jednej z moich domen obecne dane z "technical contact" bierze jako rejestratora), ale z pewnością udostępniają również czyste odpowiedzi z whois. @ PanDoktor Jeśli tak bardzo Ci zależy, to pisz do nich. dns.pl/kontakt.html Daj znać później, czy i w jaki sposób na takie pytania odpowiadają.

Dla części domen takie historyczne dane ma zgromadzone serwis DomainTools, jednak oferuje wgląd do nich odpłatnie. Być może istnieją również inne tego typu serwisy, nie wiem. Ale z pewnością istnieją takie, które rzadko odświeżają dane, można więc czasem - ale tylko czasem - natrafić na info o jakiejś domenie sprzed wielu miesięcy (możesz wpisać w Google nazwę domeny i porozglądać się po tych wszystkich "website info, domain info" itp.). Oczywiście jak najbardziej wpisać możesz nazwę domeny pod adresem whois.domaintools.com i przekonasz się, czy DomainTools ma w ogóle jakieś historyczne wpisy zgromadzone czy nie (ile ich jest i datę najstarszego). Jeśli ma i bardzo będzie Ci zależało na tych informacjach, możesz wziąć 7-dniowy darmowy okres testowy u nich. Potem tylko odpłatnie.

Ja swego czasu zauważenie takiej nieprawidłowości zgłosiłem samemu sprzedawcy. Tyle, że był to "przedsiębiorca" sprzedający regularnie dużo przedmiotów (do dziś dnia działa na Allegro, a sytuacja miała miejsce jakieś 2 lata temu). W przypadku osób wystawiających coś tylko od czasu do czasu mój sposób może być zupełnie nieskuteczny. Najpierw zapytałem jak się odnosi do tego - i czy w ogóle zauważył - że najprawdopodobniej jedna i ta sama osoba bierze udział w jego licytacjach pod wieloma nickami nabijając - jak można się domyślić - ceny. Udał, że nie wie o czym w ogóle piszę. W kolejnej wiadomości przedstawiłem więc konkretne - nazwijmy to - "poszlaki" wskazujące wyraźnie na proceder nabijania cen: godziny składania ofert przez te kilka nicków (licytowali kolejno po sobie w odstępie minut, jakby stojąc w kolejce do jednego komputera, zawsze w różnych licytacjach, nigdy "nie wchodzili sobie w drogę" co do przedmiotów), nowe trwające licytacje przedmiotów, które to przecież kilka dni wcześniej już zostały kupione. Po tej drugiej wiadomości nie otrzymałem już bezpośredniej odpowiedzi, ale: - zostałem "zbanowany" - czyli nie mogę już kupować u tego sprzedawcy; - krótko potem sprzedawca przestał wystawiać przedmioty od złotówki, a zaczął od 29, 39, 49 złotych - zależnie od realnej wartości przedmiotów - i nie było już nabijania cen (nie miał już takiej potrzeby przy innej cenie wywoławczej). Zatem okazałem się skuteczny. Na szczęście. Bo gdybym po pewnym czasie zauważył, że proceder w przypadku tego sprzedawcy nadal trwa - nie omieszkałbym tych samych "poszlak" przedstawić również obsłudze Allegro.

Znam ten trik, choć akurat nie z domen, a z innych przedmiotów. Wystawiają niektóre osoby przedmioty w licytacji od niskiej kwoty i bez ceny minimalnej (bo tak taniej, opłata za wystawienie minimalna), a gdy licytacja nie przebiega po myśli sprzedającego (cena na licytacji zbyt niska), to dosłownie kilkadziesiąt sekund, co najwyżej 2 minuty przed końcem aukcja jest w taki właśnie sposób odwoływana. Żeby było śmieszniej: czasem już następnego dnia ten sam - zniszczony/zgubiony/stracony - przedmiot wystawiany jest na sprzedaż ponownie. Inny trik z Allegro, jaki zauważyłem, to licytowanie własnych przedmiotów za pomocą kilku fikcyjnych kont - oczywiście dla podbicia ceny. Gdy nikt fikcyjnego konta nie przebije - trudno, po kilku dniach ten sam przedmiot - niby już sprzedany - wystawiany jest ponownie.

Jeśli to mają być tylko strony typu Oferia, to mają one swoje wewnętrzne wyszukiwarki, zatem i skrypt mógłby ograniczać się do przejrzenia tylko wyników wyszukiwania. Byłoby to rozwiązanie najprostsze, najszybsze i najbardziej optymalne, tak dla serwera z botem, jak i dla przeszukiwanego portalu. Chyba, że wewnętrzna wyszukiwarka na danej stronie nie istnieje lub działa w sposób niezadowalający (inny niż byśmy chcieli), wówczas trzeba faktycznie przejrzeć cały portal (lub przynajmniej ściśle określoną jego część zawierającą np. pełną listę ogłoszeń, a także każde ogłoszenie z osobna, jeśli lista zawiera tylko skrócone wersje ogłoszeń). W takim przypadku przydałby się jeszcze jakiś 'cache' (wewnętrzna kopia przejrzanych już wcześniej ogłoszeń), bo przeglądanie dziesiątek tysięcy stron (ogłoszeń) każdorazowo dla kolejnych zapytań optymalnym rozwiązaniem nie będzie (mogłoby się nawet kończyć banem dla bota na danym portalu).

Jeśli była zarezerwowana i po 14 dniach wypadła, to przez 90 dni NIE mogła zostać ponownie zarezerwowana (chyba, że odczekałeś te 90 dni, wówczas powinna zostać normalnie zarezerwowana). W takim przypadku Twoje zamówienie w OVH 21-ego lutego nie niosło za sobą żadnych faktycznych konsekwencji dla domeny, nadal była w stanie możliwym do rejestracji (ale NIE do rezerwacji) i zarejestrowana została przez tę osobę, która wcześniej dokonała wpłaty. Osobną sprawą jest to, że rejestrator wiedział o Twoim zamówieniu, a pozwolił też złożyć zamówienie komu innemu (albo kto inny wcześniej złożył zamówienie, a pozwolił też złożyć zamówienie Tobie). Będzie to trochę nieetyczne, ale formalnie nic zarzucić nie można. Jeśli nie istnieje dla domeny rezerwacja - a nie istnieje dla *.com, *.net oraz dla *.pl "BOOK_BLOCKED" - to domenę ma ten, kto pierwszy zapłaci, nie ten, kto pierwszy złoży zamówienie.

W formie ASCII powinien według mnie każdy serwer/panel domenę przyjąć, choć może istnieją takie "wybredne". Przyjmuję do wiadomości, że nie wszystkie programy/panele/aplikacje/itp. przyjmują wersję wpisywaną z ogonkami, rozumiem i akceptuję, mam to na uwadze cokolwiek z domenami takimi robiąc. Dla tworzących oprogramowanie... są dostępne w sieci gotowe do wykorzystania darmowe implementacje konwerterów IDN -> ASCII. Gdy potrzebowałem w PHP - znalazłem. A od wersji PHP 5.3.0 istnieje już wbudowana funkcja. Co do rejestracji takich domen - zgadzam się z OneDistrict, raczej należy mieć wersje z i bez polskich znaków. Nawet w zwykłych komentarzach, dyskusji na forach internetowych itp. jest (niestety!) dużo osób nie używających "prawego Alt", zapewne nie użyją tego klawisza również wpisując URL.

Żebyśmy się dobrze zrozumieli... W pierwszym poście napisałeś, że została zarejestrowana przez automat (na rok) i wygasła? Czy masz na myśli, że została zarezerwowana przez automat ("oczekuje w kolejce do rejestracji" przez 14 dni) i wypadła z tej kolejki (czyli NIE została zarejestrowana). Jeśli to drugie, to po 14 dniach rezerwacji domena *.pl przechodzi w stan "BOOK_BLOCKED", jest usunięta z kolejki, nie można jej rezerwować, ale można ją zarejestrować. Wcześniej ten stan trwał 5 dni, ale od niedawna wydłużono okres do 90 dni. Jeśli domena jest w takim stanie, a osobiście chciałbym mieć pewność jej rejestracji, to wybrałbym rejestratora, u którego istnieje tzw. "skarbonka" (i który oczywiście ma możliwość rejestracji domen w stanie "BOOK_BLOCKED", bo nie wszyscy mogą), najpierw doładowałbym konto odpowiednią kwotą, a dopiero potem w jakimkolwiek formularzu (innym niż formularz "whois") wpisał nazwę domeny, pokładając nadzieję, że opłacenie ze "skarbonki" będzie natychmiastowe i nie będzie czasu, by ktokolwiek mógł domenę "podebrać". Podobnie postępowałbym w przypadku domen *.com/*.net itp., bo tu rezerwacja nie obowiązuje, kto wcześniej zapłaci, ten ma domenę. Ale inna sprawa to taka, że jeśli faktycznie wykonałeś płatność wskazanego dnia o wskazanej godzinie i dokładnie w tym samym momencie nastąpiła rejestracja, ale NIE na Ciebie, to coś jest nie tak. W takim przypadku - przy idealnym zgraniu w czasie - upewniłbym się w rozmowie z obsługą OVH, czy aby nie wystąpił jakiś błąd po ich stronie.