kafi

Faktycznie, jeśli masz wszystkie adresy w jednej podsieci to ten link nie będzie za bardzo przydatny. Żeby zrobić to, co chcesz, to musisz wykorzystać moduł owner i połączenia wychodzące od określonych użytkowników systemowych SNAT-ować na dedykowane im adresy IP. Wtedy decydował byś o adresie wyjściowym uruchamiając skrypt/program z uprawnieniami określonego użytkownika.

http://blog.khax.net/2009/11/28/multi-gateway-routing-with-iptables-and-iproute2/

Jak chcesz skonfigurować tam uprawnienia, aby klient końcowy widział tickety zgłoszone tylko przez niego, a servicedesk zgodnie ze swoją hierarchią poziomów? Jeśli miało by to być coś bugtrackowego, to może flyspray (założenia podobne, ale napisany w php, więc nie trzeba do tego wielkiej dedykowanej kobyły stawiać (jira swoje żre ). Jeśli coś tyci bardziej kobylastego ale jeszcze znośnego to może OTRS.

Robisz pingi ICMP czy UDP?

No to łącz się przez ten pulpit zdalny przez Google Chrome skoro wiesz, że to jest możliwe... W czym niby problem ? Dowcip jest taki, że ty raczej nie mówisz o pulpicie zdalnym Połączenie przez konsolę vSphere / webowy interfejs vCenter jest z punktu widzenia wirtualnej maszyny tak, jak byś dopiął się lokalnym monitorem, klawiaturą i myszką do niej. Stąd też jeśli nawet zrealizujesz wielodostęp z jego poziomu to każdy będzie widział ten sam obraz "lokalnej konsoli".

W tej nomenklaturze konsola oznacza lokalny terminal użytkownika (monitor, klawiatura, mysz dopięta do komputera z uruchomionym systemem). Więc jeśli podłączysz się usługami pulpitu zdalnego to nie bardzo to co chcesz osiągnąć ma sens.

Jak by poprosił PRZED rozbiciem ekranu, to nie dyskutował bym, że mu to przysługuje. Ale w OBECNEJ sytuacji to zarówno producent jak i sprzedawca stwierdzą "uszkodzenie mechaniczne" więc uprawnienia z tytułu gwarancji/obecnej niezgodności towaru z umową ciężko będzie od nich wyegzekwować. Pozostaje jedynie ubezpieczyciel którego to trzeba nękać.

Zrozum, że zlecającym naprawę nie jest sprzedawca albo producent. Jest firma ubezpieczeniowa. I to do niej wg sprzedawcy trzeba by się udać z "reklamacją" naprawy.

Nie do końca, bo... Ta naprawa była dokonana nie gwarancyjnie, tylko ubezpieczeniowo zgodnie z OWU. No i teraz sprzedawca może twierdzić, że to, że się jeszcze zawiesza to wynika z owego upadku a nie niezgodności z umową i niech udaje się na dodatkowe walki z ubezpieczycielem. PS: Naprawa w ramach ubezpieczenia niekoniecznie musi być realizowana w autoryzowanym serwisie / z użyciem oryginalnych części.

Upewnij się tylko, czy tak można. W moim przypadku umowa z Netią była hybrydowa (telefon+internet) i trzeba było wypowiedzieć ją całą - nie była możliwa rezygnacja tylko z internetu lub tylko z telefonu.

Można. Np. tutaj: http://dhosting.pl/oferta/domeny/rejestracja_nowych_tld.html albo tutaj: https://domeny.domena.pl/?action=nologged A kiedy będą .free to jeszcze nikt na 100% nie wie. Ale nastaw się na raczej koniec tego roku / pierwszą połowę następnego.

Można by rzec, że u mnie działa - zarówno odpytanie 194.204.159.1 jak i 194.204.152.34 zwraca poprawną odpowiedź, co z resztą zamieściłem powyżej. Z tym, że ja sprawdzałem z iDSL ale nie sądzę, żeby to tu był jakiś problem.

Może po prostu próbujesz to sprawdzać nie będąc w sieci TPNET? nslookup f748059cc1629061d7e4691c36f64c90.pl 194.204.159.1 Serwer: dns.tpsa.pl Address: 194.204.159.1 Nieautorytatywna odpowiedź: Nazwa: f748059cc1629061d7e4691c36f64c90.pl Addresses: 2001:1a68:b:4:250:56ff:fe89:830e 176.119.42.231

Patrząc na post #27 i ten powyższy nasuwa się spostrzeżenie, że albo p. Artur ma wybitną sklerozę i nie potrafi przypomnieć sobie komu przydzielił takowy rabat, (ma przecież do dyspozycji historię całego wątku) albo też nie jest to jednorazowa pomyłka tylko celowa polityka firmy (jak klient już tam po forach zacznie jęczeć to dać mu publiczne zapewnienia gruszek na wierzbie licząc, że po roku o tym zapomni).

Patrząc na stronie ICANN to dla domeny .free wpłynęło pięć aplikacji i jeszcze z tego, co widzę to nie ma informacji czy i któremu podmiotowi została ona powierzona. Wszystkie więc informacje są mocno szacunkowe i póki nie będzie magicznego "Delegated", to możemy się licytować czyjego PartnerRegistrara przecieki są właściwsze

Ciężko powiedzieć. Wejdą dopiero w okolicy grudnia, więc jeszcze sporo czasu minie na ustalanie tego. Jednak gdy będą darmowe, to reputację będą miały taką, jak obecnie domeny .tk - czyli śmieciową.

ajaxplorer

Zmień założenia. Adres dodatkowy (ip failover) przypisz do wirtualnej maszyny, a adres główny użyj do NAT trzech pozostałych. Będzie prościej. Żeby to zrobić, to: 1. Dodajesz wirtualny MAC http://pomoc.ovh.pl/DedykowaneMac 2. Tworzysz wtedy wirtualną maszynę w trybie bridged http://pomoc.ovh.pl/Proxmox#link3 (w zakładce Network podajesz adres MAC który utworzyłeś w punkcie 1) 3. A później konfigurujesz adres IP na maszynie zgodnie z instrukcją: http://pomoc.ovh.pl/BridgeClient

Nie da się* w prosty sposób mieć tego samego adresu IP przypisanego zarówno do hypervisora jak i maszyny wirtualnej. Najprościej ci będzie po prostu dokupić jeszcze jeden adres IP Failover, przypisać go do maszyny zgodnie z instrukcją i wtedy do tego failover podpiąć licencję. * - w wersji hardcore możesz próbować dopiąć na maszynie wirtualnej ten adres do interfejsu loopback z maską /32 i tak poprzestawiać tablicę routingu aby wychodzić adresem prywatnym a ten loopbackowy olewać. Z tym, że to rozwiązanie generuje dużo potencjalnych problemów z dostępnością sieci (w najgorszym przypadku odcięcie hypervisora od sieci) które bardzo trudno zdiagnozować.

Spróbuj. Authinfo samo z siebie się nie zmienia chyba.

To i ja potwierdzę - przez yandex api blacklistował wht.

Taka osoba zwie się abonentem, dzierżawcą itp. Ale nie właścielem. Właśnie częściowo przez takie potoczne nazewnictwo wychodzą kwiatki, bo ktoś zrozumie dosłownie tą relację własnoći A odnośnie meritum - pozostaje ci tylko spróbować użyć starego kodu authinfo licząc złudnie, że się nie zmienił i wytransferować domenę do takiego partnera, który ma tyci mniej procedur zmiany abonenta... No i liczyć, że stary "prawowity" nie wyskoczy ze sporem "NA JAKIEJ PODSTAWIE PARTNER ZMIENIŁ DANE ABONENTA" A na przyszłość to polecam spisywać jakieś formalne dokumenty - bo wbrew pozorom to "dupochron" dla obu stron. Dla kupującego - że delikwent nie zostanie wykiwany i np. ktoś nie złoży wniosku o przywrócenie abonenta;; dla sprzedającego - że kupujący nie odpali np. sklepu z narkotykami pod taką domeną. Bo jak myślicie, do kogo organy ścigania przybędą? Do tajemniczego kupującego, czy też do osoby będącej abonentem w registry? A jeśli nawet w registry będzie abonent a nie będzie dokumentu cesji, to może rżnąć głupa że on nic nie wiedział że jego dane się tam znalazły i nie ma z tym nic wspólnego

Archi, za przeproszeniem - pierdolisz bzdury. Kod authinfo w myśl regulaminu domen .pl pozwala na zmianę partnera obsługującego domenę. Technicznie w momencie transferu (domen .pl) kontakty przypisane do domeny się NIE ZMIENIAJĄ. Oczywiście nowy partner może (i raczej robi to żeby uniknąć burdelu w bazie danych) skopiować kontakt ze swoim handle, może go przy tym zmienić albo i nie - zależy to od jego polityki. Jednak zmiana da nych abonenta(przynajmniej w przypadku registry .pl) powinna być poparta jakimś dokumentem. W praktyce część partnerów nask chce go papierowo, część wymyśla jak to zrobić elektronicznie (ale z odpowiedniem regulaminem przenoszącym odpowiedzialność na klienta). Inna rzecz, że pisanie o jakiejkolwiek własności domeny to bzdury totalne. Bo nie jesteś właścicielem tylko abonentem. To tak, jak byś podpisał roczną umowę wynajmu mieszkania i nazywał się jego właścicielem Inaczej jest dla domen globalnych (com, net, org, biz, info, ...) - tam w momencie transferu podajesz nowy kontakt, bo stary się nie kopiuje.

Ależ oczywiście, że mógł... W momencie transferu domeny .pl ovh kopiuje stare kontakty umieszczone w Registry. Więc jeśli tam był stary abonent, no to został skopiowany właśnie on

Próbowałeś włączyć komputer z odpiętymi od płyty głównej wszystkimi urządzeniami SATA?