DirectAdmin 1.693

[anas_xrt]

@exlhost
I’m running on Almalinux 8.10 with DirectAdmin 1.693, and I’ve already updated MariaDB and run da build all.
I’ve noticed an issue: whenever a customer (or anyone) changes the PHP version inside DirectAdmin, all the sockets under /var/run/php-fpm — along with the directory itself — suddenly disappear. This results in websites showing Service Unavailable because there’s no socket available.
I’m not sure if this is happening only on my setup or if others are experiencing the same behavior. Have you encountered this problem?

 

[exlhost]

@anas_xrt

The php version change takes ~1 minute because web server configuration is reloaded with taskq (it gets executed once per minute).

 

[anas_xrt]

@anas_xrt

The php version change takes ~1 minute because web server configuration is reloaded with taskq (it gets executed once per minute).

So /var/run/php-fpm/*.socket is still available?

 

[deltaB]

Hey Fin, thanks for the release!

I think there might have been quite a major change to letsencrypt.sh with the addition of the internal_request() function in v1.693 ? But I couldn't see it in the release notes....

As far as i can see DA is now calling that function internally from the SSL commands, so anyone using a custom letsencrypt.sh that doesn't handle internal_request is now broken.

 

[deltaB]

Hey Fin, thanks for the release!

I think there might have been quite a major change to letsencrypt.sh with the addition of the internal_request() function in v1.693 ? But I couldn't see it in the release notes....

As far as i can see DA is now calling that function internally from the SSL commands, so anyone using a custom letsencrypt.sh that doesn't handle internal_request is now broken.

Also the log files might have moved to acme_provider_cert_logs and are no longer in errortaskq.log? Unless it's just our lab setup that's gone wrong, which is entirely possible...

 

[brinkie]

The update seems to have a weird influcence, perhaps intended, when users click on phpMyAdmin to login on their database. Normally the user that logs in is the database user/owner. Now it's the accountname_long series of random characters@localhost. This causes issues with the ownership when they run certain queries, like: "Error 1227: Access denied; you need (at least one of) the privilege(s) for this operation".

The users are not aware of the 'weird' login. The workaround is: logout of phpMyAdming and login again with the correct credentials.

Is this on purpose and if yes, why?
Is there a way to fix this?