• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Doctorin' the Tardis (and Timelord): The Revived AppleTalk Time Server

Byte Knight

Well-known member
Can anyone walk me through the process of installing this onto an existing A2SERVER on a Raspberry Pi? I'd rather not start over with a whole new installation of Netatalk. I can figure it out on the Mac side of things...
 

cheesestraws

Well-known member
Can anyone walk me through the process of installing this onto an existing A2SERVER on a Raspberry Pi?

The easiest option might be if @mactjaap can send you their binary for the Pi? I am not set up for building stuff on the Pi unfortunately, so I could try to talk you through it but would be doing so without being able to reproduce on my end, which sounds of dubious use
 

Byte Knight

Well-known member
The easiest option might be if @mactjaap can send you their binary for the Pi? I am not set up for building stuff on the Pi unfortunately, so I could try to talk you through it but would be doing so without being able to reproduce on my end, which sounds of dubious use
You could SSH into my Pi if you wanna give it a shot.
 

slipperygrey

Well-known member
@Byte Knight One trick that you can try, is to go through the steps to check out Netatalk code (e.g. Netatalk 2.2.x) then configure it with --enable-timelord and compile it. This will give you the compiled timelord binary for your platform in the contrib/timelord/ subdir.

At that point, you can either run the binary from that location whenever you need it, or manually copy the binary to whatever location Netatalk binaries are currently installed (and optionally, update the startup script to append '-l' to the shell command that starts timelord if it is localtime that you want.)

Or, lobby @NJRoadfan to have A2SERVER get a new release. :)
 

Byte Knight

Well-known member
@Byte Knight One trick that you can try, is to go through the steps to check out Netatalk code (e.g. Netatalk 2.2.x) then configure it with --enable-timelord and compile it. This will give you the compiled timelord binary for your platform in the contrib/timelord/ subdir.

At that point, you can either run the binary from that location whenever you need it, or manually copy the binary to whatever location Netatalk binaries are currently installed (and optionally, update the startup script to append '-l' to the shell command that starts timelord if it is localtime that you want.)

Or, lobby @NJRoadfan to have A2SERVER get a new release. :)
Thanks for the suggestion, but as usual Linux hates me and I get all sorts of errors when I try to compile. I'll hit up @mactjaap for the binary.

I'd love to see a new release of A2SERVER - that was a breeze to set up...
 

mactjaap

Well-known member

sailingdarter

New member
Hi everyone. I feel bad for barging in here but I wanted to comment that I think this is great that people starting to work on Netatalk again. A little over a year ago, I posted a thread to r/VintageApple asking if anyone knew the status of the project. Because I had started to fear that the project had started to rot.

https://www.reddit.com/r/VintageApple/comments/grcbaa
The only reason I wanted to bring it to the attention of the folks here was that I wanted to avoid effort duplication and hope that everyone is (hopefully) collaborating on the same git repo :)
 

cheesestraws

Well-known member
I feel bad for barging in here

Hello and welcome! Don't feel bad for joining in the conversation, it's welcome. Have some opinions that you may or may not find useful:

I don't know about A2Server but I know that macipgw is being actively updated, as you can tell from @mactjaap's involvement upthread. There are regular updates on the various macipgw projects on these forums.

I don't believe there are problems with DDP on the Pi 4 as such, but there was quite a long period where DDP in the Linux kernel was broken, and it's still not what I'd consider a really reliable feature. Which is fair enough, it's hardly their priority. But netatalk2 is reliant on the underlying OS to provide basic DDP support, and if the DDP support is broken, netatalk2 won't run.

Personally, I run netatalk2 on top of NetBSD, as I'm sure people are tired of me banging on about. The DDP code in the kernel seems to be better maintained, and there's an actively maintained binary package that is tested and updated for new versions of NetBSD.

In terms of the logistics of keeping the codebase alive in an organised fashion, I know that @slipperygrey is trying to roll all the bug fixes into one place and git repo and try to manage the codebase a bit, and I believe is trying to contribute them upstream to the "main" netatalk repository. I'm always grateful for people who are willing to do that kind of work for fun: it's far too much like what I do for work, so I can never muster the energy to do it myself. I also know that @NJRoadfan has fixed multiple bugs in both netatalk2 generally and A2server more specifically, but I don't know how they organise their code or contribute it or whatever. The NetBSD package maintainer has also been around here intermittently sniffing out bug fixes.

Personally I just occasionally write stuff and fling it at whoever looks most like a project maintainer, I'm afraid!

In the really long term, I'm not convinced that netatalk2 is the right codebase to be building on. netatalk2 is a tool for big networks with complicated requirements, which is why its configuration has lots of switches and options, and why it needs finesseing on networks without a router. It's also fairly dense, fairly old-school C that is written to perform, rather than to be comprehensible or maintainable. So, while it was a good tool for corporate/largeish-network AppleTalk, it isn't really suitable for home use with a small handful of machines. That's not meant of course to argue that people who are doing logistics on keeping netatalk2 building and working are wasting their time, they're doing good work that I couldn't, and I appreciate them. But it'd also be nice to have a simpler, easier to maintain appletalk stack that perhaps didn't have all the features and performance for hobbyist use.

For the last two or three years I've been slowly trying to put together pieces for that kind of AppleTalk stack, though I don't know whether we'll ever get there or not. The two results of this project that are currently actually real are the LocalTalk over UDP support in Mini vMac, and the AirTalk wireless dongle for classic macs (which isn't quite finished yet but I think it's fair to say is in late-stage beta testing). I'm kind of letting that project go where it wilt, because it's more interesting that way...
 

slipperygrey

Well-known member
@sailingdarter Hi there, I'm the person you spoke to most recently on that Reddit thread, so you certainly came to the right place. There's a parallel thread here for discussion around the Netatalk 2.x fork that I made, which is where I'm aiming to collect and merge all community patches including the Timelord improvements from this one. Please don't hesitate to use it and contribute your own improvements!
 

slipperygrey

Well-known member
In the really long term, I'm not convinced that netatalk2 is the right codebase to be building on. netatalk2 is a tool for big networks with complicated requirements, which is why its configuration has lots of switches and options, and why it needs finesseing on networks without a router. It's also fairly dense, fairly old-school C that is written to perform, rather than to be comprehensible or maintainable. So, while it was a good tool for corporate/largeish-network AppleTalk, it isn't really suitable for home use with a small handful of machines. That's not meant of course to argue that people who are doing logistics on keeping netatalk2 building and working are wasting their time, they're doing good work that I couldn't, and I appreciate them. But it'd also be nice to have a simpler, easier to maintain appletalk stack that perhaps didn't have all the features and performance for hobbyist use.
These are very good points -- upstream Netatalk as it exists today is at its core a tool for corporate deployments and large sprawling multi-zone networks with thousands of users and complex access control and authentication needs. The project also has been less than effective at deprecating old platforms and features that are no longer relevant or plain broken. Dead platforms such as Ultrix, SunOS4, IRIX, HP/UX, BSD 4.4, Mac OS X Server, etc? Check! Kerberos 4 and 5 authentication? Yes sir! Features that either don't compile, or noone uses anymore such as Dropbox Kludge, Linux/Solaris ACLs, Quota, SRVLOC, etc? Yep, they're all there for your consideration.

I've been working on a major new update to my Netatalk 2.x fork, in collaboration with Chris, the author of Netatalk-Classic, in retreading his steps to clean up and deprecate 100k+ lines of Netatalk 2 code. Netatalk-Classic, BTW, is an excellent choice if you only care about AppleTalk/DDP networking. He's stripped out all of the DSI and AFP3.x code, amongst much other bloat, which makes it incompatible with OSX / macOS, but gains security and speed. For instance, the atalkd daemon starts up in a split second, which is a miracle if you're familiar with old Netatalk. ;)

To return to the topic for this thread: I worked with Chris to get these improvements to Timelord merged into Netatalk-Classic as well, so they're there in the current development code, but not yet in a release at the time of writing.
 

sailingdarter

New member
@sailingdarter Hi there, I'm the person you spoke to most recently on that Reddit thread, so you certainly came to the right place. There's a parallel thread here for discussion around the Netatalk 2.x fork that I made, which is where I'm aiming to collect and merge all community patches including the Timelord improvements from this one. Please don't hesitate to use it and contribute your own improvements!
That was basically my primary concern, In that Reddit thread there were several folks saying that they made patches and I did not want this to end up as a situation where there were several Netatalk 2 forks and I would have to figure out which one to use. So I am glad that there is some effort a consolidation. I just hope that everyone in that thread knows about your repo and your efforts. I think there was actually one other reply in addition to yourself and @NJRoadfan who mentioned they were making patches.

Their repo was located at the link below


So I was just hoping that they were also included in the efforts :)

P.S. I hope I didn't come off too much like a "Project Manager" or SCRUM Master during all of this :) I appreciate the efforts that you have all done. I just wish that the codebase wasn't so dense and sparsely commented. For awhile I felt that this would have been a good opportunity to dip my toes back into C (my day job is mostly REST API development with some infrastructure Java thrown in) but after trying to read the codebase I quickly realized that I was out of my depth.
 

slipperygrey

Well-known member
@sailingdarter May I suggest we bring further general Netatalk discussion elsewhere, such as the sister thread that I referenced earlier?

But yes, to answer your question, I did review the commit history in dawn-minion's fork the other day. The substance of those patches are already in my Netatalk 2.x fork.

Regardless, I appreciate your passion for keeping Netatalk alive! If you want to contribute, why don't you check out the latest development code in my fork and test it with your old Macs, including the updated Timelord of course (which is the topic of the thread ;) ). As I mentioned above, I've just merged a HUGE changeset to my main branch which should make it a lot leaner and easier to work in.
 

slipperygrey

Well-known member
Along with a lot of other good stuff, by the look of it! Is that most of the patches you'd collected? Very good work, I'm really pleased.
The vast majority of the community patches have been merged, and the head of branch-netatatalk-2-2 is indeed more or less at par with Netatalk 2.x v220101. The only one patch that was rejected was the one for preventing timestamps to be updated when copying folders on GS/OS. Apparently that patch broke conformance with the AFP3 spec. I guess some sacrifices have to be made when you try to support everything from Apple II clients all the way up to macOS Monterey. ;)
 
Top