Ekde google ekamis https lokoj, pli necesa deplojo de SSL-kaj kie vi. Entute pli ol persekutadas por serviloj kaj havas degradación en rapido. La bona novaĵo estas, ke HTTP2 normo por pli ol jaro kaj duono estas integrita en ĉiuj grandaj http serviloj kaj retumiloj kaj subtenante stabila sufiĉa. Bedaŭrinde debian stabila neniu pakoj subteni HTTP2 en la ĉefa http serviloj. Versioj kiujn ni bezonas labori HTTP2 estas jenaj:

Por mi mishmash estas granda kaj laŭ dependas ĝuas apache aŭ nginx. Mi ankoraŭ ne ludis al ilia kuro de apache http2 de debian 8 ĉar ne havis sed backports repo havas tiel, Ĝi ne estos granda problemo. Por nginx jam ludis plurajn fojojn. Ĝenerale la ŝtupoj estas malmultaj kaj relative simpla:

  1. Aldoni nginx oficiala repo – la debian eldono, bonvolu 1.6.h estas 🙄
  2. Instali vian openssl de backports Nuntempe 1.0.2k – ke ni bezonas ALPN bontenado ordo por ĉiu labori kaj estas barzichko
  3. instali vian devscripts – Nun estas la tempo por dividi kiu bildnem nian pakaĵon pro la oficiala kompilis kun OpenSSL 1.0.1t kiu ne funkcias ALPN kaj retumiloj ne respondis bone kaj laboras http2 nur se ĝi devigis
  4. incremented versio ne metu ciganoj kun pakoj kaj kiel nova versio nur fonto por sinkenm

Komencu paŝo post paŝo

Aldoni nginx repo

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

Aldoni openssl 1.0.2k kaj dev biblioteko alie ni bildnem denove kun 1.0.1t ne nia celo

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

 

Nun forlasis aldoni bibliotekojn necesa por kompilo de nginx

apt install devscripts

apt build-dep nginx

mkdir nginx-build

cd nginx-build

apt-get source nginx

Se vi laboras ĝuste vi devas havi strukturon kiel

~/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 изпълнявате команда с която инкрементирате версията, Mi persone preferas aldoni 1 konstrui ĉi

debchange --newversion 1.10.3-1

Unufoje vi aldonas changelog-kaj laŭvole procedi al la fakta kompilo

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

Iom klarigon sur agordo komando:

-ni -uc diru la skripto ne “subskribita” .DSC kaj .changes dosierojn. -i kaj -mi kaŭzi la skripto ignori dosierojn de versitena. -B generi nur binaran pakaĵon. -j kiel en kiel fari paralelan procezon kompili 🙂

 

Post la supre procezo instali nian novan pakoj. Se vi jam instalis nginx estas bona malinstali

apt remove nginx nginx-*

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

dpkg -i ../*.deb

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

Лесно можем да избием всички mysql заявки на определн потребител с елегантното:

select concat('KILL ',id,';') from information_schema.processlist where user='user123';

Заместваме user123 с желаният от нас потребител и изпълняваме в mysql и всичко е ОК 🙂

la nova debian Stabila fakto pri semajne kaj manoj pikis ĝisdatigi virtualkata al ĝi sed mi ne havis tempon hodiaŭ. Ekde la tago mi komencis frue, mi decidis dediĉi mian tempon ĝisdatigi. Промених сорс листа ми като промених wheezy на jessie

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

tie muĝis 2 speguloj:

  • MariaDB – sur spegulo ne plu bezonas Jessie inkludas version 10.0.6 en mi mem mi ne sidis bone multaj. tiam 5.5 michetodb kaj mysql ne tute konsekvenca ĉar tiutempe ŝi turnis reen al mysql 5.5.42 – ĝi estas la defaŭlta Jessie
  • DotDeb – Mi uzis ĝin antaŭ ĉar php55 tie ankaŭ nenecesa ĉar Jessie venas kun 5.6.7-1

Post piedbatado la ekstra speguloj kaj turniĝis per MariaDB al Mysql apt-get dist-upgrade mian puran, reboot kaj mi devis Debiano 8.0. Mi malfermas mian retservilo-kaj al mia surprizo laboris tie longan historion – kelkaj vortoj Nginx-kaj mi kompilita el fonto cetere kun aldonaj instrukcioj. dpkg-l nginx mezo 1.2 Yep iu forgesis unhold-ne pakoj. Unhold kaj ĝisdatigi ĉiu estas sur horaro kaj nginx-rompado 😆 . Nginx-kaj laboro procesas demandoj kaj php-FPM procezo estas supren kaj runnign sed php kodo ne ekzekutitaj kaj ne kraĉi eraroj 🙄 miaj favoritos.

Post serĉante informojn pri la ŝanĝoj mi trovis la jenajn paŝo

Fastcgi agordo temoj ============================

nginx ekspedita modifita fastcgi_params, kiu deklaris SCRIPT_FILENAME fastcgi_param. Tiu linio nun estis forigita. De nun ni ankaŭ shipping fastcgi.conf de la kontraŭflua enciklopedio, kiu inkludas sanmensa SCRIPT_FILENAME parametro valoro.

tiel, se vi abonas fastcgi_params, Vi povas provi ŝanĝi al fastcgi.conf aŭ permane agordi la koncernajn params.

bingo. Mi ŝanĝis la virtuala gastigantoj uzi fastcgi.conf anstataŭ fari malĝentila entrudiĝoj kaj ĉio lumigis. Tiam batis rapidan malsamoj vidi kio estas la diferenco inter la 2 config

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

Kiu memorigis min ke verŝante grandaj konfiguracioj en Virtuala Cebaot estas malvarmeta ideo. Ĝi restas esti recompiled denove Nginx-kaj-ons kiu volas mod_sec + pagespeed sed tio povas atendi. Multe pli grave, че правилото ми се повтори ако нямаш огледа от 3-ти източници и кастъм изпълнения Debian не се чупи при dist-upgrade!

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

Ĉiu kiu estas engaĝita en ttt retprovizanton scias kion minaco estas infektitaj uzantoj kun malware, TTT konkoj ktp. En kazoj Ĉi Ĝenerala uzo h Ne malbona skripto. ĝi prezentas 3 aferoj

  1. Estas terure malrapida
  2. Estas terure malrapida kaj se ĝi enlasis monitoreo reĝimo estos izgavri servilo vi
  3. Subtenas lian propran datumbazon de MD5 / deksesuma difino de malbona kodo.

Nur lasta karakteriza faras ĝin utila, ĉar krom io alia povas sabmitvash dosierojn kiuj ne estis detektitaj ĝis nun, kaj ĉe pli posta stadio venos en datumbazoj. Kiel mi dividis en punkto 1 kaj 2 rapido estas ŝoke malalta – ĉe malalta ŝarĝo la maŝino 70K dosiero estas skanita por proksimume horo kaj duono. Tial mi komencis helpi mian bonan amikon kun ShadowX Malmö – Alternativa maldet skribita en Python kun malmulta flexibilidad. Bedaŭrinde, manko de tempo (ĉefe sed ne nur) Ni ne finis la projekton, kiuj nuntempe ne estas tre uzebla – ekzistas multaj bugs kiu devas esti malbarita. En la pasintaj tagoj mi havis problemojn kun klientoj infektita kun CryptoPHP kiu havis grandegan dosierojn public_html ~ 60k + inod-kaj Uzanto. Ekde entute devis esti skanita super 200k dosiero kiu malglate prenus 5+ horoj mi decidis agordi la agordo de maldet, malpliigi la dosieroj kiuj estos escaneados al pli racia nombro kaj tempo. Dum pluki confit rimarkis la sekvajn liniojn

# Attempt to detect the presence of ClamAV clamscan binary
# and use as default scanner engine; up to four times faster
# scan performance and superior hex analysis. This option
# only uses ClamAV as the scanner engine, LMD signatures
# are still the basis for detecting threats.
# [ 0 = disabled, 1 = enabled; enabled by default ]
clamav_scan=1

interese… Ŝajne estas eblo uzi ClamAV – kiu ankaŭ havas granda rapido sed kial ne provi. A rapide instalita

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

/scripts/check_cpanel_rpms --fix --targets=clamav

Maldet-kontrolita kaj sur malgranda dosierujo – Mi vidas neniun diferencon en rapido kaj konduto – Li uzas sian sia perl-skio skanilo anstataŭ tiun de ClamAV. Post mallonga cribado tra fonto de maldet trovis la sekvajn liniojn

 clamscan=`which clamscan 2> /dev/null`
 if [ -f "$clamscan" ] && [ "$clamav_scan" == "1" ]; then
        eout "{scan} found ClamAV clamscan binary, using as scanner engine..." 1
    for hit in `$clamscan -d $inspath/sigs/rfxn.ndb -d $inspath/sigs/rfxn.hdb $clamav_db -r --infected --no-summary -f $find_results 2> /dev/null | tr -d ':' | sed 's/.UNOFFICIAL//' | awk '{print$2":"$1}'`; do

Yep faris kiu clamscan и за моя голяма изненада открих че clamav изобщо не е в PATH-a ами тъпият Cpanel го е оставил само в /usr/local/cpanel/3rdparty/bin/ от където той си използва бинарките. Един бърз ln реши проблема:

ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan

При повторно сканиране maldet вече горно съобщава

{scan} found ClamAV clamscan binary, using as scanner engine...

След като вече използва ClamAV maldet приключва сканирането си 3-4-5 пъти по бързо в сравнение с преди. Теста показа – 70к inod-а ги изтъркла за около 25 мин което си е около 3 пъти и половина по бързо в сравнение с преди.

Antaŭ ĝi komencis kun alia hazarda malamo al 50 s'tinki VIN Mi signifas, ke ĉiutage mi devas administri ŝin scii unua persono singulara sufiĉe bone. Hodiaŭ mi pasigis tempon al iztestvam nova magia senekzempla kaj nevidataj trajto distrubitiven altgradigo (pseŭdo) 😀 . La unua afero kiu miris min estas, ke RedHat en lia senfina saĝo decidis descontinuar subtenon por x86 arkitekturo 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 iom longan instruon mankas. Мда ама какво правят потребителите на малки VPS-и – x64 piedo pli de memoro RAM, kiel vi rigardas ĝin se vi havas maldikan virtuala maŝino kun 512MB-1GB de RAM batalos por ĉiu megabay gxin kaj ne malŝpari 20-30% Nur uzi grandan aron de instrukcioj. Prepsuvah ĉar mi instalil CentOS x86 kaj x64 tiris unu. Tuj mi vidis diferencon en ISO-a – ~ 100MB minimuma при 6.5. Prepsuvah pli tempo. Mi instalis denove virtualkata mi decidis vidi kiom bone RedHat faris sian laboron – Mi donis / var kaj / usr apartaj LVM vandoj 😈 . Post instalado altgradigita ĉiuj pakoj instalitaj kaj apache, php, mysql и ligos – estis interesa kiu ekbrulas servo. Malfermiĝis kiel bona studento gvidado de CentOS ĝisdatigi kaj komencis diligente sekvi paŝon post paŝo. Kiam mi alvenis la momento por komenci la reala ĝisdatigo tiu monto leonoj skulptitaj mi, че имам критичен проблем 🙄 . Revizii detala eligo – mdaaaa / usr ĝi ne estas aparta subdisko 😆 mi sciis, Mi ne estos seniluziigita en Jim Whitehurst kaj kompanio. ŝpari “ekstrema” problemo estis tute mesaĝojn sensigna pakoj, konfizi dosierojn kiuj ne kongruas, ktp. WTF ne eĉ uzas trian deponejoj ĉiu el siaj speguloj tiris mian mi ne estus farinta ajnan agordojn nur simplaj yum install. Nun ĉio estis klara do tute senceremonie pelis altgradigo. Rekomenci denove diligente mi fine instigas la skripton kaj ĝi estis ĉie por / usr subdisko. Mi estis tro mallaborema, kiuj provas Fix, ĉiuokaze ĝi estis nur por sciencaj celoj neniel servilo produkto ĝisdatigi tiutempe. Mi kaptis reinstali vian virtualkata tiu tempo ĉiu baton ĝin 1 kunhavigi. Ankaŭ mi prenis lecionon, ne ĝisdatigas ajnan aldonan sarvasi, post instalado rekta ĝisdatigo. La fina paŝo denove venadis Dosa dialogon kiu rakontis al mi, Mi havas multajn problemojn Alta – nevalida pakoj, konfizi ktp sed povus daŭrigi. Mi sciis, ke en la komenco ne faras ilin malĝusta aferoj. Mi reboot denove kaj atendis – ho kia miraklo ĝisdatigo kompletigita sukcese. Kaj ĝi laboris, aŭ almenaŭ boto kaj ne provis instali kromajn pakaĵojn, sed halto komando dependas – sys ankoraŭ devis esti cimo 💡 . Post tiu tuta Tarapoto decidis instali pura CentOS 7 ĉu ni grumblante por / boot dispartigo en LVM – 6.5 ne permesas tian arogantecon. ISO-mi lanĉi ĝin kaj mi milde ŝokis la instalilo – ne estis ege komfortaj “ordigita”, tute nelogike bela. След известна борба успях със заветната цел и аха да се инсталира и гръмна, че трябва да си изнеса /boot-а извън LVM-a 👿 Това е крайно не сериозно и досадно, ако поради някаква причина забравиш да си увеличиш размера на boot дяла от 200МБ и понатрупаш стари ядра какво се случва.

В общи линии нищо не очаквах и пак съм разочарован от CentOS.