megi

Nie hostował tylko przetwarzał I tak - małe sklepy internetowe też przetwarzają dane osobowe. Nie każdy zbiór danych osobowych trzeba rejestrować, ale każdy trzeba odpowiednio zabezpieczyć. Tak jak Bartek pisze: przepisy są nieżyciowe, sporo papierkologii, warto mieć jednak świadomość, że wymagania narzucone przez ustawę o ochronie danych osobowych nie dotyczą tylko dużych firm, ale wszystkich przetwarzających dane osobowe. Małych raczej nie kontrolują, chyba, że ktoś doniesie do GIODO.

Rozwiązania muszą być stosowne do zagrożeń wynikających z analizy ryzyka i w zakresie możliwości przetwarzającego. Innymi słowy trzeba dołożyć starań, aby zabezpieczyć dane, ale trzeba się kierować zdrowym rozsądkiem i w razie ewentualnej kontroli umieć przekazać swój punkt widzenia. Ciężko, żeby mały sklepik internetowy utrzymywał serwer dedykowany w zamkniętym boksie. Można byłoby odnieść wrażenie, że lepiej w ogóle nie prowadzić działalności niż przetwarzać dane osobowe, ale nie o to chodzi

MegiTeam to firma zajmująca się hostingiem Perla, Pythona i Ruby. Poszukujemy osoby na stanowisko Administrator systemu Wymagania: - dobra znajomość Linuksa z poziomu użytkownika (używamy Debiana) - znajomość konfiguracji serwerów www, smtp - umiejętność poprawnego wysławiania się - samodzielność w rozwiązywaniu problemów, umiejętność korzystania z wyszukiwarki - otwarty umysł, chęć rozwoju i pogłębiania wiedzy Mile widziane: - umiejętność programowania (w szczególności Bourne shell, Python, Perl i/lub Ruby) - znajomość zagadnien wirtualizacji (korzystamy z Linux VServer) - doświadczenie Jesteśmy zainteresowani zgłoszeniami zarówno od osób, które nie mają doświadczenia a chciałyby zostać administratorami, jak i tych już pracujących w tym zawodzie. Praca polega na opiece nad serwerami firmy, instalacji nowego oprogramowania, rozwijaniu naszego środowiska hostingowego a także pomocy klientom w rozwiązywaniu problemów (ciekawszych niż konfiguracja Outlooka Praca w Krakowie, w biurze na Wrocławskiej, domyślnie w godzinach 9-17, ale możliwe jest dostosowanie godzin. Możliwa również praca na część etatu. Wynagrodzenie 2K - 3,5K PLN brutto miesięcznie, forma zatrudnienia do uzgodnienia. Osoby zainteresowane proszę o przesłanie CV na adres praca@megiteam.pl do 20 grudnia 2009. Postaram się odpowiedzieć na wszystkie zgłoszenia

W Krakowie jest jeszcze Kei http://www.kei.pl/?stronka=dedicated/kolokacja, ale usługi kolokacji są tam świadczone przy okazji ich głównej działalności. Kiedyś nie było dostępu do własnych serwerów, nie wiem jak teraz. Wpiszę się w ogólny trend i też polecę szarą za m.in. świetny kontakt i elastyczne podejście.

Ups, trochę inaczej zrozumiałam sens wcześniejszego zdania

Hmm, MTA z pudełka tak nie robią, chyba, że podasz jakiś przykład, to jestem gotowa zmienić zdanie. Jakieś dodatkowe filtry, amavis i te okolice to możliwe. Naprawdę? :> Envelope sender to jest nadawca podawany na etapie sesji SMTP czyli to o czym pisaliście z p (MAIL FROM: <cośtam@cośtam>) i to jest widoczne jako return-path w pełnych nagłówkach maila, xorg pisał o polu from widocznym standardowo w nagłówkach w programie pocztowym czyli o nagłówku, który z perspektywy smtp jest treścią maila. Tak, zgadza się - to nie jest to samo. Właśnie o tym pisałam. Blokowanie możliwości uwierzytelnienia się jednym adresem a wysyłanie z innego tutaj nie pomoże, tak samo jak ustawienie SPFa. Nie wieszałabym psów na Hekko za konfigurację MTA

Po tym jak xorg napisał, że chodzi o from i replay-to oraz o nieobeznanych userach, którzy nie potrafią sprawdzić skąd naprawdę przyszedł mail, łatwo się domyślić, że nie chodzi o envelope sender, który jest później widoczny jako return-path a nagłówki idące jako treść maila Te można ustawić dowolnie. Poza tym ograniczenia nałożone na smtp nie pomogą jeżeli maile wysyłane są lokalnie przez sendmaila. Co to da w tej sytuacji?

Twoje wymagania może i są niewielkie, ale wymagania rozwiązań, o których piszesz już nie Ani Java ani Railsy nie nadają się do małych aplikacji, m.in. ze względu na duże zapotrzebowanie na pamięć. Sądzę, że powinieneś pomyśleć o Django Bliżej mu do Javy niż PHP, przyjemnie się w tym pisze (chociaż to subiektywne odczucie), pamięci zajmuje sporo mniej, o hosting łatwiej i jest sporo tańszy (od biedy uruchomisz na jakimś współdzielonym jako CGI).

Ja Ci zdradzę - pogooglać http://pecl.php.net/package/htscanner

A z drugiej strony czy webh.pl zabrania utrzymywania domen na innych DNSach, blokuje takie domeny? Nie, więc jest to zachowanie dopuszczalne i nie ma winy klienta. Nie wszystko musi być skrupulatnie w regulaminie opisane. Bycie fair wobec klientów się opłaca Zgadzam się

Nie, piszesz to pierwszy raz Może chciałeś to napisać, ale z tego co napisałeś wcześniej w ogóle to nie wynika. Przez domenę TLD rozumiesz np. xxx.pl? Skoro wydelegowanie xxx.pl na zewnętrzne DNSy można przeboleć, to dlaczego napisałeś: Jeśli ktoś robi tak, to sam się prosi o problemy. Gdzie pisałeś o subdomenach? Kto w ogóle pisał o subdomenach? Klient przekierował domenę na IP serwera, IP się zmieniło a wy wmawiacie gościowi, że to, że nie działa mu strona to jego wina. O jakiej specyfikacji mówisz? Zresztą zawsze to jedno zapytanie do DNSów mniej Jeżeli zakładasz z góry, że użytkownik coś zepsuje, to może lepiej w ogóle nie dawać mu możliwości edycji rekordów? To była ironia Tak, tyle, że w temacie nieutrzymywania domeny na DNSach dostawcy hostingu a nie problemów jakie stwarzają klienci

Chcesz się licytować, kto pracował w firmie z większą liczbą klientów? Nie uogólniaj. Dla ustalenia uwagi: *nie* mówimy o przypadkach, gdy klient sam coś sobie zepsuł, jak ten z przykładu Fiercia, i ma pretencje do usługodawcy. Mówimy o jednym konkretnym przypadku, gdy klient przekierował domenę na IP swojego hostingu a firma cichaczem zmieniła to IP. Napisałeś, że niewydelegowanie domeny na DNSy firmy hostingowej to bycie mądrzejszym "od ludzi, którzy po coś wymyślili NSy" i że Ty w duchu śmiejesz się z takich klientów. Jeżeli nie jesteś w stanie wyobrazić sobie, dlaczego ktoś miałby chcieć utrzymywać domenę na innych DNSach, to nie mów, że to ja z niewielką liczbą ludzi współpracowałam. Nie takie potrzeby mają klienci. Nie ma obowiązku korzystania z tych a nie innych DNSów a firmy hostingowe powinny się z tym liczyć.

Zapomniałeś dopisać, że fanaberią jest ustawienie na DNSach na hostingowym mail.domena IN A IP_konta_u_dostawcy_poczty domena IN MX mail.domena Nikt nie ma obowiązku mnie informować, że zmieniło się IP konta na którym mam pocztę, prawda? Ale nie wszyscy używają DA a rozmowa już zboczyła z tematu webh Nie tak znowu mało firm ma własne panele. Bo stosunek jakości do ceny go zadowala a to na czym mu zależy np. pocztę trzyma u innego dostawcy. Są klienci, którzy żyją z poczty, są tacy, co mają CRMa w subdomenie na serwerze innego dostawcy niż strona i DNSy utrzymują tam gdzie są pewni ich działania. Oczywiście jest możliwe, że DNSy tego innego dostawcy będą szwankować, tak samo jak to, że szwankować będą DNSy dostawcy hostingu. To nie jest argument za tym, żeby trzymać akurat tam gdzie stronę WWW Czy ja dobrze pamiętam, że pisałeś kiedyś, że nie pracujesz w żadnej firmie hostingowej? Bo piszesz tak, jakbyś pracował w jakimś hostingu dla mas Jacy potrafią być klienci nie musisz mi mówić - zanim założyłam własną DG pracowałam 3 lata w tech supporcie w firmach hostingowych. Wiem, że klienci tracą miliony na każdej przerwie, że jak im się czegoś nie zrobi to się wyniosą, albo, że zawsze wszystko na localhoscie działa tylko na hostingu nie. Mimo wszystko jestem przeciwniczką twierdzenia, że co złego to klient. Obydwie strony potrafią się brzydko zachować. Ke? Utrzymanie domeny (w domyśle na DNSach) = wydelegowanie domeny na te DNSy. Nie wiem do czego pijesz z tą subdomeną.

Powody dla których ktoś kieruje domenę na IP są *co najmniej* 4: - bo ma pocztę u innego dostawcy niż stronę - gdzie powinien trzymać DNSy, żeby nie prosić się o kłopoty? - bo jeden dostawca daje mu możliwość pełnego zarządzania wpisami w DNSach a ten u którego ma hosting akurat nie ma takiego bajeru - bo nie ufa stabilności DNSów innego dostawcy - i najlepszy z nich: bo tak - nie ma obowiązku trzymania domeny na DNSach dostawcy hostingu Nigdy nikomu nie polecaliście freedns.sgh.waw.pl? Zmieniając IP na które ludzie mają przekierowane domeny a później upierając się, że przecież nie mam obowiązku nikogo o tym informować, jasno mówię klientom, gdzie mam to, że coś może im przestać działać. Z takim podejściem to można krzaka prowadzić. Wysłanie maila z informacją o nowym IP nic nie kosztuje, a jeżeli nawet nie jest obowiązkiem dostawcy to na pewno jest w dobrym tonie. Żeby było jasne, to nie mówie konkretnie o webh, bo ciężko byłoby mi uwierzyć w złą wolę tej firmy. Utrzymywanie domeny na innych DNSach nie jest kombinowaniem, ale oczywiście zawsze winny jest klient Wyjaśnij, proszę, po co ludzie wymyślili NSy i jaki to ma związek z koniecznością utrzymywania domeny na DNSach dostawcy hostingu. To akurat nie najlepiej świadczy o Tobie a nie tych klientach. Jesteś, jak widzę, na etapie na którym wydaje Ci się, że coś wiesz i czujesz się lepszy z tego powodu. Napisz, proszę, z czyich DNSów powinnam korzystać chcąc utrzymywać pocztę u innego dostawcy niż stronę WWW. Uprzedzając: tak, MXa kieruje się na domenę, nie na IP, więc od biedy mogę podać nazwę serwera pocztowego dostawcy, ale przecież o zmianie hostname też nie ma obowiązku informować.

Nie dostajesz gotowego środowiska pod hosting WWW, ale możesz je sobie sam zainstalować a Boss nie sprecyzował, że hosting=gotowiec Bliżej EC2 do jego wymagań niż S3. Jednoliterowców uprasza się o nie wymądrzanie się

Dokładnie. I to nie jest hosting w odniesieniu do tego o co Bossowi chodziło, czy w ogóle?

To funkcjonalnie nie jest coś w rodzaju VPSa?

Pisanie "leży i kwiczy" tym bardziej nic nikomu nie mówi, zwłaszcza, że Mamuśka napisała, że leży nazwa.pl (co sugeruje, że cała) a okazuje się, że "jeden (!) z trzech (!) serwerów (...) nie chciał rozmawiać" (cokolwiek to znaczy).

A kto pisał o S3? IMHO Riklaunimowi o EC2 chodziło. http://aws.amazon.com/ec2/

W ofercie prawie każdej firmy hostingowej jest własny adres IP, ale czy w prawie każdej firmie hostingowej poczta będzie *wychodzić* z zakupionego adresu? Tzn. czy firmy uruchamiają serwer SMTP per IP? Bo inaczej i tak wszystkie maila będą wychodzić z tego samego adresu (połączenia inicjowane z serwera wychodzą z pierwszym IP interfejsu).

Jeżeli na obydwu serwerach masz dostęp do kont po IMAPie to w ten sposób bez większych problemów możesz przenieść zawartość skrzynek. Jeżeli tych kont masz wiele zawsze możesz to przenoszenie oskryptować :>

Problem nie wynika z kłopotów z zasilaniem czy przeciętych światłowodów, nie dotyczy tylko ISP w Krakowie. RIPE przydziela nowe 32bitowe ASy. Quagga (oprogramowanie do routingu, BGP i te sprawy) wywala się gdy dostanie taki AS w ścieżce. Problem jest ogólnointernetowy i dotyczy tych providerów, którzy używają Quaggi z tym bugiem. http://marlow925.blogspot.com/2009/04/quagga-bgp-crash.html http://vyatta.org/forum/viewtopic.php?t=19...asc&start=0 Patch http://marc.info/?l=quagga-dev&m=123364779626078&w=2

W takim przypadku serwer http robi za proxy i raczej mało go obchodzi to co po drugiej stronie słucha. Na czym ten problem z Railsami polegał? Na pewno był to problem Lighty'ego?

Spokojnie, nie pisałam do Ciebie przecież. Cytat jest p i pytanie też do niego.

Tak, wszystko. Dalsze uświadamianie Sary nie ma sensu - jest odporna na wiedzę. Napisz mi dlaczego lepiej udostępniać klientom sftp zamiast ftps. Chodzi Ci o to, że trzeba otworzyć jakiś zakres portów na firewallu czy o coś więcej? Pudełkowe sftp z kolei nie jest ograniczone do katalogu użytkownika.