Building a current FLNP stack or should that be LNPF

While I do have this working on a windows computer I have a few features of the web services stack that windows does not support so I've not used it as a host in production for many years. The legacy documentation on the windows based stack are still archived here, but are now somewhat irrelevant. The current windows machine here will not even support W11 but still works with the same current stack running a single website.

The next change over the years has been the move from Apache to Nginx and the part of the reason for the change was 'improvements' to Apache which I found problematic, but similarly Nginx has had it's own changes that caused similar aggro. The nginx configuration allows for a directory of files defining the setup of each website. One nice facility with this is that the version of PHP being used can be set independently for each site, so until code has been updated to a current build of PHP, the existing PHP7.3 production version can be maintained, with a simple change to the newer version. In addition, Nginx manages the certificates for HTTPS and this dovetails into the LetsEncrypt update process.

One problem with all of this is that most versions of Linux try to be helpful and update versions of the various components as new 'security updates' come out. While on one hand this can be safe to use, in other cases such as with PHP, one needs better control of which version is being employed. At one point openSUSE did support a 'PHP7' and 'PHP8' install, which was at least a half way house, but today manual installation of PHP is easier to manage and other articles here cover the problems of bringing legacy PHP code up to comply with the new rules in PHP8.4. My development server has a stack using Nginx 1.27.5 with PHP8.4.5 and Firebird 5.0.2 while the production machine is still working fine on an older setup with Nginx 1.21.5, PHP7.3.33 and Firebird 3.0.

That I prefer Firebird over other database options goes back to a time when I was using BuilderC++ to create proprietary windows software for the early systems. The original material was managed using dBase but when multiple users needed to be supported, Borland's Interbase was the obvious next step. The history of how Firebird evolved from the mistakes that Borland made at the end of the 1990's is well documented and I still have material created on Interbase and ported over to early builds of Firebird. That I served on the Foundation team for a number of teams and spoke at many conferences just re-enforces my preference. One key element is that Firebird provides an automatic backup process which currently runs daily so that in the worse case only one days material will be lost if something goes wrong.

So now we just need a Linux distribution to run all of this on and as indicated, I prefer openSUSE and that use goes back to the days of at least SUSE6. The production machine is running Leap 15.6 and hence some of the older builds of the stack, while I've given in and am running Tumbleweed on the development machine. This has caused a few problems at times since things do keep braking, but no more then those breaks happening in Leap when trying to run newer builds of the same packages. The tricky problem will be when I want to move the production machine up to the new stack. Currently I do have Firebird 5 and PHP8.4.5 loaded on the machine, so not sure I actually need to upgrade the Linux version anyway and just add a newer build of Nginx to complete the picture. The production server does not have a graphical desktop, and is purely text based.

A lot of talk and very little instruction on how to actually configure the setup. That will be part of the next pages ...