Amióta a google kezdett, mint a https oldalak, Miután több tömeges telepítés az SSL- és hol lehet. Összességében mellett további zaklatás a szerverek van és lebomlás sebessége. A jó dolog, hogy HTTP2 a szabvány több mint egy év és egy fél integrált, az összes főbb böngészők és a szerverek és a http-támogatás kellően stabil. Sajnos nincs nincs stabil debian csomagok tartani a fő http-kiszolgálók HTTP2. A verziók, szükséges számunkra, hogy HTTP2 a következők:

Nekem Mešanicata nagy és szerint használandó függ, apache, vagy nginx. Én még nem játszottam elengedem a http2 apache debian 8 Mivel soha nem volt, de van ez így repoto backports, Ez nem lesz egy nagy probléma. Nginx már játszott több alkalommal. Összességében a lépések pedig néhány viszonylag egyszerű:

  1. Add hozzá nginx hivatalos repo – a debian az 1,6 x vesiâta. 🙄
  2. Openssl telepítése magad backports jelenleg 1.0.2 (k) – Mire van szükségünk, a ALPN karbantartás, minden működik, és gyors
  3. a devscripts telepítése – Itt az ideje megosztani, hogy lesz bildnem a csomagot, mert a hivatalos össze openssl 1.0.1-t, ami nem működik a ALPN, és nem a böngészők válaszol jól, és működik, csak akkor, ha http2-revving,
  4. inkrementirame a verzió, hogy ne tartsa csomagok, mint például a ciganiâta és van egy új változat, csak a sinkenm sorsovete

Kezdjük meg a lépésről lépésre

Összead nginx repo

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

Összead egy k dev openssl könyvtár 1.0.2 és más módon bildnem azt újra 1.0.1 én t a cél

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

 

Most már megragadt az ő hozzáadása a könyvtárak szükséges nginx összeállítása

apt install devscripts

apt build-dep nginx

mkdir nginx-build

cd nginx-build

apt-get source nginx

Ha helyesen dolgozik, akkor a szerkezet, mint

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

Jelentkezzen be a papta, hol razarhiviran a nginx forrása, az én esetemben az a nginx-1.10.3 futó parancs, amelyek verziójú inkrementirate, Én személyesen jobban szeret-hoz összead 1 erre a buildre

debchange --newversion 1.10.3-1

Miután hozzáadta a changelog és folytatása, hogy a tényleges fordítás

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

A konfiguráció, a parancs egy kis pontosítás:

-nekünk - uc azt mondják, a parancsfájl nem “aláírt” .DSC és a változások fájlt.. -én és -Én hogy a szkript, hogy figyelmen kívül hagyja a verziókövetési fájlok. -B egyetlen bináris csomag létrehozásához. -j mint, hogy hány párhuzamos folyamat-hoz újból összeállító a 🙂

 

Befejezése után a fenti folyamat nem kéne felszerel a új csomagok. Ha már telepítette a nginx van jobb-hoz uninstall ez

apt remove nginx nginx-*

Is nem egy rossz ötlet, hogy a mappa biztonsági másolatának a nginx, stb. Általában, amikor a frissít 1.6.5 hogy 1.10.3 Nem a dráma volt, de sosem lehet tudni. Az új paktei a felső szintű mappában találhatók, és telepíteni kell egy parancs, mint:

dpkg -i ../*.deb

Ha minden simán ment játszani a nginx folyamat, és állítsa be a http2, amely már nem ez a cikk van.

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

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

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

Az új Debian stabil Tény, körülbelül egy hét, és kezet viszketett frissíteni virtualkata hozzá, de nem volt időm ma. Mivel a nap kezdetén, úgy döntöttem, hogy fordítson időm frissíteni. Én változtatott az én-m forrás listát, mint Mária jessie megváltozott

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

itt ordított 2 tükrök:

  • MariaDB – A tükör nem kell Jessie-as verziót tartalmazza 10.0.6 a magam nem ül jól sok. majd 5.5 michetodb és mysql nem egészen következetes, mert abban az időben megfordult vissza mysql 5.5.42 – ez az alapértelmezett Jessie
  • DotDeb – Régebben, mielőtt az php55 itt felesleges is, mert Jessie jön 5.6.7-1

Miután rugdossa az extra tükrök és megfordult a MariaDB MySQL apt-get dist-upgrade az enyém tiszta, indítsa újra, és meg kellett Debian 8.0. Kinyitottam a webszerver-és meglepetésemre dolgozott itt egy hosszú történet – Néhány szót nginx-én összeállított forrásból további kiegészítő irányelvek. dpkg -l nginx-teljes 1.2 Ja valaki elfelejtette Beléptetés-nem csomagokat. Beléptetés és korszerűsítése minden a tervek szerint halad, és nginx-törés 😆 . Nginx-és munkafolyamatok lekérdezések és php-FPM folyamat, és runnign de php kód nem kerül végrehajtásra, és nem köpött hibák 🙄 kedvencem.

Keresés után információt a változásokat találtam a következő szakaszt

Fastcgi konfigurációs problémák ============================

nginx szállított egy módosított fastcgi_params, amely kimondta SCRIPT_FILENAME fastcgi_param. Ez a vonal már eltávolították. Mostantól mi is hajózási fastcgi.conf a tárházzal, amely magában foglalja a józan SCRIPT_FILENAME paraméter értéke.

Így, ha használ fastcgi_params, akkor váltson fastcgi.conf vagy manuálisan állítsa be a megfelelő params.

bingó. Megváltoztattam a virtuális gépeket használni fastcgi.conf ehelyett durva behatolások és mindent megvilágított. Majd nyomja a gyors diff, hogy mi a különbség a 2 config

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

Ami arra emlékeztetett, hogy ömlött nagy konfigurációk virtuális házigazdák jó ötlet. Továbbra is újra kell fordítani újra nginx-és kiegészítőket, akik mod_sec + PageSpeed ​​de ez várhat. Messze még fontosabb, Ismétlem, ha nem néz a források és a 3. ruha előadások nem Debian dist frissítési break - szabály!

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

Bárki, aki részt vesz tárhely tudja, milyen veszélyt jelent a fertőzött felhasználók malware, web kagyló stb. Azokban az esetekben jelen általános használatra h Nem rossz script. Jellemzője 3 a dolgok

  1. Szörnyen lassú
  2. Ez szörnyen lassú, és ha hagyja, hogy a monitoring módban izgavri szerver
  3. Megtartja saját adatbázisa md5 / hex meghatározása rossz kód.

Csak a múlt tulajdonság teszi hasznos, mert eltekintve bármi mást sabmitvash fájlokat, amelyeket nem mutattak ki eddig, és egy későbbi szakaszban lépnek adatbázisok. Amint azt a közös pont 1 és 2 sebesség megdöbbentően alacsony – kis terhelés a gép 70K fájl beolvasása körülbelül egy és fél óra. Emiatt kezdtem, hogy segítsen a jó barát ShadowX Malmö – alternatív maldet írt python kevés rugalmasságot. Sajnos, az idő rövidsége (elsősorban, de nem kizárólag) mi nem fejezte be a projekt, amely abban a pillanatban nem nagyon használható – sok hibát, hogy tisztázni kell. Az elmúlt napokban nem volt probléma az ügyfelek fertőzött CryptoPHP aki nagy fájlok public_html ~ 60k + inod-és felhasználói. Mivel összesen kellett szkennelni alatt 200K fájl, amely nagyjából tartana 5+ órát úgy döntöttem, hogy beállítsa a konfiguráció maldet, hogy csökkentse a fájlok lesznek vizsgálva, hogy egy ésszerű számban és időben. Míg szedés confit észrevette a következő sorokat

# 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

érdekes módon… Úgy látszik, van egy lehetőség, hogy használni ClamAV – amely szintén tartalmaz nagy sebességgel, de miért nem próbálja. A gyorsan telepíthető

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet-futás és egy kis mappa – Nem látok különbséget a sebesség és a viselkedés – Ő használja az ő perl-ski szkenner helyett, hogy a clamav. Egy rövid szitálás forrása maldet talált a következő sorokat

 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

Ja tett amely clamscan és nagy meglepetésemre rájöttem, hogy clamav nem található elérési út, mi egy hülye Cpanel elhagyta őt csak a/usr/helyi/cpanel/3rdparty/bin/a házmester binarkite ahol. Egy gyors erősít a probléma ln:

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

Scan most maldet felső jelentések bíró

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

Után már használ ClamAV maldet véget ér a beolvasás 3-4-5 szer gyorsabb, mint korábban. A vizsgálat azt mutatta – 70k-izt″rkla inod őket a 25 min, ami körülbelül 3 és fél-szer gyorsabb, mint korábban.

Mielőtt elkezdte egy másik véletlenszerű gyűlöletet 50 s'tinki OS értem, hogy minden nap azt kell beadni neki, hogy az első személy egyes szám meglehetősen jól. Ma töltöttem időt iztestvam új mágikus hallott és látott funkció distrubitiven frissítés (ál) 😀 . Az első dolog, ami lenyűgözött engem, hogy RedHat végtelen bölcsességében úgy döntött, hogy hagyja abba támogatása x86 architektúra 🙄 . Én vagyok tisztában, hogy mi vagyunk az évben 2014 és kiszolgáló processzorok 32 kicsit hosszú használati hiányzik. Igen, de a felhasználók mit egy kis VPS és – x64 mancs több RAM, ahogy nézzük, ha vékony a virtuális gép 512-1 GB RAM harcolni fog minden megabay, és nem pazaroljuk 20-30% Csak, hogy egy nagy sor utasítást. Prepsuvah mert én instalil CentOS x86 és x64 kihúzott egy. Azonnal láttam a különbséget ISO-edik – ~ 100MB minimum при 6.5. Prepsuvah még egyszer. Telepítettem újra virtualkata úgy döntöttem, hogy milyen jól RedHat volna a munkát – Adtam a / var és / usr külön LVM partíciók 😈 . A telepítés után frissíteni az összes telepített csomagok és apache, php, mysql и kötődnek – Érdekes volt, hogy kifogja a tűzoltóság. Nyitott, mint egy jó tanuló vezetésével CentOS frissítéséhez és elkezdte szorgalmasan követni lépésről lépésre. Amikor elérte a pillanatban kezdődik a tényleges frissítés a hegyi oroszlán faragott nekem, Nekem van egy kritikus probléma 🙄 . Tekintse át részletes kimenet – mdaaaa / usr ez nem egy külön partíción 😆 Tudtam, Nem lennék csalódott Jim Whitehurst és a társaság. megment “szélső” probléma meglehetősen üzenetek aláíratlan csomagok, konfizi fájlokat, amelyek nem felelnek meg, stb. WTF nem is használja a harmadik adattárak mindent a tükör húztam nem tettem volna semmilyen beállítást csak egyszerű yum install. Most minden világos volt, így elég teketória nélkül kényszerű frissítési. Ismét újraindítani szorgalmasan végül kéri a forgatókönyvet, és ez volt az egész / usr partíció. Túl lusta voltam, hogy megpróbálja megjavítani, egyébként ez csak tudományos célra semmilyen módon kiszolgáló termék frissíteni idején. Elkaptam újratelepítését virtualkata ezúttal mindent lök a 1 részvény. Szintén vettem egy leckét, nem frissíti minden további sarvasi, telepítés után közvetlen frissítés. Az utolsó lépés ismét jött DOSA párbeszéd, aki azt mondta, Van egy csomó bajt Nagy – érvénytelen csomagokat, konfizi stb, de tudta folytatni. Tudtam, hogy az elején nem teszik őket rossz dolgokat. Azt indítsd újra a gépet, és vártam – ó, milyen csoda frissítés sikeresen befejeződött. És működött, vagy legalábbis csomagtartó, és nem próbált további csomagok telepítését, de halt parancsot függ – sys még volt, hogy egy hiba 💡 . Miután ez az egész Tarapoto úgy döntött, hogy telepíteni egy tiszta Centos 7 hogy ha morogva a / boot partíció LVM – 6.5 nem teszi lehetővé az ilyen arrogancia. ISO-én indít el, és nagyon enyhén sokkolt a telepítő – nem volt rendkívül kényelmes “takaros”, teljesen logikátlan, hogy gyönyörű. Után néhány harc kezelt-hoz felszerel a tömítéssel dédelgetett cél és igen, Meg kell oldania ki/boot-és azon túl-👿 egy LVM rendkívül súlyos, és nem zavaró, Ha részére némely ok ön elfelejt-hoz növekszik a méret, a rendszerindító partíció a 200 MB, és néhány régi magok mi történik.

Alapvetően én nem várok semmit, és én vagyok még mindig csalódott a CentOS.