kafi

Dyrektywy umieść w httpd.conf, a nie htaccess. Do tego pamiętaj, że katalog /skrypty/status musi umożliwiać dostęp rx dla użytkownika www-data.

MSSQL EE to raczej wskazuje nie na Express, a na Enterprise Edition, także wg samego Microsoftu PS: Windows musi być koniecznie 32bitowy? Pytam, gdyż najnowsza 2008-R2, która jest przez usługodawców i sam MS preferowana, to tylko x64.

Szukasz dedyka POD aplikacje, których licencje JUŻ POSIADASZ, czy też szukasz dedyka z licencjami na wymienione przez ciebie aplikacje? Tak swoją drogą - to nie wiem, czy dobrym pomysłem jest pchanie zasobożernego tomcata wspólnie z podobnie zasobożernymi dwoma silnikami baz danych.

Alias / ScriptAlias

Nie może. Jeśli jest CNAME'm, to zgodnie z RFC nie może mieć żadnego innego rekordu. A pod domena.pl będzie miał m.in. SOA i NS, więc nie przejdzie. A jeśli zrobi sobie cos.domena.pl CNAME domena.no-ip.org, to będzie miał widoczną stronę także i pod cos.domena.pl. Kwestia tylko konfiguracji wirtualek apaczowych. PS: A te magiczne skrypty, które opisujesz, to właśnie podstawa działania providerów Dynamic-DNS

W skrócie - adres.pl nie przekierujesz. Natomiast coś.adres.pl możesz przekierować rekordem CNAME na cos.no-ip.org, które to będziesz sobie via dynamic-dns aktualizował.

Najwidoczniej nie, bo taka kwota 1) powoduje już, że banalnych pytań klienta to nie wypada olewać, 2) nie jest jeszcze opłacalna, żeby zatrudniać multum osób w helpdesku pracującym 24/7.

Sprowadzając do absurdu - jak koparka urwie twojemu klientowi kabel z łączem do jego providera internetowego, to też i nasza usługa nie będzie dostępna dla klienta. To oznacza, że mam mu wtedy, jako jego serwerodawca, to dać on-demand i to za totalne friko radioport bezpośredni w ciągu 5min.?

Kwestia tego, co rozumiemy pod pojęciem uptime Bo jeśli to jest to, co zwróci nam komenda uptime na serwerze-hoście, to cóż. Robiąc wirtualizacyjny failover-cluster na VMware da się to zrobić jak najbardziej

Aha - przyznam, nie doczytałem twoich poprzednich postów i zmyliło mnie troszkę ----- Zapewne to, że twoja adresacja została na głowowym firewallu permanentnie (i to nie tylko ruch icmp, ale całość) wycięta.

Podaj mi waść jakieś RFC, które zmusza docelowe urządzenie sieciowe do odpowiedzi ICMP-Echo-Reply Raczej nie uda się - a tu przypuszczam komunikacja ICMP została wycięta przez firewalla.

Nie da się zlikwidować, więc można dołożyć jeszcze parę nowych, i potem zapętli się to mówiąc - że została zawarta umowa do czerwca 2011 z innymiż to firmami... Ciekawa strategia. Jakoś nie przypominam sobie, żeby tą historyczną zaszłością nierozwiązywalnych czasowych umów objęte były czy to redhosti, czy to actio.

No i tak wymanipulowałeś, że docelowy serwer poczty stwierdził, że podszywasz się pod bardzo znany serwer poczty, którym z pewnością nie jesteś, więc spokojnie można odfiltrować od ciebie maile. Zadbaj o to, żeby wszystko do siebie pasowało - hostname & revdns & adres ip & ehlo. Wtedy obstawiam, że twoje problemy ustąpią.

Czemu twój serwer przedstawia się HELO poczta.onet.pl ? Received: from poczta.onet.pl (static.82.246.63.178.clients.your-server.de [178.63.246.82])

Sednem sprawy są twoje wymagania. Czego oczekujesz od tej aplikacji? Jeśli to ma być wizytówka, w której raz na rok się coś zmieni, to nie ma najmniejszego sensu wymyślać koła na nowo, i warto wdrożyć jakieś sprawdzone rozwiązanie CMS. Będzie i tańsze, i szybsze implementacyjnie, i paradoksalnie bezpieczniejsze. A zaoszczędzone parę groszy można przeznaczyć na lepszego grafika/kodera. Zmienia się to diametralnie w przypadku, gdy (choćby planujesz) jakieś nietypowe funkcjonalności. Przykładowo, żeby wyświetlał ci się status i parametry serwerów; albo jakaś integracja z innymi systemami (w stylu - nie wyświetlimy klientowi zakładki SERWERY VPS bo akurat nie mamy wolnych slotów na hoście; albo z oferty tymczasowo "znika" jedna z konfiguracji, bo akurat skończyła się dostępność w magazynie) - tu jak najbardziej warto iść w dedykowane rozwiązania pod siebie. Ale wtedy koniecznie z dokumentacją przed- i powykonawczą, żeby dalszy rozwój można było dokonać samemu / zlecić innej firmie. Ja ze swojej strony polecił bym wspomniane wcześniej Contao/typolight - ale zrozumienie jego filozofii może być nieco trudnawe. Za to potem z górki; ewentualnie tyci łatwiejszego Drupala; ewentualnie typo3 - ale to trzeba by mieć wybitnie duże wymagania, bo to straszna kobyła już jest.

Ale przecież taką funkcjonalność zapewni większość darmowych CMSów. Więc po co wydawać na wynalezienie takich wybitnie szablonowych możliwości kupę forsy?

Komputer vs serwer to porównanie niczym samochód vs samochód dostawczy. Teoretycznie jedno i drugie posiada koła, jeździ, no i zarówno jednym, jak i drugim można ładunek przewieźć. Więc po co przepłacać ? Ano zapewne to, że dostawczy ma jakieś takie ficzery ułatwiające przewóz akurat ładunków. Tak samo i serwer - posiada zazwyczaj jakieś choćby częściowe zdalne zarządzanie, posiada też zazwyczaj lepszej jakości zasilacz nie wybuchający pod wpływem długiej dwudziestoczterogodzinnej pracy, sama mobo wykonana jest z lepszej jakości części (głównie kondensatorów), zazwyczaj też ma dodany jakiś porządniejsiejszy kontroler dyskowy (często SAS). Dochodzi jeszcze kwestia zaprojektowania pod kątem redundantności (dwa hot-swapowe zasilacze, hotswapowe backplane do dysków). I parę jeszcze jakiś innych rzeczy się znajdzie.

Widocznie nie są zainteresowani współpracą. W sumie to także ich prawo... Powodzenia Ale widząc takie podejście, jak i też wcześniejsze posty, to nic dziwnego, że nie chcą mieć nic wspólnego z takim xxxxxx.

To postaw na nim tego torentośmiecia i bądź happy. Oczywiście o ile wytrzyma to twój router, styk ciebie z usługodawcą (modem), styk usługodawcy z tobą (port w dslamie/stacji docsis) no i dalszy tranzyt usługodawcy. Bo śmiem wątpić, że wykorzystywane w soho urządzenia poradzą sobie z takim natłokiem pakietów. Bo zdaje sie nie jest ci w stanie nic uświadomić, że nikt nie będzie ci sponsorował takiej machiny zarżynającej urządzenia sieciowe (trochę tych pac/per/sec tam idzie...) za psie grosze.

Wypadało by czytać ze zrozumieniem... Czyli dokładnie to, co ty chcesz.

Jeśli to ma działać jako serwer SIP, to nie jest dobrym pomysłem, żeby to było transoceaniczne połączenie z latencją średnią 100ms i dużym prawdopodobieństwem dropów. Sugerował bym to umieścić w Polsce lub gdzieś w pobliżu (np. jakieś Niemcy, etc.) A odnośnie technologii wirtualizacyjnych: z ISO zainstalujesz to na jakiejś pełnej wirtualizacji - np. vmware. Na OpenVZ też ci się powinno udać, ale instalacja na źródłowym CentOSie (link) Jedyne, na co musisz szczególnie zwrócić uwagę, jest to, czy twój potencjalny usługodawca nie limituje ilości pakietów UDP. Bo jeśli tak, to będziesz miał małą czkawkę.

BlueMan - smarthost to smarthost - jego zadaniem jest właśnie relay przychodzącej poczty, która nie jest opatrzona autoryzacją SMTP, bo i jak. Najprostsze z najprostszych na Postfiksie masz opisane tutaj: http://www.jimmy.co.at/weblog/?p=53 Na innych daemonach pocztowych będzie to wyglądać dosyć podobnie. A jeśli chcesz mieć już wybitne security, to wytnij sobie tam na firewallu ruch przychodzący na porcie 25 spoza twojego adresu IP.

Cóż. Zaszyfrowany przez OpenSSL tar z backupem mojego serwera (dla wszystkich "postronnych" po prostu śmietnik) na pewno naruszy kwestię praw autorskich. Nie ma to jak dobre słowo poprawiające na dobranoc humorek

No chyba właśnie o to chodzi, szczególnie o Bo resztę to jeszcze niech tam - da się jakoś zrozumieć. Ale blokady tych dwóch typów "stron" (choć tu powinno być - wykorzystania serwerów do tych celów) to właśnie cecha charakterystyczna hostingów "bez limitu". I chyba o to chodziło Lan Hikariemu.

wood, nie wpadłeś w swoich wybitnych mądrościach na jeden arcyciekawy pomysł. Że w opisanej przez ciebie sytuacji... po prostu można od owej Multimedii dokupić trochę więcej łącza? Obstawiam, że trunk i tak jest po Eth/1000-FX (ciężko obecnie nawet dostać wkładkę 100-FX - bo jest praktycznie po tej samej cenie co i 1000, a większość urządzeń to SFPki ma jednak giga), więc problemem nie do przejścia to nie jest. Jeśli nawet, to jej wymiana, albo zrobienie agregacji kilku strumieni to nie jest zbyt duży problem. Kwestia tylko owych kosztów dodatkowych, o których netdc pisał.