Yet Another Netatalk 2.2 Fork

[rdmark]

TL;DR; There is a new fork called Netatalk 2.x that integrates all the community patches since the 2.2.6 release, which works out of the box on modern distros. Grab the latest stable release from GitHub.

While researching Netatalk integration with RaSCSI it struck me just how painful it was to get Netatalk 2.2 working well on a modern Linux distro. For those who are unaware, Netatalk 3.x dropped support for the AppleTalk / DDP protocol in favor of TCP/IP. For us who want to use Netatalk with really quite old Macs (and Apple //e & //gs) Netatalk 2.2 is mandatory. Unfortunately, Netatalk 2.2.6 (which was the last one in the 2.x series) no longer compiles out of the box on modern systems. In addition, there is an outstanding bug that frequently causes it to fail to run on Linux with an error in setifaddr.

As a matter of fact, in the 5 years since the release of Netatalk 2.2.6 an impressive number of forks and projects with their own downstream patchset to keep Netatalk running have emerged. Here are a few of the major ones that I encountered:

• A2SERVER
• MacIP
• AFPBridge
• NetBSD netatalk22 package
• netatalk-classic fork

All this fragmentation seemed like a huge missed opportunity to me. After a few months of gathering patches and testing, I'm ready to share with you all Netatalk 2.x, the latest and greatest among Netatalk forks!

The way I approached the development process, was to work in relatively atomic PRs against the mainline branch-netatalk-2-2. For one, it gives the community insight into each and every change that has gone into this fork, and secondly, it is keeping the flame and hope alive that we one day can get a mainline Netatalk 2.2.7 (or maybe even 2.3.0) release! As such, you may leverage Netatalk PRs on GitHub as the changelog.

A high level summary:

• All daemons can run as systemd services. Use the --enable-systemd configure option.
• Printer server: Better compatibility with Apple LaserWriter 7 and 8 drivers on Mac OS and GS/OS (special thanks to NJRoadfan and the A2SERVER team!)
• Printer server: Added spooler responses to avoid timeouts when printing over slow networks.
• The Timelord daemon can now run on modern systems; added support for time zones. (special thanks to cheesestraws for the patch!)
• Apple II: Better compatibility with Asante and Dayna network bridges
• Apple II: Retain folder dates when copying on GS/OS
• Support both Linux and NetBSD FIRSTNET behavior, which caused errors like "setifaddr: eth0 (1-65534): Invalid argument. try specifying a smaller net range"
• Add support for OpenSSL 1.1, while retaining backwards compatibility with OpenSSL 1.0
• Make it possible to compile with LDAP support
• Make it possible to disable AppleTalk session tickles/timeout.
• Resolved a large number of autoconf bootstrap and compiler warnings and errors (gcc 10)

If you want to play around with it, please simply clone the repo and check out the branch-netatalk-2-x branch.

All AppleTalk bells and whistles are now enabled by default. Example configuration:

./configure --enable-systemd --sysconfdir=/etc --with-uams-path=/usr/lib/netatalk

Afterwards, a 'make install' will install and enable the systemd services, and you can start the 'atalkd' and 'afpd' services. The papd, timelord, and a2boot services are optional and only for those who need printer server, time server, and Apple II netboot functionality, respectively.

I'd love to get feedback and bug reports, if you run into anything! I'm a total noob when it comes to AFP (and C programming) so I may very well have made plenty mistakes!

 

[fehervaria]

Wow!

Silly question, but i am fighting with Netatalk 3.x and AppleTalk few weeks as well on one of my Raspberry Pi...
So the questions: does it work with the latest "Bullseye" version?
How about the AppleTalk kernel module? Is it included as well?

I'm asking these questions because I reinstalled my Pi more often than any other computers usually, and finally I would like to "go for sure" and I'd prefer a totaly clean install...

---
#PPCChallenge
Written on an iBook G4 1.42 with 1.5GB RAM, MacOS 10.5.9, InterWebPPC 45.41.6

 

[rdmark]

@fehervaria Yes, my primary environment is Raspbian Bullseye, so I can vouch for this particular version of the OS. So far, every version of Raspbian I have tested comes with the appletalk kernel module out of the box. If your distro doesn't come with the appletalk module, you can easily recompile the kernel to get it.

Pro tip: In general the configure script is good at telling you which dependencies to install, but when it comes to the Berkley DB dependency the apt package you need is called "libdb-dev".

Good luck!

 

[Melkhior]

I had tried to talk to my netatalk 3.x shares with my Q650, but could'nt get it to work. I fell back on Dave & SMB but writing from the Q650 to the Linux PC wasn't reliable.
I tried your fork, and eventually did manage to get a working AppleTalk share between the Q650 and a Debian Buster machine with no issue at compile time, only needed to figure out the configuration - mostly on the Mac itself ;-) I'm using Debian's init system rather than systemd as I can segregate all the installed files in the same directory more easily.
Thanks! This will make sharing files with the Q650 much easier.

 

[benfranske]

I just so happen need to get Netatalk running again...the last time I needed it I could still get the 2.2 version pre-built. My Linux build skills leave something to be desired but I think I'm sort of bumbling my way through it... It would be awesome to get some better build directions.

In particular a list of dependencies (looks like libdb-dev at least), and the method to create the configure script and makefile (looks like autoconf/automake? ) would be super helpful.

Even bigger on my wishlist would be a CI/CD system that churned out dpkg files for amd64 Debian and Raspbian

 

[rdmark]

@benfranske Have you read through the Netatalk 2.2 documentation that covers installation already? It should cover the basics. I wrote some supplemental steps in the RaSCSI wiki for setting up Netatalk to run on a Raspberry Pi, which can serve as general-purpose instructions as well. The latter has a list of apt dependencies while expecting that you already have the dependencies for RaSCSI installed...

The general flow is that you run the bootstrap script first, then the configure script, then make followed by make install. Presto! Netatalk installed.

 

[benfranske]

Mea culpa for not finding the old official 2.2 docs with that information. I'm too used to directions in readme files I guess.

 

[rdmark]

It's always a fine line to walk: providing enough context to enable people to get started, while not duplicating upstream documentation. In fairness, the README on github did already have a link to the documenation at the very bottom.

Anyhow, I added an Installation section to my README that more specifically point to the Installation section of the official documentation, while offering a few supplementary tidbits. Hope this helps!

 

[shascall]

Is there any value to trying this out on Mac OS X or is this geared towards OS’s with ddp support?

I recently compiled NetBSD’s 2.2.6 on a Mojave system after digging my college-era 7100 out of the closet over the holidays. Not sure I should even be using 2.2.x though.

 

[benfranske]

Is there any value to trying this out on Mac OS X or is this geared towards OS’s with ddp support?

I recently compiled NetBSD’s 2.2.6 on a Mojave system after digging my college-era 7100 out of the closet over the holidays. Not sure I should even be using 2.2.x though.

I think, though I will let others chime in that an Appletalk kernel module is required so I don't think it would work. Truthfully with plentiful RAM and free VMs these days it's so easy to spin up a VM that I wouldn't bother running it on anything other than Linux.

I do wonder though, given some of the rot in the kernel Appletalk code if it makes sense to keep it that way indefinitely or if eventually building a standalone DDP serving application, focused on pre-OS X systems would be easier than maintaining netatalk. Just an open thought.

 

[rdmark]

Is there any value to trying this out on Mac OS X or is this geared towards OS’s with ddp support?

I recently compiled NetBSD’s 2.2.6 on a Mojave system after digging my college-era 7100 out of the closet over the holidays. Not sure I should even be using 2.2.x though.

The whole point with using Netatalk 2.2 is for the DDP support, plus the printer server, time server, and Apple II netboot server that also run on DDP. If you're content with DSI (TCP/IP) the mainline Netatalk 3.1 is a better choice, IMHO. And if you want to run it on M1 or Intel Macs, I've found this fork that can be installed with homebrew, although I haven't tested it myself.

NetBSD's 2.2.6 package is probably one of the best, if not the best, maintained Netatalk 2.2 package out there. In fact, I sourced a large chunk of my patches from their package repository. What you get from using 2.2.x over NetBSD 2.2.6 are mainly: A more functional Timelord, a papd printer server with better compatibility with old LaserWriter drivers, and the ability to run everything as systemd services out of the box.

 

[rdmark]

I think, though I will let others chime in that an Appletalk kernel module is required so I don't think it would work. Truthfully with plentiful RAM and free VMs these days it's so easy to spin up a VM that I wouldn't bother running it on anything other than Linux.

I do wonder though, given some of the rot in the kernel Appletalk code if it makes sense to keep it that way indefinitely or if eventually building a standalone DDP serving application, focused on pre-OS X systems would be easier than maintaining netatalk. Just an open thought.

I'm curious if you're aware of any outstanding appletalk Linux kernel module rot at the moment? As I understand it, the whole debacle stared with a string of patches originating from a Huawei engineer, that were accepted into the Linux kernel in early 2019 despite effectively breaking the appletalk module. Then it took over a year for a fix to be accepted. I don't think this was a software problem, but rather a process problem.

I'd still be curious to learn more what you were thinking there regarding a standalone DDP solution that runs in userland. Were you imagining something like encapsulation of AppleTalk packages in TCP? (...which Netatalk already supports actually. )

 

[shascall]

The whole point with using Netatalk 2.2 is for the DDP support, plus the printer server, time server, and Apple II netboot server that also run on DDP. If you're content with DSI (TCP/IP) the mainline Netatalk 3.1 is a better choice, IMHO. And if you want to run it on M1 or Intel Macs, I've found this fork that can be installed with homebrew, although I haven't tested it myself.

NetBSD's 2.2.6 package is probably one of the best, if not the best, maintained Netatalk 2.2 package out there. In fact, I sourced a large chunk of my patches from their package repository. What you get from using 2.2.x over NetBSD 2.2.6 are mainly: A more functional Timelord, a papd printer server with better compatibility with old LaserWriter drivers, and the ability to run everything as systemd services out of the box.

Thanks for the straight answer. Yes, afpd over ip works alright, which is what I needed for starters. I figured 2.2.x would be easier to get going, but I’ll give 3.1 a try. The user space or kernel bypass ddp idea benfranske mentioned sounds intriguing. I’m not a network guy, but that sounds like a good fit for Apple's Network.framework.

 

[benfranske]

I'm curious if you're aware of any outstanding appletalk Linux kernel module rot at the moment? As I understand it, the whole debacle stared with a string of patches originating from a Huawei engineer, that were accepted into the Linux kernel in early 2019 despite effectively breaking the appletalk module. Then it took over a year for a fix to be accepted. I don't think this was a software problem, but rather a process problem.

No, I've heard concerns about it in the past though. It does seem like something bound to be cut at some point in the future though as it's a very niche thing. It just seems unwise to rely on it being there and working indefinitely.

I'd still be curious to learn more what you were thinking there regarding a standalone DDP solution that runs in userland. Were you imagining something like encapsulation of AppleTalk packages in TCP? (...which Netatalk already supports actually. )

Couldn't such a DDP server be written? I wasn't thinking of encapsulating in TCP but building and sending DDP packets directly from the server application. It seems like such a thing should be possible using AF_PACKET (possibly in combination with libpcap) which, to the best of my understanding, allows for sending and receiving raw Ethernet frames.

 

[rdmark]

Thanks to the continued contributions by various community members, more patches are gradually being merged into this fork. If you checked out branch-netatalk-2-2-x a few weeks ago, I'd encourage you to pull the latest code and try it out! There may be bugs lurking, so please report back if you run into issues.

Since the changeset was getting fairly substantial at this point, I drafted tentative release notes in the NEWS file. As a bonus, I also retroactively summarized the 2.2.6 release notes, which were actually never written to my best knowledge.

One neat feature of Netatalk 2.2.x that I discovered fairly recently, is a fully functioning service discovery / zeroconf / Bonjour implementation. I knew of this from earlier, but wasn't able to get it to work at the time. If you configure Netatalk with '--enable-zeroconf', and have libavahi installed, Mac OS X / macOS will detect the AFP server in the Network browser. This works at least in Tiger, Big Sur, and Monterey that I've tested. So you may actually have an AFP file share running that something as old as System Software 6.0.7 and as new as Monterey both can connect to and get files off of!

The caveat is that, to my best knowledge, you can't have a chain of authentication methods that both systems are able to use simultaneously for write access. So what I have here, for instance, is uams_randum.so for System 6, with a fallback to uams_guest.so for Monterey (read-only.) If someone knows of a way to configure a series of authentication methods that allow both full access, please do share with us!

 

[pfuentes69]

Hi @rdmark

Do you plan to update the Netatalk setup which comes with the RASCSI? I'm using it and it was really practical, but I can only connect as guest from a modern Mac, as I couldn't figure out how to setup an authentication protocol that is accepted (if that's even possible)

Edit - I managed to get guest write access with the ugly technique of reassigning the guest account to a privileged unix user, but I'd prefer if possible having a better approach...

Txs!

 

[rdmark]

Hi @rdmark

Do you plan to update the Netatalk setup which comes with the RASCSI? I'm using it and it was really practical, but I can only connect as guest from a modern Mac, as I couldn't figure out how to setup an authentication protocol that is accepted (if that's even possible)

Edit - I managed to get guest write access with the ugly technique of reassigning the guest account to a privileged unix user, but I'd prefer if possible having a better approach...

Txs!

It's encouraging to hear that the Netatalk install script was helpful to you!

Yes, the plan is to cut a release from this fork at some point in the not too distant future, and then update the RaSCSI script to make use of it. However, I still haven't given up hope on getting the important patches accepted by Netatalk maintainers and lobby them to cut an upstream release of Netatalk 2 at some point.

And actually, just moments ago I was able to configure my Netatalk setup in a way that allows you to get write access from any Mac OS version (with AFP support.) The missing piece to authenticate with Big Sur / Monterey etc. was the DHX2 UAM. Thanks to a very valuable tip from NJRoadfan, I learned that the DHX UAM is actually broken when used on a Raspberry Pi, so for one you need to remove that from afpd.conf. Secondly, I realized that you need to install the libgcrypt20-dev package in Raspbian in order for Netatalk to configure and compile the DHX2 UAM for you.

Once you have the DHX2 UAM, configure afpd.conf to use it, restart afpd and you should be good to go! I updated the RaSCSI wiki page for AFP with this information.

 

[rdmark]

I'm glad to announce the first tagged release of this Netatalk fork! A broader group of people have tested it for a good few weeks now, and code changes have been minor recently, so I think this is as good a time as any to cut a "stable" release as a baseline for further development.

Find the release notes and tarballs at: https://github.com/rdmark/Netatalk-2.x/releases/tag/netatalk-2-220101

As I was compiling the release notes, I thought the sheer amount of changes warranted a bit of a larger version number bump. It's no longer a simple hotfix release for 2.2.6. Therefore, I decided to give the fork a new name: "Netatalk 2.x"

 

[Eric's Edge]

This is so awesome! Thank you!
I tried several times to get earlier releases to work and gave up.

 

[Byte Knight]

Yes, this is freaking awesome! I got my vintage Macs printing to my modern Brother laser printer and color Canon inkjet printer with minimal effort. Fantastic job!