Sinds google begon graag https-sites, hebben meer massa installatie voor SSL- en waar u kunt. Overall, naast meer intimidatie voor servers die wij hebben en afbraak in snelheid. Het goede ding is, die HTTP2 de standaard voor meer dan een jaar en een half is geïntegreerd in alle belangrijke browsers en servers en http-ondersteuning voldoende stabiel. Helaas is er geen stabiele debian pakketten te houden in de belangrijkste http servers HTTP2. De versies die nodig voor ons zijn te bedienen HTTP2 zijn als volgt:

Mešanicata mij is groot en volgens worden gebruikt hangt af van apache of nginx. Ik ben nog steeds niet spelen te laat los op de http2 van debian apache 8 Aangezien ik nooit heb gehad maar hebben het zo repoto-backports, Het zal niet een groot probleem. Voor nginx speelde al meerdere malen. Over het geheel genomen zijn de stappen paar en relatief eenvoudig:

  1. Voeg nginx officiële repo – in debian is 1.6 x vesiâta. 🙄
  2. Installeren van de openssl zelf backports is momenteel 1.0.2 (k) – Wat we nodig hebben voor ALPN onderhoud voor iedereen werkt en is snel
  3. u installeert de devscripts – Dit is de tijd om te delen dat zal bildnem onze pakket omdat de ambtenaar is gecompileerd met openssl 1.0.1-t die ALPN niet werkt en niet de browsers reageren goed en werkt alleen als http2-revving het
  4. inkrementirame de versie aan houd niet pakketten zoals ciganiâta en er is een nieuwe versie alleen voor sinkenm sorsovete

Laten we beginnen met stap voor stap

Voeg nginx repo

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

Voeg een k dev openssl bibliotheek 1.0.2 en anders bildnem het weer met 1.0.1 ik t is het 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

 

Nu vast aan zijn bibliotheken die nodig zijn voor de compilatie van nginx toevoegen

apt install devscripts

apt build-dep nginx

mkdir nginx-build

cd nginx-build

apt-get source nginx

Als u correct werkt, moet je een structuur, zoals

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

Meld u aan bij papta waar razarhiviran de bron van de nginx in mijn geval is is de opdracht nginx-1.10.3 uitgevoerd en welke versie inkrementirate, Ik verkies persoonlijk toe te voegen 1 aan deze te bouwen

debchange --newversion 1.10.3-1

Nadat u een changelog toevoegen en kan overgaan tot de eigenlijke compilatie

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

Een beetje opheldering over de configuratie van de opdracht:

-ons - uc ze zeggen dat het script niet te “ondertekend” .DSC en wijzigingen in bestanden.. -Ik en -Ik Maak het script om te negeren van de bestanden voor versiebeheer. -B voor het genereren van een binaire enige pakket. -j Als met maken hoeveel parallelle proces te compileren van 🙂

 

Nadat u de bovenstaande procedure heb voltooid moeten we onze nieuwe pakketten installeren. Als u al hebt geïnstalleerd nginx is het beter om het te desinstalleren

apt remove nginx nginx-*

Ook geen slecht idee om een back-up van de map in de nginx/etc. In het algemeen, wanneer u een upgrade uitvoert van 1.6.5 Aan 1.10.3 Ik had geen drama, maar je weet maar nooit. De nieuwe paktei bevinden zich in de map van het hoogste niveau en moet worden geïnstalleerd met een commando zoals:

dpkg -i ../*.deb

Als alles verliep vlot je blijft alleen om nginx proces lopen en kan worden geconfigureerd http2 is niet langer doel van dit artikel.

We kunnen gemakkelijk doden alle mysql-query een specifieke gebruiker elegante:

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

Het vervangen van user123 met onze gewenste gebruikersnaam en uit te voeren in mysql en alles is OK 🙂

de nieuwe Debian Stable een feit ongeveer een week en handen jeukten om virtualkata upgraden naar het, maar ik had geen tijd vandaag. Sinds de dag dat ik vroeg begon, heb ik besloten om mijn tijd te besteden om te upgraden. Промених сорс листа ми като промених wheezy на jessie

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

hier brulde 2 spiegels:

  • MariaDB – op de spiegel niet meer nodig Jessie bevat versie 10.0.6 in mezelf dat ik niet zitten ook veel. dan 5.5 michetodb en mysql zijn niet helemaal consequent, want op het moment draaide ze terug naar mysql 5.5.42 – Het is de standaard Jessie
  • DotDeb – Ik gebruikte het al eerder voor php55 hier is ook niet nodig, omdat Jessie wordt geleverd met 5.6.7-1

Na toen hij de extra spiegels en draaide door MariaDB om Mysql apt-get dist-upgrade mine schoon, reboot en ik moest Debian 8.0. Ik opende mijn web server-en tot mijn verbazing werkte hier een lang verhaal – een paar woorden Nginx-en ik samengesteld uit de bron verder met extra richtlijnen. dpkg -l nginx-full 1.2 Yep iemand vergat te unhold-niet-pakketten. Uit standby en upgrade alles ligt op schema en nginx-breaking 😆 . Nginx-en werkprocessen queries en php-FPM proces is en runnign maar php-code wordt niet uitgevoerd en niet spuwen fouten 🙄 mijn favorieten.

Na een zoektocht van informatie over de wijzigingen vond ik de volgende passage

FastCGI configuratiekwesties ============================

nginx verscheept een gemodificeerde fastcgi_params, die SCRIPT_FILENAME fastcgi_param verklaard. Deze lijn is nu verwijderd. Vanaf nu zijn we ook de scheepvaart fastcgi.conf van de upstream repository, waaronder een gezonde SCRIPT_FILENAME parameterwaarde.

Zo, als u gebruik maakt fastcgi_params, kunt u proberen over te schakelen naar fastcgi.conf of handmatig in te stellen de relevante params.

bingo. Ik veranderde de virtuele hosts te gebruiken fastcgi.conf plaats maken onbeleefd inbraken en alles verlicht. Sloeg vervolgens een snelle diff om te zien wat is het verschil tussen de 2 config

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

Die herinnerde me eraan dat het gieten van grote configuraties in Virtual gastheren zijn cool idee. Het blijft om opnieuw te worden gecompileerd Nginx-en-ons die mod_sec willen + PageSpeed ​​maar dat kan wachten. Veel belangrijker, че правилото ми се повтори ако нямаш огледа от 3-ти източници и кастъм изпълнения Debian не се чупи при dist-upgrade!

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

Iedereen die zich bezighoudt met web hosting weet wat gevaar besmet gebruikers met malware, web schelpen etc. In gevallen Dit Algemeen gebruik h geen slechte script. Het beschikt over 3 dingen

  1. Is verschrikkelijk traag
  2. Het is verschrikkelijk traag en als het laat de bewaking modus server izgavri u
  3. Handhaaft zijn eigen database van md5 / hex definitie van slechte code.

Net laatste eigenschap maakt het nuttig, want afgezien van iets anders bestanden die niet zijn tot nu toe hebben ontdekt kunnen sabmitvash, en in een later stadium zal in databases komen. Zoals ik gedeeld in punt 1 en 2 snelheid is schrikbarend laag – bij lage belasting van de machine 70K bestand wordt gescand op ongeveer een uur en een half. Om deze reden ben ik begonnen met mijn goede vriend met ShadowX helpen Malmo – alternatieve maldet geschreven in Python met weinig flexibiliteit. Helaas, gebrek aan tijd (vooral, maar niet alleen) we hebben niet het project af, die op dit moment niet erg bruikbaar – er zijn vele bugs die moeten worden opgeruimd. In de afgelopen dagen had ik problemen met cliënten die besmet zijn met CryptoPHP die grote bestanden public_html ~ 60k + inod-en User had. Aangezien de totale moest worden gescand meer dan 200k dossier dat ruwweg zou nemen 5+ uur heb ik besloten om afstemmen van de configuratie van maldet, om de bestanden die worden gescand naar een redelijk aantal en de tijd verminderen. Terwijl het oppakken confit merkte de volgende regels

# 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

belangwekkend… Blijkbaar is er een mogelijkheid om te gebruiken ClamAV – die heeft ook grote snelheid, maar waarom niet proberen. Een snel geïnstalleerd

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet-run en op een kleine map – Ik zie geen verschil in snelheid en het gedrag – Hij is met behulp van zijn van zijn perl-ski scanner in plaats van die van de ClamAV. Na een korte uitpluizen bron van maldet vond de volgende regels

 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 maakte een die 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 пъти и половина по бързо в сравнение с преди.

Voordat het begon met een andere willekeurige haat aan 50 s'tinki OS ik bedoel, dat elke dag heb ik te beheren haar leren kennen als eerste persoon enkelvoud vrij goed. Vandaag heb ik tijd om nieuwe magie ongehoord en ongezien functie distrubitiven upgrade iztestvam (pseudo) 😀 . Het eerste wat mij verbaasd is, dat RedHat in zijn oneindige wijsheid besloten om ondersteuning voor x86-architectuur te staken 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 beetje lang instructie ontbreekt. Мда ама какво правят потребителите на малки VPS-и – x64 poot meer RAM-geheugen, als je er naar kijkt als je dunne virtuele machine met 512 MB-1 GB RAM zal vechten voor elke megabay het en geen afval 20-30% Gewoon om een ​​grote reeks instructies gebruiken. Prepsuvah want ik was instalil CentOS x86 en x64 trok een. Meteen zag ik een verschil in ISO-th – ~ 100 MB minimum при 6.5. Prepsuvah nog een keer. Ik opnieuw geïnstalleerd virtualkata ik besloten om te zien hoe goed RedHat hun werk hebben gedaan – Ik gaf / var en / usr aparte LVM partities 😈 . Na de installatie opgewaardeerd alle pakketten geïnstalleerd en apache, php, mysql и bind – het was interessant dat de brandweer zal vangen. Geopend als een goede leerling leiding van CentOS te werken en begon ijverig om stap voor stap te volgen. Toen ik het moment bereikt om de werkelijke upgrade beginnen deze berg leeuwen gesneden me, че имам критичен проблем 🙄 . Geef je mening over gedetailleerde uitvoer – mdaaaa / usr niet kan is een aparte partitie 😆 ik wist, Ik zou niet teleurgesteld worden in Jim Whitehurst en bedrijf. besparen “extreem” probleem was nogal berichten ondertekende pakketten, konfizi bestanden die niet overeenkomen, etc.. WTF was niet eens gebruik maken van de derde repositories alles uit hun spiegels trok mijn ik had geen instellingen gewoon simpel gedaan yum install. Nu is alles duidelijk was zo rustig zonder plichtplegingen gedwongen upgrade. Herstart weer ijverig als ik eindelijk gevraagd het script en het was allemaal voorbij voor / usr partitie. Ik was te lui, die proberen om Fix, toch was het slechts voor wetenschappelijke doeleinden geen manier server product te upgraden op het moment. Ik ving opnieuw uw virtualkata deze keer alles duw het in 1 aandeel. Ook nam ik een les, geen updates eventuele extra sarvasi, na installatie direct upgrade. De laatste stap kwam weer op DOSA dialoog die me vertelde, Ik heb veel moeite High – ongeldig pakketten, konfizi etc. maar hij kan verder. Ik wist dat er in het begin niet ze verkeerde dingen te maken. Ik reboot opnieuw en wachtte – oh wat een wonder upgrade succesvol afgerond. En het werkte, althans opstarten en niet geprobeerd om extra pakketten te installeren, maar halt commando hangt af – sys moest nog een bug 💡 . Na deze hele Tarapoto besloten om een ​​schone installatie van CentOS 7 om te zien of we grommen voor / boot partitie in LVM – 6.5 niet een dergelijke arrogantie toestaan. ISO-lanceer ik het en ik werd licht geschokt door de installateur – Het was niet erg comfortabel “ordelijk”, volkomen onlogisch om mooie. След известна борба успях със заветната цел и аха да се инсталира и гръмна, че трябва да си изнеса /boot-а извън LVM-a 👿 Това е крайно не сериозно и досадно, ако поради някаква причина забравиш да си увеличиш размера на boot дяла от 200МБ и понатрупаш стари ядра какво се случва.

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