• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Specifics of MU #48 and missing mystery release?

HostaHost

Regular Pleskian
Can someone from Parallels clarify what was included in Micro Update #48?

http://download1.parallels.com/Ples...el-10-linux-updates-release-notes.html#104448

Parallels Plesk Panel 10.4.4 MU #48 [21-Mar-2013]
[-] Upgrade php component breaks permissions on php sessions directory.


I'm curious about this because I was about to post a thread that we noticed that you released something a few days ago that broke PHP sessions on all servers running PHP in FastCGI mode; basically the ownership was changed on /var/lib/php/session making psacln group no longer able to write to it. I'm even more curious about how this could have occurred given your release notes, RSS feed, Twitter and every other random place you advise us to get updates make no mention of anything being released yet there certainly was something released because all our 10.x servers reported panel successfully updated.
 
The way I read it is that the issue appears to be that when PHP itself is updated, the ownership/permissions are reset in a way that breaks things. *if* I'm right (big IF), then this update will set things up so that the system will notice this change and fix the permissions as required.

An easy way to see if I might be right: Did you upgrade PHP recently? If so that might be the cause.

But this is pure guess-work on my part.

Having said all that, I have never had any site running in fastcgi mode that was able to write to the global session directory. I always have to create a specific one in the private directory for the site in question. I know that's not what's supposed to happen, but that's the way it is on our systems.
 
No, that's not what occurred. A week or so ago, all of our 10.4.4 servers sent out a notice that "Plesk was successfully updated" during their nightly check-in, the following morning we began getting support tickets about php sessions failing. The ownership on /var/lib/php/session/ changed from apache : psacln to root:apache while permissions remained 770. This effectively broke every FastCGI site that used php sessions since those scripts execute as user : psacln. mod_php sites remained able to write sessions since they could write as group now where before they could write as owner.
 
Last edited:
Hmm...well, as you point out, there has not been an update for some time (last was MU#47 which was months ago).

What's the date on /root/.autoinstaller/microupdates.xml ? (before MU48)
Also what MU number does it show in that file?
 
That's all over the place, I just surveyed, but we do have a big block of servers that show it having changed in the March 11th to 14th span. That sounds about when the problems began. Bunch more on 21st to 23rd, which makes me think those are the ones that have taken on #48. Catting the files confirms not all have taken on 48 for some reason; guess I get to go check into why that is next.
 
Back
Top