We standardized our PHP dev environment on AlmaLinux 10 — same playbook for WSL 2 and bare metal

[u/arhimedosin]

Our team's local dev environment now runs on AlmaLinux 10. On Windows machines it runs inside WSL 2, and on Linux machines it runs directly on bare metal. (Disclosure: I work on the project, Dotkernel.)

The reason is parity: `dnf`, `systemd` and the service layout people use locally are the same ones they see on our staging and production servers.

One Ansible playbook provisions:

- PHP via Remi (8.5 default, aliases for 8.1–8.5)

- Apache with automatic `*.localhost` virtualhosts

- MariaDB 12.3 LTS + phpMyAdmin

- Node.js via NodeSource (22 default, aliases for 18–24)

- Composer and Git config

The playbook doesn't care whether it's provisioning WSL or bare metal. It runs the same on both.

Overview: https://www.dotkernel.com/wsl2/

Repo: https://github.com/dotkernel/development

If anyone here runs AlmaLinux as a dev workstation, we'd like feedback on the package choices, especially Remi vs AppStream modules for PHP.

[u/Maria_Thesus_40]

We have a similar setup that is Linux only (so no Windows or WSL).

Ansible playbooks for:

• AlmaLinux 8 and 10 (yes we still have some old AlmaLinux 8 servers)

• PHP 8.3.33 (as it comes with AlmaLinux 10)

• Apache setup with the Aetolos control panel

• MariaDB 10.11 (as it comes with AlmaLinux 10, also configured with Aetolos)

• Subversion for local things and Gitlab for online things

We don't use anything javascript, so there is no need for that.

As company policy and to lower possible contamination (supply chain attack) we don't use composer or Remi. Updates are semi-automatic for the same reasons.

Personally, I am not worried that something bad may come via RPM packages, they get a lot of attention. What worries me is composer, which I believe is the weakest link. I do know that many businesses blindly download and run code like that, but I'd never do it.

[u/arhimedosin → u/Maria_Thesus_40]

Oh, `composer` have a built in `audit` feature when you run it, and stops when something is fishy.

Also in require-dev you can have `roave/security-advisories` which is doing something similar.

Probably is the safest package manager compared to others.

But i understand your concern, it is a good practice to deploy a composer.lock file too.

[u/Maria_Thesus_40 → u/arhimedosin]

I think having no composer at all, solves the issue :)

But we have to do some extra manual work for updates, and we also need to do a lot more coding. At the end of the day, I prefer the technical debt of my own code, than to depend on Mr Nobody from X Obscure Country and his Questionable Code practices.

It all comes down to who your client is. I don't want to explain to my banking client that the AwesomePackage from Pakistan was "hacked" and that got our 600 servers compromised.

Composer is not some magic code repository, its somebody else's code. You can't hide from that.

[u/RetroGrid_io → u/Maria_Thesus_40]

Composer is not some magic code repository, its somebody else's code. You can't hide from that.

All of it is somebody else's code, so don't hide from that, either.

[u/flaticircle]

We use ddev for dev workstations and deploy onto AlmaLinux test, staging and production. The ddev config pins the versions. In the AlmaLinux environments we use appstream so are currently on PHP 8.4.