pleple
Użytkownicy-
Zawartość
253 -
Rejestracja
-
Ostatnio
Typ zawartości
Profile
Fora
Katalog firm
Wszystko napisane przez pleple
-
Dyski SATA maja funckję hotswap więc wcale nie trzeba wyłączac serwera. Poza tym i tak lepiej wylaczyc serwer na moment, wyciagnac dysk i miec dzialajacy system po 30 min downtime niz miec kilkukrotnie wiekszy downtime i dane z wczoraj w przypadku uzywania rsync. Ciągle również nie rozumiem czemu majac dysk (S)ATA, przy uszkodzeniu jednego dysku w maciezy mój filesystem może się posypać a w przypadku innych dysków nie może. W swoim pierwszym poście napisałeś, że software RAID nie ma sensu przy dyskach (S)ATA, przy jakich dyskach ma on sens?
-
Możesz to rozwinąć? Czemu jest sens w przypadku dysków SCSI ale juz nie (S)ATA? Czym one się różnią pod tym względem? Czemu jest taka szansa na dyskach (S)ATA a na SCSI nie ma? Pytam na prawdę z ciekawości bo bardzo mnie zdziwił ten post. Wiadomo, że hardware RAID jest lepszy niż software (inaczej nikt nie wydałby grubych pieniędzy na ten pierwszy) ale co to ma do dysków (S)ATA ?
-
To są zdecydowanie dwie różne rzeczy i ciężko je porównywać. Co więcej zarówno jedno jak i drugie samo w sobie nie zabezpieczy forum (czy jakiejkolwiek innej aplikacji webowej) przed włamaniem. Suhosin to zestaw łat bezpieczeństwa na PHP. Mod_security to w pewnym sensie taki firewall na HTTP. Oba mogą pomóc - pierwszy zabezpiecza przed wykorzystaniem błędów w PHP, drugi błędów w kodzie aplikacji (ale to skomplikowana sprawa, trzeba mieć odpowiednie regułki więc trzeba najpierw wiedzieć jakie zapytania są typowe a jakie nie).
-
lol, ślepy jestem. Jednak dalej nie zmienia to faktu, że to nie za dużo IMO.
-
Eaa.. Jeśli to jeszcze jest brutto to już w ogóle grosze (skoro chcą kogoś bez życia toważyskiego to raczej nie chcą kogoś kto opiekuje się wieloma serwerami na raz).
-
Nom tak by wychodziło ale.. nielimitowana ilość przesłanych danych?
-
A co to oznacza u nich to: Monthly Bandwidth: 2Mbit ??
-
Prawie robi różnice...
-
To dość sporo kasy. Taka transakcja to dość spore ryzyko (dla obu stron). Jak kasa zginie to nie będzie ciekawie. Może więc lepiej założyć sobie konto w mBanku (free) i eKarte (~30 zł/ rok) ? Trochę to potrwa więc możesz w międzyczasie zapłacić przez kogoś ale tylko za 1 miesiąc a nie za 3. To zawsze mniej kasy...
-
To dość dziwne. Pamiętam, że raz na serwerze pocztowym, który debugowałem zrobiło się niezłe wąskie gardło i load przez kilkadziesiat minut utzymywał się na poziomi kilkuset. Nie miałem problemu z połączeniem się przez SSH. Serwer nie był zbyt świetny ale też nie za słaby (1 GB RAM, procesor jednordzeniowy). O, mam nawet zapisane konkretne wartości jakie były: load average: 1001.19, 646.91, 302.05 Było to zmierzone z poziomu SSH. Taki load jest oczywiście zły ale nie trzeba się raczej martwić o brak łączności z maszyną. Oczywiście zależy to też od tego co powoduje ten load...
-
Napisałeś (jeszcze raz zacytuje): Jeśli użytkownik nie ma uprawnień superużytkownika i chroot jest dobrze skonfigurowany (co nie jest znów takie trudne) to nie ma możliwości wyjścia z niego. To zdecydowanie jest istotne zwiększenie poziomu bezpieczeństwa. Ostatecznie użytkownik nie powinien NIGDY dostać roota w przypadku systemu hostingowego, o którym mówimy. Dla tego stwierdziłem, że piszesz jakbyś nie miał o tym pojęcia. Zupełnie nie wiem czemu uważasz, że się przyczepiłem iż chroot jest jakimś lekarstwem. Uważam po prostu iż twierdzenie, że chroot to zabawka, która właściwie nic nie zmienia jest nie prawdą. Co do tematu chroot vs jail to nie ma co w ogóle porównywać - jails to jest bardziej jak VServer albo OpenVZ (choć może znów nie aż tak). . Teraz też tak sądzę. Jednak nadal uważam, iż mocno przesadzasz degradując rolę (nawet standardowego chroota) do zabawki. Zabezpieczenie serwera (zresztą czegokolwiek) polega na ustawieniu całego łańcucha bezpieczeństwa, składającego się z wielu czynników. Użycie jakiegokolwiek rozwiązania w przypadku kiedy zignorujemy inne elementy zawsze będzie złe. Stąd oczywistym jest iż chroot jest tylko jednym z elementów systemu zabezpieczeń. Podkreślę jednak raz jeszcze iż poprawnie skonfigurowany ma istotny wpływ na bezpieczeństwo serwera. Nie chcę robić z siebie najmądrzejszego ani też nikogo denerwować ale sądząc po tonie Twojej ostatniej wypowiedzi to chyba sam mogłbyś przyznać iż Twoje wcześniejsze stwierdzenie jest trochę przesadzone, co?
-
Nom, najpierw trzeba mieć root-a a kernel musi być, że tak powiem, waniliowy. Można zasadniczo powiedzieć, że jeśli w chroocie nie można tworzyć i nie ma żadnych plików urządzeń, nie ma suidowanych programów i żaden z uruchomionych tam daemonów nie działa jako root to z tego chroota nie da się wyjść.
-
Jak się czyta takie coś to od razu widać, że ktoś nie ma pojęcia co pisze.
-
Dotyczy to samego ustawienia php (max_execution_time) i jest to prawdopodobnie to samo ograniczenie, które podałeś jako maksymalny czas wykonywania skryptu. Inaczej mówiąc, nie liczy się czas bezwzględny a jedynie czas, w którym skrypt coś obliczał. Czyli jak skrypt czeka 30 sekund to jest ok, jak coś tyle oblicza to zostanie zatrzymany.
-
Hmm.. w sumie to właśnie sprawdziłem i do tego limitu czasu wykonywania skryptu nie wlicza sie operacji wysyłania danych (ani nawet syscalli) więc zasadniczo ten skrypt prawie nie wykonuje operacji, które się wliczają a więc w ten sposób na pewno sie nie timeoutuje (co oczywiście nie wyklucza, że gdzieś indziej nastąpi timeout). No i ważna uwaga - nie powinieneś używać tego skryptu w takiej formie w jakiej jest przedstawiony. To tylko poglądowy skrypt, który nie jest zbyt bezpieczny. Pamiętaj o tym.
-
Obciążenia nie powoduje bo większość czasu czeka aż upłynie pewien czas po którym wyśle następną porcję danych (efektywnie obniżając średnią prędkość pobierania). Jeśli limit czasu jaki skrypt PHP może być uruchomiony jest ustawiony na 60 sekund to możesz plik 5MB puszczać z minimalną prędkością wynoszącą: 5120KB/60sekund = 85KB/s Jak więc widzisz prędkość jest dość duża (3/4 MBit) więc jeśli limit nie jest ustawiony dość wysoko to mogą być problemy jeślibyś chciał na prawdę mocno ograniczać tą prędkość (ale myśle, że jest ustawiony wyżej niż 60 sekund).
-
Uważaj tylko na timeouty. PHP może ustawiony jakiś limit długości wykonywania skryptu. Tak więc jeśli Twój provider ma ustawiony taki limit to możesz mieć problemy z wysłaniem dużych plików tą metodą (skrypt wykonuje się tak długo, jak długo pobierany jest plik). Domyślnie wartość ta jest ustawiona na 30 sekund ale oczywiście u Twojego prowidera może nie być tak źle.
-
A jak ktoś znajdzie błąd w cPanelu to masz problem aż dopóki nie zostanie to spatchowane. Tylko, że zanim to nastąpi to ktoś musi o tym błędzie poinformować obsługę. Jednak zamiast tego może najpierw postarać sie wzbogacić albo popisać wsród innych jakimś 0day. Tyle firm używa cPanelu, że ludzie mogą być tym zainteresowani. Trudniej znaleźć błąd w autorskim panelu bo nikt tak na prawdę nie wie co w nim siedzi wewnątrz i jak to działa.
-
No tak, ale skoro cPanel wcale takich nie ma a pisałeś jakby był to dobry panel to znaczy, że można takowy zrobić bez tych specjalistów. Więc trochę nie widzę logiki w tym co napisałeś. Skoro uważasz, że cPanel nie ma specjalistów to albo nie trzeba ich mieć żeby zrobić dobry panel albo cPanel nie jest dobrym panelem. Więc jak w końcu? Myślę jednak, że w panelach hostingowych jest to dobre rozwiązanie. Mi takie pozwoliło ono sporo uprościć i pozbyć się wielu problemów we wszystkich przypadkach.
-
No tak, w sumie myśląc o sciąganiu plików z katalogu od razu pomyślałem o zastosowaniach bardziej niskopoziomowych czyli w serwerze WWW. Niebardzo jednak rozumiem jak chcesz PHP i .htaccess tutaj połączyć. Możesz napisać więcej szczegółów bo mnie zaciekawiłeś? Da się z poziomu PHP ograniczyć prędkość wysyłanych danych, to na pewno. Można tez ograniczyć ilość jednoczesnych ściągnięć ale po co wted .htaccess?
-
Przyglądałem się pewnym rozwiązaniom używanym w cPanelu (tak ogólnie) i nie wydaje mi się aby twórcy cPanela mieni takich speców w swojej ekipie. Kolejkowanie jest dobrym sposobem na ułatwienie zarządzania procesami, szczególnie przy instalacji z wieloma węzłami. Jednocześnie upraszcza i optymalizuje to operacje dodając jednocześnie aspekt bezpieczeństwa. Operacje można odłożyć do centralnej bazy danych, która jest odpytywana przez skrypty działające na odpowiednich uprawnieniach (i z dostosowanymi parametrami systemu) na poszczególnych hostach. Można też wyeliminować pewne zbędne operacje (np. kiedy użytkownik się pomylił i po raz kolejny zmienia to samo) oraz grupować pewne kosztowne operacje (np. wymagające rekonfiguracji serwera WWW).
-
To według mnie trochę przesada. Myślę, że istnieje wielu 16-latków, którzy mogą zadziwić swoją wiedzą niejednego seniora. Fakt, autor tego wątku wiedzą ani rozsądnymi argumentami się nie wykazał ale to nie znaczy, że od razu trzeba uogólniać.
-
A kto mówi, że tak musi być jak ktoś ma dedyki? Zawsze można się też posiłkować umowami z zewnętrznymi firmami albo po prostu zatrudniać ludzi na umowę o dzieło (szczególnie chodzi mi o programistów czy grafików).
-
1. Zgadzam się zupełnie. Ilość ludzi w supporcie powinna być proporcjonalna do ilości posiadanych kont. Ale co to ma do dedyków? 2. Może kilku a może jeden dobry, ostatecznie nie ma aż tak wiele do roboty kiedy już panel jest zrobiony. Zresztą programistów zawsze można nająć w przypadku potrzeby naprawienia czegoś, po co więc Ci programiści na stałe? I znów, co to ma do dedyków? 3. tak jak w 1, ilość administratorów proporcjonalna do ilości serwerów. Ale własne datacenter to nieporozumienie. Żeby opłacało się mieć dobrze zabezpieczone datacetner to trzebaby mieć tam przynajmniej setki serwerów. Pomyśl z jakimi kosztami wiąże się założenie redundantnego zasilania, podłączenie wielu niezależnych łącz Internetowych, zabezpieczenia na wypadek pożarów czy żywiołów. Zasadniczo jak jakaś firma hostingowa ma własne datacenter to ja wole jednak u nich nie mieć konta. Prawdopodobnie większa wichura albo powódź może zrobić tyle szkód, że firma przestnie istnieć (mimo, że wcale nie znudziło się jej właścicielom jej prowadzić). 4. A co jest złego w tym, że jak jednemu się znudzi to przekaże pałeczkę jakiemuś z innej firmy (czytaj, sprzeda firmę). Jest w tym coś złego dla użytkowników? Jak ktoś już napisał na forum, koncerny samochodowe są tak często odsprzedawane, że cieżko się połapać co należy do kogo. Czy docelowi klienci na tym tracą? Nie wydaje mi się. 5. Grafików zawsze można wynająć. Ale znów, co to ma do dedyków? 6. Na pewno ale to znów można połączyć z 5 i podpisać umowę z zewnętrzną firmą. Ale co to ma do dedyków?
-
Nie musisz. Myślę, że nie da się rozwiązać Twojego problemu. Pliki .htaccess służą do konfigurowania zachowania serwera w danych lokalizacjach. Jeśli więc serwer na home.pl obsługiwał by limitowanie prędkości wysyłania danych dla poszczególnych katalogów to mógłbyś to ustawić właśnie w tym pliku. Jestem jednak przekonany, że tego nie obsługują (zresztą sam wspomniałeś, że tak Ci napisali). Jeśli więc chcesz mieć taką funkcjonalność to prawdopodobnie musisz sam skonfigurować sobie serwer WWW (albo ktoś inny musi to zrobić za Ciebie) ale do tego potrzebujesz albo jakis VPS albo serwer dedykowany. Na pewno nie hosting dzielony.