It looks like automake-wrapper-20131203 has been replaced with automake-1.16.1 in the FreeBSD 11.1 ports tree. Unfortunately, portmaster is stumbling over the change and failing with an error. If you're receiving the output below, scroll down for the fix:

[root@host /tmp]# portmaster -avw
===>>> Sorting ports by category
===>>> Gathering distinfo list for installed ports

===>>> Starting check of installed ports for available updates

===>>> Root ports: 18
===>>> automake-wrapper-20131203

        ===>>> The devel/automake-wrapper port moved to devel/automake
        ===>>> Reason: No longer needed

===>>> Launching child to update automake-wrapper-20131203 to automake-1.16.1

===>>> All >> automake-wrapper-20131203 (1/1)

        ===>>> The devel/automake-wrapper port moved to devel/automake
        ===>>> Reason: No longer needed

===>>> Currently installed version: automake-wrapper-20131203
===>>> Port directory: /usr/ports/devel/automake

[...snip checking all installed ports...]

===>>> All >> (1)

===>>> The following actions will be taken if you choose to proceed:
        Downgrade automake-wrapper-20131203 to automake-1.16.1

===>>> Proceed? y/n [y] y

===>>> Starting build for ports that need updating <<<===

===>>> Launching child to install devel/automake

===>>> All >> devel/automake (1/1)

===>>> Port directory: /usr/ports/devel/automake

===>>> Starting check for build dependencies
===>>> Gathering dependency list for devel/automake from ports
===>>> Starting dependency check
===>>> Checking dependency: devel/autoconf
===>>> Checking dependency: lang/perl5.24
===>>> Checking dependency: ports-mgmt/pkg
===>>> Checking dependency: print/texinfo
===>>> Dependency check complete for devel/automake

[...snip compiler output...]

===>>> All >> devel/automake (1/1)

===>  Installing for automake-1.16.1
===>  Checking if automake already installed
===>   Registering installation for automake-1.16.1 as automatic
Installing automake-1.16.1...
pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203 (installs files into the same place).
Problematic file: /usr/local/bin/aclocal
*** Error code 70

Stop.
make: stopped in /usr/ports/devel/automake

===>>> Installation of automake-1.16.1 (devel/automake) failed
===>>> Aborting update

===>>> Update for devel/automake failed
===>>> Aborting update

Resolutions

The snag appears to be that because /usr/ports/devel/automake-wrapper was deleted from the ports tree, portmaster can't cleanly deinstall automake-wrapper to replace it with plain old automake. There are multiple ways to address this.

Fix it using portmaster...

I initially posted the manual steps (below), but a reader contributed an easier fix using portmaster's -o flag:

[root@host /tmp]# portmaster -o devel/automake devel/automake-wrapper

This tells portmaster that the origin of the port has changed to a different directory, without having to force the issue.

...Or fix it manually

An alternate solution is to manually remove the automake-wrapper port and then manually install the automake port:

[root@host /tmp]# pkg info | grep automake
automake-wrapper-20131203      Wrapper script for GNU automake
[root@host /tmp]# pkg delete automake-wrapper-20131203
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        automake-wrapper-20131203

Number of packages to be removed: 1

Proceed with deinstalling packages? [y/N]: y
[1/1] Deinstalling automake-wrapper-20131203...
[1/1] Deleting files for automake-wrapper-20131203: 100%
[root@host /tmp]# cd /usr/ports/devel/automake
[root@host /usr/ports/devel/automake]# make install
===>  Installing for automake-1.16.1
===>  Checking if automake already installed
===>   Registering installation for automake-1.16.1
Installing automake-1.1...

In late May of 2018, the LibreNMS project released version 1.40. This update brought the Laravel framework to LibreNMS, and with it came some interesting new errors. Most of them are covered in the community announcement titled New Requirements for 1.4.0. I've encountered some errata that I wanted to cover here.

Command changes for FreeBSD

FreeBSD users will need to make a couple of modifications to the release guidance:

1. FreeBSD doesn't have a standalone usermod command. Instead of the usermod command suggested by LibreNMS, run pw usermod instead, such that the user that runs Apache on your system is added to the librenms group. In my case, Apache runs as daemon, so I ran:

   [root@host librenms]# pw usermod daemon -G librenms

2. FreeBSD's setfacl command lacks a recursive -R option. Disregard the setfacl commands suggested by LibreNMS and run the following chmod instead, from within the main LibreNMS directory:

   [root@host librenms]# chmod -R ug+rwx bootstrap storage logs

Because group membership doesn't take effect until the next login, you'll need to restart Apache at the very least, and you may need to reboot the system. After doing so, the permissions errors had cleared for me, but I was getting a new one...

RuntimeException: The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct key lengths

This presented itself as a generic "Exception" page (with a cute mascot), which wasn't very helpful. I had to look in the LibreNMS logs/librenms.log file to find the actual error:

[2018-06-04 18:16:17] production.ERROR: RuntimeException: The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct key lengths. in /path/to/librenms/vendor/laravel/framework/src/Illuminate/Encryption/Encrypter.php:43 [full stack trace]

The solution to this RuntimeException is to cd to your main LibreNMS directory (the equivalent of /path/to/librenms in the error message above) and run:

[root@host librenms]# php artisan key:generate

Upon success, you'll see output like this:

Application key [base64:IZKYh1.......] set successfully.

Now load the LibreNMS web interface again and you should see the login page.

The launch of Cloudflare's new 1.1.1.1 DNS service has brought much fanfare and a heap of praise. More choice is always a good thing, and support for both DNS-over-TLS and DNS-over-HTTPS make 1.1.1.1 an interesting option. In this post I'm going to explain why I won't use it yet, and why you might not want to switch either without doing some testing first.

Fastest isn't always best

Cloudflare touts 1.1.1.1 as "the Internet's fastest DNS directory." In terms of pure response time, they might be right. But when dealing with DNS, response time is only part of the equation. Just as important are the replies you get from a DNS server, the IP addresses it hands out in response to domain queries. Responses from centralized DNS services are sometimes unsatisfactory and can lead to service degradation. The answers come fast, but are they the right ones?

I like to use a telephone analogy here. Imagine you dial 9-1-1 and your call is answered so quickly you never even hear it ring. But it turns out you've been connected to a dispatcher in a city hundreds of miles away, and while she can send the authorities, it's going to take them awhile to reach you. The response was fast, yes, but it wasn't optimal. You would probably have preferred to speak to your local 9-1-1 dispatcher instead, even if you had to wait 3 or 4 rings for them to pick up the phone.

So, too, is the case with DNS. Public name servers may answer faster than your ISP's DNS, but that speed is negated if the servers they point you to are very distant.

Testing public resolvers for speed

Cloudflare makes bold speed claims, so I've done some basic testing to gauge how 1.1.1.1 stacks up against other options. Measurements were taken of the following DNS services:

• 1.1.1.1 - Cloudflare
• 4.2.2.4 - Level3
• 8.8.8.8 - Google
• 9.9.9.9 - GCA/PCH/IBM
• 75.75.75.75 - Comcast (customer-only)

Because 1.1.1.1 is promoted as a consumer DNS service, all observations below are from my residential Comcast cable connection in Memphis, TN.

Latency

Cloudflare's service appears to have robust connectivity and a diverse geographic presence. 1.1.1.1 is physically closer to me than other common public DNS options. The server I'm routed to, 172.69.197.23, is 7 network hops out, with an average ping of only 13.1 ms. It responds to an RFC4892 query with mem01, so is presumably located here in Memphis. That's about even with Comcast's 75.75.75.75, which also has an anycast presence in town, and it beats the other public resolvers. See the traceroutes for details.

NXDOMAIN

For the first round of DNS testing, I queried each server for 100 invalid domains in the .com zone to gauge NXDOMAIN response time. (4.2.2.4 hijacks NXDOMAIN and returns two advertising servers instead.)

  [parse@word ~]$ for i in {1..100}; do dig A $(head /dev/urandom | sha1).com \ 
      @1.1.1.1; sleep 5; done > 1.1.1.1.nxdomain.txt &

Cold queries

Next, I queried 100 randomly generated hostnames on a domain configured for wildcard DNS. This test was intended to measure "cold" or uncached query response time.

  [parse@word ~]$ for i in {1..100}; do dig A $(head /dev/urandom | sha1).shaun.ga \ 
      @1.1.1.1; sleep 5; done > 1.1.1.1.cold.txt &

Likely cached queries

Finally, I queried the top 100 domains on the Cisco Umbrella list. DNS servers are likely to have answers for these popular domains cached, improving response time.

  [parse@word ~]$ head -100 top-1m.csv | cut -f2 -d"," | dos2unix > top-100.txt
  [parse@word ~]$ while read host; do dig A $host @1.1.1.1; sleep 5; \
      done < top-100.txt > 1.1.1.1.top.txt &

The same series of tests was performed against all 5 DNS services. The output from each test was processed to calculate the mean average query times in millisecond...

Today I saw an interesting IMAP probe. These are usually background noise, occurring by the hundreds each day and mostly trying weak passwords against non-existent accounts. This particular login attempt was made on a valid alias, so I took a few seconds to dig deeper, and found an indicator of attack I hadn't seen before.

Immediately preceding the IMAP authentication attempt, the same IP address had issued one HTTP GET request and two HTTP POST requests for /autodiscover/autodiscover.xml on the same domain (the file doesn't exist). Not being familiar with autodiscover.xml, I looked up the documentation and it's a WPAD-like configuration discovery scheme for Outlook. Aside from people whose own Outlook clients and/or Exchange servers are spamming their own web server logs with requests, I couldn't find many people talking about seeing it in their httpd logs. autodiscover.xml doesn't seem to be commonly scanned, spidered, or abused.

The HTTP and IMAP requests all originated at an IP allocated to mail.ru: 5.61.237.36. As far as I can tell, mail.ru doesn't offer any services that hand out IPs to their users, making it likely that the traffic came directly from mail.ru equipment. At first I suspected mail.ru must have an "add a remote account" feature like Gmail does, and someone figured out how to script it to run IMAP probes. Clever! mail.ru does, in fact, have some capability to collect mail from third-party accounts; I managed to find an English help page about using it for POP3. There's no mention of IMAP here, but their English documentation may be lacking or out of date.

If an attacker was automating scans through the mail.ru service, though, I'd expect to find more recorded incidents. There are only a smattering of reports on AbuseIPDB, and none on blocklist.de. The lack of widespread abuse activity leads me to believe this isn't an automated scan at all; instead, someone is using mail.ru's remote collection feature to manually target specific accounts.

If you don't use Outlook/Exchange and don't get any legitimate web requests for autodiscover.xml, it might be useful to add that string to your IDS or your log watcher.

Facebook's data collection tactics make waves

With Facebook and Cambridge Analytica in the news, Facebook's threat to privacy is finally getting the widespread attention it deserves. Beyond the obvious political propaganda concerns, the wider implications of Facebook's data collection are coming to light, and some of the examples are alarming. Multiple users have downloaded their history and discovered that Facebook had records of all of their phone calls and text messages.

In addition to siphoning up phone-related data, much of the web has become infected with Facebook tracking beacons that collect your browsing history on desktop PCs and mobile devices. When you see a Facebook "Like" or "Share" button on a web page, your browser typically loads these directly from Facebook's servers. Some websites without visible Facebook widgets will instead load a tiny invisible image known as a web bug or tracking pixel. Facebook logs where all of these requests come from, along with enough metadata to identify your specific browser like a fingerprint: your IP address, your browser's name and version, your screen resolution, any Facebook cookies you may have, and more.

This tracking all takes place whether you're logged into Facebook or not, and even if you don't have a Facebook account at all. Facebook maintains "shadow profiles" of unregistered users, and will correlate all of their surveillance with your real identity if they can obtain it through marketing partners or other means.

A comprehensive approach to blocking Facebook is required

Faced with pervasive data collection from multiple angles, what's a concerned person to do?

Abandoning your Facebook account and deleting the apps make a good first step, but this effort isn't sufficient to stop Facebook from watching what you do online. To avoid leaking data about your Internet usage habits to Facebook, a more proactive security stance is needed. I recommend a multi-layered approach:

• Uninstall all Facebook-owned apps.
  This will end any direct collection of phone data you never intended Facebook to see.

• Install privacy-enhancing browser extensions.
  These browser extensions can recognize and block specific beacon code.

• Block Facebook in DNS.
  By sinkholing Facebook's domains, you'll eliminate most of their tracking and speed up web browsing.

• Firewall Facebook from the network.
  Firewall rules will catch connection attempts to new or unknown Facebook-owned domains.

Not all of these steps are accessible to everyone. The latter two require some advanced technical skills (or a chunk of time to spend learning), and are easier if you have a computer on your network acting as a dedicated hardware router. Implement the layers you can. Each safeguard you add leaves you better protected than you were before.

Security Layer 0: Uninstall all Facebook-owned apps and disengage

Skill level: Beginner

If you have any of the following apps, consider them tainted and remove them from all your devices: phones, tablets, iPods, everything. Having these apps installed gives Facebook direct access to your device, and may imply legal consent to various forms of data collection.

• Facebook
• Messenger
• Instagram
• WhatsApp

Start by deleting the Facebook app. Get rid of the others on that list, too; they're all owned by Facebook, and the extent of data sharing between them is unclear. You might also take a few minutes to evaluate settings in your other apps, disabling the "Facebook Connect" feature wherever you find it.

If you're ready to permanently sever ties with Facebook, login to Facebook in a web browser and delete your account.

Many folks aren't ready for this level of commitment, and that's okay. Using a web browser, log in to Facebook and post a "goodbye" status update so people know you're no longer reachab...

Let's Encrypt, a leading issuer of SSL/TLS certificates, has taken a big step forward by adding support for Certificate Transparency. This capability, now merged into Let's Encrypt's Boulder CA suite, resolves a long-standing feature request by embedding Signed Certificate Timestamps (SCTs) into newly minted certificates. Because the SCT is attached directly to the certificate, no additional server modules or configuration is needed by site administrators.

Certificate Transparency support allows websites using Let's Encrypt certificates to implement the Expect-CT HTTP header. This header provides additional security by instructing web browsers to verify the certificates they receive against public certificate transparency logs. Forged or otherwise malicious certificates are often absent from these logs, and will never contain the correct SCT, making them easier to detect when a site uses Expect-CT.

The feature was officially enabled on March 29.

What Certificate Transparency does

In a perfect world, every time you connect to a website (or other service) over TLS, you'd be able to trust the certificate presented by the remote host as long as it's issued by a valid Certificate Authority that you also trust. But digital trust isn't perfect. Private signing keys sometimes get compromised, and CAs occasionally exhibit unscrupulous behavior, resulting in forged or mis-issued certificates that look valid but are controlled by a malicious actor. These certs can be used to intercept traffic, inject resources, or perform other man-in-the-middle style attacks.

Certificate Transparency (RFC6962) helps mitigate this problem by introducing additional verification into the chain of trust. The foundation lies in certificate logs, which are implemented as immutable, cryptographically signed ledgers that can be viewed and audited by the public. (If you're into buzzwords, you can think of a certificate log as a blockchain for SSL certs.) Public certificate logs are currently operated by Google, Cloudflare, DigiCert, Certly, Izenpe, WoSign, Venafi, CNNIC, StartCom, and Comodo, with other services like crt.sh providing an index to their data.

When a participating CA like Let's Encrypt mints a new certificate, they submit it to one or more certificate logs, creating a permanent visible record of its issuance. The certificate log, in turn, responds to the CA with a signed certificate timestamp (SCT) corresponding to the log entry. These logs and signatures are routinely monitored by domain owners, security researchers, and intellectual property firms. The idea is that all of this auditing means bogus certificates will be spotted early and can be quickly revoked, minimizing the fallout from counterfeits.

Automated certificate verification through Expect-CT

Certificate log monitoring only solves one aspect of the forgery threat model, because only certificates that are proactively submitted to the public logs can be inspected. An attacker who creates a malicious certificate isn't likely to publish it and tip their hand. Such certificates are often narrowly deployed to target specific individuals or groups, keeping them hidden from organizations that perform routine auditing. A system is also needed for individual end users to detect problem certificates, and this piece of the puzzle can be addressed with the Expect-CT HTTP header.

In 2017, engineers at Google proposed a new HTTP header called Expect-CT (draft specification). By implementing this header, a website operator can tell visitors' browsers that the site's legitimate TLS/SSL certificate is published in certificate logs, and that any o...

If you run a mail server, whether it's for your own personal email or for your company and its employees, one of the biggest challenges you'll face is keeping spam at bay. Fortunately, several organizations maintain DNSBLs available for public use. These blacklists of known spammer servers and networks are the biggest hammer in a mail admin's toolbox, and are easy to configure in most common MTAs.

Used wisely, a good selection of DNSBLs can reject most of your incoming spam early in the SMTP conversation. This prevents your server from having to process those messages through other, more resource-intensive filtering strategies. On the other hand, each blacklist you enable adds another potential DNS lookup for every incoming message, and another opportunity for false positives that discard legitimate mail. To that end, it's a good idea to keep an eye on how the DNSBLs you choose are working on your system.

In this post I'll share some methods for gauging how DNSBLs are performing on a Postfix install. If you're following along with a production system, you might want to copy its maillog to another server for processing, especially if its size exceeds your free RAM.

Gathering statistics

In judging a blacklist, there are two important metrics to consider:

1. How many junk transactions is it helping you block? A DNSBL that only identifies a handful of abusive senders per day may not be worth keeping around.

2. How many false positives are being generated? Even the most permissive of blacklists will flag some legitimate senders as spammy from time to time.

False positives can be a tough nut to crack, because no amount of monitoring can guess when someone's expected messages didn't arrive. Only your users can provide that insight. You should make yourself (or your ticket system) approachable to your users so they can let you know when the system doesn't meet their expectations. Follow up on each report, and if a DNSBL is responsible for missing mail, weigh the benefits of its continued use against its rate of false positives.

A DNSBL's rejection rate is much easier to figure out. To discover the numbers, we'll consult the Postfix log file(s). In its default configuration, Postfix records a DNSBL rejection with a maillog entry that looks like this:

Feb  6 20:11:39 mailman postfix/smtpd[21916]: NOQUEUE: reject: RCPT from unknown[60.177.228.194]: 
554 5.7.1 Service unavailable; Client host [60.177.228.194] blocked using sbl-xbl.spamhaus.org; 
https://www.spamhaus.org/query/ip/60.177.228.194; from=<user@helo-host> to=<user@rcpt-host> 
proto=ESMTP helo=<example.com>

Since the entries are all formatted the same way, we can use some standard Linux text processing utilities to crunch the log and gather the target numbers. Here's a bash one-liner to tally up the number of messages rejected using each DNSBL. I've broken it into three lines for illustrative purposes:

grep "$(date +%b\ %e)" /var/log/maillog* | grep 'Service unavailable' |  \
cut -f $((20 + $(date +%e | tr -cd ' ' | wc -c))) -d' ' |                \
sort -n | uniq -c | sort -nr

The first line filters the maillog files for records from today that indicate a DNSBL rejection. (If your maillog rotates into zipped files, you may need to hack on this a bit.)

That funky second line determines where to find the DNSBL hostnames in the log records. If you imagine each maillog entry as a list of columns separated by spaces, the DNSBL's hostname appears in field #20... Unless the current day of the month is only 1 digit long. In that case, Postfix pads the date with a space, so we have to shift one more column to the right.

The last line performs the accounting and sorts everything into a list.

Running that command, I get the following sample output:

   5490 sbl-xbl.spamhaus.org;
     66 dyna.spamrats.com;
     60 psbl.surriel.com;
     52 truncate.gbudb.net;
     25 spam.dnsbl.anonmails.de;
     11 noptr.spamrats.com;
      8 dnsbl.dronebl.or...

It looks like there's a new referer spam campaign underway, with a fresh batch of hosts to block. This one is predominantly promoting Russian and Ukrainian websites. I first caught wind of it from Dave Horsfall, who in late January mentioned on an anti-spam mailing list that he'd seen pills24h.com in his web access logs. I found that domain in my logs too, made a note to look further, and today I got around to poking at it a little.

Since I don't run WordPress or any common blog software, I was surprised to see referer spam suddenly hitting this site in earnest. Most modern spambots are intelligent enough to only target sites vulnerable to their spam. The мудак behind this campaign isn't so discerning, although he's at least bright enough to use IPs that aren't listed in the Stop Forum Spam blacklist. The abuse originates in snowshoe fashion from space allocated to Ukrainian provider Kyivstar / Golden Telecom (AS15895).

Offending hosts

For your blocking pleasure, here are the IPs involved in the spamming campaign:

5.248.196.93
5.248.199.158
5.248.253.101
37.115.112.228
37.115.184.155
37.115.185.9
37.115.186.4
46.118.113.100
46.118.114.175
46.118.116.121
46.118.125.21
46.118.127.172
46.118.152.50
46.118.225.78
46.119.112.98
46.119.113.175
46.119.114.157
46.119.115.60
46.119.118.96
46.119.121.22
46.119.121.71
46.119.122.170
46.119.123.218
46.119.126.51
46.185.74.179
46.211.13.134
109.162.66.73
134.249.48.151
134.249.48.174
134.249.52.34
134.249.53.158
134.249.54.27
134.249.55.53
134.249.66.84
178.137.16.45
178.137.16.174
178.137.18.222
178.137.55.200
178.137.82.153
178.137.83.231
178.137.86.85
178.137.86.152
178.137.88.8
178.137.88.90
178.137.91.90
178.137.92.135
178.137.160.170
178.137.162.218
178.137.163.137
178.137.165.61
178.137.167.106
178.137.178.122
178.159.37.55
178.159.49.228
188.163.72.38
188.163.79.63

Here are the domains each host has been pimping.

5.248.196.93

beachtoday.ru

5.248.199.158

avtovykup.kz

5.248.253.101

4inn.ru

37.115.112.228

komukc.com.ua
pills24h.com
studentguide.ru

37.115.184.155

balkanfarma.org
fishtauto.ru
gazel-72.ru
iptvuk.co.uk
krasivoe-hd.net
natprof.ru
petrushka-restoran.ru
pills24h.com
rocketchange.ru

37.115.185.9

filesclub.net

37.115.186.4

gandikapper.ru
jjbabskoe.ru

46.118.113.100

svetka.info

46.118.114.175

bird1.ru
pills24h.com
t-rec.su

46.118.116.121

doxyporno.com
raschtextil.com.ua

46.118.125.21

gazel-72.ru
krasivoe-hd.net

46.118.127.172

online-sbank.ru

46.118.152.50

pornohd1080.online

46.118.225.78

no-rx.info
pills24h.com

46.119.112.98

flowertherapy.ru
skinali.photo-clip.ru

46.119.113.175

avtorskoe-vino.ru
cryptoswap.biz
electronic-component.org
doxyporno.com
kinoduh.ru
kollekcioner.ru
popugauka.ru
raschtextil.com.ua
supermama.top
superoboi.com.ua
truebeauty.cc
whoiswho.crimea.ua

46.119.114.157

sildenafil-tadalafil.info

46.119.115.60

drugs-no-rx.info
englishtopik.ru

46.119.118.96

komputers-best.ru
magnetic-bracelets.ru
scat.porn

46.119.121.22

www.xn--80aaajkrncdlqdh6ane8t.xn--p1ai (IDN: www.мягкиеокнасаранск.рф)

46.119.121.71

5elementov.ru
buynorxx.com
en.home-task.com
pillscheap24h.com
spy-app.info

46.119.122.170

www.inet-shop.su
www.sundrugstore.com

46.119.123.218

perl.dp.ua

46.119.126.51

pills24h.com

46.185.74.179

flowertherapy.ru

46.211.13.134

polyana-skazok.org.ua
strady.org.ua
suzuki-metropolis.kiev.ua
td-l-market.ru

109.162.66.73

eduserver.net
filesdatabase....

While doing a bit of housecleaning on a system, I hit a subversion error I've never seen before:

[user@host]$ svn ci -m "Replace symlink with hard copy of file"
svn: E145001: Commit failed (details follow):
svn: E145001: Node '/path/to/my/myfile' has unexpectedly changed kind

I'd replaced a symlink, which was already versioned, with a copy of the target file itself. I'm usually pretty good at convincing subversion to accept whatever arcane mangling I've done, but it just wouldn't take this one, and Google was no help. I was able to get things right again with the nuclear option, removing the offending object from version control and then adding it back. Specifying --keep-local removes the file from the subversion repo but leaves it in place on disk.

[user@host]$ svn status
~       myfile
[user@host]$ svn rm --keep-local myfile
D         myfile
[user@host]$ svn ci -m "Remove symlink, will add back as a file"
Deleting       myfile
Committed revision 1602.
[user@host]$ svn add myfile
A         myfile
[user@host]$ svn ci -m "Adding hard copy of what used to be a symlink"
Adding         myfile
Transmitting file data .
Committed revision 1603.

All fixed.

This week I finally took the plunge and upgraded most of the servers I work with from PHP 7.1 to PHP 7.2. (Some of them still can't be brought forward due to dependencies that use mcrypt.) I ran into a few snags with the upgrade to 7.2 and thought I'd document them here. This may be useful if you:

• Run CentOS 6 (6.9 in my case),
• Want to install PHP 7.2,
• Need pthreads support in PHP, and
• Prefer to compile PHP from source

Executive summary

In order to build PHP 7.2 with pthreads on CentOS 6, you must upgrade to autoconf 2.64, which can't presently be done through the yum package manager. You'll also have to first build PHP 7.2 without pthreads, then use this "bootstrap" copy to prepare the pthreads extension before compiling PHP a second time.

autoconf 2.64

Start by installing autoconf 2.64. The latest version available through yum is 2.63, which isn't sufficient to build PHP's configure script.

It's critical that you supply the --prefix=/usr option when configuring autoconf. The default installation prefix for the generic autoconf distribution is /usr/local, but CentOS 6 keeps it in /usr. If you forget to set the correct prefix, you're going to wind up with two different versions of autoconf installed, and who wants that?

curl -Lo autoconf-2.64.tar.gz ftp://ftp.gnu.org/pub/gnu/autoconf/autoconf-2.64.tar.gz
tar xfz autoconf-2.64.tar.gz
cd autoconf-2.64
./configure --prefix=/usr
make && make install

Make sure the correct version has been properly installed. autoconf --version should show:

autoconf (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
[..snip..]

Bootstrap PHP 7.2

Compiling PHP 7.2 with pthreads presents a bit of a Catch-22: in order to build the pthreads extension, you need to have the 7.2 version of PHP (more accurately, a version with ZEND_MODULE_API_NO >= 20170718) and its libraries already installed. To work around this scenario, it's necessary to compile and install a minimal version of the PHP 7.2 CLI first, then use this "bootstrap" version to prepare pthreads.

Start by obtaining the latest PHP 7.2 source distribution and doing a minimal build. The only option you need to pass to configure this time around is --enable-maintainer-zts, to turn on thread safety. Don't worry about other modules (mysqli, PDO, etc.) as you're not going to be keeping this version of PHP installed for long. If you also run PHP as an Apache module, disregard that for now and just build the CLI version.

curl -Lo php-7.2.1.tar.gz http://us3.php.net/get/php-7.2.1.tar.gz/from/this/mirror
tar xfz php-7.2.1.tar.gz
cd php-7.2.1
./configure --enable-maintainer-zts
make
make install

Verify that a thread-safe version of PHP 7.2 has been installed. The output of php -v should indicate a 7.2 version number and the ( ZTS ) signature.

PHP 7.2.1 (cli) (built: Jan 8 2018 17:14:36) ( ZTS )
[..snip..]

Prepare pthreads

Obtain and prepare the pthreads extension. Note there's a dot . as the final argument to git clone. If you don't use git, you can manually download a .zip file of the pthreads source.

cd ext      #this should put you in the php-7.2.1/ext directory
mkdir pthreads && cd pthreads
git clone https://github.com/krakjoe/pthreads.git .
phpize && ./configure && make install

If you receive error output that includes the following,

php_pthreads.c:38:3: error: #error "pthreads requires PHP 7.2, ZTS in versions 7.0 and 7.1 is broken"

...this means that your bootstrap PHP 7.2 didn't install properly, and you have an older PHP command line binary on your system. You should repeat the bootstrapping step above.

Build your final PHP 7.2

Now it's time to build PHP 7.2 for real. Return to the main PHP source tree, clean up the artifacts from the bootstrap build, and generate a new configure script. ...