Running open source 'unix' services via MacPorts on macOS is no longer feasible for me
macportsusers-20171215 at billmail.scconsult.com
Tue Nov 29 17:29:32 UTC 2022
On 2022-11-29 at 06:54:50 UTC-0500 (Tue, 29 Nov 2022 12:54:50 +0100)
Gerben Wierda via macports-users <gerben.wierda at rna.nl>
is rumored to have said:
> Over the last years, it has become harder and harder to run Unix
> services on my Macs. I'm using MacPorts for these since the demise of
> macOS Server and they include
> a mail server (dcc, apache-solr8, clamav-server, rspamd, dovecot,
> a name server (nsd, unbound)
> a web server (nginx, minio)
> Before Monterey I was running Mojave and that worked very well. I
> skipped Catalina and went straight for Monterey so I would have a long
> period of 'no large migrations'.
A brave choice. In my opinion, Mojave is the last macOS fit to act as a
basic Internet services host. I've used Macs since 1984 and run
mail+web+DNS servers on my own Macs since 1994. Catalina is the least
suitable OS in that time. Even "Classic" MacOS 9 did less to thwart
server usage, and that was when "MacOS Server" was a product with a
3-digit pricetag. Apple does not want people running servers on Macs. Or
iPhones, or iPads, or Watches. They DO want to have largely the same OS
on all 3.
> The experience has been horrible. I had to turn off the application
> layer firewall on the server for instance.
The Apple ALF is designed to protect people using their Macs in ways
Apple approves of. It is possible to have it notionally enabled on
Catalina and still run sevices, but you basically have to configure all
real functionality off.
And with Catalina, Apple removed the fine old ipfw packet filter and
left only a weirdly dysfunctional port of pf that they've jiggered for
ALF in undocumented ways. It can be made useful, but only after ALF is
> I had to start some services (MinIO) not via launchd but by hand
> because they would not start properly because of permissions when I
> did (MinIO could not access a fixed mount external disk when started
> from launchd, but had no problem accessing it after boot).
Yes, startup and disk access has been made more arcane intentionally by
Apple as a security measure. You cannot expect a normal-ish environment
on modern macOS until there's a logged-in GUI user.
> About 1 to 2 times every day, the system is totally dead, it gets
> stuck apparently because it runs out of sockets or something like
> that. I suspect this is because I am running a public mail server
> which gets a lot of connections and macOS has some sort of resource
> leak. After maximally about an hour, the system gets 'unstuck' and
> moves on. The 'unstuck' started to happen was after 12.5 to 12.5.1 (so
> an improvement) but it has the feel of Apple doing a quick and dirty
> fix in 12.5.1 for a resource leak in 12.5.
Ewww. I don't have any experience with MinIO on macOS, but I have seen
similar hangs on Catalina machines used only as personal computers that
are *in part* due to Mach port leakage in many different programs. I
guess I'm glad to hear that there's a fix of sorts in the latest
> Apple has been a rock solid server system for me for many years. Since
> Monterey I consider it to be extremely unreliable and not feasible as
> a server environment for unix-like services.
I have long held back on moving to new versions of macOS because it has
been getting more hostile to my usage for some time. Not just server
duties, but as a workstation for a sysadmin.
> I suspect that all of this is because Apple is moving to a new
> security mechanism, one more focused on how it is done in iOS too,
> where things like code signing, immutability of parts of the file
> system, etc. are taking the role that traditionally is done by
> ACL/POSIX-like permissions.
I believe that it's more about supplementation and tightening rather
than replacement. Traditional POSIX permissions and ACLs have proven to
be inadequate to protect macOS users from themselves.
As problematic for me has been the churn of basic services. The logging,
service management, and scheduling subsystems of POSIX-compliant systems
have long been problematic. It's not accidental that Apple has gone
through 2 different bespoke init and syslog replacements and a cron
replacement, while Linux and the BSDs have all had their own forays into
novel approaches, e.g. systemd, OpenRC, Upstart, Dillon vs. Vixie cron,
rsyslog, etc. Apple made some of the same basic choices as the bulk of
the Linux world (or at theast the RedHat/Canonical Cabal,) and as a
result we share breakage with the victims of systemd: lost or unusable
logs, startup anomalies, etc.
> Apple's new way of doing security is arguably stronger than the old
No argument about it: it is MUCH stronger. The ALF is mostly functional
and unobtrusive for most users, and prevents issues that could be be a
widespread threat were it not a default part of the OS. As it is, those
of us who disable it are beneficiaries of its existence because there's
a whole class of malware behaviors that malware authors don't bother
> But the 'old' way of doing things is less and less supported and
> certainly not a focus for Apple to keep operational (which is dumb
> because by not supporting they are flying blind for the kind of
> resource leak errors I seem to have encountered). So, install unbound,
> and after boot macOS will ask you 'do you want unbound to accept
> incoming connections?'. Yes, of course, but that setting doesn't
> stick. After every next reboot, the same happens. Run the same
> executable side by side on different ports, and ALF gets confused. So,
> not only is the old ACL/POSIX way of permissions no longer properly
> implemented, the new system is not friendly for your own compiled
If you code for Macs outside of Apple's macOS commercial ecosystem and
rely on cross-platform compatibility via the use of standard POSIX APIs,
you will have trouble with any daemon-like software unless you make
special accommodations for the extra security on macOS. The same is true
of similar novelties on other platforms (SELinux, systemd, etc.) but
Apple has done a very poor job of giving developers the tools and docs
to Just Work.
> Apple turns macOS into a purely consumer appliance, it seems.
> That is their good right, but they also starve attention to the old
> unixy-way of things, leading to weak (certainly not robust)
> implementations of the unix-side. And that might be the eventual death
> of MacPorts unless it goes full in on Apple's new security model,
> signing and all.
I expect that much of MacPorts can continue to work just fine, because
so many ports are NOT server packages of any sort.
> And for the time being, Apple's own suggestion to move to open source
> variants of the macOS Server stuff they abandoned, is not to be taken
> seriously as they also are not serious about the foundation those open
> source elements need.
Absolutely correct. Apple is not serious about maintaining robust
compatibility with the POSIX-compliant world in regards to anything that
runs in the background without a UI and talks to the net. They do not
want anyone doing that on their devices but them. Whatever they have
said about replacing Server is disingenuous lip service. There's nothing
for Apple to gain by maintaining the ability to run free software that
is not wedded in any exclusive sense to their platform.
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
More information about the macports-users