Haradion

Well, to test the permissions, you could see if you can write to the file with any other functions, e.g. file_put_contents.

Well, I hope that goes smoothly. I've seen a RAID array fail during a rebuild due to stress on the "good" (but aging) drive, but that's supposed to be fairly uncommon.

Does the drive controller provide SMART statistics? With multiple instances of corruption, I'd generally start to suspect a failing drive.

Yes; that's probably the easiest way to pick up the user's session in the WebSocket context. Based on my understanding (I haven't actually tested this), the browser should pass PHPSESSID in the request automatically, so you'd just need to call session_start() in the WebSocket request handler and read the appropriate values out of $_SESSION.

Are those variables changed on every request, or do they only change when the user submits login credentials? If normal requests after login only read those fields, the WebSocket connection can do the same thing, as it should receive the PHPSESSID cookie just like normal requests do.

For SVG, you could create a path for each segment of the circle. You'd have to find the start and end coordinates of each segment, and then you'd use elliptical arc path segments: <path d="M START_X,START_Y A RADIUS RADIUS 0 0 0 END_X,END_Y" stroke="blue" /> The example above assumes that the arc is drawn clockwise and is smaller than 180 degrees; the second and third zeroes may have to be changed to ones if either of those assumptions changes for a given arc. MDN has further details on the A path command.

When you say the session will be "replaced", do you mean that the session data would be overwritten on the backend? The request to initiate the WebSocket connection should include the same session cookies that other requests would include, so if you're using cookies for sessions, the logic shouldn't be too different from the normal procedure for opening an existing session. It should be possible to use the same session ID that your normal HTTP requests are using rather than having to start a separate session ID dedicated to just the WebSocket.

OK, if you've already got SSO sorted out, is your first question about how to handle authentication specifically when you're opening the WebSocket connection?

First of all, sorry about the slow response. I was expecting to get a notification e-mail, but it turns out that I needed to adjust my settings for that to happen. So, it sounds like you've got an external SSO provider of some kind. Is it based on OAuth/OpenID Connect or on some other SSO protocol? For OAuth, if you have access to self-encoded access tokens, those can be relatively straightforward to validate without having to track too much session-related state in your own database. Since you mentioned social media logins, I'm going to guess they probably do use self-encoded access tokens since that's common for services that operate at a very large scale. For the database layer, is there already a specific database you're looking at using?

Logins via social media are usually done using OAuth and OpenID Connect, which can be non-trivial to implement. For development purposes, as long as you're just testing on your own computer, I'd recommend building a mock login flow that just takes a username. It would be far too insecure to expose to the public Internet, but it would give you an opportunity to work out your database layer, which will be required for OAuth anyway.

It depends on how the system is configured, but it's pretty common to back up the contents of /etc, at least any configuration files in there that have been manually customized. It can get a little tricky to keep track of what stuff in /etc has been customized and what was the default configuration, though. Sometimes, stuff under /var/lib can be backed up directly, but that often holds database files that really should be backed up using the database's own tools, as it's hard to get a clean snapshot by just copying the files with the database running. Specifically with Hestia, it's probably best to use its own backup tools (as Kairion linked to in the other thread), but that'd involve getting Hestia to start in the first place. Speaking of which, the port numbers are different, but there's a section of the FAQ that looks like it describes a similar issue to what you were experiencing. You might at least compare the Nginx configuration in /etc with anything that shows up in /usr/local/hestia/install/deb/.

Sort of a side note: with that big of a version jump, you might consider running a static analyzer like Phan to see what it picks up in terms of deprecated/broken functionality, etc. It'll probably pick up a number of other issues, some of which will be false positives, but there are various techniques to try to weed some of those out. The most relevant option for this use case will be backward_compatibility_checks.