regdos

Z ostatniego zdarzenia z hekko mam 2 opinie jedną pozytywna druga negatywą. S1 trafił do RBL-a najpierw do spamcop i dość szybko dostałem informację, ze w ciągu 10h będzie usunięte. Niestety trafił też do uceprotect (http://www.uceprotect.net/en/rblcheck.php?ipr=91.203.135.50), gdzie jak wiadomo zasady usunięcia są dość niemiłe 7 dni lub 50 Euro, tutaj na Ticketa nie dostałem odpowiedzi tylko musiałem dzwonić. Po zgłoszeniu problemu (z uceprotect korzysta m.in. home.pl) zostałem poinformoawny, że rozwiązaniem jest poczekać tydzień !!! i że nie planują ani zmiany IP ani zapłacenia 50 Euro. Dopiero moje usilne naleganie, że to nie jest normalne żeby klienci przez tydzień nie mogli korzystać z poczty spowodowało to, że dostałem propozycje przejścia na s2. Reasumując: minus: za podejście a raczej brak działania w celu rozwiązania problemu czyli ununięcia s1 z uceprotect (bo w końcu osobom, którzy korzystają z poczty na s1 nie działa ona poprawnie) plus: za skuteczne i szybkie przeniesienie na s2

No to pokaż mi w regulaminach firm hostingowych punkt gwarantujący przywrócenie danych sprzed awarii. Jest to tak naprawdę fizycznie niemożliwe, bo jezeli backup robi się o godz. np. 2:00 a cały dzień poświęcę na dodanie domeny, dodanie kont pocztowych, wgranie skryptów, wypełnienie treścią CMS-a, konfiguracje, itp a o godzinie 23:00 padnie dysk a na złość nawet oba w macierzy to firma nawet jak by się najbardziej starała nie przywróci Ci tych zrobionych rzeczy. Sytuacje jest wręcz odwrotna, przykład pierwszy z brzegu prohost.pl e) Operator nie ponosi odpowiedzialności za szkody wyrządzone Abonentowi, powstałe w wyniku: - utraty danych Abonenta - utraty lub błędnego wykonania kopi bezpieczeństwa - awarii podzespołów serwera - awarii łącz internetowych - awarii energetycznych - działania siły wyższej (kataklizmy, tornado, powodzie, itp.) - braku ciągłości usług nie z winy Operatora Faktycznie jedyne konsekwencje to nadszarpnięta opinia ale to Ci danych nie przywróci. Tak naprawdę jedyne rozwiązanie bezpiecznych danych to własny backup.

Jak nie jesteś pewny lub nie wiesz to nie pisz. W takich wypadkach pytający ludzie chcą uzyskać konkretną *prawdziwą* informację na swoje pytanie a nie gdybanie. W DA haseł do kont pocztowych trzymane są w: /etc/virtual/*domena*/passwd, hasła są oczywiście kodowane

A pokaż mi w regulaminach, który usługodawca odpowiada za bezpieczeństwo umieszczonych danych na serwerach i za stratę w przypadku awarii ? Nawet jeśli to do kwoty za jaką został wykupiony hosting.

Normalnie. hekko.pl ten sam problem.

Jak chcesz możesz sobie zarejestrować domenę xyz.pl i potem oddawać/odsprzedawać subdomeny. W przypadku niektórych domen NASK uznał, że są na tyle ogólne, że wciągną je na listę domen funkcjonalnych do rejestracji poprzez partnerów. Z innymi domenami NASK przekazał zarządzanie innym instytucją np. art.pl do ICM. Podobnie jest z domenami regionalnymi niektóre obsługuje NASK, a niektóre zostały przekazane do instytucji związanych z miastem np. poznan.pl jest zarządzany przez UAM i oni ustalają ceny (http://www.domeny.poznan.pl/)

moja literówka, tak /etc czyli /etc/webmin/miniserv.conf

/etc/webmin/miniserv.conf

Co się tyczy uebi miau nie wiem, której wersji Państwo używają ale jak jeszcze korzystałem z usług hostings.pl to występował błąd w Uebi a admini twierdzili, że powodem błędu jest Firefox !!!! Dopiero kiedy wskazałem im miejsce w kodzie i opisałem dlaczego tak się dzieje oraz napisałem na co mają zmienić to poprawili. Problem wtedy występował z mailami kodowanymi w iso-8859-2 i funkcją html_entity_decode (na co zresztą wskazywał bład wyświetlany)

A przeczytałeś ze zrozumieniem to co Ci Dariusz Cieślak napisał ? Wyciek haseł jest po stronie komputerów klienckich !! Co nie ma nic wspólnego z Provaiderem i z cms-em.

"Adres we własnej domenie np.: https://svn.twoja-domena.pl" w pakiecie team, o resztę przypuszczalnie musisz pytań u nich bezpośrednio.

A czytałeś regulamin usługi, którą zakupiłeś ?

Jesteś tego pewien ? Artykuł 226 mówi tylko o danych umieszczonych na fakturze, natomiast odnośnie faktur elektronicznych są to punkty 232-237 i tam wyraźnie jest określone, że "1. Państwa członkowskie akceptują faktury przesyłane lub udostępniane drogą elektroniczną, pod warunkiem że autentyczność pochodzenia faktur i integralność ich treści zagwarantowano przy użyciu jednej z następujących metod: a ) za pomocą zaawansowanego podpisu elektronicznego w rozumieniu art. 2 pkt 2) dyrektywy Parlamentu Europejskiego i Rady 1999/93/WE z dnia 13 grudnia 1999 r. w sprawie wspólnotowych ram w zakresie podpisów elektronicznych(12); b ) za pomocą elektronicznej wymiany danych (EDI) zgodnie z definicją zawartą w art. 2 zalecenia Komisji 1994/820/WE z dnia 19 października 1994 r. dotyczącego aspektów prawnych elektronicznej wymiany danych(13), w przypadku gdy porozumienie dotyczące takiej wymiany przewiduje stosowanie procedur gwarantujących autentyczność pochodzenia i integralność danych." A w przypadku pdf-ów lub faktur ze strony brak jest tych punktów.

Bzdury piszecie w związku z fakturami, bo "Podstawą prawną do wystawiania faktur bez podpisu wystawcy i odbiorcy jest §9 Rozporzadzenia Ministra Finansów z dnia 25 maja 2005r. opublikowane w dzienniku ustaw Dz.U. 2005 nr 95 poz. 798" Czyli faktura może być bez podpisów i pieczątek i to wynika z polskiego prawa a nie unijnego, problemem jest sposób dostarczenia faktury, faktura NIE może być dostarczona jako pdf, html, wydrukowana ze strony, musi byc wydrukowana u wystawcy i przekazana odbiorcy fizycznie !!!! Takie jest prawo, a w praktyce to US musi udowodnić, że fakturę wydrukował odbiorca a nie wystawca. //EDIT: Już raz podawałem tego linka -> http://www.crn.pl/archiwum_open.php?page=a...l&kod=26205

Inne dodatki zainstalowane, ktoś wyjątkowo lubi Twoją stronę atakować, inne prawa plików, faktyczna inny konfiguracja serwera (ale to i tak włam ma miejsce przez joomle a nie przez serwer i winna jest temu joomla) To normalne bo jeżeli te same prawa użytkownika odnoszą się do serwisu joomla jak i do innych katalogów to skrypt uruchomiony z prawami takimi jak joomla może sobie pobuszowaćć i pozmieniać pliki na innych serwisach.

Nie jest to problem bo faktury styczniowe można księgować i w rozliczeniu za styczeń (w lutym) i w rozliczeniu za luty (w marcu) co najwyżej koszty Ci o jeden miesiąc uciekają.

Spoko zaksięgujesz sobie ją w następnym miesiącu Faktycznie mi też to trochę przeszkadza czyli opóźnienia w fakturach i jakas tak anienowoczesność, choć aktualnie hekko przebiło efuturo, 3 dni temu dostałem fakturę wystawiona 2 stycznia, data na stemplu pocztowym 5 lutego.

Nie, bo po co ? Przedłużał bym ją co roku.

Czy Wy wszyscy, którzy tak biadolą naprawdę edytujecie pliki na serwerze i nie macie kopii lokalnych ?

W standardowej ramce/formularzu consulting service jest 10 lat.

Poznań - INEA (ICPNET) boski ~ # ping jcj.pl PING jcj.pl (91.205.74.23) 56(84) bytes of data. 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=1 ttl=58 time=12.9 ms 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=2 ttl=58 time=14.7 ms 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=3 ttl=58 time=22.5 ms 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=4 ttl=58 time=23.0 ms 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=5 ttl=58 time=15.6 ms 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=6 ttl=58 time=18.4 ms 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=7 ttl=58 time=20.9 ms 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=8 ttl=58 time=16.2 ms 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=9 ttl=58 time=21.8 ms 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=10 ttl=58 time=14.6 ms 64 bytes from ip-91-205-74-23.iwacom.net.pl (91.205.74.23): icmp_seq=11 ttl=58 time=16.0 ms ^C --- jcj.pl ping statistics --- 11 packets transmitted, 11 received, 0% packet loss, time 10041ms rtt min/avg/max/mdev = 12.951/17.926/23.028/3.425 ms

A które nowe ? te napisane przed dodaniem AddDefaultCharset czy po dodaniu ? Bo te przed dodaniem powinny się źle pokazywać, te po powinny być prawidłowe.

Faktycznie masz rację (nie sprawdziłem dokładnie) W kodzie strony jest dobrze czyli <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2"> To serwer w nagłówkach wymusza kodowanie, wyślij nagłówek z kodowaniem ISO na początku generowania strony header("Content-Type: text/html; charset=iso-8859-2");

Kodowanie na połączeniu aplikacja (php) a mysql, popróbuj z zapytaniem SET NAMES kodowanie po połączeniu z bazą danych. A phpmyadmin tez masz źle ?

Z całym szacunkiem ale co wnosi do tematu Twoja odpowiedź i w jaki sposób pomogła w rozwiązaniu problemu ?