Resolved Updating Plesk Onyx, But Without Waiting For Plesk Updates

[learning_curve]

So far our Plesk experience has been nothing but rewarding and this forum has often been of great help if/when we have had issues. On our server, official "General Release" Plesk updates normally all work correctly and Non-Plesk updates (RPMs etc) using "Enable safe updates for system packages" also normally work correctly. However, Non-Plesk updates are more frequent (reaction to changes) than Plesk. So, we're busy working through how to carefully update key areas of Plesk Onyx ourselves (mainly items shown in our signature) in order to keep on top of all those 'regular challenges'. A quick look shows;

CentOS has just been upgraded;

rpm --query centos-release
centos-release-7-4.1708.el7.centos.x86_64

Apache is regularly backported by RHEL (only the last two notes are shown here);

rpm -q --changelog httpd
* Wed Oct 11 2017 CentOS Sources <[email protected]> - 2.4.6-67.el7.centos.5
- Remove index.html, add centos-noindex.tar.gz
- change vstring
- change symlink for poweredby.png
- update welcome.conf with proper aliases

* Tue Sep 19 2017 Luboš Uhliarik <[email protected]> - 2.4.6-67.5
- Resolves: #1493064 - CVE-2017-9798 httpd: Use-after-free by limiting
  unregistered HTTP method

Updating sw-cp-server (Plesk) was solved by @Varrenlad primarily with THIS post in a connected thread

rpm -qa | grep sw-cp-server
sw-cp-server-2.6-1.x86_64

Updating Postfix was solved by @IgorG with THIS post in a connected thread

rpm -qa | grep postfix
postfix-3.2.3-1.el7.centos.x86_64

Next is sw-nginx which is compiled on an old nginx release, so it's out of date and missing a few handy modules too

rpm -qa | grep sw-nginx
sw-nginx-1.11.10-centos7.17032813.x86_64

There's no news as to when this will be addressed by Plesk (well none that we can find anyway, at the time this thread was posted) So re-compiling sw-nginx from up-to-date sources and enabling it, is what we ourselves, need to do... Next Post

We didn't forget Dovecot, but Dovecot is not too far behind at present, so we'll cover that separately after nginx
The offical stable release is v2.2.33 (2017-10-10) and we are on v2.2.27 (2016-12-03):

rpm -qa | grep dovecot
plesk-dovecot-pigeonhole-0.4.16-centos7.17031614.x86_64
plesk-dovecot-core-2.2.27-centos7.17031716.x86_64
plesk-dovecot-2.2.27-centos7.17031716.x86_64
plesk-dovecot-imap-driver-17.5.3-cos7.build1705170317.16.x86_64

 

[learning_curve]

So moving on to "...re-compiling sw-nginx from up-to-date sources and enabling it, is what we ourselves, need to do"

There is already THIS brilliant post from @UFHH01 which is essentially what we are wanting to do plus other helpful posts too, like THIS one from @virtubox. We think that we can slowly and methodically follow these other posts and the challenges that they may present for us. Questions relevant to those threads we will post in them directly.

Our question before we start with any of these changes, is actually a lot more simple fortunately

How (where?) do we examine (in detail) the current sw-nginx specification with all it's associated dependences etc so that we can make 100% sure that the new 'unofficial, but much in demand' replacement version will run on our server 1st time The addition of TLS 1.3 / Pagespeed / Brotli etc are all added bonuses, which we'll set up correctly post-enablement, but not causing an issue with our fully working current setup is #1 priority.

It seems very simple, but if you've not done this before, then it isn't

 

[virtubox]

So moving on to "...re-compiling sw-nginx from up-to-date sources and enabling it, is what we ourselves, need to do"

There is already THIS brilliant post from @UFHH01 which is essentially what we are wanting to do plus other helpful posts too, like THIS one from @virtubox. We think that we can slowly and methodically follow these other posts and the challenges that they may present for us. Questions relevant to those threads we will post in them directly.

Our question before we start with any of these changes, is actually a lot more simple fortunately

How (where?) do we examine (in detail) the current sw-nginx specification with all it's associated dependences etc so that we can make 100% sure that the new 'unofficial, but much in demand' replacement version will run on our server 1st time The addition of TLS 1.3 / Pagespeed / Brotli etc are all added bonuses, which we'll set up correctly post-enablement, but not causing an issue with our fully working current setup is #1 priority.

It seems very simple, but if you've not done this before, then it isn't

Hello @learning_curve , for sw-nginx and sw-cp-server, you can display their current configuration with the option -V :

# sw-cp-serverd -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.1t  3 May 2016
TLS SNI support enabled
configure arguments: --prefix=/usr/share --sbin-path=/usr/sbin/sw-cp-serverd --conf-path=/etc/sw-cp-server/config --error-log-path=/var/log/sw-cp-server/error_log --http-log-path=/var/log/sw-cp-server/access.log --lock-path=/var/lock/sw-cp-server.lock --pid-path=/run/sw-cp-server.pid --http-client-body-temp-path=/var/lib/sw-cp-server/body --http-fastcgi-temp-path=/var/lib/sw-cp-server/fastcgi --http-proxy-temp-path=/var/lib/sw-cp-server/proxy --http-scgi-temp-path=/var/lib/sw-cp-server/scgi --http-uwsgi-temp-path=/var/lib/sw-cp-server/uwsgi --user=sw-cp-server --group=sw-cp-server --with-ipv6 --with-file-aio --with-http_ssl_module --with-http_v2_module --with-http_gzip_static_module --add-module=/home/builder/buildbot/sw-cp-server-trunk-bdeb80x64/build/sw-cp-server/work/lua-nginx-module-0.10.7 --add-module=/home/builder/buildbot/sw-cp-server-trunk-bdeb80x64/build/sw-cp-server/work/ngx_devel_kit-0.2.19

# nginx -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.2k  26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/share --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --modules-path=/usr/share/nginx/modules --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-ipv6 --with-file-aio --with-http_v2_module --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_dav_module --with-http_gzip_static_module --with-http_stub_status_module --with-openssl=/home/builder/buildbot/psa-17.8-bdeb80x64/build/unix/plesk/packages/nginx/work/openssl-1.0.2k --with-openssl-opt='enable-tlsext zlib no-idea no-mdc2 no-rc5 no-ssl2 no-shared -fpic' --add-dynamic-module=/usr/share/passenger/ngx_http_passenger_module

 

[UFHH01]

but if you've not done this before, then it isn't

Pls. 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. Reviewing your previous posts and threads to your desired goal(s), I come to the conclusion, that I shouldn't miss to suggest, that waiting one or two months could save you quite a lot of time.

 

[learning_curve]

Pls. 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. Reviewing your previous posts and threads to your desired goal(s), I come to the conclusion, that I shouldn't miss to suggest, that waiting one or two months could save you quite a lot of time.

Hahahaha Yes that's a very good point.

Our modified "sw-cp-server" will be overwritten by the official Plesk upgrade (just as the official current "sw-nginx" would have been) and we're totally fine with that. We'll know in advance and have backups just in case etc. If the official Plesk upgrade is bang up to date (latest nginx release / security levels etc) then this will be another positive (if somewhat overdue) welcome change from Plesk. FWIW: Modifying "sw-cp-server" ourselves was a very informative, relatively quick learning process for us and in the interim, our resultant modified "sw-cp-server" runs perfectly.

Modifying "sw-nginx" is far more involved and impactive though (we always leave the hardest things to last...) hence a lot of advance research and pre-reading before starting this. If we had some idea from somewhere, that the Plesk upgrade of "sw-nginx" was on target for say January 2018, then yes, it's not worth starting, fully agreed. As per your previous advice, we do keep a close eye on Plesk Onyx 17.8 updates, as they will come before our own Plesk Onyx 17.5.3 updates and would therefore give us an early indication, but we can't see any indication that it's even close over there yet... If we carefully run the modification ourselves meantime and the resultant modified "sw-nginx" then runs perfectly for say 4-6 months (like our modified "sw-cp-server" will have done ^^) we're fine with that too. It should provide us with more information - hopefully

 

[learning_curve]

Hello @learning_curve for sw-nginx and sw-cp-server, you can display their current configuration with the option -V

Sometimes it's the simplest things... Thank you @virtubox Yes we already use -V and ironically, as a result of somebody posting this advice for us in a previous thread. We were not sure that this alone, was 'everything' we needed to check everything in advance (...always check the checker ) but seeing as your own post on this (that we linked above) is way ahead of our experience so far, then we assume this is all you needed, to make the progress you have so far.

Brilliant, we'll now move carefully forward. We may wait a little while though, to see your finished version CentOS bash script, as this may save a lot of time and effort on our part. Hopefully @IgorG will re-test your finished version too, which would be very useful and helpful for you, us and others. Thanks again