Piotr GRD

Widzę, że Twoja strona jest zupełnie nowiutka - domena zarejestrowana niecałe 5 dni temu. Musisz niestety pogodzić się z tym, że aby znaleźć się na pierwszej stronie wyników wyszukiwania będziesz musiał trochę popracować. Zauważyłem już kilka lat temu na przykładzie swoich własnych stron, że strony zupełnie nowe są tak jakby promowane przez Google i znajdują się wysoko na liście. Po pewnym czasie pozycja się wyrównywała do tej właściwej, jakiej można się spodziewać po stronie nie mającej jeszcze wiele linków w sieci do niej kierujących, nie mającej jeszcze żadnej renomy, historii itd. Nie jestem ekspertem od SEO, mogę się mylić, ale na przykładzie praktycznie każdej ze swoich stron, które zaczynały swoje życie kilka lat temu, taki właśnie efekt zauważyłem.

Jak dla mnie odpowiadają. I ode mnie osobiście i z użyciem spacereg.com (Kalifornia, San Diego). Pozwoliłem sobie włączyć mój monitor - akurat odpytywanie NSów o rekord A nie zabiera mi wiele zasobów - czasowo (powiedz, jeśli mam wyłączyć), więc jeśli wykryję ze swojej strony jakieś pady czy spowolnienia, dam Ci znać, będą wtedy jakieś konkretne dane, być może regularność w określonym czasie itp.

No cóż... wygląda na to, że transakcja została dokonana. Właśnie otrzymałem email informujący o przejęciu usług UPhost.pl / UPares.pl przez KRDC sp. z o.o.

Nawet jeśli drzwi od mieszkania nie zamknę na klucz - nie ma prawa nikt wejść. Nawet jeśli prywatny ogródek odgrodzę tylko symbolicznie 20-centymetrowym ozdobnym płotkiem - nie ma prawa nikt wejść. Nawet jeśli niczego nie szyfruję i mam pootwierane wszystkie porty w firewallu - nie ma prawa nikt wejść. Nawet jeśli nie mam żadnych zabezpieczeń antywłamaniowych, a ktoś wejdzie, to będzie to włamanie. I tak jak nie chcę, żeby przestępca wchodził mi do mieszkania - nawet gdy zostawię je otwarte - tak też nie chciałbym, by jakikolwiek urzędnik, policjant czy nawet rządowy automatyczny skrypt monitorował co robię, jeśli niezależny sąd czy prokuratura nie wydały takiej zgody, nawet jeśli mam 100-procentowo czyste sumienie i nic do ukrycia. Nawet jeśli techniczne możliwości do wprowadzenia tego pojawią się dopiero za 100 lat i faktycznie, w praktyce wszystko będzie miało wpływ dopiero na Twoich praprawnuków - nie znaczy, że mamy się na to zgodzić i przejść obojętnie, bo akurat dla nas nic lub niewiele się zmieni. To czego się obawiam - a już poniekąd wspomniane było przez kilka osób - to że skutki będą najbardziej odczuwalne dla zwykłego szarego człowieka, który podobające mu się zdjęcie wrzucił na facebook czy nk, by pokazać znajomym, albo na YouTube wgrał "cover" (karaoke) chronionego utworu. Bo akurat prawdziwi piraci, ludzie zajmujący się tym na dużą skalę wiedzą jak wszystko poukrywać, zaszyfrować itd. itp. A druga rzecz to taka, że określone lobby zyskujące na tym najwięcej mogą chcieć iść za ciosem i wprowadzać coraz to kolejne dalej idące obostrzenia i sposoby kontroli. Mam nadzieję, że nigdy - ani dziś, ani za tysiąc lat - nikt nie posunie się za daleko.

To jest PCRE (Perl-Compatible Regular Expressions) i w kodzie brakowało ograniczników (delimiters). Więcej: http://pl.php.net/ma....delimiters.php Jeśli faktycznie dana fraza ma się zaczynać od "http", to tak jak napisał regdos #^http# (ja zazwyczaj używam krzyżyka). Jeśli natomiast "http" może występować gdziekolwiek - na początku, na końcu, wewnątrz przeszukiwanej frazy - to bez daszka ^, czyli tylko z dowolonymi ogranicznikami #http# /http/ ^http^ itp.

Gratuluję. : ) Niech się rozwija. : ) Ja nie rozbudowuję swojego poza publicznie dostępny monitoring niektórych hostingów współdzielonych / shared. No, dodałem monitorowanie niektórych usługodawców DNS, ale nie upubliczniłem jeszcze żadnego z nich, ciężko mi idzie wprowadzanie czegokolwiek nowego. : )

Pracuj bezpośrednio z wiersza poleceń. To najszybszy i najwydajniejszy sposób. Niech no sobie przypomnę jak to szło... Załóżmy, że masz folder xampp bezpośrednio na C: i nazwa użytkownika bazy danych to "root". c:\xampp\mysql\bin\mysql -uroot use NazwaBazyDanych source c:\plik.sql exit Jeśli pojedyncze zapytania w Twoim zrzucie bazy danych są duże (powyżej 1MB) możesz napotkać problem wymagający zmiany ustawień w pliku xampp\mysql\bin\my.cnf albo my.ini (już nie pamiętam dokładnie) w linijce dotyczącej max_allowed_packet, bo wartość domyślna (przynajmniej u mnie) była 1M.

Tak ściśle mówiąc to nie ma teraz "kierunkowych", zawsze (w przypadku połączeń krajowych) wklepujemy 9 cyfr, ale owszem, 91 ******* to numery stacjonarne w Szczecinie i okolicach (spore okolice, obszar dawnego województwa Szczecińskiego, jak było jeszcze 49 województw).

Można mieć najczystsze intencje, jak najbardziej profesjonalne podejście, ale realia tego świata są takie, że osoby oszukujące spotkać można na każdym rogu ulicy. I niestety to powoduje, że stajemy się podejrzliwi wobec wszystkich wokół. Niestety. Skala podejrzliwości będzie oczywiście zalezna od charakteru danego człowieka (czy jest ufny czy podejrzliwy itd.) oraz od tego ile razy do tej pory w swoim życiu "się nadział" (osobiście bądź wśród rodziny/znajomych doświadczył oszustw). Na to się nic nie poradzi i można tylko robić swoje przykładając się jak najlepiej, jeśli działa się faktycznie w pełni uczciwie i rzetelnie. To już niestety taka przypadłość tego świata i ludzkości, obecna w szczególności tam, gdzie pojawia się polityka i/lub pieniądze.

Dziś od ok. 14:00 do ok. 14:18. (serwer k5 dłużej). Wczoraj od ok. 02:48 do ok. 03:18. @eRIZ: Problemów w godzinach popołudniowych NIE zauważyłem. Wcześniej po pierwszej rano 12-ego stycznia (ok. 16-18 minut). Poza tym ze 3 (wczoraj i dziś) krótsze przerwy w zakresie 1-2 minut. Informacyjnie.

@ hostit.pl Masz 100% racji. Jednak ja wychwyciłem ważniejsze słowa Mariusza: Jeśli faktycznie o tym nie informują (albo informują "drobnym drukiem na sto dwudziestej czwartej stronie specyfikacji usług", czyli tam gdzie praktycznie nikt nie zajrzy) to tylko i wyłącznie w tym widzę problem, w braku pełnej informacji dotyczącej usługi przedstawionej klientowi PRZED zakupem przez niego tej usługi. Sam limit jest zrozumiały jak dla mnie. To nie dotyczy tylko ilości plików, ale wielu innych limitów, w szczególności (ale nie tylko!) w ofertach "bez limitu", gdzie niby to się ma nieograniczony dysk, transfer, a dopiero po czasie okazuje się, że to wszystko jest "z zastrzeżeniem", którego to zastrzeżenia próżno szukać w dostępnej publicznie dokumentacji, wychodzi to dopiero "w praniu", gdy klient zgłaszając problem do supportu dowiaduje się o - zupełnie nieznanych dla niego do tej pory - limitach.

Ja sprawdzałem ze Szczecina (od siebie) i z Niemiec (za pomocą web-sniffer.net) - 91.210.242.160 nie był dostępny. Zatem coś gdzieś na łączach w świat przez ok. 50 minut pomiędzy ok. 11:24 i ok. 12:14 było nie tak. Tak tylko w celach informacyjnych.

Jak dla mnie... - Przed planowaną zmianą wybieram dla domeny takie serwery nazw, które będą działać i nad którymi będę miał kontrolę przez cały czas trwania migracji pomiędzy serwerami (przed, w trakcie, po zmianach). Mogą być one z zewnętrznego serwisu lub w ramach posiadanych przez siebie zasobów. Wprowadzam na nich wszystkie dotychczas istniejące rekordy i - jeśli są to inne serwery nazw niż dotychczas używane - ustawiam je jako autorytatywne dla domeny co najmniej 2 dni przed zaplanowaną migracją (ale nic nie szkodzi by dać większy margines, by nigdzie jakiś zapomniany cache nie pozostał). - Zmniejszam TTL dla wszystkich rekordów do najmniejszej rozsądnej wartości (1 sekunda jest nierozsądna, ale np. 300 sekund wydaje się być OK). Musi to być zrobione odpowiednio wcześniej - jeśli np. dotychczasowe TTL'e miały wartość 86400 to co najmniej 24 godziny przed migracją (ale nic nie szkodzi by dać większy margines, by nigdzie jakiś zapomniany cache nie pozostał). - W momencie migracji zmieniam wszystkie potrzebne rekordy A, CNAME i co tam jeszcze konieczne na używanych w obecnej chwili serwerach nazw. NIE zmieniam samych serwerów nazw przypisanych do domeny, ani też adresów tychże serwerów nazw. Migracja zajmuje więc tylko te 5 minut, jeśli TTL'e były ustawione na 300. - Jeśli wszystko działa, mogę wydłużyć TTL'e. Jeśli to konieczne mogę zmienić serwery nazw uzywane dla domeny. Kluczowym dla mnie jest: - jeśli muszę zmienić serwery nazw to upewniam się, by wszystkie rekordy na starych i nowych były identyczne i aby wszystkie (i stare i nowe) działały poprawnie przez 2-3 dni od momentu zmiany (nie wyłączam starych dopóki zmiany nie rozejdą się wszędzie), w ten sposób zmiana jest kompletnie transparentna i nie powoduje żadnych komplikacji; - jeśli zmianiam lokalizację /adres IP domeny, to robię to tylko poprzez zmianę rekordów A/CNAME, a nie poprzez zmianę serwerów nazw, w ten sposób zmiana trwa tylko czas ustawiony w TTL dla tych rekordów, który może być bardzo krótki (nad czasem propagacji zmian serwerów nazw nie mam kontroli, może to zająć nawet 24 godziny albo i dłużej dla niektórych zakątków internetu w "niesprzyjających warunkach"). Jednakże w każdym konkretnym przypadku może to wyglądać trochę inaczej. Przykładowo w przypadku drakera można to uprościć. Co najmniej 24 godziny przed migracją zmniejszyłbym TTL dla rekordów A na np. 300 (5 minut). A w momencie migracji natomiast poza zmianą serwerów nazw u rejestratora domeny zaktualizowałbym rekordy A na nowe IP na obydwu - i starym i nowym - BIND'ach, w ten sposób klienci obojętnie na który serwer nazw by trafili w momencie propagacji zmian DNS, kierowani byliby na to samo nowe IP. (Pomijam kwestię kłopotów z "secondary", to osobny nieprzewidziany przez niego niuans, wystarczyło zmieniać serial SOA - co zazwyczaj większość osób robi - by ns.kimsufi.com się prawidłowo zaktualizował.)

Sprzedaż poprzedniego hostingu Pana Miodka wyszła hostingowi tylko na dobre, w tej chwili pod pieczą Kylosa złego słowa powiedzieć nie można. Jeśli i w tym przypadku jakaś większa firma by to przejęła pod siebie, to na dobre dla klientów (tych co jeszcze zostali).

Hostingów darmowych - lepszych lub gorszych - znajdziesz sporo. W jednym z tematów nawet wymieniałem już te moim zdaniem warte trochę większej uwagi (przynajmniej dla małych, niewymagających stron, np. byethost, 000webhost itp., a z polskich z doklejonymi reklamami CBA). W domenę natomiast polecałbym zainwestować, bo o ile hosting jest zmienić łatwo w razie potrzeby nie tracąc przy tym odwiedzających, to zmiana adresu (domeny) już się na odwiedzających odbije. Jeśli mówimy o *.pl to za pierwszy rok to ok. 12zł, za drugi i kolejny ok. 50zł u najtańszych rejestratorów. W az.pl była (i może nadal jest) promocja co do domeny za 0zł na pierwszy rok bez konieczności pozostania tam na drugi rok, ale co do tego się upewnij, bo w razie czego za drugi rok już płaciłbyś tam ponad 120zł. Istnieją też firmy/osoby, które są gotowe zasponsorować ciekawe projekty, ale faktycznie ciekawe i obiecujące projekty wnoszące coś swoją jakością lub pomysłowością, a nie ot tak każdego.

Moim zdaniem: opcja A) - na starym serwerze zaktualizować można było wszystkie rekordy, by domena kierowana była na nowy adres IP; opcja B ) sugerowana przez Miłosza - wyłączyć stary serwer DNS, wtedy przy niedostępności (starego) "ns1" zapytanie pójdzie do "ns2" (ns.kimsufi.com), który już ma poprawne dane. Poza tym tak na przyszłość to odpowiednio wcześniej przed taką zmianą adresacji pozmniejszaj sobie wszelkie możliwe TTL'e do rozsądnego minimum, by przyspieszyć choć trochę takie procesy. Zmiana zrobiona w sposób właściwy z odpowiednimi wcześniejszymi przygotowaniami do tego może być dokonana w ciągu minut.

W przypadku błędów 500 - posprawdzajcie swoje pliki .htaccess. Coś zmieniło się w konfiguracji, bo jak dla mnie od dziś dnia "Options +FollowSymLinks" powoduje błąd 500 właśnie, mimo iż poprzednio grało.

Powtórzę, bo chyba nie przeczytano mojej edycji. Dla modbase.pl sprawa załatwiona. Popraw serial SOA dla taniograj.pl. Wygląda na to, że ns.kimsufi.com sprawdza serial SOA. Jeśli pozostaje bez zmian - nie aktualizuje wpisów. Przy każdej zmianie zmień SOA, by ns.kimsufi.com się zaktualizował.

No to sprawa prosta - ns.kimsufi.com ma wciąż stare wpisy. Postaraj się, by zaktualizowane zostały na nim na nowe. Edycja: Dla modbase.pl sprawa załatwiona. Popraw serial SOA dla taniograj.pl. Wygląda na to, że ns.kimsufi.com sprawdza serial SOA. Jeśli pozostaje bez zmian - nie aktualizuje wpisów. Przy każdej zmianie zmień SOA, by ns.kimsufi.com się zaktualizował.

taniograj.pl Według whois kieruje na ks200894.kimsufi.com i ns.kimsufi.com (ostatnia zmiana 30 grudnia) ks200894.kimsufi.com kieruje domenę na 91.121.114.25 ns.kimsufi.com kieruje domenę na 176.31.108.171 Problem? Różne rekordy na obydwu używanych serwerach nazw. SOA na ns.kimsufi.com sugeruje użycie ks392018.kimsufi.com jako primary, i może tu tkwi błąd? modbase.pl Według whois kieruje na ns2.hans.hosteurope.de i lvps46-163-76-120.dedicated.hosteurope.de (ostatnia zmiana dziś o 16:08). lvps46-163-76-120.dedicated.hosteurope.de kieruje domenę na 46.163.76.120 ns2.hans.hosteurope.de nic o domenie nie wie Jednakże widnieją w sieci jeszcze wpisy wcześniejsze kierujące domenę na ks200894.kimsufi.com i ns.kimsufi.com ks200894.kimsufi.com kieruje domenę na 91.121.114.25 ns.kimsufi.com kieruje domenę na 176.31.108.171 Problem? Jesli to ma być na hosteurope.de, to zadbaj by ns2.hans miał informację o domenie. Jeśli problem był z kimsufi, to identycznie jak dla taniograj.

Ja bym powiedział tak: Zależy do jakich odbiorców chcesz trafić. Jeśli głównie do polskiego społeczeństwa, to .pl, jeśli natomiast prowadzisz głównie kontakty międzynarodowe i chcesz mieć adres łatwy dla nich do zapamiętania, to .com. @ romix Przecież nie chodzi konkretnie o nazwisko.pl / nazwisko.com, a o jego prawdziwe nazwisko - znasz je?...

Tak dla śmiechu trochę... Zaskoczyła mnie jedna rzecz - jeśli chodzi o wsteczną kompatybilność z "dinozaurami" wśród przeglądarek. Na IE6 (najnowsza aktualizacja rok 2004) strona wygląda lepiej (bardziej poprawnie, choć też z błędami) niż na Fx3.0 (najnowsza aktualizacja rok 2008). ; D Sądziłem, że będzie odwrotnie. ; D Opera zdaje się to w miarę poprawnie chwytać od wersji 9.80 w górę. Ale to chyba skutek zastosowania: <!--[if IE]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]--> Starszym Firefox'om chyba też by się taki javascript przydał. Choć nie wiem jak wiele osób ich używa. Zapewne jestem jadnym z niewielu wyjątków co do używania Fx3.0. Ale jak patrzę na to ile pamięci potrzebują nowsze wersje przeglądarek... mój komputer by nie wydolił, pagefile.sys non stop w użyciu by był.

Teorie spiskowe, powiadasz... : ) Nawet jeśli taka blokada dostępu dla mnie (albo przynajmniej niechęć zdjęcia blokady nałożonej automatycznie) spowodowana byłaby celowym zamiarem ukrycia faktycznej, nie najlepszej dostępności do usług serwera, to i tak nikt tego nigdy się nie dowie. Podkreślam: "nawet jeśli" - ot, tylko taka sobie hipoteza bez żadnego potwierdzenia, stworzona pod wpływem stwierdzenia "teorie spiskowe". ; ) Niestety nie przywrócę monitoringu serwerów s2 i s5 ze swojej strony. Prawdopodobnie też nie rozszerzę monitoringu na inne (istniejące obecnie lub przyszłe) serwery tego hostingu. Podążając za odpowiedzią, jaką uzyskałem z BOK MasterNET.pl, odniosłem wrażenie, że "ciągłe notoryczne odpytywanie usług (...), zaśmiecanie logów" i tym podobne sprawy przeszkadzają administracji hostingu (jest to jedno zapytanie poprzez HTTP i jedno poprzez FTP do każdego z serwerów raz na dwie minuty). Ponadto w ich ocenie nie służy to bezpośrednio klientom hostingu - z tym akurat stwierdzeniem nie do końca się zgadzam, przecież po to właśnie wyniki mojego monitoringu udostępniam publicznie dla każdego (obecnego i potencjalnego przyszłego) klienta, ale oczywiście każdy ma własne zdanie na temat użyteczności takich monitoringów. Uzyskałem też informację, że każdy klient MasterNET.pl posiadający usługę serwera wirtualnego ma możliwość monitorowania dostępności usług dzięki specjalnej nowo udostępnionej przez sam hosting funkcji. Sam ze swojej strony jednak bardziej polecałbym zewnętrznych usługodawców. Jeden z klientów mógłby dla przykładu uruchomić monitoring ze strony np. pingdom.com lub jakiegokolwiek innego usługodawcy (mam nadzieję, że Ci nie będą blokowani) dla swojej strony i udostępnić wyniki publicznie, w ten sposób wszyscy klienci mogą korzystać z jednego monitora, zamiast uruchamiać dziesiątki czy setki monitoringów, każdy dla własnej strony prywatnie, i odpytywać serwer bardziej intensywnie niż jeden monitoring z publicznie dostępnymi wynikami.

Owszem, * * * * * uruchomi wszystko co minutę. Możesz więc dać 0 * * * * - wtedy będzie o każdej pełnej godzinie, lub 25 * * * * - wówczas 25 minut po każdej pełnej godzinie itd.

Nie wiem czy Pan Adrian ma coś z tym wspólnego ani czy o tym wie. Od tamtego dnia - 22-ego lutego 2011 - IP mojej maszyny monitorującej jest zbanowane na serwerze s2/ns2 Masternetu. Prawdopodobnie z automatu (czasem tak się dzieje w przypadku mojego monitoringu, niektóre hostingi musiały dodać moje IP do "whitelisty", moje połączenia nie są w żaden sposób szkodliwe, jednak tak mogą być przez różne automatyczne firewall'e postrzegane - w zależności od bardziej lub mniej restrykcyjnych ustawień), choć oczywiście bez wyjaśnienia sytuacji nie mogę być pewien. Jakiś czas później nastąpiła podobna blokada na s5, jednak tam nie na IP, a na frazę w wysyłanym przeze mnie nagłówku HTTP_USER_AGENT (mój monitor się przedstawia w ten sposób). Ja ze swojej strony nigdy tego problemu do Masternetu nie zgłaszałem ze względu na znikomą ilość osób odwiedzających mój serwis w tamtym czasie (jak i po części inne sprawy po mojej stronie zupełnie nie związane z tym ani z jakimkolwiek innym hostingiem). Wszystkie osoby, które jednak z mojego serwisu monitorującego korzystają - przepraszam. Powinienem był postarać się o to, by monitoring wznowić lub przynajmniej sprawę wyjaśnić.