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

Tue, 29 Nov 2022 05:42:55 -0800

FWIW, I’ve had the opposite experience: migration away from macOS Server has provided a path to configure these service to be a lot more performant and reliable than the older and stagnant macOS Server versions.

And the reality that most/all of the mobile devices that use these services are iOS-based, it makes sense to just adapt to the latest macOS platform that can also be used to manage these devices.

All this stuff is configurable open source, and can just as easily be run on a Linux or BSD. The firewall and permissions approaches are different, especially if one uses SELinux or other locked down options. Running a server with multiple firewall layers requires troubleshooting facility with those layers on the platform. On BSD, that means pf, and on macOS it means pfctl, /usr/libexec/ApplicationFirewall/socketfilterfw if one uses the Application firewall, and some services controlled by MacPorts like clams requires enabling Full Disk Access for the MacPorts process "daemondo" in System Preferences> Security & Privacy> Full Disk Access. And any default macOS configurations that affect functionality or performance can be adjusted using the basic BSD sysctl and/or /etc/sysctl.conf settings.

If an application is blocked for some reason on any platform, one has walk back through the blockers: firewall, permissions, disk access, and figure out how to unblock them. Removing a redundant or unnecessary layer can facilitate this. For example, a macOS server running a locked-down pf firewall behind a router behind an ISP may not also need the macOS Application Firewall.

My own last step away from macOS Server is the automatically-generated PKI it provided. I swapped this out with a few bash scripts that create much faster EC-based PKI for things like an OpenVPN server, mail, and other services. Again migrating away from macOS Server using configurable open source made things better with a little elbow grease on the configuration side.

 
On Nov 29, 2022, at 06:55, Gerben Wierda via macports-users <macports-users@lists.macports.org> wrote:


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

The experience has been horrible. I had to turn off the application layer firewall on the server for instance. 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). 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.

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 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. Apple's new way of doing security is arguably stronger than the old way. 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.

The setup has become so unreliable that I do not dare to upgrade my current server beyond macOS 12.5.1, afraid as I am that the next update will kill even more, rendering my production setup effectively dead. 

I can't update my macOS anymore for fear that it kills what I cannot work without.

The key weak point in all of this seems to be the macOS Application Level Firewall which is iffy and especially iffy when it has to work with unsigned executables. But even when it is turned off, lots of other things that would normall work fine in a unix-like environment stop working, esppecially when you want to do 'server-like' stuff that requires open ports and sockets and such.

Sadly, this means that running a 'macOS Server substitute using MacPorts' is no longer feasible for me. I have started to move to a Linux setup and I hope my 'macOS Server' (which I have been running since it's start in some way or another, and OPENSTEP/NeXTSTEP before that) survives until I have that working properly.

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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to