Recently there was an issue where the fopen and curl function and shell_exec functions were reverting back to original values. Using the MutiPHP Editor was not working.

the resolution was that the php-fmp handler was being used on a cpanel server. So the php-fpm config file needed to be changed.

The line that needs to be edited is:in /opt/cpanel/ea-php56/root/etc/php-fpm.d/$DOMAIN

Remove the disable_functions which includes shell_exec

php_admin_value[disable_functions] =

Then restart the following services.

systemctl restart httpd.service
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_cpanel_php_fpm

UPDATE; Seems the yaml files need to be updated:
https://forums.cpanel.net/threads/stop-cpanel-from-overwriting-php-fpm-settings-file.596527/

This information is for editing the yaml file which should result in permanent changes.

More information here on php-fpm configurations:
https://documentation.cpanel.net/display/64Docs/Configurations+Values+of+PHP-FPM#ConfigurationsValuesofPHP-FPM-Howtoremovedefaultvaluesfromaconfiguration

UPDATE 2:

Also, there was an issue with fopen where the changes in the MultiPHP Editor were being overwritten.

If  PHP handler is LSAPI, you can adjustment to your Apache configuration. Please ensure the setting is enabled for the site(s) in question under MultiPHP Ini Editor. If this still does not work, in whm from   Home »Software »MultiPHP Manager there is a System PHP-FPM Configuration tab and from it you can change the user override ability for allow_url_fopen and other options.

 

The Plesk Control Panel has the ability to create multiple MySQL and PostgreSQL databases as well as multiple users within each database. Also, directly accessible via Plesk, are the links to phpMyAdmin and PhpPGAdmin, the PHP interface applications that abstract mysql or postgresql into a web-based administration tool, allowing you to sort, edit, and create tables within a given database.

Before creating your databases within the Plesk Control Panel, please ensure that you have already added a hosted domain name to your dedicated server.

Here is how you can create MySQL (or PostgreSQL) databases using Plesk:
Login to your Plesk Control Panel. The login URL is in the following format (https://ipaddress:8443).
Click on Websites and Domains from the navigation bar on the left.

Select the domain name that you’d like to associate your database with.
Click the Databases icon on the top right menu.

Click the Add Database icon.

Add the Database Name
Select the related site for the data base.
Click the “Create a Database User” box in order to setup database administrator’s credentials.
Enter a username and a password which will be used for accessing the contents of the database.
Select if the User has access to all databases.
Select Access Control for the database.
Click OK.
Now, you can use the phpMyAdmin and other tools where you can manage your database.

I went and adjusted the expected time out to 4 hours on every domain and on the default settings through Plesk. But it seems that instead of time outs being handled by php, the server runs a cron job that handles the timeouts and ignore php settings. That breaks our apps. Is it there a way to change his?

See: https://websavers.ca/plesk-php-sessions-timing-earlier-expected

After switching a WordPress website to FPM served by nginx in Plesk, it fails to load with “404 Not Found” on all pages except start page.

See: https://support.plesk.com/hc/en-us/articles/213912945-A-WordPress-website-on-a-Plesk-server-shows-404-Not-Found-on-all-pages-except-index-php-when-running-on-FPM-by-nginx

For one website

In Plesk, add the content below to the Additional nginx directives field of the WordPress domain at Domains > example.com > Apache & nginx Settings:


    if (!-e $request_filename) {
    set $test P;
    }
    if ($uri !~ ^/(plesk-stat|webstat|webstat-ssl|ftpstat|anon_ftpstat|awstats-icon|internal-nginx-static-location)) {
    set $test "${test}C";
    }
    if ($test = PC) {
    rewrite ^/(.*)$ /index.php?$1;
    }


I am using mariadb and I to investigate some issue I wanted to check the logs. To my surprise, log file is not generated for mariadb.

I suspect this cannot be the case so I am doubting my search skills.

MariaDB [(none)]> show variables like 'log_error'
    -> ;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_error     |       |
+---------------+-------+
1 row in set (0.00 sec)

I have added the entry in my.cnf still above field is coming to be empty.

[root@cslcodev11-oem ~]# cat /etc/my.cnf
[mysqld]
!includedir /etc/mysqld/conf.d
datadir=/mnt/mgmt/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
tmpdir=/mnt/mgmt/var/lib/mysql_tmp
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
### TRT-3229 #####
sync_binlog=1
innodb_flush_method=O_DIRECT
innodb_support_xa = 1
myisam_repair_threads = 2
myisam_recover_options = FORCE
###################
innodb_file_per_table=1
innodb_log_buffer_size = 8M
table_open_cache=256
max_heap_table_size=256M
### TRT-4685 ###
max_connections=500
################
innodb_log_file_size = 512M

[mysqld_safe]
log-error=/var/log/mariadb/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[root@cslcodev11-oem ~]# 

So, I want to know do we have any default location where these logs are getting generated, if the path cannot be read from config files.

INFO: Reference: https://mariadb.com/kb/en/mariadb/error-log/

On the MariaDB Knowledge base page for the error-log there is a paragraph that states.

systemd has its own logging system, and Linux distributions running systemd may log errors there instead. To view the systemd logs, use:

# journalctl -u mariadb.

This answers the question because –log-error would be an option that could be added to MY_SPECIAL.conf file and journalctl is where mariadb logs errors by default on a systemd system.

iPerf is a command-line tool used in diagnosing network speed issues by measuring the maximum network throughput a server can handle. It is particularly useful when experiencing network speed issues, as you can use iPerf to determine which server is unable to reach maximum throughput.

Basic usage:

run iperf -s on machine A then go to machine b and run iperf -c and it’ll tell you the xfer speed

Install iPerf

The iperf package is included in most Linux distribution’s repositories.

Debian and UbuntuPermalink

# apt-get install iperf

CentOS

CentOS repositories do not have iPerf. Use the EPEL repository, which is a repository used to install third-party software packages on RedHat systems such as RHEL and CentOS:

# yum install epel-release
# yum update
# yum install iperf

Arch LinuxPermalink

# pacman -S iperf

openSUSEPermalink

# zypper install iperf

GentooPermalink

# emerge iperf

If you have not yet run emaint –sync you may need to do so before it will allow you to install the iPerf package. Additionally, by default you will need to substitute each iperf command with /usr/bin/iperf3. This path may differ dependent on your iPerf version.

How to Use iPerf

iPerf must be installed on the computers at both ends of the connection you’re testing. If you are using a Unix or Linux-based operating system on your personal computer, you can install iPerf on your local machine.

If you are testing the throughput of your server, however, it’s better to use another server as the end point, as your local ISP may impose network restrictions that can affect the results of your test.

CP Clients & Servers

iPerf requires two systems because one system must act as a server, while the other acts as a client. The client connects to the server you’re testing the speed of.

On the server you plan to test, launch iPerf in server mode:

# iperf -s

You should see output similar to:

      
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

On your second server, connect to the first. Replace 198.51.100.5 with the first servers IP address.


# iperf -c 198.51.100.5

     
------------------------------------------------------------
Client connecting to 198.51.100.5, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 198.51.100.6 port 50616 connected with 198.51.100.5 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  1.27 GBytes  1.08 Gbits/sec

You will also see the connection and results on your iPerf server:


------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 198.51.100.5 port 5001 connected with 198.51.100.6 port 50616
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.1 sec  1.27 GBytes  1.08 Gbits/sec

To stop the iPerf server process, press CTRL + c.

UDP Clients & Servers

Using iPerf, you can also test the maximum throughput achieved via UDP connections.

Start a UDP iPerf server:

# iperf -s -u

      
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------

Connect your client to your iPerf UDP server. Replace 198.51.100.5 with your IP address:


# iperf -c 198.51.100.5 -u

   
------------------------------------------------------------
Client connecting to 198.51.100.5, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 198.51.100.6 port 58070 connected with 198.51.100.5 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  3] Sent 893 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.084 ms    0/  893 (0%)

1.05 Mbits/sec is considerably less than what was observed on the TCP tests. It is also considerably less than the maximum outbound bandwidth cap provided by the 1GB link. This is because iPerf limits the bandwidth for UDP clients to 1 Mbit per second by default.

You can change this with the -b flag, replacing the number after with the maximum bandwidth rate you wish to test against. If you are testing for network speed, set this number above the maximum bandwidth cap provided by your provider:

# iperf -c 198.51.100.5 -u -b 1000m

This tells the client that we want to achieve a maximum of 1000 Mbits per second if possible. The -b flag only works when using UDP connections, since iPerf does not set a bandwidth limit on the TCP clients.

   
------------------------------------------------------------
Client connecting to 198.51.100.5, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
 ------------------------------------------------------------
      [  3] local 198.51.100.5 port 52308 connected with 198.51.100.5 port 5001
      [ ID] Interval       Transfer     Bandwidth
      [  3]  0.0-10.0 sec   966 MBytes   810 Mbits/sec
      [  3] Sent 688897 datagrams
      [  3] Server Report:
      [  3]  0.0-10.0 sec   966 MBytes   810 Mbits/sec   0.001 ms    0/688896 (0%)
      [  3]  0.0-10.0 sec  1 datagrams received out-of-order

This time the results are considerably higher.

Bidirectional Tests

In some cases, you may want to test both servers for the maximum amount of throughput. This can easily be done using the built-in bidirectional testing feature iPerf offers.

to test both connections, run the following command from the client:

# iperf -c 198.51.100.5 -d

The result is that iPerf will start a server and a client connection on the client server (198.51.100.6). Once this has been done, iPerf will connect the iPerf server to the client connection, which is now acting as both a server connection and a client connection.

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 198.51.100.5, TCP port 5001
TCP window size:  351 KByte (default)
------------------------------------------------------------
[  3] local 198.51.100.6 port 50618 connected with 198.51.100.5 port 5001
[  5] local 198.51.100.6 port 5001 connected with 198.51.100.5 port 58650
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.1 sec  1.27 GBytes  1.08 Gbits/sec
[  3]  0.0-10.2 sec  1.28 GBytes  1.08 Gbits/sec

On the server, you will see:


------------------------------------------------------------
Client connecting to 198.51.100.6, TCP port 5001
TCP window size:  153 KByte (default)
------------------------------------------------------------
[  6] local 198.51.100.5 port 58650 connected with 198.51.100.6 port 5001
[  6]  0.0-10.1 sec  1.27 GBytes  1.08 Gbits/sec
[  5]  0.0-10.2 sec  1.28 GBytes  1.08 Gbits/sec

Options
Option Description
-f Change the format in which the tests are run. For example, you can use -f k to get results in Kbits per second instead of Mbits per second. Valid options include m (Mbits, default), k (Kbits), K (KBytes), and M (MBytes).
-V Forces iPerf to use IPv6 rather than IPv4.
-i Changes the interval between periodic bandwidth tests. For example, -i 60 will make a new bandwidth report every 60 seconds. The default is zero, which performs one bandwidth test.
-p Changes the port. When not specified, the default port is 5001. You must use this flag on both the client and server.
-B Binds iPerf to a specific interface or address. If passed through the server command, the incoming interface will be set. If passed through the client command, the outgoing interface will be set.

Recently, there was an issue with a curl command that ran a script with php. The curl command would finish after a lengthy time as before it was completing within seconds.

The issue turned out to be that the command was using the IPV6 connection where in the data center the IPV6 was not active.

This was discovered with the -v option in curl.

curl -v "https://domain.com/path-to-php-script.php"
/* About to connect() to domain.com port 443 (#0)
/* Trying 2a09:2980:f0ee:a:fabe:b50c:0:2...
/* Connection timed out
/* Trying 23.17.44.888...

As you can see – the IPV6 address times out. The solution is to disable IPV6 in the network setting for the Ethernet card.