Gdy firma hostingowa zmienia lokalizację itp.

[neon103]

Jeżeli firma XXX zmienia lokalizację serwera lub bazy danych przenosi na inny serwer (z localhost na inny) to czy użytkownik sam powinien sobie poprawiać plik config.php lub zmieniać atrybuty plikom? Czy powinien wymagać tego od firmy hostingowej? Kilka dni temu pewna firma (nie chcę kłócić się temu nazwy nie podaję) zmieniła chyba lokalizację serwerów. Strony były zapleczowe podpięte do SWL i chmody przywróciły pierwotną postać (zamiast 777 mają 644). Kto powinien poświęcić cały dzień lub dwa dni na ich zmiane - firma hostingowa czy użytkownik? Stron było kilkaset.

[lords]

Osobiście wolałbym to sam zmienić, żeby firma hostingowa czegoś nie pochrzaniła. Osobną kwestią jest to, że o takich zmianach user powinien być informowany minimum tydzień wcześniej.

Nie pytam o nazwę ale to hosting z allegro czy jakiś bardziej markowy?

[Arkadiusz]

Sam powinieneś zmieniać, bo od paru lat w hostingach nie trzeba już używać 777 (tylko 755) i 666 (644). Ale masakra że jeszcze były (są?) takie firmy...

[pandha]

ja w podobnym przypadku sie klocilem ze to ich wina. w koncu skad mialem wiedziec ze beda cos przenosic. a przeciez nie trzeba sprawdzac codziennie swoich stron nie?

[neon103]

Nie pytam o nazwę ale to hosting z allegro czy jakiś bardziej markowy?

Hm... z allegro nie. A czy markowy? Hm, firma długo na rynku ale coraz więcej osób narzeka.

Edycja: dobrze, ze kupuje juz praktycznie same serwery dedykowane.

[hekko]

1. Powinni wysłać stosowne powiadomienie chociaż.

2. Poważnie musisz mieć te chmody takie ustawione ?

[iSwift.pl]

Osobną kwestią jest to, że o takich zmianach user powinien być informowany minimum tydzień wcześniej.

Nawet jeśli poinformują, że coś takiego ma miejsca to nie zmieni to faktu, że i tak musi ktoś przeklikać chmody. A co do tygodniowego uprzedzenia to łatwo tak powiedzieć, ale nie zawsze tak da się zrobić .

Chmod 777 w ogóle nie powinien być dopuszczony.

czy użytkownik sam powinien sobie poprawiać plik config.php lub zmieniać atrybuty plikom?

To jest naprawdę różnie, ale jeśli klient naciska to, przynajmniej my, siadamy i przywracamy takie rzeczy albo staramy się to w inny sposób naprawić, choć nie zawsze się da. Jeśli stron jest kilkaset i dostaje informacje, że coś nie działa przez plik config.php to nie widzę problemu by w godzinę napisać skrypt i wszystko zmienić dla jednego użytkownika.

[Gonzo23]

@neon103 - czy to była firma na "c" ? Tak z ciekawości pytam

PS - co się dzieje z top100.pl ? Mnie przekierowuje na home.pl..

[maras1]

PS - co się dzieje z top100.pl ? Mnie przekierowuje na home.pl..

wygląda na to że zamknęli serwis, przekierowanie 301..

[Darek82]

A ja może będę tutaj wyjątkiem, ale chętnie dowiedziałbym się, z jakiej firmy był ten hosting. Nie widzę powodu, aby nie podawać nazwy firmy, przecież prawo tego nie zabrania. Trzeba napisać nazwę firmy i podać suche fakty, co ta firma zrobiła a z czego nie jesteśmy zadowoleni. Nie jest to w żadnym wypadku antyreklama, to po prostu dostarczanie suchych faktów o usługach firmy i jest w pełni legalne jeżeli oczywiście opisana sytuacja miała miejsce.

[βασιλιάς]

Chmod 777 w ogóle nie powinien być dopuszczony.

Ale przecież na większości hostingów PHP działa jako moduł Apache i obsługuje wszystkie skrypty z konta www-data.

Ustawienie chmod 777 to jedyna możliwość zrobienia folderu z możliwością zapisu z poziomu PHP, bo przez FTP nie można np. zmienić grupy na www-data i ustawić 770.

Jak nadrzędny ma user.www-data 750 czy 770, a w PHP jest ustawiony prawidłowo open_basedir i w Apache nie ma włączonych innych modułów do języków skryptowych czy obsługi CGI, to konfiguracja ta nie jest szczególnie niebezpieczna.

[hekko]

Ale przecież na większości hostingów PHP działa jako moduł Apache i obsługuje wszystkie skrypty z konta www-data.

Większość ?

Jak nadrzędny ma user.www-data 750 czy 770, a w PHP jest ustawiony prawidłowo open_basedir i w Apache nie ma włączonych innych modułów do języków skryptowych czy obsługi CGI, to konfiguracja ta nie jest szczególnie niebezpieczna.

Jeśli tak jest w rzeczywistości to chwała adminom..

[Arkadiusz]

Ale przecież na większości hostingów PHP działa jako moduł Apache i obsługuje wszystkie skrypty z konta www-data.

Masz rację. O ile oczywiście żyjesz w erze kamienia łupanego.

[βασιλιάς]

Masz rację. O ile oczywiście żyjesz w erze kamienia łupanego.

To sprawdź np. 5 losowych z https://www.webhostingtalk.com/forumdisplay.php?f=4, na pewno albo wszystkie albo 4 z nich to będzie domyślna instalacja cPanela (w przypadku polskich hostingów DirectAdmina), z Apache + mod_php.

[Arkadiusz]

Nie muszę testować (zresztą, co to niby są za hostingi? sprawdzam pierwszą lepszą... Domain Name: gocheaphost.com Creation Date: 2010-01-21 - host istnieje 1,5 miesiąca; drugi lepszy - ufhosting.org ładuje się pół minuty; dalej sprawdzać nie mam ochoty). Korzystam z ~ 50 (strzelam) hostingów w Polsce i na świecie i ŻADEN nie działa na mod_php. Wręcz nie wyobrażam sobie, aby jakakolwiek licząca się marka korzystała z php jako modułu (no chyba, że jest na tyle rozgarnięta, że wady jakoś łata, bo teoretycznie jest to do wykonania).

PS. w Cpanelu zmiana mod_php ma fcgi/suphp to kwestia 1 kliknięcia i 10 sekund oczekiwania. W DA taką opcję można też spokojnie wybrać np. przy instalacji.