@slipperygrey Did you ever get to the bottom of this error? I'm seeing the same thing when building on Ubuntu 18.04.
Yet Another Netatalk 2.2 Fork
- Thread starter slipperygrey
- Start date
slipperygrey
Well-known member
@shirsch No, we did some high level troubleshooting but couldn't figure out at what stage in the bootstrap and configuration process that incompatible makefiles gets generated. There's some change deep in the Autotools toolchain over the last few years that broke backwards compatibility.
If you have a moment to help troubleshooting, can you please try the upstream HEAD of branch-netatalk-2-2? In the upstream code, we've only done the bare minimum of fixes to get it compiling and running on modern systems, whereas in my fork we've been more proactive about resolving autoconf deprecation warnings and bringing the codebase up to date. This may very well have broken compatibility with very old environments.
And in the long run, would you consider upgrading to a more recent OS version? Your Ubuntu release there is over 4 years old, which is an eon in the Linux world.
If you have a moment to help troubleshooting, can you please try the upstream HEAD of branch-netatalk-2-2? In the upstream code, we've only done the bare minimum of fixes to get it compiling and running on modern systems, whereas in my fork we've been more proactive about resolving autoconf deprecation warnings and bringing the codebase up to date. This may very well have broken compatibility with very old environments.
And in the long run, would you consider upgrading to a more recent OS version? Your Ubuntu release there is over 4 years old, which is an eon in the Linux world.
Fair enough. The GNU build system is dark, deep and impenetrable. The four or five folks who really understand it deeply aren't going to help with debugging. I suspect it's time to put a gun to my head and upgrade.
As I wrote in the Github issue the same problem exists on the upstream HEAD.
As I wrote in the Github issue the same problem exists on the upstream HEAD.
slipperygrey
Well-known member
Dark and deep, indeed! In addition, the Netatalk codebase is at least 25 years old, with many sedimentary layers of tech debt.
slipperygrey
Well-known member
@galgot There's a workaround available now in the latest HEAD of branch-netatalk-2-x. See the discussion in https://github.com/rdmark/Netatalk-2.x/issues/13
slipperygrey
Well-known member
A new release has been tagged, that contains the above workaround, plus three more bug fixes. Recommended to upgrade for all users: https://github.com/rdmark/Netatalk-2.x/releases/tag/netatalk-2-220801
I stumbled upon this thread since I've been struggling to find a way to create an AppleShare server after Netatalk 3 has stopped functioning with the older protocols.
The latest release seemed like it went OK, but it still won't appear on my old 68k Macs, and though it does appear on the sidebar in the latest macOS, it simply fails to login with an error. I've been scrambling on the internet for weeks, but to find no answers or solutions.
I do see some error that I have no clue what it's about - any help appreciated getting Netatalk 2.x up and running
Nov 19 18:10:58 raspberrypi afpd[1103]: Failed to commit entry group: Is empty
Code:
Nov 19 18:10:52 raspberrypi systemd[1]: Started Netatalk AFP fileserver for Macintosh clients.
Nov 19 18:10:58 raspberrypi afpd[1103]: Raspberry Pi:AFPServer@* started on 65280.5:131 (2.221101)
Nov 19 18:10:58 raspberrypi afpd[1103]: "Raspberry Pi"'s signature is 397509BD4D6B41A2B6045F8A28DA9C28
Nov 19 18:10:58 raspberrypi afpd[1103]: uam: "DHX2" available
Nov 19 18:10:58 raspberrypi afpd[1103]: uam: "Cleartxt Passwrd" available
Nov 19 18:10:58 raspberrypi afpd[1103]: uam: "No User Authent" available
Nov 19 18:10:58 raspberrypi afpd[1103]: Failed to commit entry group: Is empty
Nov 19 18:10:58 raspberrypi afpd[1103]: Successfully started avahi loop.
Nov 19 18:10:58 raspberrypi afpd[1103]: Registering CNID module [last]
Nov 19 18:10:58 raspberrypi afpd[1103]: Registering CNID module [dbd]Nov 19 18:10:09 raspberrypi afpd[499]: dsi_tcp: couldn't find network interface with IP address to advertice, check to make sure "raspberrypi" is in /etc/hosts or can be resolved with DNS, or add a netinterface that is not a loopback or point-2-point type
Code:
Nov 19 18:10:07 raspberrypi systemd[1]: Starting Netatalk AFP fileserver for Macintosh clients...
Nov 19 18:10:08 raspberrypi systemd[1]: netatalk.service: Can't open PID file /var/lock/netatalk (yet?) after start: No such file or directory
Nov 19 18:10:08 raspberrypi systemd[1]: Started Netatalk AFP fileserver for Macintosh clients.
Nov 19 18:10:08 raspberrypi netatalk[495]: Netatalk AFP server starting
Nov 19 18:10:08 raspberrypi netatalk[495]: Registered with Zeroconf
Nov 19 18:10:09 raspberrypi cnid_metad[501]: CNID Server listening on localhost:4700
Nov 19 18:10:09 raspberrypi afpd[499]: dsi_tcp: couldn't find network interface with IP address to advertice, check to make sure "raspberrypi" is in /etc/hosts or can be resolved with DNS, or add a netinterface that is not a loopback or point-2-point type
Nov 19 18:10:09 raspberrypi afpd[499]: Netatalk AFP/TCP listening on :::548slipperygrey
Well-known member
@Yoshihide At least part of the problem here is that Netatalk 3.x is still running. You need to properly uninstall Netatalk 3.x, or at the very least disable the `netatalk` systemd service, before attempting to run Netatalk 2.x on your system.
Thanks, uninstalling Netatalk 3.x did the trick... partly.
There are no errors, everything looks OK, and I can access it from a modern macOS. But, not from a 68k Mac with System 7.1.
It simply won't appear in the Chooser "AppleShare" servers like it did on older versions of the original Netatalk.
bummed. what else could be wrong here?
Code:
pi@raspberrypi:~ $ nbplkup
raspberrypi:ProDOS16 Image 65280.151:3
raspberrypi:Apple //e Boot 65280.151:3
HP ENVY 110:LaserWriter 65280.151:133
raspberrypi:AFPServer 65280.151:131
raspberrypi:TimeLord 65280.151:129
raspberrypi:Apple //gs 65280.151:3
pi@raspberrypi:~ $ systemctl status afpd
● afpd.service - Netatalk AFP fileserver for Macintosh clients
Loaded: loaded (/lib/systemd/system/afpd.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2022-11-20 12:54:01 JST; 2min 44s ago
Process: 1251 ExecStart=/usr/local/sbin/afpd -c 20 (code=exited, status=0/SUCCESS)
Tasks: 3 (limit: 2058)
CPU: 4.930s
CGroup: /system.slice/afpd.service
├─1257 /usr/local/sbin/afpd -c 20
└─1528 /usr/local/sbin/afpd -c 20
Nov 20 12:55:03 raspberrypi afpd[1257]: child[1522]: exited 1
Nov 20 12:55:03 raspberrypi afpd[1257]: child[1505]: done
Nov 20 12:55:03 raspberrypi afpd[1527]: AFP/TCP session from 192.168.26.101:64280
Nov 20 12:55:03 raspberrypi afpd[1257]: child[1526]: exited 1
Nov 20 12:55:03 raspberrypi afpd[1257]: child[1527]: done
Nov 20 12:55:03 raspberrypi afpd[1528]: AFP/TCP session from 192.168.26.101:64281
Nov 20 12:55:03 raspberrypi afpd[1528]: DHX2 login: pi
Nov 20 12:55:05 raspberrypi afpd[1528]: AFP3.3 Login by pi
Nov 20 12:55:05 raspberrypi afpd[1528]: Volume /home/pi/afpshare use CNID scheme dbd.
Nov 20 12:55:05 raspberrypi afpd[1528]: CNID server: localhost:4700
pi@raspberrypi:~ $ systemctl status atalkd
● atalkd.service - Netatalk AppleTalk daemon
Loaded: loaded (/lib/systemd/system/atalkd.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2022-11-20 12:54:01 JST; 2min 52s ago
Process: 496 ExecStart=/usr/local/sbin/atalkd (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 2058)
CPU: 55ms
CGroup: /system.slice/atalkd.service
└─522 /usr/local/sbin/atalkd
Nov 20 12:53:15 raspberrypi systemd[1]: Starting Netatalk AppleTalk daemon...
Nov 20 12:53:15 raspberrypi atalkd[522]: Set syslog logging to level: LOG_DEBUG
Nov 20 12:53:15 raspberrypi atalkd[522]: restart (2.221101)
Nov 20 12:53:17 raspberrypi atalkd[522]: zip_getnetinfo for eth0
Nov 20 12:53:40 raspberrypi atalkd[522]: zip_getnetinfo for eth0
Nov 20 12:53:50 raspberrypi atalkd[522]: zip_getnetinfo for eth0
Nov 20 12:54:00 raspberrypi atalkd[522]: config for no router
Nov 20 12:54:01 raspberrypi atalkd[522]: ready 0/0/0
Nov 20 12:54:01 raspberrypi systemd[1]: Started Netatalk AppleTalk daemon.
pi@raspberrypi:~ $ systemctl status netatalk
● netatalk.service
Loaded: loaded (/etc/init.d/netatalk; generated)
Active: active (exited) since Sun 2022-11-20 12:53:15 JST; 3min 42s ago
Docs: man:systemd-sysv-generator(8)
Process: 502 ExecStart=/etc/init.d/netatalk start (code=exited, status=0/SUCCESS)
CPU: 42ms
Nov 20 12:53:15 raspberrypi systemd[1]: Starting netatalk.service...
Nov 20 12:53:15 raspberrypi systemd[1]: Started netatalk.service.
pi@raspberrypi:~ $slipperygrey
Well-known member
@Yoshihide Did you try out different configurations in /etc/netatalk/atalkd.conf ? I suspect that the AppleTalk routing between your server and your System 7.1 Mac isn't working. I have some configuration examples in my README, and there's more in the official Netatalk 2.x docs on SourceForge.
One thing you can try to see if the routing works, is to turn on file sharing on your System 7.1 Mac. If routing works, the `nbplkup` tool should be able to see the file server that's running on the Mac.
One thing you can try to see if the routing works, is to turn on file sharing on your System 7.1 Mac. If routing works, the `nbplkup` tool should be able to see the file server that's running on the Mac.
Both don't seem to work either.
I haven't really tried different configurations for atalkd.conf, becuase there's only one interface (eth0), and no other options. There is WiFi, but not connected or used.
So the only option in atalkd.conf is adding "eth0", which after a reboot would be populated with there parameters:
This is pretty much the same as when it did work with the original Netatalk 2.2 with an older version of the OS, so it's unlikely these settings are incorrect.
As with the 'nbplkup', I've tried enabling it on my SE/30 as shown below, but it doesn't seem to catch that on the linux server side. No signs of any Macintosh SE/30 there.
Wi-Fi is currently blocked by rfkill.
Use raspi-config to set the country before use.
pi@raspberrypi:~ $ nbplkup
raspberrypi
raspberrypi:Apple //e Boot 65280.88:3
HP ENVY 110:LaserWriter 65280.88:133
Raspberry Pi:AFPServer 65280.88:131
raspberrypi:TimeLord 65280.88:129
raspberrypi:Apple //gs 65280.88:3
slipperygrey
Well-known member
@Yoshihide What does the network topography look like between the two systems? What kinds of routers sit in between? The AppleTalk packets are seemingly not being routed correctly between the two systems.
BINGO
I realized that there is a wireless converter between the hub that the SE/30 is connected to and the hub that the RPi is connected to.
Moved the SE/30 and connected it directly to the same hub as the RPi and now they both see each other, including the printer.
But, this is quite strange - This setup with the wireless converter in between has worked flawlessly for years and known to pass AppleTalk packets. Nothing has been altered until today.
I don't see how upgrading the RPi OS and Netatalk would somehow magically change how the wireless converters, that have no physical connection to the RPi, work and stop passing AppleTalk packets.
Are there any differences in the original Netatalk and your version on how it identifies and sends out packets?
slipperygrey
Well-known member
@Yoshihide Good to hear that you figured out where it got hung up. I don't know of any deliberate changes that we made to the low level DDP networking layer of Netatalk in my fork. After fixing the obvious low hanging fruit bugs and merging a few dozen community patches, what I did was to pretty much follow along with Chris Kobayashi's netatalk-classic project, which led to a huge amount of refactoring and getting rid of dead/useless features and unused platform code, while strengthening the security here and there. Unlike Chris's project, I did not deprecate DSI (the TCP/IP layer). All that said, the tens of thousands of lines code that were changed could easily have led to the introduction of any number of corner case bugs that we haven't caught yet.
One thing you could try, if you like, is to run the bleeding edge upstream Netatalk 2.2. This is the more conservative branch, where all patches have been vetted by veteran Netatalk (and Samba) maintainer Ralph Boehme. It should functionally be identical to Netatalk 2.x, with the main difference that you have to pass a bunch of option parameters to the configure script in order to enable DDP and other AppleTalk components.
One thing you could try, if you like, is to run the bleeding edge upstream Netatalk 2.2. This is the more conservative branch, where all patches have been vetted by veteran Netatalk (and Samba) maintainer Ralph Boehme. It should functionally be identical to Netatalk 2.x, with the main difference that you have to pass a bunch of option parameters to the configure script in order to enable DDP and other AppleTalk components.
twelvetone12
Well-known member
@slipperygrey do you know if there is a way to only configure one interface in netatalk-2.2x? I've been playing with my tashtalh lt0 driver. My configuration of atalkd is like this:
When the program starts, I see packets going off lt0 on the LocalTalk. yeah! But then it always configure automatically the ethernet eth0, and everything then gets routed there. When I close the program, if also removes my lt0 line and overwrites it with eth0!
Is there a way to disable this? I've reading the code and the docs and I can't figure it out. Thanks!
lt0 -phase 2 -net 0.65534 -addr 65280.251When the program starts, I see packets going off lt0 on the LocalTalk. yeah! But then it always configure automatically the ethernet eth0, and everything then gets routed there. When I close the program, if also removes my lt0 line and overwrites it with eth0!
Is there a way to disable this? I've reading the code and the docs and I can't figure it out. Thanks!
slipperygrey
Well-known member
@twelvetone12 Right, I know what you're talking about -- atalkd is trying to be clever and autoconfigures itself. It doesn't always have the desired outcome. The brute force approach that I'm aware of is to make atalkd.conf read-only by everyone, i.e. "chmod 444".
I have a vague recollection that there's a more sophisticated method as well, but my memory fails me at the moment. Perhaps searching the ML archives will reap rewards?
I have a vague recollection that there's a more sophisticated method as well, but my memory fails me at the moment. Perhaps searching the ML archives will reap rewards?
slipperygrey
Well-known member
I love your work equally! Your guide was a godsend some three years ago when I needed to (re)learn everything about classic Mac networking. I'd be honored to assist in updating the Netatalk section.
Glancing through the section, the overall flow is still valid, but a lot of the specific steps, commands, packages etc. would have to be updated to make this applicable on the latest stable Netatalk 2.2.x. I think it'd be worth the effort to make these updates. Please let me know your preferred method of collaboration. Maybe we can drop the section into a Google doc and take it from there?
Two other minor tweaks for your consideration:
One paragraph talks about MacPorts and Fink. You may want to add a note on Homebrew there. Homebrew has an actively maintained cask for Netatalk.
Regarding this sentence:
Time Machine support was actually introduced with Netatalk 2.0.5! The unique features in Netatalk 3.x are: OSX style file metadata, AFP 3.4 compliance (2.x only supports up to 3.3), Samba interoperability, and Spotlight support via GNOME Tracker.
Pardon my nitpicking.
Mk.558
Well-known member
Your nitpicking is desired as that guide was specifically ran though with a fine toothed comb (about the size you'd use to comb the desert) with a general concept that I had verify every single claim I made. If someone said on the internet that Panther can connect to System 7 server, but I couldn't reproduce it, I didn't put it in there unless I found the secret (that was major headache tbh). I'm not going to say that Disk Copy 4.2 will work on a 512K unless I actually tested it. (spoiler: it doesn't work, it doesn't have enough memory)
I don't know when I'll update it but I've got it on my mind for another major update. Many of the websites referenced have changed or gone down (thanks Apple KB) so one of the major changes will be to switch to local archived backups of those referenced sites.
As for collaboration, the only thing I can say is drop the suggestions/corrections/comments/errors here and I'll work them in whenever I get around to it. As far as I'm concerned, everything in that guide is public domain, I don't care what people do with it as long as it's not grossly negative, fundamentally wrong and some attribution is nice but not required.
I don't know when I'll update it but I've got it on my mind for another major update. Many of the websites referenced have changed or gone down (thanks Apple KB) so one of the major changes will be to switch to local archived backups of those referenced sites.
As for collaboration, the only thing I can say is drop the suggestions/corrections/comments/errors here and I'll work them in whenever I get around to it. As far as I'm concerned, everything in that guide is public domain, I don't care what people do with it as long as it's not grossly negative, fundamentally wrong and some attribution is nice but not required.
slipperygrey
Well-known member
I had to go through the exact same process earlier this year when updating the netatalk html documentation. Dozens of links had to be updated or pointed to the Wayback Machine archives.
For a few concrete examples of how the flow has changed since you wrote your guide, you can see this wiki page that I wrote last year. It practically follows the same steps as you have documented, but with some key changes to packages and configure parameters.
Anyhow, so reading through your guide, here are the high level improvement I can think of:
- Use the very latest 2.2 release, which are now published on the Github project
- Link to the 2.2 manual instead of the 2.1 one
- Debian 11 Bullseye is probably the sweet spot right now as far as Linux distros goes. Ubuntu 22.04 and Debian 12 Bookworm have migrated to OpenSSL 3.0 which breaks the DHX UAM unfortunately. We're working on a fix (which will likely involve not using OpenSSL at all.)
- The "libgcrypt20-dev" package is required for building the DHX2 UAM -- which is recommended because it allows you to authenticate with any recent macOS client, for handy file sharing between very new and very old Macs!
- In case your system don't already have it, the "cups" package is required for papd printing to work fully with CUPS.
- Instead of using the init.d scripts, the newly added systemd services are much more user friendly. So instead of "--enable-debian", pass "--enable-systemd" to ./configure and use systemctl to control the services (see my wiki page for examples.)
- DDP, a2boot, papd, and timelord are all configured and built by default. No need to pass those configure parameters.
- Zeroconf / Bonjour should work perfectly out of the box without having to use the "--enable-zerconf" parameter, as long as you have the Avahi client dev package installed.
- These days ifconfig is phased out in favor of ip (e.g. "ip addr show")
- You shouldn't have to manually edit atalkd.conf in most scenarios -- atalkd autodetects interfaces and attempts to write optimized configurations by itself. If you have multiple interfaces or network bridges you may have to manually configure it though.
- Consider adding a paragraph about papd.conf -- adding a line that says
should make papd register any CUPS / AirPrint compatible printers it can see on the network and make them available via the LaserWriter driver on a classic Mac. It's amazing how seamless it is, really!Code:
cupsautoadd:op=root: - Also, consider mentioning timelord and Tardis. If you pop the Tardis extension into your System Folder, you can sync time with netatalk and bypass those pesky Y2K date picker bugs in old Mac OS versions!
Last edited:
