Ubuntu Package Updates and PHP.ini / PHP FPM Config Files

Howdy!

The servers are essentially yours, and Forge only managed specific things. Software upgrades are not one of them :D

This is one area where knowing a bit more about the configuration can help!

My book covers PHP-FPM's www.conf pretty extensively.

In my case, I would let the script install the updated version. Then I would go back and re-change the www.conf file as Forge makes it - likely by checking out a forge server that is not updated and comparing it (spinning a new one up just to see).

Possible (likely?) changes in the www.conf file made by Forge to check out:

• Changing the user/group that PHP is run as to "forge" rather than "www-data"
• Changing the listen directive to a TCP socket (e.g. 127.0.0.1:9000) over a Unix socker (e.g. /var/run/php-fpm.sock)
• If using a Unix socket (file path), it will also have a user/group setting, which is likely also set to "forge" rather than "www-data"

Updates in general:

Updates are not really a "solved problem" in any hosting environment. A classic approach is to have a test/stage server around where you can run updates and see what breaks. A more modern approach is a "read only" server, in which you avoid writing files that need to be saved (including using a sep. server for a database) and then just re-provision a new server for any change - software or application updates. Then delete the old server, assuming the new one is up and running.

The latter typically requires a decent amount of automation. Using Linode and their Node Balancer with Forge might allow you a good middle-of-the-road approach for that, where you spin up a new server, add application deployment, and then add it to the nod balancer before removing the old server. (Forge doesn't manage the linode node balancer, you'd have to do that a bit yourself in Linode's control panel).

While the username to run the servers are different to what Forge sets up, a good reference is the provision script @taylorotwell provides for Homestead found in the Settler repo.

https://github.com/laravel/settler/blob/master/scripts/provision.sh

Ah, right - good call! Specifically this stuff for www.conf: https://github.com/laravel/settler/blob/master/scripts/provision.sh#L149-L157

You can normally see the changes compared to your local version (On Debian it's D to compare). All that's ever changed is some comments and I've seen a new option about twice in 3 years. Probably don't need to if there's no changes/new options.

Great tips guys. Not too many resources for Forge in regards to dev ops and we are in production, so check, check, double check before doing anything new. Thank you all and @fideloper - book bought. Done.

Forge is just a control panel (like any other one that's attached to a server). Read up on Linux and configuration for PHP and Nginx etc for it :)

@bashy, yup, knew that. The issue is that what Forge modifies when spinning up a new server is not documented, unlike other control panels.

I have a rough idea and it's really not that different to what I'd do for my server's L(A/N)MP setup (mostly Nginx these days).

If anyone is interested. I put up a repo with the default Forge LEMP directory structure, files, and permissions. Helpful to cross-reference if you are editing or updating.

https://github.com/jhauraw/forge-lemp-defaults

I get so confused with the E in LEMP. However it's pronounced, it should be N :(

It has "include /etc/nginx/conf.d/*.conf;" but there's no conf.d directory. Hummmmmmm

@bashy: That dir is empty by default. I added a .gitkeep to the repo so it would get pulled up by git.

Cool beans. I always delete that folder and include :) useless ms wasted!