Solved how to install php74?

PHP7.4 has been EOL for almost half a year now and hence has been removed from ports.
So in short: you don't install PHP 7.4 anymore; use any of the 8.X releases.
 
bsd.default-versions.mk contains :
PHP_DEFAULT?= 8.1
I suggest don't put anything php related in make.conf and you will have the default php8.1
 
I mean, you *could* revert the commit that removed php74 on your local ports-tree and try to build all required packages. I've done this once to salvage an old horde installation shortly after php74 was removed; but due to dependencies moving on and above what php74 supports, there's no guarantee that builds of php74 or modules will succeed. Or better say: after half a year of everthing moving on, most of them *will* fail to build and need manual intervention *if* they could be build at all.
 
bagas: Thank you.

This is also pertinent to our use-case. Quite a few apps still rely on php74, one egregious example being owncloud. Some business-critical Wordpress plugins also rely on it.

For sysadmins this is a case of bad security, but for some users it is a case of desperate business situation, where they would rather jump to Linux.

The choice they made was, rather than using Ubuntu or Debian, install php74 in a FreeBSD 13.1 jail on a 13.2 host and closely monitor the php74 third-party audits, until they move to php8x.

mkjail create -v 13.1-RELEASE -j site -f default
 
priyadarshan said:
Quite a few apps still rely on php74, one egregious example being owncloud.
Click to expand...

Maybe switch to Nextcloud? That's where all the original owncloud devs are and where you will get everything (and more) that owncloud charges money for...


But yes, there's still some (mainly dead) software out there that still has no support for PHP8+. But for most of them I highly doubt there ever will be, so it would be wise to just pull the plug at one point and migrate to an actively developed alternative.
E.g. Horde is said to "soon" merge the work of php8 compatible forks upstream, but so far nothing happened and I consider Horde being dead and gone. Still haven't found the time to evaluate an alternative though...
There are some 'pear-horde-*' packages that are being build with php8+, but last time I tried this was still the old codebase that blows up left and right when running with php8+ and there are essential parts missing, so those packages won't give you a working Horde groupware installation.
 
sko:

Maybe switch to Nextcloud? That's where all the original owncloud devs are and where you will get everything (and more) that owncloud charges money for...
Click to expand...

We recently tested the latest version of nexcloud and owncloud (on a Linux box, using Docker).

To our use-case, owncloud outperformed nexcloud by a significant margin.

Using a 13.1-RELEASE jail seems to temporarily solve the issue for us, while keeping the host server safe.
 
I got the same issue today (14.0-RELEASE), the solution was to install the older openssl version (111< 3x):

pkg install openssl111

Download the latest final php74 src (php 7.4.33) from php.net and compile/install it.
This was the bare minimum for me, to install a working mod_php74 for an old CMS on apache24:

fetch https://www.php.net/distributions/php-7.4.33.tar.gz
tar -xvf php-7.4.33.tar.gz
cd php-7.4.33
./configure --prefix=/tmp/makeinstall --with-apxs2=/usr/local/sbin/apxs --with-libdir=lib64 --with-openssl --with-curl --with-mysqli --
with-pdo-mysql --enable-gd --with-curl --enable-mbstring
gmake
gmake install clean

Needed to comment out "mod_php" (which one is for php8) in httpd.conf, and leave only mod_php74 to load...
#LoadModule php_module libexec/apache24/libphp.so
LoadModule php7_module libexec/apache24/libphp7.so
Click to expand...
 
on FreeBSD13

get ports from 2022Q4: https://cgit.freebsd.org/ports/snapshot/ports-2022Q4.tar.gz

extract and install php74, mod_php74
cd /usr/ports/lang/php74 &
make BATCH=yes install clean

cd /usr/ports/www/mod_php74
make BATCH=yes install clean
Click to expand...

similarly with perl and php-extension

# cd /usr/ports/lang/perl5.6
# make;make install;make clean

cd /usr/ports/lang/php73-extensions && make config
select php-extensions

cd /usr/ports/lang/php73-extensions && make BATCH=yes install clean
Click to expand...
 
The ports tree has in recent years become a lot more aggressive in removing older version (and abandoned) software that still 'works'. That's fine, the tech world of today is moving faster and faster and the longevity of software has been decreasing dramatically. Whether that's good or bad in the long run, we have yet to see the consequences of that.

Anyway, I think there would be a benefit to preserve quarterly snapshots of the pre-built package repositories for at least a few years or decades for the final major version of each FreeBSD release going forward (ie. 13, 14, etc...). Given that FreeBSD jails are often used to run older versions of software (and the OS) due to specific needs that prevent an immediate upgrade/modernization path.

PHP is an excellent example.

While Git/SVN will retain the port Makefiles, it's not always going to be possible to manually re-build the needed packages. Either the destination hardware is too under-powered, or the source dist files are gone.

I understand costs are involved, but I don't believe they would be too significant if they are moved to lower powered infrastructure with less demanding uptime requirements.

Just my 2 cents...

To build PHP 7.4 with Poudriere for 13.2:
Assuming you already have it setup: https://github.com/freebsd/poudriere/wiki/pkg_repos

Code: 
poudriere jail -c -j 13amd64 -v 13.2-RELEASE -a amd64
poudriere ports -c -p 2022Q4 -m git+http -U https://git.freebsd.org/ports.git -B 2022Q4
poudriere bulk -p 2022Q4 -j 13amd64 -z php74 lang/php74 www/mod_php74 lang/php74-extensions
 
tuaris said:
The ports tree has in recent years has become a lot more aggressive in removing older version (and abandoned) software that still 'works'.
Click to expand...
I get your point, but stuff like PHP 7.x is completely unsupported, has real security issues, etc. Plenty in the media recently about overseas groups that specifically hunt out unpatched/out-of-date software.

I've been frustrated a few times by things disappearing from ports but it has encouraged me to keep an eye on EOLs and keep moving - probably a bit faster than I want to, but it's a real nudge knowing that if I don't do it, something will be gone and then it will x10 more difficult to migrate.

Then there are dependancies ...

I think if it was too easy to use out-of-date software, we would get slack.

Sometimes that would be OK, and convenient, but best practice? Dunno.
 
tuaris said:
To build PHP 7.4 with Poudriere for 13.2:
Click to expand...

Thank you for this.

In regards to security: Sometimes I hear colleagues complaining about the patronising feeling they get from FreeBSD.

Personally, I appreciate being reminded about security, but I would also like the freedom to risk shooting myself in the foot.

FreeBSD to me always meant that kind of freedom as well, as long as it comes from a responsible, informed choice.
 
priyadarshan said:
FreeBSD to me always meant that kind of freedom
Click to expand...
But what about the resources that the project has to devote to giving you the chance to shoot yourself in the foot?

Every hour a FreeBSD developer spends on out-dated unsupported EOL ports is an hour not spent on newer more secure supported ports.
 
richardtoohey2 said:
But what about the resources that the project has to devote to giving you the chance to shoot yourself in the foot?

Every hour a FreeBSD developer spends on out-dated unsupported EOL ports is an hour not spent on newer more secure supported ports.
Click to expand...

Thanks for bringing up that point.

Forgive my nitpicking, Chance to make a mistake is not freedom to do so. The latter is more of an ethical imperative. But then, if one care so much, he should become a developer himself, isn't he?

In regards of resources: As far as I understand, keeping past ports available somewhere would be a matter of disk space resource, not developer time.

Also true, one could build the whole port tree, at any point int time, based on the subversion/git repositories, and the offer this to the community.
 
priyadarshan said:
In regards of resources: As far as I understand, keeping past ports available somewhere would be a matter of disk space resource, not developer time.
Click to expand...

And what about maintaining tons of outdated dependencies? Especially for PHP, which even on supported versions has a multitude of modules with questionably old dependencies, this will be an absolute shitshow, requiring *a lot* of time to put out dumpster fires left and right...

Everyone has the "freedom" to check out a heavily outdated branch of the ports tree and build that old cruft for himself. There's no need to force that "freedom" upon maintainers...
 
You must log in or register to reply here.
Back
Top