JohnyByk

Niestety dostawca internetu prężnie się rozwija i niespecjalnie chce odstąpić większą ilość adresów (mamy około 10 sztuk). Faktycznie nie pomyślałem, że mniej niż 256 się nie da. A może ktoś ma dużo leżących odłogiem adresów i może chce wydzierżawić /24 za sensowne pieniądze . Pozdrawiam

Uzupełnię zapytanie o dodatkowe informacje: - posiadamy własny serwer - serwer znajduje się w naszej serwerowni - poszukujemy możliwości wynajmu adresów ip poza lokalizację właściciela adresów Pozdrawiam

Witam. Czy wiecie gdzie można wydzierżawić niewielką ilość adresów ip (10-30 sztuk). Znalazłem firmy, które dzierżawią adresy IP, ale minimum 256 sztuk. Tyle nie potrzebujemy, a branie 256 adresów po to aby użyć około 10% z nich to mocno nieopłacalna sprawa. Jeśli miałby ktoś kilka adresów na zbyciu to chętnie wynajmiemy. Pozdrawiam

Witam Poszukuję firmy, która sprzedaje licencje do DirectAdmin. Kiedyś bez problemu można było kupić licencję (np. ionic, neateasy). Niestety teraz nie sprzedają licencji na zewnątrz. Jeśli ktoś wie gdzie można kupić licencję taniej niż na stronie oficjalnej to proszę o info. Nie mamy nic przeciwko aby była to internal license . Pozdrawiam

Wszystko padło. Kebab nie działa, ich strona nie działa. Totalny armagedon .

Jednak się udało. Zrobiłem jeszcze raz na spokojnie i działa. Nginx działa jako reverse proxy dla apache. Głównie zależy mi na zlimitowaniu wywołań do PHP'a. Serwer w sumie się nudzi jeśli chodzi o serwowanie statyków. Bardziej zabijają go zasobożerne skrypty PHP'a. Czasami wpada jakiś bot i zapycha pulę ilości procesów przeznaczonych dla usera i dana strona leży. Czy jest jakiś sposób za zlimitowanie wywołań plików php? Próbowałem z Location ~ \.php$, ale niestety nie działa. Pozdrawiam ------------------- Edycja: Jak używam Location ~ \.php$ to nie działa limitowanie, ale za to pliki php nie są parsowane (jak podaję pełną ścieżkę to można pobrać ich źródła). Może to przez to, że nginx działa jako reverse proxy albo inne problemy konfiguracyjne.

Właśnie męczę się z podobnym problemem w związku z tym odkopuję temat. Szukam sposobu na limitowanie requestów do PHP'a lub całego vhosta. Próbuję zdefiniować następującą regułkę w głównej sekcji http: limit_req_zone $binary_remote_addr zone=antiflood:10m rate=15r/s; Następnie w server danego vhosta dodaję: limit_req zone=antiflood; Zawszę otrzymuję komunikat: nginx: [emerg] unknown limit_req_zone "antiflood" in ... Wszystko działa w otoczce Direct Admina. Regułę tworzę w pliku głównym, sekcja http, a później includuję ją do sekcji server konkretnego vhosta. Zakładam, że definiuję regułę w złym miejscu? Generalnie w ten sposób mówi o tym dokumentacja, ale zapewne źle ją zrozumiałem. Przy okazji: co oznacza parametr burst? W dokumentacji nie udało mi się znaleźć dosłownego wytłumaczenia. Czy chodzi o to, że reguła zaczyna działać jeśli klient przekroczy wartość burst, coś jak burst przy podziale łącza np. niceshaperem? Pozdrawiam

U nas dzisiaj znowu pad :/ Też macie problemy? Jak tak dalej pójdzie to trzeba będzie szukać innego dostawcy. Pozdrawiam

U nas serwer powrócił do życia po około 40 minutach. Mam nadzieję, że już tak zostanie . Pozdrawiam

Dziwnym zbiegiem w momencie gdy w Trójmieście pojawiła się burza. Czyżby infrastruktura nie była w stanie wytrzymać przeciętnej burzy. Może TP-Linki WR740 im nie wytrzymały albo ktoś ropę z agregatów podprowadził

Nie włamali, tylko spamboty zarejestrowały konta przez core'ową funkcję joomli zapewne w celu spamowania. Dotyczy to większości popularnych skryptów.

Na razie z braku pomysłu ustawiam RLimitNPROC tak żeby w razie czego strony odpalane z danego usera nie zapchały serwera, a tym samym innych stron. Niestety rozwiązanie ma wadę ponieważ strona atakowana palcem zagłady leżącym na F5 nie działa. Dlatego szukam rozwiązania, które na chwilę odetnie psotnika i pozwoli na bezproblemowego działanie "atakowanej" strony. Wydaje mi się, że właśnie do tego sluży mod_evasive, ale coś nie za bardzo działa. Zauważyłem, że przy którejś próbie konfiguracji zaczęły pojawiać się wpisy: [Wed Feb 05 21:03:48.840463 2014] [:error] [pid 4366] [client 72.14.199.36:38141] client denied by server configuration: Niestety wpisy pojawiają się dopiero po tym jak odświeżane skrypty (np. w ilości 100 procesów) skończą się wykonywać. Moja teoria jest taka, że wykonuje się PHP (najbardziej zasobożerna część całości) i dopiero wtedy oddawane są dane (requesty) i zliczane przez mod_evasive. Czyli szybkie wykonywanie skryptu powoduje zapchanie reszty i blokada nie załącza się pomiędzy odświeżeniami skryptu a dopiero po requestach, które lecą po wykonaniu logiki w PHP'ie. Czy dobrze rozumuję i faktycznie może tak być? A może jednak mam skopaną konfigurację? Nie wierzę, że nie da się tego rozwiązać. Pozdrawiam

Witam W jaki sposób można zabezpieczyć się przed zabiciem serwera przez trzymanie klawisza F5? Użycie go przez kilkanaście sekund na dużym skrypcie PHP może zabić cały serwer. Nawet na serwerach home.pl czy innych można dostać komunikat server overloaded (zakładam, że dotyczy to zasobów jednego konta, ale jednak). Wiem, że jest mod_evasive. Zainstalowałem go. Skrypt dołączony do archiwum pokazuje, że działa: root@server:/usr/src/mod_evasive# ./test.pl HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden Konfiguracja jest standardowa, czyli: <IfModule mod_evasive20.c> DOSHashTableSize 3097 DOSPageCount 2 DOSSiteCount 50 DOSPageInterval 1 DOSSiteInterval 1 DOSBlockingPeriod 10 </IfModule> Pomimo to jak zastosuję F5 na jednym z cięższych (jeśli chodzi o PHP'a) skryptów to nic się nie dzieje. Load serwera wzrasta, a ja nie jestem w żaden sposób ograniczany. Strona generuje około 120 requestów. Problemem jest sam config czy może powinienem poszukać jakiegoś innego rozwiązania? Nakierujcie mnie co może być nie tak. Może powinienem coś pokombinować z konfiguracją? Już kombinowałem, ale niewiele się zmieniło. Odświeżanie strony za każdym razem zapycha serwer i muszę odczekać aż apache przemieli wszystkie procesy. Używam apache'a 2.4 z mod_ruid2 + DA. Pozdrawiam

Witam Odkurzę dosyć stary temat. Jakiś czas używałem suPHP. Jest mało bezpieczny, ale ma udogodnienie w postaci możliwości uruchomienia custom php.ini (tworzę plik php.ini w katalogu domeny i już mam nowe ustawienia). Udogodnieniem jest to, że nie jest to główny plik konfiguracyjny, a nadpisuje jedynie ustawienia, które w custom,owym pliku się znajdują (additional php.ini). Niestety suPHP nie jest bezpieczny i wydajnością też nie urywa. Zastanawiam się nad mod_php+mod_ruid2, php-fpm oraz fastcgi. Wszystkie powyższe rozwiązania są bezpieczniejsze od suPHP i też nie są wolniejsze. mod_ruid2 jest o tyle fajny, że bez problemu mogę sobie dopisać customowe ustawienia do konfiguracji Vhosta (używam DirectAdmina). php-fpm wydaje mi się najszybszy (może tu subiektywne odczucie, ale kilka testów własnych potwierdziło tą tezę, do tego miał najmniej Failed Request przy ab) fastcgi też wydaje się OK, ale miałem z nim kilka problemów, których nie udało mi się rozwiązać: http://www.webhostingtalk.pl/topic/42589-blad-mod-fcgid-32broken-pipe/ W przypadku php-fpm i fastcgi miałem jeszcze jeden problem z rewrite'ami. Część gratów leżących na serwerze działa w oparciu od cakePHP. Webroot znajduje się w /app/webroot (dopowiednie reguły .htaccess - jest to standard przy cakePHP). W przypadku suPHP czy mod_php wpisanie adresu strona.pl/phpinfo.php powoduje odpalenie skryptu. W przypadku fastcgi i php-fpm nie działa poprawnie taki link. Dostęp uzyskuję przez strona.pl/app/webroot/phpinfo.php Może to jakiś problem konfiguracyjny, a może jakaś typowa bolączka. Co ciekawe nie ma to wpływu na ogólne działanie aplikacji. Którą metodę serwowania php'a byście polecili. Zależy mi na w miarę nietrudnej możliwości manipulowania ustawieniami php'a per user (z poziomu DA) oraz bezawaryjności. Najchętniej wybrałbym fstcgi, ale generuje to problem, o którym pisałem wyżej. A może mod_php + mod_ruid2 wcale nie jest złym wyborem? Własne testy wykazały, że wydajność jest OK, ale może ma inne przeciwwskazania o których nie wiem. Proszę o opinie doświadczonych kolegów. Pozdrawiam

SEO w Magento jest na dużo wyższym poziomie niż w PS. W e-commerce można zauważyć tendencję, że firmy zakładają wiele sklepów (często 1 główny i kilka tematycznych z częścią oferty - dzięki temu zajmujesz większą półkę wśród innych poza tym jeśli sklep jest bardziej tematyczny to dla klient jest more exclusive). Nie ma problemu aby w obrębie jednej instalacji magento uruchomić kilka sklepów. Nie ma konieczności instalowania kolejnych instancji sklepu. Oczywiście zgodzę się z Tobą, że magento jest aplikacją bardziej wymagającą, ale nie doskwiera to bardzo mocno. Już niejedną prestę widzieliśmy, która się krztusiła przy ruchu 2-3kUU dziennie (mowa tu o "zwykłych" hostingach). Oczywiście wtedy i tak trzeba jakiegoś dobrego VPS'a czy dedyka, a przy takich rozwiązaniach to i magento poradzi sobie dobrze. Jak masz duży ruch to niezależnie od rozwiązania prędzej czy później będziesz musiał przygarnąć jakiegoś potwora czy nawet kilka potworów po to żeby sklep działał dobrze i nie zamulał klientom. Jeśli osiągnąłeś pułap 100-200 zamówień dziennie to strona webowa (sprzęt) nie jest największą bolączką. Za kulisami działa oprogramowanie fakturująco-magazynowe, księgowe, soft do obsługi zamówień i kilka innych, które również potrzebują odpowiedniej infrastruktury (kilkunastogigowe bazy, na których namiętnie działa kilkanaście osób). Musisz się martwić żebym im to działało dobrze. Sprzętowo to wbrew pozorom nie jest największy problem. Najgorsze jest oprogramwanie - musisz martwić się np. o licencje na MSSQL'a bo expressy są już za słabe, "Łindowsy", Subiekty (my do księgowości i faktur/ magazynu używamy oprogramowania firmy Insert), częste backupu wymagające dużych zasobów (bardzo wrażliwe dane). Wiadomo, że web ma dobrze działać i jest to bardzo ważne, ale większość magii dzieje się po drugiej stronie i też trzeba o wszystko zadbać. Jak wybierzesz PS to będzie łatwiej na początku i jeśli biznes nie rokuje na X-set zamówień dziennie to PS się sprawdzi jako rozwiązanie docelowe, ale jeśli przewidziany jest rozwój to prawdopodobnie skończy się migracją na inną, bardziej zaawansowaną platformę. Niestety migracja na coś innego w momencie gdy biznes kwitnie nie jest łatwym krokiem, a i też swoje kosztuje bo trzeba zachować kompatybilność z wieloma rzeczami ze starego systemu + ponownie wdrożyć ewentualne dodatkowe rzeczy, które zostały wdrożone na starszym systemie. Dochodzi jeszcze do tego przyzwyczajenie pracowników do starego systemu, które ciężko przełamać. Na ogół system obsługują nie informatycy a PM'owie. To nie jest tak, że PS jest zły. Zależy od firmy, która podejmie się sprzedaży online. PS na początku jest tańszy i przez jakiś czas będzie, ale w pewnym momencie jego utrzymanie staje się bardziej uciążliwe. Mageto na początku nie jest systemem łatwym, ale w pewnym momencie zaczyna wynagradzać za dużą ilość czasu poświęconego dla niego. Ja do niczego nie namawiam - kwestia indywidualnego podejścia i wyboru. Sami nie mamy żadnego z tych rozwiązań, a autorski system i wg nas jest to najlepsza opcja