Menu

Работа

Тука ще има разни истории свързани с работата ми :)

PHP 5.5.12 problems after upgrade

, , 1

Днес ъпгрейднах няколко сървъра с последната версия на PHP 5.5.12 (нали съм фен на ъпдейтването) .. Тоя път стана проблеммм 🙂 След ъпдейта започна да ми дава 502 – bad gateway , а в лога излизаше permission denied. Излезе че в новата версия на PHP-fpm е задължително да се използват listen.owner и съответно за owner да се сложи същият потребител през който работи и уеб сървъра – в моя случай nginx.

След като го оправих, видях нова грешка.. още по-смотана и нахална :

 

2014/05/07 14:10:58 [error] 1951#0: *5 inflate() failed: 4, -3, client: *.*.*.*, server: friendbg.net, request: "GET / HTTP/1.1", host: "friendbg.net"
2014/05/07 14:11:58 [error] 1951#0: *44 inflate() failed: 4, -3, client: *.*.*.*, server: friendbg.net, request: "GET / HTTP/1.1", host: "friendbg.net"

Тук якото беше следното – през уеб браузър сайта се отваря , през lynx или curl дава : unexpected error и съответно pingdom.com ми съобщи че сайта ми е DOWN 🙂
След няколко часово тестване, ровене и мъчение реших кардинално да оправя проблема, като сваля версията на PHP* до 5.5.11 която си работеше без проблеми.

Сторих го по следния начин :

dpkg -i /var/cache/apt/archives/php5*5.5.11*

тъй като в хранилището на dotdeb вече всичко беше с новата версия.

Извод 1 – за сега ще изчакам с ъпдейтване на нови версии на PHP по сървърите ми, че явно промените не са никак малки и могат да ми причинят доста главоболия.

Извод 2 – трябва да спра с тея ъпдейти веднъж завинаги..!!

haproxy fail2ban configuration

, , , , 0

Идеята е fail2ban да се грижи за сигурността на нашият load balancer сървър – в случая – haproxy. 1. HAProxy трябва да може да логва всички конекции като опишем следните опции в /etc/haproxy/haproxy.cfg :

option httplog clf
option tcplog clf
# option dontlognull
log 127.0.0.1 local5 info

2. Да имаме работещ rsyslog и да добавим следното в конфигуранционният му файл:

$ModLoad imudp
$UDPServerRun 514
local5.* /var/log/haproxy.log

3. Logrotate – това не е задължително но е хубаво да го имаме. Добавяме в /etc/logrotate.d/haproxy.cfg :

/var/log/haproxy*.log
{
rotate 4
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
reload rsyslog >/dev/null 2>&1 || true
endscript
}

4. Следва и самият код за fail2ban в /etc/fail2ban/filter.d/haproxy-get-dos.conf

# Haproxy Fail2Ban Regex using CLF format # [Definition] failregex = haproxy\[\d+\]: .* "(GET|POST) .*https?:// ignoreregex =

5. След това в /etc/fail2ban/jail.conf:

[haproxy-get-dos]
enabled = true
port = http,https
filter = haproxy-get-dos
logpath = /var/log/haproxy*
maxretry = 500
findtime = 120
bantime = 3600
action = tarpit[name=HTTP, port=http, protocol=tcp]
sendmail-whois[name=haproxy-get-dos, dest=alerts@root.bg, sender=fail2ban@root.bg]

6. Следва инсталирането на пакета xtables който е необходим да работи TARPIT 7. Добавяме следното в /etc/fail2ban/action.d/tarpit.conf :

# Tarpit trap
[Definition]
actionstart = iptables -N fail2ban-TARPIT-
iptables -A fail2ban-TARPIT- -j RETURN
iptables -I INPUT -p -j fail2ban-TARPIT-
actionstop = iptables -D INPUT -p -j fail2ban-TARPIT-
iptables -F fail2ban-TARPIT-
iptables -X fail2ban-TARPIT-
actioncheck = iptables -n -L INPUT | grep -q fail2ban-TARPIT-
actionban = iptables -I fail2ban-TARPIT- 1 -s -j TARPIT
actionunban = iptables -D fail2ban-TARPIT- -s -j TARPIT[Init]
name = default
port = http
protocol = tcp

8. Рестартираме haproxy и fail2ban и готово 🙂

Безплатен SSL сертификат

, , , , 0

безплатен SSL сертификатОнлайн пазаруването се развива стремглаво нагоре, и поради това, сигурността и бързината на уеб сайтовете е много важна за всеки един уеб администратор. От както google пуснаха на пазара своя протокол наречен SPDY, аз започнах да експериментирам със SSL техники на блога си, защото освен че съм голям фен на така нареченият „performance“, обичам и сигурността.

Поради тази причина искам да споделя сайта http://www.startssl.com/ който предлага безплатен SSL сертификат за един или повече домейни + 1 суб домейн. Хубавото в случая е, че сертификатите на startssl се разпознават безпроблемно от почти всеки браузър, което значи че ще избягваме досадните съобщения за self signed certificate. Разбира се това не е вариянт за големите компании и за страници на големи онлайн магазини които искат най-голямата възможна надежност предоставена от SSL сертификатите, но е добро начало, и идеално за блогове като моя 🙂

Обаче стигнах до заключение, че изцяло изването на този сертификат (тоест пълен 301 редирект от http към https) ще ни навреди за SEO позициите на сайта. Причината е че един прост curl -I не вижда сертификата като валиден. Също така се вижда невалиден и за ботовете и популярните SEO тулчета. Поради тази причина не съм направил 301 редирект все още, въпреки че много ме блазни отново да пусна SPDY.

Сигурно има и други сайтове които предлагат безплатни сертификати, и съм обеден че не откривам топлата вода със startssl (за което искам да се извиня предварително) , но ще се радвам ако някой сподели друг по-добър сайт за да мога да продължавам да тествам 🙂 Благодаря!

 

Настройка на OpenVPN клиент за IPhone

, , , 0

Тъй като след обновяване на версията на iOS, настройките за OpenVPN приложението не се запазват, реших да драсна в блога набързо как лесно става настройката, за да ми е лесно за напред.

  1. Първо е необходимо да се изтегли OpenVPN Connect от AppStore.
  2. Отваряме един текстов редактор и вкарваме конфиг-а + сертификатите в него.
  3. Отваряме iTunes, отиваме на Apps, избираме OpenVPN и цъкаме „add“ и селектираме предварително записаният файл с разширение .ovpn
  4. Отваряме приложението през телефона където ще видим че е излязал нов конфигурационен файл. Даваме да се запише и го стартираме.
  5. Това е 🙂

Сега и подробностите.

Това е конфигурационният файл + сертификатите ( разбира се съм сложил невалидни такива )

 
Отваряме iTunes и избираме „apps“
Настройка на OpenVPN клиент за IPhone

nginx remove server header

, , , , , 0

Често съм се питал как facebook.com си скриват Server header-а, тоест :

web2:~# curl -I https://www.facebook.com
HTTP/1.1 200 OK
Pragma: no-cache
X-Frame-Options: DENY
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Set-Cookie: reg_fb_gate=https%3A%2F%2Fwww.facebook.com%2F; path=/; domain=.facebook.com
Set-Cookie: reg_fb_ref=https%3A%2F%2Fwww.facebook.com%2F; path=/; domain=.facebook.com
Set-Cookie: reg_ext_ref=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com
Set-Cookie: datr=redUU4C5xfriseY9srwt472n; expires=Wed, 20-Apr-2016 09:41:01 GMT; path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-FB-Debug: vLVadCnq65jFMIPA4W/cXrElVE09UTk61wyH+iB5WHU=
Date: Mon, 21 Apr 2014 09:41:01 GMT
Connection: keep-alive
Content-Length: 51718

Не виждаме никакъв Server отговор.
Открих начин как да го постигна с един модул за nginx, наречен headers-more-nginx-module. Готиното тук е, че освен скриването на Server, можем да променяме и името на Server. Опцията може да се слага освен в http, server и в location, тоест можем да променяме името на всеки един от виртуалните ни хостове. Инсталирането е елементарно, и е описано как става тук.
Опцията е:

more_set_headers 'Server: my-server';

А резултата е:

web2:~# curl -I http://friendbg.net
HTTP/1.1 200 OK
Date: Mon, 21 Apr 2014 09:48:54 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.5.11-1~dotdeb.1
X-Pingback: http://friendbg.net/xmlrpc.php
Server: my-server
X-Friendbg-Cache: HIT'n'RUN
X-Content-Type-Options: nosniff
P3P: Can I help you? Contact me via http://friendbg.net/contacts/, CP=CAO ADMa DEVa IND PHY ONL UNI COM LOC

Скриването на Server става със слагането на more_clear_headers в nginx.conf:

more_clear_headers Server;

Повече за HttpHeadersModule може да се намери в wiki-то на nginx.org.

Load More