Recent content by mediapepper

Yes, I know and I've triple-checked. The SSL/TLS certificate is issued by Let's Encrypt for the panel domain — no warnings, no errors, clean chain. That said, I found a workaround: Plesk is basically accessible via all domains and IPs on the server that are not configured as a web host (if the...

Fair point — I cannot provide direct proof from Anthropic's documentation that the issuer mismatch is the specific cause of the failure in claude.ai's web connector. The RFC 8414 requirement is clear (Section 3), but whether claude.ai strictly enforces it client-side is a different question...

Hi there, I'm trying to connect Claude.ai as an MCP client to my Plesk server. Claude accepts the URI (https://your-plesk-host:8443/modules/mcp/http) and the endpoint is reachable via browser, but clicking "Connect" fails with: After some debugging I tracked down the root cause: the...

Issuer always "https://plesk.localhost" regardless of panel_url Extension version: 0.3.0Plesk version: 18.0.76+OS: Ubuntu 24.04 LTS Description: The /.well-known/oauth-authorization-server endpoint always returns https://plesk.localhost as the issuer, even after correctly setting panel_url in...

For the time being I switched to S3. Although I want to use OneDrive aa I have a payed plan there already. MS needs to find a solution fast.

Hey PLESK team, will you please fix this? It's getting very annoying. BTW, when I delete all existing Backups and start over it works - until one full cycle has been reached (i.e. weekly full + incremental = full cycle after 7 days).

Not working for me either. MU13, I also set the backup to split files every 2GB, still not finishing.

Nope, no such cron task on my system. Cannot be the reason.

On Plesk Onyx Version 17.0.17 Update #12 this happens (again). I have applied the manual pmm-ras fix as it helped in the past and will report back. This thread should NOT be tagged as "resolved".

Hi, Im on MU9. Product version: Plesk Onyx 17.0.17 Update #9 Update date: 2016/12/06 22:30 Build date: 2016/11/17 16:00 OS version: Ubuntu 14.04 Revision: ab6766191d3ba26e7b21255ab007fc7fc56d84c6 Architecture: 64-bit Wrapper version: 1.2

I copied the pmm-ras file over manually, that did the trick for a few days. Suddenly the errors are back and I realized: My copy was overwritten. I repeated the manual fix. Let's see how that works...

I removed the config, removed aum, reinstalled it, copied the config file from /var/asl/rbc/etc/asl/config , now the crons are not generating error reports with REPUTATION_REPORT="no" APACHE_RESTART_COMMAND="/etc/init.d/apache2 restart" on Debian.

Nope. Did no such thing. Using the content of the config(backup?) that was located at /var/asl/rbc/etc/asl/config with APACHE_RESTART_COMMAND and REPUTATION_REPORT adjusted to apache2 Debian / "no".

The KB (which now just says update aum) doesn't fix the cron error message run-parts: /etc/cron.hourly/asl exited with return code 126 with aum 4.0.19-40 on Debian.

What does ASL do anyway? Is it safe to just disable the cron jobs for now? Im tired of this until it became permanently fixed.