Ever since google started to love https sites, more mass installation of SSLs is required where possible. In general, in addition to more harassment for servers, we also have a degradation in speed. It's good, that HTTP2 the standard has been integrated in all major http servers and browsers for over a year and a half and its support is stable enough. Unfortunately debian stable does not have packages that support HTTP2 in the main http servers. The versions we need for HTTP2 to work are as follows:

For me the mix is ​​big and depending depends on apache or nginx. I haven't played playing debian's apache http2 yet 8 since I didn't have to but in backports the repo is like that, that won't be a big deal. For nginx has already played it several times. In general, the steps are several and relatively simple:

  1. We add the nginx official repo – in debian the version is 1.6.x 🙄
  2. Installing openssl from backports is currently 1.0.2k – this is what we need for ALPN maintenance so that everything can work and be fast
  3. we install our devscripts – here is the moment to share that we will build our package because the official one is compiled with openssl 1.0.1t where ALPN does not work and the browsers do not respond well and the http2 works only if you force it
  4. we increment the version so as not to hold the gypsies with the packages and when there is a new version only to sync sources

Let's start step by step

Add nginx repo

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

Adding openssl 1.0.2k and the dev library otherwise we will build it again with 1.0.1t which is not our goal

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


Now it remains to add the libraries needed to compile nginx

apt install devscripts

apt build-dep nginx

mkdir nginx-build

cd nginx-build

apt-get source nginx

If you have worked correctly you must have a structure like

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

You enter a folder in which the source of nginx is unzipped, in my case it is also nginx-1.10.3 you execute a command with which you increment the version, I personally prefer to add 1 to the current build

debchange --newversion 1.10.3-1

After adding the changelog of your choice, you can proceed to the actual compilation

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

A little explanation of the command configuration:

-us -uc tell the script not to “signs” .dsc and .changes files. -i and -I cause the script to ignore version control files. -B to generate only a binary package. -j as in make with how many parallel processes to compile 🙂


Once the above process is complete, we should install our new packages. If you already have nginx installed, it's a good idea to uninstall it

apt remove nginx nginx-*

It's also a good idea to back up the nginx folder in / etc. Basically when upgrading from 1.6.5 to 1.10.3 I had no dramas but you never know. The new packs are located in the top-level folder and should be installed with a command such as:

dpkg -i ../*.deb

If everything went smoothly, all you have to do is run the nginx process and configure http2, which is no longer the goal of this article..

We can easily kill all mysql requests of a certain user with the elegant one:

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

We replace user123 with the user we want and run in mysql and everything is OK 🙂

The new one Debian Stable has been a fact for about a week and my hands were itching to upgrade my virtual machine next to it but I didn't have any time until today. Since my day started early, I decided to dedicate time to the upgrade. I changed my source list by changing wheezy to jessie

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

They thundered here 2 mirrors:

  • MariaDB – from this mirror no longer needs Jessie includes a version 10.0.6 in myself which I didn't like very much. After 5.5 michetodb and mysql are not quite compatible which is why at the moment I turned back to mysql 5.5.42 – it is the default in jessie
  • DotDeb – i used it before for php55 here is also redundant because jessie comes with 5.6.7-1

After I lost the unnecessary mirrors and turned from MariaDB to Mysql apt-get dist-upgrade went clean, reboot and I was already with Debian 8.0. I opened my web server and to my surprise it worked here, the story is long – in a few words my Nginx is further compiled from source with additional directives. dpkg -l nginx-full 1.2 mdaaa someone forgot to unhold-not the packages. Unhold and upgrade everything is according to plan nginx broke 😆 . Nginx works processing requests and the php-fpm process is up and runnign but the php code does not execute and does not spit errors 🙄 MY FAVORITE.

After some searching for information about the changes, I found the following passage

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.

Bingo. I changed the virtual hosts to use fastcgi.conf instead of making rough interventions and everything worked. Then I hit a quick diff to see the difference between the 2 configs

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

Which reminded me that pouring large configurations into virtual hosts is not a cool idea. It remains to recompile my Nginx again with the add-ons I want mod_sec + pagespeed but this can wait. It is far more important, that my rule is repeated if you do not have the review from 3rd sources and custom performances Debian does not break at dist-upgrade!

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

Anyone who deals professionally with web hosting knows the threat posed by infected users with malware, web shells etc. In the general case it is used maldet a not bad script. It is distinguished by 3 things

  1. It's terribly slow
  2. It's terribly slow and if you put it in monitoring mode it will mess with your server
  3. Supports own database with md5 / hex definitions for bad code.

It is its last feature that makes it useful, because, among other things, you can submit files that have not been detected so far and will enter the databases at a later stage.. As I shared in point 1 and 2 its speed is shockingly low – at low machine load, 70k files were scanned in about an hour and a half. For this reason, I started helping my good friend ShadowX with Malmo – an alternative to maldet written in python with a little more flexibility. Unfortunately for lack of time (mainly but not only) we have not completed the project, which is not very usable at the moment – there are a lot of bugs that need to be cleared. In the past few days I had problems with clients infected with CryptoPHP who had huge public_html files ~ 60k + user inods. Since a total of over 200k files had to be scanned, which would take roughly 5+ hours I decided to tune the configuration of maldet, to reduce the files that will be scanned to a reasonable number and time. As I picked up the conf, I noticed the following lines

# 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 ]

Interesting… Apparently there is an opportunity to use ClamAV – which also does not differ in its high speed, but why not give it a try. I quickly installed it

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

I run the maldet on a small folder – I don't see a difference in speed and behavior – he used his perl scanner instead of the clamav. After a short digging through the source of maldet, I found the following lines

 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

Hmmm, I made one which clamscan and to my great surprise I found that clamav is not in the PATH at all, but the stupid Cpanel left it only in / usr / local / cpanel / 3rdparty / bin / from where he uses his binaries. A quick ln solved the problem:

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

When re-scanning, maldet already reports the above

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

After already using ClamAV maldet, it finishes its scan 3-4-5 times faster than before. The test showed – 70k inod-a rubbed them for about 25 min which is about 3 times and a half faster than before.

Before I start with another random hate to 50 thin OS I mean, that I have to administer it every day and I know it first hand singular quite well. Today I took the time to test the new magical unheard and unseen feature for a destructive upgrade (pseudo) 😀 . The first thing that amazed me was, that RedHat in its infinite wisdom have decided to stop supporting the x86 architecture 🙄 . I am fully aware that we are 2014 and server processors with 32 bits instructions have been missing for a long time. Yep, but what do users of small VPSs do? – x64 paw more frame, as well as look at it, if you have a thin virtual machine with 512MB-1GB RAM, you will fight for every megabyte of it and you will not waste 20-30% from it just to use on the big set of instructions. I messed up because I had x86 CentOS installed and pulled an x64. I immediately saw a difference in the ISOs – ~100MB при minimal 6.5. I cursed once more. I reinstalled the virtual machine and decided to see how well RedHat did their job – I exported / var and / usr to separate LVM partitions 😈 . After the installation, I updated all the packages and installed apache, php, mysql и bind – it was interesting if they would turn on the services. As a good student, I opened the CentOS guide to the update and diligently began to follow it step by step.. When I got to the point where the real upgrade started, this cougar cut me off, that I have a critical problem 🙄 . I'm reviewing the detailed output – mdaaaa / usr can't be on a separate partition 😆 I knew, that I will not be disappointed with Jim Whitehurst and company. Except “the extreme” problem there were a lot of messages about unsigned packages, confiscation files that do not match and so on. WTF I hadn't even used 3rd repositories everything from their mirrors I took down I hadn't made any settings just simple yum install. Everything was already clear, so I unceremoniously forced the upgrade. I restarted diligently again as the script finally prompted me and everything ended because of the / usr partition. I was too lazy, that I'm trying to fix it, anyway, everything was just for scientific purposes, there is no way to upgrade a product server at the moment. I caught reinstalling my virtual machine and this time I pushed everything into it 1 title. I also learned a lesson, no updates no additional services, after installation direct upgrade. In the final step, the annoying dialogue he told me reappeared, that i have quite high problems – invalid packages, confiscations and so on but can continue. I knew in the beginning they didn't do things right. I restarted again and waited – oh what a miracle the upgrade ended successfully. And everything worked or at least the system boot and I never tried to install additional packages, but the halt command hung – huh still had to have a bug 💡 . After all this fuss, I decided to install Centos clean 7 let's see if it will growl for / boot partition in LVM – 6.5 does not allow such audacity. I started my ISO and was shocked by the installer to say the least – everything was extremely inconvenient “tidy”, completely illogical in order to be beautiful. After some struggle I succeeded with the cherished goal and aha to install and explode, that I have to take my / boot out of the LVM 👿 This is extremely not serious and annoying, if for some reason you forget to increase the size of the boot partition from 200MB and accumulate old kernels what happens.

In general, I did not expect anything and I am still disappointed with CentOS.