Stało się. Po kilku, jak nie więcej latach korzystania ze strefy DNS znajdującej się w OVH, finalnie dojrzałem do tego by przenieść wszystko na CloudFlare. Do tej pory blokowała mnie myśl żmudnej konfiguracji, problemów z nią oraz przerw w działaniu bloga i innych usług. Efekt? Wszystko bardzo szybko i przyjemnie.
Udało się również bezboleśnie skonfigurować zadanie CRON, które łączy się z API CloudFlare i w razie zmiany mojego adresu IP podmienia go w konfiguracji strefy DNS – bajka.
Obecnie cały ruch do bloga prowadzony jest przez proxy CloudFlare. Zauważyłem, że dzięki temu strona ładuje się też zauważalnie szybciej (co zauważyłem nawet przy połączeniu z lokalnej sieci, siedząc obok RaspberryPi).
Konfiguracja DNS i bonus
Strefa DNS z OVH do CloudFlare przeniosła się niemal automatycznie, konfigurator wykrył część ustawień ze strefy DNS i przeniósł ją. Było parę rekordów, które trzeba było ręcznie przenieść, oraz idąc od razu za ciosem, postanowiłem przywrócić funkcjonalność poczty e-mail. Tzn. może to jest za dużo powiedziane – skierowałem po prostu rekord MX na CyberFolksa. Dzięki temu możliwe stało się w końcu przywrócenie powiadomień do komentarzy.
Z uwagi na fakt, że wtyczka Subscribe to Comments Reloaded z której korzystałem x lat temu została wygaszona w repozytoriach WordPressa – szukałem alternatyw. Znalazłem :). Bardzo prostą i zarazem funkcjonalną wtyczkę o nazwie Comment Reply Email Notification (a i tym samym przetłumaczyłem też wtyczkę na j. Polski. Czekam aż autor wrzuci do repo by móc jeszcze nanieść ewentualne poprawki).
Tym samym – można subskrybować komentarze i dostać powiadomienie o nowym (odpowiedzi do swojego).
Bardzo ważnym jest również to, by dla usług takich jak VPN utworzyć dodatkową subdomenę, która nie jest proxowana. Dzięki temu można połączyć się bezpośrednio do domeny przez konfigurację. Gdyby nie to, trzeba by było znać aktualny adres IP i łączyć się „na sztywno”.
Korzystanie z API CloudFlare
To był temat, który nie dawał mi spokoju. W przypadku OVH miałem ustawione makro, dla CloudFlare chciałem osiągnąć podobny efekt. Nie planowałem instalacji żadnych aplikacji do tunelowania połączenia. Chciałem możliwie najprościej osiągnąć zamierzony dla mnie cel – dać CloudFlare znać po 15-30 minut, jaki jest mój obecny IP.
Znalazłem w sieci gotowy skrypt, który z założenia właśnie to robił. Po dodaniu skryptu do CRONa sprawdza IP, wysyła przez API informację do CloudFlare, ALE wyłączał opcję proxowania połączenia.
To – udało się rozwiązać za pomocą małej modyfikacji z pomocą AJAJAJA. Poniżej gotowy, poprawiony skrypt:
#!/bin/bash
DNS_ZONE_ID='xxx' # your dns zone ID
API_KEY='yyy' # your API Token created previously
HOST_NAME='ddns.thms.uk' # Your DNS record host name
RECORD_TYPE='A' # A for IPv4, AAAA for IPv6
CLOUDFLARE_PROXY='true' # Enable Cloudflare Proxy (orange cloud)? 'true' or 'false'
#############################################
### Don't change anything below this line ###
#############################################
# get current external ip address
if [ "$RECORD_TYPE" = "A" ]; then
CURRENT_IP_ADDRESS=$(curl -s -4 https://ip.me)
elif [ "$RECORD_TYPE" = "AAAA" ]; then
CURRENT_IP_ADDRESS=$(curl -s -6 https://ip.me)
else
echo "Unknown Record Type '${RECORD_TYPE}'. Allowed values are 'A' or 'AAAA'"
exit 1
fi
# get DNS Record
DNS_RECORD=$(curl -sX GET "https://api.cloudflare.com/client/v4/zones/${DNS_ZONE_ID}/dns_records/?name=${HOST_NAME}" -H "Authorization: Bearer ${API_KEY}" | jq -r '.result[] | select(.name == "'${HOST_NAME}'" and .type == "'${RECORD_TYPE}'")')
DNS_RECORD_ID=$(echo $DNS_RECORD | jq -r '.id')
CURRENT_DNS_VALUE=$(echo $DNS_RECORD | jq -r '.content')
# if IP address has changed: update it
if [ "${CURRENT_DNS_VALUE}" != "${CURRENT_IP_ADDRESS}" ]; then
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones/${DNS_ZONE_ID}/dns_records/${DNS_RECORD_ID}" \
-H "Authorization: Bearer ${API_KEY}" \
-H "Content-Type: application/json" \
--data '{"type":"'${RECORD_TYPE}'","name":"'${HOST_NAME}'","content":"'${CURRENT_IP_ADDRESS}'","proxied":'${CLOUDFLARE_PROXY}'}' > /dev/null
fi
W powyższym skrypcie świadomie i celowo nie zmieniam wartości domyślnych zdefiniowanych przez jego autora. Doceniam jego pracę, chcąc jednocześnie udostępnić poprawiony skrypt.
Z pomocą powyższej modyfikacji „przełącznik” od proxowania się nie wyłącza już :). Z tego co wyczytałem bez podania informacji o proxowaniu do API, domyślnie przyjmuje wartość false i wyłącza tę opcję.
Wysyłka wiadomości przez SMTP, nie PHP mail()
Dochodzimy do kolejnego problemu, z którym się spotkałem. WordPress domyślnie nie zezwala na wysyłkę wiadomości przez serwer SMTP. Możemy skorzystać z gotowej wtyczki, np. WP Mail SMTP, lub dodać potrzebne funkcje i zmienne do konfiguracji WordPressa.
Ja wybrałem opcję #2. Tam, gdzie jest to możliwe i mogę – stronię od wtyczek. W samym WordPressie w chwili pisania tego wpisu, mam aktywnych 9 wtyczek.
Do poprawnego działania wysyłki SMTP potrzebujemy zmodyfikować dwa pliki:
- Plik konfiguracyjny
wp-config.php - Funkcje motywu
wp-content/themes/{motyw}/functions.php
Dla pierwszego, czyli wp-config.php dodajemy i poprawiamy poniższą konfigurację na końcu pliku, przed ?>:
// Konfiguracja SMTP
define( 'SMTP_USER', '[email protected]' ); // Nazwa użytkownika SMTP (często to po prostu e-mail)
define( 'SMTP_PASS', 'twoje_haslo_smtp' ); // Hasło do skrzynki e-mail
define( 'SMTP_HOST', 'smtp.twojadomena.pl' ); // Adres serwera SMTP
define( 'SMTP_FROM', '[email protected]' ); // Adres e-mail nadawcy
define( 'SMTP_NAME', 'Nazwa Twojej Strony' ); // Nazwa nadawcy, np. "Sklep XYZ"
define( 'SMTP_PORT', '465' ); // Port SMTP (zazwyczaj 465 dla SSL lub 587 dla TLS)
define( 'SMTP_SECURE', 'ssl' ); // Szyfrowanie (ssl lub tls)
define( 'SMTP_AUTH', true ); // Wymaga autoryzacji (najczęściej true)
Natomiast dla pliku functions.php również na samym końcu, dodajemy:
/**
* Konfiguracja wysyłki maili przez SMTP
*/
add_action( 'phpmailer_init', 'custom_smtp_setup' );
function custom_smtp_setup( $phpmailer ) {
$phpmailer->isSMTP();
$phpmailer->Host = SMTP_HOST;
$phpmailer->SMTPAuth = SMTP_AUTH;
$phpmailer->Port = SMTP_PORT;
$phpmailer->Username = SMTP_USER;
$phpmailer->Password = SMTP_PASS;
$phpmailer->SMTPSecure = SMTP_SECURE;
$phpmailer->From = SMTP_FROM;
$phpmailer->FromName = SMTP_NAME;
}
Od teraz, bez wtyczki do SMTP, wysyłka zacznie działać.
Ale u mnie był problem
Nie mogło obejść się bez problemów z obsługą SMTP. Blisko 4 godziny zeszło mi na zlokalizowanie troublemejkera, a okazało się, że po prostu w ustawieniach CSF nie zezwoliłem nikomu na komunikację przez port SMTP 465. Domyślnie weryfikację, czy port jest otwarty wykonywałem z konta roota, a on domyślnie ma zezwoloną komunikację na porcie 465.
# Note: root (UID:0) is always allowed
SMTP_ALLOWUSER = ""
Potem szybkie csf -r po dodaniu użytkownika, na którym stoi apache2.
I działa. Do teraz. Bez problemów.


Dodaj komentarz