If you want to compile Doxygen (/usr/ports/devel/doxygen/) on FreeBSD without also building LaTeX and Ghostscript, disabling the "LaTeX support" option in the make config screen isn't sufficient.

You also need to disable the "Build and/or install documentation" option.

Turns out, Doxygen uses itself to build its own docs, and requires features from the LaTeX and Ghostscript support to do so. As such, if you disable LaTeX support but ask for the documentation to be built, LaTeX will be silently re-enabled! This isn't intuitive or apparent from the config interface; you have to look in the Makefile to figure it out. The DOCS_IMPLIES line forces LaTeX back on:

DOCS_USES=              ghostscript:build
DOCS_ALL_TARGET=        docs
DOCS_BUILD_DEPENDS=     dot:graphics/graphviz
DOCS_CMAKE_BOOL=        build_doc
DOCS_PLIST_FILES=       man/man1/doxygen.1.gz \
                        man/man1/doxyindexer.1.gz \
                        man/man1/doxysearch.1.gz \
                    ...

I spend a lot of time on Reddit, and have wanted to explore their public API for years. Last month that itch struck again and I finally decided to scratch it. Armed with a list of data I needed to spider and crunch (more on that another day, maybe), I set out to see what libraries are available. The most popular Reddit API client is written in Python, which I don't grok, and the PHP offerings didn't excite me much. You already know how this story ends; I decided to start writing my own.

Enter Snuze, a new PHP client for Reddit's API.

It's in a preview release state while I get the design stabilized. At the moment, Snuze can:

• Authenticate via OAuth
• Store and re-use OAuth bearer tokens until expired
• Track the API rate limit status and autopause when the bucket's empty
• Fetch subreddit data (and optionally persist to MySQL)
• Fetch link data (and optionally persist to MySQL)
• Fetch user account data

Snuze comes with entity classes to encapsulate th...

Beginning with Java JRE 8u211, the online Windows installer appears to generate a prolific amount of traffic not seen in previous versions. In my environment, it attempted to contact the following hosts:

0138-0-nyc104[unique-id-removed].beacon.rum.dynapis.info
0138-0-nyc108[unique-id-removed].beacon.rum.dynapis.info
0138-0-nyc10a[unique-id-removed].beacon.rum.dynapis.info
0138-0-nyc10d[unique-id-removed].beacon.rum.dynapis.info
0138-0-nyc10e[unique-id-removed].beacon.rum.dynapis.info
aws-iad1.rum.dynapis.com
aws-sfo1.rum.dynapis.com
azr-dsm1.rum.dynapis.com
azr-iad1.rum.dynapis.com
azr-ord1.rum.dynapis.com
azr-sat1.rum.dynapis.com
azr-sjc1.rum.dynapis.com
beacon.rum.dynapis.com
cdnet.jisusaiche.com
cdnet.jisusaiche.com.wtxcdn.com
dgo-nyc1.rum.dynapis.com
dgo-sfo1.rum.dynapis.com
dgo-yyz1.rum.dynapis.com
edge.jisusaiche.com
flare.jisusaiche.biz
goo-cbf1a.rum.dynapis.com
goo-chs1b.rum.dynapis.com
ibm-iad1.rum.dynapis.com
ibm-sjc1.rum.dynapis.com
jisusaiche-475487.c.cdn77.org
j...

If you see an error message like this one in the BIND DNS server's client log, it may be harmless:

24-May-2019 21:00:05.019 client: error: (example.com/A): query_find: query_getdb failed

I couldn't find anything explaining the error (hence this post) so I looked at the source; this message comes from query.c. What's happening here is that BIND is trying to figure out which zone contains the answer it needs, but it can't find the zone, so query_getdb failed is logged and a SERVFAIL response is sent to the client.

As it turns out, the timing of this error in the log coincides exactly with the BIND service being restarted. In this case I had just upgraded a server from 9.11.6-P1 to 9.11.7 and bounced the service. At the precise moment the logged query arrived, BIND hadn't loaded that zone yet, so of course it couldn't be located in memory. The zone in question was loaded a...

While deploying a port upgrade this afternoon, I ran into a problem that I knew was coming eventually. FreeBSD's daily run output has been warning me for months that Perl 5.24 would be reaching end-of-life, and it just happened. It turns out that perl5.24's expiration date was May 9th 2019, so portmaster bombed out while working on a port with a dependency on Perl:

The lang/perl5.24 port has been deleted: Has expired

portmaster helpfully (?) installed a newer-but-not-newest version of Perl, 5.26.3, but something about it didn't "stick." Running perl -v showed the 5.24 version remained in place, and portmaster itself was still unable to upgrade any ports with a dependency on Perl. After some digging in the ports collection's UPDATING docs, here are the steps I took to get Perl back in proper working order (and upgraded to the latest stable, 5.28).

First, edit /etc/make.conf and append the following l...

Update

Reddit user megalomaniacs4u has found a more elegant solution that you probably want to try first. It achieves the same goals (importing a good certificate, re-verifying your add-ons) in fewer, easier steps.

Original post

This is an interim fix for Armagadd-on 2.0 on Firefox 61, 56, and potentially other old versions. As of this writing, Mozilla's official hotfix XPI doesn't work on these versions, so manual workarounds are needed.

This process successfully reactivated my extensions on Firefox 61 and Firefox 56 under Windows. It also worked on an old copy of Firefox 48 for Mac OS X. I can't promise that your add-ons won't be disabled again in the future, but this might get them working for now.

There are two objectives: one, get a working Mozilla signing certificate imported into Firefox; and two, tell Firefox to re-verify your extensions. You must complete all of the steps below. Use this g...

One of my DNS servers has been seeing some unusual bursts of traffic over the past month. At random intervals, several hundred rapid queries for qname miep and qtype ANY will arrive, appearing in BIND's security log like this:

03-May-2019 16:05:18.430 security: info: client @0x7f392c0bcfe0 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied
03-May-2019 16:05:18.430 security: info: client @0x7f392c0bcfe0 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied
03-May-2019 16:05:18.430 security: info: client @0x7f392c0cb600 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied
03-May-2019 16:05:18.430 security: info: client @0x7f392c0bcfe0 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied

At first glance, this resembles a DNS amplification attack. For one thing, the deprecated ANY qtype is used in such attacks to maximize the size of the answer packets. Secondly, the origin IPs are probably forged, considering the legitimate resolver 1.1.1.1...

With a couple of my domains now past 20 years old, dozens of email addresses I've used over the years have made their way onto countless different spammer mailing lists. As such, my mail server rejects a lot of spam, thousands of attempts daily. Keeping an eye on the rejection stats lets me observe spam trends, and an interesting one caught my eye over the weekend.

For reasons unknown, someone launched a high-volume spam campaign targeting completely bogus and undeliverable addresses.

I'm used to dictionary attacks, where a spammer pumps messages to common aliases like david@ every domain he can find, hoping that many of them reach a real person. This is something different. The user parts of these recipients are longer, unique strings that somewhat resemble compound words or names. Here are a few examples,

awproceed    
brigmanramac    
celiavolkan    
hginherent    
kalenametzge    
ksuassignment    
phileyburlin    
straussotokar    
wickertmilos    

Not only have thes...

If you're looking to speed up your FreeBSD kernel and world builds, try using the WITH_META_MODE compile option and/or installing and enabling ccache. Turning these on gave me a 30x speed boost for the buildworld and buildkernel process. That's not a typo. Compiling a complete kernel and world on my test machine used to take over 6 hours, even with /usr/obj/ having been left intact from prior builds. My most recent build finished in just 13 minutes, or around 1/30th of the old time!

WITH_META_MODE

The WITH_META_MODE compile option takes advantage of the filemon kernel module, creating and inspecting metadata about the objects compiled during a system build. New metadata files get stored in /usr/obj alongside the object files they refer to. On subsequent builds, when the compiler goes to build an object, if nothing about the build command or its related files (headers, libraries, etc.) has changed, the cached object can be used instead...

Poking around at a project this morning, I encountered an unusual error from subversion:

[myuser@host ~/projects/slice]$ svn ci -m "Parse EDNS options from log lines"
Sending        ingest.php
Transmitting file data .svn: E000013: Commit failed (details follow):
svn: E000013: Unable to create pristine install stream
svn: E000013: Can't create temporary file from template 
    '/home/myuser/projects/slice/.svn/tmp/svn-XXXXXX': Permission denied

Well that's interesting, I've been committing to this repository for days now without any errors. What happened?

[myuser@host ~/projects/slice]$ ls -la .svn/tmp/
total 8
drwxr-xr-x  2 root    myuser  512 Dec 21 19:23 .
drwxr-xr-x  4 myuser  myuser  512 Dec 21 19:23 ..

Aha, my project's .svn/tmp directory is suddenly owned by root. This was my own mistake. A few days ago, while logged in as root, I had run svn cleanup in this working copy; during the cleanup process, root took ownership of .svn/tmp. The fix was as eas...