Search results

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

I don't know why Plesk is still using different logfiles for http and https for websites - as well as different webstats (AWStats/Webalizer) for that matter... As for fail2ban and the "to many logfiles", go with Monty and enable piped logs for Apache2

If LetsEncrypt does not work with DNSSEC enabled domains, you most likely (99%+ chance) have an invalid DNS configuration. (that may or may not affect "normal" DNS services) - what status does a "dig caa yourdomain.tld" query return? If it's SERVFAIL instead of NOERROR, then you have a DNS...

If you are running Linux, I suggest using SSHFS to mount the SFTP exposed stoarge as a local disk and then use this for storing the backups. Then you have the best of both worlds

Not very useful and will most likely never be supported by Plesk, as this is not a solution that would work in a broad environment. what about users that use Apache2 only, without having Nginx installed? or users with Litespeed? or users that wanna block FTP or Email access?

You can use this as a blueprint: # list existing block devices fdisk -l --> /dev/vdb # partition the new block device fdisk /dev/vdb n p <enter> <enter> w # format the new partition mkfs.ext4 /dev/vdb1 # disable automatic fs-check every X days/mounts tune2fs -c0...

It may help if you manually remove the expired "DST Root CA X3" root certificate from the files /etc/ssl/certs/ca-bundle.crt and /etc/ssl/certs/ca-bundle.trust.crt You can open these files in your editor and search for it. (either it's name or this string...

@Monty I really don't get these LetsEncrypt guys... They insist on keeping the old chain alive and you can read statements like these from many involved people: But, but, but.....I mean, the old chain and root expired two days ago, so these certificates are no longer valid on the old Android...

remove the following lines/certificate (should be on the bottom) from within the file /etc/postfix/postfix.pem and restart your postfix -----BEGIN CERTIFICATE----- MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT...

Addendum, yes on brand new servers you don't need a manual workaround, because OpenSSL has some built-it filter that explicitly masks the offending LetsEncrypt chain certificate if it encounters it. I did not read into the details on the OpenSSL Dev List, but there may even be some...

Guys, just be aware that even newly issued LetsEncrypt certificates are still dual/cross-signed with the old and now expired R3 certificate and a properly configured server will send this expired intermediate to the client. (alongside the domain certificate and the proper/new intermediate )...