• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Yet Another Netatalk 2.2 Fork

slipperygrey

Well-known member
Sure :
gcc version 6.3.0 20170516 (Raspbian 6.3.0-18+rpi1+deb9u1)
Thanks! That's far older than the baseline versions I've been developing against (gcc 8 in Buster, and gcc 10 in Bullseye). If at all possible I'd recommend moving to a more contemporary Raspbian version.

But if I you prefer not to, try removing this line in ./configure.ac and start over with the bootstrap process:
CFLAGS="-Wall -Werror $CFLAGS"
 

galgot

Well-known member
Thanks! That's far older than the baseline versions I've been developing against (gcc 8 in Buster, and gcc 10 in Bullseye). If at all possible I'd recommend moving to a more contemporary Raspbian version.

But if I you prefer not to, try removing this line in ./configure.ac and start over with the bootstrap process:
CFLAGS="-Wall -Werror $CFLAGS"
Thanks to you :)
I was suspecting that was something to do with my older raspbian distro...
Will try that trick tomorrow.
Good evening.
 

slipperygrey

Well-known member
@galgot I pushed some changes to branch-netatalk-2-x just now that should take care of the immediate issues that you were having. That said, there may still be other incompatibilities with gcc 6.3.0 hiding under the surface. Please let me know how it goes!
 

galgot

Well-known member
Hi @slipperygrey ,
Sorry this one fails again at build. Here is how I try to be sure I'm not goofing :
git clone https://github.com/rdmark/Netatalk-2.x. <-- is it the correct one to get ?
cd Netatalk-2.x/
./bootstrap
./configure --enable-systemd --enable-zeroconf
make all

fails here :
... Makefile:868: ../../etc/afpd/.deps/test-volume.Po: Aucun fichier ou dossier de ce type make[3]: *** Aucune règle pour fabriquer la cible « ../../etc/afpd/.deps/test-volume.Po ». Arrêt. make[3] : on quitte le répertoire « /home/galgot/Documents/Netatalk-2.x/test/afpd » Makefile:424 : la recette pour la cible « all-recursive » a échouée make[2]: *** [all-recursive] Erreur 1 make[2] : on quitte le répertoire « /home/galgot/Documents/Netatalk-2.x/test » Makefile:477 : la recette pour la cible « all-recursive » a échouée make[1]: *** [all-recursive] Erreur 1 make[1] : on quitte le répertoire « /home/galgot/Documents/Netatalk-2.x » Makefile:407 : la recette pour la cible « all » a échouée make: *** [all] Erreur 2

(Translation : "Aucun fichier ou dossier de ce type" means "No file or folder of this type"
"Aucune règle pour fabriquer la cible" ---> "no rules to build target"
"Arrêt" ---> "stop"
"on quitte le répertoire" ---> "we leave directory..."
"la recette pour la cible « all-recursive » a échouée" ---> "the recipe for target « all-recursive » failed"
...)

Also tried removing
CFLAGS="-Wall -Werror $CFLAGS"
from ./configure.ac earlier. But it failed build too.
 

slipperygrey

Well-known member
@galgot Would you mind sending me the full output of configure and make up to the error, in a private message? There may be some hints earlier in the logs about why test-volume.Po doesn't get created.

Also, let me know the contents of etc/afpd/.deps/ -- I think all those test_* files are dummy files anyways.
 

slipperygrey

Well-known member
A new stable release of Netatalk 2.x is now available: https://github.com/rdmark/Netatalk-2.x/releases/tag/netatalk-2-220701

The main fix is resolving a regression bug in the previous release, 220401, which led to dsi_stream_read errors when establishing DSI connections under certain circumstances. It seems to have been caused by a refactoring of the logging routines. Reverting those changes leaves us with slightly lower quality logs, until I can figure out how to apply those changes without messing with DSI.

I'm also introducing an easy install shell script, tested on Debian Linux and derivatives. Find it in ./contrib/shell_utils/debian_install.sh

The project's README.md is now much fleshed out, borrowing contents I wrote for the RaSCSI wiki, to make it a one stop shop for getting started with Netatalk.

Beyond this, there are a few improvements to Makefiles and header imports to make the codebase more compatible with modern Linux distros and toolchains. (As reported by users of Arch and Alpine Linux.)
 

foo8ar

New member
First of all. Thank you very much for keeping Netatalk up to date and working like a charm!!

I just installed on an Ubuntu Server 20.04 LTS with some very minor issues.
1. The installation script assumes (line 75) that there the local user (not sudo) have full rights to the share paths, which might not be the case. It bales out on "mkdir"
2. The services are not enabled as part of the installation even though the confgured with the default --enable-systemd

Again thx!

/f
 

slipperygrey

Well-known member
@foo8ar Thanks for using my fork, and for taking the time to provide feedback!

For the script permission thing, I just pushed an update that I think should accomplish what we want regardless of the current user privileges. Please have a look and let me know if it looks good to you.

Regarding the systemd service enabling issue, the expected behavior with the --enable-systemd option is that services gets installed and enabled, but not started. I've introduced another option, --enable-systemd-start, for when you want to have 'make install' also start the services for you. Is this what you're seeing too, or are your services actually not even enabled? (Which would definitely be a bug.)
 
Last edited:

NJRoadfan

Well-known member
Note that the other options using init.d don't start netatalk services after a 'make install' either. You have to manually run the startup script or reboot.
 

foo8ar

New member
@foo8ar Thanks for using my fork, and for taking the time to provide feedback!

For the script permission thing, I just pushed an update that I think should accomplish what we want regardless of the current user privileges. Please have a look and let me know if it looks good to you.
The change looks good to me :) thank you very much.

Regarding the systemd service enabling issue, the expected behavior with the --enable-systemd option is that services gets installed and enabled, but not started. I've introduced another option, --enable-systemd-start, for when you want to have 'make install' also start the services for you. Is this what you're seeing too, or are your services actually not even enabled? (Which would definitely be a bug.)
As the services weren't enabled I had to enable the services manually like below. And no, a restart did not fix that.
local@finback:/usr/local/src/NA$ sudo systemctl enable atalkd
Created symlink /etc/systemd/system/multi-user.target.wants/atalkd.service → /lib/systemd/system/atalkd.service.


BR
/f
 

Chopsticks

Well-known member
@slipperygrey how hard would this be to get building on modern macOS? I know Mac is bad based but uses launchd as its startup service. I use some somewhere called Homebrew unix software (its kinda like apt-get) that might be the way to go for this?
Im not really skilled in porting software though so im not really sure if this is an easy or hard task to do?
 

slipperygrey

Well-known member
@Chopsticks Netatalk 2.x relies on AppleTalk support being provided by the kernel, whereas macOS has long since deprecated AppleTalk. However, if you don't care about AppleTalk and are content with AFP over TCP/IP, you might want to look into one of the versions of Netatalk 3.x instead. Perhaps the homebrew repo already has a version Netatalk? Have you looked?

I've also stumbled upon this Netatalk 3.x fork that has been optimized for macOS that you could try to build from scratch. (It's not my fork, and I haven't tested it.)
 

Chopsticks

Well-known member
@slipperygrey thanks for the info, wasn't aware that it used a kernel module. I guess that completely rules out any future macOS support.
I have looked at netatalk v3 but as far as I know version 3 just won't and cannot work with system 6 or 7.x due to something being removed in the newer netatalk.
 

slipperygrey

Well-known member
@Chopsticks You're welcome. I think the way forward would be to implement AppleTalk networking in userspace, perhaps in an interpreted language such as Python for readability and maintainability. Even on Linux relying on the appletalk kernel module is iffy, since the Linux kernel contributors have broken it in the past, and are likely to break it again. And the next time noone might care enough to try to fix it.

And yes, the oldest Mac OS version that can do TCP/IP AFP is 7.1 (if you manually copy over a few extensions). Mac OS 7.5 or later is recommended.
 

slipperygrey

Well-known member
@slipperygrey just how hard would it be to move it into userspace? I guess doing that would allow it to be more portable and platform independent going forward?
Somewhere inbetween harder than trivial but easier than impossible. ;)

Joke aside, I'd have to dig into the appletalk code to get a sense for the complexity involved. Maybe a project for next summer!
 

Chopsticks

Well-known member
@slipperygrey that sounds like quite the challenge then.
if you do ever feel like going down that road and trying to reimplement AppleTalk in userspace it would be pretty awesome.
id certainly be signing up to test and help out with that side of stuff. ive got a few Macs and they run everything from system 6.0.8 to 9.2.2 so it would be great to someday have them all connected to the same AFP share... running on a modern MacOS
 
Top