kafi

http://www.postfix.org/ADDRESS_VERIFICATION_README.html

Na większości* hostingów z DirectAdminem ownclouda odpalić się nie da. Tzn. - działać będzie i działał, ale będzie problem z synchronizacją zasobów z zewnętrznym klientem. Moje testy wykazały, że na serwerze nie może być zainstalowanego modułu dav. Nie pomaga nawet wyłączenie go dyrektywą Dav Off - trzeba było zrekompilować apache bez niego. Lepiej wziąć VPS i sobie go skonfigurować pod własne potrzeby - odejdą problemy z dav, limitami i innymi dziwactwami.

Jeśli stawiasz tam wirtualizację, to raczej nikłe szanse, że będziesz miał na systemie gościa prawdziwe GPU

Do konfigurowania pliku z bundle służy w Apache dyrektywa SSLCertificateChainFile. SSLCACertificateFile jest używane tylko w klienckiej autoryzacji SSL i definiuje (z grubsza) zaufanych wystawców certyfikatów klienckich (aka jeżeli klient zweryfikuje się certyfikatem podpisanym przez jedno z tych CA to go wpuści). PS: ChainFile może zawierać sklejkę certyfikatów Geotrust, Comodo i innych i być wspólny (w sensie - każdy vhost ma dyrektywę ...ChainFile kierującą na ten sam plik). Problem tylko taki, że ten bundle jest wysyłane klientowi co żądanie, więc zbytni zlepek spowoduje, że może to działać wolno

Chyba, że klient wyraził zgodę na świadczenie usług przed upływem tego terminu a usługodawca takie świadczenie rozpoczął To już jest kwestia sporna. Bo jeżeli usługodawca wykaże, że dołożył wszelkich starań odnośnie poinformowania cię, to możesz być na straconej pozycji. Rozróżnijmy tu trzy przypadki: pierwszy to taki, że na stronie jest sam przycisk mówiący o "darmowym dostępie", po kliknięciu którego niby zostaje zawarta umowa zgodnie z mitycznym "regulaminem". Drugi to telefoniczna chęć "kontynuacji", gdzie nijak nie jest to kontynuacja (tylko formalnie zawarcie nowej długoterminowej umowy), bo firma istnieje od 3 miesięcy i rok temu nie mogła nawet zawrzeć umowy. To też oszustwo. Trzeci to formularz mówiący - zawierasz umowę o to i o tamto, to jest regulamin tej usługi, przeczytaj go dokładnie i zaakceptuj żeby przejść dalej. Zwróc uwagę na opłaty. O ile w pierwszym i w drugim to IMO jest to ewidentne oszustwo (i sprawa jest jak najbardziej do wygrania), to w trzecim zasłanianie się tym, że ja-biedny-nie-wiedziałem bo wszędzie tylko next>dalej>next>finish bez jakiegokolwiek czytania ze zrozumieniem to delikatnie nie na miejscu jest. Odpowiedź może być też następująca: Umowa została zawarta poprzez wypełnienie formularza rejestracyjnego pod adresem http://rejestracja.mojafirma.pl z adresu IP 1.2.3.4 w dniu 03.09.2014.

1. Autor tematu napisał, że wiadomość otrzymał z _formularza_kontaktowego_ na stronie. Wybitnym idiotyzmem (@NetMat) jest ciągłe domaganie się nagłówków wiadomości, skoro na zdrowy rozsądek nie będzie tam nic ciekawego - w końcu "autorem" wiadomości jest skrypt formularza kontaktowego na serwerze, 2. Maili w domenie gov.pl (pod warunkiem, że to gov, a nie jakiś zbliżony IDN) żaden scamer nie założy. A jeśli nawet trafi się owy delikwent, to trzyliterowe służby operacyjne znajdą go w razie potrzeby w miarę szybko Więc pisanie, że to NA PEWNO próba wyłudzenia jest także żałosne. 3. We wiadomości jest zawarty numer telefonu i dane autora wiadomości. Można otworzyć stronę internetową Policji w Szczyrku, znaleźć tam numer telefonu - zweryfikować, czy ten we wiadomości jest tożsamy - i zadzwonić. 4. W pewnych działaniach liczy się po prostu czas. Więc zamiast uruchamiać operacyjne procedury pozyskania danych administratora serwisu (które trwają - bo nadrzędny operator dostanie podobne pismo o zwolnienie z tajemnicy + przekazanie danych administratora serwisu), to można po prostu zapytać, gdzie bezpośrednio stosowne dokumenty przesłać.

Zdecyduj się, czy wszystkie adresy postaci example.com/NAZWAUŻYTKOWNIKA chcesz mapować a) do pliku NAZWAUŻYTKOWNIKA.php (to robi reguła RewriteRule ^([A-Za-z0-9-_]+)$ $1.php [QSA]) b) do pliku profile.php z parametrem id=NAZWAUŻYTKOWNIKA (to robi reguła RewriteRule ^([^.]*)$ profile.php?u=$1 [L])

Skoro nie ma pliku index (bez rozszerzenia) to jak najbardziej poprawnym jest zwrócenie przez serwer, że plik nie istnieje. Wklejony kod z pliku htaccess robi zasadniczo tyle, że jeżeli adres strony nie rozpoczyna się od www., to przekierowuje klienta na adres z www. na początku. I tylko tyle...

Problemem jest plik .htaccess. Wklej jego zawartość.

To i ja sobie trochę pojęczę jeśli chodzi o jakość supportu. Mam sobie konto. Zapomniałem do tego konta hasła. Dodatkowe utrudnienie jest takie, że domena maila podanego przy rejestracji wygasła. Sytuacja dosyć patowa, więc wymagany jest kontakt z supportem. Niedzielne popołudnie - livechat, na którym ktoś (podobno) siedzi. Napisałem o co chodzi, po lekkiej chwili oczekiwania komunikat, że żadnego operatora nie ma dostępnego i należy zostawić wiadomość. To można by rzec jest zrozumiałe - w końcu to niedziela, to 24h obsługi wymagać nie można. No to zostawiłem takową wiadomość (podając nowy - aktywny już mail w polu e-mail) wiadomość. Niestety, do tej pory (a jest wtorkowe popołudnie) odpowiedzi nijak nie ma, a logi serwera pocztowego raczej nie wskazują jakiejkolwiek (nawet odbitej) próby komunikacji. Suma sumarum hasło do HyperVM znalazłem w archiwalnych mailach, ale do panelu billingowego jak hasła nie znałem, tak nadal nie znam...

Koniecznie nie trzeba. Nie ma takiego ustawowego obowiązku. Ale jak dysponent adresów IP będzie miał to w d...e to inni też go będą mieli w d...e i będą filtrować te prefiksy na swoich routerach brzegowych jako siedlisko zła. Nie mówiąc już o blacklistach takich jak Spamhaus, dzięki którym z takiej adresacji nie wyśle się praktycznie nigdzie maila (patrz opisywany niedawno na tym forum przykład ŚląskDataCenter).

Kiedyś był sobie taki temat o szyfrowaniu VPS. Powtórze się - w przypadku jakiejkolwiek wirtualizacji szyfrowanie partycji nie ma jakiegokolwiek sensu. Bo jeżeli administrator hypervisora będzie chciał, to zrobi snapshot serwera + pamięci RAM i wyciągnie z niego to, co jest mu potrzebne. Jeśli chodzi o backupy - to najrozsądniej jest zaszyfrować poszczególne pliki z kopiami (np. przez wspomniane GPG), które dostatecznie ograniczą ryzyko vzctl enter 101 / mc / enter / f3 przez dostawcę vps.

Zaparkuj subdomenę jako nową domenę. Wtedy stworzy ci się w ~/domains nowy katalog, zawierający podkatalog public_html, do którego wrzucisz sobie stronę. Wtedy będziesz miał takowe rozdzielenie.

Jeżeli go nie potrzebujesz, to wyłącz w konfiguracji MySQL silnik InnoDB.

Ja dostałem fakturkę za adresy... za które już dawno temu zapłaciłem (w lutym na 6 miesięcy)

587 to port kliencki - klient posiadający skrzynkę mailową łączy się do niego (z teoretycznie bezwzględną autoryzacją) i przekazuje mu wiadomość do wysyłki. MX to serwer odbierający pocztę od innych serwerów i tylko serwerów. U mniejszych dostawców hostingowych, gdy całość konta jest na jednej maszynie, to rola submission i mx jest wspólna, więc działa i to i to. Więksi dostawcy posiadający troszkę bardziej rozbudowaną infrastrukturę rozdzielają te dwie role. I wtedy - tak jak w gmailu - na MX dostępny jest port tylko 25, ale klient nie może z niego skorzystać, a na smtp/submission tylko port 587 (no i inne serwery nie mogą tu rozsyłać maili bez autoryzacji). Zapewnia to raz że większą odporność na awarie (mniejsze prawdopodobieństwo, że padnie i wysyłanie poczty użytkownika i "odbieranie" poczty z innych serwerów; a dwa - przy takiej konfiguracji da się sporo spamu wyeliminować (bo nie trzeba wróżyć z fusów, czy ten co łączy się, to jest innym serwerem pocztowym, czy też dziwnym klientem). A co zrobić? Skontaktować się z operatorem w celu odblokowania portu 25. Jeżeli się nie da, to trzeba sobie albo darować serwer pocztowy, albo wykupić jakiegoś VPS i skonfigurować na nim smarthosta.

Spróbuj jawnie połączyć się telnetem do smtp.gmail.com na porcie 587. Jeżeli ci się to najprawdopodobniej tak - provider blokuje port 25. mariaczi - wyżej masz załączone traceroute które przechodzą poprawnie. Wspomniany komunikat jest raczej skutkiem odpowiedzi ICMP Destination unreachable z subkodem Network is unreachable na pakiet kierowany na port tcp/25. Źródło: http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Destination_unreachable

Jesteś pewien, że twój ISP nie filtruje portu 25? Spróbuj na porcie 587, tak jak napisał mariaczi. Z tym, że musisz pamiętać, aby testować na klienckich serwerach smtp (np. smtp.gmail.com), bo serwery MX siłą rzeczy na porcie przeznaczonym stricte do komunikacji klienckiej słuchać nie będą.

Przyczyną błędu poniżej nie jest konfiguracja MXów. connect to alt2.gmail-smtp-in.l.google.com[2607:f8b0:4001:c05::1a]:25: Network is unreachable Zerknij przed dłubaniem w strefie dns, czy nie pomoże ci polecenie echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

W ramach Office 365 da się bezproblemowo dopiąć wiele domen. Aliasy to też nie jest jakiś duży problem z tego, co pamiętam.

1. Spróbuj podmienić zasilacz. 2. Otwórz router i zobacz, czy jakieś kondensatory nie są wybrzuszone.

http://www.cyberbajt.pl/produkt/6250/routerboard-sxt-g2hnd.html

Ma znaczenie. Gdy rezerwacja domeny wygaśnie, to nie wróci od razu do puli wolnych, ale przez pięć dni będzie w stanie umożliwiającym rejestrację bez możliwości wcześniejszej rezerwacji. U większości rejestratorów domena w stanie BOOK_BLOCKED (usunięta z kolejki...) nadal będzie oznaczona jako niemożliwa do rejestracji. Z tego, co wiem, to np. az.pl oferuje możliwość rejestracji takiej domeny, ale też dopiero specjalną opcją w panelu, a nie domyślnie ze strony głównej.

Przedstaw dokładną topologię twojej sieci - jakie są dokładnie urządzenia i jak/do czego podłączone.

Wszystko zależy od domeny (konkretnie od jej końcówki) i od dostawcy u którego jest utrzymywana. Dla .pl formalnie transfer oznacza tylko zmianę partnera u którego domena jest utrzymywana. Nie zmienia się wtedy abonent i delegacja domeny (no chyba, że nowy partner po transferze wyśle polecenie aktualizacji danych). Dla .eu przykładowo trzeba w momencie transferu podać serwery nazw na które domena będzie przedelegowana. Dla .com/.net/.org podaje się chyba nowe dane abonenta (ale serwery nazw zostają stare).