Running open source 'unix' services via MacPorts on macOS is no longer feasible for me

[Bill Cole]

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, 
> postfix)
> 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 
disabled.

> 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 
version.

> 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 
> way.

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 
trying.

> 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 
> stuff.

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.

Yes.

> 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 Cole
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire