kafi

Być może. Jeśli serwer hostingodawcy będzie w Polsce, a użytkownik końcowy ma do niego bezpośrednie przyłącze, to może paręnaście milisekund szybciej dostanie odwzorowanie. Ale jeśli serwer owej firmy hostingowej też jest w OVH to różnica z tego żadna Tak. I właśnie dlatego bardziej zalecane jest podanie adresów NS firmy hostingowej, bo wtedy ona tą strefą zarządza. A nie zapominaj, że w większości nie wykupujesz sobie stałych adresów IP, więc nie masz gwarancji, że on się nie zmieni... no i będzie płacz, że firma hostingowa zepsuła bo strona mi się nie wyświetla Takie na koniec uproszczone podsumowanie dróg, jakie musi wykonać DNS w celu odnalezienia odwzorowania dla domeny www.example.pl w owych dwóch przypadkach: 1. Klient DNS zwraca się do swojego resolvera z zapytaniem, jaki jest adres dla www.example.pl. 2. Resolver DNS nie wie, więc pyta root-serverów DNS, na jakimż to serwerze można znaleźć domenę pl. Dostaje odpowiedź, że root-serverem dla tej TLD jest a-dns.pl o adresie IP 195.187.245.44 3. Resolver DNS pyta serwer a-dns.pl, czy wie, pod jakim adresem IP jest www.example.pl. a-dns.pl nie wie adresu IP, ale sugeruje, że autorytatywnym serwerem dla example.pl jest serwer [ns.cos.pl] o adresie ip [1.2.3.4] 4. Resolver pyta owego [ns.cos.pl] czy wie, jaki jest adres IP dla www.example.pl. Jako, że owy "coś" wie, to zwraca rekord A z adresem IP www.example.pl 5. Resolver zwraca owy adres klientowi. I teraz, czy w miejscu [ns.cos.pl] będzie adres DNS usługodawcy hostingowego, czy rejestratora domen, to raczej mechanizm zwracania odpowiedzi jest dokładnie ten sam i nie ma tu żadnych dodatkowych dziwnych przekierowań.

To po grzyba produkować moduł o nazwie opinie, skoro jakiś złośliwy szkodnik hipotetycznie może 90% firm tak objechać i przez to dokleić im notkę, że opinie o nich są prawdopodobnie manipulowane? A jeśli napisze, że się wyniósł... to cóż, opisałem to wcześniej: można odpytać nameservery owego hostingodawcy i zerknąć, czy odpowiadają na taką podaną domenę itp. Ale tak naprawdę, to przeczytaj sobie tak kilka razy pierwsze zdanie moich dwóch poprzednich wypowiedzi

Tak jak napisałem na poprzedniej stronie - zbieranie opinii od informatyków-Polaków najmniejszego sensu nie ma. Bo jeśli nawet ktoś poda owe imię, nazwisko i nazwę konta, to co z tego, skoro firma X może sobie spreparować to sama robiąc foreach po tabelce dot. klientów obsługiwanej przez swój panel billingowy. Sami użytkownicy też święci nie będą, bo byli już tu tacy bardzo ciekawi użytkownicy, którzy bez przerwy czarny PijaR uprawiali w stosunku do firmy, której przestało się chcieć iść im dalej na rękę. Jedynym jakimkolwiek choć trochę weryfikowalnym systemem było by podanie obowiązkowo adresu www (w przypadku hostingu), bądź adresu IP w przypadku usług rootvps/dedyk. Wtedy brygada moderująca mogła by na szybko zweryfikować, czy to, co użytkownik biadoli to prawda, czy też np. użytkownikowi ISP wyciął jakieś klasy adresowe A co do tego, czy stronę przeniósł - to póki konto z serwera skasowane nie zostanie, to jakieś tam ślady po niej pozostaną (wpisy w serwerach DNS hostingodawcy, sama strona dostępna po wykonaniu statycznych mapowań, itp.).

xen hvm != kvm-qemu Chociaż powiem szczerze, że kvm-qemu (gdy to jakiś czas temu testowałem) to zbyt stabilne to nie było. Instalując np. Windowsa można było zawiesić całą maszynę-hosta, więc nie dziwie się, że mało kto będzie ryzykował z dostarczaniem tak niestabilnej usługi.

A wpadłeś na pomysł "kopnięcia" serialu w rekordzie SOA?

Co to znaczy "przekierowuje rekord A na ip" ? Tu nie ma żadnych przekierowań. Po prostu serwer zwraca podany rekord A (a w nim jakieś tam ip) i nic nie przekierowuje.

A co to za różnica, czy odpytasz w poszukiwaniu rekordu A nsy OVH, czy też nsy providera? Przecież oba zwrócą ci bez większych ceregieli wpisany tam adres IP. Różnica tylko taka, że jeśli linuxpl zachce się zmiany adresów IP (chociażby migrując konto na inny serwer), to przy delegacji domeny na ichsze serwery to hostmasterzy zadbają o to, aby się zaktualizowały. Jak trzymasz dnsy gdzieś indziej, to ten adres musisz aktualizować samemu.

Zasięg Polkomtela

Jakiekolwiek zbieranie opinii od informatyków nie ma najmniejszego sensu. Podawanie danych osobowych - to dla takiej firmy X to co to jest wyciągnąć dane klientów z panelu billingowego i powystawiać opinie (nawet "klikając" w odnośnik który klientowi do mboxa/maildira przyjdzie). Z drugiej strony, to i klient może wejść na stronę sklepu XYZ, który po sprawdzeniu jest na danym hostingu i wystawić arcyciekawą opinię w imieniu owego sklepu. Weryfikacja na podstawie kont - to co za problem założyć sto kont widm? Takie moje luźne przemyślenia: ja bym dał obowiązkowe podanie adresu serwisu www (w przypadku hostingu) lub adresu IP (w przypadku żalenia się na serwery vps/dedykowane). Pozwoli to w miarę precyzyjnie określić owemu weryfikatorowi, czy treść opinii z grubsza odzwierciedla rzeczywiste warunki. Reszta to raczej będzie tylko zbędnym formalizmem nikomu nie przydatnym.

Tak na szybkiego - w logach powtarza ci się dosyć często wpis May 17 20:45:47 netdc-pl kernel: [81436.836084] tg3 0000:02:01.0: firmware: requesting tigon/tg3_tso.bin May 17 20:45:47 netdc-pl kernel: [81436.847893] eth0: Failed to load firmware "tigon/tg3_tso.bin" May 17 20:45:47 netdc-pl kernel: [81436.847989] eth0: TSO capability disabled. May 17 20:45:47 netdc-pl kernel: [81436.897730] ADDRCONF(NETDEV_UP): eth0: link is not ready Co może oznaczać, że masz jakiś trefny sterownik do sieciówki, który się może wywalać, stąd też owe błędy w obsłudze stosu TCP.

Pierwsza rzecz, to wynik polecenia traceroute podczas gdy ci serwer nie działa. Druga - sprawdź z innego hosta (czyt. podpiętego do zupełnie innego ISP) czy też nie działa. Wykluczysz tym winę po stronie swojej, swojego komputera i swojego łącza internetowego. Kolejną sprawą jest przejrzenie sobie logów ( /var/log/messages i /var/log/syslog ) czy tam nie ma jakichś dziwnych zwieszek interfejsów. No i pytanie, czy na owym serwerze nie działa jakiś firewall, który coś tam gdzieś tam blokuje.

Tak.

Tak jak pisałem - jak przydzielisz IP do serwera-hosta, to nie przydzielisz do vpsa. Wyrzuć to auto eth0:1 iface eth0:1 inet static address 89.231.6.15 netmask 255.255.255.0 Potem zrestartuj sieć ( /etc/init.d/networking restart ) a potem zrestartuj serwer vps.

Ty wogóle myślisz waść, co robisz?

Poleceniem ifconfig.

inet 89.231.6.15/24 brd 89.231.6.255 scope global secondary eth0:1 I to jest zapewne IP, które chcesz przydzielać owemu VPSowi. Usuń to eth0:1, a następnie zrestartuj kontener przez vzctl, to powinno zadziałać* * chyba, że hostem dla tej konfiguracji nie jest fizyczna maszyna, a np. VMware. Wtedy to, nie mając dostępu do konfiguracji vmnet wirtualizacji OpenVZ się nie odpali.

IP trzeba pewnie mieć. Ale mądrzy ludzie wymyślili coś takiego, jak prywatne, nierutowalne klasy adresowe. Wymyślili także coś takiego jak translacje adresów, zarówno źródłowe jak i docelowe. Więc w teorii mając jeden publiczny adres IP da się postawić wiele maszyn wirtualnych; z tym, że komfort czegoś takiego będzie praktycznie zerowy, bo jak ktoś chce się bawić z dwukropkami w adresach, to przecież może i wszystko postawić bezpośrednio na maszynie-hoście. A problem autora polega pewnie na tym, że on to IP ma podpięte do interfejsu sieciowego serwera, a do tego ustawione jako IP kontenera; a tak to raczej nie zadziała.

No to sorry, postaw sobie farmę serwerów rozproszonych geograficznie (jednym tego nie wyślesz, bo się dość szybko zatka na RBLach jako spam). Do tego ciągłe monitorowanie owych list, użeranie się z NOCami i abusami hosterów pocztowych, itp. Ciekawe, czy za miskę ryżu uda ci się to spreparować...

To, co siedzi w bazie REGON to wiodąca działalność. Jeśli ktoś dopisał sobie do Ewidencji Działalności Gospodarczej także inne PKD, to problemu w teorii nie ma. Ale w praktyce to kupowanie usług hostingowych od np. zakładu pogrzebowego [mimo, że inne pkd też mają dopisane] śmierdzi z daleka i aż prosi się o jakąś profilaktyczną kontrolę ;] szczególnie w jakichś instytucjach finansowanych z budżetu.

Pierwsza sprawa - nie tworzysz tu serwera slave bo i po co. Druga sprawa - powerdns nie za bardzo lubi działać na wielu adresach IP. Problem objawia się w tym, że wszystkie odpowiedzi wychodzą głównym interfejsem sieciowym, z adresem SourceIP ustawionym na adres główny serwera. Czyli taki schemat komunikacji: klient -> DNS QUERY --1.2.3.4--> pdns --4.3.2.1--> DNS ANSWER -> klient Wówczas jeśli klient odbierze taką odpowiedź z innego adresu SourceIP niż ten, na który wysyłał żądanie, to traktuje to jako SpoofDNS i filtruje. Jak już chcesz bardzo mieć PDNS ze względu na łatwość zarządzania poprzez backend MySQL, to pozostanie ci albo kombinacja z odpaleniem dwóch instancji z dwoma plikami konfiguracyjnymi, albo dosyć nietypowo - czyli postawić go na loopbacku albo prywatnym IP, a na frontendzie postawić Binda działającego jako proxy-dns.

Przeczytaj ze zrozumieniem komunikat błędu, który wkleiłeś. Potem przeczytaj taką ramkę, która jest pod polem do edycji sygnatury. Jak zastosujesz się do tych wytycznych, to podpis zmienisz bezproblemowo. ( SOA#1 - u mnie działa )

Sfrustrowany brakiem działania usługi być możesz. Publikować opinie oczywiście też możesz. Z tym, że z łaski swojej - jak już ją chcesz opublikować, to skup się na tym, a nie co godzinę doklejasz nowego posta z jednym zdaniem jaka to firma jest jeszcze bardziej bebe niż była wcześniej, chyba tylko po to, aby jeszcze bardziej firmie owej zrobić na złość, co by temat był ciągle na topie.

A ktoś ci gwarantuje pingi? Ktoś ci gwarantuje polską lokalizację? Ponawiam - jeśli to, co zostało w regulaminie zdefiniowane, się zmieni, to i owszem. A wszelkie "polubowne" dziwactwa to tylko dobra wola takowej firmy. Ale myślę, że tych, którzy mieli w umowie wpisaną lokalizację ATM S.A. Warszawa Grochowska, średnią latencję z łącz polskich operatorów nie większą niż 50 ms. i inne dziwne gwarantowane umownie parametry, to ten temat nie dotyczy, bo pewnie dostaną propozycję migracji i jeśli się zgodzą to się zgodzą, a jeśli się nie zgodzą, to zostaną tam gdzie są. Tylko, że pewnie za gwarancje lokalizacji, latencji, itp. rzeczy to trzeba dodatkowo dopłacić

Przepychając się słownie Inne osoby dbające o korporacyjne łebsajty także jakoś umieją takie sprawy rozwiązywać szybko, i skoro już wcześniej były takie problemy z kontaktem, awariami itp. to twoja wina, żeś nie podjął działań przeniesienia tego na bardziej stabilną platformę. A ty zamiast monitorować działanie serwisu, to czekasz na, jak to nazwałeś, OPR od współpracowników i biadolisz. Więc można by rzec, że poziom operatywności macie podobny.

Podaj podstawę prawną. Czy gdzieś ktoś ci gwarantował, że twój IP to będzie w.x.y.z, albo że maszyna, na której stoisz siedzi w DC Atmana w pokoju 123, szafie A.13, module 4U? Jeśli nie, to póki usługa działa tak, jak została opisana w regulaminie, to może być i nawet umieszczona w Zimbabwe.