От както google започнаха да обичат https сайтовете, повече се налага масова инсталация на SSL-и където може. Като цяло освен повече тормоз за сървърите имаме и деградация в скоростта. Хубавото е, че HTTP2 стандарта вече над година и половина се интегрира във всички големи http сървъри и браузъри и поддръжката му достатъчно стабилна. За съжаление debian stable няма пакети които да поддържат HTTP2 в основните http сървъри. Версиите които са ни необходими за да работи HTTP2 са както следва:

  • Apache > 2.4.17
  • Nginx > 1.9.5
  • останалите персонално не ме вълнуват (lighttpd имат евентуално планирано…..)

При мен мешаницата е голяма и според зависи се ползва apache или nginx. Все още не съм си играл да пускам на apache http2 на debian 8 тъй като не ми се е налагало но в backports репото го има така, че няма да е голям проблем. За nginx е вече го играхме няколко пъти. Като цяло стъпките са няколко и относително прости:

  1. Добавяме nginx официалното репо – в debian весията е 1.6.х 🙄
  2. Инсталираме си openssl от backports към момента е 1.0.2к – това ни трябва за ALPN подръжката за да може всичко да работи и да е бързичко
  3. инсталираме си devscripts – тук е момента да споделя че ще си билднем наш пакет защото официалният е компилиран с openssl 1.0.1t при който не работи ALPN и браузърите не му реагират добре и работи http2-то само ако го форсираш
  4. инкрементираме версията за да не правим hold циганията с пакетите а като има нова версия само да синкенм сорсовете

Нека да започнем стъпка по стъпка

Добавяне на nginx repo

deb http://nginx.org/packages/debian/ codename nginx
deb-src http://nginx.org/packages/debian/ codename nginx

Добавяне на openssl 1.0.2k и dev библиотеката в противен случай ще си го билднем пак с 1.0.1t което не ни е целта


echo 'deb http://ftp.debian.org/debian jessie-backports main' | tee /etc/apt/sources.list.d/backports.list

apt update && apt install libssl-dev -t jessie-backports

 

Сега остана да си добавим библиотеките необходими за компилацията на nginx


apt install devscripts

apt build-dep nginx

mkdir nginx-build

cd nginx-build

apt-get source nginx

Ако сте работили коректно трябва да имате структура от рода на


~/nginx-build # ll
total 1004
drwxr-xr-x 10 root root   4096 Feb 21 18:37 nginx-1.10.3
-rw-r--r--  1 root root 103508 Jan 31 17:59 nginx_1.10.3-1~jessie.debian.tar.xz
-rw-r--r--  1 root root   1495 Jan 31 17:59 nginx_1.10.3-1~jessie.dsc
-rw-r--r--  1 root root 911509 Jan 31 17:59 nginx_1.10.3.orig.tar.gz

Влизате в папта  в която е разархивиран сорса на nginx в моят случай е и nginx-1.10.3 изпълнявате команда с която инкрементирате версията, аз лично предпочитам да добавя 1 към настоящият билд

debchange --newversion 1.10.3-1

След като си добавите changelog-а по избор може да се пристъпи към същинската компилация

debuild -us -uc -i -I -b -j6

Малко разяснение по конфигурацията на командата:

-us -uc казват на скрипта да не „подписва“ .dsc и .changes файловете. -i и -I карат скрипта да игнорира файловете за контрол на версия. -B да се генерира само бинарен пакет. -j както при make с колко паралелни процеса да се компилира 🙂

 

След като приключи горният процес следва да си инсталираме нашите нови пакети. Ако имате вече инсталиран nginx е добре да го деинсталирате

apt remove nginx nginx-*

Също не лоша идея е да си направите бекъп на nginx папката в /etc. По принцип при ъпгрейд от 1.6.5 към 1.10.3 нямах драми но никога не се знае. Новите пактеи се намират в папката от по горно ниво и следва да се инсталират с команда от рода на:

dpkg -i ../*.deb

Ако всичко е минало гладко ви остава само да си пуснете nginx процеса и да си се конфигурира http2 което вече не е цел на тази статия.

Преживях малка драма с диска на лаптопа ми. След фиксването на проблема при apt-get update лъсваше следният крайно не приятен край на процеса

E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/debian.ipacct.com_debian_dists_sid_contrib_binary-i386_Packages
E: The package lists or status file could not be parsed or opened.

Както обикновено проблема е крайно очевиден /var/lib/apt/lists/debian.ipacct.com_debian_dists_sid_contrib_binary-i386 не може да бъде прочетен коректно. Фикса е също толкова елементарен колкото и самата диагностика на проблема:

 rf -f /var/lib/apt/lists/*

В крайна сметка резултата е форсирана синхронизация на apt.

Любимият ми текстови редактор е Geany. Той е много минималистично IDE което поддържа огромен набор от езици – shell, php, python, C … etc. Има си автоматично довършване и същевременно е адски пъргаво. Липсват му някоя и друга приятна възможност но и към момента за мен е повече от напълно достатъчен. Започнах да online курса Python Programming на SoftUni – да си освежа познанията и да ги надградя тъй като не съм следил адекватно какво се случва с python 3. Лекторите от курса препоръчват PyCharm като IDE за pyton програмиране, но на мен далеч не ми е по вкуса, естествено си използвам Geany за упражненията.

По време на лекциите болезнено усетих 2 липси

  1. python autocomplete-а издиша от към документация на функции и методи
  2. няма валидация за pep8 стандарта

Хубавото е че Geany е достатъчно гъвкав от към конфигурация и може лесно да бъде допълван от към липсващи такива. Нека да добавим python документация към нашето IDE:

  • дърпаме си следният скрипт някъде в нашият PATH например /usr/bin като не забравяме да го направим изпълним
  • редактираме файла ~/.config/geany/filedefs/filetypes.python като в частта settings добавяме следният ред context_action_cmd=pydocw %s. Ако съществува само добавяме името на бинарката от предишната стъпка. Рестартираме Geany ако е пуснат.
  • Вече имаме context-action който ще ви извади информация за функцията. Аз си добавих shortcut за  да ми е по удобно като не ми е ясно някоя функционалност. Лич мен този подход много ми допада защото много ме дразни netbeans подхода.

До тук добре. След това много ми се прииска да имам валидация на кода който пиша – дали го пиша според общо приетите стандарти или пиша някакви грозотии. В общи линии намерих отново туториалче как се случват нещата но то е малко остаряло – Geany си има всичко вградено в себе си само трябва да му се инсталира pep8 пакета. В Debian apt-get install pep8 върши работа в останалите дистрота сами трябва да откриете как се случва магията. В менюто Build вторият бутон (поне при мен) е Lint след кликването му ще откриете колко грозен код сте сътворили 😀

Screenshot from 2016-01-11 20-42-21

Това е общи линии как да накарате вашият Geany да работи по добре с Python и същевременно да продължи да бъде бърз без да кара процесора ви да иска да си тегли куршума.

Поради някакви (не много ясни ми причини) бях пропуснал да направя ъпгрейд на postgresql демона при дистрибутивният ъпгрейд на един от Debian сървърите ми. Postgresql демона има хубавото свойство да не започва да използва новата си версия (за разлика от Mysql) докато не убедим, че новата е на пълно съвместима със старта – изключително полезно при големи бази данни. Самият процес по обновяване се ограничава до следните 2 стъпки:

  • pg_dropcluster
  • pg_upgradecluster

Преди да издропите клъстера pg демона трябва да е спрян!

pg_dropcluster 9.4 main

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

pg_upgradecluster 9.1 main
Disabling connections to the old cluster during upgrade...
Restarting old cluster with restricted connections...
Creating new cluster 9.4/main ...
config /etc/postgresql/9.4/main
data   /var/lib/postgresql/9.4/main
locale en_US.UTF-8
Flags of /var/lib/postgresql/9.4/main set as -------------e-C
port   5433
Disabling connections to the new cluster during upgrade...
Roles, databases, schemas, ACLs...
Fixing hardcoded library paths for stored procedures...
Upgrading database postgres...
Analyzing database postgres...
Fixing hardcoded library paths for stored procedures...
Upgrading database template1...
Analyzing database template1...
Fixing hardcoded library paths for stored procedures...
Upgrading database xpqt...
Analyzing database xpqt...
Re-enabling connections to the old cluster...
Re-enabling connections to the new cluster...
Copying old configuration files...
Copying old start.conf...
Copying old pg_ctl.conf...
Copying old server.crt...
Copying old server.key...
Stopping target cluster...
Stopping old cluster...
Disabling automatic startup of old cluster...
Configuring old cluster to use a different port (5433)...
Starting target cluster on the original port...
Success. Please check that the upgraded cluster works. If it does,
you can remove the old cluster with

pg_dropcluster 9.1 main

Ако всичко е минло гладко трябва да получите съобщение като горното което ви подканва да разкарате старите данни от pg.

pg_dropcluster 9.1 main

В края на тая тарпана вече можете да стартирате процеса си отново. При мен базите са малки и за съжаление не мога да дам оценка за колко време преминава същественият ъпгрейд.

Новият Debian Stable е факт от около седмица и ме сърбяха ръцете да си надградя виртуалката до него но нямах никакво време до днес. Тъй като денят ми стартира рано реших да посветя време на ъпгрейда. Промених сорс листа ми като промених wheezy  на jessie

sed -i "s/wheezy/jessie/g" /etc/apt/sources.list && apt-get update

Тук изгърмяха 2 огледала:

  • MariaDB – от това огледало вече няма нужда Jessie включва версия 10.0.6 в себе си което не ми се понрави много. След 5.5 мичетодб и mysql не са съвсем съвместими заради което към момента врътнах обратно към mysql 5.5.42 – той е по подразбиране в jessie
  • DotDeb – използвах го преди за php55 тук също е излишен защото Jessie идва с 5.6.7-1

След като разкарах излишните огледала и врътнах от MariaDB към Mysql apt-get dist-upgrade мина чисто, reboot и вече бях с Debian 8.0. Отворих си web server-а и за моя изненада работеше тук историята е дълга – с няколко думи Nginx-а ми е компилиран допълнително от source с допълнителни директиви. dpkg -l nginx-full 1.2 мдааа някой е забравил да си unhold-не пакетите. Unhold и upgrade всичко е по план nginx-а се счупи 😆 . Nginx-а работи обработва заявки и php-fpm процеса е up and runnign но php code не се изпълнява и не плюе грешки 🙄 ЛЮБИМОТО МИ.

След известно търсене на информация за промените открих следният пасаж

Fastcgi configuration issues ============================

nginx shipped a modified fastcgi_params, which declared SCRIPT_FILENAME fastcgi_param. This line has now been removed. From now on we are also shipping fastcgi.conf from the upstream repository, which includes a sane SCRIPT_FILENAME parameter value.

So, if you are using fastcgi_params, you can try switching to fastcgi.conf or manually set the relevant params.

Бинго. Промених виртуалните хостове да използват fastcgi.conf вместо да правя груби вмешателства и всичко запали. След това ударих един бърз diff за да видим разликата каква е между 2-та конфига


diff /etc/nginx/fastcgi_params /etc/nginx/fastcgi.conf
1a2
> fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

Което ми припомни че наливането на големи конфигурации във виртуаните хостове не е готина идея. Остава да си прекомпилирам отново Nginx-а с добавките които искам mod_sec + pagespeed но това може да почака. Далеч по важното е, че правилото ми се повтори ако нямаш огледа от 3-ти източници и кастъм изпълнения Debian не се чупи при dist-upgrade!

https://www.youtube.com/watch?v=gEQCny6zNF0