On 2022-11-29 at 06:54:50 UTC-0500 (Tue, 29 Nov 2022 12:54:50 +0100)
Gerben Wierda via macports-users <[email protected]>
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
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
