🚀 go-pugleaf

On 04/09/2011 12:24 PM, MC wrote:
> Przenoszę stronę do jednego dostawcy hostingu do drugiego. Chciałbym 
> zachować URL. Jak to się robi? 

Zasadniczo, żeby URLe zostały takie same, trzeba zadbać o domenę. Nie
może to być domena należąca do dostawcy hostingu (w stylu
mojsklep.superhosting.pl, tylko własna - mojsklep.pl).

Dostawca usługi hostingowej nie musi być tożsamy z firmą rejestrującą
domenę. Chociaż, jeśli to jakaś popularna firma, można się spodziewać,
że wszystko jest w pakiecie.

Od firmy, która rejestrowała domenę trzeba wydobyć tzw. "auth code" i
przekazać nowej firmie. Dzięki niemu firma, do której przenosi się
domenę, może ustanowić siebie jako nowego "opiekuna" domeny. Należy to
zrobić przed rozpoczęciem procesu destrukcji aktualnego hostingu.

Należy się również liczyć z tym, że podczas przenosin z jednego hostingu
na drugi będzie pewien okres (pewnie około doby), kiedy część świata
będzie kierowana na stary hosting, a część już na nowy. Ważne w
kontekście treści strony, ew. zamówień, czy poczty (jeśli hosting
zajmuje się i tym).

-- 
Marcin Szewczyk                       http://wodny.org
mailto:Marcin.Szewczyk@wodny.borg  <- remove b / usuń b
xmpp:wodny@ubuntu.pl                  xmpp:wodny@jabster.pl

Marcin Szewczyk <wodny@nospam.nowhere> wrote:
> Należy się również liczyć z tym, że podczas przenosin z jednego hostingu
> na drugi będzie pewien okres (pewnie około doby), kiedy część świata
> będzie kierowana na stary hosting, a część już na nowy. Ważne w
> kontekście treści strony, ew. zamówień, czy poczty (jeśli hosting
> zajmuje się i tym).

E-e, przy planowanych przenosinach to się bez problemu skraca
nawet do minuty.

p.

-- 
Beware of he who would deny you access to information, for in his
heart he dreams himself your master.   -- Commissioner Pravin Lal

On 04/10/2011 04:33 PM, Piotr KUCHARSKI wrote:
> Marcin Szewczyk <wodny@nospam.nowhere> wrote:
>> Należy się również liczyć z tym, że podczas przenosin z jednego hostingu
>> na drugi będzie pewien okres (pewnie około doby), kiedy część świata
>> będzie kierowana na stary hosting, a część już na nowy. Ważne w
>> kontekście treści strony, ew. zamówień, czy poczty (jeśli hosting
>> zajmuje się i tym).
> 
> E-e, przy planowanych przenosinach to się bez problemu skraca
> nawet do minuty.

Ale to chyba tylko, jeśli ma się wpływ na rekord SOA?

-- 
Marcin Szewczyk                       http://wodny.org
mailto:Marcin.Szewczyk@wodny.borg  <- remove b / usuń b
xmpp:wodny@ubuntu.pl                  xmpp:wodny@jabster.pl

W dniu 2011-04-10 16:49, Marcin Szewczyk pisze:
> On 04/10/2011 04:33 PM, Piotr KUCHARSKI wrote:
>> Marcin Szewczyk<wodny@nospam.nowhere>  wrote:
>>> Należy się również liczyć z tym, że podczas przenosin z jednego hostingu
>>> na drugi będzie pewien okres (pewnie około doby), kiedy część świata
>>> będzie kierowana na stary hosting, a część już na nowy. Ważne w
>>> kontekście treści strony, ew. zamówień, czy poczty (jeśli hosting
>>> zajmuje się i tym).
>>
>> E-e, przy planowanych przenosinach to się bez problemu skraca
>> nawet do minuty.
>
> Ale to chyba tylko, jeśli ma się wpływ na rekord SOA?

tak, ale to dość łatwo zrobić, nawet jak nie masz wpływu:

1. ustawiasz domenę u siebie, ustawiasz rekord A na stare IP.
2. ustawiasz TTL u siebie na 1 minutę
3. zmieniasz DNSy na swoje (ale cały czas wskazują na "stareIP"
4. czekasz ponad dobę, żeby wszyscy widzieli twoje DNSy
5. zmieniasz IP u siebie w pliku strefy na nowe - twoje

6. i tak dla części serwerów się nie uda, bo np. dns2.tpnet.pl olewa 
ustawione TTLe a działa tam chmura, zatem czasem odpowiedzi są poprawne 
od razu, a czasem nie :-), takich serwerów jest więcej.

Niemniej na chwilę obecną i tak nie ma lepszego sposobu.

Wojtek

-- 
polecam stronę: www.nartyrowery.pl
największy sklep ze sprzętem narciarskim i snowboardowym

On 10.04.2011 21:06, crazy bejbi wrote:
> W dniu 2011-04-10 16:49, Marcin Szewczyk pisze:
>> On 04/10/2011 04:33 PM, Piotr KUCHARSKI wrote:
>>> Marcin Szewczyk<wodny@nospam.nowhere>  wrote:
>>>> Należy się również liczyć z tym, że podczas przenosin z jednego
>>>> hostingu
>>>> na drugi będzie pewien okres (pewnie około doby), kiedy część świata
>>>> będzie kierowana na stary hosting, a część już na nowy. Ważne w
>>>> kontekście treści strony, ew. zamówień, czy poczty (jeśli hosting
>>>> zajmuje się i tym).
>>>
>>> E-e, przy planowanych przenosinach to się bez problemu skraca
>>> nawet do minuty.
>>
>> Ale to chyba tylko, jeśli ma się wpływ na rekord SOA?
> 
> tak, ale to dość łatwo zrobić, nawet jak nie masz wpływu:
> 
> 1. ustawiasz domenę u siebie, ustawiasz rekord A na stare IP.
> 2. ustawiasz TTL u siebie na 1 minutę
> 3. zmieniasz DNSy na swoje (ale cały czas wskazują na "stareIP"
> 4. czekasz ponad dobę, żeby wszyscy widzieli twoje DNSy
> 5. zmieniasz IP u siebie w pliku strefy na nowe - twoje
> 
> 6. i tak dla części serwerów się nie uda, bo np. dns2.tpnet.pl olewa
> ustawione TTLe a działa tam chmura, zatem czasem odpowiedzi są poprawne
> od razu, a czasem nie :-), takich serwerów jest więcej.

Jeśli w nowym miejscu masz też inny adres, co jest korzystne w takim
przypadku:

1. Konfigurujesz nowy hosting pod swoją domenę.
2. Wyłączasz na chwilę, żeby przegrać dane.
3. Na starym hostingu dajesz przekierowanie na nowy hosting.
4. Zmieniasz strefę.

Problem gdy strona jest dynamiczna i np trzeba przegrać 3GB danych. To
musi chwilę trwać.

-- 
wer <",,)~~
http://szumofob.eu

W dniu 11.04.2011 09:05, bofh@nano.pl pisze:

> Jeśli w nowym miejscu masz też inny adres, co jest korzystne w takim
> przypadku:
>
> 1. Konfigurujesz nowy hosting pod swoją domenę.
> 2. Wyłączasz na chwilę, żeby przegrać dane.
> 3. Na starym hostingu dajesz przekierowanie na nowy hosting.
> 4. Zmieniasz strefę.
>
> Problem gdy strona jest dynamiczna i np trzeba przegrać 3GB danych. To
> musi chwilę trwać.
>

Na starym hostingu nie ustawisz przekierowania poczty na nowy hosting, a 
to jest w takich przenosinach największym problemem...

Pozdrawiam
Daniel

On 11.04.2011 14:00, Daniel wrote:
> W dniu 11.04.2011 09:05, bofh@nano.pl pisze:
> 
>> Jeśli w nowym miejscu masz też inny adres, co jest korzystne w takim
>> przypadku:
>>
>> 1. Konfigurujesz nowy hosting pod swoją domenę.
>> 2. Wyłączasz na chwilę, żeby przegrać dane.
>> 3. Na starym hostingu dajesz przekierowanie na nowy hosting.
>> 4. Zmieniasz strefę.
>>
>> Problem gdy strona jest dynamiczna i np trzeba przegrać 3GB danych. To
>> musi chwilę trwać.
>>
> 
> Na starym hostingu nie ustawisz przekierowania poczty na nowy hosting, a
> to jest w takich przenosinach największym problemem...

Poczta to nie taki problem, w końcu można przerzucić maile później te,
które przyszły w czasie przenosin. A serwery pocztowe też próbują kilka
razy wysyłać.

-- 
wer <",,)~~
http://szumofob.eu

W artykule Marcin Szewczyk napisał(a):

>>> Należy się również liczyć z tym, że podczas przenosin z jednego hostingu
>>> na drugi będzie pewien okres (pewnie około doby), kiedy część świata
>>> będzie kierowana na stary hosting, a część już na nowy. Ważne w
>>> kontekście treści strony, ew. zamówień, czy poczty (jeśli hosting
>>> zajmuje się i tym).
>> 
>> E-e, przy planowanych przenosinach to się bez problemu skraca
>> nawet do minuty.
>
> Ale to chyba tylko, jeśli ma się wpływ na rekord SOA?

Nawet wtedy "średnio" to widzę. Masę dnscache'y ma w głębokim poważaniu
TTL. 

pozdr,
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:fenio@debian.org | pgp:0x13fefc40 | irc:fEnIo
 : :' :       32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
 `. `'           phone:+48602383548 | proud Debian maintainer and user
   `-            http://fenski.pl | xmpp:fenio@jabber.org | rlu:172001

W artykule bofh@nano.pl napisał(a):

>>>>> Należy się również liczyć z tym, że podczas przenosin z jednego
>>>>> hostingu
>>>>> na drugi będzie pewien okres (pewnie około doby), kiedy część świata
>>>>> będzie kierowana na stary hosting, a część już na nowy. Ważne w
>>>>> kontekście treści strony, ew. zamówień, czy poczty (jeśli hosting
>>>>> zajmuje się i tym).
>>>>
>>>> E-e, przy planowanych przenosinach to się bez problemu skraca
>>>> nawet do minuty.
>>>
>>> Ale to chyba tylko, jeśli ma się wpływ na rekord SOA?
>> 
>> tak, ale to dość łatwo zrobić, nawet jak nie masz wpływu:
>> 
>> 1. ustawiasz domenę u siebie, ustawiasz rekord A na stare IP.
>> 2. ustawiasz TTL u siebie na 1 minutę
>> 3. zmieniasz DNSy na swoje (ale cały czas wskazują na "stareIP"
>> 4. czekasz ponad dobę, żeby wszyscy widzieli twoje DNSy
>> 5. zmieniasz IP u siebie w pliku strefy na nowe - twoje
>> 
>> 6. i tak dla części serwerów się nie uda, bo np. dns2.tpnet.pl olewa
>> ustawione TTLe a działa tam chmura, zatem czasem odpowiedzi są poprawne
>> od razu, a czasem nie :-), takich serwerów jest więcej.
>
> Jeśli w nowym miejscu masz też inny adres, co jest korzystne w takim
> przypadku:
>
> 1. Konfigurujesz nowy hosting pod swoją domenę.
> 2. Wyłączasz na chwilę, żeby przegrać dane.
> 3. Na starym hostingu dajesz przekierowanie na nowy hosting.
> 4. Zmieniasz strefę.
>
> Problem gdy strona jest dynamiczna i np trzeba przegrać 3GB danych. To
> musi chwilę trwać.

rsync sprawę ogarnie. Tylko to wszystko porady dla kogoś kto ma trochę
więcej niż hosting. Obawiam się, że wątkotwórca ma dostęp do czegoś ala
webmin+ftp i guzik ma z tych wszystkich elastycznych usprawnień.

Nawet spory, dynamiczny serwis można przerzucić z praktycznie
pomijalnym downtimem pod warunkiem, że ma się roota w obu
lokalizacjach. No i pasi też aktualny serwer mieć dostępny przez kilka dni
po migracji. Z mojego doświadczenia to mimo ustawienia TTL na minutę
jeszcze po 2-3 dniach trafiają hity na starą lokalizację, więc warto je
przekierować via jakiś rinetd czy inne haproxy.

pozdr,
fEnIo
-- 
  ,''`.  Bartosz Fenski | mailto:fenio@debian.org | pgp:0x13fefc40 | irc:fEnIo
 : :' :       32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
 `. `'           phone:+48602383548 | proud Debian maintainer and user
   `-            http://fenski.pl | xmpp:fenio@jabber.org | rlu:172001

Użytkownik "Bartosz Feński aka fEnIo" <fenio@debian.org> napisał w 
wiadomości news:slrniq6htb.71d.fenio@serwer.fenski.pl...
>W artykule bofh@nano.pl napisał(a):
>
>>>>>> Należy się również liczyć z tym, że podczas przenosin z jednego
>>>>>> hostingu
>>>>>> na drugi będzie pewien okres (pewnie około doby), kiedy część świata
>>>>>> będzie kierowana na stary hosting, a część już na nowy. Ważne w
>>>>>> kontekście treści strony, ew. zamówień, czy poczty (jeśli hosting
>>>>>> zajmuje się i tym).
>>>>>
>>>>> E-e, przy planowanych przenosinach to się bez problemu skraca
>>>>> nawet do minuty.
>>>>
>>>> Ale to chyba tylko, jeśli ma się wpływ na rekord SOA?
>>>
>>> tak, ale to dość łatwo zrobić, nawet jak nie masz wpływu:
>>>
>>> 1. ustawiasz domenę u siebie, ustawiasz rekord A na stare IP.
>>> 2. ustawiasz TTL u siebie na 1 minutę
>>> 3. zmieniasz DNSy na swoje (ale cały czas wskazują na "stareIP"
>>> 4. czekasz ponad dobę, żeby wszyscy widzieli twoje DNSy
>>> 5. zmieniasz IP u siebie w pliku strefy na nowe - twoje
>>>
>>> 6. i tak dla części serwerów się nie uda, bo np. dns2.tpnet.pl olewa
>>> ustawione TTLe a działa tam chmura, zatem czasem odpowiedzi są poprawne
>>> od razu, a czasem nie :-), takich serwerów jest więcej.
>>
>> Jeśli w nowym miejscu masz też inny adres, co jest korzystne w takim
>> przypadku:
>>
>> 1. Konfigurujesz nowy hosting pod swoją domenę.
>> 2. Wyłączasz na chwilę, żeby przegrać dane.
>> 3. Na starym hostingu dajesz przekierowanie na nowy hosting.
>> 4. Zmieniasz strefę.
>>
>> Problem gdy strona jest dynamiczna i np trzeba przegrać 3GB danych. To
>> musi chwilę trwać.
>
> rsync sprawę ogarnie. Tylko to wszystko porady dla kogoś kto ma trochę
> więcej niż hosting. Obawiam się, że wątkotwórca ma dostęp do czegoś ala
> webmin+ftp i guzik ma z tych wszystkich elastycznych usprawnień.

Dokładnie. Nic więcej.

> Nawet spory, dynamiczny serwis można przerzucić z praktycznie
> pomijalnym downtimem pod warunkiem, że ma się roota w obu
> lokalizacjach. No i pasi też aktualny serwer mieć dostępny przez kilka dni
> po migracji. Z mojego doświadczenia to mimo ustawienia TTL na minutę
> jeszcze po 2-3 dniach trafiają hity na starą lokalizację, więc warto je
> przekierować via jakiś rinetd czy inne haproxy.

To nie jest problem jeśli oba serwisy mogą funkcjonować jakiś czas 
jednocześnie. 

W artykule MC napisał(a):

>>>>>> E-e, przy planowanych przenosinach to się bez problemu skraca
>>>>>> nawet do minuty.
>>>>>
>>>>> Ale to chyba tylko, jeśli ma się wpływ na rekord SOA?
>>>>
>>>> tak, ale to dość łatwo zrobić, nawet jak nie masz wpływu:
>>>>
>>>> 1. ustawiasz domenę u siebie, ustawiasz rekord A na stare IP.
>>>> 2. ustawiasz TTL u siebie na 1 minutę
>>>> 3. zmieniasz DNSy na swoje (ale cały czas wskazują na "stareIP"
>>>> 4. czekasz ponad dobę, żeby wszyscy widzieli twoje DNSy
>>>> 5. zmieniasz IP u siebie w pliku strefy na nowe - twoje
>>>>
>>>> 6. i tak dla części serwerów się nie uda, bo np. dns2.tpnet.pl olewa
>>>> ustawione TTLe a działa tam chmura, zatem czasem odpowiedzi są poprawne
>>>> od razu, a czasem nie :-), takich serwerów jest więcej.
>>>
>>> Jeśli w nowym miejscu masz też inny adres, co jest korzystne w takim
>>> przypadku:
>>>
>>> 1. Konfigurujesz nowy hosting pod swoją domenę.
>>> 2. Wyłączasz na chwilę, żeby przegrać dane.
>>> 3. Na starym hostingu dajesz przekierowanie na nowy hosting.
>>> 4. Zmieniasz strefę.
>>>
>>> Problem gdy strona jest dynamiczna i np trzeba przegrać 3GB danych. To
>>> musi chwilę trwać.
>>
>> rsync sprawę ogarnie. Tylko to wszystko porady dla kogoś kto ma trochę
>> więcej niż hosting. Obawiam się, że wątkotwórca ma dostęp do czegoś ala
>> webmin+ftp i guzik ma z tych wszystkich elastycznych usprawnień.
>
> Dokładnie. Nic więcej.

No to pole manewru masz sporo ograniczone.

>> Nawet spory, dynamiczny serwis można przerzucić z praktycznie
>> pomijalnym downtimem pod warunkiem, że ma się roota w obu
>> lokalizacjach. No i pasi też aktualny serwer mieć dostępny przez kilka dni
>> po migracji. Z mojego doświadczenia to mimo ustawienia TTL na minutę
>> jeszcze po 2-3 dniach trafiają hity na starą lokalizację, więc warto je
>> przekierować via jakiś rinetd czy inne haproxy.
>
> To nie jest problem jeśli oba serwisy mogą funkcjonować jakiś czas 
> jednocześnie. 

No tylko ja miałem na myśli zwykły redirect ze starej lokalizacji na nową,
a nie działanie serwisu w dwóch miejscach. To zazwyczaj nie jest możliwe,
bo pod spodem jest baza, która musi zachować integralność.

Może po prostu pochwal się co to za serwis i może ktoś doradzi co zrobić na
przyszłość. Inaczej przenosi się jakieś gówniane stronki gdzie downtime nie
jest jakimś problemem, a inaczej serwisy gdzie downtime to przestój firmy.

Jeśli to strona gdzie godzina przestoju to straszny ból i strata kasy to
może po prostu czas pomyśleć o postawieniu tego tam gdzie ma się roota
choćby to był VPS zamiast hostingu.

pozdr,
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:fenio@debian.org | pgp:0x13fefc40 | irc:fEnIo
 : :' :       32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
 `. `'           phone:+48602383548 | proud Debian maintainer and user
   `-            http://fenski.pl | xmpp:fenio@jabber.org | rlu:172001

W dniu 2011-04-12 11:40, MC pisze:
> Użytkownik "Bartosz Feński aka fEnIo" <fenio@debian.org> napisał w
> wiadomości news:slrniq6htb.71d.fenio@serwer.fenski.pl...
>> W artykule bofh@nano.pl napisał(a):
>>
>>>>>>> Należy się również liczyć z tym, że podczas przenosin z jednego
>>>>>>> hostingu
>>>>>>> na drugi będzie pewien okres (pewnie około doby), kiedy część świata
>>>>>>> będzie kierowana na stary hosting, a część już na nowy. Ważne w
>>>>>>> kontekście treści strony, ew. zamówień, czy poczty (jeśli hosting
>>>>>>> zajmuje się i tym).
>>>>>>
>>>>>> E-e, przy planowanych przenosinach to się bez problemu skraca
>>>>>> nawet do minuty.
>>>>>
>>>>> Ale to chyba tylko, jeśli ma się wpływ na rekord SOA?
>>>>
>>>> tak, ale to dość łatwo zrobić, nawet jak nie masz wpływu:
>>>>
>>>> 1. ustawiasz domenę u siebie, ustawiasz rekord A na stare IP.
>>>> 2. ustawiasz TTL u siebie na 1 minutę
>>>> 3. zmieniasz DNSy na swoje (ale cały czas wskazują na "stareIP"
>>>> 4. czekasz ponad dobę, żeby wszyscy widzieli twoje DNSy
>>>> 5. zmieniasz IP u siebie w pliku strefy na nowe - twoje
>>>>
>>>> 6. i tak dla części serwerów się nie uda, bo np. dns2.tpnet.pl olewa
>>>> ustawione TTLe a działa tam chmura, zatem czasem odpowiedzi są poprawne
>>>> od razu, a czasem nie :-), takich serwerów jest więcej.
>>>
>>> Jeśli w nowym miejscu masz też inny adres, co jest korzystne w takim
>>> przypadku:
>>>
>>> 1. Konfigurujesz nowy hosting pod swoją domenę.
>>> 2. Wyłączasz na chwilę, żeby przegrać dane.
>>> 3. Na starym hostingu dajesz przekierowanie na nowy hosting.
>>> 4. Zmieniasz strefę.
>>>
>>> Problem gdy strona jest dynamiczna i np trzeba przegrać 3GB danych. To
>>> musi chwilę trwać.
>>
>> rsync sprawę ogarnie. Tylko to wszystko porady dla kogoś kto ma trochę
>> więcej niż hosting. Obawiam się, że wątkotwórca ma dostęp do czegoś ala
>> webmin+ftp i guzik ma z tych wszystkich elastycznych usprawnień.

w wielu hostingach jest jakiś panel. Jeżeli będzie to cPanel to nie 
widzę problemu edycji rekordów DNS - wielu to udostępnia - w tym ja :)

Wojtek

-- 
polecam stronę: www.nartyrowery.pl
największy sklep ze sprzętem narciarskim i snowboardowym

W artykule crazy bejbi napisał(a):

>>>>>>> E-e, przy planowanych przenosinach to się bez problemu skraca
>>>>>>> nawet do minuty.
>>>>>>
>>>>>> Ale to chyba tylko, jeśli ma się wpływ na rekord SOA?
>>>>>
>>>>> tak, ale to dość łatwo zrobić, nawet jak nie masz wpływu:
>>>>>
>>>>> 1. ustawiasz domenę u siebie, ustawiasz rekord A na stare IP.
>>>>> 2. ustawiasz TTL u siebie na 1 minutę
>>>>> 3. zmieniasz DNSy na swoje (ale cały czas wskazują na "stareIP"
>>>>> 4. czekasz ponad dobę, żeby wszyscy widzieli twoje DNSy
>>>>> 5. zmieniasz IP u siebie w pliku strefy na nowe - twoje
>>>>>
>>>>> 6. i tak dla części serwerów się nie uda, bo np. dns2.tpnet.pl olewa
>>>>> ustawione TTLe a działa tam chmura, zatem czasem odpowiedzi są poprawne
>>>>> od razu, a czasem nie :-), takich serwerów jest więcej.
>>>>
>>>> Jeśli w nowym miejscu masz też inny adres, co jest korzystne w takim
>>>> przypadku:
>>>>
>>>> 1. Konfigurujesz nowy hosting pod swoją domenę.
>>>> 2. Wyłączasz na chwilę, żeby przegrać dane.
>>>> 3. Na starym hostingu dajesz przekierowanie na nowy hosting.
>>>> 4. Zmieniasz strefę.
>>>>
>>>> Problem gdy strona jest dynamiczna i np trzeba przegrać 3GB danych. To
>>>> musi chwilę trwać.
>>>
>>> rsync sprawę ogarnie. Tylko to wszystko porady dla kogoś kto ma trochę
>>> więcej niż hosting. Obawiam się, że wątkotwórca ma dostęp do czegoś ala
>>> webmin+ftp i guzik ma z tych wszystkich elastycznych usprawnień.
>
> w wielu hostingach jest jakiś panel. Jeżeli będzie to cPanel to nie 
> widzę problemu edycji rekordów DNS - wielu to udostępnia - w tym ja :)

A resztę wątku czytałeś? TPSA na przykład ma TTL w głębokim poważaniu
i Twój panel do edycji DNS nic nie zmienia ;P

pozdr,
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:fenio@debian.org | pgp:0x13fefc40 | irc:fEnIo
 : :' :       32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
 `. `'           phone:+48602383548 | proud Debian maintainer and user
   `-            http://fenski.pl | xmpp:fenio@jabber.org | rlu:172001

W dniu 2011-04-12 20:13, Bartosz Feński aka fEnIo pisze:

>> w wielu hostingach jest jakiś panel. Jeżeli będzie to cPanel to nie
>> widzę problemu edycji rekordów DNS - wielu to udostępnia - w tym ja :)
>
> A resztę wątku czytałeś? TPSA na przykład ma TTL w głębokim poważaniu
> i Twój panel do edycji DNS nic nie zmienia ;P

oczywiście - ale na to nic nie poradzisz. ale zamiast mówić, że nic nie 
da się zrobić można minimalizować downtime serwisu. Po pierwsze nie samą 
tepsą człowiek żyje, a po drugie zawsze można np. kupić tepsę i zmienić 
zasady działania ich dnsów :)

Wojtek

-- 
polecam stronę: www.nartyrowery.pl
największy sklep ze sprzętem narciarskim i snowboardowym

W artykule crazy bejbi napisał(a):

>>> w wielu hostingach jest jakiś panel. Jeżeli będzie to cPanel to nie
>>> widzę problemu edycji rekordów DNS - wielu to udostępnia - w tym ja :)
>>
>> A resztę wątku czytałeś? TPSA na przykład ma TTL w głębokim poważaniu
>> i Twój panel do edycji DNS nic nie zmienia ;P
>
> oczywiście - ale na to nic nie poradzisz. ale zamiast mówić, że nic nie 
> da się zrobić można minimalizować downtime serwisu. Po pierwsze nie samą 
> tepsą człowiek żyje, a po drugie zawsze można np. kupić tepsę i zmienić 
> zasady działania ich dnsów :)

No tak. Myślę, że twórcę wątku stać na kupienie tepsy skoro nie stać go
nawet na VPSa ;)

pozdr,
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:fenio@debian.org | pgp:0x13fefc40 | irc:fEnIo
 : :' :       32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
 `. `'           phone:+48602383548 | proud Debian maintainer and user
   `-            http://fenski.pl | xmpp:fenio@jabber.org | rlu:172001

W dniu 2011-04-12 21:40, Bartosz Feński aka fEnIo pisze:
> W artykule crazy bejbi napisał(a):
>
>>>> w wielu hostingach jest jakiś panel. Jeżeli będzie to cPanel to nie
>>>> widzę problemu edycji rekordów DNS - wielu to udostępnia - w tym ja :)
>>>
>>> A resztę wątku czytałeś? TPSA na przykład ma TTL w głębokim poważaniu
>>> i Twój panel do edycji DNS nic nie zmienia ;P
>>
>> oczywiście - ale na to nic nie poradzisz. ale zamiast mówić, że nic nie
>> da się zrobić można minimalizować downtime serwisu. Po pierwsze nie samą
>> tepsą człowiek żyje, a po drugie zawsze można np. kupić tepsę i zmienić
>> zasady działania ich dnsów :)
>
> No tak. Myślę, że twórcę wątku stać na kupienie tepsy skoro nie stać go
> nawet na VPSa ;)

myślałem o Tobie bardziej z tym kupieniem ;)

Wojtek

-- 
polecam stronę: www.nartyrowery.pl
największy sklep ze sprzętem narciarskim i snowboardowym

W artykule crazy bejbi napisał(a):

>>>>> w wielu hostingach jest jakiś panel. Jeżeli będzie to cPanel to nie
>>>>> widzę problemu edycji rekordów DNS - wielu to udostępnia - w tym ja :)
>>>>
>>>> A resztę wątku czytałeś? TPSA na przykład ma TTL w głębokim poważaniu
>>>> i Twój panel do edycji DNS nic nie zmienia ;P
>>>
>>> oczywiście - ale na to nic nie poradzisz. ale zamiast mówić, że nic nie
>>> da się zrobić można minimalizować downtime serwisu. Po pierwsze nie samą
>>> tepsą człowiek żyje, a po drugie zawsze można np. kupić tepsę i zmienić
>>> zasady działania ich dnsów :)
>>
>> No tak. Myślę, że twórcę wątku stać na kupienie tepsy skoro nie stać go
>> nawet na VPSa ;)
>
> myślałem o Tobie bardziej z tym kupieniem ;)

Ja swojego debetu i kredytówek nie ogarniam, a co dopiero taką studnię bez
dna jak TPSA ;P

pozdr,
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:fenio@debian.org | pgp:0x13fefc40 | irc:fEnIo
 : :' :       32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
 `. `'           phone:+48602383548 | proud Debian maintainer and user
   `-            http://fenski.pl | xmpp:fenio@jabber.org | rlu:172001

Dnia 2011-04-12, o godz. 19:17:05
Bartosz Feński aka fEnIo <fenio@debian.org> napisał(a):

> No tylko ja miałem na myśli zwykły redirect ze starej lokalizacji na
> nową, a nie działanie serwisu w dwóch miejscach. To zazwyczaj nie
> jest możliwe, bo pod spodem jest baza, która musi zachować
> integralność.

Ale przecież zwykle baza nie musi być na tym samym hoście co serwis i
to załatwia problem spójności danych. A czy do bazy będą lecieć
zapytania ze starego czy nowego serwera to zwykle obojętne.

Zdrówko