Well that was a waste of sodding time.

Needing to set up to run a copy of my website here at home for testing, I
thought I'd run it on the fileserver (which is running Monterey), and test
from my own machine (running Catalina).

First thing I discover in httpd.conf is that PHP is now no longer supplied
with macOS. So I go through a big rigmarole of installing homebrew so I can
then install PHP. I found a site which lists all the steps, including those of
creating a root certificate and a signing certificate, because for some reason
apache won't load the just-installed PHP module without it being code-signed.
So while all that was tedious, it just took time. Perhaps Apple is locking
more and more stuff down with all the code-signing and so on so they figure
they can cut down the workload by no longer supplying so much stuff
pre-installed. In which case I dunno why they bother to supply apache at all.

Then I try copying a number of files that create the home page for my website.
These include, f'rinstance, three css files and some images. But when I try to
view the site from my machine, the home page is all messed up. Apache simply
doesn't find an image and two of the css files. After checking a number of
things - permissions, perhaps the css files had a UTF-8 BOM shoved into them
somehow, I look at the appache log. And it seems that some of the child
processes that apache spins off to presumably download files in parallel, are
segfaulting. WTF? Not, I suppose, all of them, because most of the css files,
images, etc, were loading in OK.

Well I gave up at that point. I'll just reverse the roles of the two machines.
But after Catalina, that will become progressively harder, which is a shame as
I always thought that being able to run a website at home without it being a
big production or my needing Linux on Yet Another Box, was a good thing.

Hey ho.

--
Tim

TimS <tim@streater.me.uk> wrote:
> Well I gave up at that point. I'll just reverse the roles of the two machines.
> But after Catalina, that will become progressively harder, which is a shame as
> I always thought that being able to run a website at home without it being a
> big production or my needing Linux on Yet Another Box, was a good thing.

I would just install Docker at this point. You can run big chunks of
software as a one liner, and updates happen automatically. They run in a
slim Linux VM which Docker manages behind the scenes for you - all these are
at the Mac shell prompt:

$ docker run -v /Users/tim/www:/var/www -p 80:80 -p 443:443 php:apache

will run Apache with PHP - in that particular image today it's PHP 8.3.1,
although there are many others available:
https://hub.docker.com/_/php/tags

Put your website files in /Users/tim/www or adjust the command as
appropriate. The website will be exposed on ports 80 and 443 on your
machine.

To set the config for Apache, create a folder /Users/tim/apache2 with the
config files and map it to /etc/apache2 in the container with an extra flag:

-v /Users/tim/apache2:/etc/apache2

If you need to run a shell in the container:

$ docker run -it php:apache /bin/sh

but note each time you start the container it's a fresh copy (ie no state
persists between runs, outside of paths mapped as above).

If you want to see inside a running container, do:

$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7c6c667e5873 php:apache "docker-php-entrypoi…" 3 seconds ago Up 2 seconds 80/tcp vibrant_dijkstra

$ docker exec -it 7c6c667e5873 /bin/sh
#

and that gives you a shell prompt inside the container (in this case a
minimalist Debian bookworm image). I would do:
# cp -a /etc/apache2 /var/www/apache2
# exit

and that gives you a copy of the default set of Apache config in
/Users/tim/www/apache2

If you want to make persistent changes on top of the base image (eg install
packages), look up 'Dockerfiles' and 'docker build'. The docs also explain
how to make containers persistent so they start on boot.

Theo

On 03 Jan 2024 at 11:29:55 GMT, "Theo" <theom+news@chiark.greenend.org.uk>
wrote:

> TimS <tim@streater.me.uk> wrote:
>> Well I gave up at that point. I'll just reverse the roles of the two machines.
>> But after Catalina, that will become progressively harder, which is a shame as
>> I always thought that being able to run a website at home without it being a
>> big production or my needing Linux on Yet Another Box, was a good thing.
>
> I would just ... [dragged to the Desktop to save for reference and then
> snipped]

Thanks for that - I'll investigate Docker.

Still cheesed off with Apple for deprecating PHP - why couldn't *they*
code-sign it? Of course when I put up the website under Catalina and accessed
it from the fileserver, it worked as expected first time - and no segmentation
faults either.

--
Tim

TimS <tim@streater.me.uk> wrote:
> On 03 Jan 2024 at 11:29:55 GMT, "Theo" <theom+news@chiark.greenend.org.uk>
> wrote:
>
> > TimS <tim@streater.me.uk> wrote:
> >> Well I gave up at that point. I'll just reverse the roles of the two machines.
> >> But after Catalina, that will become progressively harder, which is a shame as
> >> I always thought that being able to run a website at home without it being a
> >> big production or my needing Linux on Yet Another Box, was a good thing.
> >
> > I would just ... [dragged to the Desktop to save for reference and then
> > snipped]
>
> Thanks for that - I'll investigate Docker.

Also worth looking at Docker Compose, which is a way to run several related
containers (eg PHP and Mysql) and describes how they talk to each other.
Instead of flags at the docker command line you write a YAML file that
describes the service(s) and their config.

If you want to do it via a GUI I can recommend Portainer, a web UI for
Docker and Docker-compose. It probably makes more sense to know some of the
basic Docker concepts first though.

> Still cheesed off with Apple for deprecating PHP - why couldn't *they*
> code-sign it? Of course when I put up the website under Catalina and accessed
> it from the fileserver, it worked as expected first time - and no segmentation
> faults either.

PHP is a PITA IMHO. Do you mean PHP5, PHP7 or PHP8? They're incompatible.
I have some websites in PHP5 that are going to be a ballache to port to a
newer PHP, since PHP5 isn't supported in any modern Linux distro (and even
the Docker images are ancient). Maybe the Apple's PHP was a retired
version?

It seems like Apple aren't really interested in having a good CLI
environment and leave it up to Homebrew and friends, which are a bit half
baked.

That's why I mostly run Linux these days :)

Theo

On 03 Jan 2024 at 15:48:32 GMT, "Theo" <theom+news@chiark.greenend.org.uk>
wrote:

> PHP is a PITA IMHO. Do you mean PHP5, PHP7 or PHP8? They're incompatible.
> I have some websites in PHP5 that are going to be a ballache to port to a
> newer PHP, since PHP5 isn't supported in any modern Linux distro (and even
> the Docker images are ancient). Maybe the Apple's PHP was a retired
> version?

Under Catalina it's 7.3 - as supplied by Apple. When homebrewing under
Monterey, I installed 7.4 to run with apache 2.4.

--
Tim

TimS <tim@streater.me.uk> wrote:
> On 03 Jan 2024 at 15:48:32 GMT, "Theo" <theom+news@chiark.greenend.org.uk>
> wrote:
>
> > PHP is a PITA IMHO. Do you mean PHP5, PHP7 or PHP8? They're incompatible.
> > I have some websites in PHP5 that are going to be a ballache to port to a
> > newer PHP, since PHP5 isn't supported in any modern Linux distro (and even
> > the Docker images are ancient). Maybe the Apple's PHP was a retired
> > version?
>
> Under Catalina it's 7.3 - as supplied by Apple. When homebrewing under
> Monterey, I installed 7.4 to run with apache 2.4.

PHP 7 is EOL as of 28 November 2022, so not surprising it's been removed.
Only PHP 8 is maintained now. Since 8 has breaking changes from 7, I
suppose Apple decided it wasn't worth including what's effectively a new
language when removing the old one.

Theo