netatalk 4.0.8 (new formula)

[rdmark]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>? (see caveat below)

---

Please note that brew audit --new netatalk throws non-compliance as per the below. However, the native macOS berkeley-db and openldap libraries are both unusable: The former lacks required symbols, and the latter (represented by LDAP.Framework) isn't fork safe while netatalk is a forking application.

brew audit --new netatalk                                                  
netatalk
  * Dependency 'berkeley-db' is provided by macOS; please replace 'depends_on' with 'uses_from_macos'.
  * Dependency 'openldap' is provided by macOS; please replace 'depends_on' with 'uses_from_macos'.

[github-actions]

Thanks for contributing to Homebrew! 🎉 It looks like you're having trouble with a CI failure. See our contribution guide for help. You may be most interested in the section on dealing with CI failures. You can find the CI logs in the Checks tab of your pull request.

[rdmark]

The remaining CI failures are triggered by the brew audit checks, AFAICT.

As mentioned in the summary, complying with them and using the macOS supplied libraries will break the software. Can these CI failures be ignored?

[carlocab]

Thanks for the PR; a few comments.

[rdmark]

@carlocab Thanks for all your help! I'm pleased that we got it working in the end.

FYI, I had to force-push the branch again because one of the macOS CI runners got flaky and posted a failure. Seems to have been an intermittent connection issue with the runner machine. Hopefully we get a green slate this time...

Edit: All jobs passed this time!

[rdmark]

I figured out how to register the launchd / systemd services for netatalk. It basically works, if you invoke brew services with sudo. However I'm on the fence about whether it's worth adding or not, because brew services is clearly designed to be run as non-root, so I'm getting various warnings and errors.

diff --git a/Formula/n/netatalk.rb b/Formula/n/netatalk.rb
index 7258a9604f7..8fff22103e7 100644
--- a/Formula/n/netatalk.rb
+++ b/Formula/n/netatalk.rb
@@ -45,7 +45,8 @@ class Netatalk < Formula
       "-Dwith-appletalk=#{OS.linux?}", # macOS doesn't have an AppleTalk stack
       "-Dwith-bdb-path=#{Formula["berkeley-db@5"].opt_prefix}",
       "-Dwith-docbook-path=#{Formula["docbook-xsl"].opt_prefix}/docbook-xsl",
-      "-Dwith-init-style=none",
+      "-Dwith-init-dir=#{prefix}",
+      "-Dwith-init-hooks=false",
       "-Dwith-install-hooks=false",
       "-Dwith-pam-config-path=#{etc}/pam.d",
       "-Dwith-rpath=false",
@@ -57,6 +58,10 @@ class Netatalk < Formula
     system "meson", "install", "-C", "build"
   end
 
+  service do
+    name macos: "io.netatalk.daemon", linux: "netatalk"
+  end
+
   test do
     system sbin/"netatalk", "-V"
     system sbin/"afpd", "-V"

[SMillerDev]

There is a requires_root for the service block for exactly that.

[rdmark]

@SMillerDev Right on, that did the trick. Thanks!

[carlocab]

What do these service files look like? In particular, where do they send logs, and what working directory do they use?

[EricFromCanada]

• macOS: https://github.com/Netatalk/netatalk/blob/main/distrib/initscripts/macos.netatalk.plist.in
  • logs to /tmp/netatalk.out and /tmp/netatalk.err
• Linux: https://github.com/Netatalk/netatalk/blob/main/distrib/initscripts/systemd.netatalk.service.in

[carlocab]

We probably want to fix up some of those path references, since they'll likely be Cellar paths that aren't suitable for long-lived services

[rdmark]

@carlocab So you're arguing that the two /tmp paths for the macOS logs should be rewritten to start with #{prefix}, for instance /opt/homebrew/Cellar/netatalk/4.0.8/var/log ?

Or am I getting your comment backwards?

[rdmark]

On Linux, we log to journald by default, and not to a particular file.

The working directory is not controlled by the service files, but rather the build system. On aarch64 macOS, for instance, the working directory is /opt/homebrew/Cellar/netatalk/4.0.8/var/netatalk.

[rdmark]

All of the paths in plist, and the systemd unit file, are agnostic to the absolute path. The netatalkd file is just a helper script used by the plist (or can be used directly by users: sudo netatalkd start) that can be installed and reinstalled freely by brew.

However, thanks to this discussion I realized that it's critical to set a custom path for -Dwith-statedir-path which translates to /opt/homebrew/opt/netatalk/var or perhaps /opt/homebrew/var. This is where netatalk stores the CNID database which contains a structured representation of all the files in the shared volumes. This must be carried over when upgrading netatalk.

[rdmark]

Hm, never mind, I see now that there's a symlink in place that makes /opt/homebrew/opt/netatalk/var a stable path between installed versions.

[rdmark]

Actually strike that, I ran some empirical tests. With the current configuration, updating from one version to another will wipe the contents of /opt/homebrew/opt/netatalk/var, because it symlinks to f.e. /opt/homebrew/Cellar/netatalk/4.0.8/var which gets replaced in an upgrade.

What gets me the expected behavior is -Dwith-statedir-path=#{var} which stores the CNID database under /opt/homebrew/var/netatalk/CNID

[EricFromCanada]

I'd still suggest using the stable opt_bin path instead of the versioned path in the service files. See the inreplace directive in the batt formula for an example. Something like: inreplace "distrib/initscripts/macos.netatalk.plist.in", "@bindir@", opt_bin

[rdmark]

I do like these paths better. Now I've pushed this, plus the same substitution for the sbin dirs in all init scripts.

[EricFromCanada]

I've filed a PR to fix the launchd item not being able to stop the netatalk process: Netatalk/netatalk#1859

For now, I'd suggest adding a patch stanza to integrate the above fix, unless the next netatalk release is imminent.

Side note: what's it take to get its user authentication working in modern macOS? With the server running on Sonoma on M3 and logging enabled in afp.conf, clicking "Connect As…" on another Mac and entering my credentials just logs (info:ad): DHX2: PAM_Error: authentication error.

[rdmark]

@EricFromCanada Thanks for filing the PR. Let me follow up over there. The next stable netatalk release is about a week out.

Authentication should work out of the box on any host, as long as the Mac client is running Mac OS 8.6, 9.x, or any version of OSX / macOS. What OS is the client Mac running?

My first guess would be some kind of PAM library failure on Sonoma. Alternatively, you're using a password that the DHX2 UAM doesn't like for some reason. If you like, you can open up a Discussion thread over at the netatalk GitHub project and we can dig into it.