Search results

go over to DEB.SURY.ORG and use their repository for PHP 7.4, once Plesk stops providing updates. Sure, there is no guarantee on how long they will support PHP 7.4, but as they still provide security updates for releases back to PHP 5.6 as of today, the chances are high that you'll see a...

I assume that the SSL/TLS configuration of your Postfix service is not working properly in general. Maybe a wrong certificate, missing chain, cipher suite, or one of the many other possible things that can be wrong when it comes to SSL/TLS Maybe a tool/website like Mailserver encryption test...

change/adjust your config.inc.php to: $config['smtp_host'] = 'localhost:25'; $config['smtp_auth_type'] = 'PLAIN'; You most likely have some problem with the SSL certificate/configuration on your SMTP service, thus Roundcube refuses to connect via SSL (port 465) or StartTLS (port 587)

login via SSH, then: rm /etc/nginx/conf.d/cf-stop /root/cf.sh

looks a bit like you forgot the chain/intermediate certificate or added a wrong one? A website like Mailserver encryption test (STARTTLS, TLS and PFS) · SSL-Tools can help identify this.

No, "old" is not recommended to use for anything else than SMTP And as this setting can not be configured per service in the "SSL it" extension, you should use "intermediate" and change the Postfix configuration manually. (the parameters tls_medium_cipherlist, smtpd_tls_protocols and...

We use TLS 1.0/1.1 for Postfix on all our servers and so far it did never got reset (except if we manually click "Sync now" with the Intermediate profile in the SSL it! extension) So it may be quite save, but I can not guarantee that....here we would need a word from the Plesk devs. I would...

old/lost data is lost, no way to get these statistics data back. so you need to wait till next month to see an additional month and so on. Why you see 12 months but only four are populated with data, I don't know. But I only ever work with AWstats, so it's possible that Webalizer does always...

well, with the "old" setting your php script could connect at least, but then failed because either the configured username or password was wrong.

well, for a quick change/check, you can go to "Tools&Settings" --> "TLS versions and ciphers management" and apply the "Old" preset. This will enable TLS 1.0/1.1 (including the required old ciphers) for Postfix - but of course also for nginx, apache, dovecot, proftpd (where you don't wanna...

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