T

Tak, trzeba go doznać, żeby uznawać za przejaw nieuczciwej konkurencji wskazywanie ewidentnych kłamstw w sloganach, a nad samymi kłamstwami przechodzić do porządku dziennego. Marketing nie musi (a wręcz nie może!) sprawadzać się do głoszenia jednoznacznych kłamstw. Co mam sprawdzać? Że cXc nie istnieje od 1990? Że u nich nie narodził się hosting? Że nie zapewniają 100% uptime-u? Przecież to jest oczywiste! Wyobraź sobie, że powstaje firma motoryzacyjna, wypuszcza jakieś auto produkowane na licencji i po dwóch latach ogłasza że: - Istnieją od 20 lat (bo od tylu lat działa jeden z udziałowców firmy, aczkolwiek w zupełnie innej branży) - To u nich narodziła się motoryzacja - Ich samochody są niezawodne w 100% i nie zepsują się nawet na sekundę Taka firma zostałaby wyśmiana i zapewne nie obeszłoby się bez procesów. "Czy wierzysz, że Twój serwer może działać cały rok bez sekundy przerwy? Jeżeli nie to najwyższy czas abyś to zmienił. Teraz cXc.PL oferuje 100% Uptime we wlasnym polskim Data Center" Co tu można rozumieć niejednoznacznie? Pomijam koszmarną stylistykę tych paru zdań i błędy interpunkcyjne.

Co to za zasady? Sam je wymyśliłeś? Zresztą nie wiem czy zauważyłeś, ale w dyskusjach na forum uczestniczą raczej osoby, a nie firmy. Nie trzeba nic testować żeby zauważyć kłamliwa hasła na ich stronie (że CXC jest "since 1990", że to u nich narodził się hosting, że zapewniają uptime 100% i inne).

Dlaczego? Wysłany 24/1/2006, 18:16: Gdziekolwiek będzie się trzymało backup, tam można się teoretycznie włamać (pomijająć rozwiązania typu streamer).

Przedstawiłeś rejestrowanie na osobę prywatną jako alternatywę do rejestrowania na firmę i wspomniałeś o ukryciu danych jako bonusie. Logiczny sens tego zdania jest taki, ze uważasz ujawnienie danych firmy we whois za problem.

No niestety nie mogę się z Toba zgodzić. Fakt, zawsze lepiej jest mieć własną maszynę, ale wcale nie taniej. Zauważ, że jeśli masz przynajmniej 2 maszynki, to możesz robić na nich wzajemne backupy, więc koszt spada prawie do zera.

A co to za problem dla firmy, że nie może ukryć danych we whois (które i tak w zasadzie są jawne)? Boisz się, że Cię Twoi klienci odwiedzą?

Nie sądzę, żeby było.

Nie myl. Istnienie i wysokość kwoty wolnej od podatku nie ma nic wspólnego z koniecznością zarejestrowania DG (lub jej brakiem).

1. Powyłączaj wszystkie usługi które nie będą Ci potrzebne (zahashuj odpowiednie wpisy w skryptach startowych, inetd.conf, gdziekolwiek), a najlepiej wręcz pousuwaj zbędne pakiety z serwera 2. Te których potrzebujesz skonfiguruj tak, żeby były możliwe trudno dostepne bez ograniczenia funkcjonalności, a w szczególności: - Pozwól na połączenia z SSH wyłącznie z Twoich adresów IP - Niech SQL nasłuchuje tylko na interfejsie lokalnym 3. Naucz się porządnie konfiguracji apache/php i aktualizuj na bieżąco (ten tandem to wielka kobyła w której groźne błędy pojawiają się dość często) 4. Naucz się konfigurować i kompilować jądro, w szczególności powyrzucaj z niego wszystko, co nie jest Ci potrzebne, spatchuj np. grsec (i skonfiguruj je sensownie) no i dbaj, żeby kernel był aktualny (tutaj też czesto pojawiają się bugi) 5. Programy, które kompilowałes ręcznie stale monitoruj i aktualizuj, te, które masz z pakietów możesz codziennie aktualizować automatycznie 6. Niech daemony nie działają z prawami roota, tylko zwykłego użytkownika Tyle na początek Wysłany 22/1/2006, 03:29: Czym wiecej zabezpieczen to lepiej i nigdy nie opierac sie na jednym zabezpieczeniu (wypowiedz lcamtufa bodajze). To stwierdzenie jest prawdziwe, ale umieszczenie SSH na niestandardowym porcie nie jest zabezpieczeniem. Jeśli ktoś będzie chciał je znaleźć to znajdzie obojętne na jakim porcie będzie -- co za różnica? Nie denerwuję się, prostuję tylko.

Bzdura. Firewall nie służy do wycinania działających usług! To jeden z bardziej szkodliwych mitów powtarzanych bezmyślnie od lat. Niepotrzebne usługi nalezy _wyłączyć_. Firewallem można np. ograniczyć dostęp do usług, które np. nie są udostępniane użytkownikom (jak wspomniane dalej SSH). Bind nie cierpi raczej na częste błędy krytyczne, po za tym można spokojnie użyć standardowej wersji z danej dystrybucji i aktualizować automatycznie. Po co na wysoki port, jak będzie filtrowane? Nie wycięta na firewallu, tylko nasłuchująca wyłącznie na interfejsie lokalnym. BREDNIE. O remote bugach nie słyszałeś?

Tak... Gentoo to w tej chwili cały czas raczej dystrybucja do zabawy, na workstację. To już nie do końca prawda. Istotnie standardowe pakiety w głównym repozytorium Debiana są kompilowane pod i386, ale nic nie stoi na przeszkodzie, żeby brać je z innego lub tworzyć własne, dostosowane do posiadanej maszynki (co zresztą warto zrobić z kluczowymi pakietami, w szczególności warto mieć własnoręcznie skompilowane jądro).

Gdyby najtańsze było dobre, to nikt by nie kupował droższego. Bardzo tanie konta mogą być dobre przez jakiś czas, ale wraz ze wzrostem liczby użytkowników (których przy niskich cenach trzeba "upakować" wielu) jakość może drastycznie się obniżyć. Pomyśl o tym.

Nie ma znaczenia ile zarabiasz, jeśli będziesz miał stronę, ofertę, będziesz świadczył usługi w sposób zorganizowany, to nie możesz tego robić tak po prostu. DG nie potrzebowałbyś, gdybyś np. kupił konto resellerskie na swój serwis, a niepotrzebną część zasobów odsprzedał trzem znajomym. Czujesz różnicę? Istnieje obowiązek podania danych firmy, jeśli dany usługodawca nie publikuje ich na swojej stronie, to nalezy podchodzić do niego z dużą rezerwą.

Jeśli chcesz odsprzedawać konta, to jest wręcz niezbędny, jeśli chcesz postawić kilka własnych serwisów, to niekoniecznie.

Mniejszym? Przecież konta resellerskie nie są zwykle istotnie tańsze od zwykłych kont (w przeliczeniu na np. 1 GB transferu) czyli końcowa oferta będzie droższa i gorsza. McD to złe porównanie -- oni tworzą swój produkt z półproduktów, wg. pewnych oryginalnych zasad. Konto resellerskie to w zasadzie gotowy produkt, a cała inwencja sprowadza się do podzielenia go na mniejsze części.

Próbowałeś użyć google? Jak długo szukałeś?

Strona.pl to prawdziwa nazwa tej domeny?

Bardzo podobnie, ciężko wskazać faworyta... chociaż ja bym wybrał EeasyISP. Ktoś zgadnie dlaczego?

Traceroute służy do pokazania trasy, no właśnie, a nie do uzyskiwania informacji o docelowym IP czy usługodawcy -- do tego służy głównie baza whois. Jedyne informacje jakie podaje traceroute o docelowym hoście to (w najlepszym razie) jego IP i wpis w domenie odwrotnej. Jeśli nie chce się zobaczyć trasy do hosta docelowego to nie ma żadnego powodu, żeby użyć traceroute (szczególnie, że - jak już wspomniałem - nie sprawdza ono zgodności wpisu w domenie odwrotne z wpisem w domenie prostej -- więc dowcipny admin może sobie "nazwać" router dowolnie, także "użyć" domeny której nie posiada).

Progreso (wcześniej pod nazwami civ.pl/konta.pl) istnieje ZTCP niewiele krócej niż Home. Dziwię się, że nie informują o tym w widocznym miejscu, ani nie piszą wiele o swojej historii, bo przecież mają o czym.

Litości... traceroute zwykle podaje wpis PTR bez sprawdzania zgodności z A/AAAA. Ogólnie używanie traceroute do sprawdzania docelowego hosta (a nie tych pomiędzy) jest niezbyt mądre -- to nie do tego służy. Żeby zrobić to o co pytasz trzeba przede wszystkim sprawdzić na jakie IP wskazuje badany host i sprawdzić to IP w bazie whois. Dodatkowo dla pewności można sprawdzić np. wpisy w domenie odwrotnej (PTR) i kilka innych drobiazgów. 04:16:22 neas@insane:~ host -t A streetracing.pl streetracing.pl has address 85.128.136.25 streetracing.pl mail is handled by 10 streetracing.pl. 04:16:34 neas@insane:~ host -t A www.streetracing.pl www.streetracing.pl has address 217.119.64.74 04:16:37 neas@insane:~ whois 85.128.136.25 | grep netname netname: NETART 04:16:58 neas@insane:~ whois 217.119.64.74 | grep netname netname: ETELPLNET 04:29:58 neas@insane:~ whois streetracing.pl [...] nservers: ns1.netart.pl.[85.128.128.10] ns2.netart.pl.[85.128.129.10] ns3.netart.pl.[85.128.130.10] [...] Wskazuje to na to, że domena jest kupiona w Netarcie, a strona hostowana w eTel, oraz ze właściciel domeny niewiedzieć czemu porobił niepełne wpisy (olał "@") w panelu Netartu, więc zapewne nie ma w eTel wykupionego serwera, tylko zwykły hosting, względnie nie umie tym serwerem administrować (w szczególności skonfigurować DNS). Traceroute (tracert) to nie jest, na litość boską, narzędzie do wypluwania usługodawców, tylko (przede wszystkim) do sprawdzania routingu pomiędzy Tobą, a podanym hostem. Ostatnie, co zwróci traceroute w formie innej niż gwiazdki (w przypadku standardowego uniksowego traceroute i większości klonów), to ostatni komputer/router/cokolwiek pomiędzy Tobą, a badanym hostem, który odpowiedział na zapytanie programu.

Użycie fns.sgh jako zapasowy DNS to dobry pomysł. Postawienie obu na jednej maszynie to nonsens (chociaż wielu wannabe-adminów tak niestety robi).

Nie widziałem jeszcze procesora, z którym byłyby jakiekolwiek problemy nie wynikające z winy użytkownika (tzn. z zastosowania złego chłodzenia, overlockingu (a w szczególności przesadnego podniesienia napięcia), fizycznego uszkodzenia przy zakładaniu radiatora itd.). Powtarzasz tylko mity produkowane przez overlockerów od 7 boleści, którym wstyd było się przyznać, że sami swoje CPU zepsuli.

Można coś bliżej o tych dotacjach?

Ale _dlaczego_?