Search results

As far as I know, to change this setting for existing sites, you need to use the CLI (or edit the PSA database directly) This CLI command should be able to do that:

OpenSSL 1.1.1h indicates that your PHP supports TLS 1.2 and even 1.3 (from OpenSSL 1.0.1 on, TLS 1.2 is supported) Most likely something else in your environments is responsible for the "downgrade" to TLS 1.0/1.1 of your SMTP connections. That can either be a firewall or the PHP script itself...

If I am not mistaken, this only depends on the PHP version (i.e. the OpenSSL version PHP was compiled against) and not Windows or Apache2. And for the standard PHP binary releases you can download from the official page (PHP For Windows: Home), everything from PHP 5.6 on should support TLS 1.2

Most likely the problem is that your Plesk/Postfix server is configured to run with TLS 1.2 (and newer), but your Windows/Apache/PHP server does support TLS 1.0/1.1 only So you will either need to change your Plesk/Postfix server to support these older TLS versions as well, or you need up...

Plesk is installed on the root ("/") partition As for expanding a disk/partion on Linux, there is no single answer... Most likely ionos.mx does have a control panel for your server and there you can increase this disk of your server. (your server will most likely only have a single disk) These...

Forget about workers and pools, as this is not your problem, unless you have set php-fpm to spawn only one worker (pm.max_children), but you don't have as I can see from the screenshot in #3 Moreover you would then not have the same issue when using FastCGI PHP in a webserver environment is in...

bump, I would like to know as well (as I just have a use case for that right now)

I assume the following works: 1) Open table "ServiceNodeConfiguration" of the "psa" MySQL database, search for the row with "frontendPort" as the name and change the value from "80" to "81" 2) Regenerate all webserver config files via the Plesk Repair Utility ("plesk repair web") 3) Restart...

Maybe there is a way to circumvent the (exec/shell_exec) function restriction of PHP and then using /usr/bin/crontab to create these files? There are/were several ways to bypass PHP's disable_function() as well, though I have no idea how many of them are still working with recent PHP versions.

uhhh, I don't wanna know, how many scripts and cms software no longer run properly, when ini_set is disabled :D Though maybe in combination with display_errors=off, it may not be that bad

If you don't need to allow your customers to use cronjobs at all, you can remove all permissions (chmod 000) on the /var/spool/cron/crontabs directory We use that ourselves on some specific servers, but it will force you to manually create/edit/manage/delete all required cronjobs in...

https://bugs.php.net/bug.php?id=76359 It's a feature, not a bug.

Well, I assume that the crons got created with a simple PHP script that writes a file to /var/spool/cron/crontabs/XXXX If you think that open_basedir should prevent that, then you are wrong, as that directive can be circumvented easily by some "malicious" code lines in a php script. So, once an...

I meant the one from Ondrej Sury, aka ppa: ondrej/php

Joomla 1.5 will not run with PHP 7.x, regardless of the configuration options you set. You would need to fiddle with the Joomla code, in order to get that working. PHP 5.6 on the other hand works just fine for Joomla 1.5 - and no, it will not really make this site more insecure than using a...

You would need to manually adjust the file /etc/sw-cp-server/conf.d/plesk.conf on your server (and redo that every time that file gets overwritten by Plesk) But as it will not help you avoid the warning message, this whole undertaking is moot The only way to get rid of this message when...

If it's all about not getting a warn/error message in the browser when accessing https://123.123.123.123:8443/, then there is no way to prevent that. (even if you manage to configure an automatic redirect to https://domain.com:8443/)

here the command I would use to add such a "FPM" handler for PHP 7.3 on a Debian plesk bin php_handler --add -displayname 7.3.x -path /usr/sbin/php-fpm7.3 -phpini /etc/php/7.3/fpm/php.ini -type fpm -id os-php73-fpm -clipath /usr/bin/php7.3 -service php7.3-fpm -poold /etc/php/7.3/fpm/pool.d/ We...

You can add the PHP repo of DEB.SURY.ORG (see https://packages.sury.org/php/README.txt for instructions) to add PHP 5.6, ... 8.1 to your server. After installing you simply add them as custom PHP versions to plesk. (there is a CLI command for that) We use this on many of our Debian 9, Debian 10...

Hmm, I think that HTTP 1.0 does not use SNI and thus such a client is unable to connect to most https:// sites nowadays. (as we don't use dedicated IP addresse per site anymore) So this client would land on the default site of your server and not this particular website, so the 404 is explainable