Piotr GRD

Stworzyłeś strefę DNS w panelu CT8, a "konto hostingowe" dla tej domeny? (pozycja wyżej w menu ponad strefami DNS: "strony www"). Jeśli tak, a mimo to nie działa, to zgłoś się na forum.ct8.pl, nie tutaj.

W rzeczywistości obecnie jest inaczej. Ale uważam, że powinien pojawić jakiś społeczny ruch, nacisk na to, aby zmienić prawo w tym zakresie i uznać systemy i programy komputerowe (i inne tym podobne) za produkty takie same jak każdy inny. Uważam, że powinienem mieć prawo system lub program przenieść z jednego urządzenia na drugie (np. kupując nowy komputer powinienem mieć swobodę, aby na starym system skasować i zainstalować ten sam na nowym, co nierzadko kończy się fiaskiem nawet, gdy tylko część podzespołów komputera jest zmieniana) lub też po znudzeniu się systemem lub programem odinstalować go u siebie i odsprzedać tak jak każdą inną rzecz.

A może to coś z RewriteBase jest namieszane dziwnie na tym konkretnym serwerze?... Drako66, przerzuć linijkę z RewriteBase powyżej przekierowania, bezpośrednio po RewriteEngine On. edycja: Ale widzę, że już działa prawidłowo.

@ jotme %1 ma (powinien mieć) teraz nazwę domeny (bez www) i to jest wstawiane po http:// a przed /$1 Taki kod stosuje się, by nie musieć wpisywać każdej używanej przez siebie domeny/subdomeny osobno, kod uniwersalny dla każdej, aby "pozbyć się" www z URLa. Ten dodatkowy folder "netpiko/" po zastosowaniu tego kodu występować nie powinien, gdzieś jest jakiś błąd, jeśli się pojawia. Drako66, wrzuć na próbę domenę "na sztywno" (zamiast %1), ale to nie powinno mieć znaczenia, Twój powyższy .htaccess wygląda prawidłowo.

www. netpiko .com HTTP/1.1 301 Moved Permanently (...) Location: http://netpiko.com/netpiko/ (...) Skąd ten dodatkowy folder "netpiko" w ścieżce?

Możesz też dodać wyraźny nagłówek HTTP "Content-Disposition: attachment;". <FilesMatch "\.(txt|jpg)$"> ForceType application/octet-stream Header set Content-Disposition attachment </FilesMatch>

Nie wiem jak to jest teraz, ale w 2007 portal taki jak napisy.org został zamknięty, a kilka osób zatrzymanych przez policję. Co się stało z tymi osobami, czy i jak odpowiadali za to - nie wiem. Myślę, że zostały w sieci informacje i artykuły o tym, więc możesz poszukać. Zacząć można od napisy.org i kinomania.org/list.html Nie wiem też czy i co zmieniło się w stanie prawnym od tego czasu. Podstawową - prawnie - kwestią było to, że rozpowszechnianie tłumaczenia ścieżki dźwiękowej filmu wymaga zgody właściciela praw autorskich tegoż filmu. To był portal z napisami do całej masy filmów, było tego dużo, w dodatku czas był taki, że akurat nasilały się ruchy próbujące ukrócić piractwo takie czy inne. Dziś o takich akcjach słyszy się już mniej, bo i zjawisko zmalało, zmieniło się. Na małą skalę osobiście nie widzę w tym nic nagannego, na małą skalę nie bałbym się też konsekwencji, zwykle pewnie będzie tak jak napisał Kamikadze, że właściciel praw autorskich zgłosi się do Ciebie lub Twojego hostingu, a jakbyś nie zareagował, to dopiero do odpowiednich służb (chyba, że ktoś by był wredny, nie lubił Cię z jakiegokolwiek powodu, uparł się i złożył donos, wtedy organy muszą zareagować i sprawdzić). Ale to NIE jest wykładnia prawna. O takową zapytaj na jakimś forum prawnym.

Skoro już mnie naprowadziłeś na find (którego - mając mało wspólnego z linuxem nie używałem dotąd), to chyba będzie to jakoś tak: find $toarchfiles -newermt 2016-01-01 -type f Oczywiście datę możesz wprowadzić ze zmiennej. Albo odwołać się można do daty modyfikacji pełnego rocznego backupu: find $toarchfiles -newer fullstartyear.tar.gz -type f Choć to może być zdradliwe ze względu na różnicę - nawet wielominutową w przypadku dużej ilości danych - pomiędzy rozpoczęciem tworzenia tego rocznego archiwum, a zakończeniem jego tworzenia - w międzyczasie coś przecież mogło ulec zmianie i nie będzie wtedy uwzględnione. // edytowałem, bo pierwotnie źle napisałem pierwszą linijkę, źle zrozumiałem instrukcje dotyczące -newerXY.

Jedno mnie zastanawia... Skoro dla wielu osób jest to pewien rzeczywisty problem, to dlaczego nie reaguje na to zespół WHMCS? Przecież dla nich rozwiązanie tego byłoby stosunkowo najprostsze w implementacji, dodanie jednej opcji "twórz / nie twórz faktur za zero" i dopisanie kilka linijek z "IF" gdzie należy. Z ciekawości zajrzałem, zobaczyłem frazę "if(!extension_loaded('ionCube Loader'))" i resztę sobie podarowałem, nie mam natchnienia do wertowania dokumentacji dotyczącej modułów, choć chętnie zabawiłbym się w "detektywa" odnajdującego odpowiedni fragment w kodzie.

Nie do końca rozumiem do czego, w jakiej sytuacji mogłyby Ci się przydać archiwa ze zmianami z ostatnich 7 dni. Ale być może masz swoje zastosowanie. Twoja - obecnie zmodyfikowana - uwaga dotycząca niedogodności z archiwami gzip... Ściśle rzecz ujmując to nie chodzi o rodzaj kompresji, ale w ogóle o skompresowane archiwa TAR, bez względu na to czy skompresowane przy użyciu gzip, bz2, deflate, lzma czy jakkolwiek inaczej. Jeszcze jedną opcję TARa Ci podpowiem, może skorzystasz, może nie. Jak dla mnie pewną niedogodnością jest obecność wewnątrz archiwum pełnej struktury folderów włącznie ze ścieżką /home/USERNAME/domains/EXAMPLE.COM - przecież jeśli wybraną domenę przeniosę na inny hosting, to ścieżka - choćby USERNAME - pewnie będzie inna, a więc po wypakowaniu plików trzeba jeszcze wykonać ich przeniesienie do odpowiedniego folderu. Dlatego korzystam z opcji -C ("-C /home/USERNAME/domains/EXAMPLE.COM/"), a w swoich archiwach mam jedynie zawartość public_html dla każdej domeny osobno (z poczty na hostingach nie korzystam, za wyjątkiem przekierowań, reszta jest mi zbędna w razie przenosin). Inną niedogodnością - w przypadku archiwów ze zmianami - jest niepotrzebne odzwierciedlenie pełnej struktury folderów, nawet jeśli są one w tymże archiwum puste (bo wewnątrz nie ma zmodyfikowanych ostatnio plików). Przy rozbudowanym drzewie i chęci ręcznego przejrzenia co się zmieniło jest to pewne utrudnienie. Ale w ramach samego TAR tego ponoć nie można obejść, trzeba by osobnym skryptem najpierw badać datę modyfikacji plików, a później TARowi przedstawić tylko wyszczególnioną ich listę, co raczej nie jest warte zachodu. Dla osób, które jednak korzystają z baz danych - najczęściej MySQL - dodam prostą, podstawową linijkę, na bazie której można oprzeć archiwizowanie baz danych właśnie. Pierwsza wersja dla jednej określonej bazy danych, druga dla wszystkich baz, do których użytkownik ma dostęp. Modyfikacje według uznania, oczywiście, każdemu według potrzeb, ale początkujący może od poniższego zacząć. mysqldump -u MYSQLUSERNAME -pPASSWORD DATABASENAME | gzip > /PATH/database_backup.sql.gz mysqldump -u MYSQLUSERNAME -pPASSWORD --all-databases | gzip > /PATH/alldatabases_backup.sql.gz Dla dodatkowego bezpieczeństwa dla celów backupu tworzę specjalnego użytkownika bazy danych, który ma nadane wyłącznie uprawnienia SELECT i LOCK TABLES.

Dlatego ja stosuję format .tar.gz - wiem, że w jakimkolwiek środowisku nie przyjdzie mi pracować, na jakiekolwiek ograniczenia nie trafię, z pewnością obsługa tar i gzip będzie. Owszem, dziwnie wykorzystywać cronjob do takiego zadania, choć przy braku SSH zdarzało mi się wykorzystywać tę procedurę do różnych jednorazowych wywołań jakiejś komendy. Ponadto... Skoro jesteś świadom ograniczeń tychże tanich hostingów, to musisz wykazać się kreatywnością w podejściu do tematu. Masz jeszcze PHP, a w nim funkcję exec() (jeśli nie zablokowana, bo i z tym różnie bywa). Na wspomnianym wyżej hostingu pozbawionym dostępu do cronjob wywołuję tworzenie backupów z zewnątrz (np. z pomocą cronjob.de), uruchamiam skrypt PHP, który to z kolei uruchamia tar i mysqldump.

W formacie ZIP istnieje nagłówek "extra field", który może zawierać cokolwiek, ale nie wiem czy jakiekolwiek oprogramowanie zapisuje tam i odczytuje stamtąd UNIXowe uprawnienia plików. Nie wiem, nigdy nie zagłębiałem się w temat. Jeśli menadżer plików w DirectAdmin rozpakowuje tylko archiwa TAR spakowane metodą GZIP, to pozostaje Ci takie właśnie archiwa tworzyć, albo rozpakowywać je później bezpośrednio tym samym TARem bez użycia menadżera DA. Przecież nie jesteś ograniczony menadżerem plików w DA, jeśli na jakimś hostingu możesz używać TAR do pakowania plików, to i możesz do rozpakowywania. tar xf archiwum.tar tar xzf archiwum.tar.gz tar xjf archiwum.tar.bz2 tar xf archiwum.tar.lzma (albo: "tar xf archiwum.tar.lzma --lzma", nie jestem pewien, nie stosowałem)

Czyste nieskompresowane archiwum tar będzie większe niż rozmiar składowanych w nim plików, w końcu trzeba jeszcze zachować informacje o strukturze folderów, o uprawnieniach każdego, datach modyfikacji itp. Co do 7zip... Chyba nie do końca odróżniasz format archiwum 7z od sposobu kompresji. Format archiwum 7z nie przechowuje uprawnień plików właściwych dla danego systemu plików, nie zachowa więc informacji o użytkownikach/grupach UNIXowych, ani ACL w systemie NTFS itp. Dlatego nie nadaje się do tworzenia kopii zapasowych, o których tutaj mowa. Do tego musimy (powinniśmy) użyć formatu archiwum TAR. Ale jeśli zauważyłeś, że kompresja oferowana przez 7zip jest lepsza, a zależy Ci na wielkości archiwum, to z powodzeniem możesz zastosować tę samą również i dla archiwów TAR. Domyślnie 7zip wykorzystuje kompresję LZMA (choć możesz też wybrać dla przykładu bzip2 lub zwykłe deflate). Z tego co wyczytałem TAR od wersji 1.20 ma również zaimplementowaną obsługę LZMA (opcja --lzma zamiast j dla bzip2 czy z dla gzip), a od wersji 1.22 również i LZMA2 poprzez xz (opcja --xz albo -J). To jednak nie rozwiąże Twojego problemu (niedogodności) z koniecznością dekompresji takiego pliku przed wydobyciem czegokolwiek ze środka. Po prostu najpierw tworzone jest archiwum TAR, a dopiero potem całość kompresowana. Inaczej niż w archiwach 7z, ale ten format nie przechowa uprawnień. Co do obecności na poszczególnych hostingach... nie wiem. Z rozpakowywaniem ZIP nigdy nigdzie nie miałem problemu, archiwów7z nigdy w sumie nie używałem.

Bazując na wielu wcześniejszych tematach koriego - mówi on o "hostingach" ; ), jak to ująłeś samu. Wiele maluczkich osób nie ma wielkich wymagań i korzysta z najtańszych możliwych (lub wręcz darmowych) rozwiązań. Sam też korzystam z takich, gdzie dostępu po SSH nie ma, ba, na jednym nawet nie ma cronjob. kori, podpowiem Ci może co ja robię w przypadku, gdy ogólna ilość plików na serwerze jest względnie duża, ale tych zmieniających się, dodawanych na bieżąco względnie mało. Mianowicie pełny backup plików dokonywany jest rzadziej, a częściej tylko ten z plikami zmodyfikowanymi później niż wyznaczona data. Korzystając z tar dodaję argument --newer-mtime=... A jako że w moim przypadku w ogóle są to niewielkie rozmiary, bazy danych (zrzucane za pomocą mysqldump) i archiwum .tar.gz z tymi zmodyfikowanymi plikami wysyłam sobie emailem na dwie różne skrzynki pocztowe (nawet darmowi usługodawcy udostępniają wystarczająco duże skrzynki, a dość małe jest prawdopodobieństwo, że nagle znikną dwa serwisy naraz, więc dane są relatywnie bezpieczne). Pełen backup pobieram raz na rok lub rzadziej i wtedy też zmieniam datę dla archiwum z plikami zmienionymi. W razie potrzeby odzyskania danych przywracam ten pełen plus zmienione pliki i najnowszą bazę danych z emaila. Przy większej ilości danych zmienić by trzeba sposób przesyłania danych na zewnątrz (bo nic Ci nie da backup trzymany tylko na tymże tanim hostingu, jeśli on padnie na dłuższy czas lub zniknie w ogóle, a ręczne pobieranie na dłuższą metę się nie sprawdza w żaden sposób). Archiwa przechowuję też oczywiście lokalnie na tymże hostingu. W razie czego szybciej można przywrócić wszystko bez konieczności wgrywania backupów z zewnątrz (np. gdy osoba korzystająca ze strony/forum/bloga coś namiesza, przez przypadek skasuje wszystkie posty itp.). W przypadku baz danych kopia wykonywana co 24 godziny, te starsze niż powiedzmy tydzień usuwane prostym skryptem. To wszystko oczywiście rady dla 'maluczkich', którzy mają jakieś tam strony ważne dla siebie, ale już nie tak ważne patrząc obiektywnie, by koniecznie wdawać się w bardziej profesjonalne rozwiązania, które mogą kosztować więcej (np. droższy - czyli więcej niż 30zł rocznie - hosting dający dostęp SSH) lub wymagać więcej czasu na poznanie sposobu działania (3 linijki wykorzystujące tar/gzip/mysqldump plus gotowy skrypt wysyłający emaila i kasujący starsze archiwa - to opanować można i zaimplementować szybciej, niż poznawanie rsync i podobnych systemów). PS. Tego raczej nie przeskoczysz. Bo sposób działania jest taki, że tworzone jest archiwum .tar - czyli wiele plików łączonych jest w jeden duży - a następnie tenże duży plik jest kompresowany - czy to wykorzystując gzip czy bz2. W drugą stronę *musi* nastąpić dekompresja (chociażby tylko do pliku tymczasowego), by móc zajrzeć do archiwum .tar i z niego cokolwiek wydobyć. Musiałbyś zmienić sobie sposób tworzenia archiwum, wprowadzić kolejność odwrotną niż domyślna. Najpierw kompresja każdego pliku osobno, a dopiero potem z nich tworzenie .tar. Do późniejszego przywracania danych też jednak musiałbyś mieć podobnie działające indywidualnie stworzone narzędzie (chyba, że już ktoś zrobił coś takiego gotowego, nie wiem).

Zawsze możesz w ramach swojego monitoringu zacząć odpytywać również i wybrane serwery DNS. ; ) Ja tak robię z DNSami wybranych usługodawców (nie tylko HTTP czy FTP, ale i DNS), a pośrednio w ograniczony sposób nawet i DNSy odpowiedzialne za końcówkę *.pl (a-dns.pl, c-dns.pl itd. i mogę powiedzieć, że w ostatnich miesiącach g-dns.pl potrafi szwankować). Choć przyznam, że o sprawdzaniu zarówno UDP jak i TCP do tej pory bym nie pomyślał. Większość sprawdzam przez UDP, a tylko dla niektórych włączałem TCP, gdy problemy z UDP były permanentne, a mimo to wszystko zdawało się dla świata działać.

Proponuję - odnośnie tej dezorientacji tych, którzy nie czytając pierwotnego tematu mogą nie znać i nie rozumieć ewentualnego kontekstu itd. itp. - w przypadku takich tematów nazywać je odpowiednio, np.: "Zła i okrutna administracja [wydzielone z: Temat oryginalny]" Coś takiego (w dość okrojonej wersji) znaleźć możemy w koszu, są tam tematy zatytułowane: "Z: Temat oryginalny".

Jeżeli w 'whois' widzę, że "ostatnia zmiana: 2016.03.10 20:57:10", a o 21:59 (czyli zaledwie godzinę później) już ktoś narzeka, że jeszcze się zmiany nie rozpropagowały wszędzie, to przyznam, że zaczynają mi ręce opadać, bo to niestety coraz częstsze zachowanie. Uwzględnijcie cache DNS. Nie tylko ten na własnym komputerze, który można wyrzucić przez /flushdns, ale i na wszelkich "stacjach pośredniczących", jak np. DNSy dostawcy internetowego. Dla domen *.pl propagacja może zająć do 24 godzin, dla domen *.com do 48 godzin, choć z reguły dla 99% lokalizacji dzieje się to w kilka godzin. Ale nie w godzinę, dla sporej części internetu jeszcze nie w godzinę. Poza tym ostatnio zauważyłem, że nawet główne DNSy dla *.pl potrafią mieć opóźnienie. 'Whois' pokazywało już dla pewnej domeny nowe serwery nazw, a 'a-dns.pl, c-dns.pl' itd. "zaskoczyły" dopiero kilkadziesiąt minut później. Więc niestety... jeśli zmieniacie autorytatywne serwery nazw u rejestratora (a nie tylko rekordy A, AAAA z krótkim TTL na wciąż tych samych DNSach), to wykażcie odrobinę cierpliwości, więcej niż godzinę. A tak na marginesie... Panie 'webmaster'. Na nowym serwerze odwołujesz się wciąż do ścieżki na CBA. <img src="http: / / nieidealni.cba.pl/wp-content/uploads/2016/03/abcd.jpg" alt="Nieidealni" Na darmowych kontach CBA (na płatnych nie) 'hotlinkowanie' jest zablokowane, więc widać ładny obrazek reklamujący ten hosting zamiast Twojego. Może właśnie dlatego klientka twierdzi, że widzi wciąż CBA? Zapewne o tym właśnie "header wyświetla CBA" mówi Westbam.

Od 50 do 55 milisekund z Chello/UPC Szczecin.

@ Spoofy Przyjrzyj się choćby opcji "ukryte pole captcha" w MyBB. Warto jest dobrać "zachęcającą" do wypełnienia nazwę takiego pola. Wordpressa z kolei zmodyfikowałem tak, że poza dodaniem pustego pola pozamieniałem również nazwy pól formularza do komentowania. Sprawdza mi się od wielu lat również proste pytanie "jesteś botem? tak/nie" przy rejestracji na forum SMF. To wszystko oczywiście działa świetnie, dopóki nie jest zbyt powszechne, dopóki rozwiązanie jest indywidualne, *unikalne* i na niezbyt wielkiej stronie, dla której nikt nie będzie się silił, by specjalnie tworzyć dla niej bota. To może zupełnie nie sprawdzić się na stronach dużych, popularnych, lub na takich, które stanowią dużą zachętę dla twórców botów jak wspomniana przez xfilokolo jego strona związana z bitcoinami, w takim przypadku ktoś pewnie jak najbardziej może zechcieć się wysilić i napisać bota specjalnie pod tę stronę. Innymi słowy: maluczcy mogą ustawić sobie coś prostego, nieinwazyjnego, ale unikalnego i skutecznego, jednak duże portale i/lub takie, które są z jakichś względów szczególnym magnesem dla botów i ich twórców muszą prowadzić ciągłą walkę.

W Home było tak jakoś od pierwszej dekady listopada 2013 do końca roku 2014 (lub nawet do 1 stycznia 2015), czyli niecałe 14 miesięcy. ; ) Przed listopadem 2013 też chyba było w Atman (choć bazuję na obecnej geolokalizacji IP, która może być inna niż w 2013). A z Beyond od pierwszych dni forum było serwowane o kilka dziesiątych sekundy wolniej niż z pozostałych lokalizacji.

Nikt jednak nie odpowiedział odnośnie domeny *.eu waito, możesz czuć się bezpiecznie, gdyż kod AuthID możesz pobrać bezpośrednio w systemie EurID: http://www.eurid.eu/pl/abonenci-domen-eu/transfer-your-eu-domain-name/wniosek-o-kod-autoryzacyjny Więc jeśli to będzie konieczne lub po prostu masz taką ochotę możesz przenieść obsługę domeny do innego rejestratora bez oglądania się na dotychczasowego. edycja: Oczywiście transfer domeny *.eu wiąże się z jednoczesną koniecznością przedłużenia na rok następny i wniesienia opłaty.

Po migracji jest szybciej. Od wczoraj - za wyjątkiem okresu 13:48-14:16, kiedy to znów był jakiś problem - strona główna forum wczytuje mi się w czasie ok. 300-600 milisekund. Na poprzednim serwerze strona główna forum wczytywała mi się - gdy wszystko działało sprawnie - w czasie ok. 600-900 milisekund, a na początku roku 2015 nawet ok. 700-1000 milisekund. Na jeszcze wcześniej używanym serwerze, w roku 2014, było to odpowiednio ok. 400-700 milisekund, choć wtedy znacznie częstsze były chwile, kiedy wydłużało się to do półtorej lub dwóch, a nawet trzech sekund.

Jednej, a właściwie dwóch rzeczy nie rozumiem... Miałem pisać już o tym poprzednio, 27-ego stycznia, ale piszę teraz. Czy naprawdę istnieje konieczność każdorazowego pozyskiwania treści z zewnętrznych źródeł, przy każdym wywołaniu strony skrypt musi się do tych zewnętrznych źródeł odwoływać? Osobiście zawsze staram się wprowadzać cache. Jak długi - to zależy od tego jak częstych zmian w tych zewnętrznych źródłach się spodziewam. Nawet ustawiony na kilkadziesiąt sekund moim zdaniem się przydaje - bo oszczędza zasoby tak moje jak i tego zewnętrznego serwera - a w przypadku problemów z połączeniem ratuje sytuację dla osób odwiedzających stronę, bo co najwyżej na niektóre ich zapytania serwer będzie odpowiadał ze zwłoką, a nie na każde. A druga kwestia to długość 'timeoutu' - 20 sekund? Niewiele osób ma chęć czekać na stronę dłużej niż dziesięć sekund. Trzeba to uwzględnić i rozważyć, czy koniecznie chcemy pobrać te zewnętrzne dane kosztem utraty odwiedzających w razie problemów z połączeniem?

Podobnie jak 27 stycznia, tak i od wczoraj (18 lutego) począwszy od godziny 17:38 (czyli już prawie 24 godziny) na każde wyświetlenie strony na forum WHT czekać trzeba ok. 20-21 sekund. Zapytania AJAXowe serwowane są bez takiej zwłoki. Stąd - tak jak poprzednio - moje podejrzenie skierowane jest na problem skryptu forum z dostępem do jakiegoś zewnętrznego źródła, a 'time-out' ustawiony jest właśnie na 20 sekund.

@ drozdobyx Jeśli połączenie trwa cały czas (lub rozłączane jest na krótko, nie dłużej niż to na ile dzierżawiony jest adres IP dla danego adresu MAC), to w UPC ma się praktycznie rzecz biorąc niemalże stały adres IP. Niby jest on przypisywany dynamicznie, ale dla przykładu ja poprzedni miałem niezmienny przez ponad 2 i pół roku, a w wyniku zmiany pakietu usług i podłączenia nowego modemu, który przysłali, nowy adres mam od grudnia. Wcześniej też zmiany zachodziły u mnie co roku lub rzadziej, w zasadzie chyba tylko wtedy, gdy coś w swojej konfiguracji UPC zmieniało. @ j1gg Ja u siebie mam. System -> Tryb switch -> tryb router / tryb bridge. Nie testuję jednak, bo akurat ja nie chcę zmieniać adresu. Zapewne będzie to działać, ale chciałbym mieć pewność, że po zmianie powrotnej wrócę do poprzedniego IP (przypuszczam, że tak). Kiedyś zaryzykuję i spróbuję, bo ta możliwość zmiany IP w tę i z powrotem czasem się przydaje. Jeszcze jedno mi przyszło do głowy... W podstawowych informacjach, tam gdzie widać MAC i obecne IP, mam też datę i godzinę wygaśnięcia. Ostatecznie, jeśli nie znajdziesz innego rozwiązania, możesz sprawdzić, czy jeśli wyłączysz modem przed tą datą, a włączysz już po niej, to czy nie uzyskasz w ten sposób nowego (bo obecna dzierżawa wraz z tą datą wygaśnie). edycja kilka godzin później: Nic z tego, modem automatycznie regularnie odnawia dzierżawę adresu, musiałbyś się odłączyć na 48 godzin, a robiąc to o odkładnie zaplanowanej porze, na co najmniej 24 godziny i kilka sekund.