PHP GEOS is a PHP extension for geographic objects support, while RunCloud is a cloud server control panel designed for PHP applications. With PHP GEOS module installed on RunCloud, PHP applications can take advantage of geographic data and use the GEOS (Geometry Engine – Open Source) library to perform spatial operations.
In this blog post, I will show you how to install PHP GEOS module on RunCloud module.
Steps 1. Install the required development tools
Before installing the PHP GEOS module, make sure that the required development tools are installed on your Ubuntu server. You can install them by running the following command:
apt-get install autoconf
2. Install GEOS library Next, download and install the latest GEOS (Geometry Engine – Open Source)
wget http://download.osgeo.org/geos/geos-3.9.4.tar.bz2 tar xvf geos-3.9.4.tar.bz2 cd geos-3.9.4/ ./configure make make install
3. Install PHP GEOS module
Now, it’s time to install the PHP GEOS module. Follow the steps below to install it for PHP 8.2:
# make clean will always fail if you never compile it before make clean /RunCloud/Packages/php82rc/bin/phpize --clean /RunCloud/Packages/php82rc/bin/phpize ./configure --with-php-config=/RunCloud/Packages/php82rc/bin/php-config make && make install
This will install geos.so in the correct php extension directory
4. Add the module to PHP.ini file echo "extension=$MODULE_NAME.so" > /etc/php82rc/conf.d/$MODULE_NAME.ini
And finally restart the PHP FPM service systemctl restart php82rc-fpm
It’s important to note that the above steps are specific to PHP 8.2. If you wish to install the module for a different version, you will need to modify the commands accordingly. For instance, you can replace PHP 8.2 with 8.1 with below changes: Replace /RunCloud/Packages/php82rc/bin/phpize with /RunCloud/Packages/php81rc/bin/phpize, replace ./configure –with-php-config=/RunCloud/Packages/php82rc/bin/php-config with ./configure –with-php-config=/RunCloud/Packages/php81rc/bin/php-config, replace /etc/php82rc/conf.d/$MODULE_NAME.ini with /etc/php81rc/conf.d/$MODULE_NAME.ini, and replace systemctl restart php82rc-fpm with systemctl restart php81rc-fpm.
You can contact me if you need help with installing any custom modules on RunCloud control panel.
phpMyAdmin is installed with CentOS Web Panel. By default, it is not protected and there is only MySQL user authentication. This can put your server vulnerable. So it is recommended to add additional layer protection.
phpMyAdmin is available through the following url in a CWP based server.
http:/hostname/phpmyadmin http:/hostname:2030/pma
CWP panel runs its core services through its own version of Nginx. So normal htaccess based password protection will not work.
Create the Password File
You can do this by using the OpenSSL utilities that may already be available on your server. Alternatively, you can use the purpose-made htpasswd utility included in the apache2-utils package(Debian/ubuntu) or httpd-tools(Redhat/Centos).
Using OpenSSL Utilities
We will create a hidden file called .pma_pass /usr/local/cwpsrv/var/services/ folder. You can use any username. I am using dbadmin here as an example
sudo sh -c "echo -n 'dbadmin:' >> /usr/local/cwpsrv/var/services/.pma_pass"
Next, add an encrypted password entry for the username by typing:
sudo sh -c "openssl passwd -apr1 >> /usr/local/cwpsrv/var/services/.pma_pass"
Using Apache Utilities
This tool is already installed and available on all CWP servers.
We will need to configure Nginx to read this file before serving our protected content. CWP Service Nginx configuration file: /usr/local/cwpsrv/conf/cwp_services.conf
Open the above file add the following to the location block of phpMyAdmin.
To confirm that your content is protected, try to access your restricted content in a web browser. You should be presented with a username and password prompt
Ajenti is an open source, web-based control panel that can be used for a large variety of server management tasks. Optionally, an add-on package called Ajenti V allows you to manage multiple websites from the same control panel
Step 1: First make sure that all your system packages are up-to-date sudo apt-get update sudo apt-get upgrade
Step 2: Installing Ajenti Control Panel. wget -O- https://raw.github.com/ajenti/ajenti/1.x/scripts/install-ubuntu.sh | sudo sh
Anjeti will be available on HTTP port 8000 by default. Open your favourite browser and navigate to http://yourdomain.com:8000 or http://server-ip:8000 and enter default username “admin” or “root” and password is “admin”.
Change the password immediately to something secure.
Nagios provides complete URL monitoring of HTTP and HTTPS servers and protocols as well as full URL transaction monitoring.
Benefits
Implementing effective URL monitoring with Nagios offers the following benefits: * Increased server, services, and application availability * Fast detection of network outages and protocol failures * Monitor user experience when accessing URLs * Web server performance monitoring * Web transaction monitoring * URL monitoring
URL monitoring
By using the ‘check_http’ nagios command, we can monitor a specific url rather than checking the Apache service is up or not. This method is helpful to identify if the website is hacked and url is injected with malicious codes or there is some Apache or php errors and page is throwing an error instead. The normal Apache service check will return successful results in the above case. We can check for a specific keyword string on the webpage. If that string not present, an error will be returned.
Here is an real example
define service{
use urlmonitoring-service
host_name server.linuxwebhostingsupport.in
service_description url_check
check_command check_http!-H linuxwebhostingsupport.in -t 30 -R "Cpanel and WHM" -f follow
}
The above will check for the keyword “Cpanel and WHM” on the page “linuxwebhostingsupport.in”. If the keyword is missing or the page is not responding nagios will retun and error.
URL monitoring +SSL
You can refer to below example if the web page has SSL/TLS enabled.
Let’s start with your digital certificate, which is at the core of HTTPS. The certificate enables clients to verify the identity of servers, through a chain of trust from your server’s certificate through intermediate certificates and up to a root certificate trusted by users’ browsers. Your server certificate should be 2048 bits in length. Using 4096 bit certificate is more secure however it require more computation times and hence slow compared to 2048 bit certs.
Basic HTTPS Setup
Here are basic SSL configurations, first for Apache:
In Nginx, the ssl_certificate parameter is confusing. It expects your certificate plus any necessary intermediate certificates, concatenated together.
Make sure all of these files are at least mode 0444, except your private key, which should be 0400.
Software versions
On the server side you should update your OpenSSL to 1.0.1c+ so you can support TLS 1.2, GCM, and ECDHE as soon as possible. Fortunately that’s already the case in Ubuntu 12.04 and later.
On the client side the browser vendors are starting to catch up. As of now, Chrome 30, Internet Explorer 11 on Windows 8, Safari 7 on OS X 10.9, and Firefox 26 all support TLS 1.2.
Cipher Suite Configuration
The recommended cipher suites for Apache are follows
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLHonorCipherOrder on
The recommended cipher suite for backwards compatibility (IE6/WinXP):
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
SSLHonorCipherOrder on
If your version of OpenSSL is old, unavailable ciphers will be discarded automatically. Always use the full ciphersuite above and let OpenSSL pick the ones it supports.
The ordering of a ciphersuite is very important because it decides which algorithms are going to be selected in priority. The recommendation above prioritizes algorithms that provide perfect forward secrecy.
Prioritization logic
ECDHE+AESGCM ciphers are selected first. These are TLS 1.2 ciphers and not widely supported at the moment. No known attack currently target these ciphers. PFS ciphersuites are preferred, with ECDHE first, then DHE. AES 128 is preferred to AES 256. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks. In the backward compatible ciphersuite, AES is preferred to 3DES. BEAST attacks on AES are mitigated in TLS 1.1 and above, and difficult to achieve in TLS 1.0. In the non-backward compatible ciphersuite, 3DES is not present. RC4 is removed entirely. 3DES is used for backward compatibility
Protocol Support: SSL or no SSL
To prevent downgrade attacks and poodle attack, we will also disable old SSL protocols
For Apache:
SSLProtocol all -SSLv2 -SSLv3
For Nginx:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
This disables all versions of SSL, enabling only TLS 1.0 and up. All versions of Chrome and Firefox support at least TLS 1.0.