As google het begin om lief te hê https webwerwe, verder, die massa installasie van SSL en waar kan. Gewoonlik, ook, meer boelie vir die bedieners wat ons het en die agteruitgang in die spoed. Goed, wat HTTP2 die standaard is reeds meer as die helfte van'n integrasie in al die groot http bedieners en implementeer, en die inhoud is redelik stabiel. Ongelukkig, nie debian stabiele pakkette wat bied HTTP2 ondersteuning in basiese http bedieners. Die weergawes wat ons nodig het om te werk in HTTP2 soos volg:

Ek het mecanizata groot en hang om te gebruik apache of nginx. Ek het nog nie gespeel te stoot debian apache http2 8 aangesien ek nie backports, maar repoto dit is so, dit is nie'n groot probleem. Vir nginx ons gespeel het'n paar keer. As'n reël, stappe en'n paar relatief maklik:

  1. Voeg die amptelike nginx repo – debian weergawe - 1.6.x 🙄
  2. Installeer dit van backports openssl op die oomblik is 1.0.2 k – ons nodig het om te ALPN ondersteuning in orde om vinnig te werk
  3. devscripts installeer dit – hier is die tyd om te deel wat sal bildner ons pakket, want die amptelike is saamgestel met die openssl weergawe 1.0.1 in wat t nie werk nie ALPN en implementeer nie reageer nie en hardloop http2-net as sy forcers
  4. incremential weergawe, nie te maak hou van tiganita pakkette as daar is in die nuwe weergawe, net sink Aravete

Kom ons begin stap deur stap

Voeg nginx retrograde

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

Voeg openssl 1.0.2 k en dev biblioteke, anders sal dit bildner selfs met 1.0.1 t dat ons is nie die doel

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

 

Dit bly nou om te voeg by die biblioteke wat nodig is om te stel nginx

apt install devscripts

apt build-dep nginx

mkdir nginx-build

cd nginx-build

apt-get source nginx

As jy gewerk het korrek, jy moet'n struktuur van'n soort

~/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

Tik PPTA in wat gebruikers kode nginx in my geval, hierdie nginx-1.10.3 voer die opdrag wat incrementare weergawe, Ek persoonlik verkies om by te voeg 1 op die huidige bou

debchange --newversion 1.10.3-1

Nadat dit voeg die changelog-as'n keuse, kan jy gaan na die werklike samestelling

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

'n bietjie duidelikheid oor die opset opdrag:

-ons-uc sê die skrif nie “tekens” .dsc en .veranderinge lêers. -ek en -Ek die krag van die script te ignoreer lêers vir weergawe beheer. -B net genereer die binêre pakket. -j en wanneer jy maak, hoe baie parallelle proses van die versameling van 🙂

 

Na voltooiing van die vorige proses moet geïnstalleer word ons nuwe pakkette. As jy reeds geïnstalleer nginx-dit is goed, jy moet dit verwyder

apt remove nginx nginx-*

Ook nie'n slegte idee om'n rugsteun van die nginx gids onder /ens. In beginsel, wanneer die opdatering van 1.6.5 om te 1.10.3 Ek het nie drama nie, maar jy weet nooit. Nuwe Partei is in die hoër-vlak gids, en moet geïnstalleer word met'n opdrag soos:

dpkg -i ../*.deb

As alles vlot, jy moet net om te begin die nginx proses, en om te stel http2 dit is nie die doel van hierdie artikel.

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

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

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

Nuwe Debian Stabiel feit oor'n week en ek shirbaha hande, sal dit update virtualdata hom, maar ek het nie tyd om te vandag. As my dag begin vroeg besluit om te wy tyd updates. Промених сорс листа ми като промених wheezy на jessie

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

Hier, miskien, 2 spieël:

  • MariaDB – hierdie spieël is nie meer nodig in hees sluit weergawe 10.0.6 in myself dat ek nie regtig nie.. Na 5.5 Michelob en mysql is nie heeltemal versoenbaar is, want tans urjtag terug te mysql 5.5.42 – dit is die standaard in jessie
  • DotDeb – Ek gebruik dit voor, om te php55 hier is ook nie nodig nie, want Jessie kom met 5.6.7-1

Na azkarah ekstra spieëls en urjtag MariaDB van Mysql apt-get dist-opgradering op my suiwer, herlaai en ek het reeds met Debian 8.0. Ek het my web bediener, en tot my verbasing, hier gewerk het'n lang geskiedenis – 'n paar woorde met Nginx-my versamel addisionele bron met bykomende Richtlijn. dpkg-l nginx-volle 1.2 mdaaa iemand het vergeet unhold-nie-pakkette. Unhold en opgradering van al die plan nginx-en gebreek 😆 . Nginx en hardloop, prosesse versoeke en php-fpm proses is en runnign maar php-kode is nie uitgevoer nie en nie spoeg foute 🙄 MY GUNSTELING.

Na'n paar navorsing wat vir'n verandering het ek die volgende gedeelte

Fastcgi opset kwessies ============================

verskeep'n aangepaste nginx fastcgi_params, wat verklaar fastcgi_param SCRIPT_FILENAME. Hierdie lyn is nou verwyder. Van nou af ons is ook gestuur fastcgi.Conf van die stroomop repository, wat sluit'n normale SCRIPT_FILENAME parameter waarde.

So, as jy met behulp van fastcgi_params, jy kan probeer om oor te skakel na fastcgi.conf of met die hand stel die betrokke parameters.

Bingo. Ek verander die virtuele gasheer te gebruik fastcgi.conf in plaas daarvan, maak'n onbeskofte geraas, en al die lig. Dan tref'n vinnige diff om die verskil te sien, wat tussen die 2de apache

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

Ek onthou dat die giet van groot konfigurasies in virtualite die leërskare nie'n goeie idee. Dit bly te wees precompilers weer Nginx en byvoegings wat ek wil mod_sec + pagespeed maar dit kan wag. Veel meer belangrik is, че правилото ми се повтори ако нямаш огледа от 3-ти източници и кастъм изпълнения Debian не се чупи при dist-upgrade!

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

Enigiemand wat handel professioneel met web hosting weet wat die bedreiging verteenwoordig besmet gebruikers wat met hierdie malware, web skulpe ens. In obset hier gebruik maldet een slegte script. Dit verskil 3 dinge

  1. Vreeslik stadig
  2. Regtig stadig en as jy dit laat gaan in monitor af sal, shauri server wat jy
  3. Hou sy eie databasis met die md5/hex, definitiewe slegte kode.

Dit is die laasgenoemde funksie maak dit nuttig, want onder ander dinge, kan symitar lêers wat nog nie ontdek is so ver en op'n later stadium sal kry in die databasis. As gedeel in die punt 1 en 2 sy spoed is skokkend laag – by lae las op die motor 70K lêer geskandeer vir'n uur en'n half. Vir hierdie rede, het ek begin om te help om my goeie vriend, ShadowX met Malmö – alternatiewe maldet geskryf in python met'n bietjie van buigsaamheid. Ongelukkig, as gevolg van'n gebrek van die tyd (meestal, maar nie net) ons doen nie dovrsili projek, wat is tans nie baie nuttig – daar is nogal'n baie van die foute om skoon te maak. Oor die afgelope paar dae het ek het probleme gehad met kliënte besmet is met CryptoPHP wat'n groot public_html lêers ~60K+ inod-gebruiker. So in samewerking moes word nagegaan op 200k lêer wat groot rekeninge sal dit neem 5+ uur het ek besluit tuningova opset maldet, om te verminder die lêers wat sal nagegaan word in'n meer redelike plek en tyd. Terwyl die kies van konfa opgemerk die volgende lyne

# 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

Interessant… Natuurlik, dit is moontlik om te gebruik ClamAV – wat is nie'n hoë spoed, maar nie hoekom nie om te probeer. Vinnig ek stel

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Vrylating maldet-'n klein gids – Ek sien geen verskil in spoed en gedrag – gebruik dit perl-ish skandeerder plaas vir clamav. Na'n kort grawe in die kode maldet ek het gevind dat die volgende lyne

 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

Mdaaa, ek het een wat 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 пъти и половина по бързо в сравнение с преди.

Voor ek begin met'n ander ewekansige % % 50 ’tinky OS ek bedoel, elke dag het ek het haar administrasie, en weet dat dit van die eerste persoon enkelvoud is redelik goed. Vandag het ek het die tyd om te estestven nuwe magie sechuana en nog nooit tevore gesien funksies te werk distrubition (pseudo) 😀 . Die eerste ding wat my opgeval het, was dit, dat RedHat in hul oneindige wysheid besluit om te staak hierdie diens x86 argitektuur 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 bietjie van die gebruiker ontbreek vir'n lang tyd. Мда ама какво правят потребителите на малки VPS-и – 64-bietjie meer RAM kloue, as jy kyk na dit, as jy het'n dun virtuele trimmer met 512MB-1GB ram sal veg vir elke megaball van haar en nie voorstel 20-30% dit is om te gebruik'n groot stel van instruksies. Prasowej sedert ek installeer x86 CentOS en lig een 64-bit. Ek het gesien die verskil in die ISO-oktaan – ~100MB minimum 6.5. Prasowej een meer tyd. Ek het dit geïnstalleer weer virtualita, het ek besluit om te sien RedHat, hoe goed het die werk – Ek het /var en /usr op'n aparte LVM mure 😈 . Na die installasie ek opgedateer al die pakkette ek het geïnstalleer en apache, php, mysql en bind – het gewonder of om die lig van sylvinite. Ek het dit soos'n goeie meisie gids tot CentOS vir die opgradering en begin getrou aan sy behoeftes stap vir stap. Toe ek by die punt om te begin om die werklike gradeer hierdie pumie my izraza, че имам критичен проблем 🙄 . "Die bees het gesê uitset – mdaaaa /usr is nie'n aparte afdeling 😆 ek geweet het, dit sal nie teleurgesteld wees Jim Whitehurst en maatskappy. In bykomend “een van die” die probleem is, was daar nogal'n baie van die boodskappe oor unsigned pakkette, lêers vir confidi wat nie ooreenstem met, en so aan. WTF was nie eens in die guns van'n 3de bron van al hul spieëls Smirna het nie enige instellings, net die basiese yum installeer. Alles was duidelik, so duidelik forsarah op te gradeer. Herlaai weer gehoorsaam as ek gevra word, ten slotte, die skrif, en dit eindig as gevolg van die /usr partisie. Ek is te lui, wat om te probeer om te fiksna, така или иначе всичко беше само с научна цел няма как продуктов сървър да го надграждам към момента. Хванах преинсталирах си виртуалката като този път всичко си го набутах в 1 дял. Също си взех поука, никакви ъпдейти никакви допълнителни сървъси, след инсталацията директен ъпгрейд. На финалната стъпка отново изскочи досаният диалог който ми каза, че имам доста High проблеминевалидни пакети, конфизи и прочие но може да продължи. Знаех си че по начало не ги правят както трябва нещата. Рестартирах отново и зачакахо какво чудо ъпгрейда приключи успешно. И всичко работеше или поне зареждането на системата така и не пробвах да инсталирам допълнителни пакети, но halt командата си зависвашехух все пак трябваше да има бъг 💡 . След тая цялата тарапана реших да инсталирам на чисто Centos 7 да видим дали ще ръмжи за /boot дял в LVM – 6.5 не позволява такава дързост. Стартирах си ISO-то и бях меко казано шокиран от инсталаторавсичко беше крайно не удобноподредено”, напълно алогично с цел да е красиво. Na'n paar stryd daarin geslaag om met die gekoesterde doel te bereik, en ja, om te installeer en te klap, wat jy nodig het om te sit /boot buite van LVM-'n 👿 Hierdie uiters ernstige en irriterende, as vir een of ander rede vergeet om te verhoog die grootte van die boot partisie van 200MB en paratroopas ou pitte, wat gebeur.

In die Algemeen, enigiets nie verwag nie en hoewel ek is teleurgesteld in CentOS.