kafi

Tak mi się przypomniała niedawna dyskusja http://www.webhostingtalk.pl/topic/53225-promocja-na-serwery-dedykowane-w-slask-data-center-sldc/page-2?do=findComment&comment=455076

http://sjp.pwn.pl/sjp/do-dnia;3027957.html

Do takich celów polecam zainteresować się ioncube24

Zobacz, czy podczas pracy na AutoCadzie zwiększy ci się prędkość procesora do maksymalnej (Core Speed). Na chwilę obecną masz ustawioną najniższą z możliwych (1596 z 3300). Jeśli nie zwiększy się wraz ze wzrostem obciążenia, to oznacza, że masz nieoptymalnie ustawione zarządzanie energią i warto z tym będzie powalczyć (instalując stosowne narzędzia lub wyłączając c/pstates w BIOS/UEFI.

Jeżeli do sprawdzania logów transakcji EPP przywiązujecie podobną wagę jak do sprawdzania logów własnego MTA/MDA, to pozostaje tylko współczuć waszym klientom... No bo przecież to domain:renew zostało wysłane, więc o co marudzącemu klientowi chodzi? A to, że nie dotarło do registry...

Czyli jednak coś związanego z wirtualizacją, tylko jak się okazało, troszkę z innej strony. 1. Czy z wewnątrz kontenerów lxc też obserwujesz te problemy? 2. Ile masz uruchomionych kontenerów na pierwszym (nie działającym), a ile na drugim (działającym)? 3. Czy po wyłączeniu kilku kontenerów problem nie "ustąpi"? Przy LXC wszystkie kontenery współdzielą dbus, więc może po prostu wszystkie razem przekraczają 512 połączeń? @Archi - obecna w Debianie Stable wersja DBUS ma limit 512 połączeń. Dopiero w stretch i sid poprawili to do 4k. http://sources.debian.net/src/systemd/215-17%2Bdeb8u2/src/core/dbus.c/ vs http://sources.debian.net/src/systemd/227-2/src/core/dbus.c/ Więc jeżeli po zamknięciu kilku kontenerów będzie działać, to jedyne, co autorowi pozostanie, to albo ręcznie przekompilować systemd/dbus, albo spróbować aktualizacji do testowego stretcha.

To jest vps czy dedyk?

http://bfy.tw/3Hmd i http://bfy.tw/3Hmj

Istotą usług vps jest to, że zasoby są współdzielone z innymi i czasem trzeba przymknąć oko na odrobinkę niewygód z tego wynikających. Są różne klasy usług i każdy decyduje, jak krytyczna pod wieloma względami (m.in. ekonomicznym, technicznym, niezawodnościowym) jest potrzeba, do której dobierasz ową usługę. Taki obrazowy analogiczny przykład: chcesz dojechać z Warszawy do Krakowa. I możesz telepać się pociągiem osobowym (niewygodnie, pełno ludzi jadących w ruchu lokalnym, męcząco - ciągłe zatrzymywanie się, wymagane przesiadki, zmarnowany cały dzień) - no ale najtaniej; możesz jechać pociągiem-włóczęgą TLK przez Radom-Kielce (droższy, jedzie szybciej niż osobówka - ale okrężną trasą, niewygodne ośmioosobowe przedziały gdzie ktoś postury lekko bardziej miśkowej zajmuje dwa miejsca, do tego pełno ludzi więc czasem jest problem z jakimkolwiek miejscem siedzącym - to jest dopiero overselling ); możesz do tego pociągu TLK troszkę dopłacić za pierwszą klasę (ale poza zmianą przedziałów na 6-osobowe nic się nie zmienia). Możesz też dopłacić do Pendolino i jechać w znacznie lepszych warunkach; ale jak trafisz na męczące otoczenie (np. gromadkę dzieciaków, albo głośno dyskutujących polityków) to też będzie źle. Ale i na to jest metoda - wykupić przedział menedżerski lub wziąć taksówkę. Tak samo i przy serwerach - albo suwak idzie w kierunku ceny, albo jakości (wynikającej m.in. z rzeczywistych rozliczalnych gwarancji zasobów). A co do samego RPi jako serwer - to wszystko zależy od zastosowań. Przy mizernym łączu do nauki będzie to także ciężkie (chociażby dlatego, że aby coś zainstalować, to trzeba będzie dłuugo czekać). Ale jeśli potrzeba tego wymaga, chociażby ze względów politycznych (NAS ze zdjęciami które niebezpiecznie jest wysyłać w świat), to czemu nie? Wiadomo, są specjalizowane urządzenia i jeżeli myślimy o przyszłości, to warto kupić właśnie je, choćby ze względu na support, ale jak mamy zbędne, walające się gdzieś Pi?

RC8 tak precyzując I tak na tę chwilę jest problem, chociażby z kompilacją, bo nie działa poprawnie pear.php.net. Co za tym idzie trzeba troszkę Makefile poprawić aby nie wykładał się na błędzie, no i nie ma dostępu do pear i częściowo pecl (bo menedżer pecl jest składnikiem menedżera pear).

Nie. Adres gatewaya 46.x.x.1 nie jest w podsieci 46.x.x.208/29 - czyli nie jest nijak osiągalny. Dla takiej konfiguracji najprawdopodobniej jego adresem będzie pierwszy lub ostatni użyteczny z tej klasy - czyli .209 lub .214.

Sprawdź poleceniem uptime czas działania serwera i poszukaj w /var/log/syslog i /var/log/messages jakichś informacji z tego czasu.

To jest VPS czy dedyk? A osobom proponującym "zaorać" serwer i takie tam inne ciekawe rady proponuję zajrzeć do źródeł skryptu init.d odpalającego ejabberd: https://github.com/rivendale2010/content/wiki/etc%5Cinit.d%5Cejabberd a następnie zaorać sobie troszkę neuronów w mózgu. W wersji tl;dr - wpisy su odnośnie ejabberd nie są niczym złym (bo tak ejabberd jest startowany); a restart mógł być spowodowany - w przypadku serwera dedykowanego np. awarią zasilania albo działaniem operatora serwerowni; w przypadku vpsa - czymś po stronie usługodawcy (np. aktualizacją oprogramowania na serwerze).

Dla mnie to po prostu prowokacja jakiegoś dowcipnisia grubymi nićmi szyta

Z niczym. Interfejs sieciowy TAP zapewni ci właśnie ową "sieć lokalną".

dev tap

rtmpdump uruchamiany w cronie co 10 minut?

Zapewne dlatego, że... Niestety, adresacja należąca do online.net niestety nie cieszy się dobrą reputacją gdziekolwiek. Napisz do ich supportu. Podadzą ci tam linka gdzie należy się zarejestrować i później popchną wniosek. Ale lepiej będzie ci chyba po prostu zmienić providera.

Zasadniczo na serwerze powinieneś wyłączyć opcję pushowania domyślnej trasy/gatewaya do klientów. Jeśli już upierasz się, żeby zrobić to po stronie klienta, to https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway

1) PPTP, jak sama nazwa wskazuje, to Point-to-Point, więc nie ma tam formalnie czegoś takiego, jak sieć. Oczywiście, można próbować przydzielać klientom adresy z maską inną niż /32, ale ciężkie będzie ustawienie tego tak, aby była łączność między tymi klientami. 2) PPTP technicznie nie wymusza jakiejkolwiek adresacji, można stosować dowolną. 3) Przez PPTP ciężko przepchnąć multicast/broadcast - a m.in. tak komunikuje się Windowsowa obsługa udostępniania plików. 4) Z implementacją kliencką PPTP jest zasadniczo taki problem, że pozwala przyjąć albo trasę domyślną, albo nie modyfikować trasy wcale*. W efekcie albo koncentrator będzie robił za proxy dostępowe do internetu dla wszystkich klientów, albo ci klienci będą musieli ręcznie (z wiersza poleceń) po każdym połączeniu dodawać sobie statyczny routing. 5) Lekarstwem na te problemy jest faktycznie OpenVPN - pozwala zrobić ładną sieć, dodawać częściowe trasy (w razie potrzeby nawet domyślną) i po zainstalowaniu i poprawnym skonfigurowaniu na komputerze (a w sumie można zrobić ładny instalatorek provisioningowanego klienta) tak naprawdę wszystko działa. Jak ktoś się uprze, to i jako usługę systemową da się to postawić. * - protokół oczywiście przewiduje push-route przez koncentrator, ale część implementacji klienckich to olewa i nie ma gwarancji, że to będzie działać poprawnie na wszystkich urządzeniach.

Jako ficzer dla paranoidalnych świadomych użytkowników hostingowych może być. Jako obowiązek niekoniecznie. W środowisku hostingowym jest zbyt dużo sytuacji wielodostępu do panelu administracyjnego. Ot np. - udostępnić konto programiście, developerowi... lub po prostu kilka osób w różnych działach firmy. A jednym z głównych założeń jest to, że użytkownik posiada JEDEN generator tokenów, który nosi zawsze przy sobie. Do tego dochodzi cała zabawa związana z helpdeskiem - zapomniałem hasła i tokenu.

Od kiedy to certyfikaty DV poświadczają jakąkolwiek wiarygodność? Przecież sama nazwa mówi, że to tylko "domain validated".

Czasem nie trzeba mieć ani słów kluczowych, ani dziwnego adresu. Przykład takiego o2. Adresacja o2 bardzo często trafia na listy RBL. A co na zgłoszenie o tym odpowiada ich support? Że nie mają wpływu na zbyt restrykcyjną politykę antyspamową odbiorcy i nie są winni tego, że poczta od nich jest niedostarczana.

A jaka usługa ci nie działa? traceroute to ***.***.*** (192.166.218.***), 64 hops max, 52 byte packets 1 192.168.254.254 (192.168.254.254) 15.046 ms 0.823 ms 0.761 ms 2 192.168.99.254 (192.168.99.254) 7.209 ms 11.103 ms 9.742 ms 3 * * * 4 * * * 5 * * * 6 user-89-108-198-2.mobile.playmobile.pl (89.108.198.2) 35.104 ms 26.603 ms 37.246 ms 7 89.108.194.83 (89.108.194.83) 36.631 ms 32.430 ms 38.975 ms 8 iwacom.thinx.pl (212.91.0.97) 34.195 ms 35.667 ms 34.951 ms 9 router.teredo.pl (193.227.116.242) 30.986 ms 32.555 ms 27.920 ms 10 192-166-218-3.arpa.teredo.pl (192.166.218.3) 36.156 ms 26.358 ms 28.946 ms 11 ***.***.*** (192.166.218.***) 45.023 ms 28.425 ms 35.916 ms

Prosta informacja prasowa (a pod to może podchodzić owe wyszczególnienie zmian w grze bez głębszego autorskiego komentarza) nie jest chroniona przez prawo autorskie, więc nie można jej ukraść.