Input Bash script to compile Nginx from source with additional modules on Plesk Onyx

[learning_curve]

Actually, I should note that I have not updated this script since the first version

Looking forward to the all singing / all dancing, fully 17.8.11 compatible script update (and inclusive of sw-cp-server too? It is Easter soon after all...)

 

[IgorG]

and inclusive of sw-cp-server too?

Tell me please, what do you need sw-cp-server update for? What are you waiting for? Tell me more. For example, I'm waiting for an increase in productivity because ... Or, I'm waiting for improvements the stability because ...
And further, in detail, why do you think this really should be like this?
Thanks.

 

[learning_curve]

Tell me please, what do you need sw-cp-server update for? What are you waiting for? Tell me more

Apologies for the slight delay in response (was out of country) but the answer in simple terms:

We wish to use TLSv1.3 for everything on our server.
We can only do that when using nginx release 1.13 >>> plus other relevant upgrades
Currently, we are doing the nginx part, on everything that we run, apart from.... sw-cp-server
We need a later version of openssl and TLSv1.3 to have its officlal release to make this applied as opposed to almost ready status

Our current modified version of sw-cp-server runs on nginx release 1.12.1 which is a later release that the Plesk supplied 1.11.10 (but this modification was done for a different reason). Even so, we obviously cannot run TLSv1.3 on it, but we did set things up to allow it to be easily upgraded via the normal Plesk routine as/when the new spec sw-cp-server was released...

On a different (but related to sw-cp-server) thread @UFHH01 helpfully advised as follows: "...don't forget, that your invested time and efforts to compile your own "sw-nginx" and "sw-cp-server" with your own modifications might become obsolete, as Plesk updates its products always to common standarts and this will include as well TLS 1.3 in the future" He was completely correct (well...nearly ) because with the general release of Plesk 17.8.11 we (wrongly) assumed that both would be a part of this upgrade...

 

[virtubox]

New release available.

Changelog :

• Github page : Plesk Nginx
• update nginx : v1.13.10
• update brotli : v1.0.2

 

[IgorG]

We wish to use TLSv1.3 for everything on our server.

Please tell me in details why current sw-cp-server realization is not good for you? Is this not sufficiently protected or secure for you or what? Why is TLSv1.3 compliance so critical for you?
I would like to say that at the moment we do not know of any security problems with the current implementation of sw-cp-server and therefore updating it for TLSv1.3 compliance is not a priority for developers. But we keep this task in mind, and someday it will reach its turn.

 

[learning_curve]

Please tell me in details why current sw-cp-server realization is not good for you? Is this not sufficiently protected or secure for you or what? Why is TLSv1.3 compliance so critical for you?

^^ This is a question very similar to the one below that was posted in another thread earlier:

...BTW, could you please clarify why are you so worried about openssl for a sw-cp-server, while other services, like sshd, Apache, etc. work the same way with vendor's openssl version and you do not care?

And which was answered by another forum member:

Apache is not connected to the outside world on a system that has Nginx running. The Plesk interface is communicated to our clients and port 8443 is by now a "well-known port" and it always involves a login. SSH is not used by clients. I would rather do a virgin installation than a distupgrade. That's the reason I still have my CentOS 5.11 version. The OpenSSL-version on sw-cp-server doesn't depend on the client's OS, but on the OS on which you compiled it. You are the only supplier of a compiled sw-cp-serverd. How is it possible that I have a more modern sw-cp-serverd on end-of-life CentOS 5.11 than the people running the latest CentOS 7? You already answered that, really. It still would not stop you from supplying a more modern one for CentOS 6 & 7 and Ubuntu 12, 14. BTW.... All this is not of such importance to me as it may seem. It started with helping out @learning_curve and his need to apply the same tweaks on his panel as he had on his normal nginx. I had no problem applying those changes while he did. Only after many back-and-forths this openssl-version of sw-cp-serverd turned out to be the culprit. I wasn't expecting that.

Our own answer is yes it's protected and secure we do acknowledge and agree. However, as you may glean from the above answer / thread details, if you have a setup similiar to ours (signature) the protection level that's in place when using the default Plesk sw-cp-server, is behind the rest of our Plesk setup & this will increase once we're using 17.8.11

It's possible to modify many things within Plesk Onyx 17.5.3 in order to improve things. We have done so and you @IgorG have helped us frequently to do this! We also updated our default sw-cp-server too, but only with great help from forum member @Varrenlad in THIS #16 post and yes it works perfectly after this upgrade So with our current setup, we don't plan to make further changes for a while. This is because TLSv1.3 isn't definitively finished yet, although it's much, much closer now to being at general release status. There's a great danger of doing lot's of futher modification work twice at this point in time, which is why were waiting for TLSv1.3 / openssl / etc etc to all be formally relased, which we think might be in May.

We're happy right where we are currently with 17.5.3, but when running the whole 17.5.3 > 17.8.11 upgrade (when 17.8.11 reaches General Release status) we really want to do that just in just one project (which includes running your helpful bash script too after that's been updated to 17.8.11 as well) if at all possible! Not one project then lots of plus / plus / plus / plus / plus minor projects etc

TLSv1.3 is perhaps more important than many often realise. For example, we only use TLSv1.2 (and TLSv1.3 draft spec) currently, but almost without choice. This is because several online card processing API's that are used on domains that we host, will no longer accept anything less (including TLSv1.1). The same status change will happen again once TLSv1.3 becomes available, so that's one of the reasons why wer'e looking ahead to a smooth, all-inclusive upgrade to 17.8.11

I would like to say that at the moment we do not know of any security problems with the current implementation of sw-cp-server and therefore updating it for TLSv1.3 compliance is not a priority for developers. But we keep this task in mind, and someday it will reach its turn.

Yes fully understand this, but reading back through the above, it's not the same level on all setups (and it could easily be) Compared to the work involved in making 15.8.11 consistent across all setups, we are thinking (guessing) that this is much less work by comparison...

 

[IgorG]

This is because TLSv1.3 isn't definitively finished yet

Yes, and this is the main reason why we do not implement it for Plesk. As you may know, we never include beta, alpha, etc versions of components and technologies to Plesk.
Let's wait for the official TLSv1.3 release, ok?

 

[learning_curve]

.....Let's wait for the official TLSv1.3 release, ok?

Sure, that would be warmly welcomed by many. i.e. if the updated sw-cp-server becomes available very soon after TLSv1.3 is officially released. Yes, everybody would be very happy with that.

If it becomes like waiting for CentOS for the next upgrade though... (you know all about this ) then maybe we'll all have retired by then and won't be chasing it anymore

 

[IgorG]

BTW, I have updated my script for CentOS 7 - Archive - Script for building replacement of default sw-nginx Plesk package (CentOS7 Only!)

 

[virtubox]

New release available.
Changelog :

• latest nginx mainline release : v1.13.12
• revert ngx_brotli to the previous version due to issues

@IgorG I have no idea of the reason, but I'm not able to download the latest version of your script. The button "download" link to the first release with nginx v1.13.7

 

[IgorG]

@virtubox hmm... really. Strange. Will fix it when tomorrow I will come to the office. Thank you!

 

[learning_curve]

We'll check this update ^^ again later toady @IgorG just one question please, as we can't see a clear answer in the existing text / notes:

The new updated verison notes say "checked with Plesk 17.8 Centos 7.2" & that's quite clear.

However, we're using an earlier version of Plesk plus the latest version of CentOS (signature)
Has it already been tested with these version combinations? (and/or do you plan to do so..)
No problem either way, we just want to be sure of exactly how we do this, before we do it

 

[IgorG]

Well. The resource was updated with correct script version.

However, we're using an earlier version of Plesk plus the latest version of CentOS (signature)
Has it already been tested with these version combinations? (and/or do you plan to do so..)
No problem either way, we just want to be sure of exactly how we do this, before we do it

Yes, I tested it with 17.5.3 on CentOS 7 and it worked there as well.

 

[learning_curve]

Thanks! We'll have a very close look soon. We think we'll remove a couple of items in advance (e.g. Google Pagespeed which doesn't suit other items that we run) and then go from there. The earlier version has been updated by other users too, so we'll study both and then proceed carefully...

Okay @IgorG we're going to run this updated script this weekend

To allow us to miss out Google Pagespeed (old post above ^^) we assume we can remove this section:

wget https://github.com/apache/incubator-pagespeed-ngx/archive/v1.13.35.2-stable.tar.gz
tar -xzf v1.13.35.2-stable.tar.gz
cd incubator-pagespeed-ngx-1.13.35.2-stable
wget https://dl.google.com/dl/page-speed/psol/1.13.35.2-x64.tar.gz
tar -xzf 1.13.35.2-x64.tar.gz
rm 1.13.35.2-x64.tar.gz

and this section:

--add-module=/usr/local/src/incubator-pagespeed-ngx-1.13.35.2-stable \

from the script in advance?

And finally, we don't have Phusion Passenger installed or use it anyway.
Therefore, we assume we can also remove this final section too:

mv /etc/nginx/modules.conf.d/phusion-passenger.conf /etc/nginx/modules.conf.d/phusion-passenger.conf_bak
mv /etc/nginx/conf.d/phusion-passenger.conf /etc/nginx/conf.d/phusion-passenger.conf_bak

These omissions (of additional options) won't effect the success of the script, we're pretty sure of that.
What's your opinion before we do run it like this?

It's good practice, as we'll need to run your next update of this script, once TLSv1.3 is officially released, in order to update openssl, nginx and probably some of the modules too, so that TLSv1.3 all works "officially". The previous method that we ran, did run TLSv1.3 successfully (at draft-18) in several browsers, but then it became depreciated as you know. Everybody (including us) is kind of 'on hold' waiting for that imminent TLSv1.3 official release

 

[IgorG]

from the script in advance?

Yes, that will be enough.

What's your opinion before we do run it like this?

You can remove these lines. You can remove phusion configs later if you meet some problems with starting nginx.

 

[learning_curve]

It's always exciting when running mods We edited the script exactly as per our last post and then ran it.
Where Pagespeed was removed, the script now reads

< Snip >
tar -zxf ngx_http_redis-0.3.8.tar.gz
mv ngx_http_redis-0.3.8 ngx_http_redis
cd ..
rm *.gz
< Snip >

This resulted in one small error

rm: cannot remove ‘*.gz’: No such file or directory

but didn't stop or delay the script running, which it did, very smootly until the very end, where we had these errors

< Snip >
adding module in /usr/local/src/ngx_brotli
./configure: error: no /usr/local/src/ngx_brotli/config was found
make: *** No rule to make target `build', needed by `default'.  Stop.
make: *** No rule to make target `install'.  Stop.
< Snip>

It's too long to post on here, so here's a link to the full script run, for closer inspection: Full Script Run Data
After the script failure, we rolled back to the server snapshot taken just a few moments before running the script so we're now back to "as was" again. Obvioulsy there's an inconsistency somewhere, probably on our part. Any useful comments @IgorG ?

 

[m_p]

Hello,

Thank you for this very nice script!
Every thing going well but when I test with Qualys SSL Labs, TLS 1.3 is not working.

I check my nginx conf (seems to be OK):
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305-D:ECDHE-RSA-CHACHA20-POLY1305-D:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384';

I also checked nginx/openssl version (seems to be OK):
nginx version: nginx/1.13.12
built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
built with OpenSSL 1.1.1-dev xx XXX xxxx
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --user=nginx --group=nginx --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-file-aio --with-threads --add-module=/usr/local/src/ngx_cache_purge --add-module=/usr/local/src/memc-nginx-module --add-module=/usr/local/src/ngx_devel_kit --add-module=/usr/local/src/headers-more-nginx-module --add-module=/usr/local/src/echo-nginx-module --add-module=/usr/local/src/ngx_http_substitutions_filter_module --add-module=/usr/local/src/redis2-nginx-module --add-module=/usr/local/src/srcache-nginx-module --add-module=/usr/local/src/set-misc-nginx-module --add-module=/usr/local/src/ngx_http_redis --add-module=/usr/local/src/ngx_brotli --add-module=/usr/local/src/ngx_http_auth_pam_module --with-openssl=/usr/local/src/openssl --with-openssl-opt=enable-tls1_3

Is there something wrong?

Thank you!

 

[learning_curve]

...Every thing going well but when I test with Qualys SSL Labs, TLS 1.3 is not working < Snip>
Is there something wrong?...

Qualys SSL Labs are only reporting to TLSv1.3 draft 18 (which is now out of date ) whilst they presumably... like all of us are waiting for the imminent officlal TLSv1.3 release. Our current Qualys SSL Labs tests run at A+ but are slightly fake really, as a result of the draft 18 TLSv1.3 only status / verification (pic). The great CentOS script provided by @IgorG calls for TLSv1.3 draft 19 (not draft 18) so when implememnted successfully, will probably mean that our TLSv1.3 rating won't appear via Qualys SSL Labs anyway. We don't actually know yet, because we have to clear a slight glitch first, when running this script on our server (see above). TLSv1.3 draft 18 (as we have also posted above) worked well on several browsers, but then it became depreciated. It looks like you're on Debain not CentOS, so we can't comment on the script you have run (@virtubox probably will soon) but it's worth checking which draft you're running now, as this may be the reason you're not seeing TLSv1.3 at Qualys SSL Labs

 

[IgorG]

Any useful comments @IgorG ?

It should be like:

tar -zxf ngx_http_redis-0.3.8.tar.gz
mv ngx_http_redis-0.3.8 ngx_http_redis
# wget https://github.com/apache/incubator-pagespeed-ngx/archive/v1.13.35.2-stable.tar.gz
# tar -xzf v1.13.35.2-stable.tar.gz
# cd incubator-pagespeed-ngx-1.13.35.2-stable
# wget https://dl.google.com/dl/page-speed/psol/1.13.35.2-x64.tar.gz
# tar -xzf 1.13.35.2-x64.tar.gz
# rm 1.13.35.2-x64.tar.gz
# cd ..
rm *.gz

...........

 --add-module=/usr/local/src/ngx_brotli  \
# --add-module=/usr/local/src/incubator-pagespeed-ngx-1.13.35.2-stable \
 --with-openssl=/usr/local/src/openssl \
 --with-openssl-opt=enable-tls1_3

 

[learning_curve]

Thank you @IgorG for the clarification. That's fine now. We'll run a corrected version of the script tonight.

That's just a straightforward posts misunderstanding really. We detailed what we were intending to do in post #34 and you replied in post #35 With hindsight, your answer was wasn't 100% clear in terms of the precise method that should be used (i.e. Comment out. Do not remove from the script) But... our own post wasn't 100% clear anyway in terms of our intention to use which method. Whoops!