Netatalk 2.4.0 released - TinkerDifferent

The Netatalk team is proud to present version 2.4.0 of the venerable AFP file sharing suite. Grab the source code, or a Docker image, today!

This version is primarily a future-proofing release, introducing the modern Meson build system, while integrating an embedded WolfSSL as the encryption provider for the DHX and RandNum user authentication modules.

To make a long story short, you can now run Netatalk 2 on any modern OS and still be able to authenticate securely with old Macs (and IIGSes).

It also ships with a range of bugfixes, documentation updates and quality-of-life improvements. See the release notes (linked above) for the full list of changes!

Additionally, a massively improved v2.0 of the Webmin module for easy administration has been released in parallel, with support for all features in Netatalk 2.4.0.

[Image: 1719129992718.png]

I'm looking forward to hearing your feedback!

Sweet! What's the easiest way to upgrade to this version of Netatalk on my PiSCSI?

To serve my ancient machines, I decided to downgrade my Pi 4 from the apt-installed Netatalk3 as follows:

remove Netatalk3
git clone Netatalk2.4
install required dependencies libgcrypt and Berkeley DB
build meson and
build Netatalk (per the vanilla INSTALL.md instructions).

This built fine but yielded no init-scripts for systemd. So I rebuilt with -Dwith-init-style=systemd. That gave an install that ran and was visible to clients .. but authenication always failed. With logging turned up to max, there were clues about exactly what was failing to authenticate.

At this point I trawled through the installation docs and noticed that I was missing a number of "optional" packages (including libcrack2-dev) for the Debian distribution which Pi uses.

So I built for a third time with all Debian dependences installed and with-init-style=systemd.

Third time was a charm!

I think Appendix A. Compile Netatalk from Source could do with a Raspberry Pi OS section.

>> Byte Knight said:

Sweet! What's the easiest way to upgrade to this version of Netatalk on my PiSCSI? Click to expand...

The easiest way? Wait until the next PiSCSI release. ;)

One trick you can do is to edit PiSCSI's easyinstall.sh and update the line that defines the netatalk version number. Should be in the function called `installNetatalk()'. It should just work. But let me know if you try it and run into weird errors.

>> speakers said:

To serve my ancient machines, I decided to downgrade my Pi 4 from the apt-installed Netatalk3 as follows: remove Netatalk3 git clone Netatalk2.4 install required dependencies libgcrypt and Berkeley DB build meson and build Netatalk (per the vanilla INSTALL.md instructions). This built fine but yielded no init-scripts for systemd. So I rebuilt with -Dwith-init-style=systemd. That gave an install that ran and was visible to clients .. but authenication always failed. With logging turned up to max, there were clues about exactly what was failing to authenticate. At this point I trawled through the installation docs and noticed that I was missing a number of "optional" packages (including libcrack2-dev) for the Debian distribution which Pi uses. So I built for a third time with all Debian dependences installed and with-init-style=systemd. Third time was a charm! I think Appendix A. Compile Netatalk from Source could do with a Raspberry Pi OS section. Click to expand...

Thanks for trying out netatalk, and for sharing your story! This is a valuable "newcomer" perspective that helps us continuously improve. Good job unblocking yourself.

Do you remember exactly what the log messages said? And the full list of packages you installed to make it work?

If libcrack was mandatory to make auth work then we have a bug somewhere. It should be a highly optional library that is only used by the Random Number UAM.

To my best knowledge, installation instructions for RPi OS would look exactly the same as for Debian, for the same base OS version (e.g. v12 Bookworm). Were there any special steps you needed to take on RPi OS?

And finally, an improvement to the build system is being developed as we speak that will attempt to auto detect the appropriate init script, so in the next release there will be one less thing that can go wrong. :)

>> rdmark said:

Do you remember exactly what the log messages said? Click to expand...

Dedging the log, I saw sequences like this:

Jun 23 19:34:29.946265 afpd[10829] {logger.c:405} (D5:Logger): Setup file logging: type: Default, level: LOG_MAXDEBUG, file: /var/log/afpd.log
Jun 23 19:34:35.952955 afpd[10829] {afp_config.c:302} (I:AFPDaemon): pi:AFPServer@* started on 65280.81:129 (2.4.0)
Jun 23 19:34:35.953172 afpd[10829] {status.c:722} (I:AFPDaemon): "pi"'s signature is 2D862E55519990267922C6784565E7D5
Jun 23 19:34:35.958999 afpd[10829] {afp_config.c:342} (D5:AFPDaemon): DSIConfigInit: hostname: pi, ip/port: default/548,
Jun 23 19:34:35.959495 afpd[10829] {dsi_tcp.c:335} (I:DSI): dsi_tcp_init: bind: Address already in use

Jun 23 19:34:35.959597 afpd[10829] {dsi_tcp.c:335} (I:DSI): dsi_tcp_init: bind: Address already in use

Jun 23 19:34:35.959621 afpd[10829] {dsi_tcp.c:349} (E:DSI): dsi_tcp_init: no suitable network config for TCP socket
Jun 23 19:34:35.959653 afpd[10829] {afp_config.c:351} (E:AFPDaemon): main: dsi_init: Address already in use
Jun 23 19:34:35.959679 afpd[10829] {auth.c:1094} (D5:AFPDaemon): uam: loading (/usr/local/lib/arm-linux-gnueabihf/netatalk/uams_dhx.so)
Jun 23 19:34:35.959734 afpd[10829] {auth.c:1101} (D5:AFPDaemon): uam: uams_dhx.so loaded
Jun 23 19:34:35.959758 afpd[10829] {auth.c:1094} (D5:AFPDaemon): uam: loading (/usr/local/lib/arm-linux-gnueabihf/netatalk/uams_dhx2.so)
Jun 23 19:34:35.959795 afpd[10829] {auth.c:1101} (D5:AFPDaemon): uam: uams_dhx2.so loaded
Jun 23 19:34:35.959831 afpd[10829] {auth.c:116} (I:AFPDaemon): uam: "DHX2" available
Jun 23 19:34:35.959856 afpd[10829] {auth.c:116} (I:AFPDaemon): uam: "DHCAST128" available
Jun 23 19:34:35.959892 afpd[10829] {afp_config.c:578} (D5:AFPDaemon): Finished parsing Config File

...

Jun 23 19:38:25.707815 afpd[10891] {afp_dsi.c:598} (D5:DSI): DSI request ID: 2
Jun 23 19:38:25.707863 afpd[10891] {afp_dsi.c:613} (D5:AFPDaemon): <== Start AFP command: AFP_LOGIN_EXT
Jun 23 19:38:25.708625 afpd[10891] {uams_dhx2_passwd.c:269} (I:UAMS): DHX2 login: cp
Jun 23 19:38:26.984289 afpd[10891] {afp_dsi.c:619} (D5:AFPDaemon): ==> Finished AFP command: AFP_LOGIN_EXT -> AFPERR_AUTHCONT

>> rdmark said:

And the full list of packages you installed to make it work? Click to expand...

Here's the entire apt history:

Start-Date: 2024-06-23  10:22:17
Commandline: apt-get remove netatalk
Requested-By: cp (1000)
Remove: netatalk:armhf (3.1.12~ds-8)
End-Date: 2024-06-23  10:22:23

Start-Date: 2024-06-23  10:38:03
Commandline: apt-get install meson
Requested-By: cp (1000)
Install: meson:armhf (1.0.0-1.1~bpo11+1~rpt1), ninja-build:armhf (1.10.1-1, automatic)
End-Date: 2024-06-23  10:38:07

Start-Date: 2024-06-23  10:48:04
Commandline: apt-get install libdb-dev
Requested-By: cp (1000)
Install: libdb-dev:armhf (5.3.1+nmu1+b1), libdb5.3-dev:armhf (5.3.28+dfsg1-0.8, automatic)
End-Date: 2024-06-23  10:48:05

Start-Date: 2024-06-23  10:50:13
Commandline: apt-get install libevent-dev
Requested-By: cp (1000)
Install: libevent-pthreads-2.1-7:armhf (2.1.12-stable-1, automatic), libevent-extra-2.1-7:armhf (2.1.12-stable-1, automatic), libevent-openssl-2.1-7:armhf (2.1.12-stable-1, automatic), libevent-core-2.1-7:armhf (2.1.12-stable-1, automatic), libevent-dev:armhf (2.1.12-stable-1)
End-Date: 2024-06-23  10:50:16

Start-Date: 2024-06-23  10:51:14
Commandline: apt-get install libgcrypt-dev
Requested-By: cp (1000)
Install: libgcrypt20-dev:armhf (1.8.7-6), libgpg-error-dev:armhf (1.38-2, automatic)
End-Date: 2024-06-23  10:51:16

Start-Date: 2024-06-23  16:40:33
Commandline: apt-get install xsltproc docbook-xsl
Requested-By: cp (1000)
Install: xsltproc:armhf (1.1.34-4+deb11u1), docbook-xml:armhf (4.5-9, automatic), docbook-xsl:armhf (1.79.2+dfsg-1), sgml-data:armhf (2.0.11+nmu1, automatic)
End-Date: 2024-06-23  16:40:45

Start-Date: 2024-06-23  20:00:31
Commandline: apt-get install libcrack2-dev
Requested-By: cp (1000)
Install: libcrack2-dev:armhf (2.9.6-3.4)
End-Date: 2024-06-23  20:00:33

Start-Date: 2024-06-23  20:16:07
Commandline: apt install autoconf automake docbook-xsl libacl1-dev libavahi-client-dev libcrack2-dev libcups2-dev libdb-dev libgcrypt-dev libkrb5-dev libldap2-dev libltdl-dev libpam0g-dev libssl-dev libtirpc-dev libtool libtool-bin libwrap0-dev quota tcpd xsltproc
Requested-By: cp (1000)
Install: libavahi-common-dev:armhf (0.8-5+deb11u2, automatic), libcups2-dev:armhf (2.3.3op2-3+deb11u6), libpam0g-dev:armhf (1.4.0-9+deb11u1+rpt2), libattr1-dev:armhf (1:2.4.48-6, automatic), libkrb5-dev:armhf (1.18.3-6+deb11u4), libjpeg-dev:armhf (1:2.0.6-4, automatic), libjpeg62-turbo-dev:armhf (1:2.0.6-4, automatic), libtool-bin:armhf (2.4.6-15), libkadm5srv-mit12:armhf (1.18.3-6+deb11u4, automatic), automake:armhf (1:1.16.3-2), libtiffxx5:armhf (4.2.0-1+deb11u5, automatic), libjbig-dev:armhf (2.1-3.1+b2, automatic), liblzma-dev:armhf (5.2.5-2.1~deb11u1, automatic), libltdl-dev:armhf (2.4.6-15), comerr-dev:armhf (2.1-1.46.2-2, automatic), autoconf:armhf (2.69-14), libdeflate-dev:armhf (1.7-1, automatic), libssl-dev:armhf (1.1.1w-0+deb11u1+rpt1), autotools-dev:armhf (20180224.1+nmu1, automatic), libcupsfilters-dev:armhf (1.28.7-1+deb11u2, automatic), libkdb5-10:armhf (1.18.3-6+deb11u4, automatic), libtool:armhf (2.4.6-15), libavahi-client-dev:armhf (0.8-5+deb11u2), krb5-multidev:armhf (1.18.3-6+deb11u4, automatic), libacl1-dev:armhf (2.2.53-10), libldap2-dev:armhf (2.4.57+dfsg-3+deb11u1), m4:armhf (1.4.18-5, automatic), tcpd:armhf (7.6.q-31), libtiff-dev:armhf (4.2.0-1+deb11u5, automatic), libgssrpc4:armhf (1.18.3-6+deb11u4, automatic), quota:armhf (4.06-1), libwrap0-dev:armhf (7.6.q-31), libkadm5clnt-mit12:armhf (1.18.3-6+deb11u4, automatic), libcupsimage2-dev:armhf (2.3.3op2-3+deb11u6, automatic)
Upgrade: libcups2:armhf (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u6), libgssapi-krb5-2:armhf (1.18.3-6+deb11u2, 1.18.3-6+deb11u4), cups-common:armhf (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u6), libavahi-common-data:armhf (0.8-5+deb11u1, 0.8-5+deb11u2), libavahi-core7:armhf (0.8-5+deb11u1, 0.8-5+deb11u2), cups-client:armhf (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u6), cups-daemon:armhf (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u6), libtiff5:armhf (4.2.0-1+deb11u1, 4.2.0-1+deb11u5), avahi-daemon:armhf (0.8-5+deb11u1, 0.8-5+deb11u2), libkrb5support0:armhf (1.18.3-6+deb11u2, 1.18.3-6+deb11u4), cups-ipp-utils:armhf (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u6), libkrb5-3:armhf (1.18.3-6+deb11u2, 1.18.3-6+deb11u4), libk5crypto3:armhf (1.18.3-6+deb11u2, 1.18.3-6+deb11u4), libcupsimage2:armhf (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u6), libavahi-common3:armhf (0.8-5+deb11u1, 0.8-5+deb11u2), libssl1.1:armhf (1.1.1n-0+deb11u3+rpt1, 1.1.1w-0+deb11u1+rpt1), cups-core-drivers:armhf (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u6), libavahi-glib1:armhf (0.8-5+deb11u1, 0.8-5+deb11u2), cups:armhf (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u6), cups-server-common:armhf (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u6), libavahi-client3:armhf (0.8-5+deb11u1, 0.8-5+deb11u2), libcupsfilters1:armhf (1.28.7-1+deb11u1, 1.28.7-1+deb11u2)
End-Date: 2024-06-23  20:16:58

>> rdmark said:

If libcrack was mandatory to make auth work then we have a bug somewhere. It should be a highly optional library that is only used by the Random Number UAM. To my best knowledge, installation instructions for RPi OS would look exactly the same as for Debian, for the same base OS version (e.g. v12 Bookworm). Were there any special steps you needed to take on RPi OS? Click to expand...

Nope. This was a a vanilla install using the Imager.

$ uname -a
Linux pi 5.15.61-v7l+ #1579 SMP Fri Aug 26 11:13:03 BST 2022 armv7l GNU/Linux

>> rdmark said:

And finally, an improvement to the build system is being developed as we speak that will attempt to auto detect the appropriate init script, so in the next release there will be one less thing that can go wrong. Click to expand...

Cool :cool:

Netatalk 2.4.1 has been released today!

It contains a patch for a published CVE vulnerability, so it's recommended to upgrade your 2.x deployment, especially if serves a public IP.

We also restore support for SLP (Server Location Protocol) in the Meson build system, for those who you like to network your OSX 10.1 or 10.2 machines. :)

Continuing the saga of old-school encryption in Netatalk, we released version 2.4.2 today which addresses a licensing issue raised by the Debian project. As a result, we have reverted to relying on OpenSSL/LibreSSL with the bundled SSL provider... for the CAST algorithm only.

This is only a concern for redistribution, as we have been told, so it doesn't hinder distribution (as in: the Netatalk project distributing its own package, or private use by end users) but if you're redistributing a binary package of Netatalk in, say, a Linux distro, then upgrading to 2.4.2 is mandatory, as it were...

But IANAL; the above is just what laypersons are telling other laypersons about legal things. I'm definitely glad that we could jettison the code with iffy licensing terms, so I think it's a change for the better. My collaborator is looking into potentially using libnettle for our crypto needs, and bail on the OpenSSL ecosystem once and for all. I can't wait!

Additionally, the release includes a bunch of build system fixes for specific platforms and use cases.

What do you guys think about incorporating MacIP routing and NAT, at least an option?

I haven't done macipgw stuff, but I'm thinking that for the Guide, I probably should, but that's when I noticed it hasn't been updated in 9 years.

How do you imagine macipgw could be best incorporated with netatalk? What is the drawback of the current situation where macipgw is its own project that you can install and run if you need it? How would the user experience improve if the two projects were more closely integrated?

I'm genuinely curious to get your perspective on this... macipgw has been on my radar for a long time but I've yet to actually use it.

>> rdmark said:

How do you imagine macipgw could be best incorporated with netatalk? Click to expand...

I'm a user. My opinion probably counts for less than useless. Incorporation could be one .conf file that is edited, or using the webmin tool, another page.

What is the drawback of the current situation where macipgw is its own project that you can install and run if you need it? Click to expand...

You'd be reusing an AppleTalk stack you already have and is being actively maintained by some devout people, who as far as I can tell, know it pretty well and would be the best men for the job.

How would the user experience improve if the two projects were more closely integrated? Click to expand...

Anybody who is doing AFP2.1 and earlier could benefit from it in a TCP world. Odds are pretty good even if you didn't use it, it's a nice perk. Incorporating Web Rendering Proxy is probably too much though, i wouldn't do that. But the whole 9 years thing is getting me slightly worried, but probably for the wrong reasons.

And odds are pretty decent if you are using netatalk to serve files and stuff to your Macintosh Plus, having TCP so readily accessible for FTP is just so ... good.

>> Mk.558 said:

I'm a user. My opinion probably counts for less than useless. Incorporation could be one .conf file that is edited, or using the webmin tool, another page. You'd be reusing an AppleTalk stack you already have and is being actively maintained by some devout people, who as far as I can tell, know it pretty well and would be the best men for the job. Anybody who is doing AFP2.1 and earlier could benefit from it in a TCP world. Odds are pretty good even if you didn't use it, it's a nice perk. Incorporating Web Rendering Proxy is probably too much though, i wouldn't do that. But the whole 9 years thing is getting me slightly worried, but probably for the wrong reasons. And odds are pretty decent if you are using netatalk to serve files and stuff to your Macintosh Plus, having TCP so readily accessible for FTP is just so ... good. Click to expand...

From my perspective, your opinion as a user is the most valuable of all. :)

I agree that macipgw not being updated for 9 years is worrying. It's unlikely to build cleanly on modern systems anymore.

There are pros and cons to integrating macipgw into netatalk proper. Some practical concerns include the compatibility of licensing terms, security, maintenance overhead, as well as the idea of making the netatalk2 package even more monolithic and sprawling than it already is.

That said, I'm personally invested in rescuing vintage open source projects, so regardless of the final shape, I would like to try to do something! At the very least, I can fork the GitHub project in my personal namespace and freshen it up.

If you want to help us out, I would appreciate a ticket over at the netatalk GitHub project where you break down the details of your request.

Thank you!

If anyone wants to lean in, the ticket is https://github.com/Netatalk/netatalk/issues/1204

Version 2.4.3 is out now. This is mainly a Meson build system feature and bugfix release, as part of my effort to deliver Debian deb packaging of Netatalk. It fixes fun stuff such as Kerberos API checks, 64 bit architecture detection, library runpaths, pkgconfdir overrides, and support for installing multiple init styles. (Debian is weird that is encourages packages to supply old-school SysV init scripts, but the init.d backend is actually just systemd under the hood AFAICT.)

If you don't care about any of the above, there's no rush to upgrade!

Anyone get this working on Sonoma? Is the config in the launch daemon or in specific places? The docs don't say where the config files like afpd.conf actually go. etc? etc/netatalk? A step by step guide to macOS installation with a shared guest folder would be handy to get started understanding how this works on macOS.

>> Slimes said:

% afpd -V
afpd 2.4.3 - Apple Filing Protocol (AFP) daemon of Netatalk

This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version. Please see the file COPYING for further information and details.

afpd has been compiled with support for these features:

          AFP versions:    1.1 2.0 2.1 2.2 3.0 3.1 3.2 3.3
DDP(AppleTalk) Support:    Yes
         CNID backends:    dbd last
           SLP support:    No
      Zeroconf support:    mDNSResponder
  TCP wrappers support:    No
         Quota support:    Yes
   Admin group support:    Yes
    Valid shell checks:    Yes
      cracklib support:    No
            EA support:    ad|sys
           ACL support:    No
          LDAP support:    Yes

             afpd.conf:    /usr/local/etc/afpd.conf
   AppleVolumes.system:    /usr/local/etc/AppleVolumes.system
  AppleVolumes.default:    /usr/local/etc/AppleVolumes.default
    afp_signature.conf:    /usr/local/etc/afp_signature.conf
      afp_voluuid.conf:    /usr/local/etc/afp_voluuid.conf
         afp_ldap.conf:    /usr/local/etc/afp_ldap.conf
       UAM search path:    /usr/local/lib/netatalk/
  Server messages path:    /var/local/netatalk/msg/
              lockfile:    /var/run/afpd

The shared volumes are defined in AppleVolumes.default using a very simple syntax...

/path/to/dir "My Volume"

Create that dir somewhere on your file system and give it appropriate permissions. In the default configuration, the system users will be able to authenticate.

What kinds of Mac clients do you plan to connect to this AFP server?

>> rdmark said:

The location of the config files depends on how the software was installed, so it's not something that can be explicitly documented in the manual. The most sure way to know is to ask netatalk directly. If you have installed netatalk 2.x, run afpd -V . This is an example from my Sonoma MBA: Code: % afpd -V afpd 2.4.3 - Apple Filing Protocol (AFP) daemon of Netatalk This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Please see the file COPYING for further information and details. afpd has been compiled with support for these features: AFP versions: 1.1 2.0 2.1 2.2 3.0 3.1 3.2 3.3 DDP(AppleTalk) Support: Yes CNID backends: dbd last SLP support: No Zeroconf support: mDNSResponder TCP wrappers support: No Quota support: Yes Admin group support: Yes Valid shell checks: Yes cracklib support: No EA support: ad|sys ACL support: No LDAP support: Yes afpd.conf: /usr/local/etc/afpd.conf AppleVolumes.system: /usr/local/etc/AppleVolumes.system AppleVolumes.default: /usr/local/etc/AppleVolumes.default afp_signature.conf: /usr/local/etc/afp_signature.conf afp_voluuid.conf: /usr/local/etc/afp_voluuid.conf afp_ldap.conf: /usr/local/etc/afp_ldap.conf UAM search path: /usr/local/lib/netatalk/ Server messages path: /var/local/netatalk/msg/ lockfile: /var/run/afpd The shared volumes are defined in AppleVolumes.default using a very simple syntax... Code: /path/to/dir "My Volume" Create that dir somewhere on your file system and give it appropriate permissions. In the default configuration, the system users will be able to authenticate. What kinds of Mac clients do you plan to connect to this AFP server? Click to expand...

Mac OS 9 clients. This should give me enough to go on now. Thanks.

Does afpd respect resource and data forks on modern macOS?

>> Slimes said:

Mac OS 9 clients. This should give me enough to go on now. Thanks. Does afpd respect resource and data forks on modern macOS? Click to expand...

Netatalk 2.x's afpd is not aware of macOS / OSX filesystem EA (Extended Attributes). It stores filesystem metadata in the legacy AppleDouble v2 format by default, which are binary metadata files living in dot-folders. This article is a good introduction: https://netatalk.io/docs/Special-Files-and-Folders

If you want better macOS host interoperability, I recommend running Netatalk 3.x, which does store all metadata as filesystem EA on the host machine. Dunno exactly how compliant it is with APFS specifications... but it works. :)

BTW, this is all transparent to the client. The clients don't really care what format the metadata is stored in on the host.

Netatalk 2.4.4 is available. This is yet again a build system bugfix release, working towards stabilizing Debian deb packaging. If Netatalk is working fine for you, take this is an optional upgrade.

At this point, I consider the current Netatalk release series (2.4.x, 3.2.x) stable and "done".

This project is finally in a good place where we have a modern and flexible build system, with fully functioning user authentication. I can finally pivot to what I wanted to do in the first place: consolidate the best of 2.x and 3.x into one Mac file sharing suite to rule them all, so stay tuned...